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 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_error_verbosity database flag with one of the following recommended values, according to your organization's logging policy.

    • default
    • verbose

  6. Click Update Instance.

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

AlloyDB Public IP

Category name in the API: ALLOYDB_PUBLIC_IP

An AlloyDB for PostgreSQL database instance has a public IP address.

To reduce your organization's attack surface, use private instead of public IP addresses. Private IP addresses provide improved network security and lower latency for your application.

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. Under the Instances in your cluster section, click Edit for the instance.

  4. Under the Connectivity section, uncheck the box for Enable Public IP.

  5. Click Update Instance.

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

AlloyDB SSL not enforced

Category name in the API: ALLOYDB_SSL_NOT_ENFORCED

An AlloyDB for PostgreSQL database instance doesn't require all incoming connections to use SSL.

To avoid leaking sensitive data in transit through unencrypted communications, all incoming connections to your AlloyDB database instance should use SSL. Learn more about Configuring SSL/TLS.

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. Under the Instances in your cluster section, click Edit for the instance.

  4. Under the Network Security section, click the box for Require SSL Encryption.

  5. Click Update Instance.

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

Admin service account

Category name in the API: ADMIN_SERVICE_ACCOUNT

A service account in your organization or project has Admin, Owner, or Editor privileges assigned to it. These roles have broad permissions and shouldn't be assigned to service accounts. To learn about service accounts and the roles available to them, see Service accounts.

To remediate this finding, complete the following steps:

  1. Go to the IAM policy page in the Google Cloud console.

    Go to IAM policy

  2. For each principal identified in the finding:

    1. Click Edit principal next to the principal.
    2. To remove permissions, click Delete role next to the role.
    3. Click Save.

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

Alpha cluster enabled

Category name in the API: ALPHA_CLUSTER_ENABLED

Alpha cluster features are enabled for a Google Kubernetes Engine (GKE) cluster.

Alpha clusters let early adopters experiment with workloads that use new features before they're released to the general public. Alpha clusters have all GKE API features enabled, but aren't covered by the GKE SLA, don't receive security updates, have node auto-upgrade and node auto-repair disabled, and can't be upgraded. They're also automatically deleted after 30 days.

To remediate this finding, complete the following steps:

Alpha clusters can't be disabled. You must create a new cluster with alpha features disabled.

  1. Go to the Kubernetes clusters page in the Google Cloud console.

    Go to Kubernetes clusters

  2. Click Create.

  3. Select Configure next to the type of cluster you want to create.

  4. Under the Features tab, ensure Enable Kubernetes alpha features in this cluster is disabled.

  5. Click Create.

  6. To move workloads to the new cluster, see Migrating workloads to different machine types.

  7. To delete the original cluster, see Deleting a cluster.

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

API key APIs unrestricted

Category name in the API: API_KEY_APIS_UNRESTRICTED

There are API keys being used too broadly.

Unrestricted API keys are insecure because they can be retrieved from devices on which the key is stored or can be seen publicly, for instance, from within a browser. In accordance with the principle of least privilege, configure API keys to only call APIs required by the application. For more information, see Apply API key restrictions.

To remediate this finding, complete the following steps:

  1. Go to the API keys page in the Google Cloud console.

    Go to API keys

  2. For each API key:

    1. In the API keys section, on the row for each API key for which you need to restrict APIs, click Actions.
    2. From the Actions menu, click Edit API key. The Edit API key page opens.
    3. In the API restrictions section, select Restrict APIs. The Select APIs drop-down menu appears.
    4. On the Select APIs drop-down list, select which APIs to allow.
    5. Click Save. It might take up to five minutes for settings to take effect.

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

API key apps unrestricted

Category name in the API: API_KEY_APPS_UNRESTRICTED

There are API keys being used in an unrestricted way, allowing use by any untrusted app.

Unrestricted API keys are insecure because they can be retrieved on devices on which the key is stored or can be seen publicly, for instance, from within a browser. In accordance with the principle of least privilege, restrict API key usage to trusted hosts, HTTP referrers, and apps. For more information, see Apply API key restrictions.

To remediate this finding, complete the following steps:

  1. Go to the API keys page in the Google Cloud console.

    Go to API keys

  2. For each API key:

    1. In the API keys section, on the row for each API key for which you need to restrict applications, click Actions.
    2. From the Actions menu, click Edit API key. The Edit API key page opens.
    3. On the Edit API key page, under Application restrictions, select a restriction category. You can set one application restriction per key.
    4. In the Add an item field that appears when you select a restriction, click Add an item to add restrictions based on the needs of your application.
    5. Once finished adding items, click Done.
    6. Click Save.

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

API key exists

Category name in the API: API_KEY_EXISTS

A project is using API keys instead of standard authentication.

API keys are less secure than other authentication methods because they are simple encrypted strings and easy for others to discover and use. They can be retrieved on devices on which the key is stored or can be seen publicly, for instance, from within a browser. Also, API keys do not uniquely identify users or applications making requests. As an alternative, you can use a standard authentication flow, with either service accounts or user accounts.

To remediate this finding, complete the following steps:

  1. Ensure your applications are configured with an alternate form of authentication.

  2. Go to the API credentials page in the Google Cloud console.

    Go to API credentials

  3. In the API keys section on the row for each API key that you need to delete, click Actions.

  4. From the Actions menu, click Delete API key.

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

API key not rotated

Category name in the API: API_KEY_NOT_ROTATED

An API key hasn't been rotated for more than 90 days.

API keys do not expire, so if one is stolen, it might be used indefinitely unless the project owner revokes or rotates the key. Rotating API keys frequently reduces the amount of time that a stolen API key can be used to access data on a compromised or terminated account. Rotate API keys at least every 90 days. For more information, see Best practices for managing API keys.

To remediate this finding, complete the following steps:

  1. Go to the API keys page in the Google Cloud console.

    Go to API keys

  2. For each API key:

    1. In the API keys section, on the row for each API key that you need to rotate, click Actions.
    2. From the Actions menu, click Edit API key. The Edit API key page opens.
    3. On the Edit API key page, if the date in the Creation date field is older than 90 days, click Rotate key. A new key is generated.
    4. Optionally, change the API key name.
    5. Click Create.
    6. Update your applications to use the new key.
    7. After you have updated your applications, return to the Edit API key page and click Delete the previous key to delete the old key. The old key won't be deleted automatically.

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

Audit config not monitored

Category name in the API: AUDIT_CONFIG_NOT_MONITORED

Log metrics and alerts aren't configured to monitor audit configuration changes.

Cloud Logging produces Admin Activity and Data Access logs that enable security analysis, resource change tracking, and compliance auditing. By monitoring audit configuration changes, you ensure that all activities in your project can be audited at any time. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see