使用 CMEK 的最佳实践

本页面概述了在 Cloud de Confiance 资源上使用客户管理的加密密钥 (CMEK) 配置静态加密的最佳实践。本指南面向云架构师和安全团队，概述了在设计 CMEK 架构时必须遵循的最佳实践和做出的决策。

本指南假定您已熟悉 Cloud Key Management Service (Cloud KMS) 和客户管理的加密密钥。

决定是否使用 CMEK

如果您需要以下任一功能，建议您使用 CMEK 加密 Cloud de Confiance服务中的静态数据：

• 拥有自己的加密密钥。

• 控制和管理您的加密密钥，包括选择位置、保护级别、创建、访问权限控制、轮替、使用和销毁。

• 在 Cloud KMS 中生成密钥材料，或导入在 Cloud de Confiance外部维护的密钥材料。

• 设置有关密钥必须在何处使用的政策。

• 在员工离职或需要修正安全性事件时，有选择地删除受密钥保护的数据（加密粉碎）。

• 创建和使用客户独有的密钥，从而在数据周围建立加密边界。

• 记录对加密密钥的管理和数据访问权限。

• 满足当前或未来的法规要求，即需要实现上述任一目标。

如果您不需要这些功能，请评估使用 Google Cloud-powered keys 的默认静态加密是否适合您的使用情形。 如果您选择仅使用默认加密，则可以停止阅读本指南。

设计 CMEK 架构

在设计 CMEK 架构时，您必须考虑所用密钥的配置以及这些密钥的管理方式。这些决策会影响您的成本、运营开销以及实现加密粉碎等功能的难易程度。

以下各部分讨论了针对每种设计选择的建议。

为每个环境使用一个集中式 CMEK 密钥项目

我们建议为每个环境文件夹使用一个集中式 CMEK 密钥项目。 请勿在您管理 Cloud KMS 密钥的同一项目中创建使用 CMEK 加密的资源。这种方法有助于防止在不同环境之间共享加密密钥，并有助于实现职责分离。

下图展示了推荐设计中的这些概念：

• 每个环境文件夹都有一个 Cloud KMS 密钥项目，该项目与应用项目分开管理。
• Cloud KMS 密钥环和密钥在 Cloud KMS 密钥项目中预配，这些密钥用于加密应用项目中的资源。
• Identity and Access Management (IAM) 政策应用于项目或文件夹，以实现职责分离。在 Cloud KMS 密钥项目中管理 Cloud KMS 密钥的主账号与在应用项目中使用加密密钥的主账号不是同一主账号。

为每个位置创建 Cloud KMS 密钥环

您必须在部署使用 CMEK 加密的Cloud de Confiance 资源的位置创建 Cloud KMS 密钥环。

• 区域级资源和可用区级资源必须使用与资源位于同一区域或 global 位置的密钥环和 CMEK。
• 全局资源必须使用 global 位置中的密钥环和 CMEK。

强制执行区域密钥是数据区域化策略的一部分。通过强制使用特定区域中的密钥环和密钥，您还可以强制资源必须与密钥环的区域匹配。

对于需要在多个位置实现高可用性或灾难恢复功能的工作负载，您有责任评估在某个区域中 Cloud KMS 变得不可用的情况下，您的工作负载是否具有弹性。例如，在灾难恢复方案中，如果区域 A 不可用，则无法在区域 B 中重新创建使用区域 A 中的 Cloud KMS 密钥加密的 Compute Engine 永久性磁盘。为了降低此方案的风险，您可以规划使用 global 密钥加密资源。

选择密钥粒度策略

粒度是指每个密钥的预期用途的规模和范围。例如，与仅保护一个资源的密钥相比，保护多个资源的密钥的精细度较低。

用于 CMEK 的 Cloud KMS 密钥必须预先完成配置，然后才能创建将使用该密钥加密的资源，例如 Compute Engine 永久性磁盘。 您可以选择为单个资源创建非常精细的键，也可以选择创建不太精细的键，以便在更多资源之间更广泛地重复使用。

一般来说，我们建议采用以下粒度策略：

• 每个密钥都用于保护单个位置（例如 us-central1）中的资源。
• 每个密钥都用于保护单个服务或产品（例如 BigQuery）中的资源。
• 每个密钥都用于保护单个 Cloud de Confiance 项目中的资源。

