Secure enterprise foundation controls

Use the automaticIamGrantsForDefaultServiceAccounts boolean constraint to disable automatic role grants when Google Cloud services automatically create default service accounts with overly permissive roles.

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 (roles/editor) on your project. If an attacker compromises a single part of the system, they could gain control over the entire project. This constraint disables those automatic, high-level permissions, forcing a more secure, deliberate approach where only the minimal necessary permissions are granted.

Use the iam.disableServiceAccountKeyCreation boolean constraint to disable external service account keys from being created. This constraint lets you control the use of unmanaged long-term credentials for service accounts. When this constraint is set, you can't create user-managed credentials for service accounts in projects that are affected by the constraint.

Use the iam.disableServiceAccountKeyUpload boolean constraint to disable the upload of external public keys to service accounts. When this constraint is set, users can't upload public keys to service accounts in projects affected by the constraint.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

To help prevent phishing attacks that can lead to cryptocurrency mining attacks, use Titan Security Keys.

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.

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.

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.

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.

Set the idle session timeout to 15 minutes for sensitive use cases. Idle sessions might be used by attackers for credential theft.

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.

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.

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.

Ensure that your offboarding procedures include processes to deactivate accounts and reset permissions when employees leave your organization or change roles.

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.

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.

To avoid granting excessive access to Google Cloud, block access to Cloud Shell for Cloud Identity managed user accounts.

Use Policy Intelligence tools such as IAM recommender and Policy Analyzer to analyze and refine your Identity and Access Management (IAM) permissions.

Use IAM recommender to remove roles that aren't needed or replace overly permissive roles with more granular, less-privileged roles. Use Policy Analyzer to understand who has what access to which Google Cloud resources based on your Identity and Access Management (IAM) allow policies.

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).

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 (gcp.restrictTLSVersion) organization policy constraint. You can apply this constraint to organizations, folders, or projects in the resource hierarchy. The Restrict TLS Versions constraint uses a deny list, which denies explicit values and allows all others. An error occurs if you try to use an allow list.

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:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Ensure only identities from your organization are allowed in your Google Cloud environment. Use the Domain restricted sharing (iam.allowedPolicyMemberDomains) or the iam.managed.allowedPolicyMembers organization policy constraint to define one or more Cloud Identity or Google Workspace customer IDs whose principals can be added to Identity and Access Management (IAM) policies.

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.

The gcp.restrictServiceUsage constraint ensures that only your approved Google Cloud services are used in the right places. For example, a production or highly sensitive folder has a small list of Google Cloud services that are approved to store data. A sandbox folder might have a larger list of services and accompanying data security controls to help prevent data exfiltration. The value is specific to your systems and matches your approved list of services and dependencies for specific folders and projects.

This constraint lets your organization create an allowlist of approved services, which helps prevent employees from using unvetted services.

The Resource Location Restriction (gcp.resourceLocations) constraint ensures that only your approved Google Cloud regions are used to store data. The value is specific to your systems and matches your organization's approved list of regions for data residency.

This constraint lets your organization enforce that your resources and data are only created and saved in specific, approved geographic regions.

Use Infrastructure as Code (such as Terraform) with the enterprise foundations blueprint as a secure baseline to help ensure known good states and enable rapid, consistent deployments.

The compute.skipDefaultNetworkCreation boolean constraint skips the creation of the default network and related resources when creating Google Cloud projects.

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.

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:

• DNS zone
• Top-level domain (TLD)
• DNS resolution

Enable Private Google Access on all subnets.

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.

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.

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.

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.

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.