简介
本页面提供了安全性方面的最佳做法，在使用 Cloud IAM 时，您应注意这些最佳做法。
本页内容面向精通 Cloud IAM 的用户。这些说明不会教您如何使用 Cloud IAM，刚开始使用 Cloud IAM 的新用户应该从《Cloud IAM 快速入门》开始学习。
最小权限
|
❑
|
|
❑
在以下情况下授予初始角色：
|
|
❑
将您的应用的每个组件视为单独的信任边界。如果您有多个需要不同权限的服务，请为每个服务创建一个单独的服务帐号，然后只为每个服务帐号授予必需的权限。
|
|
❑
请注意，在子资源上设置的政策无法限制对其父项授予的访问权限。请检查在每项资源上授予的政策，并确保您了解层次结构沿用设置。
|
|
❑
在所需的最小范围内授予角色。例如，如果用户只需要发布 Pub/Sub 主题的权限，则可以针对该主题为用户授予发布者角色。
|
|
❑
限制谁可以充当服务帐号。已被授予服务帐号的“服务帐号操作者”角色的用户可以访问该服务帐号有权访问的所有资源。因此，在向用户授予“服务帐号操作者”角色时一定要谨慎。
|
|
❑
限制谁可以在您的项目中创建和管理服务帐号。
|
|
❑
授予项目 IAM 管理员和文件夹 IAM 管理员预定义角色将允许修改 Cloud IAM 政策，但不允许对所有资源进行直接读取、写入和管理。
为成员授予所有者 ( roles/owner) 角色可允许他们访问和修改几乎所有资源，包括修改 Cloud IAM 政策。这种权限可能存在风险。仅在需要或差不多需要通用访问权限时才授予所有者 (roles/owner) 角色。
|
服务帐号和服务帐号密钥
|
❑
您可以使用 Cloud IAM 服务帐号 API 轮替服务帐号密钥。要轮替密钥，只需创建新密钥，让应用改用新密钥，然后删除旧密钥即可。您可以结合使用
serviceAccount.keys.create() 方法和 serviceAccount.keys.delete() 方法来自动执行轮替。
|
|
❑
实施相关流程以管理用户管理的服务帐号密钥。
|
|
❑
请务必小心，不要将加密密钥与服务帐号密钥混淆。加密密钥通常用于加密数据，服务帐号密钥用于安全访问 GCP API。
|
|
❑
不要删除正由运行中的实例使用的服务帐号。否则可能会导致整个应用或应用的一部分失败（如果您事先未切换为使用备用服务帐号的话）。
|
|
❑
使用服务帐号的显示名称跟踪它们的用途以及它们应具有的权限。
|
|
❑
请勿将服务帐号密钥签入源代码中或将其保留在“下载内容”目录中。
|
审核
|
❑
使用 Cloud Audit Logging 日志定期审核 Cloud IAM 政策的更改。
|
|
❑
将审核日志导出至 Cloud Storage，以便更长时间地存储您的日志。
|
|
❑
审核谁能够更改您的项目上的 Cloud IAM 政策。
|
|
❑
使用 Logging 角色限制日志访问权限。
|
|
❑
对您用于导出日志的 GCP 资源应用与日志查看者相同的访问权限政策。
|
|
❑
使用 Cloud Audit Logging 日志定期审核对服务帐号密钥的访问权限。
|
政策管理
|
❑
设置组织级层 Cloud IAM 政策以授予对贵组织中所有项目的访问权限。
|
|
❑
尽可能向 Google 群组（而不是单个用户）授予角色。向 Google 群组中添加成员以及从中移除成员更加容易，而不是更新 Cloud IAM 政策以添加或移除用户。
|
|
❑
如果您需要授予多个角色以允许执行特定任务，请创建一个 Google 群组，为该群组授予这些角色，然后向该群组添加用户。
|
