本页面推荐了安全性方面的最佳做法，在使用 IAM 时，您应该牢记这些最佳做法。
本页内容面向精通 IAM 的用户。这些说明不会教您如何使用 IAM，刚开始使用的新用户应该从 IAM 快速入门开始学习。
最低权限
|
❑
基本角色具有针对所有 Google Cloud 服务的数千项权限。在生产环境中，除非没有替代角色，否则请勿授予基本角色。应授予满足您的需求的最受限的预定义角色或自定义角色。
如果您需要替换基本角色，则可以使用角色建议来确定继而要授予的角色。您还可以使用 Policy Simulator 来确保更改角色不会影响主账号的访问权限。 在以下情况下可以授予基本角色：
|
|
❑
将您的应用的每个组件视为单独的信任边界。如果您有多个需要不同权限的服务，请为每个服务创建一个单独的服务账号，然后只为每个服务账号授予必需的权限。
|
|
❑
切记，子资源的允许政策继承自其父资源的允许政策。举例来说，如果项目的允许政策授予用户管理 Compute Engine 虚拟机 (VM) 实例的权限，则用户可以管理该项目中的任何 Compute Engine 虚拟机，无论您在各虚拟机上设置怎样的允许政策都是如此。
|
|
❑
在所需的最小范围内授予角色。例如，如果用户只需要发布 Pub/Sub 主题的访问权限，则可为该用户授予该主题的 Publisher 角色。
|
|
❑
指定哪些主账号可以充当服务账号。被授予服务账号的 Service Account User 角色的用户可以访问该服务账号有权访问的所有资源。因此，在向用户授予 Service Account User 角色时要谨慎。
|
|
❑
指定具备在您的项目中创建和管理服务账号的访问权限的用户。
|
|
❑
授予 Project IAM Admin 和 Folder IAM Admin 预定义角色将允许修改允许政策，但不允许对所有资源进行直接读取、写入和管理。
为主账号授予 Owner ( roles/owner) 角色可允许他们访问和修改几乎所有资源，包括修改允许政策。这种权限可能存在风险。仅在需要或差不多需要通用访问权限时才授予 Owner 角色。 |
|
❑
|
服务账号
|
❑
采用使用服务账号的最佳实践。确保服务账号具有有限的权限，并防范潜在的安全威胁。
|
|
❑
不要删除运行中的实例正在使用的服务账号。这可能导致整个或部分应用失败（如果您事先未切换为使用备用服务账号的话）。
|
|
❑
使用服务账号的显示名称来跟踪服务账号的用途及其所需的权限。
|
服务账号密钥
|
❑
如果还有其他选项，请避免使用服务账号密钥。
如果服务账号密钥未正确管理，则会带来安全风险。您应该尽可能选择更安全的服务账号密钥替代方案。如果必须使用服务账号密钥进行身份验证，您将负责私钥的安全性以及管理服务账号密钥的最佳实践中所述的其他操作。如果系统阻止您创建服务账号密钥，您的组织可能会停用服务账号密钥创建功能。如需了解详情，请参阅
管理默认安全的组织资源。
|
|
❑
您可以使用 IAM 服务账号 API 轮替您的服务账号密钥。如需轮替密钥，可创建新密钥、让应用改用新密钥、停用旧密钥，并在确定不再需要旧密钥后将其删除。
|
|
❑
实施相关流程以管理用户管理的服务账号密钥。
|
|
❑
请务必小心，不要将加密密钥与服务账号密钥混淆。加密密钥通常用于加密数据，服务账号密钥用于安全访问 Google Cloud API。
|
|
❑
请勿将服务账号密钥签入源代码中或将其保留在“下载内容”目录中。
|
审核
|
❑
使用 Cloud Audit Logs 中的日志定期审核允许政策的更改。
|
|
❑
将审核日志导出至 Cloud Storage，以便长时间存储您的日志。
|
|
❑
审核谁能够更改您的项目上的允许政策。
|
|
❑
使用 Logging 角色管理日志访问权限。
|
|
❑
对您用于路由日志的 Google Cloud 资源应用与日志浏览器相同的访问权限政策。
|
|
❑
使用 Cloud Audit Logs 中的日志定期审核对服务账号密钥的访问权限。
|
政策管理
|
❑
如果主账号需要访问组织中的所有项目，请在组织级层向主账号授予角色。
|
|
❑
尽可能向群组（而不是单个用户）授予角色。更新群组的成员比更新允许政策中的主账号更容易。
|