本页面概述了有关在 Google Cloud 资源上使用客户管理的加密密钥 (CMEK) 配置静态加密的推荐做法。本指南面向云架构师和安全团队，概述了在设计 CMEK 架构时必须遵循的建议实践和做出的决策。
本指南假定您已熟悉 Cloud Key Management Service (Cloud KMS) 和客户管理的加密密钥。选择在何处使用 CMEK
Google 建议您在需要为云端数据（无论是您自己的数据还是客户的数据）设置加密边界时使用客户管理的加密密钥。如需了解详情，请参阅客户管理的加密密钥 (CMEK)。
您可以在兼容的服务中使用 CMEK，以帮助您实现以下目标：拥有自己的加密密钥。
控制和管理您的加密密钥，包括选择位置、保护级别、创建、访问权限控制、轮替、使用和销毁。
在 Cloud KMS 中生成密钥材料，或导入在 Google Cloud外部维护的密钥材料。
设置有关密钥必须在何处使用的政策。
在用户离职或需要修正安全事件（加密粉碎）时，有选择地删除受密钥保护的数据。
创建和使用客户独有的密钥，在数据周围建立加密边界。
满足当前或未来的法规要求，即需要实现上述任一目标。
Google 还建议您考虑适用于您业务需求的合规性框架。不同的合规性框架对加密和密钥管理有不同的要求。合规性框架通常会概述加密密钥管理的高级原则和目标，但不会规定实现合规性的特定产品或配置。您有责任了解合规性框架的要求，以及您的控制措施（包括密钥管理）如何帮助您满足这些要求。
如需了解 Google Cloud 服务如何帮助满足不同合规性框架的要求，请参阅以下资源：
选择密钥材料的来源
创建密钥时，您必须允许 Cloud KMS 为您生成密钥材料，或者手动导入在 Google Cloud之外生成的密钥材料。我们建议您尽可能选择在 Cloud KMS 中生成密钥材料。此选项不会有将原始密钥材料暴露在 Cloud KMS 之外的风险，并且会根据您选择的密钥轮替周期自动创建新的密钥版本。如果您必须导入自己的密钥材料，建议您评估以下操作注意事项以及使用自带密钥 (BYOK) 方法的风险：
您能否实现自动化，以持续导入新的密钥版本？这包括 Cloud KMS 设置（用于限制密钥版本只能导入）以及 Cloud KMS 外部的自动化功能（用于持续生成和导入密钥材料）。如果自动化流程未能按预期时间创建新密钥版本，会有什么影响？
您打算如何安全地存储或托管原始密钥材料？
如何降低密钥导入流程泄露原始密钥材料的风险？
如果原始密钥材料保留在 Google Cloud之外，那么重新导入先前销毁的密钥会有什么影响？
自行导入密钥材料的益处是否值得增加运营开销和风险？
选择密钥管理和密钥存储模型
在设计 CMEK 架构时，您必须决定密钥的管理位置和方式。理想情况下，您应选择相互契合的密钥治理模型和密钥存储模型。您选择的治理模式和存储模式会影响强制执行职责分离等关键配置。
关键治理
密钥治理是指组织中哪些人负责管理 Cloud KMS 资源的生命周期，以及维护哪些安全措施来控制 Cloud KMS 的使用方式。密钥治理方法从集中式治理到委托式治理不等：
- 集中式治理：由专门的安全团队或平台团队负责管理整个组织中所有加密密钥的生命周期。这种模式通常受到合规要求严格的高度监管企业的青睐。
- 委托治理：中央安全团队使用安全防护栏来强制执行加密标准，但将密钥生命周期运营的责任委托给其项目中的应用所有者。这些安全措施可以包括使用托管式限制和自定义限制的组织政策，以及 IAM 授权和拒绝政策。这消除了中心运营瓶颈。
密钥存储
密钥存储位置是指在组织内创建 Cloud KMS 资源的位置。密钥存储主要有两种方法：专用项目密钥存储和同项目密钥存储。
专用项目密钥存储：专用密钥项目包含用于多个应用的密钥。通常，每个环境文件夹都有自己的密钥项目。您可以将 Autokey 与专用项目密钥存储搭配使用。 如需详细了解专用项目密钥存储模型，请参阅专用项目密钥存储。
同项目密钥存储：密钥存储在与受保护资源相同的Google Cloud 项目中。有时，这种方法会被描述为“密钥随数据而动”。您可以将 Autokey 与同项目密钥存储搭配使用。 如需详细了解同项目密钥存储模型，请参阅同项目密钥存储。
统一治理和存储
下表提供了一些示例，说明如何将这些治理和存储模型结合起来，以满足不同的组织需求：
| 治理模式 | 专用项目密钥存储 | 同项目密钥存储 |
|---|---|---|
| 集中式治理 | 完全集中式方法 建议的使用场景：有严格的监管要求，必须进行项目边界隔离的组织。 运营影响：设置复杂程度高。需要强大的自动化功能（例如“项目工厂”）来防止开发团队出现运营延迟。 |
受管的所有权 建议使用：需要集中进行安全监督但希望尽可能提高开发者速度的组织。 运营影响：设置复杂度较低。集中式安全功能通过安全防护措施强制执行政策，同时将密钥与其保护的资源同地放置，以便于管理。 |
| 委派的治理 | 不推荐 引入跨项目 IAM 复杂性会违背将密钥管理委托给应用团队的初衷。 |
自治 DevOps 建议使用场景：高速、去中心化的组织，具有强大的 DevOps 文化。 运营影响：设置复杂性极低。应用团队对其项目边界内的资源和密钥拥有完全自主权。 |
在各个环境中使用一致的架构
我们建议您在开发、测试和生产环境中针对任何给定应用使用相同的密钥存储模式。这种架构一致性有助于确保在将 IAM 权限、部署流水线和安全控制部署到生产环境之前，先在较低的环境中对其进行全面测试。如果您为环境选择不同的架构，则会引入配置漂移的风险，从而导致部署失败。
专用项目密钥存储
在专用项目密钥存储模型中，特定环境文件夹（例如“生产环境）的所有密钥都存储在一个集中式共享密钥项目中。密钥管理权限授予给共享的安全团队，该团队通常还负责管理密钥生命周期操作和安全措施，例如 CMEK 组织政策以及 IAM 政策和角色授予。
使用场景
如果您的组织优先考虑对加密密钥进行严格的集中控制（通常是出于监管要求），或者密钥托管在外部 HSM 上，我们建议使用专用项目密钥存储模型。
如果您的组织受合规性框架（例如 PCI DSS 或 BSI C5）的约束，而该框架要求组织设置加密官或密钥保管员，那么此模型是一个不错的选择。通过将应用的所有密钥隔离在一个专用密钥项目中，您可以仅向一小群经过审核的安全管理员授予 Cloud KMS 管理员角色。这样可以限制必须审核的关键管理访问权限政策所适用的项目数量，从而简化合规性审核。
注意事项
这种方法可能会给开发团队带来跨项目的 IAM 复杂性和潜在瓶颈。 为帮助缓解此问题，您可以实现自动化项目配置（有时称为“项目工厂”），以自动执行密钥创建和权限分配。
示例
下图展示了使用专用项目密钥存储模型的生产环境的资源层次结构示例：
- Prod 文件夹包含不同应用的各个文件夹和项目，以及一个 Shared 文件夹。
- 应用项目包含各种不同的资源，例如 Compute Engine 实例和 Cloud Storage 存储桶，但不包含任何 Cloud KMS 密钥。
- Shared 文件夹包含在不同应用之间共享的资源。
- 在“共享”文件夹中，有一个已启用 Cloud KMS API 的专用密钥项目。此项目包含用于保护 Prod 文件夹中资源的所有密钥。
- 组织级和文件夹级安全防护措施（例如组织政策限制和 IAM 政策）可强制执行职责分离和其他实践。
- 开发者可以在单个应用文件夹或项目中拥有 Project Owner 等提升的权限，而无需向其授予密钥项目的权限。
同项目密钥存储
在此模型中，密钥与受其保护的资源存储在同一项目中。即使开发者管理其自有应用的密钥生命周期，核心安全团队通常也会实施密钥管理安全措施。
使用场景
如果您优先考虑开发速度、敏捷性和明确的责任分工，建议使用同一项目密钥存储模型。将密钥与其保护的资源同地放置可使密钥所有权与数据所有权保持一致：密钥随数据而动。此模型有助于将关键管理职责委派给工作负载所有者，他们可以负责遵守 CMEK 组织政策，并在其项目中管理密钥生命周期操作。
注意事项
虽然此模型可为应用团队赋能，但需要对每个项目中的 IAM 角色进行认真审核，以强制执行最小权限原则。对于实施自带密钥 (BYOK) 或使用 Cloud EKM 密钥的组织，此模型可能会增加运维复杂性，因为需要在多个系统之间进行协调，从而产生开销。
示例
下图显示了使用同项目密钥存储模型的生产环境的示例资源层次结构：
- Prod 文件夹包含不同应用的各个文件夹和项目。
- 应用项目包含各种不同的资源，例如 Compute Engine 实例和 Cloud Storage 存储桶，包括用于保护这些资源的任何 Cloud KMS 密钥。
- 组织级和文件夹级安全防护措施（例如组织政策限制条件和 IAM 政策）可强制执行职责分离和其他实践，但强制执行职责分离可能需要更仔细的配置。
- 开发者需要在资源项目上拥有提升的 Cloud KMS 权限，才能创建和管理密钥。
强制执行职责分离
无论采用哪种存储模型，您都必须为加密密钥管理员和加密密钥使用者分别维护不同的主体和权限。为了强制执行最小权限原则和严格的职责分离原则，请根据具体的操作职责授予 IAM 角色。
下表总结了 Cloud KMS 的建议角色分离：
| 责任 | 建议的角色 | 权限摘要 |
|---|---|---|
密钥管理，例如密钥生命周期和治理 这可能包括需要提升权限的人工管理员和 IaC 主账号。 |
Cloud KMS Admin (roles/cloudkms.admin) |
|
资源预配，例如创建受 CMEK 保护的资源 这可以包括没有提升权限的人类开发者和 IaC 主账号。 |
特定于服务的管理员或编辑者角色，例如：
|
在创建资源期间选择密钥。 |
密钥用途，例如加密和解密 请仅向服务代理授予此角色。对于在 CMEK 集成中使用的密钥，人类主体不需要这些权限。 |
Cloud KMS CryptoKey Encrypter/Decrypter
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
使用密钥加密和解密数据。 |
为 IaC 流水线应用最小权限提权
许多组织使用基础设施即代码 (IaC) 流水线（例如 Terraform Runner）自动预配资源。密钥存储的架构方式直接影响这些流水线的安全状况。
如需自动执行 Cloud KMS 密钥预配，必须向您的 IaC 流水线授予高权限的管理角色，以便生成密钥和修改 IAM 政策。如果攻击者破解了 IaC 流水线，他们可能会获得对密钥管理平面的完整管理员控制权。
- 如果您使用专用项目密钥存储，则流水线需要对中央 Cloud KMS 项目具有管理员权限。流水线遭到入侵可能会暴露整个组织的密钥管理平面。
- 如果您使用同项目密钥存储，则流水线只需要对资源项目具有管理员权限。这样会将潜在风险的范围限制在特定应用内，但仍需要在项目中管理提升的权限。
Cloud KMS Autokey 通过将密钥预配委托给安全的 Google 代管式服务代理来解决此风险，因此您可以实现最小权限流水线，以持续预配密钥：
- 低权限流水线：Iac 流水线仅需要低权限的 Cloud KMS Autokey User 角色 (
roles/cloudkms.autokeyUser) 即可通过创建KeyHandle资源来请求密钥。 - 自动预配：实际的密钥创建和 IAM 政策更新由 Google 管理的 Cloud KMS 服务代理在后台处理。
- 风险范围有限：通过最大限度地减少授予流水线的权限，此设计可避免向部署流水线授予提升的密钥创建或安全管理员权限，或分配辅助角色的能力，从而显著降低流水线遭到入侵的风险。
启用 Autokey 的 IaC 流水线需要更宽松的角色，例如 Cloud KMS Autokey Admin (roles/cloudkms.autokeyAdmin)，因此如果您使用 IaC 流水线来管理 Autokey 启用，则还必须对各个 IaC 主账号应用职责分离。
符合推荐的密钥管理实践
Google 针对密钥位置、保护级别、轮替时间表、粒度和权限提供了相关建议。 您可以使用加密指标信息中心查看密钥与这些实践的契合度。您可以使用 Security Command Center 漏洞发现结果来检测职责分离违规情况。
密钥位置
您必须在计划部署 Google Cloud 使用 CMEK 加密的资源的位置创建 Cloud KMS 密钥环。 您必须先执行此操作，然后才能创建密钥。- 区域级和可用区级资源必须使用与资源位于同一区域或
global位置的密钥环和密钥。 - 全局资源必须使用
global位置的密钥环和密钥。
在大多数情况下，这些限制由 Google Cloud服务强制执行。
强制使用区域密钥是成功实施数据区域化策略的一部分。通过强制使用特定区域中的密钥环和密钥，您还可以强制要求资源必须与密钥环的区域一致。
选择密钥粒度策略
粒度是指每个密钥的预期用途的规模和范围。例如，与仅保护一个资源的密钥相比，保护多个资源的密钥的精细度较低。选择合适的密钥粒度策略有助于您遵循 NIST 建议，即每个密钥都有特定用途。
一般来说，我们建议按如下方式使用每个密钥：
- 用于单个 Google Cloud 项目。
- 在单个位置使用 - 例如
us-central1。 - 用于单个服务或产品（例如 BigQuery）。
- 尽可能用于单个资源，例如单个 Cloud Storage 存储桶。
对于大多数组织而言，此策略可在维护许多精细度较高的密钥的开销与使用在许多项目、服务或资源之间共享的精细度较低的密钥的潜在风险之间取得良好的平衡。
遵循这些精细度准则有助于更安全地停用或销毁密钥版本，并限制意外或恶意销毁密钥的风险。
选择密钥的保护级别
创建密钥时，您有责任根据对使用 CMEK 加密的数据和工作负载的要求，为每个密钥选择合适的保护级别。
* 如果您要求将密钥材料存储在 Google Cloud之外，请使用 Cloud EKM 密钥。我们建议采用 EXTERNAL_VPC 保护级别，以提高可用性。
* 如果您不需要将密钥材料存储在 Google Cloud之外，那么我们建议您使用软件支持的密钥。
选择轮播周期
Cloud KMS 支持自动密钥轮替由软件支持和由硬件支持的对称密钥，例如用于 CMEK 的密钥。对于软件支持的密钥，我们建议您使用 90 天的行业标准轮替周期。对于 Cloud HSM 密钥，我们建议采用 365 天的行业标准轮替周期。外部密钥必须按照您选择的时间安排手动轮替。
建议您根据自己的需求评估合适的密钥轮替周期。密钥轮替的频率取决于工作负载的敏感度或合规性要求。例如，为了满足某些合规性标准，可能需要每年至少轮换一次密钥；或者，对于高度敏感的工作负载，您可能会选择更频繁的轮换周期。
频繁轮替密钥有助于限制使用同一密钥版本加密的消息数量，进而帮助降低密钥泄露的风险和后果。
应用最小权限原则
授予 IAM 角色时，请遵循最小权限原则。我们强烈建议您避免使用所有者、编辑者和 Viewer 等基本角色。请改为授予预定义的 Cloud KMS 角色，以降低与过度授权的访问权限相关的安全事件风险。例如，如果某主账号只需要导入密钥材料，请授予 Cloud KMS Importer 角色 (roles/cloudkms.importer)，而不是权限更高的 Cloud KMS Admin 角色 (roles/cloudkms.admin)。
设置运营保护措施
以下部分介绍了您可以实施的控制措施，以帮助降低密钥使用不一致或意外删除或销毁等风险。
强制执行项目安全锁
我们建议您使用安全锁保护项目（预览版），以帮助防止 Cloud KMS 项目及其包含的密钥被意外删除。在强制执行项目安全锁期间，项目会被阻止删除，直到安全锁被移除。对于包含 Cloud KMS 密钥的项目，这可防止意外删除密钥。
需要 CMEK 密钥
我们建议您使用组织政策限制在整个环境中强制执行 CMEK 使用。
使用 constraints/gcp.restrictNonCmekServices 可阻止在未指定 CMEK 密钥的情况下创建特定资源类型的请求。
要求已安排销毁时长不得低于某个最小值
建议您设置预定销毁的最短时长。密钥销毁是一项不可逆的操作，可能会导致数据永久丢失。默认情况下，Cloud KMS 使用的“已安排销毁”时长（有时称为“软删除期限”）为 30 天，之后密钥材料会被永久销毁。这样一来，即使密钥意外遭到销毁，您也有一些时间来恢复密钥。不过，拥有 Cloud KMS 管理员角色的用户可以创建安排销毁时长低至 24 小时的密钥，这可能不足以让您检测到问题并恢复密钥。安排销毁时长只能在创建密钥时设置。
当密钥被安排销毁后，该密钥将无法用于加密操作，并且任何使用该密钥的请求都会失败。在此期间，请监控审核日志，以检查密钥是否正在使用。如果您想再次使用该密钥，必须在安排销毁期限结束之前恢复该密钥。
为确保创建的所有密钥都遵循最短预定销毁时长，我们建议您将组织政策限制条件 constraints/cloudkms.minimumDestroyScheduledDuration 配置为至少 30 天或您偏好的时长。此组织政策可防止用户创建安排销毁时长低于政策中指定的值的密钥。
强制执行允许的 CMEK 保护级别
我们建议您使用组织政策限制，在整个环境中始终如一地强制执行密钥保护级别要求。
使用 constraints/cloudkms.allowedProtectionLevels 可强制要求新密钥、密钥版本和导入作业必须使用您允许的保护级别。
为 CMEK 配置检测控制措施
Google Cloud 为 CMEK 提供各种检测性控制措施。以下部分介绍了如何启用和使用与 Cloud KMS 相关的控制措施。
启用和汇总审核日志记录
我们建议您在集中位置汇总组织中所有资源的 Cloud KMS 管理员活动审核日志。这样，安全团队或审核人员可以一次性查看与创建或修改 Cloud KMS 资源相关的所有活动。如需有关配置汇总日志接收器的指南，请参阅汇总和存储组织的日志。
您可以选择启用数据访问权限日志，以记录使用密钥的操作，包括加密和解密操作。使用 CMEK 时，这可能会生成大量日志，并影响您的费用，因为使用 CMEK 的每个服务中的每项操作都会创建数据访问日志。在启用数据访问日志之前，我们建议您明确定义这些额外日志的用例，并评估日志记录费用会增加多少。
最佳做法摘要
下表总结了本文档中建议的最佳做法。
| 主题 | 任务 |
|---|---|
| Cloud KMS 密钥项目 | 为每个环境使用一个集中式密钥项目。请勿在 Google Cloud资源（密钥保护的资源）所在的同一项目中创建 Cloud KMS 资源。 |
| Cloud KMS 密钥环 | 为要保护 Google Cloud资源的所有位置创建 Cloud KMS 密钥环。 |
| 密钥粒度 | 选择一种密钥粒度模式，以满足您在风险承受能力、费用和运营开销方面的需求。 |
| 保护级别 | 如果您的密钥材料必须存储在 Google Cloud 之外，或者您需要 FIPS 140-2 2 级或 3 级认证，请选择 Cloud EKM。否则，请选择软件密钥。查看有关选择保护级别的指南。 |
| 密钥材料 | 对于托管在 Google Cloud上的密钥材料，请尽可能使用 Google Cloud生成的密钥材料。如果您使用导入的密钥材料，请实施自动化和程序来缓解风险。 |
| 密钥用途和算法 | 所有 CMEK 密钥都必须使用对称 ENCRYPT_DECRYPT 密钥用途和 GOOGLE_SYMMETRIC_ENCRYPTION 算法。 |
| 轮替周期 | 使用自动密钥轮替功能可确保密钥按计划轮替。选择并应用符合您需求的轮换周期，最好每年至少轮换一次。对于敏感工作负载，请更频繁地轮替密钥。 |
| 最小权限 | 授予最受限的预定义角色，以便您的主体完成其任务。请勿使用基本角色。 |
| 职责分离 | 为密钥管理员和使用密钥的主账号分别维护不同的权限。 |
| 项目留置权 | 使用项目安全锁防止关键项目被意外删除。 |
| 需要 CMEK | 使用 constraints/gcp.restrictNonCmekServices 限制条件。 |
| 要求已安排销毁时长不得低于某个最小值 | 使用 constraints/cloudkms.minimumDestroyScheduledDuration 限制条件。 |
| 强制执行允许的 CMEK 保护级别 | 使用 constraints/cloudkms.allowedProtectionLevels 限制条件。 |
| 启用和汇总审核日志记录 | 汇总组织中所有资源的管理员活动审核日志。考虑是否要启用使用密钥的操作的日志记录。 |
| 评估合规性要求 | 查看您的 Cloud KMS 架构，并与您必须遵守的任何合规性要求进行比较。 |