近期，Unit 42的研究人员在Google Workspace的全域委派功能中发现了一个关键安全问题，攻击者将能够利用该安全问题从Google Cloud Platform（GCP）中获取Google Workspace域数据的访问权。

根据研究人员的发现，一个具有必要权限的GCP角色可以为委派用户生成访问令牌，恶意内部攻击者或窃取到凭证数据的外部攻击者将能够使用此访问令牌来冒充 Google Workspace用户，从而授予对目标数据未经授权的访问权限，或直接代表合法用户执行操作。

在这篇文章中，我们将重点讨论Google Workspace全域委派功能中存在的关键安全问题，并分析攻击者利用该问题的相关技术和方法，以及该问题对Google Workspace数据安全的影响。

下图所示的潜在攻击路径为恶意内部攻击者可能执行的操作，他们可以通过利用Google Workspace中被授予全域委派权限的服务帐号来实现这一目的，且内部人员有权为同一GCP项目内的服务帐户生成访问令牌：

启用了全域委派权限后，恶意内部人员可以冒充Google Workspace域中的用户并使用访问令牌来验证API请求。通过在适当的范围利用API访问权限，内部人员可以访问和检索Google Workspace的敏感数据，从而可能会泄露存储在Google Workspace中的电子邮件、文档和其他敏感信息。

如果获得了跟计算引擎实例绑定的GCP服务帐户令牌，则情况将更加严重。此时，攻击者将可能利用全域委派功能来产生更大的影响。如果在同一项目中存在具有全域委派权限的服务帐号，这可能会导致攻击者冒充委派的服务帐号并基于GCP实现横向移动，并获取对目标Google Workspace环境的访问权限。

在深入分析安全风险之前，我们先了解一下跟Google Workspace相关的基础内容。

Google Workspace应用是一组基于云的协作工具，各组织可以使用Google Workspace并通过以下各种工具来提高工作效率和沟通能力：

1. 电子邮件

2. 日历

3. 文件存储与共享

4. 团队沟通

5. 工作流程自动化

6. 安全

7. 管理

Google Workspace提供基于角色的访问控制（RBAC）功能，允许管理员向用户分配特定角色，并根据他们的职责和需求向他们授予预定义的权限集。这些角色包括：

1. 超级管理员

2. 群组管理员

3. 用户管理管理员

每个角色都对组织的Google Workspace环境的不同方面拥有特定的权限和控制权。Google Workspace超级管理员拥有更高的权限和更广泛的域管理职责，包括向服务帐号授予全域委派权限的能力。Google Workspace管理员还可以定义特定于应用程序的权限并限制共享和公开范围，比如说，管理员可以强制执行策略，阻止用户公开共享文件并限制共享选项，以确保文件始终限制在授权范围内。

GCP和Google Workspace之间链接的一种常见场景，就是一个托管在GCP中的应用程序需要跟Google Workspace中的某个服务进行交互时，这些服务包括：

1. Gmail；

2. Calendar；

3. Drive；

4. Docs；

这种集成允许应用程序访问和操作特定于用户的数据、代表用户执行操作或利用Google Workspace的协作和生产力功能。

需要委派的 GCP 服务帐户才能创建与 Google 服务交互、访问 Google API、处理用户数据或代表用户执行操作的应用程序。

服务帐户是GCP中的一种特殊类型帐户，代表非人类实体，例如应用程序或虚拟机。服务账户将允许这些应用程序进行身份验证并于Google API交互。服务帐户与应用程序本身相关联，而不是与单个最终用户相关联。

与用户帐号的不同之处在于，服务帐号不是Google Workspace域的成员。它们不受Google Workspace管理员设置的域策略约束，且如果授予了全域委派权限，也只能访问用户的数据。

全域委派是Google Workspace中的一项功能，它允许GCP服务帐号访问Google Workspace用户的数据，并在特定域内代表这些用户来执行操作。

在使用全域委派功能时，应用程序可以代表Google Workspace域中的用户执行操作，且无需单个用户对应用程序进行身份验证和授权。

只有Google Workspace超级用户才能授权应用程序作为服务帐号代表域中的用户访问数据，这种授权被称为服务账号的“全域委派授权”。

如需使用全域委派功能，需要按照一下步骤设置和执行操作：

下图显示的是全域委派操作流程：

获得全域委派权限后，Google Workspace中的服务账户将能够访问用户数据，并代表用户向Google API发送身份认证请求。具体可使用的功能和可访问的数据需要取决于策略定义的范围。

一旦将全域委派权限授予了GCP服务账户，具有必要权限的GCP角色就可以为委派用户生成访问令牌，恶意内部攻击者或窃取到凭证数据的外部攻击者将能够使用此访问令牌来冒充 Google Workspace用户，从而授予对目标数据未经授权的访问权限，或直接代表合法用户执行操作。

这种情况将导致全域委派权限的敏感程度与GCP平台上管理的权限模型之间不匹配。

Google也在其官方文档中就全域委派功能的授权问题标记了警告声明，Google提到：“只有超级管理员才能管理全域委派功能，并且必须要指定每一个应用程序可以访问的每一个API的范围，并减少授予过多的权限。”

如果不分析GCP和Google Workspace这两个平台的审计日志，就无法了解潜在利用活动的全貌并识别全域委派功能的任何亲啊在滥用情况。其中，服务帐号密钥日志将显示在GCP日志中，而Google密钥生成和API调用执行日志将显示在Google Workspace日志中。

在下图中，显示了一个Cortex Web接口的XQL查询，该查询可以在GCP审计日志中搜索服务账号的密钥创建行为：

等价的Prisma Cloud RQL语句：

下图显示的是查询服务账号授权日志的XQL查询：

等价的Prisma Cloud RQL语句：

下图中，我们尝试检测是谁以及何时给目标服务账号授予了全域委派权限：

等价的Prisma Cloud RQL语句：

下图显示的是Cortex Web接口中触发的“Google Workspace管理员已启用对GCP服务帐户的全域委派，并授予其对敏感范围的访问权限”警报：

为了缓解潜在的安全风险问题，最佳的安全实践是将具备全域委派权限的服务账号设置在GCP层次结构中更高级别的文件夹处，因为GCP层次模型中，访问控制是层次化的。

设置在更高级别的权限和策略并不会自动给低级别文件夹或项目授予访问权限。访问控制不会在层次结构中向下继承，这意味着较低级别的文件夹或项目无法自动访问较高级别的文件夹或项目：

这样一来，也就降低了恶意内部人员利用该安全问题的可能性。除此之外，我们也可以阻止较低级别区域中的实体获取服务账号的访问令牌，确保只有相同或更高级别文件夹或项目中的实体才能生成委派服务帐户的访问令牌。

https://cloud.google.com/iam/docs/understanding-roles

https://developers.google.com/identity/protocols/oauth2/scopes

https://workspace.google.com/blog/product-announcements/introducing-google-workspace

https://developers.google.com/identity/protocols/oauth2/service-account

https://cloud.google.com/iam/docs/service-account-overview

https://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/