This document presents best practices for deciding how manyCloud Identity orGoogle Workspace accounts, Google Cloud organizations, and billing accounts you need to use. Thedocument provides guidance on identifying a design that satisfies your securityand organizational requirements.

In Google Cloud, identity and access management is based on twopillars:

• Cloud Identity and Google Workspace accounts arecontainers for users and groups. These accounts are therefore key toauthenticating your corporate users and managing access to yourGoogle Cloud resources. A Cloud Identity orGoogle Workspace account denotes a directory of users, not anindividual user account. Individual user accounts are referred to asusers oruser accounts.

• Organizations are containers for projects and resources within Google Cloud.Organizations allow resources to be structured hierarchically andare key to centrally and efficiently managing resources.

This document is intended primarily for customers who are setting up enterpriseenvironments.

Cloud Identity and Google Workspace accounts

Google Workspace is an integrated suite of cloud-native collaboration andproductivity apps. It includes tools that let you manage users, groups, andauthentication.

Cloud Identity provides a subset of the Google Workspacefeatures. Like Google Workspace, Cloud Identity lets you manageusers, groups, and authentication, but it doesn't include all ofGoogle Workspace's collaboration and productivity features.

Cloud Identity and Google Workspace share a common technicalplatform and use the same set of APIs and administrative tools. The productsshare the concept of an account as a container for users and groups. Thiscontainer is identified by a domain name such asexample.com. For managingusers, groups, and authentication, the two products can be consideredequivalent.

Combine Cloud Identity and Google Workspace in a single account

Because Cloud Identity and Google Workspace share a commonplatform, you can combine access to the products in a single account.

If you already administer a Google Workspace account and want to enablemore users to use Google Cloud, you might not want to assign all users aGoogle Workspace license. In this case,add Cloud Identity Free to your existing account.You can then onboard more users without additional charge and decide which usersshould have access to Google Workspace byassigning them a Google Workspace license.

Similarly, if you already administer a Cloud Identity Free or Premiumaccount, you might want to grant certain users the right to useGoogle Workspace. Rather than creating separate Google Workspaceaccounts for those users, you canadd Google Workspace to an existing Cloud Identity account.After you've assigned the Google Workspace license to those selectedusers, they can use the productivity and collaboration apps.

Use as few accounts as possible, but as many as necessary

To let your users collaborate by using Google Workspace, and to minimizeadministrative overhead, it's best to manage all users through a singleCloud Identity or Google Workspace account and provide a singleuser account to each individual. This approach helps ensure that settings suchaspassword policies,single sign-on, andtwo-step verification are consistently applied to all users.

Despite these benefits of using a single Cloud Identity orGoogle Workspace account, you can gain flexibility and administrativeautonomy by using multiple accounts. When you are deciding how manyCloud Identity or Google Workspace accounts to use, consider allrequirements that suggest using multiple accounts. Then use the smallest numberof Cloud Identity or Google Workspace accounts that satisfies yourrequirements.

Use separate accounts for staging and production

For most settings that you can configure in Cloud Identity andGoogle Workspace, you can choose the scope at which each setting shouldapply—for example, you can specify thegeographic location for your data by user, by group, or by organizational unit. When you plan to apply a newconfiguration, you can initially choose a small scope (for example, by user) andverify whether the configuration meets your expectations. When you've verifiedthe configuration, you can then apply the same setting to a larger set of groupsor organizational units.

Unlike most settings, integrating a Cloud Identity orGoogle Workspace account with an external identity provider (IdP) has aglobal impact:

• Enabling single sign-on is a global setting that applies to all users other than super admins.
• Depending on your external IdP, setting up user provisioning can alsohave global impact. An accidental misconfiguration in the external IdPmight lead to users inadvertently being modified, suspended, or even deleted.

To mitigate these risks, have separate staging and productionCloud Identity or Google Workspace accounts:

• Use the staging account to verify any risky configuration changesbefore applying the same change to your production account.
• Create a few test users in the staging accounts that you and otheradministrators can use to verify configuration changes. But don't grantyour users access to the staging account.

