主體是指可以取得資源存取權的身份。主體包括使用者的 Google 帳戶、Google 群組、Google Workspace 帳戶、Cloud Identity 網域和服務帳戶。有些服務還會讓您將存取權授予所有使用 Google 帳戶進行驗證的使用者，或所有網際網路使用者。如要讓實體與 Google Cloud 服務互動，您必須在 Identity and Access Management (IAM) 中授予該實體角色。
如要大規模管理 IAM 角色，建議您根據使用者的職務功能和存取權需求，將使用者指派至群組，然後將 IAM 角色授予這些群組。您應使用現有身分提供者的程序，將使用者新增至群組，以便建立群組和管理成員資格。
如果您在加入 Google Cloud前未使用 Cloud Identity 或 Google Workspace，貴機構的員工可能已使用與公司電子郵件身分相關聯的個人帳戶存取其他 Google 服務，例如 Google Marketing Platform 或 YouTube。個人帳戶是由帳戶建立者個人全權擁有及管理的帳戶。由於這些帳戶不在貴機構的控管之下，且可能包含個人和公司資料，因此您必須決定如何將這些帳戶與其他公司帳戶合併。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：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)."]]
