员工身份联合会将您的 Google Cloud 组织与外部身份提供方 (IdP) 联合，以实现单点登录 (SSO)。
您可以应用这些最佳实践，以有效使用员工身份联合并最大限度地降低安全风险。
选择合适的架构
以下各部分介绍了选择符合您要求的联合架构的关键因素。
选择联合架构模式
以下四种模式介绍了将 Google Cloud组织与外部 IdP 联合的常见方法：
在联合之前，请考虑每种模式的优势和限制，并选择符合您要求的模式。如需了解详情，请参阅身份联合的架构模式。
按服务划分的分区联合使用情况
通常，我们建议您按服务（而非按用户）对联合身份使用情况进行分区。总体而言，按服务对用量进行分区具有较少的缺点。
为降低复杂性，我们建议您使用 Cloud Identity 或员工身份联合。不过，根据您的要求，您可能需要同时使用这两种模式，如混合模式中所述。
如果您同时使用 Cloud Identity 联合和员工身份联合，则可以通过以下方式划分其使用场景：
按用户划分：将用户划分为两个群组：一个使用员工身份联合，另一个使用 Cloud Identity 联合。
- 优势：每个用户在各项 Google 服务中都只有一个身份，并且只有一种登录方法。
缺点：按用户分区有几个缺点，包括：
管理访问权限群组可能很复杂，因为 IAM 允许政策需要包含主账号类型的组合，并且您无法对 Cloud Identity 和员工身份联合用户使用相同的群组。
来自不同同类群组的用户无法相互分享链接，因为 Google Cloud 控制台、Gemini Enterprise 和其他工具会根据用户的登录方式使用不同的网址。
来自不同同类群组的用户可能可以使用不同的特征集。
按服务划分：配置每项服务（例如Google Cloud 或 Gemini Enterprise），使其仅向员工身份联合用户或 Cloud Identity 用户授予访问权限，但绝不同时向这两类用户授予访问权限。
- 优势：简化管理，并确保不同用户的特征集一致。
- 缺点：可能需要为某些员工分配两个身份，一个使用员工身份联合，另一个使用 Cloud Identity。
我们建议按服务进行划分，特别是将 Gemini Enterprise 和 Gemini Notebook 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 资源的访问权限。此类群组代表工作职能，可简化执行这些工作职能所需的角色分配。
- 组织群组：这些群组表示组织结构中的各个小组，通常来自于人力资源数据。这些群组可以根据部门、隶属结构、地理位置或其他组织分组方式进行建立。
- 协作群组：这些群组代表希望协作处理项目或讨论特定主题的工作组、项目成员或用户，可能用于电子邮件分发。协作群组通常是用户临时自行创建的。
- 强制执行群组：强制执行群组也称为政策群组，用于限制访问权限，而访问权限群组则用于授予访问权限。例如，Principal Access Boundary、拒绝政策或强制执行多重身份验证。 访问权限群组可以允许成员自愿退出群组。 不过，强制执行组的成员资格并非自愿。
您需要联合的群组取决于您使用的以下服务：
- 对于 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 拒绝政策
- Principal Access Boundary
- 组织政策
强制执行群组示例包括 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 无法访问用户在这些群组中的成员资格，则可能无法正确评估用户是否有权访问这些文档。
- 笔记本共享：Gemini Notebook Enterprise 允许用户共享笔记本。与限制仅能与个别用户共享相比，允许用户与协作群组共享笔记本通常更方便。
为确保组织群组和协作群组仅可供 Gemini Enterprise 使用，您可以按如下方式配置 IdP：
- 使用 SCIM 预配组织群组和协作群组及其成员资格。
- 在用于员工身份联合的令牌或断言中排除组织和协作群组成员资格。
管理员工身份池
员工身份池为主账号标识符定义命名空间，并充当联合配置的容器。与用户目录不同，池不会存储有关用户或群组的信息。
每个 IdP 使用一个池
员工身份池是组织级资源，而不是项目级资源。这种设计反映了员工身份池管理整个 Google Cloud 组织的身份验证，而不是单个项目或工作负载。
对于大多数组织，员工身份池的数量应与 IdP 的数量一致：
- 如果您的组织使用单个 IdP 来管理身份验证，请使用单个员工身份池。
- 如果您的组织使用多个 IdP（例如，由于收购），请为每个 IdP 使用一个员工身份池。
限制员工身份池的数量有助于确保以下事项：
- 将新工作负载添加到 Google Cloud时，您无需创建或修改员工身份池。
- 您可以使用 IAM 来控制 Google Cloud 中的哪些项目和资源可供个人用户访问。
选择一个唯一且有意义的池名称
为了使主账号标识符具有全局唯一性，员工身份会将员工身份池名称编码到主账号标识符中。为员工身份池选择名称时，请考虑以下限制：
- 唯一性：选择一个在 Google Cloud 中独一无二且未被其他组织占用的名称。
- 不可变性：您无法更改员工身份池名称。选择一个长期有意义的名称，避免使用临时计划名称。
- 用户体验：根据您的登录配置，用户可能需要在登录期间输入池名称。选择一个简短好记的名称。
将池视为高特权资源
员工身份池和提供方决定了用户登录的方式，并控制如何从外部 IdP 派生身份和群组成员资格。由于这些组件控制身份验证逻辑，因此它们对 Google Cloud 组织的安全至关重要。这些组件遭到入侵可能会使不法分子能够执行欺骗攻击。
为了实施欺骗攻击，不法分子可能会尝试以下操作：
- 修改特性映射：更改特性映射可能会让不法分子以他人身份进行身份验证，并获得未经授权的特权访问权限。
- 添加恶意提供方：添加提供方可能会让不法分子绕过您组织的 IdP，并使用他们控制的其他 IdP 进行身份验证。
员工身份池和提供方是安全关键型资源，需要以下保护：
- 限制对非联合用户的访问权限：将管理员权限限制为少数 Cloud Identity 或 Google Workspace 用户，包括至少一个紧急访问用户。
- 保护管理员用户：要求所有管理员和紧急访问用户进行两步验证。
- 即时访问：使用 Privileged Access Manager (PAM) 授予即时管理员权限，而不是授予永久访问权限。
将联合身份验证扩展到合作伙伴时，请考虑风险
使用员工身份联合将 Google Cloud 与外部 IdP 联合，可建立信任关系。通过使用联合，您可以依靠外部 IdP 执行以下操作：
- 执行符合您安全要求的多重身份验证 (MFA)。
- 对用户身份和群组成员资格做出准确断言。
- 遵循身份治理流程，确保及时将用户离职，并确保群组成员资格准确反映当前角色。
员工身份联合提供有限的机制来验证外部 IdP 做出的断言。具体而言，员工身份联合不支持与 Cloud Identity 相同的单点登录后 MFA。
在使用员工身份联合允许外部合作伙伴或承包商访问您的 Google Cloud 资源之前，请确定此信任级别是否合适。请勿使用员工身份联合来授予合作伙伴访问权限，除非您信任合作伙伴及其 IdP 能够始终如一地满足您的安全标准。
监控令牌交换配额
员工身份联合令牌交换受配额指标 sts.googleapis.com/workforce_requests 的限制，该指标默认为每分钟 1,000 个请求，并按组织强制执行。该配额由组织中的每个员工池、提供方、用户和工作负载共享。单独的池不会获得单独的配额。如需了解当前值，请参阅配额和限制。
由于配额是组织范围内的，因此单个高频客户端可能会耗尽配额，并导致组织中的所有其他用户（包括管理员）出现 429 RESOURCE_EXHAUSTED 错误。
我们建议您执行以下操作：
- 为人工登录预留员工身份联合。将自动化工作负载、CI/CD 流水线和代理路由到工作负载身份联合，该服务专为机器到机器的流量而设计。
- 在受到限制时退避。使用指数退避算法和抖动重试
429 RESOURCE_EXHAUSTED响应。紧密的重试循环会加深饱和度，并延长组织中每个人的服务中断时间。 - 提前申请更多配额。如果贵组织有超出默认值的合法、持续需求，请申请增加配额，而不是在配额上限边缘运行。
- 在达到配额上限之前发出提醒。创建一个 Cloud Monitoring 提醒，当用量达到上限的 80% 时触发，方法是将
serviceruntime.googleapis.com/quota/rate/net_usage与serviceruntime.googleapis.com/quota/limit进行比较，并过滤到metric.label.quota_metric="sts.googleapis.com/workforce_requests"。 - 维护紧急访问权限。确保至少有一位管理员可以在不使用员工身份联合的情况下访问您的组织，以便在令牌交换受到限制时，您仍然可以采取行动。
如需查看当前用量和限制，请前往 Google Cloud 控制台中的“配额”页面，选择您的组织作为资源，然后过滤 Workforce Pool token exchange requests。
管理员工身份池提供方
员工身份池提供方定义了与外部 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 |
| Gemini Notebook 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：Gemini Notebook Enterprise 项目编号。
每个池使用单个提供方以避免主题冲突
您可以使用员工身份联合向员工池添加多个提供方。在迁移期间，添加第二个提供方非常有用，因为您可以暂时允许用户使用不同的 IdP 进行身份验证。除了临时情况之外，请避免使用多个提供商，原因如下：
- 主题冲突：使用多个提供方会带来主题冲突的风险。在此类冲突中，一个提供方的
google.subject属性映射会返回与另一个提供方相同的值。这种冲突会将多个外部身份映射到同一个 IAM 主体，导致它们在 Cloud Audit Logs 中无法区分。 - IAP 兼容性：IAP 要求员工身份池具有单个提供方，以便自动将未经身份验证的用户重定向到 IdP。如果您添加了其他提供方，IAP 将无法对用户进行身份验证。
如果您需要与多个提供方联合，请创建多个员工池，并为每个池配置一个提供方。
为 Google Cloud 控制台和 Gemini Enterprise 使用相同的池和提供方
如果您同时为 Gemini Enterprise 和 Google Cloud使用员工身份联合，请使用单个提供方，以确保用户可以同时访问这两项服务，而无需重新登录。如果您使用具有不同属性映射的单独提供方，则用户可能会遇到以下情况：他们对资源的访问权限因登录的提供方而异。
使用特定于租户的颁发者 URI
配置提供方时，您需要指定一个颁发者 URI 来唯一标识您的 IdP。不过，根据您的 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 版中已弃用，因为它容易受到令牌泄露和注入攻击。使用授权代码流程有助于降低令牌被拦截的风险。
管理用户
您可以使用员工身份联合管理用户。员工身份联合通过执行以下步骤，从用户的令牌或断言中派生用户的主账号标识符：
- 通过应用
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标志指定过滤条件。员工身份联合在请求群组成员资格时会将此过滤条件传递给 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 被盗用，此设置可帮助保护用户。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。
会话在发生以下任一情况之前始终有效：
如果允许会话在较长时间内保持有效，则会增加令牌被盗的风险，并可能导致群组成员资格信息过时：
- 如果权限在 IdP 中被撤消，用户保留访问权限的时间可能会超出预期。
- 用户可能需要重新进行身份验证并建立新会话，才能行使新授予的访问权限。
为了降低这些风险，请限制会话时长，以便用户每天至少重新登录一次。
使会话时长与 JIT 访问权限要求保持一致
为了管理特权访问权限，您的 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 启用数据访问日志。如需进一步提高登录日志的详细程度，请启用详细审核日志记录。
如需跟踪其他与身份验证相关的活动，我们建议您启用并使用以下日志：
后续步骤
- 查看员工身份联合概览。
- 了解如何管理池和提供方。
- 了解如何撤消员工身份联合用户会话。