If you have separate staging and production instances of your external IdP,take these steps:

• Integrate your staging Cloud Identity or Google Workspaceaccount with your staging IdP instance.
• Integrate your production Cloud Identity orGoogle Workspace account with your production IdP instance.

For example, suppose you plan toset up federation with Active Directory and have a separate Active Directory forest for testing purposes. In this case,you integrate your staging Cloud Identity or Google Workspaceaccount with the staging forest and the production Cloud Identity orGoogle Workspace account with your main forest. Apply the same mappingapproach forDNS domains,users,andgroups to both forest/account pairs, as shown in the following diagram:

Your production and staging Active Directory forests and domains might use DNSdomains that don't let you apply the same domain mapping approach for stagingand production. In this case, consider registering more User Principal Name(UPN) suffix domains in your staging forest.

Similarly, if you plan toset up federation with Microsoft Entra ID,it's best to take the following approach:

• Integrate the staging Cloud Identity or Google Workspaceaccount with a staging Entra ID tenant.
• Integrate the production Cloud Identity orGoogle Workspace account with your main Entra ID tenant.

Apply the same mapping approach forDNS domains,users,andgroups to both tenant/account pairs:

Your production and staging Entra ID tenants might use DNSdomains that don't let you apply the same domain mapping approach for stagingand production. In this case, consider adding an extra domain to your stagingtenant.

Use disjoint DNS domains among Cloud Identity and Google Workspace accounts

When you first add a domain such asexample.com to yourCloud Identity or Google Workspace account, you need toverify that you own the domain.After you have added and verified a domain, you can add subdomains such asmarketing.example.com andfinance.example.com without having to verify eachsubdomain individually.

However, if you add subdomains without verifying each one, conflicts can resultif you have another Cloud Identity or Google Workspace accountthat already uses this subdomain. To avoid these conflicts, prefer usingdisjoint domains for each account. For example, if you need twoCloud Identity or Google Workspace accounts, try to avoid usingtwo domains where one domain is a subdomain of the other. Instead, use twodomains that are not subdomains of another. This practice applies to the primarydomain and tosecondary domains.

Don't separate Google Workspace and Google Cloud

If you already use Google Workspace, some users in yourGoogle Workspace account might have been grantedsuper admin privileges so that they can carry out administrative tasks.

Users with super admin privileges are implicitly granted permission to modifythe Identity and Access Management (IAM) policy of the organization node. This permissionenables super admins to assign themselves theorganization administrators role or any other role in the Google Cloud organization. Having super adminaccess to a Cloud Identity or Google Workspace account alsoenables a user to delete the account, its associated Google Cloudorganization, and all its resources. You therefore have to assume that superadmins have full access to all resources within an organization.

The fact that super admins are also organization administrators might be asecurity concern if your existing Google Workspace administrators are adifferent set of users from the users who will be in charge of managing yourGoogle Cloud organization. In this case, you might decide to create aseparate Cloud Identity account that is dedicated to Google Cloudin order to limit the access of Google Workspace super admins toGoogle Cloud resources. Separating Google Workspace andGoogle Cloud can have several unintended consequences.

For example, you might try creating separate users in the Cloud Identityaccount and thenrestricting access to the Google Cloud organization users to the Cloud Identity account.This would ensure that your Google Cloud deployment andGoogle Workspace are fully isolated. However, duplicating users negativelyaffects both user experience and administrative overhead. Additionally, youwouldn't be able to receive any notification emails sent by Google Cloudbecause the domain used by Cloud Identity must be different from thedomain used for Google Workspace and is therefore unsuitable for routingemail.

If you instead reference users from the Google Workspace account in yourGoogle Cloud organization, you undermine the isolation betweenGoogle Workspace and Google Cloud:

Google Workspace super admins have the ability to usedomain-wide delegation to impersonate any user in the same Google Workspace account. A roguesuper admin could use their elevated privileges to regain access toGoogle Cloud.

