This document includes the best practices and guidelines for building a secure enterprise foundation when running workloads that use Google Cloud. A secure enterprise foundation includes controls for the following:
- Authentication and authorization
- Organization
- Networking
- Logging, monitoring, and alerting
- Key and secret management
- Security posture and analytics
Authentication and authorization
This section includes the best practices and guidelines for Identity and Access Management (IAM) and Cloud Identity when running workloads on Google Cloud.
Disable automatic IAM grants for default service accounts
| Google control ID | IAM-CO-4.1 |
|---|---|
| Implementation | Required |
| Description | Use the By default, some systems grant overly broad permissions to automated accounts, which is a potential security risk. For example, if you don't enforce this constraint and you create a default service account, the service account is automatically granted the Editor role ( |
| Applicable products |
|
| Path | constraints/iam.automaticIamGrantsForDefaultServiceAccounts |
| Operator | Is |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Block the creation of external service account keys
| Google control ID | IAM-CO-4.2 |
|---|---|
| Implementation | Required |
| Description | Use the |
| Applicable products |
|
| Path | constraints/iam.disableServiceAccountKeyCreation |
| Operator | Is |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Block service account key uploads
| Google control ID | IAM-CO-4.3 |
|---|---|
| Implementation | Required |
| Description | Use the |
| Applicable products |
|
| Path | constraints/iam.disableServiceAccountKeyUpload |
| Operator | Is |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Configure separation of duties for organization policy administrators
| Google control ID | OPS-CO-6.1 |
|---|---|
| Implementation | Required |
| Description | Assign the Organization Policy Administrator (
roles/orgpolicy.policyAdmin) role to groups that are accountable for the security posture of the Google Cloud organization. To avoid resource creation that violates security policy, don't assign this role to project owners. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable two-step verification for super admin accounts
| Google control ID | CI-CO-6.1 |
|---|---|
| Implementation | Required |
| Description | Google recommends Titan Security Keys for 2-step verification (2SV) for super admin accounts. However, for use cases where this isn't possible, we recommend using another security key as an alternative. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enforce two-step verification on the super admin organization unit
| Google control ID | CI-CO-6.2 |
|---|---|
| Implementation | Required |
| Description | Enforce 2-step verification (2SV) for a specific organization unit (OU) or the entire organization. We recommend that you create an OU for super admins and enforce 2SV on that OU. |
| Applicable products |
Cloud Identity |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Create an exclusive email address for the primary super admin
| Google control ID | CI-CO-6.4 |
|---|---|
| Implementation | Required |
| Description | Create an email address that's not specific to a particular user as the primary Cloud Identity super admin account.
|
| Applicable products |
Cloud Identity |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Create redundant administrator accounts
| Google control ID | CI-CO-6.7 |
|---|---|
| Implementation | Required |
| Description | Don't have a single super admin or Organization Administrator. Create one or more (up to 20) backup administrator accounts. A single super admin or Organization Administrator can result in lockout scenarios. This situation also carries a higher risk as one person can make platform-altering changes, potentially with no oversight. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use Privileged Access Manager
| Google control ID | GCVE-CO-3.2 |
|---|---|
| Implementation | Required |
| Description | Use Privileged Access Manager for managing privileged access. For all other access, use access groups, let group memberships expire automatically, and implement an approval workflow for group memberships. Using the least privilege model lets you only provide access when needed, for the resources that are needed. Using pre-built roles simplifies use and reduces sprawl caused by custom roles so that you don't have to worry about managing the role lifecycle. |
| Applicable products |
Identity and Access Management (IAM) |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Define the identity source of truth
| Implementation | Required |
|---|---|
| Description | Decide on your source of truth for provisioning managed user identities. Patterns include creating user identities in Cloud Identity, syncing identities from an existing identity provider, or using Workforce Identity Federation. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enforce strong password policies
| Implementation | Required |
|---|---|
| Description | Enforce strong and unique passwords for all user accounts. Consider using a password manager. Weak or no credentials are a common pattern that malicious users can easily exploit. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use roles based on job functions
| Implementation | Required |
|---|---|
| Description | Use Identity and Access Management (IAM) roles that are based on job functions to assign permissions to users. Job functions are predefined roles that allow admins to provide a set of permissions that is limited to a job function, thus improving productivity and reducing the back-and-forth of asking for permissions. To better align with your organization's requirements, you can create custom roles based on predefined roles. |
| Applicable products |
IAM |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict external members in groups
| Implementation | Required |
|---|---|
| Description | Set organization-wide policies to prevent adding external members to Google Groups. By default, external user accounts can be added to groups in Cloud Identity. We recommend that you configure sharing settings so that group owners can't add external members. Note that this restriction doesn't apply to the super admin account or to other delegated administrators with Google Groups admin permissions. Because federation from your identity provider runs with administrator privileges, the group sharing settings don't apply to this group synchronization. We recommend that you review controls in the identity provider and synchronization mechanism to ensure that non-domain members aren't added to groups, or that you apply group restrictions. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Set daily session length
| Implementation | Required |
|---|---|
| Description | Set the session length for Google Cloud services to expire at least once a day. Leaving an account signed in for an extended period is a security risk. Enforcing a maximum session duration automatically ends the session after a set time, forcing a new, secure sign-in. This practice reduces the opportunity for a malicious user to use a stolen password and ensures access is regularly reverified. For new customers, a default session length of 16 hours is automatically enforced. Customers who created their Google Cloud organization before 2023 might have a default setting to never require reauthentication. Review this setting to ensure that you have a reauthentication policy with a session length that is between 1 and 24 hours. The reauthentication policy invalidates the refresh token and forces the user to regularly reauthenticate the gcloud CLI with their password or security key. The session length for Google Cloud services is a distinct setting from session length for Google services, which controls web sessions for sign-in across Google Workspace services but doesn't control reauthentication for the Google Cloud. If you use Google Workspace services, set the session length for both. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Remediate unmanaged consumer accounts
| Implementation | Required |
|---|---|
| Description | Don't permit unmanaged consumer accounts. Consolidate any unmanaged consumer accounts, and consider a solution to prevent the creation of further unmanaged consumer accounts with your domain. Unmanaged consumer accounts are not governed by your joiner-mover-leaver (JML) processes, so they introduce the risk that an employee still has access to your resources after they leave their job. These accounts are also treated as external with regard to controls like domain restricted sharing. |
| Applicable products |
Cloud Identity |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enforce dedicated admins and multiparty approval
| Implementation | Required |
|---|---|
| Description | Ensure that super admin accounts are separate from day-to-day user accounts. Super admin accounts must be dedicated accounts that are used only when making critical changes. For increased security, turn on multiparty approval for admin actions. Turning on multiparty approval means sensitive actions are approved by two administrators, which helps prevent attackers from compromising an admin account and lock out other admin users. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable multi-factor authentication for all Google Accounts and Cloud Identity users
| Google control ID | CI-CO-6.1 |
|---|---|
| Implementation | Required |
| Description | Enable multi-factor authentication (MFA), also known as 2-step authentication (2SV) for all Google Accounts and Cloud Identity users, not just super admins. MFA for super admins is enabled by default. MFA adds another layer of defense because passwords alone often aren't a strong enough security measure. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Revoke default creator roles
| Implementation | Required |
|---|---|
| Description | Remove the domain-wide Project Creator and Billing Account Creator roles that are granted by default to all members in a new organization. New organizations grant the Project Creator and Billing Account Creator roles to all managed user identities in the domain. While these roles are useful for getting started, this configuration isn't intended for production environments. Letting billing accounts proliferate leads to increased administrative overhead and has technical consequences when splitting services across multiple Billing Accounts. Allowing free-form project creation can lead to projects that don't adhere to your governance conventions. Instead, remove these roles and establish a project creation process to request new projects and associate them with billing. |
| Applicable products |
IAM |
| Path | resourcemanager.organizations/iamPolicy.bindings |
| Operator | not_contains |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Rotate service account keys
| Implementation | Required |
|---|---|
| Description | If you must use service account keys, rotate the keys at least once every 90 days. A rotation interval limits how long an attacker can have access to the system. Without a rotation interval, the attacker has access forever. Where possible, consider using Workload Identity Federation instead of service account keys. |
| Applicable products |
IAM |
| Path | constraints/iam.serviceAccountKeyExpiryHours |
| Operator | <= |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use Workload Identity Federation
| Implementation | Required |
|---|---|
| Description | Use Workload Identity Federation to let CI/CD systems and workloads running on other clouds authenticate to Google Cloud. Workload Identity Federation lets workloads that run outside of Google Cloud authenticate without requiring a service account key. By avoiding service account keys and other long-lived credentials, Workload Identity Federation can help you reduce the risk of credential leakage. |
| Applicable products |
IAM |
| Path | iam.googleapis.com/WorkloadIdentityPool |
| Operator | Is set |
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Block account self-recovery for super admin accounts
| Google control ID | CI-CO-6.3 |
|---|---|
| Implementation | Required |
| Description | By default, super admin account self-recovery is off for new customers. However, existing customers might have this setting on. Turning this setting off helps to mitigate the risk that a compromised phone, a compromised email, or a social engineering attack might let an attacker gain super admin privileges over your environment. Plan an internal process for a super admin to contact another super admin in your organization if they have lost access to their account, and ensure that all super admins are familiar with the process for support-assisted recovery. To turn off the feature, go to the account recovery settings in the Google Admin console. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Set idle session timeout for sensitive use cases
| Implementation | Required |
|---|---|
| Description | Set the idle session timeout to 15 minutes for sensitive use cases. Idle sessions might be used by attackers for credential theft. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enforce hardware security keys for administrators
| Implementation | Required |
|---|---|
| Description | Provide hardware security keys, if possible, to super admins or Organization Administrators as a second factor. Super admin accounts are the highest-value targets for sophisticated attacks. Hardware security keys provide a high level of protection because they are phishing-resistant. Hardware security keys are the strongest possible defense against account takeover for your most critical administrators and build on your standard MFA policy. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable post-SSO verification
| Implementation | Required |
|---|---|
| Description | If you're using an external identity provider, set up post-SSO verification. Enable an additional layer of control based on Google's sign-in risk analysis. After you apply this setting, users might see additional risk-based login challenges at sign-in if Google determines that a user sign-in is suspicious. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable principal access boundary policies
| Implementation | Required |
|---|---|
| Description | Enable principal access boundary (PAB) policies to limit principal access and help protect against phishing and data exfiltration. Enable a PAB policy for the organization to avoid external phishing attacks. PABs improve security by reducing the extent of an attack with a compromised identity, and they also help prevent any external phishing attacks and other exfiltration attacks. |
| Applicable products |
IAM |
| Path | iam.googleapis.com/PrincipalAccessBoundaryPolicy |
| Operator | Is set |
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Implement tags to efficiently assign IAM policies and organization policies
| Google control ID | IAM-CO-6.1 |
|---|---|
| Implementation | Recommended |
| Description | Tags provide a way to create annotations for resources, and in some cases conditionally allow or deny policies based on whether a resource has a specific tag. Use tags and conditional policy enforcement for fine-grained control across your resource hierarchy. |
| Applicable products |
Resource Manager |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Audit high-risk changes to IAM
| Google control ID | IAM-CO-7.1 |
|---|---|
| Implementation | Recommended |
| Description | Use Cloud Audit Logs to monitor for high-risk activity, such as accounts being granted high-risk roles like Organization Admin and Super Admin. Set up alerts for this type of activity. |
| Applicable products |
Cloud Audit Logs |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Block access to Cloud Shell for Cloud Identity managed user accounts
| Google control ID | CI-CO-6.8 |
|---|---|
| Implementation | Recommended |
| Description | To avoid granting excessive access to Google Cloud, block access to Cloud Shell for Cloud Identity managed user accounts. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Configure Context-Aware Access for Google consoles
| Google control ID | IAM-CO-8.2 |
|---|---|
| Implementation | Optional |
| Description | With Context-Aware Access, you can create granular access control security policies for applications based on attributes such as user identity, location, device security status, and IP address. We recommend that you use Context-Aware Access to restrict access to the the Google Cloud console (https://console.cloud.google.com/) and the Google Admin console (https://admin.cloud.google.com). |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Block account self-recovery for super admin accounts
| Google control ID | CI-CO-6.3 |
|---|---|
| Implementation | Optional |
| Description | An attacker could use the self-recovery process to reset super admin passwords. To mitigate the security risks associated with Signaling System 7 (SS7) attacks, SIM Swap attacks, or other phishing attacks, we recommend that you turn off this feature. To turn off the feature, go to the account recovery settings in the Google Admin console.
|
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Turn off unused Google services
| Google control ID | CI-CO-6.6 |
|---|---|
| Implementation | Optional |
| Description | In general, we recommend turning off the services that you won't use.
|
| Applicable products |
Cloud Identity |
| Path | http://admin.google.com > Apps > Additional Google Services |
| Operator | Setting |
| Value |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Organization
This section includes the best practices and guidelines for Organization Policy Service and Resource Manager when running workloads on Google Cloud.
Restrict TLS versions supported by Google APIs
| Google control ID | COM-CO-1.1 |
|---|---|
| Implementation | Required |
| Description | Google Cloud supports multiple TLS protocol versions. To meet compliance requirements, you might want to deny handshake requests from clients that use older TLS versions. To configure this control, use the Restrict TLS Versions ( Due to the behavior of organization policy hierarchy evaluation, the TLS version restriction applies to the specified resource node and all of its folders and projects (children). For example, if you deny TLS version 1.0 for an organization, it is also denied for all children that descend from that organization. You can override the inherited TLS version restriction by updating the organization policy on a child resource. For example, if your organization policy denies TLS 1.0 at the organization level, you can remove the restriction for a child folder by setting a separate organization policy on that folder. If the folder has any children, the folder's policy will also be applied on each child resource due to policy inheritance. To further restrict the TLS version to TLS 1.3 only, you can set this policy to also restrict TLS version 1.2. You must implement this control on applications that you host inside of Google Cloud. For example, at the organization level, set:
|
| Applicable products |
All; managed by Organization Policy Service |
| Path | gcp.restrictTLSVersion |
| Operator | == |
| Value |
|
| Type | String |
| Compliance Manager control ID | RESTRICT_LEGACY_TLS_VERSIONS |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict authorized principals
| Google control ID | COM-CO-4.1 |
|---|---|
| Implementation | Required |
| Description | Ensure only identities from your organization are allowed in your Google Cloud environment. Use the Domain restricted sharing ( These constraints help prevent employees from granting access to external accounts outside of your organization's control that don't follow your security policies for multifactor authentication (MFA) or password management. This control is critical for preventing unauthorized access, ensuring that only trusted, managed corporate identities can be used. |
| Applicable products |
|
| Path | constraints/iam.allowedPolicyMemberDomains |
| Operator | Is |
| Value |
|
| Type | List |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict resource service usage
| Google control ID | RM-CO-4.1 |
|---|---|
| Implementation | Required |
| Description | The This constraint lets your organization create an allowlist of approved services, which helps prevent employees from using unvetted services. |
| Applicable products |
|
| Path | constraints/gcp.restrictServiceUsage |
| Operator | Is |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict resource locations
| Google control ID | RM-CO-4.2 |
|---|---|
| Implementation | Required |
| Description | The Resource Location Restriction ( This constraint lets your organization enforce that your resources and data are only created and saved in specific, approved geographic regions. |
| Applicable products |
|
| Path | constraints/gcp.resourceLocations |
| Operator | Is |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Networking
This section includes the best practices and guidelines for Virtual Private Cloud (VPC) and Cloud DNS when running workloads on Google Cloud.
Block default network creation
| Google control ID | VPC-CO-6.1 |
|---|---|
| Implementation | Required |
| Description | The The default network is an auto-mode Virtual Private Cloud (VPC) network with pre-populated IPv4 firewall rules to allow internal communication paths. Generally, this setup isn't a recommended security posture for production environments. |
| Applicable products |
|
| Path | constraints/compute.skipDefaultNetworkCreation |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable DNS Security Extensions
| Google control ID | DNS-CO-6.1 |
|---|---|
| Implementation | Required |
| Description | The Domain Name System Security Extensions (DNSSEC) is a feature of the Domain Name System (DNS) that authenticates responses to domain name lookups. It doesn't provide privacy protections for those lookups, but prevents attackers from manipulating or poisoning the responses to DNS requests. Within Cloud DNS, enable DNSSEC in the following places:
|
| Applicable products |
Cloud DNS |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable Private Google Access
| Google control ID | GCVE-CO-1.5 |
|---|---|
| Implementation | Required |
| Description | Enable Private Google Access on all subnets. Enabling Private Google Access lets services access Google Cloud services that don't have external IP addresses. By default, Private Google Access isn't enabled on new resources and requires additional steps to explicitly enable it. |
| Applicable products |
Virtual Private Cloud (VPC) |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable private service access for service producers
| Google control ID | GCVE-CO-1.6 |
|---|---|
| Implementation | Required |
| Description | Enable private service access to create a private network between Google Cloud services such as Google Cloud VMware Engine legacy networks and service producers such as Cloud SQL. Private service access helps avoid exposing workload network connections to the internet unnecessarily. |
| Applicable products |
Virtual Private Cloud (VPC) |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Disable IPv6 unless required
| Implementation | Required |
|---|---|
| Description | Disable IPv6 external subnet creation unless specifically required. To reduce your attack surface, consider disabling IPv6 on systems and networks where it's not actively managed or required. Many organizations have mature security controls and monitoring for IPv4, but their tools and policies might not fully extend to IPv6, which can create a significant blind spot for threats. Running a dual-stack network also introduces operational complexity, requiring specific configurations and expertise to manage and troubleshoot effectively. Therefore, if you don't have a clear business driver for IPv6, disabling it can simplify your environment and ensure all traffic is consistently filtered through your established IPv4 security posture. |
| Applicable products |
Compute Engine |
| Path | constraints/compute.disableVpcExternalIpv6 |
| Operator | Is |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict outbound traffic
| Implementation | Required |
|---|---|
| Description | Limit access to external sources because by default, all access is allowed out. Set specific firewall rules for intended patterns of traffic needing to egress. By default, systems are often allowed to make outbound connections to the internet, which can be deemed a security risk. A deny-by-default policy blocks outbound traffic and requires specific rules to be created for only the known, necessary destinations. |
| Applicable products |
Cloud Next Generation Firewall |
| Path | cloudasset.assets/assetType |
| Operator | == |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Limit inbound access to SSH and RDP ports
| Implementation | Required |
|---|---|
| Description | Where possible, restrict inbound access to specific resources and resource ranges only. If Identity-Aware Proxy (IAP) is configured, set inbound SSH and Remote Desktop Protocol (RDP) firewall rules to IAP IP ranges as sources. Permissive SSH and RDP firewall rules allow for brute force attacks. Instead, use Google Cloud identity-aware proxies (such as IAP) for SSH and RDP. |
| Applicable products |
IAP |
| Path | cloudasset.assets/assetType |
| Operator | == |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable VPC Service Controls
| Implementation | Required |
|---|---|
| Description | Enable VPC Service Controls as an additional layer of protection to prevent potential data loss. VPC Service Controls can help prevent data exfiltration by creating isolation perimeters around your cloud resources, sensitive data, and networks. The service perimeter limits the usefulness of compromised credentials because the perimeter blocks requests to restricted services that originate from attacker-controlled endpoints that are outside of your environment. |
| Applicable products |
VPC Service Controls |
| Path | accesscontextmanager.accessPolicies.servicePerimeters/perimeterType |
| Operator | == |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use Cloud Armor policies
| Implementation | Required |
|---|---|
| Description | For applications that are exposed behind Cloud Load Balancing, use Google Cloud Armor default policies or configure your own policies to add Layer 3 to Layer 7 network protection for externally-facing applications or services. Cloud Armor security policies help protect your application by providing Layer 7 filtering. These policies also review incoming requests for common web attacks or other Layer 7 attributes to potentially block traffic before the traffic reaches your load-balanced backend services or backend buckets. Each security policy is made up of a set of rules that include attributes from Layer 3 through Layer 7. |
| Applicable products |
Cloud Armor |
| Path | compute.backendServices/securityPolicy |
| Operator | Is set |
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable the service scope restriction in Access Context Manager access policies
| Google control ID | COM-CO-8.1 |
|---|---|
| Implementation | Recommended for generative AI on use cases |
| Description | For every service perimeter, confirm in the Google Cloud console that the perimeter type is set to regular. |
| Applicable products |
|
| Path | accesscontextmanager.accessPolicies.servicePerimeters/perimeterType |
| Operator | == |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict APIs within VPC Service Controls service perimeters
| Google control ID | COM-CO-8.2 |
|---|---|
| Implementation | Recommended for generative AI on use cases |
| Description | For every service perimeter, use Access Context Manager to confirm that the perimeter is protecting the API. |
| Applicable products |
|
| Path | accesscontextmanager.accessPolicies.servicePerimeters/status.restrictedServices |
| Operator | Anyof |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use zonal DNS
| Google control ID | DNS-CO-4.1 |
|---|---|
| Implementation | Optional |
| Description | The |
| Applicable products |
Organization policy |
| Path | constraints/compute.setNewProjectDefaultToZonalDNSOnly |
| Operator | = |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Logging, monitoring, alerting
This section includes the best practices and guidelines for logging and auditing services in Google Cloud and configuring alerts for services such as Cloud Billing.
Share audit logs from Cloud Identity
| Google control ID | CI-CO-6.5 |
|---|---|
| Implementation | Required |
| Description | If using Cloud Identity, share audit logs from Cloud Identity to Google Cloud. Admin Activity audit logs from Google Workspace or Cloud Identity are ordinarily managed and viewed in the Google Admin console, separately from your logs in your Google Cloud environment. These logs contain information that is relevant for your Google Cloud environment, such as user login events. We recommend that you share Cloud Identity audit logs to your Google Cloud environment to centrally manage logs from all sources. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use audit logs
| Google control ID | COM-CO-7.3 |
|---|---|
| Implementation | Required |
| Description | Google Cloud services write audit log entries to answer who did what, where, and when with Google Cloud resources. Enable audit logging at the organization level. You can configure logging using the pipeline that you use to set up the Google Cloud organization. |
| Applicable products |
Cloud Audit Logs |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable VPC Flow Logs
| Google control ID | COM-CO-7.4 |
|---|---|
| Implementation | Required |
| Description | VPC Flow Logs record a sample of network flows that are sent from and received by VM instances, including those used as Google Kubernetes Engine (GKE) nodes. The sample is typically 50% or less of the VPC network flows. When you enable VPC Flow Logs, you enable logging for all VMs in a subnet. However, you can reduce the amount of information written to logging. Enable VPC Flow Logs for each VPC subnet. You can configure logging using a pipeline that you use to create a project. |
| Applicable products |
Virtual Private Cloud |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable Firewall Rules Logging
| Google control ID | COM-CO-7.5 |
|---|---|
| Implementation | Required |
| Description | By default, firewall rules don't automatically write logs.Firewall Rules Logging lets you audit, verify, and analyze the effects of your firewall rules. For example, you can determine if a firewall rule designed to deny traffic is functioning as intended. Logging is also useful if you want to determine how many connections are affected by a given firewall rule. Enable logging for each firewall rule. You can configure logging using a pipeline that you use to create a firewall. |
| Applicable products |
Virtual Private Cloud |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable auditing of administrator activity
| Google control ID | COM-CO-7.1 |
|---|---|
| Implementation | Required |
| Description | By default, Google Cloud enables and doesn't let anyone disable auditing of key administrator activity for privileged accounts. Admin Activity audit logs contain log entries for API calls or other actions that modify the configuration or metadata of resources. For example, these logs record when users create VM instances or change IAM permissions. Admin Activity audit logs contain log entries for creating, modifying, and deleting of organization policy constraints from an organization, folder, and project level. Admin Activity audit logs are always written; you can't configure, exclude, or disable them. Even if you disable the Cloud Logging API, Admin Activity audit logs are still generated. We recommend that your organization set up policies and procedures to monitor these alerts, and generate actions or alerts according to your enterprise access policies for monitoring administrator activities. |
| Applicable products |
Cloud Audit Logs |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Subscribe to security bulletins
| Google control ID | GKE-CO-1.8 |
|---|---|
| Implementation | Required |
| Description | Subscribe to the security bulletin notifications for Google Cloud services to receive alerts about vulnerabilities and mitigation measures. When security bulletins are available that are relevant to your Google Cloud service (such as GKE), the service can publish notifications about those events as messages to Pub/Sub topics that you configure. You can receive these notifications on a Pub/Sub subscription, integrate with third-party services, and filter for the notification types you want to receive. |
| Applicable products |
All |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Configure Essential Contacts groups
| Implementation | Required |
|---|---|
| Description | Configure Essential Contacts to ensure that a monitored group alias or mailing list receive important notifications. Google sends critical security alerts (like a potential account compromise) to the email addresses listed as Essential Contacts. If an individual's email is used for this purpose, the alert is missed if that person is unavailable or has left the company.Using a monitored group email address helps ensure these time-sensitive alerts are delivered to an active team that can respond quickly. |
| Applicable products |
Resource Manager |
| Path | essentialcontacts.googleapis.com/Contact |
| Operator | Is set |
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Monitor billing anomalies
| Implementation | Required |
|---|---|
| Description | Use the billing anomaly feature in Cloud Billing to track any spikes or deviations in expected spend. A sudden, unexpected spike in a cloud bill is a primary indicator of a security compromise. Unexpected billing spikes are sometimes caused by attackers who have gained access and are using resources for unauthorized activities. Enabling billing anomaly detection provides an essential early warning system so that you can automatically flag this suspicious activity. |
| Applicable products |
Cloud Billing |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Export logs to a log sink for long-term storage
| Implementation | Required |
|---|---|
| Description | Create a log sink to export logs for your security monitoring solution and set the retention period to meet your requirements. The default log retention periods are often not long enough to meet the 1-7 year requirements mandated by compliance regulations like PCI or HIPAA. Creating a log sink to export logs to a long-term storage location is essential for meeting certain legal and regulatory obligations. Log sinks also let you send logs to a centralized security monitoring system for advanced threat detection. |
| Applicable products |
Cloud Logging |
| Path | logging.googleapis.com/LogSink/disabled |
| Operator | Is |
| Value |
|
| Type | Boolean |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable Data Access audit logs
| Google control ID | COM-CO-7.2 |
|---|---|
| Implementation | Recommended for certain use cases |
| Description | To track who accessed data in your Google Cloud environment, enable Data Access audit logs. These logs record API calls that read, create, or modify user data, as well as API calls that read resource configurations. We highly recommend enabling Data Access audit logs for generative AI models and sensitive data to ensure you can audit who has read the information. To use Data Access audit logs, you must set up your own custom detection logic for specific activities, like super admin logins. Data Access audit logs volume can be large. Enabling Data Access logs might result in your Google Cloud project being charged for the additional logs usage. |
| Applicable products |
Cloud Audit Logs |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Configure billing alerts
| Google control ID | CB-CO-6.1 |
|---|---|
| Implementation | Recommended |
| Description | Avoid surprises on your bill by creating Cloud Billing budgets to monitor all of your Google Cloud charges in one place. After you've established a budget amount, set budget alert threshold rules on a per-project basis to trigger email notifications. These notifications help you track your spending against your budget. You can also use Cloud Billing budgets to automate cost-control responses. |
| Applicable products |
Cloud Billing |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Enable Access Transparency logs
| Google control ID | COM-CO-7.7 |
|---|---|
| Implementation | Optional |
| Description | Standard logs show you what your organization's own users are doing, but Access Transparency logs show what Google support staff do when they access the account. This access typically only happens in response to a support request. Access Transparency logs provide a complete and verifiable audit trail of all access, which is essential for meeting strict compliance and data governance requirements. You can enable Access Transparency at the organization level. |
| Applicable products |
Access Transparency |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Export billing data for detailed analysis
| Google control ID | CB-CO-6.2 |
|---|---|
| Implementation | Optional |
| Description | For further billing analysis, you can export Google Cloud billing data to BigQuery or a JSON file. For example, you can automatically export detailed data, such as usage, cost estimates, and pricing, throughout the day to a BigQuery dataset that you specify. You can then access your Cloud Billing data from BigQuery for detailed analysis, or use a tool like Data Studio to visualize your data. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Key and secret management
This section includes the best practices and guidelines for Cloud Key Management Service and Secret Manager when running workloads on Google Cloud.
Encrypt data at rest in Google Cloud
| Google control ID | COM-CO-2.1 |
|---|---|
| Implementation | Required (default) |
| Description | All data in Google Cloud is encrypted at rest by default using NIST-approved algorithms. |
| Applicable products |
Google Cloud default |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use NIST-approved algorithms for encryption and decryption
| Google control ID | COM-CO-2.4 |
|---|---|
| Implementation | Required |
| Description | Ensure that Cloud Key Management Service (Cloud KMS) only uses NIST-approved algorithms to store sensitive keys in the environment. This control ensures secure key usage by only NIST-approved algorithms and security. The Remove algorithms that don't comply with your organization's policies. |
| Applicable products |
Cloud KMS |
| Path | cloudkms.projects.locations.keyRings.cryptoKeys/versionTemplate.algorithm |
| Operator | in |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Set the purpose for Cloud KMS keys
| Google control ID | COM-CO-2.5 |
|---|---|
| Implementation | Required |
| Description | Set the purpose for Cloud KMS keys to |
| Applicable products |
Cloud KMS |
| Path | cloudkms.projects.locations.keyRings.cryptoKeys/purpose |
| Operator | == |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Ensure that CMEK settings are appropriate for secure BigQuery data warehouses
| Google control ID | COM-CO-2.6 |
|---|---|
| Implementation | Required |
| Description | The protection level indicates how cryptographic operations are performed. After you create a customer-managed encryption key (CMEK), you can't change the protection level. Supported protection levels are the following:
|
| Applicable products |
|
| Path | cloudkms.projects.locations.keyRings.cryptoKeys/primary.protectionLevel |
| Operator | in |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Rotate encryption key every 90 days
| Google control ID | COM-CO-2.7 |
|---|---|
| Implementation | Required |
| Description | Ensure that the rotation period of your Cloud KMS keys are set to 90 days. A general best practice is to rotate your security keys on a regular interval. This control enforces key rotation for keys that are created with HSM services. When you create this rotation period, also create appropriate policies and procedures to securely handle the creation, deletion, and modification of keying material so that you can help protect your information and ensure availability. Ensure that this period adheres to your corporate policies for key rotation. |
| Applicable products |
Cloud KMS |
| Path | cloudkms.projects.locations.keyRings.cryptoKeys/rotationPeriod |
| Operator | <= |
| Value |
|
| Type | int32 |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Set up automatic secret rotation
| Google control ID | SM-CO-6.2 |
|---|---|
| Implementation | Required |
| Description | Automatically rotate secrets and have emergency rotation procedures available in case of a compromise.
|
| Applicable products |
Secret Manager |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Create a managed encryption strategy
| Implementation | Required |
|---|---|
| Description | Create an encryption management strategy using Cloud Key Management Service (Cloud KMS) with Autokey, Cloud External Key Manager (Cloud EKM), or both. This strategy lets your organization use and manage its own encryption keys to meet your specific requirements. Using your own encryption keys provides granular, auditable control over data access, including the ability to immediately block access to data by disabling the key. |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use CMEK for Pub/Sub messages
| Google control ID | PS-CO-6.1 |
|---|---|
| Implementation | Recommended |
| Description | When you enable customer-managed encryption keys (CMEK) for Pub/Sub, you obtain greater control of the encryption keys that Pub/Sub uses to protect your messages. At the application layer, Pub/Sub individually encrypts incoming messages when Pub/Sub receives them. Before Pub/Sub publishes messages to a subscription, it encrypts the messages using the newest data encryption key (DEK) that was generated for the topic. Pub/Sub decrypts the messages shortly before they're delivered to subscribers.
Pub/Sub uses a Google Cloud service account to access Cloud Key Management Service. The service account is maintained internally by Pub/Sub for each project, and isn't visible in your list of service accounts.
|
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Restrict customer-managed encryption keys location
| Google control ID | COM-CO-2.2 |
|---|---|
| Implementation | Recommended |
| Description | Use the Restrict which projects may supply KMS CryptoKeys for CMEK ( To modify this constraint, administrators need the Organization Policy Administrator ( If you want to add a second layer of protection, such as bring your own key, change this constraint to represent the key names of the CMEK that is enabled. Product specifics:
|
| Applicable products |
|
| Path | constraints/gcp.restrictCmekCryptoKeyProjects |
| Operator | notexists |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Use CMEK for Google Cloud services
| Google control ID | COM-CO-2.3 |
|---|---|
| Implementation | Recommended |
| Description | If you require more control over key operations than what Google-owned and Google-managed encryption keys allow, you can use customer-managed encryption keys (CMEKs). These keys are created and managed using Cloud KMS. Store the keys as software keys, in an HSM cluster, or in an external key management system. Cloud KMS encryption and decryption rates are subject to quotas. Cloud Storage specifics In Cloud Storage, use CMEKs on individual objects, or configure your Cloud Storage buckets to use a CMEK by default on all new objects added to a bucket. When using a CMEK, an object is encrypted with the key by Cloud Storage at the time it's stored in a bucket, and the object is automatically decrypted by Cloud Storage when the object is served to requesters. The following restrictions apply when using CMEKs with Cloud Storage:
|
| Applicable products |
|
| Path | constraints/gcp.restrictNonCmekServices |
| Operator | == |
| Value |
|
| Type | String |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Replicate secrets automatically
| Google control ID | SM-CO-6.1 |
|---|---|
| Implementation | Recommended |
| Description | Choose the automatic replication policy to replicate your secrets unless your workload has specific location requirements. The automatic policy meets the availability and performance needs of most workloads. If your workload has specific location requirements, you can use the API to select the locations for the replication policy when you create the secret.
|
| Applicable products |
Secret Manager |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Security posture and analytics
This document includes the best practices and guidelines for Security Command Center when running workloads on Google Cloud.
Enable Security Command Center at the organization level
| Google control ID | SCC-CO-6.1 |
|---|---|
| Implementation | Required |
| Description | Enable Security Command Center at the organization level to avoid additional configuration. If you don't want to use Security Command Center, you must enable another posture management solution.
|
| Applicable products |
Security Command Center |
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
Configure alerts from Security Command Center
| Google control ID | SCC-CO-7.1 |
|---|---|
| Implementation | Recommended |
| Description | Alerts from the Security Command Center provide visibility into your organization and notify you about issues with your Google Cloud services so you can take appropriate action. You can set up alerts in Cloud Logging to get notifications on errors that are related to the Security Command Center service agent (
service-org-ORGANIZATION_NUMBER@security-center-api.iam.gserviceaccount.com). |
| Applicable products |
|
| Related NIST-800-53 controls |
|
| Related CRI profile controls |
|
| Related information |
What's next
Review infrastructure controls.
See more Google Cloud security best practices and guidelines.