主账号是一种可被授予资源访问权限的身份。主账号包括用户的 Google 账号、Google 群组、Google Workspace 账号、Cloud Identity 网域和服务账号。某些服务还允许您向使用 Google 账号进行身份验证的所有用户或互联网上的所有用户授予访问权限。为了让主账号能够与 Google Cloud 服务进行交互，您必须在 Identity and Access Management (IAM) 中为其授予角色。
要大规模管理 IAM 角色，我们建议您根据用户的工作职能和访问权限要求将用户分配给相应群组，然后为这些群组授予 IAM 角色。您应按照现有身份提供方中的流程将用户添加到群组，以创建群组和授予成员资格。
如果您在开始使用 Google Cloud之前未使用过 Cloud Identity 或 Google Workspace，则贵组织的员工可能已经在使用与其公司电子邮件身份关联的消费者账号来访问 Google Marketing Platform 或 YouTube 等其他 Google 服务。消费者账号完全由创建账号的个人拥有和管理。由于这些账号不受组织控制，并且可能同时包含个人和公司数据，因此您必须决定如何将这些账号与其他公司账号整合起来。
我们建议您在加入 Google Cloud时整合现有消费者用户账号。如果您尚未将 Google Workspace 用于所有用户账号，我们建议禁止访问个人账号。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-05-15。"],[],[],null,["# Authentication and authorization\n\nThis section introduces how to use\n[Cloud Identity](/identity/docs/overview)\nto manage the [identities that your employees use](/architecture/identity/overview-google-authentication#google_identities) to access Google Cloud\nservices.\n\nExternal identity provider as the source of truth\n-------------------------------------------------\n\nWe recommend federating your Cloud Identity account with your existing\nidentity provider. Federation helps you ensure that your existing account\nmanagement processes apply to Google Cloud and other Google services.\n\nIf you don't have an existing identity provider, you can create user accounts\ndirectly in Cloud Identity.\n| **Note:** If you're already using Google Workspace, Cloud Identity uses the same console, administrative controls, and user accounts as your Google Workspace account.\n\nThe following diagram shows a high-level view of identity federation and single\nsign-on (SSO). It uses Microsoft Active Directory, located in the on-premises\nenvironment, as the example identity provider.\n\nThis diagram describes the following best practices:\n\n- User identities are managed in an Active Directory domain that is located in the on-premises environment and federated to Cloud Identity. Active Directory uses Google Cloud Directory Sync to provision identities to Cloud Identity.\n- Users attempting to sign in to Google services are redirected to the external identity provider for [single sign-on with SAML](/architecture/identity/single-sign-on), using their existing credentials to authenticate. No passwords are synchronized with Cloud Identity.\n\nThe following table provides links to setup guidance for identity providers.\n\nWe strongly recommend that you enforce multi-factor authentication at your\nidentity provider with a phishing-resistant mechanism such as a\n[Titan Security Key](/titan-security-key).\n\nThe recommended settings for Cloud Identity aren't automated through\nthe Terraform code in this blueprint. See\n[administrative controls for Cloud Identity](#administrative-controls-for-cloud-identity)\nfor the recommended security settings that you must configure in addition to\ndeploying the Terraform code.\n\nGroups for access control\n-------------------------\n\nA *principal* is an identity that can be granted access to a resource.\nPrincipals include [Google Accounts for\nusers](/docs/authentication#user-accounts), Google groups,\nGoogle Workspace accounts, Cloud Identity domains, and service\naccounts. Some services also let you grant access to all users who authenticate\nwith a Google Account, or to all users on the internet. For a principal to\ninteract with Google Cloud services, you must grant them roles in\n[Identity and Access Management (IAM)](/iam/docs/overview).\n\nTo manage IAM roles at scale, we recommend that you assign users\nto groups based on their job functions and access requirements, then grant\nIAM roles to those groups. You should add users to groups using\nthe processes in your existing identity provider for group creation and\nmembership.\n\nWe don't recommend granting IAM roles to individual users because individual\nassignments can increase the complexity of managing and auditing roles.\n\nThe blueprint configures groups and roles for view-only access to foundation\nresources. We recommend that you deploy all resources in the blueprint through\nthe foundation pipeline, and that you don't grant roles to users to groups to\nmodify foundation resources outside of the pipeline.\n\nThe following table shows the groups that are configured by the blueprint for\nviewing foundation resources.\n\nAs you build your own workloads on top of the foundation, you create additional\ngroups and grant IAM roles that are based on the access\nrequirements for each workload.\n\nWe strongly recommend that you avoid\n[basic roles](/iam/docs/understanding-roles#basic)\n(such as Owner, Editor, or Viewer) and use\n[predefined roles](/iam/docs/understanding-roles#predefined_roles)\ninstead. Basic roles are overly permissive and a potential security risk. Owner\nand Editor roles can lead to privilege escalation and lateral movement, and the\nViewer role includes access to read all data. For best practices on IAM\nroles, see\n[Use IAM securely](/iam/docs/using-iam-securely).\n\nSuper admin accounts\n--------------------\n\nCloud Identity users with the\n[super admin account](/resource-manager/docs/super-admin-best-practices)\nbypass the organization's SSO settings and authenticate directly to\nCloud Identity. This exception is by design, so that the super admin can\nstill access the Cloud Identity console in the event of an SSO\nmisconfiguration or outage. However, it means you must consider additional\nprotection for super admin accounts.\n\nTo protect your super admin accounts, we recommend that you always enforce\n2-step verification with security keys in Cloud Identity. For more\ninformation, see\n[Security best practices for administrator accounts](https://support.google.com/a/answer/9011373).\n\nIssues with consumer user accounts\n----------------------------------\n\nIf you didn't use Cloud Identity or Google Workspace before you\nonboarded to Google Cloud, it's possible that your organization's\nemployees are already using\n[consumer accounts](/architecture/identity/overview-google-authentication#consumer_account)\nthat are associated with their corporate email identities to access other Google\nservices such as Google Marketing Platform or YouTube. Consumer accounts are accounts that\nare fully owned and managed by the individuals who created them. Because those\naccounts aren't under your organization's control and might include both\npersonal and corporate data, you must decide how to consolidate these accounts\nwith other corporate accounts.\n\nWe recommend that you [consolidate existing consumer user\naccounts](/architecture/landing-zones/decide-how-to-onboard-identities#account-consolidation)\nas part of onboarding to Google Cloud. If you aren't using\nGoogle Workspace for all your user accounts already, we recommend\n[blocking access to consumer\naccounts](https://support.google.com/a/answer/1668854).\n\nAdministrative controls for Cloud Identity\n------------------------------------------\n\nCloud Identity has various administrative controls that are not\nautomated by Terraform code in the blueprint. We recommend that you enforce each\nof these best practice security controls early in the process of building your\nfoundation.\n\nWhat's next\n-----------\n\n- Read about [organization\n structure](/architecture/blueprints/security-foundations/organization-structure) (next document in this series)."]]