A more effective approach than using separate accounts is to segregateresponsibilities between Google Workspace and Google Cloudadministrators to reduce the number of super admins:

• Most administrative duties in Google Workspace don't requiresuper admin privileges. Usepre-built administrative roles orcustom administrator roles in place of super admin privileges to grant Google Workspaceadministrators the permissions necessary to conduct their duties.

• Retain only a minimal number of super-admin users anddiscourage everyday usage.

• Takeadvantage of auditing to detect suspicious activity among administrative users.

Secure your external IdP when using single sign-on

Cloud Identity and Google Workspace let youset up single sign-on with your external IdP such as Active Directory, Entra ID, or Okta(to name a few). If single sign-on is enabled, Cloud Identity andGoogle Workspace trust the external IdP to authenticate users on Google'sbehalf.

Enabling single sign-on offers several advantages:

• Users can use their existing credentials to sign on to Google services.
• Users don't need to enter their passwords again if they already have anexisting sign-on session.
• You can apply consistent multi-factor authentication policies acrossyour applications and all Google services.

But enabling single sign-on also exposes you to risks. When single sign-on isenabled and a user needs to be authenticated, Cloud Identity orGoogle Workspace redirects the user to your external IdP. Afterauthenticating the user, the IdP returns to Google a SAML assertion that statesthe user's identity. The SAML assertion is signed. Therefore, Google can verifythe authenticity of the SAML assertion and verify that the correct identityprovider has been used. However, there is no way for Cloud Identity orGoogle Workspace to verify that the IdP made the right authenticationdecision and correctly stated the user's identity.

If single sign-on is enabled, the overall security and integrity of your Googledeployment hinges on the security and integrity of your IdP. YourCloud Identity or Google Workspace account and all resources thatrely on the users managed by the account are at risk if any of the following areconfigured insecurely:

• The IdP itself
• The machines that the provider is running on
• The user database that the provider is getting user information from
• Any other system that the provider depends on

To prevent single sign-on from becoming a weak link in your security posture,ensure that your IdP and all systems it depends on are configured securely:

• Limit the number of users with administrative access to your IdP or toany of the systems that the provider relies on.
• Don't grant any user administrative access to these systems to whom youwouldn't also give super admin privileges in Cloud Identity orGoogle Workspace.
• Don't use single sign-on if you are unsure about the security controlsin place for your external IdP.

Secure access to your DNS zones

Cloud Identity and Google Workspace accounts are identified by aprimary DNS domain name. When you create a new Cloud Identity orGoogle Workspace account, you mustverify ownership of the DNS domain by creating a special DNS record in the corresponding DNSzone.

The importance of DNS and the impact on the overall security of your Googledeployment extends beyond the sign-up process:

• Google Workspace relies onDNS MX records for routing emails. By modifying these MX records, an attacker might beable to route emails to a different server and gain access to sensitiveinformation.

• If an attacker is able to add records to the DNS zone, they might thenbe able to reset the password of a super admin user and gain access to theaccount.

To prevent DNS from becoming a weak link in your security posture, ensure thatyour DNS server is configured securely:

• Limit the number of users that have administrative access to the DNSserver that manages the primary domain used for Cloud Identity orGoogle Workspace.

• Don't grant any user administrative access to your DNS server to whomyou wouldn't also give super admin privileges in Cloud Identity orGoogle Workspace.

• If you plan to deploy a workload on Google Cloud that has securityrequirements that aren't met by your existing DNS infrastructure, considerregistering for that workload a new DNS domain that uses separate DNSservers or a managed DNS service.

Export audit logs to BigQuery

Cloud Identity and Google Workspace maintain multiple audit logsto keep track of configuration changes and other activities that might berelevant to the security of your Cloud Identity orGoogle Workspace account. The following table summarizes these auditlogs.

You can access these audit logs either through theAdmin Console or through theReports API.For most audit logs, data isretained for 6 months.

If you are operating in a regulated industry, retaining audit data for 6 monthsmight not be sufficient. To retain data for a longer period of time,configure audit logs to be exported to BigQuery.

