本文档介绍了一些使用 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 中创建任何协作群组,因此最好停用群组企业版,以防止用户在 Cloud Identity 中创建群组。
强制为协作群组添加后缀
如果您使用的是群组企业版,请将其配置为强制使用后缀。如果您允许所有人创建新的群组企业版群组,这一点就尤为重要。
强制使用后缀可防止用户创建名称故意与即将从外部来源预配的访问权限群组或组织群组冲突的群组。这种情况可能会让虚假命名的协作群组的创建者提升其权限。
不要使用协作群组来进行访问权限控制
协作群组的访问权限控制较为宽松,通常没有明确定义的生命周期。这使得它们非常适合协作,但不适合访问权限控制。
如果您严格遵循了协作群组的命名惯例,则可以创建自定义组织政策限制,以防止向协作群组授予 IAM 角色。
同样,如果您在外部预配和管理协作群组,请勿将其预配到 Cloud Identity,否则可能会被滥用于访问权限控制目的。
管理访问权限群组
请遵循以下最佳实践来管理您的访问权限群组。
选择合适的工具来管理访问权限群组
由于访问权限群组由工作负载所有者管理,因此请使用适合自助服务的工具。您的工具应允许用户查找现有的访问权限群组,并强制执行应用了以下控制的安全防护措施:
- 哪些人(哪个组织群组的成员)有资格加入访问权限群组
用户必须满足哪些要求才能加入群组
例如,用户是否需要提供理由?
群组成员资格的有效期上限
是否需要批准成员资格,以及由谁批准
审核跟踪支持
满足这些要求的一种工具是 JIT Groups。
使用访问权限群组对工作职能进行建模并授予对资源的访问权限
为每个工作职能创建一个访问权限群组,并向其授予该工作职能中的用户所需的所有资源的访问权限。然后,您可以将该工作职能中的用户添加到该群组中,向他们授予所需的访问权限,而不是向每个单独的用户授予相同的角色。
您可以使用单个访问权限群组来提供对多个资源(甚至多个项目)的访问权限。不过,请确保每个群组成员都需要您授予群组的访问权限。如果部分用户不需要额外的访问权限,请改为创建新的访问权限群组,并向该群组授予额外的访问权限。
使用访问权限群组处理特定工作负载
重复使用访问权限群组处理多个工作负载会导致过度许可和管理复杂。
为工作负载所有者消除创建访问权限群组的障碍
为了减少重复使用现有访问权限群组的诱惑,请确保访问权限群组易于创建和维护。工作负载所有者在正确命名的支持下,应该能够自助创建访问权限群组。
让用户能够查找和加入访问权限群组
如果用户可以发现现有的访问权限群组并加入所需的群组,那么他们就不太可能积累不必要的权限。如有需要,您可以使用邀请或审批流程来控制哪些人可以加入群组。
默认让会员资格自动到期
要求用户在一段时间后重新加入访问权限群组或延长其成员资格。这种做法可故意增加保持访问权限群组成员身份的阻力,并促使不需要的成员资格失效。这种最佳做法对于实现零持续特权 (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 Groups 等工具在 Cloud Identity 中直接管理访问权限群组。
如果您按名称映射群组,请使用辅助域名
Cloud Identity 按电子邮件地址标识群组,但外部 IdP 中的群组可能没有电子邮件地址。
许多 IdP 都允许您通过从群组名称衍生出伪电子邮件地址(例如使用 my-group@example.com
)来解决此问题。虽然这种方法可行,但如果此电子邮件地址已被其他群组或用户使用,则可能会导致冲突。最糟糕的情况是,恶意行为者可能会利用这种命名冲突来创建安全群组,这些安全群组伪装成另一个审查不严的群组类型。
为避免发生冲突风险,请对您从外部来源(例如 groups.example.com
)预配的群组使用专用辅助域名。
避免向部署流水线授予 Groups Admin 角色
如果您使用 IaC 管理群组(例如 Terraform),则部署流水线必须具有完成其任务所需的权限。Groups Admin 角色授权创建群组,但也允许拥有该角色的任何主账号管理 Cloud Identity 账号中的所有群组。
您可以创建仅具有一项权限(创建群组的权限)的服务账号,然后将该流水线设为其创建的任何群组的所有者,从而限制为流水线赋予的访问权限。这样一来,该流水线就可以管理它创建的任何群组,并创建更多群组,但又无权管理它未创建的任何群组。
以下步骤概述了这种方法:
创建自定义管理员角色,其中仅包含 Admin API 群组创建权限。
为此角色提供一个描述性名称,例如 Group Creator。
创建服务账号并为其分配 Group Creator 角色。
使用流水线的服务账号,并在创建群组时传递
WITH_INITIAL_OWNER
标志。
使用 Cloud Logging 审核和监控您的群组。
借助 Logging,您可以收集、监控和分析群组活动。
审核会员资格变动
添加或移除组织群组、访问权限群组或强制执行群组成员可能会影响该成员可以访问的资源,因此请务必保留用于跟踪这些变动的审核跟踪记录。
要求提供加入访问权限群组的理由
为了让监控数据更有用,请要求用户在加入群组或申请加入群组时提供理由,并记录相应理由。如果有审批流程,请记录有关请求批准人的详细信息。
此额外元数据日后可帮助您分析某人为何被添加到群组中,进而分析他们为何被授予某些资源的访问权限。
启用 Cloud Identity 审核日志共享
将 Cloud Identity 配置为将日志路由到 Cloud Logging,以便您可以像处理其他 Google Cloud 日志一样处理这些审核日志,包括设置提醒或使用外部安全信息和事件管理 (SIEM) 系统。