此建议可能不是贵组织的理想粒度策略。对于大多数组织而言，此策略可在维护许多精细度较高的密钥的开销与使用精细度较低的密钥（在许多项目、服务或资源之间共享）的潜在风险之间取得良好的平衡。

如果您想采用其他粒度策略，请考虑不同模式的以下权衡取舍：

细粒度密钥 - 例如，每个单独的资源对应一个密钥

• 更安全地停用密钥版本：与停用或销毁共享的钥匙相比，停用或销毁用于小范围的密钥版本对其他资源的影响风险更低。这也意味着，与使用低粒度密钥相比，使用高粒度密钥有助于降低密钥被破解的潜在影响。
• 费用：与使用粒度较低的密钥的策略相比，使用精细密钥需要维护更多有效密钥版本。 更精细的密钥粒度需要更多有效的密钥版本，这会产生额外费用。
• 运营开销：使用精细度很高的密钥可能需要管理员付出额外精力，或者需要使用自动化工具来预配大量 Cloud KMS 资源并管理服务代理的访问权限控制，以便他们只能使用适当的密钥。

低精细度密钥 - 例如，每个应用、每个区域和每个环境各有一个密钥：

• 需要谨慎操作才能安全地停用密钥版本：停用或销毁用于广泛范围的密钥版本比停用或销毁高度精细的密钥需要更加谨慎。在停用旧密钥版本之前，您必须确保使用该密钥版本加密的所有资源都已使用新密钥版本安全地重新加密。这也意味着，与使用高精细度密钥相比，使用低精细度密钥可能会因密钥遭到入侵而造成更大的影响。
• 费用：使用粒度较小的密钥需要创建的密钥版本更少，因此费用更低。
• 运营开销：您可以定义和预先配置已知数量的密钥，从而减少确保适当访问权限控制所需的工作量。

选择密钥的保护级别

创建密钥时，您有责任根据您对使用 CMEK 加密的数据和工作负载的要求，为每个密钥选择适当的保护级别。以下问题可帮助您进行评估：

1. 您是否需要任何 CMEK 功能？您可以查看本页面的决定是否使用 CMEK 中列出的功能。

   • 如果符合，请继续回答下一个问题。
   • 如果不是，我们建议使用 S3NS 默认加密。

2. 您是否需要 FIPS 140-2 2 级或 3 级认证，或者需要将密钥材料存储在 Cloud de Confiance之外？

   • 如果是，我们建议使用 CMEK 和 Cloud External Key Manager。
   • 否则，我们建议您将 CMEK 与软件支持的密钥搭配使用。

尽可能使用 Cloud de Confiance生成的密钥材料

本部分不适用于 Cloud EKM 密钥。

创建密钥时，您必须允许 Cloud KMS 为您生成密钥材料，或者手动导入 Cloud de Confiance外部生成的密钥材料。我们建议您尽可能选择生成的选项。此选项不会在 Cloud KMS 外部公开原始密钥材料，并且会根据您选择的密钥轮替周期自动创建新的密钥版本。如果您需要导入自己的密钥材料，建议您评估以下操作注意事项以及使用自带密钥 (BYOK) 方法的风险：

• 您能否实现自动化，以持续导入新的密钥版本？这包括 Cloud KMS 设置（用于限制密钥版本只能导入）以及 Cloud KMS 外部的自动化功能（用于持续生成和导入密钥材料）。如果自动化流程未能按预期时间创建新密钥版本，会有什么影响？
• 您打算如何安全地存储或托管原始密钥材料？
• 如何降低密钥导入流程泄露原始密钥材料的风险？
• 如果原始密钥材料保留在 Cloud de Confiance之外，那么重新导入先前销毁的密钥会有什么影响？
• 自行导入密钥材料的益处是否值得增加运营开销和风险？

根据您的需求选择合适的密钥用途和算法

创建密钥时，您必须选择密钥的用途和底层算法。对于 CMEK 使用场景，只能使用具有对称 ENCRYPT_DECRYPT 用途的密钥。此密钥用途始终使用 GOOGLE_SYMMETRIC_ENCRYPTION 算法，该算法使用 256 位高级加密标准 (AES-256) 密钥（采用伽罗瓦计数器模式 (GCM)），使用 Cloud KMS 内部元数据进行填充。使用 Autokey 时，系统会自动为您应用这些设置。