To limit the risk of unauthorized access to the exported audit logs, use adedicated Google Cloud project for the BigQuery dataset. To keep theaudit data safe from tampering or deletion, grant access to the project anddataset on a least-privilege basis.

The Cloud Identity and Google Workspace audit logs arecomplementary toCloud Audit Logs logs.If you also use BigQuery to collect Cloud Audit Logs logs andother application-specific audit logs, you can correlate login events toactivities that a user has performed in Google Cloud or in yourapplications. Being able to correlate audit data across multiple sources canhelp you detect and analyze suspicious activity.

Setting up BigQuery exporting requires a Google Workspace Enterprise license. After you set up the mainaudit logs, these are exported for all users, including those users without aGoogle Workspace license. Certain logs such as the Drive and Mobileaudit logs are exported for users that have at least a Google WorkspaceBusiness license.

If you use Cloud Identity Free for the majority of your users, you canstill export to BigQuery byadding Google Workspace Enterprise to your existing Cloud Identity account and purchasing Google Workspace licenses for a selected set ofadministrators.

Organizations

Organizations let you organize resourcesinto a hierarchy of projects and folders,with the organization node being the root. Organizations are associated with aCloud Identity or Google Workspace account, and they derive theirname from the primary domain name of the associated account. An organization iscreated automatically when a user from the Cloud Identity orGoogle Workspace account creates a first project.

Each Cloud Identity or Google Workspace account can have only asingle organization. In fact, it's not possible to create an organizationwithout a corresponding account. Despite this dependency, you cangrant users from multiple different accounts access to resources in a single organization:

The flexibility to reference users from different Cloud Identity orGoogle Workspace accounts lets you separate how you treat accountsand organizations. You can separate the decision of how manyCloud Identity or Google Workspace accounts you need in order tomanage your users from the decision of how many organizations you need in orderto manage your resources.

The number of organizations that you create and their purposes can profoundlyimpact your security posture, the autonomy of your teams and departments, andthe consistency and efficiency of your administration.

The following sections describe best practices for deciding how manyorganizations to use.

Use as few organizations as possible, but as many as necessary

The resource hierarchy of an organization lets you reduce the effort ofmanaging IAM policies and organizational policies by takingadvantage of inheritance. By configuring policies at the folder or organizationlevel, you ensure that policies are applied consistently across a sub-hierarchyof resources, and you avoid repetitive configuration work. To minimize youradministrative overhead, it'sbest to use as few organizations as possible.

In contrast, you can gain additional flexibility and administrative autonomy byusing multiple organizations. The following sections describe when you mightrequire such additional flexibility or autonomy.

In any case, when you are deciding how many organizations to use, consider allrequirements that suggest using multiple organizations. Then use the smallestnumber of organizations that satisfies your requirements.

Use organizations to delineate administrative authority

Within a resource hierarchy, you can grant permissions at the resource,project, or folder level. The ultimate level at which you can grant a userpermissions is the organization.

A user who has been assigned the Organization Administrator role at theorganization level has full control over the organization, its resources, andits IAM policies. An Organization Administrator can take controlof any resource within the organization and is free to delegate administrativeaccess to any other user.

However, the capabilities of an Organization Administrator are confined to theorganization, making the organization the ultimate scope of administrativeauthority:

• An Organization Administrator cannot access any resources in otherorganizations unless explicitly granted permission.
• No user outside the organization can take control away from anOrganization Administrator of that organization.

The right number of organizations to use depends on the number of independentgroups of administrative users in your company:

• If your company is organized by function, you might have a singledepartment that's in charge of overseeing all Google Cloud deployments.
• If your company is organized by division or owns a number ofautonomously-run subsidiaries, then there might not be a single departmentthat's in charge.

If a single department is in charge of overseeing Google Clouddeployments, it's best to use a single Google Cloud organization node.Within the organization, use folders to structure resources and grant differentlevels of access to other teams and departments.

If you are dealing with multiple independent departments, trying to centralizeadministration by using a single organization might cause friction:

• If you designate a single department to manage the organization, youmight face resistance from other departments.
• If you let multiple teams or departments co-own a single organization,it might be difficult to maintain a consistent resource hierarchy and toensure that IAM policies and organizational policies areused consistently across your resources.

To prevent this kind of friction, use multiple organizations and createseparate folder structures in each organization. By using separateorganizations, you establish boundaries between different groups ofadministrative users, thus delineating their administrative authority.

Use a separate staging organization

To help ensure consistency and avoid repetitive configuration work, organizeyour projects into a hierarchy of folders and apply IAM policiesand organizational policies at the folder or organization level.

There is a downside of having policies that apply to many projects andresources. Any change to the policy itself or the resource hierarchy the policyapplies to might have far-reaching and unintended consequences. To mitigate thisrisk, it's best to test policy changes before you apply them in your mainorganization.

We recommend that you create a separate staging organization. This organizationhelps you test resource hierarchy changes, IAM policies,organizational policies, or other configuration that have potentialorganization-wide impact such asaccess levels andpolicies.

To ensure that the results of tests or experiments conducted in the stagingorganization also apply to the production organization, configure the stagingorganization to use the same folder structure as your main organization, butwith only a small number of projects. At any point, the IAM andorganizational policies in the staging organization should either match thepolicies of your production organization or should reflect the next version ofpolicies that you intend to apply to your production organization.

As the following diagram shows, you use yourstaging Cloud Identity or Google Workspace account as a basis for the staging organization. You use the staging account (or theexternal IdP that your staging account is integrated with) to create dedicatedtest users and a group structure that mirrors the groups you use in yourproduction Cloud Identity or Google Workspace account. You canthen use these dedicated test users and groups to test IAMpolicies without impacting existing users.

Avoid using a separate testing organization

For each production workload that you plan to deploy on Google Cloud, youprobably need one or more testing environments, which your development andDevOps teams can use to validate new releases.

From a security perspective, to prevent untested releases from accidentallyimpacting production workloads, you want to cleanly separate your testenvironments from your production environments. Similarly, the two types ofenvironments have different requirements for IAM policies. Forexample, in order for you to grant developers and testers the flexibility theyneed, the security requirements for your testing environments might besubstantially looser than those of your production environments.

As the following diagram shows, from a configuration perspective you want tokeep your test environments as similar to your production environments aspossible. Any divergence increases the risk that a deployment that workedproperly in a test environment fails when deployed to a productionenvironment.

To strike a balance between keeping environments isolated and consistent, usefolders within the same organization to manage testing and productionenvironments:

• Apply any IAM policies or organizational policies that arecommon across environments at the organizational level (or by using a commonparent folder).
• Use the individual folders to manage IAM policies andorganization policies that differ between different types of environments.

Don't use yourstaging organization for managing testing environments. Testing environments are critical to theproductivity of development and DevOps teams. Managing such environments in yourstaging environment would restrict your ability to use the staging organizationto experiment with and test policy changes; any such change might disrupt thework of these teams. In short, if you use a staging organization to managetesting environments, you undermine the purpose of your staging organization.

Use a separate organization for experimenting

To get the most out of Google Cloud, let your development, DevOps, andoperations teams familiarize themselves with the platform and expand theirexperience by runningtutorials.Encourage them to experiment withnew features and services.

Use a separate organization as the sandbox environment to support these typesof experimental activities. By using a separate organization, you can keepexperiments unencumbered by any policies, configuration, or automation that youuse in your production organization.

Avoid using yourstaging organization for experimenting. Your staging environment should use IAM andorganization policies that are similar to your production organization.Therefore, the staging environment is likely to be subject to the samelimitations as your production environment. At the same time, relaxing policiesin order to allow experiments would undermine the purpose of your stagingorganization.

To prevent your experimental organization from becoming disorganized, fromgenerating excessive cost, or from becoming a security risk, issue guidelinesthat define how teams are allowed to use the organization, and who bearsresponsibility for maintaining the organization. Additionally, consider settingup automation to automatically delete resources, or even entire projects, aftera certain number of days.

