本文档介绍了确定需要使用的 Cloud Identity 或 Google Workspace 账号数量、Google Cloud 组织数量和结算账号数量的最佳做法。本文档提供了有关指南来帮助您确定满足您的安全要求和组织要求的设计。
在 Google Cloud 中，身份和访问权限管理基于两个核心：
Cloud Identity 和 Google Workspace 账号是用户和群组的容器。因此，这些账号是对公司用户进行身份验证以及管理对 Google Cloud 资源的访问权限的关键。Cloud Identity 或 Google Workspace 账号表示用户目录，而非单个用户账号。单个用户账号称为用户或用户账号。
组织是 Google Cloud 中项目和资源的容器。组织允许资源按层次结构进行组织，组织对于集中高效地管理资源至关重要。
本文档主要面向设置企业环境的客户。
Cloud Identity 和 Google Workspace 账号
Google Workspace 是一套集成式云原生协作和办公应用。其中包含可以用于管理用户、群组和身份验证的工具。
Cloud Identity 具有 Google Workspace 的部分功能。与 Google Workspace 一样，Cloud Identity 可让您管理用户、群组和身份验证，但它并不包含 Google Workspace 的所有协作和办公功能。
Cloud Identity 和 Google Workspace 共用一个技术平台，并使用相同的一组 API 和管理工具。这两种产品都采用账号作为用户和群组的容器这一概念。此容器由域名（如 example.com）标识。在管理用户、群组和身份验证方面，这两种产品作用相同。
在一个账号中合并 Cloud Identity 和 Google Workspace
由于 Cloud Identity 和 Google Workspace 共用一个平台，因此您可以将对这两种产品的访问权限合并在一个账号中。
如果您已管理一个 Google Workspace 账号并希望允许更多用户使用 Google Cloud，建议您不要为所有用户分配 Google Workspace 许可。在这种情况下，请将 Cloud Identity 免费版添加到您的现有账号。然后，您可以添加更多用户，无需支付额外费用，并可以通过为用户分配 Google Workspace 许可来决定哪些用户应该有权访问 Google Workspace。
同样，如果您已管理一个 Cloud Identity 免费版账号或付费版账号，建议您向特定用户授予使用 Google Workspace 的权限。您可以将 Google Workspace 添加到现有 Cloud Identity 账号，而不是为这些用户创建单独的 Google Workspace 账号。在您将 Google Workspace 许可分配给选定的用户后，他们就可以开始使用办公和协作应用。
使用的账号数量在满足实际需要的前提下，越少越好
若要让您的用户使用 Google Workspace 进行协作并最大程度地减少管理开销，最好通过单个 Cloud Identity 或 Google Workspace 账号管理所有用户，并为每个用户提供一个用户账号。此方法有助于确保将密码政策、单点登录和两步验证等设置一致地应用到所有用户。
虽然使用单个 Cloud Identity 或 Google Workspace 账号具有这些好处，但通过使用多个账号，您可以获得灵活性和管理自主权。在确定要使用的 Cloud Identity 或 Google Workspace 账号数量时，请考虑所有建议使用多个账号的要求。然后，使用可以满足您的要求的最小数量的 Cloud Identity 或 Google Workspace 账号。
将单独的账号用于预演和生产
对于您可以在 Cloud Identity 和 Google Workspace 中配置的大多数设置，您可以选择每项设置的应用范围，例如，您可以按用户、群组或组织单元指定数据的地理位置。当您计划应用新配置时，可以先选择一个小范围（例如按用户），并验证配置是否符合您的预期。验证配置后，您可以再将同一设置应用于更多群组或组织单元。
与大多数设置不同，将 Cloud Identity 或 Google Workspace 账号与外部身份提供商 (IdP) 集成会产生全局性的影响：
- 启用单点登录是一项全局设置，会应用到除超级用户以外的所有用户。
- 设置用户配置也可能产生全局性影响，具体取决于您的外部 IdP。外部 IdP 中的意外配置错误可能会导致用户在无意间被修改、暂停，甚至删除。
为降低这些风险，请使用单独的预演和生产 Cloud Identity 账号或 Google Workspace 账号：
- 在将同一更改应用到生产账号之前，请使用预演账号验证任何存在风险的配置更改。
- 在预演账号中创建一些测试用户，以便您和其他管理员可以将其用于验证配置更改。但是，请勿向您的用户授予访问预演账号的权限。
如果您有单独的外部 IdP 的预演实例和生产实例，请执行以下步骤：
- 将您的预演 Cloud Identity 账号或 Google Workspace 账号与您的预演 IdP 实例集成。
- 将您的生产 Cloud Identity 账号或 Google Workspace 账号与您的生产 IdP 实例集成。
例如，假设您计划设置与 Active Directory 的联合，并将单独的 Active Directory 林用于进行测试。在这种情况下，您可以将预演 Cloud Identity 账号或 Google Workspace 账号与预演林集成，将生产 Cloud Identity 账号或 Google Workspace 账号与主林集成。将用于 DNS 域名、用户和群组的同一映射方法应用于这两个林/账号对，如下图所示：
您的生产和预演 Active Directory 林和域名使用的 DNS 域名可能不允许您将同一域名映射方法应用于预演和生产。在这种情况下，请考虑在预演林中注册更多的用户主体名称 (UPN) 后缀域名。
同样，如果您计划设置与 Azure Active Directory 的联合，最好采用以下方法：
- 将预演 Cloud Identity 账号或 Google Workspace 账号与预演 Azure Active Directory 租户集成。
- 将生产 Cloud Identity 账号或 Google Workspace 账号与您的 Azure Active Directory 主租户集成。
将用于 DNS 域名、用户和群组的同一映射方法应用到这两个租户/账号对：
您的生产和预演 Azure Active Directory 租户使用的 DNS 域名可能不允许您将同一域名映射方法应用于预演和生产。在这种情况下，请考虑向您的预演租户添加一个额外的域名。
在 Cloud Identity 账号和 Google Workspace 账号中使用独立的 DNS 域名
首次将域名（例如 example.com）添加到 Cloud Identity 账号或 Google Workspace 账号时，您需要验证您是否拥有该域名。添加并验证域名后，您可以添加子域名（例如 marketing.example.com 和 finance.example.com），且无需单独验证各个子域名。
但是，如果您添加子域名，但是没有验证各个子域名，并且您拥有的其他 Cloud Identity 账号或 Google Workspace 账号已在使用该子域名，则可能会发生冲突。为避免这些冲突，建议您为每个账号使用独立的域名。例如，如果您需要两个 Cloud Identity 账号或 Google Workspace 账号，请尽量避免使用彼此之间存在子域名关系的两个域名。请改为使用彼此之间不存在子域名关系的两个域名。此做法适用于主域名和辅助域名。
请勿将 Google Workspace 和 Google Cloud 分离
如果您已在使用 Google Workspace，您的 Google Workspace 账号中的一些用户可能已被授予超级用户权限，以便他们可以执行管理任务。
拥有超级用户权限的用户会隐式获得修改组织节点的 Identity and Access Management (IAM) 政策的权限。此权限允许超级用户为自己分配组织管理员角色或 Google Cloud 组织中的任何其他角色。拥有 Cloud Identity 或 Google Workspace 账号的超级用户访问权限的用户还可以删除该账号、其关联的 Google Cloud 组织及其所有资源。因此，您必须假设超级用户拥有对组织内所有资源的完全访问权限。
如果您的现有 Google Workspace 管理员不负责管理您的 Google Cloud 组织，那么超级用户也是组织管理员这一做法可能会带来安全问题。在这种情况下，您可能会决定创建一个专用于 Google Cloud 的单独的 Cloud Identity 账号，以限制 Google Workspace 超级用户对 Google Cloud 资源的访问权限。将 Google Workspace 和 Google Cloud 分离会产生一些意外后果。
例如，您可能会尝试在 Cloud Identity 账号中创建单独的用户，然后限定该 Cloud Identity 账号才具有对 Google Cloud 组织用户的访问权限。这样可以确保您的 Google Cloud 部署与 Google Workspace 完全隔离开来。但是，复制用户会对用户体验和管理开销造成负面影响。此外，您将无法收到 Google Cloud 发送的任何通知电子邮件，这是因为 Cloud Identity 使用的域名必须不同于 Google Workspace 使用的域名，因此不适合用于路由电子邮件。
但是，如果您在 Google Cloud 组织中引用 Google Workspace 账号中的用户，则会破坏 Google Workspace 和 Google Cloud 之间的隔离性：
Google Workspace 超级用户能够通过全网域授权伪装成同一 Google Workspace 账号中的任何用户。恶意超级用户可能会使用提升的权限重新获得对 Google Cloud 的访问权限。
与使用单独的账号相比，更有效的一个方法是划分 Google Workspace 和 Google Cloud 管理员的责任，以减少超级用户的数量：
Google Workspace 中的大部分管理职责不需要超级用户权限。使用预建的管理角色或自定义管理员角色代替超级用户权限来授予 Google Workspace 管理员履行其职责所需的权限。
仅保留数量尽可能少的超级用户，并不建议在日常使用超级用户权限。
利用审核功能检测管理员用户的可疑行为。
使用单点登录时保护您的外部 IdP
Cloud Identity 和 Google Workspace 可以让您使用外部 IdP（例如 Active Directory、Azure Active Directory 或 OKta 等）设置单点登录。如果启用了单点登录，则 Cloud Identity 和 Google Workspace 将信任外部 IdP 代表 Google 对用户进行身份验证。
启用单点登录具有以下几项优势：
- 用户可以使用现有凭据登录 Google 服务。
- 如果用户已经拥有一个登录会话，则无需再次输入密码。
- 您可以在您的应用和所有 Google 服务中应用一致的多重身份验证政策。
但是，启用单点登录也会让您面临一些风险。单点登录已启用且需要对用户进行身份验证时，Cloud Identity 或 Google Workspace 会将用户重定向到您的外部 IdP。对用户进行身份验证后，IdP 会向 Google 返回一个声明用户身份的 SAML 断言。此 SAML 断言已签名。因此，Google 可以验证 SAML 断言的真实性，并验证是否已使用正确的身份提供商。但是，Cloud Identity 或 Google Workspace 无法验证 IdP 是否做出了正确的身份验证决策以及是否正确声明了用户的身份。
启用单点登录后，您的 Google 部署的整体安全性和完整性取决于您的 IdP 的安全性和完整性。如果以下任意一项存在不安全的配置，您的 Cloud Identity 或 Google Workspace 账号以及依赖于该账号所管理的用户的所有资源都将面临风险：
- IdP 本身
- 运行提供商的机器
- 提供商从中获取用户信息的用户数据库
- 提供商依赖的任何其他系统
为了防止单点登录成为安全状况的薄弱环节，请确保您的 IdP 及其依赖的所有系统均已安全配置：
- 限制对您的 IdP 或提供商所依赖的任何系统拥有管理员权限的用户数量。
- 对于您不希望在 Cloud Identity 或 Google Workspace 中向其提供超级用户权限的用户，也勿向其授予这些系统的管理员权限。
- 如果您不确定是否具有针对您的外部 IdP 的安全控制措施，请勿使用单点登录。
保护对 DNS 区域的访问
Cloud Identity 账号和 Google Workspace 账号由主 DNS 域名标识。创建新的 Cloud Identity 或 Google Workspace 账号时，您必须通过在相应的 DNS 区域中创建特殊 DNS 记录来验证 DNS 域名的所有权。
DNS 的重要性以及对 Google 部署整体安全性的影响并不仅限于注册过程：
Google Workspace 依靠 DNS MX 记录来路由电子邮件。通过修改这些 MX 记录，攻击者或许能够将电子邮件路由到其他服务器并获得对敏感信息的访问权限。
如果攻击者能够将记录添加到 DNS 区域，他们或许能够重置超级用户的密码并获得对账号的访问权限。
为了防止 DNS 成为安全状况的薄弱环节，请确保您的 DNS 服务器具有安全的配置：
对于管理用于 Cloud Identity 或 Google Workspace 的主域名的 DNS 服务器，限制对其拥有管理员权限的用户的数量。
对于您不希望在 Cloud Identity 或 Google Workspace 中向其提供超级用户权限的用户，也勿向其授予您的 DNS 服务器的管理员权限。
如果您计划在 Google Cloud 上部署的工作负载具有现有 DNS 基础架构无法满足的安全要求，请考虑为该工作负载注册一个使用独立 DNS 服务器或代管式 DNS 服务的新 DNS 域名。
将审核日志导出到 BigQuery
Cloud Identity 和 Google Workspace 会保留多个审核日志，以跟踪可能与您的 Cloud Identity 或 Google Workspace 账号安全性相关的配置更改和其他活动。下表汇总了这些审核日志。
| 日志 | 捕获的活动 |
|---|---|
| 管理 | 在您的 Google 管理控制台中执行的操作 |
| 登录 | 成功、失败和可疑的网域登录尝试 |
| 令牌 | 授予或撤消对第三方移动应用或 Web 应用访问权限的实例 |
| 群组 | 对群组和群组成员的更改 |
您可以通过管理控制台或报告 API 访问这些审核日志。对于大多数审核日志，数据将保留 6 个月。
如果您从事的是受管制的行业，将审核数据保留 6 个月可能还不够。如需将数据保留更长时间，请将审核日志配置为导出到 BigQuery。
为了限制导出的审核日志遭到未经授权访问的风险，请对 BigQuery 数据集使用专用 Google Cloud 项目。为了防止审核数据遭到篡改或删除，请遵循最小权限原则授予对该项目和数据集的访问权限。
Cloud Identity 和 Google Workspace 审核日志是对 Cloud Audit Logs 日志的补充。如果您还使用 BigQuery 收集 Cloud Audit Logs 日志和其他特定于应用的审核日志，则可以将登录事件与用户在 Google Cloud 或您的应用中执行的活动相关联。如果您能够跨多个来源关联审核数据，这有助于您检测和分析可疑活动。
设置 BigQuery 导出需要 Google Workspace 企业版许可。设置主审核日志后，系统会为所有用户（包括没有 Google Workspace 许可的用户）导出这些日志。对于至少拥有 Google Workspace 商务版许可的用户，系统会导出云端硬盘和移动设备审核日志等特定日志。
如果您针对大多数用户使用 Cloud Identity 免费版，您仍然可以将日志导出到 BigQuery，方法是将 Google Workspace 企业版添加到现有 Cloud Identity 账号并为选定的一组管理员购买 Google Workspace 许可。
单位
通过组织，您可以使用项目和文件夹层次结构组织资源，将组织节点作为根。组织与 Cloud Identity 或 Google Workspace 账号关联，并且其名称派生自关联账号的主域名。当 Cloud Identity 或 Google Workspace 账号中的用户创建第一个项目时，系统会自动创建一个组织。
每个 Cloud Identity 或 Google Workspace 账号只能有一个组织。实际上，如果没有对应的账号，则无法创建组织。尽管存在这种依赖关系，您仍然可以将对单个组织中资源的访问权限授予给多个不同账号中的用户：
由于您可以灵活地引用不同 Cloud Identity 账号或 Google Workspace 账号中的用户，因此您可以单独处理账号和组织。您可以分开决定管理用户所需的 Cloud Identity 或 Google Workspace 账号数量和管理资源所需的组织数量。
您创建的组织数量及其用途会对您的安全状况、团队和部门的自主权以及管理的一致性和效率产生重大影响。
以下部分介绍确定要使用的组织数量的最佳做法。
使用的组织数量在满足实际需要的前提下，越少越好
通过组织的资源层次结构，您可以利用继承来减少管理 IAM 政策和组织政策的工作量。通过在文件夹或组织级层配置政策，您可以确保政策在资源的子层次结构中得到统一应用，从而避免重复的配置工作。为了最大程度地减少管理开销，使用的组织数量越少越好。
相比之下，使用多个组织可以获得更大的灵活性和管理自主权。以下部分介绍了您在什么情况下可能需要更大的灵活性或自主权。
在任何情况下，在决定要使用的组织数量时，请考虑所有建议使用多个组织的要求。然后，在满足您要求的前提下使用最少的组织。
使用组织来划分管理权限
在资源层次结构中，您可以授予资源、项目或文件夹级别的权限。您可以向用户授予权限的最大级别是组织级别。
获得组织级别的组织管理员角色的用户拥有对组织、其资源和其 IAM 政策的完全控制权。组织管理员可以控制组织内的任何资源，并且可以自由地将管理员权限委派给其他任何用户。
但是，组织管理员的权限仅限于组织中，组织是管理员权限适用的最大范围：
- 除非获得明确授权，否则一个组织的管理员无法访问其他组织中的任何资源。
- 组织外部的任何用户都无法取消该组织的组织管理员的控制权。
要使用的合理组织数量取决于您公司的独立管理员用户组的数量：
- 如果您的公司是按职能组织的，那么可能有一个部门负责监管所有 Google Cloud 部署。
- 如果您的公司是按部门组织的，或者拥有多个自主经营的子公司，则可能没有一个专门负责的部门。
如果单个部门负责监管 Google Cloud 部署，则最好使用单个 Google Cloud 组织节点。在组织内，使用文件夹结构来组织资源并向其他团队和部门授予不同级别的访问权限。
如果涉及到多个独立部门，尝试通过单个组织来集中管理可能会造成冲突：
- 如果您指定某个部门来管理组织，其他部门可能会反对。
- 如果您让多个团队或部门共同拥有一个组织，则可能很难保持一致的资源层次结构，并且很难确保 IAM 政策和组织政策一致地应用于您的资源中。
要避免这种冲突，请使用多个组织并在每个组织中创建单独的文件夹结构。通过使用单独的组织，您可以在不同的管理员用户组之间建立界限，从而划分其管理权限。
使用单独的预演组织
为了有助于确保一致性和避免重复配置工作，请使用文件夹层次结构组织项目，并在文件夹或组织级别应用 IAM 政策和组织政策。
将政策应用于多个项目和资源存在负面影响。对政策本身或政策所应用到的资源层次结构的任何更改都可能会产生影响广泛的意外后果。为降低此风险，在将政策更改应用到主组织中之前，最好先对其进行测试。
我们建议您创建一个单独的预演组织。此组织可以帮助您测试资源层次结构更改、IAM 政策、组织政策或其他可能会在组织范围产生影响的配置，例如访问权限级别和政策。
为了确保在预演组织中执行的测试或实验的结果也适用于生产组织，请将预演组织配置为使用和主组织相同的文件夹结构，但只包含少量的项目。在任何时候，预演组织中的 IAM 政策和组织政策都应与您的生产组织的政策相匹配，或者应反映您计划应用于生产组织的下一个政策版本。
如下图所示，您将预演 Cloud Identity 账号或 Google Workspace 账号作为预演组织的基础。您使用预演账号（或与您的预演账号集成的外部 IdP）创建专用测试用户和反映您在生产 Cloud Identity 账号或 Google Workspace 账号中所用群组的群组结构。然后，您可以使用这些专用测试用户和群组来测试 IAM 政策，并且不会影响现有用户。
避免使用单独的测试组织
对于您计划在 Google Cloud 上部署的每个生产工作负载，您可能需要一个或多个测试环境，您的开发团队和 DevOps 团队可以使用这些测试环境来验证新版本。
从安全角度来看，为了防止未经测试的版本意外影响生产工作负载，您需要将测试环境与生产环境完全分离开来。同样，这两种类型的环境对 IAM 政策也有不同的要求。例如，为了向开发者和测试人员提供所需的灵活性，您的测试环境的安全要求可能比生产环境的安全要求要宽松得多。
如下图所示，从配置的角度来看，您需要使测试环境与生产环境尽可能相似。任何差异都会增加在测试环境中正常运行的部署在被部署到生产环境后出现故障的风险。
为在保持环境隔离性和一致性之间取得平衡，请使用同一组织内的文件夹来管理测试环境和生产环境：
- 在组织级别（或使用共同的父级文件夹）应用环境中通用的任何 IAM 政策或组织政策。
- 使用单独的文件夹管理不同类型环境之间存在差异的 IAM 政策和组织政策。
请勿使用预演组织来管理测试环境。测试环境对开发团队和 DevOps 团队的工作效率至关重要。在预演环境中管理此类测试环境会限制您使用预演组织试验和测试政策更改的能力；任何此类更改都可能中断这些团队的工作。简而言之，如果您使用预演组织管理测试环境，会削弱预演组织的用途。
使用单独的组织进行实验
为充分利用 Google Cloud，请让您的开发团队、DevOps 团队和运维团队熟悉该平台，并通过运行教程来扩展其体验。鼓励他们试用新功能和服务。
使用单独的组织作为沙盒环境以支持这些类型的实验活动。通过使用单独的组织，您可以让实验不受您在生产组织中使用的任何政策、配置或自动化的影响。
避免使用预演组织进行实验。您的预演环境应使用与生产组织类似的 IAM 政策和组织政策。因此，预演环境可能与生产环境存在相同的限制。同时，通过放宽政策来允许实验会削弱预演组织的用途。
为防止实验性组织变得混乱无序、产生过多费用或导致安全风险，请发布相应准则来规定团队使用组织的方式以及负责维护组织的人员。此外，请考虑设置自动化，以在特定天数后自动删除资源，甚至整个项目。
如下图所示，在创建组织以用于实验时，需要先创建一个专用 Cloud Identity 账号。然后，使用主 Cloud Identity 账号或 Google Workspace 账号中的现有用户授予用户访问实验性组织的权限。
要管理其他 Cloud Identity 账号，您需要在 Cloud Identity 账号中至少拥有一个超级用户账号。如需了解如何保护这些超级用户账号，请参阅超级用户账号最佳做法。
通过网域限定共享来强制建立信任关系
通过 IAM 政策，您可以将任何有效的 Google 身份添加为成员。这意味着当您修改资源、项目、文件夹或组织的 IAM 政策时，可以添加来自不同源的成员，包括：
- 与组织关联的 Cloud Identity 账号或 Google Workspace 账号以及同一组织的服务账号中的用户
- 其他 Cloud Identity 或 Google Workspace 账号中的用户
- 其他组织中的服务账号
- 消费者用户账号（包括
gmail.com用户和使用公司电子邮件地址的消费者账号）
对于需要与关联公司或其他公司进行协作的场景和项目，如果能够引用不同来源的用户，这会非常有用。在大多数其他情况下，最好将 IAM 政策限定为仅允许来自可信来源的成员。
通过网域限定共享来定义一组允许从其中将成员添加到 IAM 政策的受信任的 Cloud Identity 或 Google Workspace 账号。在组织级别定义此组织政策（以便将其应用于所有项目）或在资源层次结构顶部附近的文件夹中定义此组织政策（以允许特定项目被豁免）。
如果您使用单独的 Cloud Identity 或 Google Workspace 账号和组织来分隔预演环境、生产环境和实验环境，请使用网域限定共享政策来强制执行分隔，如下表所示：
| 组织 | 受信任的 Cloud Identity 或 Google Workspace 账号 |
|---|---|
| 预演 | 预演 |
| 生产 | 生产 |
| 实验 | 生产 |
为组织使用中性域名
组织由 DNS 域名（如 example.com）标识。该域名派生自关联的 Cloud Identity 或 Google Workspace 账号的主域名。
如果您的公司使用了规范的 DNS 域名，请在生产 Cloud Identity 或 Google Workspace 账号中使用该域名作为主域名。通过使用规范的 DNS 域名，您可以确保员工能够轻松识别组织节点的名称。
如果您的公司拥有若干子公司或多个不同的品牌，则可能没有规范的域名。这种情况下应考虑注册一个中性且专供 Google Cloud 使用的新 DNS 域名，而不是任意选择一个现有域名。通过使用中性 DNS 域名，您可以避免对公司内的特定品牌、子公司或部门表现出偏好，防止可能对云采用造成的负面影响。将您的其他品牌专属域名添加为辅助域名，使它们可以用于用户 ID 和单点登录。
跨 Google Cloud 组织使用结算账号
结算账号定义了一组给定 Google Cloud 资源的付款方。虽然结算账号可以存在于 Google Cloud 组织之外，但最常见的是结算账号与组织相关联。
当结算账号与组织关联后，它们被视为组织的子资源，并且受组织内定义的 IAM 政策的约束。最重要的是，这意味着您可以使用 Billing IAM 角色来定义哪些用户或群组可以管理或使用账号。
已被授予 Billing Account User 角色的用户可以将项目关联到结算账号，使资源计费归入此账号下。将项目与结算账号关联不仅可在同一组织内进行，还可跨组织进行。
如果您使用多个组织，则您可以利用结算账号可以跨组织使用这一事实。这样，您可以单独决定需要多少个结算账号，而无需考虑您需要多少个组织。
合适的结算账号数量仅取决于您的商业或合同要求，例如币种、付款资料以及您需要的单独账单数量。与账号和组织一样，为了最大程度地降低复杂性，您需在满足您要求的前提下使用最少的结算账号。
若要细分多个组织产生的费用，请配置您的结算账号以将结算数据导出到 BigQuery。导出到 BigQuery 的每条记录不仅包含项目名称和 ID，还包含与项目关联的组织的 ID（在 project.ancestry_numbers 字段中）。
后续步骤
- 创建新的 Cloud Identity 账号
- 了解 Google Cloud 如何让您在混合环境中对公司用户进行身份验证以及常见模式。
- 查看联合 Google Cloud 与外部身份提供方的最佳实践。
- 了解如何将 Google Cloud 与 Active Directory 或 Azure Active Directory 联合。
- 查看管理身份和访问权限的最佳实践。