对于其他使用场景（例如客户端加密功能），请查看可用的密钥用途和算法，以选择最适合您应用场景的选项。

选择轮替周期

建议您根据自己的需求评估合适的密钥轮替周期。密钥轮替的频率取决于工作负载基于敏感度或合规性的要求。例如，为了满足某些合规性标准，可能需要每年至少轮替一次密钥；或者，对于高度敏感的工作负载，您可能会选择更频繁的轮替周期。

轮替对称密钥后，新版本会被标记为主密钥版本，并用于所有新请求以保护信息。旧密钥版本仍可用于解密受相应版本保护的任何之前加密的数据。轮替密钥时，使用先前的密钥版本加密的数据不会自动重新加密。

频繁轮替密钥有助于限制使用同一密钥版本加密的消息数量，进而帮助降低密钥泄露的风险和后果。

应用适当的访问权限控制

我们建议您在规划访问权限控制时考虑最小权限原则和职责分离原则。以下部分将介绍这些建议。

应用最小权限原则

在分配用于管理 CMEK 的权限时，请遵循最小权限原则，授予执行任务所需的最低权限。我们强烈建议您避免使用基本角色。请改为授予预定义的 Cloud KMS 角色，以降低与过度授予的访问权限相关的安全事件风险。

规划职责分离

为加密密钥的管理员和使用者分别维护不同的身份和权限。NIST SP 800-152 定义了加密官员（负责启用和管理加密密钥管理系统的服务）与用户（负责使用这些密钥加密或解密资源）之间的职责分离。

当您使用 CMEK 通过 Cloud de Confiance 服务管理静态加密时，使用加密密钥的 IAM 角色会分配给 Cloud de Confiance 服务的服务代理，而不是分配给个人用户。例如，如需在加密的 Cloud Storage 存储桶中创建对象，用户只需拥有 IAM 角色 roles/storage.objectCreator，而同一项目中的 Cloud Storage 服务代理（例如 service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.iam.gserviceaccount.com）需要拥有 IAM 角色 roles/cloudkms.cryptoKeyEncrypterDecrypter。

下表列出了哪些 IAM 角色通常与哪些工作职能相关联：

IAM 角色	说明	NIST SP 800-152 指定
roles/cloudkms.admin	提供对 Cloud KMS 资源的访问权限，但不提供对受限资源类型和加密操作的访问权限。	加密管理员
roles/cloudkms.cryptoKeyEncrypterDecrypter	仅提供使用 Cloud KMS 资源执行 encrypt 和 decrypt 操作的权限。	加密密钥管理系统用户
roles/cloudkms.viewer	启用 get 和 list 操作。	审核管理员

始终强制执行 CMEK

以下部分介绍了其他控制措施，可帮助降低密钥使用不一致或意外删除/销毁等风险。

强制执行项目安全锁

我们建议您使用安全锁保护项目（预览版），以避免意外删除。在强制执行项目安全锁后，Cloud KMS 密钥项目会被阻止删除，直到安全锁被移除。

需要 CMEK 密钥

我们建议您使用组织政策限制在整个环境中强制执行 CMEK 使用。

使用 constraints/gcp.restrictNonCmekServices 可阻止在未指定 CMEK 密钥的情况下创建特定资源类型的请求。

要求已安排销毁时长不得低于某个最小值

建议您设置最短的预定销毁时长。销毁密钥是一项不可逆的操作，可能会导致数据丢失。默认情况下，Cloud KMS 使用的“已安排销毁”时长（有时称为“软删除期限”）为 30 天，之后密钥材料会被永久销毁，无法恢复。这样一来，即使密钥意外遭到销毁，您也有时间恢复密钥。不过，拥有 Cloud KMS 管理员角色的用户可以创建安排销毁时长低至 24 小时的密钥，这可能不足以让您检测到问题并恢复密钥。预定销毁时长只能在创建密钥期间设置。

当密钥被安排销毁后，该密钥将无法用于加密操作，并且任何使用该密钥的请求都会失败。在此期间，请监控审核日志，以检查密钥是否未使用。 如果您想再次使用该密钥，必须在安排销毁期限结束之前恢复该密钥。

