Remediating Security Health Analytics findings

This page provides a list of reference guides and techniques for remediating Security Health Analytics findings using Security Command Center.

You need adequate Identity and Access Management (IAM) roles to view or edit findings, and to access or modify Google Cloud resources. If you encounter permissions errors when accessing Security Command Center in the Google Cloud console, ask your administrator for assistance and, to learn about roles, see Access control. To resolve resource errors, read documentation for affected products.

Security Health Analytics remediation

This section includes remediation instructions for all Security Health Analytics findings.

For finding types that are mapped to CIS Benchmarks, the remediation guidance comes from Center for Internet Security (CIS), unless otherwise stated. For more information, see Detectors and compliance.

Automatic deactivation of findings

After you remediate a vulnerability or misconfiguration finding, Security Health Analytics automatically sets the state of the finding to INACTIVE the next time it scans for the finding. Disabling a detector in Security Health Analytics also sets the state of any findings generated by that detector to INACTIVE. How long Security Health Analytics takes to set a remediated finding to INACTIVE depends on when the finding is fixed and the schedule of the scan that detects the finding.

Security Health Analytics also sets the state of a finding to INACTIVE when a scan detects that the resource that is affected by the finding is deleted. If you want to remove a finding for a deleted resource from your display while you are waiting for Security Health Analytics to detect that the resource is deleted, you can mute the finding. To mute a finding, see Mute findings in Security Command Center.

Do not use mute to hide remediated findings for existing resources. If the issue recurs and Security Health Analytics restores the ACTIVE state of the finding, you might not see the reactivated finding, because muted findings are excluded from any finding query that specifies NOT mute="MUTED", such as the default finding query.

For information about scan intervals, see Security Health Analytics scan types.

Access Transparency disabled

Category name in the API: ACCESS_TRANSPARENCY_DISABLED

Access Transparency logs when Google Cloud employees access the projects in your organization to provide support. Enable Access Transparency to log who from Google Cloud is accessing your information, when, and why. For more information, see Access Transparency.

To enable Access Transparency on a project, the project must be associated with a billing account.

Required roles

To get the permissions that you need to perform this task, ask your administrator to grant you the Access Transparency Admin (roles/axt.admin) IAM role at the organization level. For more information about granting roles, see Manage access.

This predefined role contains the permissions axt.labels.get and axt.labels.set, which are required to perform this task. You might also be able to get these permissions with a custom role or other predefined roles.

Remediation steps

To remediate this finding, complete the following steps:

  1. Check your organization-level permissions:

    1. Go to the Identity and Access Management page on the Google Cloud console.

      Go to Identity and Access Management

    2. If you're prompted, select the Google Cloud organization in the selector menu.

  2. Select any Google Cloud project within the organization using the selector menu.

    Access Transparency is configured on a Google Cloud project page but Access Transparency is enabled for the entire organization.

  3. Go to the IAM & Admin > Settings page.

  4. Click Enable Access Transparency.

Learn about this finding type's supported assets and scan settings.

AlloyDB auto backup disabled

Category name in the API: ALLOYDB_AUTO_BACKUP_DISABLED

An AlloyDB for PostgreSQL cluster doesn't have automatic backups enabled.

To help prevent data loss, turn on automated backups for your cluster. For more information, see Configure additional automated backups.

To remediate this finding, complete the following steps:

  1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

    Go to AlloyDB for PostgreSQL clusters

  2. Click a cluster in the Resource Name column.

  3. Click Data protection.

  4. Under the Automated backup policy section, click Edit in the Automated backups row.

  5. Select the Automate backups checkbox.

  6. Click Update.

Learn about this finding type's supported assets and scan settings.

AlloyDB backups disabled

Category name in the API: ALLOYDB_BACKUPS_DISABLED

An AlloyDB for PostgreSQL cluster has neither automatic nor continuous backups enabled.

To help prevent data loss, turn on either automated or continuous backups for your cluster. For more information, see Configure additional backups.

To remediate this finding, complete the following steps:

  1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

    Go to AlloyDB for PostgreSQL clusters

  2. In the Resource Name column, click the name of the cluster that is identified in the finding.

  3. Click Data protection.

  4. Set up a backup policy.

Learn about this finding type's supported assets and scan settings.

AlloyDB CMEK disabled

Category name in the API: ALLOYDB_CMEK_DISABLED

An AlloyDB cluster is not using customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google uses to encrypt your data, giving you more control over access to your data. For more information, see About CMEK. CMEK incurs additional costs related to Cloud KMS.

To remediate this finding, complete the following steps:

  1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

    Go to AlloyDB for PostgreSQL clusters

  2. In the Resource Name column, click the name of the cluster that is identified in the finding.

  3. Click Create Backup. Set a backup ID.

  4. Click Create.

  5. Under the Backup/Restore section, click Restore next to the Backup ID entry you chose.

  6. Set a new cluster ID and network.

  7. Click Advanced Encryption Options. Select the CMEK that you want to encrypt the new cluster with.

  8. Click Restore.

Learn about this finding type's supported assets and scan settings.

AlloyDB log min error statement severity

Category name in the API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

An AlloyDB for PostgreSQL instance does not have the log_min_error_statement database flag set to error or another recommended value.

The log_min_error_statement flag controls whether SQL statements that cause error conditions are recorded in server logs. SQL statements of the specified severity or higher are logged. The higher the severity, the fewer messages that are recorded. If set to a severity level that is too high, error messages might not be logged.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

  1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

    Go to AlloyDB for PostgreSQL clusters

  2. Click the cluster in the Resource Name column.

  3. Under the Instances in your cluster section, click Edit for the instance.

  4. Click Advanced Configuration Options.

  5. Under the Flags section, set the log_min_error_statement database flag with one of the following recommended values, according to your organization's logging policy.

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning
    • error

  6. Click Update Instance.

Learn about this finding type's supported assets and scan settings.

AlloyDB log min messages

Category name in the API: ALLOYDB_LOG_MIN_MESSAGES

An AlloyDB for PostgreSQL instance does not have the log_min_messages database flag set to at minimum warning.

The log_min_messages flag controls which message levels are recorded in server logs. The higher the severity, the fewer messages are recorded. Setting the threshold too low can result in increased log storage size and length, making it difficult to find actual errors.

For more information, see Configuring database flags.

To remediate this finding, complete the following steps:

  1. Go to the AlloyDB for PostgreSQL clusters page in the Google Cloud console.

    Go to AlloyDB for PostgreSQL clusters

  2. Click the cluster in the Resource Name column.

  3. Under the Instances in your cluster section, click Edit for the instance.

  4. Click Advanced Configuration Options.

  5. Under the Flags section, set the log_min_messages database flag with one of the following recommended values, according to your organization's logging policy.

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning

  6. Click Update Instance.

Learn about this finding type's supported assets and scan settings.

AlloyDB log error verbosity

Category name in the API: ALLOYDB_LOG_ERROR_VERBOSITY

An AlloyDB for PostgreSQL instance does not have the log_error_verbosity database flag set to default or another less restrictive value.

The log_error_verbosity flag controls the amount of detail in messages logged. The greater the verbosity, the more details are recorded in messages. We recommend setting this flag to default or another less restrictive value.

For more information, see