本文档介绍了使用 Google 群组通过 Identity and Access Management (IAM) 管理对 Google Cloud 资源的访问权限的一些最佳实践。
群组类型
您可以通过以下方式考虑、使用和管理 Google 群组。这些群组类型不是由任何 Google 群组属性设置的。 不过，在整体 Google 群组管理方法中使用这些群组类型有助于您避免一些常见的安全陷阱。
本文档使用以下类型的组：
组织群组
组织群组代表组织结构的子集，通常来自人力资源数据。这些组可能基于部门、报告结构、地理位置或其他组织分组。
当员工加入组织、转移到其他部门或离开组织时，组织群组的成员会发生变化。
企业重组时，组织组的整体结构可能会发生变化。重组可能会导致创建新组或弃用现有组。
一些组织组示例包括
org.marketing-fte、org.finance-all、org.msmith-reports、org.apac-all和org.summer-interns。组织群组通常用于电子邮件通信。
协作组
协作群组代表希望就项目协作或讨论特定主题的工作组、项目成员或用户。
协作群组的结构与任何组织结构都没有关联。它们通常是临时自行创建的。
协作群组的成员资格可以不受限制，允许组织中的任何人加入。或者，协作群组也可以自行管理，这意味着某些成员可以决定将哪些人加入群组。
协作组的示例包括
collab.security-discuss和collab.website-relaunch。协作群组通常用于电子邮件通信。
访问权限群组
访问权限群组的唯一用途是提供访问权限。它们代表工作职能，用于简化执行这些工作职能所需角色的分配。您可以向群组授予角色，而不是向各个主账号授予角色，然后管理群组成员资格。
访问权限群组的结构受贵组织中资源或工作负载的结构影响。部署新资源或工作负载可能需要创建新的访问群组。
访问权限群组的成员资格通常由一个或多个群组所有者控制，他们可以邀请用户加入群组，也可以批准用户加入群组的请求。
一些访问权限组示例包括
access.prod-firewall-admins、access.finance-datamart-viewers和access.billing-dashboard-users。访问权限群组仅用于提供访问权限。它们不会用于通信目的。
违规处置组
违规处置组与访问权限组类似，但用于强制执行访问权限限制政策，而不是提供访问权限。
违规处置团队的结构通常受到合规性要求和组织结构的共同影响。
违规处置组的成员资格通常由一组预定义规则决定，这些规则会考虑用户的审批级别、位置或在组织中的角色。
一些违规处置组示例包括
enforcement.users-in-restricted-locations、enforcement.fedramp-low和enforcement.sso-users。强制执行组仅用于强制执行访问权限限制政策。这些信息不会用于通信目的。
为群组命名，以反映其类型
为帮助您遵循本文档其余部分中的最佳实践，请使用群组名称，以便您通过名称确定群组的类型。您可以使用命名惯例或辅助网域。
命名惯例
以下是可让组类型可见的命名惯例示例：
组织组：
org.GROUP_NAME@example.com。 例如org.finance-all@example.com。协作组：
collab.TEAM_NAME@example.com。 例如collab.msmiths-team@example.com。访问权限群组：
access.JOB_FUNCTION@example.com。例如access.billing-dashboard-users@example.com。违规处置组：
enforcement.GROUP_DESCRIPTION@example.com。 例如enforcement.sso-users@example.com。
采用适合贵组织且受群组管理软件支持的惯例。使用前缀可按功能对群组进行排序，但某些群组管理系统（例如群组企业版）仅支持后缀。如果您无法使用前缀，可以使用后缀或辅助域名。
辅助域名
除了命名惯例之外，您还可以使用辅助网域将组类型嵌入到名称中，例如 access.example.com。作为已验证网域的子网域的辅助网域无需验证，也不必在 DNS 中存在。此外，通过不为辅助网域创建 DNS 邮件交换 (MX) 记录，您可以阻止传入电子邮件发送到不用于通信的群组。
嵌套规则
不同类型的群组对是否允许嵌套（接受群组作为成员）有不同的规则。
组织群组的嵌套规则
最佳实践是嵌套组织群组以反映组织结构图。这种方法意味着，每个员工都包含在一个组中，然后这些组相互包含。例如，org.finance-all 组可能包含 org.finance-us、org.finance-germany 和 org.finance-australia 组作为成员。
您可以将组织群组添加为任何其他群组类型的成员。这比将组织群组的每个成员都添加到另一个群组要容易得多。
请勿将任何其他群组类型添加为组织群组的成员。请勿将访问权限组、违规处置组或协作组用作组织层次结构的一部分。
协作群组的嵌套规则
每个协作团队都应有一组明确定义的政策，用于确定添加成员的方式。如果两个协作群组遵循相同的成员资格政策，则可以嵌套。不过，嵌套具有不同成员资格政策的协作群组可以让不符合某个群组成员资格政策的成员成为成员。在嵌套协作群组之前，请仔细查看会员资格政策。
协作群组可以将组织群组作为成员。
访问权限群组的嵌套规则
通常，您不应嵌套访问权限组。嵌套访问权限组可能会导致难以确定哪些人有权访问哪些资源。此外，嵌套具有不同访问权限政策的访问权限群组可能会让主账号绕过严格的访问权限群组成员资格政策。
访问权限群组可以将组织群组作为成员。
违规处置组的嵌套规则
请勿嵌套违规处置组。嵌套违规处置组可能会导致难以确定主账号被拒绝访问的原因。此外，嵌套具有不同成员资格政策的违规处置组可能会导致某些正文受到意外限制的影响。
违规处置团队可以将组织群组作为成员。
管理组织群组
请遵循以下最佳实践来管理组织群组。
从单一可信来源进行配置
由于组织群组基于人力资源数据，因此最好仅通过人力资源信息系统或外部真相来源（例如外部身份提供程序 [IdP] 或 Sailpoint、Okta 或 Entra ID 等身份治理系统）预配这些群组。
不允许修改群组
请勿手动向组织群组添加或从中移除用户，也不得允许用户从组织群组中移除自己。
避免使用组织群组来提供资源访问权限
组织群组中的所有用户很少需要对资源拥有相同的访问权限级别。因此，向组织群组授予访问权限可能会导致该群组的部分成员拥有超出实际需要的访问权限。
此外，在外部 IdP 中进行更改与更改传播到 Cloud Identity 之间可能会有延迟，具体取决于外部 IdP 与 Cloud Identity 之间的同步频率。这种延迟可能会导致过多权限泛滥。例如，这可能会导致资源所有者向现有群组授予访问权限，而不是创建新群组，即使这些现有群组包含不需要访问资源的用户也是如此。
如果您必须使用组织群组提供访问权限，请将组织群组添加为访问群组的成员，而不是直接授予访问权限，并且仅授予权限有限的角色，例如 Organization Viewer。否则，请使用访问权限群组来提供对资源的访问权限。
不允许在组织群组中添加服务账号和外部用户
请勿在组织群组中添加服务账号，因为它们不代表个人。
外部用户（使用其他 Google Workspace 或 Cloud Identity 账号的用户）通常不属于贵组织，因此没有理由将他们纳入组织群组。如果您将外部员工纳入自己的 Google Workspace 或 Cloud Identity 账号，则他们会被视为内部用户，并且可以纳入您的组织群组。
您可以使用 Cloud Identity 安全群组和群组限制来强制执行这些规则。
管理协作群组
请遵循以下最佳实践来管理协作群组。
使用群组企业版管理协作群组
如果您使用的是 Google Workspace，则可以使用群组企业版管理协作群组。这样，用户就可以使用 Google 群组创建、浏览和加入群组。您必须配置群组企业版，才能允许用户创建新的协作群组。
如果您不使用群组企业版，请将其停用
如果您使用的是 Cloud Identity，但不使用 Google Workspace，则没有理由在 Cloud Identity 中创建任何协作群组，因此最好停用 Google 工作组，以防止用户在 Cloud Identity 中创建群组。
为协作群组强制添加后缀
如果您使用的是群组企业版，请将其配置为强制使用后缀。如果您允许所有人创建新的 Google 群组企业版群组，这一点尤为重要。
强制使用后缀可防止用户创建的群组名称故意与即将从外部来源配置的访问群组或组织群组冲突。在这种情况下，虚假命名的协作群组的创建者可能会提升其权限。
请勿使用协作群组来访问权限控制
协作群组的访问权限控制较为宽松，通常不遵循明确定义的生命周期。这使得它们非常适合协作，但不适合访问权限控制。
如果您严格遵循协作群组的命名惯例，则可以创建自定义组织政策限制，以防止向协作群组授予 IAM 角色。
同样，如果您在外部预配和管理协作群组，请勿将其预配到 Cloud Identity，否则可能会被滥用来进行访问权限控制。
管理访问权限组
请遵循以下最佳实践来管理访问权限群组。
选择合适的工具来管理访问权限组
由于访问权限群组由工作负载所有者管理，因此请使用适合自助服务的工具。您的工具应让用户查找现有访问群组，并强制执行应用以下控制功能的安全边界：
- 哪些人（哪个组织群组的成员）可以加入访问权限群组
用户必须满足哪些要求才能加入群组
例如，用户是否需要提供理由？
群组成员资格的最长有效期
是否必须获得批准才能加入，以及由谁批准
审核跟踪支持
JIT 组就是符合这些要求的工具之一。
使用访问权限群组对工作职能进行建模并授予对资源的访问权限
为每个作业功能创建一个访问权限群组，并向该群组授予该作业功能用户所需的所有资源的访问权限。然后，您可以将该工作职能中的用户添加到群组中，为他们授予所需的访问权限，而无需向每个用户单独授予相同的角色。
您可以使用单个访问群组来提供对多个资源（甚至多个项目）的访问权限。不过，请确保每个群组成员都需要您授予群组的访问权限。如果某些用户不需要额外的访问权限，请改为创建新的访问权限群组，并向该群组授予额外的访问权限。
为特定工作负载使用访问权限群组
为多个工作负载重复使用访问群组会导致权限过多且管理复杂。
消除为工作负载所有者创建访问群组的障碍
为了减少重复使用现有访问权限群组的诱惑，请确保访问权限群组易于创建和维护。工作负载所有者应能够自行创建访问组，并支持正确命名。
让用户能够查找和加入访问权限群组
如果用户能够发现现有的访问权限群组并加入所需的群组，则不太可能积累不需要的权限。如有需要，您可以使用邀请或审批流程来控制哪些人可以加入群组。
默认让会员资格自动到期
要求用户在一定时间后重新加入访问权限群组或续订会员资格。此做法会刻意增加继续保留访问权限群组成员资格的难度，并提供激励措施来让用户放弃不需要的成员资格。此最佳实践对于实现零常规特权 (ZSP) 目标至关重要，对于外部用户而言尤为重要。
不过，请勿将此规则应用于服务账号，因为从访问权限群组中移除服务账号可能会导致服务中断。
为每个群组指定所有者
每个访问群组都应有一个或多个指定的所有者。这有助于培养群组成员的责任感。所有者可以是与该群组关联的工作负载的所有者。
限制访问群组的公开范围
不让访问权限群组显示在群组目录中。（您应该能够在访问权限群组管理工具中找到它们。）此外，请仅允许群组成员查看其他成员。这些做法可防止不良行为者获取有价值的信息。
限制外部成员
由于网域限定共享 (DRS) 政策限制适用于群组，但不适用于群组成员，因此允许外部成员加入的访问群组可能会造成 DRS 漏洞。
您可以使用 Cloud Identity 安全群组和群组限制，允许或禁止访问群组中的外部成员。此外，对于允许外部成员加入的访问权限群组，不妨考虑使用特殊的命名惯例（例如 external.access.GROUP_NAME@example.com）。
管理违规处置组
请遵循以下最佳实践来管理违规处置组。
选择合适的工具来管理违规处置组
由于违规处置组的成员资格取决于组织规则，并用于应用安全限制，因此请勿允许成员退出违规处置组或将自己从违规处置组中移除。
使用动态群组可自动配置违规处置组。如果您使用的是外部 IdP，请使用 IdP 提供的动态群组，然后将其预配到 Cloud Identity。请注意，使用外部 IdP 可能会导致政策更新延迟。
如果您无法使用动态群组，不妨考虑使用 Terraform 或其他基础架构即代码 (IaC) 工具来预配违规处置组。如果您使用 IaC 创建违规处置组，请确保不要向相应组授予过于宽泛的访问权限。
使用强制执行组实现强制访问权限控制和身份验证控制
使用访问权限组强制执行强制性访问权限控制。Google Cloud 通过多项服务和工具支持强制性访问权限控制，包括：
强制执行组还用于应用身份验证控制措施，例如 SAML 配置文件分配或两步验证 (2SV)。
由于这些控件都限制功能或移除访问权限，因此强制执行组是合适的选择。
不允许用户退出违规处置组
允许用户退出强制执行组违背了强制性访问权限控制原则。如需禁止用户退出群组，请使用 Groups Settings API 将 whoCanLeaveGroup 属性设置为 NONE_CAN_LEAVE。
外部 IdP 的最佳实践
如果您使用外部 IdP 进行身份验证，则不妨同时使用该 IdP 预配组织群组和强制执行群组。
避免使用外部来源创建访问权限群组
您可以在外部 IdP 中管理访问权限群组，并将其预配到 Cloud Identity，但这种方法有几个缺点：
配置延迟
在外部 IdP 中进行的更改最长可能需要几个小时才能反映在访问权限群组中。
分歧风险
某些 IdP 不会对群组进行权威控制。例如，它们可能不会在外部删除群组后在 Cloud Identity 中删除该群组，或者会主动删除 Cloud Identity 中存在但 IdP 中不存在的群组成员。
差异可能会导致用户保留不需要的访问权限，并向他们提供有关哪些人拥有访问权限的错误信息。这还可能会增加创建访问权限群组的难度。
为避免这些陷阱，请使用外部 IdP 仅预配组织群组和强制执行群组，并使用 JIT 群组等工具在 Cloud Identity 中直接管理访问权限群组。
如果您要按名称映射群组，请使用辅助网域
Cloud Identity 按电子邮件地址识别群组，但外部 IdP 中的群组可能没有电子邮件地址。
许多 IdP 都允许您通过从群组名称派生伪电子邮件地址（例如使用 my-group@example.com）来解决此问题。这种方法虽然可行，但如果其他群组或用户已在使用此电子邮件地址，则可能会导致冲突。在最糟糕的情况下，恶意行为者可能会利用这种命名冲突创建冒充其他审核较少的群组类型的安全群组。
为避免发生冲突，请为从外部来源预配的群组使用专用辅助域名，例如 groups.example.com。
避免向部署流水线授予“群组管理员”角色
如果您使用 IaC 来管理组（例如 Terraform），则您的部署流水线必须具有完成其任务所需的权限。“群组管理员”角色可授权创建群组，但也允许拥有该角色的任何主账号管理 Cloud Identity 账号中的所有群组。
您可以通过创建一个仅具有一项权限（创建群组）的服务账号，然后将该流水线设为其创建的任何群组的所有者，从而限制向流水线授予的访问权限。这样，该流水线就可以管理其创建的任何组，并创建更多组，而无需授权其管理其未创建的任何组。
以下步骤概述了此方法：
创建自定义管理员角色，其中仅包含 Admin API 群组创建权限。
为此角色提供一个描述性名称，例如“群组创建者”。
创建一个服务账号，并为其分配“群组创建者”角色。
使用流水线的服务账号，并在创建群组时传递
WITH_INITIAL_OWNER标志。
使用 Cloud Logging 审核和监控您的群组。
借助日志记录，您可以收集、监控和分析群组活动。
审核成员资格变更
向组织群组、访问权限群组或违规处置群组添加或移除成员可能会影响成员对哪些资源的访问权限，因此请务必保留用于跟踪这些更改的审核轨迹。
要求加入访问权限群组需提供理由
为了让监控数据更实用，请要求用户在加入群组或请求加入群组时提供理由，并记录理由。如果有审批流程，请记录有关谁批准了请求的详细信息。
这些额外的元数据日后有助于您分析某人为何被添加到群组，以及为何被授予对某些资源的访问权限。
启用 Cloud Identity 审核日志共享
将 Cloud Identity 配置为将日志路由到 Cloud Logging，以便您可以像处理其他 Google Cloud 日志一样处理这些审核日志，包括设置提醒或使用外部安全信息和事件管理 (SIEM) 系统。