为确保创建的所有密钥都遵循最短预定销毁时长，我们建议您将组织政策限制条件 constraints/cloudkms.minimumDestroyScheduledDuration 配置为至少 30 天或您偏好的时长。此组织政策可防止用户创建安排销毁时长小于政策中指定的值的密钥。

强制执行允许的 CMEK 保护级别

我们建议您使用组织政策限制在整个环境中始终如一地强制执行密钥保护级别要求。

使用 constraints/cloudkms.allowedProtectionLevels 可强制要求新密钥、密钥版本和导入作业必须使用您允许的保护级别。

为 CMEK 配置检测控制措施

Cloud de Confiance 为 CMEK 提供各种检测控制措施。以下部分介绍了如何启用和使用与 Cloud KMS 相关的这些控制机制。

启用和汇总审核日志记录

我们建议您在组织中为所有资源集中汇总 Cloud KMS 管理员活动审核日志（以及所有服务的管理员活动日志）。这样一来，安全团队或审核员就可以一次性查看与创建或修改 Cloud KMS 资源相关的所有活动。如需有关配置汇总日志接收器的指南，请参阅汇总和存储组织的日志。

您可以选择启用数据访问日志，以记录使用密钥的操作，包括加密和解密操作。使用 CMEK 时，这可能会生成大量日志，并影响您的费用，因为使用 CMEK 的每个服务中的每项操作都会创建数据访问日志。在启用数据访问日志之前，我们建议您明确定义额外日志的使用场景，并评估日志记录费用会增加多少。

评估您的合规性要求

不同的合规性框架对加密和密钥管理有不同的要求。合规性框架通常会概述加密密钥管理的高级原则和目标，但不会规定实现合规性的特定产品或配置。您有责任了解合规性框架的要求，以及您的控制措施（包括密钥管理）如何满足这些要求。

如需了解 Cloud de Confiance 服务如何帮助满足不同合规性框架的要求，请参阅以下资源：

• 在 Cloud de Confiance上保护医疗保健数据

最佳做法摘要

下表总结了本文档中建议的最佳做法。

主题	任务
决定是否使用 CMEK	如果您需要使用 CMEK 启用的任何功能，请使用 CMEK。
Cloud KMS 密钥项目	为每个环境使用一个集中式密钥项目。请勿在密钥保护的 Cloud de Confiance资源所在的同一项目中创建 Cloud KMS 资源。
Cloud KMS 密钥环	为要保护 Cloud de Confiance资源的所有位置创建 Cloud KMS 密钥环。
密钥粒度	选择一种密钥粒度模式，以满足您在风险承受能力、费用和运营开销方面的需求。
保护级别	如果您的密钥材料必须存储在 Cloud de Confiance 之外，或者您需要 FIPS 140-2 2 级或 3 级认证，请选择 Cloud EKM。否则，请选择软件密钥。查看有关选择保护级别的指南。
密钥材料	对于托管在 Cloud de Confiance上的密钥材料，请尽可能使用 Cloud de Confiance生成的密钥材料。如果您使用导入的密钥材料，请实施自动化和程序来缓解风险。
密钥用途和算法	所有 CMEK 密钥都必须使用对称 ENCRYPT_DECRYPT 密钥用途和 GOOGLE_SYMMETRIC_ENCRYPTION 算法。
轮替周期	使用自动密钥轮替功能可确保密钥按计划轮替。选择并应用符合您需求的轮换周期，最好每年至少轮换一次。对于敏感工作负载，请更频繁地轮替密钥。
最小权限	授予最受限的预定义角色，以便正文完成其任务。请勿使用基本角色。
职责分离	为密钥管理员和使用密钥的主账号分别维护不同的权限。
项目留置权	使用项目安全锁防止关键项目被意外删除。
需要 CMEK	使用 constraints/gcp.restrictNonCmekServices 限制条件。
要求已安排销毁时长不得低于某个最小值	使用 constraints/cloudkms.minimumDestroyScheduledDuration 约束。
强制执行允许的 CMEK 保护级别	使用 constraints/cloudkms.allowedProtectionLevels 限制条件。
启用和汇总审核日志记录	汇总组织中所有资源的管理员活动审核日志。考虑是否要启用使用密钥的操作的日志记录。
评估合规性要求	查看您的 Cloud KMS 架构，并与您必须遵守的任何合规性要求进行比较。