As the following diagram shows, when you create an organization forexperimenting, you first create a dedicated Cloud Identity account. Youthen use the existing users from your main Cloud Identity orGoogle Workspace account to grant users access to the experimentalorganization.

To manage the additional Cloud Identity account, you need at least onesuper admin user account in the Cloud Identity account. For informationabout how to secure these super-admin user accounts, seeSuper administrator account best practices.

Use domain-restricted sharing to enforce trust relationships

IAM policies let you add any valid Google identity as a member.This means that when you edit the IAM policy of a resource,project, folder, or organization, you can add members from different sources,including the following:

• Users from the Cloud Identity or Google Workspace accountthat the organization is associated with, as well as service accounts fromthe same organization
• Users from other Cloud Identity or Google Workspace accounts
• Service accounts from other organizations
• Consumer user accounts, includinggmail.com users and consumeraccounts that use a corporate email address

Being able to reference users from different sources is useful for scenariosand projects where you need to collaborate with affiliates or other companies.In most other cases, it's best to constrain IAM policies to onlyallow members from trusted sources.

Usedomain-restricted sharing to define a set of trusted Cloud Identity or Google Workspaceaccounts from which you want to allow members to be added to IAMpolicies. Define this organizational policy either at the organization level(so that it applies to all projects) or at a folder near the top of the resourcehierarchy (to allow certain projects to be exempted).

If you use separate Cloud Identity or Google Workspace accountsand organizations to segregate staging, production, and experimentingenvironments, use domain-restricted sharing policies to enforce the segregationas listed in the following table:

Use neutral domain names for organizations

Organizations are identified by a DNS domain name such asexample.com. Thedomain name is derived from the primary domain name of the associatedCloud Identity or Google Workspace account.

If there is a canonical DNS domain name that is used throughout your company,use that domain as primary domain in your production Cloud Identity orGoogle Workspace account. By using the canonical DNS name, you ensure thatemployees can easily recognize the name of the organization node.

If your company has several subsidiaries or owns a variety of different brands,there might not be a canonical domain name. Rather than arbitrarily picking oneof the existing domains, consider registering a new DNS domain that is neutraland dedicated for use by Google Cloud. By using a neutral DNS name, youavoid expressing a preference for a specific brand, subsidiary, or departmentwithin your company, which could negatively affect cloud adoption. Add yourother, brand-specific domains assecondary domains so that they can be used in user IDs and for single sign-on.

Use billing accounts across Google Cloud organizations

Billing accounts definewho pays for a given set of Google Cloud resources.Although billing accounts can exist outside of a Google Cloudorganization, they are most commonly associated with an organization.

When billing accounts are associated with an organization, they are considereda sub-resource of the organization and are subject to IAMpolicies defined within the organization. Most importantly, this means that youcan use theBilling IAM roles to define which users or groups are allowed to administer or use an account.

A user who has been granted theBilling Account User role can link a projectto a billing account, causing the resources to be billed to this account.Linking a project to a billing account works within the same organization, butalso across organizations.

If you use multiple organizations, you can take advantage of the fact thatbilling accounts can be used across organizations. This lets you decide how manybilling accounts you need independent of how many organizations you need.

The right number of billing accounts depends exclusively on yourcommercial or contractual requirements such as currency, payment profile, and the number of separate invoices you need.As you did with accounts and organizations, in order to minimize complexity, youwant to use the smallest number of billing accounts that satisfies yourrequirements.

To break down costs accrued across multiple organizations, configure yourbilling account toexport billing data to BigQuery.Each record exported to BigQuery not only contains the projectname and ID, but also the ID of the organization the project is associated with(in theproject.ancestry_numbers field).

What's next

• Create a new Cloud Identity account
• Learn how Google Cloud lets youauthenticate corporate users in a hybrid environment andcommon patterns.
• Review thebest practices for federating Google Cloud with an external identity provider.
• Find out how tofederate Google Cloud with Active Directory orMicrosoft Entra ID.