员工身份联合会将您的 Google Cloud 组织与外部身份提供方 (IdP) 联合起来，以实现单点登录 (SSO)。
您可以应用这些最佳实践来有效使用员工身份联合，并最大限度地降低安全风险。
选择合适的架构
以下各部分介绍了选择符合您要求的联合身份验证架构的关键因素。
选择联合架构模式
以下四种模式介绍了将组织与外部 IdP 联合的常见方式： Google Cloud
在进行联邦学习之前，请考虑每种模式的优势和限制，然后选择符合您要求的模式。如需了解详情，请参阅身份联合的架构模式。
按服务划分的分区联盟使用情况
一般来说，我们建议您按服务（而非按用户）划分联合使用情况。按服务划分使用情况总体而言缺点较少。
为降低复杂性，我们建议使用 Cloud Identity 或 Workforce Identity Federation。不过，根据您的需求，您可能需要同时使用这两种模式，如混合模式中所述。
如果您同时使用 Cloud Identity 联合和员工身份联合，可以按以下方式划分其使用范围：
按用户进行分区：将用户划分为两个群组：一个使用员工身份联合，另一个使用 Cloud Identity 联合。
- 优势：每位用户在 Google 服务中都拥有一个身份，并且只需一种登录方法。
缺点：按用户进行分区有以下几个缺点：
管理访问权限群组可能很复杂，因为 IAM 允许政策需要包含多种主账号类型，并且您无法为 Cloud Identity 用户和员工身份联合用户使用相同的群组。
不同群组的用户无法相互分享链接，因为 Google Cloud 控制台、Gemini Enterprise 和其他工具会根据用户的登录方式使用不同的网址。
不同群组的用户可能可以使用不同的功能集。
按服务进行划分：配置各项服务（例如Google Cloud 或 Gemini Enterprise），使其仅向员工身份联合用户或 Cloud Identity 用户授予访问权限，但绝不会同时向这两类用户授予访问权限。
- 优势：简化管理，并确保不同用户获得的功能集保持一致。
- 缺点：部分员工可能需要分配两个身份，一个使用 Workforce Identity Federation，另一个使用 Cloud Identity。
我们建议按服务进行分区，特别是将 Gemini Enterprise 和 NotebookLM Enterprise 与其他服务分开。Gemini Enterprise 和 Google Cloud 控制台是为不同任务设计的独立工具。登录流程的任何差异都应尽可能减少对整体用户体验的影响。
为了帮助强制执行此分区，请使用组织政策限制条件。
加强群组治理
您应使用群组管理访问权限，并建立明确的流程来管理这些群组，以便有效使用员工身份联合。
用户访问资源的权限不是在身份验证期间确定的。相反，当用户尝试访问资源时，系统会根据附加到该特定资源的政策评估访问权限。这些政策可能包括：
- 一项或多项允许政策
- 零个或多个拒绝政策
- 零个或多个主账号访问权限边界政策
政策用于定义单个主账号或主账号集的访问权限：
主账号：通过主账号标识符识别的经过身份验证的用户。 员工主账号标识符类似于以下内容：
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT主账号标识符包含以下内容：
POOL_ID：唯一标识员工身份池。SUBJECT：唯一标识特定用户。 值和格式取决于您的 IdP 和属性映射。
正文集：符合特定条件的用户。 员工身份联合支持三种主账号集：基于群组（群组成员）、基于属性和通配符（所有用户）。
向各个正文授予访问权限在特定情况下可能很有用，但由于存在以下问题，这种做法往往难以扩展：
- 逐个添加主账号会导致允许政策不断扩大，越来越难以管理。
- 个人访问权限管理需要经常更改允许政策。
- 随着时间的推移，政策可能会变得越来越不一致。
为了实现可伸缩且有效的访问权限管理，使用基于群组的主账号集可带来以下优势：
- 您可以使用现有的身份工具和流程，通过在群组中添加或移除成员来管理访问权限。
- 减小允许政策的大小并降低其复杂性。
- 确保具有相同角色的用户拥有相同的资源访问权限。
如需使用群组来管理访问权限，您必须以特定方式配置外部 IdP，并了解 IdP 对群组施加的任何限制。
以下部分介绍了如何有效地使用群组并避免 IdP 限制的最佳实践。
最佳做法：
区分不同类型的群组。使用访问权限群组授予对资源的访问权限。
使用强制执行群组来限制对资源的访问权限。
请勿使用组织群组和协作群组来管理访问权限。
仅将组织群组和协作群组用于 Gemini Enterprise。
区分不同类型的群组
以下列表介绍了组织中常见的四种类型的群组：
- 访问权限群组：仅用于授予对 Google 服务或Google Cloud 资源的访问权限。此类群组代表工作职能，用于简化执行这些工作职能所需的角色分配。
- 组织群组：这些群组表示组织结构中的各个小组，通常来自于人力资源数据。这些群组可以根据部门、隶属结构、地理位置或其他组织分组方式进行建立。
- 协作群组：这些群组代表希望协作处理项目或讨论特定主题的工作组、项目成员或用户，可能用于电子邮件分发。协作群组通常是用户临时自行创建的。
- 强制执行群组：强制执行群组也称为政策群组，用于限制访问权限，而访问权限群组用于授予访问权限。例如，主账号访问权限边界、拒绝政策或强制执行多重身份验证。 访问权限群组可以允许成员自愿退出群组。 不过，加入强制执行组并非自愿行为。
您需要联合的群组取决于您使用的以下服务：
- 对于 Google Cloud，您只需要访问权限群组和强制执行群组。
- 对于 Gemini Enterprise，您需要访问权限群组、强制执行群组，以及（如果使用基于数据注入的连接器）某些组织和协作群组。
配置员工身份联合时，请排除不相关的群组类型，以避免 IdP 出现令牌限制。这种方法有助于您降低超出 IdP 施加的限制的风险，并确保更一致地使用群组。
使用访问权限群组授予对资源的访问权限
为了有效管理访问权限，我们建议您使用与访问群组对应的正文集。 访问权限群组的唯一用途是提供访问权限。此类群组代表工作职能，可简化执行这些职能所需的角色分配。
通过执行以下操作来配置访问权限群组：
- 在 IdP 中，创建代表工作职能的访问权限群组。
- 将访问群组映射到正文集，以便在 IAM 中使用它们。
- 创建政策绑定，以向主账号集授予每个工作职能所需的资源访问权限。
- 在外部 IdP 中，根据用户的工作职能向群组添加用户或从中移除用户。
使用访问权限群组来管理授予访问权限的政策，包括以下政策：
- IAM 允许政策
- VPC Service Controls 入站规则
确保访问群组足够精细。例如，以下群组表示有效访问权限群组：
widget-sales-dashboard-readers：授予对特定 BigQuery 数据集和关联信息中心的读取权限。dev-ssh-users：向开发环境中的 Compute Engine 虚拟机授予 OS Login 访问权限。相比之下，以下类型的群组通常不适合用作访问权限群组：
cloud-admins等广泛的管理员组通常缺乏有关适用工作负载或环境的具体信息。australia-fte等组织群组表示团队或按地理位置划分的群组，而不是按工作职能划分的群组。security-discuss等通信群组专为电子邮件收件人列表或协作而设计，而不是用作访问权限群组。
为了保持访问权限群组的精细度，请为每个加入 Google Cloud的工作负载或项目创建一组新的访问权限群组。这样，您就可以根据在 Google Cloud上运行的工作负载数量来扩缩访问组数量。
使用强制执行群组限制对资源的访问权限
强制执行群组与访问权限群组类似，但通常在以下方面有所不同：
- 不允许成员自愿退出群组。
- 它们并非特定于某个工作负载。
对于会减少访问权限的政策，请使用强制执行群组，包括以下政策：
- IAM 拒绝政策
- 主体访问边界
- 组织政策
强制执行群组的示例包括 users-in-restricted-locations、fedramp-low 和 mfa-users。强制执行组的数量通常很少，不太可能影响用户的总群组成员资格。
请勿使用组织群组和协作群组来管理访问权限
为了有效管理访问权限，您可以使用访问权限群组和强制执行群组，而不是组织群组或协作群组。
组织群组表示组织结构中的各个团队或子集，通常来自于人力资源数据。这些群组不适合用于管理对 Google Cloud 资源的访问权限，原因如下：
- 团队的职责和组成可能会随着时间的推移而发生变化。例如，某个团队可能会将工作负载移交给另一个团队，或者两个团队可能会合并。在这些过渡期间，使用组织群组管理访问权限可能需要级联式政策变更。
- 组织群组的成员极少需要相同的资源访问权限。向组织群组授予访问权限通常会导致部分成员获得超出实际需要的访问权限。
协作群组通常由群组成员自行管理，允许成员在获得其他成员批准后加入，也可以无需批准即可加入。使用协作群组授予访问权限可能会导致权限过高和权限升级。
为防止组织群组和协作群组用于访问权限管理，请将 IdP 配置为在用于员工身份联合的令牌或断言中排除这些群组成员身份。
仅将组织群组和协作群组用于 Gemini Enterprise
虽然组织群组和协作群组不太适合用于管理对 Google Cloud 资源的访问权限，但您可能需要使用它们来管理 Gemini Enterprise：
- ACL 评估：当您使用基于数据注入的连接器将 Gemini Enterprise 与 Microsoft 365 集成时，它可能会遇到访问权限控制列表 (ACL) 引用组织和协作群组的文档。如果 Gemini Enterprise 无法访问用户在这些群组中的成员身份，则可能无法正确评估用户是否有权访问这些文档。
- 笔记本分享：NotebookLM 允许用户分享笔记本。允许用户与协作群组共享笔记本通常比限制仅与个别用户共享更方便。
为确保组织群组和协作群组仅适用于 Gemini Enterprise，您可以按如下方式配置 IdP：
- 使用 SCIM 来配置组织群组和协作群组及其成员资格。
- 在用于员工身份联合的令牌或断言中排除组织和协作群组成员身份。
管理员工身份池
员工身份池用于定义主账号标识符的命名空间，并充当联合配置的容器。与用户目录不同，池不存储有关用户或群组的信息。
每个 IdP 使用一个池
员工身份池是组织级层资源，而不是项目级层资源。此设计反映了员工身份池管理整个 Google Cloud 组织的身份验证，而不是单个项目或工作负载的身份验证。
对于大多数组织，员工身份池的数量应与 IdP 的数量一致：
- 如果贵组织使用单个 IdP 来管理身份验证，请使用单个员工身份池。
- 如果您的组织使用多个 IdP（例如，因收购而使用多个 IdP），请为每个 IdP 使用一个员工身份池。
限制员工身份池的数量有助于确保以下事项：
- 将新工作负载添加到 Google Cloud时，您无需创建或修改员工身份池。
- 您可以使用 IAM 来控制 Google Cloud 个人用户可以访问哪些项目和资源。
选择一个唯一且有意义的池名称
为了使主账号标识符具有全局唯一性，员工身份会将员工身份池名称编码到主账号标识符中。为员工身份池选择名称时，请考虑以下限制：
- 唯一性：选择一个在 Google Cloud 中唯一且未被其他组织声明的名称。
- 不可变性：您无法更改员工身份池名称。选择一个随着时间的推移仍有意义的名称，避免使用临时性计划名称。
- 用户体验：根据您的登录配置，用户可能需要在登录时输入池名称。选择一个简短且容易记住的名称。
将池视为高权限资源
员工身份池和提供方决定了用户登录的方式，并控制了如何从外部 IdP 派生身份和群组成员资格。由于这些组件控制着身份验证逻辑，因此对于 Google Cloud 组织的安全至关重要。如果这些组件遭到入侵，不法分子可能会发起欺骗攻击。
为了发起欺骗攻击，不法分子可能会尝试执行以下操作：
- 修改特性映射：更改特性映射可能会让不法分子以他人的身份进行身份验证，并获得未经授权的特权访问权限。
- 添加恶意提供方：添加提供方可能会让作恶方绕过您组织的 IdP，并使用他们控制的其他 IdP 进行身份验证。
员工身份池和提供方是安全至关重要的资源，需要以下保护：
- 限制对非联合身份验证用户的访问权限：将管理员权限限制为仅授予少数 Cloud Identity 或 Google Workspace 用户，包括至少一名紧急访问用户。
- 保护管理用户：要求所有管理用户和紧急访问用户启用两步验证。
- 即时访问权限：使用 Privileged Access Manager (PAM) 授予即时管理访问权限，而不是永久访问权限。
将联盟扩展到合作伙伴时，请考虑风险
使用员工身份联合与外部 IdP 进行 Google Cloud 联合可建立信任关系。通过使用联合身份验证，您可以依赖外部 IdP 来执行以下操作：
- 执行符合您的安全要求的多重身份验证 (MFA)。
- 针对用户身份和群组成员资格做出准确的断言。
- 遵循身份治理流程，确保及时取消配置用户，并且群组成员资格准确反映当前角色。
员工身份联合提供的机制有限，无法验证外部 IdP 所做的断言。具体而言，员工身份联合不支持与 Cloud Identity 相同方式的 SSO 后 MFA。
在使用员工身份联合来允许外部合作伙伴或承包商访问您的 Google Cloud 资源之前，请确定此信任级别是否合适。除非您信任合作伙伴及其 IdP 能够始终满足您的安全标准，否则请勿使用员工身份联合来授予合作伙伴访问权限。
管理员工身份池提供方
员工身份池提供方定义了与外部 IdP 的联合关系，并包含以下配置：
- 用于单点登录的 IdP。
- 用于从 IdP 提供的令牌或断言中派生出主账号标识符的属性映射。
- 可选：用于查找群组成员资格信息的 SCIM 租户。
最佳做法：
选择有意义的提供商名称。使用 IdP 的应用门户公开各个服务。
每个池使用单个提供方以避免主题冲突。
为 Google Cloud 控制台和 Gemini Enterprise 使用相同的池和提供方。
使用特定于租户的颁发者 URI。
避免使用 OpenID Connect (OIDC) 隐式流程。
选择有意义的提供方名称
创建员工身份池提供方时，您必须为其分配一个名称。与员工身份池名称不同，此名称无需具有全局唯一性，也不会编码到主账号标识符中。不过，根据您的登录配置，用户可能需要在登录时输入提供方名称。为改善用户体验，请选择有意义且易于记忆的名称，例如 entra 或 staff。
请避免使用 oidc 或 saml 之类的名称，因为这些首字母缩写词可能不为用户所熟知。
在 IdP 应用门户中显示各个服务
Microsoft Entra ID 和 Okta 等身份提供方提供了一个应用门户，可让用户发现并访问其已获分配的应用。您可以使用门户网站通过以下方式优化用户体验：
- 将门户配置为单独显示相关的 Google 服务，而不是显示单个 Google Cloud 链接。
- 配置可自动登录用户的链接。
下表列出了支持员工身份联合的常见 Google 服务以及用于自动登录的网址：
| 应用 | 网址 |
|---|---|
| Google Cloud 员工身份联合控制台（也称为控制台 [联合]） | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google |
| Gemini Enterprise | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID |
| NotebookLM Enterprise | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER |
| IAP Web 应用 | 应用网址，例如 https://iap.example.com/ |
替换以下内容：
POOL：员工身份池名称。PROVIDER：池提供方名称。WEBAPP_ID：Gemini Enterprise Web 应用 ID。PROJECT_NUMBER：NotebookLM Enterprise 项目编号。
每个池使用单个提供方以避免主题冲突
您可以使用员工身份联合向员工池添加多个提供方。在迁移期间，如果您暂时允许用户使用不同的 IdP 进行身份验证，则添加第二个提供方会很有用。除了临时情况外，请避免使用多个提供商，原因如下：
- 主题冲突：使用多个提供方会带来主题冲突的风险。在这种冲突中，一个提供方的
google.subject属性映射返回的值与另一个提供方的相同。此类冲突会将多个外部身份映射到同一 IAM 主账号，导致这些身份在 Cloud Audit Logs 中无法区分。 - IAP 兼容性：IAP 要求员工身份池具有单个提供方，以便自动将未经身份验证的用户重定向到 IdP。如果您添加其他提供方，IAP 将无法对用户进行身份验证。
如果您需要与多个提供方联合，请创建多个员工池，并为每个池配置一个提供方。
为 Google Cloud 控制台和 Gemini Enterprise 使用相同的池和提供方
如果您同时为 Gemini Enterprise 和 Google Cloud使用员工身份联合，请使用单个提供方，以确保用户可以同时访问这两项服务，而无需再次登录。如果您使用具有不同属性映射的单独提供方，用户可能会遇到以下情况：他们对资源的访问权限因登录时使用的提供方而异。
使用特定于租户的颁发者 URI
配置提供方时，您需要指定一个用于唯一标识 IdP 的提供方 URI。不过，根据您的 IdP 配置，发布者 URI 可能并非贵组织租户独有。例如，如果您使用通用或共享的颁发者 URI（例如 Microsoft Entra ID 通用端点 [https://login.microsoftonline.com/common/v2.0]），您可能会无意中允许其他组织的用户向您的 Google Cloud组织进行身份验证。
为帮助防止意外的跨租户访问，请使用特定于租户的颁发者 URI。如果您的 IdP 不提供特定于租户的颁发者 URI，请配置属性条件以限制对特定租户的访问权限。
避免使用 OpenID Connect (OIDC) 隐式流
配置 OIDC 提供方时，请优先选择授权代码流程，而不是隐式流程。在 OAuth 规范的 2.1 版中，隐式流程已被弃用，因为该流程容易受到令牌泄露和注入的攻击。使用授权代码流程有助于降低令牌被拦截的风险。
管理用户
您可以使用员工身份联合管理用户。Workforce Identity Federation 通过执行以下步骤，从用户的令牌或断言中派生出用户的正文标识符：
- 通过应用
google.subject的属性映射来确定主题标识符。主题标识符必须在员工身份池中唯一标识用户，但不必在整个 Google Cloud中具有唯一性。 通过将主题标识符附加到用于标识员工身份池的前缀来派生主账号标识符。生成的主账号标识符在 Google Cloud 中是唯一的，并且具有以下格式：
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\ subject/SUBJECT
当使用员工身份联合进行身份验证的用户访问资源时，IAM 会使用主账号标识符评估允许政策中的角色绑定，并将其记录在 Cloud Audit Logs 中。
使用不可变的正文标识符
当用户的正文标识符发生变化时，其正文标识符也会发生变化。 因此， Google Cloud 不再将他们识别为同一用户：
- 用户无法访问之前被授予访问权限的资源，因为其新的主账号标识符不再与允许政策中列出的主账号标识符匹配。
- Cloud Audit Logs 条目仅包含新的主账号标识符，无法再与使用旧主账号标识符的日志相关联。
为了保持用户主账号标识符的稳定性，请使用可为 google.subject 生成稳定值的属性映射。
许多 IdP 会自动为用户生成唯一的数字标识符或 UUID 格式的标识符。这些标识符是唯一且稳定的，因此非常适合用作 google.subject。不过，将这些标识符用作 google.subject 可能会导致主账号标识符过长且难以理解，从而难以使用。
为帮助您选择 google.subject 的标识符，请按优先级降序考虑以下要求：
- 唯一性：该值可唯一标识 IdP 中的用户。
- 可用性：该值有意义，或者至少可以在 IdP 的用户目录中轻松搜索到。
- 不可变性：值是不可变的，或者至少只能由管理员更改。
请勿重复使用主题标识符
许多 IdP 会对某些用户标识符强制执行唯一性限制，但允许重复使用标识符。例如，IdP 可能不允许您创建两个具有相同用户名 bob 的用户。不过，在您删除用户账号 bob 后，IdP 可能会允许您创建新用户账号，并再次为其分配用户名 bob。
如果提供商针对 google.subject 的属性映射引用了允许重复使用的用户标识符，您可能会遇到正文冲突：如果旧用户和新用户的 google.subject 相同，则员工身份联合无法区分他们。因此，新用户可能会获得仅供旧用户访问的资源的访问权限。
为防止主题冲突，请执行以下一项或两项操作：
- 将
google.subject映射到您的 IdP 不允许重复使用的用户标识符。 - 在 IdP 中删除用户时，请使用
locations.workforcePools.subjects.deleteAPI 来删除 Google Cloud中的用户数据，并阻止在所有数据都被清除之前使用同一用户标识符进行登录。
Microsoft Entra ID：使用 UPN 作为主题标识符
此最佳实践仅适用于您将 Microsoft Entra ID 用作 IdP 的情况。
如果您使用 Microsoft Entra ID，则可用作主题标识符的标识符包括以下内容：
- 用户主账号名称 (
upn) - 对象 ID (
oid) - 电子邮件地址（
proxyAddresses中的主要地址）
在这些选项中，我们建议使用用户正文名称作为正文标识符，原因如下：
- 所有用户都有用户正文名称。
- 用户正文名称可唯一标识用户。
- 用户主账号名称往往有意义且易于使用。
- 用户正文名称中嵌入了域名，可唯一标识用户关联的 Microsoft Entra ID 租户。
- 您的组织可能已制定政策，禁止或管控用户主账号标识符的重复使用。
相比之下，用户的对象 ID 和电子邮件地址不太适合，原因如下：
- 对象 ID (
oid) 是不可变的，但格式为 GUID。这种格式难以处理，对人类来说也没有意义。 - 电子邮件地址不是必需属性，可能不会针对所有用户进行填充。
无论您选择哪种标识符，我们都建议您避免应用强制将标识符转换为小写等转换。
管理群组
员工身份联合可以从以下来源确定用户的群组成员资格：
- 由 IdP 提供的 SAML 断言或 ID 令牌。
- Microsoft Graph API（如果您使用 Microsoft Entra ID 作为 IdP）。
- 与员工身份池提供方关联的 SCIM 租户。
默认情况下，员工身份联合仅使用 SAML 断言或 ID 令牌：
| 来源 | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML 或 ID 令牌 | ||
| Microsoft Graph API | - | - |
| SCIM 租户 | - | - |
如果您使用 Microsoft Entra ID 作为 IdP，则可以启用额外属性功能。然后，员工身份联合仅使用 Microsoft Graph API 作为群组成员资格的来源：
| 来源 | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML 或 ID 令牌 | - | - |
| Microsoft Graph API | ||
| SCIM 租户 | - | - |
如果您使用 Gemini Enterprise，则可以配置员工身份联合以使用 SCIM 租户，这会改变以下行为：
- Gemini Enterprise 使用 SCIM 租户中的群组成员资格，并忽略 SAML 断言或 ID 令牌中的群组成员资格信息。
- Google Cloud 使用 SAML 断言或 ID 令牌中的群组成员资格信息，并忽略 SCIM 租户中的群组成员资格信息。
| 来源 | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML 或 ID 令牌 | - | |
| Microsoft Graph API | - | - |
| SCIM 租户 | - |
对于每个群组成员身份，员工身份联合会通过执行以下步骤来派生出正文标识符：
- 通过执行以下任一操作来确定群组标识符：
- SAML 断言或 ID 令牌：为
google.groups应用属性映射。 - SCIM 租户：为
google.group应用声明映射。 - Microsoft Graph API：按照提供方配置中的
extra-attributes-type操作。
- SAML 断言或 ID 令牌：为
通过将群组标识符附加到用于标识员工身份池的前缀来派生主账号标识符。生成的主账号标识符在 Google Cloud 中是唯一的，并且具有以下格式：
principalSet://iam.googleapis.com/locations/global/workforcePools/\ POOL_ID/group/GROUP_ID
当使用员工身份联合进行身份验证的用户访问资源时，IAM 会使用这些主账号标识符来评估允许政策中的角色绑定。
使用不可变的群组标识符
所有 IAM 政策都通过主账号标识符引用群组。当您在 IdP 中重命名群组以致其标识符发生更改时，Google Cloud 不再将其识别为同一群组：
- 现有 IAM 角色绑定继续引用旧的主账号标识符，并变得无效。
- 重命名后的群组的成员会失去访问权限，因为该群组的新正文标识符不再与任何 IAM 角色绑定相匹配。
为防止出现这些中断情况，请将属性和声明映射配置为使用稳定且不可变的值，例如 IdP 生成的唯一 ID。避免使用显示名称或电子邮件地址作为群组标识符，因为这些信息可能会在组织发生变化时发生更改。
减少断言或令牌中的群组成员资格
默认情况下，您的 IdP 可能会在 SAML 断言或 ID 令牌中包含比管理对 Gemini Enterprise 和 Google Cloud 资源的访问权限所需的更多群组成员资格。包含不必要的群组成员资格会带来多种风险：
- 部分访问权限丢失：许多身份提供方 (IdP) 会限制可在令牌或断言中包含的群组成员资格数量。当用户超出此限制（群组超额）时，IdP 可能会舍弃一些群组成员资格，导致用户无法访问某些资源。
- 登录失败：员工身份联合限制了
google.groups属性映射可生成的群组成员资格的大小和数量。如果用户超出其中一项限制，将无法登录。 - 群组使用不一致：如果您向 Google Cloud公开群组，项目所有者可能会决定使用这些群组来管理对资源的访问权限，即使您从未打算在Google Cloud中使用某些群组也是如此。
以下方法有助于您降低这些风险，并减少断言或令牌中的组成员身份数量：
按群组类型过滤：某些 IdP（包括 Microsoft Entra ID）允许您配置一个过滤器，以确定要在断言或令牌中包含哪些群组。您可以配置过滤器，以排除与您的配置和计划使用的服务无关的群组类型。
下表显示了您可能需要在断言或令牌中包含哪些类型的群组，具体取决于您计划使用的服务：
组类型 Google Cloud Gemini（无同步） Gemini (SCIM) 访问权限群组 - 违规处置群组 - 组织群组 不需要 * - 协作群组 不需要 * - * 仅在使用基于数据注入的连接器时才需要。
- 如需管理对 Google Cloud的访问权限，您必须添加访问权限群组和强制执行群组。
- 管理 Gemini Enterprise 访问权限所需的过滤条件取决于您是否使用 SCIM。如果您使用 SCIM，Gemini Enterprise 会忽略断言或令牌中包含的群组成员资格，因此您无需添加任何特定于 Gemini Enterprise 的群组。如果您不使用 SCIM，则必须包含 Gemini Enterprise 所需的访问权限组和强制执行组。根据您是否计划使用基于数据注入的连接器，您可能还需要添加某些组织和协作群组。
分配：某些 IdP（包括 Microsoft Entra ID）允许您将令牌和断言中的群组成员身份限制为已分配的群组，即您明确分配给信赖方配置的群组。
额外属性过滤条件：如果您使用 Microsoft Entra ID 并已启用额外属性功能，则可以使用
--extra-attributes-filter标志指定过滤条件。Workforce Identity Federation 在请求群组成员身份时，会将此过滤条件传递给 Microsoft Graph API。
如需测试或排查过滤条件，请使用 Google Cloud 控制台中的调试 IdP 令牌工具或启用详细的审核日志记录。
Microsoft Entra ID：使用对象 ID 作为群组标识符
此最佳实践仅适用于您将 Microsoft Entra ID 用作 IdP 的情况。
如果您使用 Microsoft Entra ID，则可用作群组标识符的标识符包括以下内容：
- 对象 ID (
oid) - 电子邮件地址
- 显示名称
在这些选项中，我们建议使用对象 ID (oid) 作为群组标识符，原因如下：
- 所有群组都有一个对象 ID。相比之下，电子邮件地址是一个可选字段，可能仅针对 Microsoft 365 群组填充。
- 对象 ID 是唯一的且不可更改。相比之下，群组的显示名称可以更改，并且可能不是唯一的。
无论您选择哪种标识符，我们都建议您避免应用强制将标识符转换为小写等转换。
管理访问权限
访问权限限制和即时 (JIT) 管理的最佳实践。
最佳做法：
使用 Cloud Identity 用户进行紧急访问。使用 Cloud Identity 进行高权限访问。
使用组织政策限制条件来管理联合。
请勿向池的所有成员授予访问权限。
限制会话时长。
使会话时长与 JIT 访问权限要求保持一致。
使用 Cloud Identity 用户进行紧急访问
为确保能够持续访问您的 Google Cloud 环境，请为每个环境创建紧急访问用户。
当服务配置错误、遭到入侵或无法正常运行时，紧急访问用户可提供对 Google Cloud 环境的访问权限。 紧急访问用户拥有较高的特权。依靠员工身份联合对紧急访问用户进行身份验证会带来以下风险：
- 员工身份池提供方配置中的错误可能会导致您无法访问自己的账号。
- 影响外部 IdP 的服务中断可能会导致您在最需要时无法使用紧急访问用户。
- 如果外部 IdP 遭到入侵，不法分子可以作为紧急访问用户进行身份验证，并获得对 Google Cloud资源的广泛访问权限。
为缓解这些风险，请为紧急访问用户使用 Cloud Identity 或 Google Workspace，即使您为其他用户使用员工身份联合：
- 在 Cloud Identity 中创建紧急访问用户。
- 将这些用户排除在单点登录之外，并允许他们使用用户名和密码进行身份验证。
- 为这些用户注册安全密钥，以确保其账号安全。
如需详细了解紧急访问用户，请参阅确保持续访问 Google Cloud的最佳实践。
使用 Cloud Identity 实现高权限访问
高特权用户对您的 Google Cloud环境拥有广泛的访问权限。此类用户的示例包括：
- 具有 Organization Administrator 角色 (
roles/resourcemanager.organizationAdmin) 的用户 - 拥有 Security Admin 角色 (
roles/iam.securityAdmin) 或类似角色的用户，可以修改 Google Cloud 资源层次结构中重要部分的允许政策
如果您为高权限用户使用员工身份联合，则外部 IdP 中的任何错误配置或安全漏洞都可能会影响 Google Cloud 资源的安全。具体而言，如果外部 IdP 遭到入侵，不法分子可以作为高权限用户进行身份验证，并广泛访问您的 Google Cloud 资源。
为降低这些风险，请为高权限用户使用 Cloud Identity：
- 在 Cloud Identity 中创建高权限用户。
- 为这些用户注册安全密钥，以确保其账号安全。
- 如果您已将 Cloud Identity 与外部 IdP 联合，请为这些用户启用额外的单点登录验证和两步验证。
如果您的 IdP 已强制执行多重身份验证，则其他 SSO 验证似乎是多余的，但如果 IdP 被盗用，此设置可帮助保护用户。额外的 SSO 验证是 Cloud Identity 支持的一项功能，但员工身份联合不支持。
使用组织政策限制条件来管理联合
如果您将 Cloud Identity 用于紧急或高权限访问以外的其他用途，请按服务划分 Cloud Identity 联合和员工身份联合的使用情况。如需强制执行此实践，请使用自定义组织政策限制条件来限制特定项目中允许的主账号类型。
例如，您可以执行以下操作，将员工身份联合限制为仅适用于 Gemini Enterprise：
- 将自定义组织政策限制条件应用于使用
MemberTypeMatches函数的 Gemini Enterprise 项目，以将允许的主账号类型限制为iam.googleapis.com/WorkforcePoolPrincipal和iam.googleapis.com/WorkforcePoolPrincipalSet。以下是员工身份联合使用的主账号类型。 - 对于所有其他项目，请应用一项限制条件，允许所有主账号类型，但
iam.googleapis.com/WorkforcePoolPrincipal和iam.googleapis.com/WorkforcePoolPrincipalSet除外。
使用自定义组织政策限制条件有助于确保一致性，并有助于防止意外使用错误的主账号类型。
请勿向池中的所有成员授予访问权限
员工身份联合支持使用以下格式的通配符主账号标识符：
principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*
此标识符与您的 IdP 允许向Google Cloud进行身份验证的每个用户相匹配。
请勿使用此通配符标识符授予权限。随着 IdP 的用户群不断扩大，使用通配符主账号标识符授予访问权限会导致权限过度授予。
您可以在 IdP 中创建访问权限群组，并使用这些群组来管理资源访问权限。这种方法有助于确保访问权限由有意的群组成员身份控制，而不是由成功的身份验证控制，从而降低过度授权的风险。
限制会话时长
当用户登录时，员工身份联合会启动会话。会话允许用户执行以下操作：
- 使用并切换到控制台（联合）、Gemini Enterprise 或其他支持员工身份联合的门户。
- 使用受 IAP 保护的 Web 应用。
- 获取联合刷新令牌和联合访问令牌，例如通过运行
gcloud auth login来获取。
在发生以下任一情况之前，会话一直有效：
- 会话时长达到员工身份池定义的上限。
- 会话时长达到用户 SAML 断言中
SessionNotOnOrAfter属性定义的限制（如果存在）。 - 用户退出账号。
允许会话在较长时间内保持有效会增加令牌被盗的风险，并可能导致群组成员资格信息过时：
- 如果在 IdP 中撤消权限，用户可能会在比预期更长的时间内保留访问权限。
- 用户可能需要重新进行身份验证并建立新的会话，才能使用新授予的访问权限。
为降低这些风险，请限制会话时长，以便用户每天至少必须重新登录一次。
使会话时长与 JIT 访问权限要求保持一致
为了管理特权访问权限，您的身份提供方可能支持成员可以暂时激活的即时 (JIT) 群组。仅使用即时群组来管理对 Google Cloud 或 Gemini Enterprise 的特权访问权限可能会带来以下风险：
- 延迟激活：如果用户在激活其即时群组成员资格时拥有有效的员工身份联合会话，则成员资格变更会在用户退出并重新登录后生效。或者，如果员工身份池提供方使用 SCIM，则只有在群组成员资格变更得到配置后，相应变更才会生效。
- 延迟撤消：如果群组成员资格过期，用户不会立即失去特权访问权限，直到他们退出并重新登录，或者使用 SCIM 配置群组成员资格变更后，才会失去特权访问权限。根据会话时长，此延迟可能会影响会员资格到期的目的。
为降低这些风险，请将员工身份池会话时长配置为足够短。
监控活动
每当您发现影响Google Cloud中某项资源的可疑活动时，Cloud Audit Logs 便可提供关键信息，帮助您确定该活动发生的时间以及参与的用户。
启用数据访问日志
员工身份联合可以生成日志，让您跟踪登录和令牌交换活动。Security Token Service API 会写入这些日志，其中包括以下 方法：
google.identity.sts.SecurityTokenService.WebSignIngoogle.identity.sts.SecurityTokenService.WebSignOutgoogle.identity.sts.v1.SecurityTokenService.ExchangeTokengoogle.identity.sts.v1beta.SecurityTokenService.ExchangeToken
与登录和令牌交换活动相关的所有日志都归类为数据访问日志，并且默认处于停用状态。如需捕获这些日志，请为整个Google Cloud 组织中的 Security Token Service API 启用数据访问权限日志。如需进一步提高登录日志的详细程度，请启用详细审核日志记录。
如需跟踪其他与身份验证相关的活动，建议您启用并使用以下日志：
- IAM SCIM 审核日志
- Service Account Credentials 审核日志
- Cloud Identity 和 Google Workspace 登录审核日志