职责分离是指确保单个主账号不具备完成恶意行为所需的所有必要权限。在 Cloud Key Management Service 中，这样的操作可能是使用密钥来访问和解密该用户没有正当理由访问的数据。
职责分离是大型组织的常用的业务控制手段之一，旨在帮助避免发生安全或隐私事件和错误。 该手段被认为是最佳做法。
在 Cloud KMS 中，职责分离要求严格区分以下角色：
- 密钥管理员：有权管理密钥生命周期（包括创建、删除、轮替和状态更改）的主账号，例如具有 Cloud KMS Admin 角色的用户。
- 密钥用户：获授权可使用密钥（包括加密、解密、签名或签名验证）的主账号，例如具有 Cloud KMS CryptoKey Encrypter/Decrypter 角色的用户。
如果您使用 Cloud KMS 密钥作为客户管理的加密密钥，我们建议您仅授权服务账号使用该密钥进行加密和解密。如需详细了解 CMEK 集成如何处理资源访问权限，请参阅集成 CMEK 的服务如何处理资源访问权限。
为防止绕过职责分离，请勿向主账号授予广泛的基本角色，例如同时包含管理权限和加密权限的所有者 (roles/owner) 角色。您可以使用加密指标信息中心（预览版）来帮助识别不符合职责分离建议的密钥。如需了解详情，请参阅查看加密指标。
如需详细了解如何安全使用 IAM 角色，请参阅安全使用 IAM。
密钥管理模型
Cloud KMS 支持两种主要模型来强制执行职责分离：集中式密钥管理和委托式密钥管理。这些密钥管理模型可以单独使用，也可以组合使用。例如，组织可以选择对生产环境使用集中式密钥管理模型，而对用于开发和测试的较低环境使用专用密钥管理模型。
下表比较了集中式和委托式密钥管理模型，可帮助您确定哪种模型最适合您的需求。
| 区 | 集中式（文件夹级） | 委托（项目级） |
|---|---|---|
| 密钥位置 | 存储在专用密钥项目中，通常按文件夹存储。 | 存储在密钥所保护的资源所在的同一项目中。 |
| 分离方法 | 项目边界：密钥及其保护的资源位于不同的项目中。 | 角色分离：严格的 IAM 角色分离，确保任何主账号都无法同时管理和使用密钥。 |
| 企业文化 | 非常适合拥有专门的中央安全团队或加密团队的高度监管组织。 | 非常适合优先考虑开发者敏捷性和去中心化权限的组织。 |
| 主要驱动因素 | 高度隔离和集中监督。 | 简化了配额管理并减少了运营工作量。 |
委托的密钥管理
对于优先考虑开发者敏捷性并旨在减少中央安全团队与开发者之间“循环”的组织，建议采用委托或“同一项目”密钥管理模型。
在委托模型中，您的 CMEK 和其他密钥与它们保护的资源存储在同一项目中。在委托密钥管理中强制执行职责分离需要严格分离 IAM 角色。
您可以在项目或文件夹中为项目启用 Autokey（预览版），以使用委托的密钥管理模型自动创建密钥。如需了解详情，请参阅为委托的密钥管理启用 Autokey。
集中式密钥管理
对于拥有集中式安全团队的组织，或者需要将密钥材料与应用环境严格隔离的组织，建议采用集中式或“专用项目”密钥管理模型。
在集中式模型中，您的 CMEK 和其他密钥存储在专用密钥项目中，与它们保护的资源分开。通常，这意味着每个文件夹都有自己的专用密钥项目，其中包含用于保护整个文件夹中资源的密钥。此专用密钥项目由中央安全团队管理，该团队在密钥项目中拥有密钥管理权限，但无法访问包含受这些密钥保护的资源的项目。
您可以在文件夹中启用 Autokey，以使用集中式密钥管理模型自动创建密钥。如需了解详情，请参阅设置 Autokey 以实现集中式密钥管理。
自动化合规性监控
Google Cloud 提供以下工具来自动执行和监控安全边界：
- Cloud KMS Autokey：Autokey 支持集中式和委托式（预览版）密钥管理模型。对于这两种情况，它都会自动向所需的服务代理授予密钥使用角色，而不是向请求密钥的人员授予，从而实现职责分离的自动化。Autokey 旨在支持不需要提升密钥创建权限的基础设施即代码流水线。
- Security Command Center：监控 KMS 角色分离发现结果，以检测任何在单个密钥上同时拥有管理权限和加密权限的主账号（包括 Project Owner 或 Google 服务账号）。
CMEK 加密指标：使用此信息中心验证组织内是否符合职责分离实践。