本页面概述了在 Google Cloud 资源上使用客户管理的加密密钥 (CMEK) 配置静态加密的最佳实践。本指南面向云架构师和安全团队，概述了在设计 CMEK 架构时必须遵循的最佳实践和做出的决策。
本指南假定您已熟悉 Cloud Key Management Service (Cloud KMS) 和客户管理的加密密钥，并且已阅读 Cloud KMS 深入分析。初步决定
本页上的建议适用于使用 CMEK 加密数据的客户。如果您不确定在安全策略中是使用手动创建的 CMEK 还是自动创建的 CMEK，本部分将针对这些初步决策提供指导。
决定是否使用 CMEK
如果您需要以下任一功能，建议您使用 CMEK 加密 Google Cloud服务中的静态数据：
拥有自己的加密密钥。
控制和管理加密密钥，包括选择位置、保护级别、创建、访问权限控制、轮替、使用和销毁。
在 Cloud KMS 中生成密钥材料，或导入在 Google Cloud之外维护的密钥材料。
设置有关密钥必须在何处使用的政策。
在用户离职或需要修正安全事件（加密粉碎）时，有选择地删除受密钥保护的数据。
创建和使用客户独有的密钥，在数据周围建立加密边界。
满足当前或未来的法规要求，即需要实现上述任一目标。
选择手动或自动密钥创建
本指南概述了在自行预配 CMEK 时必须做出的决策的最佳实践。Cloud KMS Autokey 会为您做出其中一些决策，并自动执行本指南中的许多建议。与自行预配密钥相比，使用 Autokey 更简单，如果 Autokey 创建的密钥满足您的所有要求，建议您选择使用 Autokey。
Autokey 会为您预配 CMEK。由 Autokey 预配的 CMEK 具有以下特征：
- 保护级别：HSM。
- 算法：AES-256 GCM。
轮替周期：一年。
Autokey 创建密钥后，Cloud KMS 管理员可以修改轮替周期，使其不再是默认值。
- 职责分离：
- 系统会自动为该服务的服务账号授予密钥的加密和解密权限。
- Cloud KMS 管理员权限会像往常一样应用于 Autokey 创建的密钥。Cloud KMS 管理员可以查看、更新、启用或停用以及销毁由 Autokey 创建的密钥。Cloud KMS 管理员不会获得加密和解密权限。
- Autokey 开发者只能请求创建和分配密钥。他们无法查看或管理钥匙。
- 密钥专属性或精细度：由 Autokey 创建的密钥的精细度因资源类型而异。如需了解有关密钥粒度的服务特定详细信息，请参阅兼容的服务。
位置：Autokey 会在要保护的资源所在的同一位置创建密钥。
如果您需要在 Cloud HSM 不可用的位置创建受 CMEK 保护的资源，则必须手动创建 CMEK。
- 密钥版本状态：使用 Autokey 请求的新创建的密钥会以启用状态创建为主密钥版本。
- 密钥环命名：Autokey 创建的所有密钥都将在所选位置的 Autokey 项目中名为
autokey的密钥环中创建。当 Autokey 开发者请求指定位置的第一个密钥时，系统会在 Autokey 项目中创建密钥环。 - 密钥命名：由 Autokey 创建的密钥遵循以下命名规范：
PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX - 密钥导出：与所有 Cloud KMS 密钥一样，Autokey 创建的密钥无法导出。
- 密钥跟踪：与密钥跟踪兼容的集成 CMEK 的服务中使用的所有 Cloud KMS 密钥一样，Autokey 创建的密钥也会在 Cloud KMS 信息中心内进行跟踪。
如果您有 Autokey 创建的密钥无法满足的要求（例如保护级别不是 HSM 或服务与 Autokey 不兼容），建议您使用手动创建的 CMEK，而不是 Autokey。
设计 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 加密的Google Cloud 资源的位置创建 Cloud KMS 密钥环。
- 区域级资源和可用区级资源必须使用与资源位于同一区域或
global位置的密钥环和 CMEK。 单区域资源和可用区级资源不能使用global以外的多区域密钥环。 - 多区域资源（例如
us多区域中的 BigQuery 数据集）必须使用位于同一多区域或双区域中的密钥环和 CMEK。多区域资源无法使用区域级密钥环。 - 全局资源必须使用
global位置中的密钥环和 CMEK。
强制执行区域密钥是数据区域化策略的一部分。通过强制使用特定区域中的密钥环和密钥，您还可以强制资源必须与密钥环的区域匹配。 如需有关数据驻留的指南，请参阅控制数据驻留。
对于需要在多个位置实现高可用性或灾难恢复功能的工作负载，您有责任评估在 Cloud KMS 在特定区域变得不可用的情况下，您的工作负载是否具有弹性。例如，在灾难恢复方案中，如果区域 A 不可用，则无法在区域 B 中重新创建使用区域 A 中的 Cloud KMS 密钥加密的 Compute Engine 永久性磁盘。为了降低此方案的风险，您可以规划使用 global 密钥加密资源。
如需了解详情，请参阅选择最佳位置类型。
如果您使用 Cloud KMS Autokey，系统会在您保护的资源所在的同一位置为您创建密钥环。
选择密钥粒度策略
粒度是指每个密钥的预期用途的规模和范围。例如，与仅保护一个资源的密钥相比，保护多个资源的密钥的精细度较低。
对于 CMEK，必须预先手动配置 Cloud KMS 密钥，然后才能创建将使用该密钥加密的资源，例如 Compute Engine 永久性磁盘。 您可以选择为单个资源创建非常精细的密钥，也可以选择创建不太精细的密钥，以便在更多资源之间更广泛地重复使用。
一般来说，我们建议采用以下粒度策略：
- 每个密钥都用于保护单个位置（例如
us-central1）中的资源。 - 每个密钥都用于保护单个服务或产品（例如 BigQuery）中的资源。
- 每个密钥都用于保护单个 Google Cloud 项目中的资源。
此建议可能不是贵组织的理想粒度策略。对于大多数组织而言，此策略可在维护许多精细度较高的密钥的开销与使用在许多项目、服务或资源之间共享的精细度较低的密钥的潜在风险之间取得良好的平衡。
使用 Cloud KMS Autokey 创建的密钥遵循此建议。
如果您想采用其他粒度策略，请考虑不同模式的以下权衡取舍：
细粒度密钥 - 例如，每个单独的资源对应一个密钥
- 更安全地停用密钥版本：与停用或销毁共享密钥相比，停用或销毁用于小范围的密钥版本对其他资源的影响风险更低。这也意味着，与使用低粒度密钥相比，使用高粒度密钥有助于降低密钥被破解的潜在影响。
- 费用：与使用粒度较低的密钥的策略相比，使用精细密钥需要维护更多有效密钥版本。 由于 Cloud KMS 定价取决于有效密钥版本的数量，因此选择更高的密钥粒度会导致更高的费用。
- 运营开销：使用精细度很高的密钥可能需要管理员付出额外精力或使用其他自动化工具来预配大量 Cloud KMS 资源，并管理服务代理的访问权限，以便他们只能使用适当的密钥。如果您需要细粒度的密钥，Autokey 可能是自动执行密钥配置的理想选择。如需详细了解每项服务的 Autokey 密钥粒度，请参阅兼容的服务。
低精细度密钥 - 例如，每个应用、每个区域和每个环境各有一个密钥：
- 需要谨慎操作才能安全地停用密钥版本：停用或销毁用于广泛范围的密钥版本比停用或销毁精细度高的密钥需要更加谨慎。在停用旧密钥版本之前，您必须确保使用该密钥版本加密的所有资源都已使用新密钥版本安全地重新加密。 对于许多资源类型，您可以查看密钥使用情况，以帮助确定密钥的使用位置。 这也意味着，与使用高精细度密钥相比，使用低精细度密钥可能会增加密钥遭到入侵的影响。
- 费用：使用粒度较小的密钥需要创建的密钥版本较少，而 Cloud KMS 价格取决于有效密钥版本的数量。
- 运营开销：您可以定义和预先配置已知数量的密钥，从而减少确保适当访问权限控制所需的工作量。
选择密钥的保护级别
创建密钥时，您有责任根据您对使用 CMEK 加密的数据和工作负载的要求，为每个密钥选择适当的保护级别。以下问题可帮助您进行评估：
您是否需要任何 CMEK 功能？您可以查看本页面的决定是否使用 CMEK 中列出的功能。
- 如果符合，请继续回答下一个问题。
- 如果不是，我们建议使用Google 默认加密。
您是否要求密钥材料保留在硬件安全模块 (HSM) 的物理边界内？
- 如果符合，请继续回答下一个问题。
- 如果不是，我们建议您将 CMEK 与软件支持的密钥搭配使用。
您是否要求将密钥材料存储在 Google Cloud之外？
- 如果是，我们建议使用 CMEK 和 Cloud External Key Manager。
- 如果不是，我们建议使用 Cloud HSM（由硬件支持的密钥）的 CMEK。
尽可能使用 Google Cloud生成的密钥材料
本部分不适用于 Cloud EKM 密钥。
创建密钥时，您必须允许 Cloud KMS 为您生成密钥材料，或者手动导入 Google Cloud外部生成的密钥材料。如果可以，我们建议您选择生成的选项。此选项不会在 Cloud KMS 外部公开原始密钥材料，并且会根据您选择的密钥轮替周期自动创建新的密钥版本。如果您需要导入自己的密钥材料，建议您评估以下操作注意事项以及使用自带密钥 (BYOK) 方法的风险：
- 您能否实现自动化，以便持续导入新的密钥版本？这包括 Cloud KMS 设置（用于将密钥版本限制为仅导入）以及 Cloud KMS 外部的自动化（用于持续生成和导入密钥材料）。如果自动化流程未能按预期时间创建新密钥版本，会有什么影响？
- 您打算如何安全地存储或托管原始密钥材料？
- 如何降低密钥导入流程泄露原始密钥材料的风险？
- 如果原始密钥材料保留在 Google Cloud之外，那么重新导入先前销毁的密钥会有什么影响？
- 自行导入密钥材料的益处是否值得增加运营开销和风险？
根据您的需求选择合适的密钥用途和算法
创建密钥时，您必须选择密钥的用途和底层算法。对于 CMEK 使用场景，只能使用具有对称 ENCRYPT_DECRYPT 用途的密钥。此密钥用途始终使用 GOOGLE_SYMMETRIC_ENCRYPTION 算法，该算法使用 256 位高级加密标准 (AES-256) 密钥（采用伽罗瓦计数器模式 (GCM)），并使用 Cloud KMS 内部元数据进行填充。使用 Autokey 时，系统会自动为您应用这些设置。
对于其他使用场景（例如客户端加密功能，请查看可用的密钥用途和算法，以选择最适合您使用场景的选项。
选择轮替周期
建议您根据自己的需求评估合适的密钥轮换周期。密钥轮替的频率取决于工作负载的敏感度或合规性要求。例如，为了满足某些合规性标准，可能需要每年至少轮换一次密钥；或者，对于高度敏感的工作负载，您可能会选择更频繁的轮换周期。
轮替对称密钥后，新版本会被标记为主密钥版本，并用于所有新请求以保护信息。旧密钥版本仍可用于解密之前使用该版本加密的任何数据。轮替密钥时，使用先前的密钥版本加密的数据不会自动重新加密。
频繁轮替密钥有助于限制使用同一密钥版本加密的消息数量，进而帮助降低密钥泄露的风险和后果。
如果您使用 Autokey，系统会使用一年的默认密钥轮换周期来创建密钥。您可以在密钥创建后更改密钥的轮换周期。应用适当的访问权限控制
我们建议您在规划访问权限控制时考虑最小权限原则和职责分离原则。以下部分将介绍这些建议。
应用最小权限原则
在分配用于管理 CMEK 的权限时，请遵循最小权限原则，授予执行任务所需的最低权限。我们强烈建议您避免使用基本角色。请改为授予预定义的 Cloud KMS 角色，以降低与过度授予的访问权限相关的安全事件风险。
Security Command Center IAM 漏洞发现结果可以自动检测到违反此原则的行为和相关问题。规划职责分离
为加密密钥的管理员和使用者分别维护不同的身份和权限。NIST SP 800-152 定义了加密官员（负责启用和管理加密密钥管理系统的服务）与用户（负责使用这些密钥加密或解密资源）之间的职责分离。
当您使用 CMEK 通过 Google Cloud 服务管理静态数据加密时，使用加密密钥的 IAM 角色会分配给 Google Cloud 服务的服务代理，而不是分配给个人用户。例如，如需在加密的 Cloud Storage 存储桶中创建对象，用户只需拥有 IAM 角色 roles/storage.objectCreator，而同一项目中的 Cloud Storage 服务代理（例如 service-PROJECT_NUMBER@gs-project-accounts.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 配置检测控制措施
Google Cloud 为 CMEK 提供各种检测控制措施。以下部分介绍了如何启用和使用与 Cloud KMS 相关的这些控制机制。
启用并汇总审核日志记录
我们建议您在组织中为所有资源集中汇总 Cloud KMS 管理员活动审核日志（以及所有服务的管理员活动日志）。这样一来，安全团队或审核员就可以一次性查看与创建或修改 Cloud KMS 资源相关的所有活动。如需有关配置汇总日志接收器的指南，请参阅汇总和存储组织的日志。
您可以选择启用数据访问日志，以记录使用密钥的操作，包括加密和解密操作。使用 CMEK 时，这可能会生成大量日志，并影响您的费用，因为使用 CMEK 的每个服务中的每项操作都会创建数据访问日志。在启用数据访问日志之前，我们建议您明确定义额外日志的使用场景，并评估日志记录费用会增加多少。
监控密钥使用情况
您可以使用 Cloud KMS 清单 API 查看密钥使用情况，以便识别组织中依赖于 Cloud KMS 密钥并受其保护的 Google Cloud 资源。您可以使用此信息中心来监控密钥版本及其保护的相应资源的状态、使用情况和可用性。该信息中心还会识别因密钥已停用或已销毁而无法访问的数据，以便您采取相应措施，例如清除无法访问的数据或重新启用密钥。 您可以将 Cloud Monitoring 与 Cloud KMS 搭配使用，以便为关键事件（例如安排销毁密钥）设置提醒。 Cloud Monitoring 可让您有机会对执行此类操作的原因进行初步诊断，并触发可选的下游流程，以便在需要时恢复密钥。我们建议您制定运营计划，以自动检测您认为重要的事件，并定期查看密钥使用情况信息中心。
针对 Cloud KMS 漏洞发现结果启用 Security Command Center
Security Command Center 会生成漏洞发现结果，突出显示与 Cloud KMS 和其他资源相关的配置错误。我们建议您启用 Security Command Center，并将这些发现结果集成到现有的安全运营中。这些发现包括公开可访问的 Cloud KMS 密钥、具有过于宽松的 owner 角色的 Cloud KMS 项目，或违反职责分离原则的 IAM 角色等问题。
评估您的合规性要求
不同的合规性框架对加密和密钥管理有不同的要求。合规性框架通常会概述加密密钥管理的高级原则和目标，但不会规定实现合规性的特定产品或配置。您有责任了解合规性框架的要求，以及您的控制措施（包括密钥管理）如何满足这些要求。
如需了解有关 Google Cloud 服务如何帮助满足不同合规性框架的要求的指南，请参阅以下资源：最佳做法摘要
下表总结了本文档中建议的最佳做法。
| 主题 | 任务 |
|---|---|
| 决定是否使用 CMEK | 如果您需要使用 CMEK 启用的任何功能，请使用 CMEK。 |
| 选择手动或自动密钥创建 | 如果 Autokey 创建的密钥的特征符合您的需求，请使用 Cloud KMS Autokey。 |
| Cloud KMS 密钥项目 | 为每个环境使用一个集中式密钥项目。请勿在与密钥所保护的 Google Cloud资源相同的项目中创建 Cloud KMS 资源。 |
| Cloud KMS 密钥环 | 为要保护 Google Cloud资源的所有位置创建 Cloud KMS 密钥环。 |
| 密钥粒度 | 选择符合您需求的密钥粒度模式，或使用 Autokey 自动为每项服务预配建议粒度的密钥。 |
| 保护级别 | 如果您的密钥材料必须存储在 Google Cloud之外，请选择 Cloud EKM。如果您的密钥材料可以托管在 Google Cloud拥有的硬件安全模块 (HSM) 上，请选择 Cloud HSM。如果您的需求不需要 Cloud HSM 或 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 清单 API 或 Google Cloud 控制台了解密钥使用情况。（可选）使用 Cloud Monitoring 为敏感操作（例如安排销毁密钥）设置提醒。 |
| 为 Cloud KMS 启用 Security Command Center | 查看漏洞发现结果，并将查看漏洞发现结果纳入安全运维流程。 |
| 评估合规性要求 | 查看您的 Cloud KMS 架构，并与您必须遵守的任何合规性要求进行比较。 |
后续步骤
- 详细了解 Cloud KMS Autokey 如何减少您在持续使用 CMEK 方面的工作量。