安全使用 IAM

简介

本页面提供了安全性方面的最佳做法,在使用 Cloud IAM 时,您应注意这些最佳做法。

本页内容面向精通 Cloud IAM 的用户。这些说明不会教您如何使用 Cloud IAM,刚开始使用的新用户应该从 Cloud IAM 快速入门开始学习。

最小权限

❑  
对于安全性至关重要的资源,请不要授予原初角色、例如(roles/ownerroles/editorroles/viewer),而应该授予预定义角色以允许获取所需的最低访问权限。
❑  
在以下情况下授予原初角色:
  • 当 Google Cloud 服务未提供预定义角色时。有关所有可用预定义角色的列表,请参阅预定义角色表
  • 当您想为项目授予更广泛的权限时。当您在开发或测试环境中授予权限时,往往会发生这种情况。
  • 当您在团队成员不需要精细权限的小型团队中工作时。
❑  
将您的应用的每个组件视为单独的信任边界。如果您有多个需要不同权限的服务,请为每个服务创建一个单独的服务帐号,然后只为每个服务帐号授予必需的权限。
❑  
请注意,子级资源上设置的政策无法限制授予其父级的访问权限。请检查在每项资源上授予的政策,并确保您了解层次结构沿用设置
❑  
在所需的最小范围内授予角色。例如,如果用户只需要发布 Pub/Sub 主题的权限,则可以针对该主题为用户授予 Publisher 角色。
❑  
限制谁可以充当服务帐号。被授予服务帐号 Service Account Actor 角色的用户可以访问该服务帐号有权访问的所有资源。因此,在向用户授予 Service Account Actor 角色时一定要谨慎。
❑  
限制谁可以在您的项目中创建和管理服务帐号。
❑  
授予 Project IAM Admin 和 Folder IAM Admin 预定义角色将允许修改 Cloud IAM 政策,但不允许对所有资源进行直接读取、写入和管理。

为成员授予 Owner (roles/owner) 角色可允许他们访问和修改几乎所有资源,包括修改 Cloud IAM 政策。这种权限可能存在风险。仅在需要或差不多需要通用访问权限时才能授予 Owner (roles/owner) 角色。

服务帐号和服务帐号密钥

❑  
您可以使用 Cloud IAM 服务帐号 API 轮替您的服务帐号密钥。如需轮替密钥,可创建新密钥、让应用改用新密钥,然后删除旧密钥。您可以结合使用 serviceAccount.keys.create() 方法和 serviceAccount.keys.delete() 方法来自动执行轮替。
❑  
实施相关流程以管理用户管理的服务帐号密钥。
❑  
请务必小心,不要将加密密钥与服务帐号密钥混淆。加密密钥通常用于加密数据,而服务帐号密钥用于安全访问 Google Cloud API。
❑  
不要删除运行中的实例正在使用的服务帐号。这可能导致整个或部分应用失败(如果您事先未切换为使用备用服务帐号的话)。
❑  
使用服务帐号的显示名称跟踪它们的用途以及它们应具有的权限。
❑  
请勿将服务帐号密钥签入源代码中或将其保留在“下载内容”目录中。

审核

❑  
使用 Cloud Audit Logs 日志定期审核 Cloud IAM 政策的更改。
❑  
将审核日志导出至 Cloud Storage,以便长时间存储您的日志。
❑  
审核谁能够更改您的项目上的 Cloud IAM 政策。
❑  
使用 Logging 角色限制日志访问权限。
❑  
向您用于导出日志的 Google Cloud 资源应用与日志查看器相同的访问权限政策。
❑  
使用 Cloud Audit Logs 日志定期审核对服务帐号密钥的访问权限。

政策管理

❑  
设置组织级层 Cloud IAM 政策以授予对贵组织中所有项目的访问权限。
❑  
尽可能向 Google 群组(而不是单个用户)授予角色。与更新 Cloud IAM 政策以添加或移除用户相比,向 Google 群组中添加成员以及从中移除成员更简单。
❑  
如果您需要授予多个角色以允许执行特定任务,请创建一个 Google 群组,为该群组授予这些角色,然后向该群组添加用户。