使用 CMEK 的最佳实践

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

本指南假定您已熟悉 Cloud Key Management Service (Cloud KMS),并已阅读 Cloud KMS 深度解析

初步决定

本页中的建议适用于使用 CMEK 加密数据的客户。如果您不确定在安全策略中应使用手动创建的 CMEK 还是自动创建的 CMEK,本部分将就这些初步决策提供指导。

决定是否使用 CMEK

如果您需要以下任何功能,我们建议您使用 CMEK 加密 Google Cloud 服务中的静态数据:

  • 拥有加密密钥。

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

  • 在 Cloud KMS 中生成密钥材料,或导入在 Google Cloud 之外维护的密钥材料。

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

  • 在停用账号或修复安全事件时,选择性删除由您的密钥保护的数据(加密碎片化)。

  • 创建并使用客户专有的密钥,在您的数据周围建立加密边界。

  • 记录对加密密钥的管理员访问和数据访问

  • 满足当前或未来法规要求,需要实现任何这些目标。

如果您不需要这些功能,请评估使用 Google 管理的密钥的默认休眠加密是否适合您的用例。如果您选择仅使用默认加密,则可以停止阅读本指南。

选择手动或自动密钥创建

本指南概述了在自行预配 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 文件夹和项目结构

如果您使用 Cloud KMS Autokey,则启用了 Autokey 的每个文件夹都必须有一个专用的 Cloud KMS 密钥项目。

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

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

  • 区域级资源和可用区级资源必须使用与资源位于同一区域或 global 位置的密钥环和 CMEK。单区域资源和可用区级资源无法使用 global 以外的多区域密钥环。
  • 多区域资源(例如 us 多区域中的 BigQuery 数据集)必须使用位于同一多区域或双区域中的密钥环和 CMEK。多区域资源无法使用区域密钥环。
  • 全局资源必须使用 global 位置的密钥环和 CMEK。

强制执行区域密钥是数据区域化策略的一部分。通过强制在指定区域中使用密钥环和密钥,您还可以强制要求资源必须与密钥环的区域一致。如需有关数据驻留的指导,请参阅实现数据驻留和主权要求

对于需要在多个位置实现高可用性或灾难恢复功能的工作负载,您有责任评估在 Cloud KMS 在某个区域不可用的情况下,您的工作负载是否具有弹性。例如,在 us-central1 不可用且发生灾难恢复的情况下,无法在 us-central2 中重新创建使用 us-central1 中的 Cloud KMS 密钥加密的 Compute Engine 永久性磁盘。为降低这种情况的风险,您可以计划使用 global 密钥对资源进行加密。

如需了解详情,请参阅选择最佳位置类型

如果您使用 Cloud KMS Autokey,系统会在您要保护的资源所在的位置为您创建密钥环。

选择键粒度策略

粒度是指每个密钥预期用途的规模和范围。例如,与仅保护一个资源的密钥相比,保护多个资源的密钥的粒度更粗

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

虽然没有普遍适用的正确模式,但请考虑不同模式之间的以下权衡:

高精细度键,例如,为每个单独的资源分配一个键

  • 增强控制功能,安全地停用密钥版本:与停用或销毁共享密钥相比,停用或销毁用于小范围的密钥版本对其他资源的影响风险更低。这也意味着,与使用低精细度密钥相比,使用高精细度密钥有助于降低密钥遭到破解的潜在影响。
  • 费用:与使用粒度较低的密钥的策略相比,使用粒度较细的密钥需要维护更多有效的密钥版本。由于 Cloud KMS 的价格取决于有效密钥版本的数量,因此选择更高的密钥精细化程度会导致费用增加。
  • 运营开销:使用精细化的密钥可能需要进行管理工作,或者需要额外的自动化工具来预配大量 Cloud KMS 资源,并管理服务代理的访问控制,以便他们只能使用适当的密钥。如果您需要高精确度的密钥,Autokey 可能是自动配置的理想之选。如需详细了解每项服务的 Autokey 密钥粒度,请参阅兼容的服务

粒度较低的键,例如,为每个应用、每个区域和每个环境分配一个键

  • 请务必小心谨慎地停用密钥版本:与停用或销毁精细划分的密钥相比,停用或销毁用于广泛范围的密钥版本需要更加谨慎。您必须确保使用该密钥版本加密的所有资源都已使用新密钥版本安全地重新加密,然后才能停用旧密钥版本。对于许多资源类型,您可以查看密钥用量,以帮助确定密钥的使用位置。这也意味着,与使用高精细度密钥相比,使用低精细度密钥可能会增加密钥被破解的潜在影响。
  • 费用:使用粒度较低的密钥需要创建的密钥版本更少,而 Cloud KMS 价格取决于有效密钥版本的数量。
  • 运营开销:您可以定义并预配已知数量的密钥,从而减少确保适当访问控制所需的工作量。

选择密钥的保护级别

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

  1. 您是否需要任何 CMEK 功能?您可以查看本页面上决定是否使用 CMEK 部分列出的能力。

    • 如果是,请继续回答下一个问题。
    • 如果没有,我们建议您使用 Google 默认加密
  2. 您是否要求密钥材料始终位于硬件安全模块 (HSM) 的物理边界内?

    • 如果是,请继续回答下一个问题。
    • 如果没有,我们建议您将 CMEK 与软件加密密钥搭配使用。
  3. 您是否要求将密钥材料存储在 Google Cloud 之外?

Autokey 仅支持 HSM 保护级别。如果您需要其他保护级别,则必须自行预配密钥。

尽可能使用 Google 生成的密钥材料

本部分不适用于 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 资源执行 encryptdecrypt 操作的权限。 加密密钥管理系统用户
roles/cloudkms.viewer 启用 getlist 操作。 审核管理员

Security Command Center 针对 Cloud KMS 的漏洞发现结果可以自动检测违反此原则的情况和相关问题。

一致强制执行 CMEK

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

强制执行项目安全锁

我们建议您使用安全锁保护项目,以免意外删除。强制执行项目安全锁后,系统会阻止删除 Cloud KMS 密钥项目,直到移除安全锁为止。

要求使用 CMEK 密钥

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

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

要求设定最短的已安排销毁时长

我们建议您设置最短的已安排销毁时间时长。密钥销毁是一项不可逆的操作,可能会导致数据丢失。默认情况下,Cloud KMS 会将已安排销毁时长(有时称为软删除期限)设为 30 天,在该期限结束后,密钥材料将不可恢复地销毁。这样一来,在意外销毁密钥时,您就有时间恢复密钥。不过,具有 Cloud KMS 管理员角色的用户可以创建安排销毁时长短至 24 小时的密钥,这可能不足以让您检测到问题并恢复密钥。已安排销毁时长只能在创建密钥时设置。

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

为确保创建的所有密钥都遵循最短的预定销毁时间时长,我们建议您将组织政策限制 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 拥有的硬件安全模块 (HSM) 上,请选择 Cloud HSM。如果您的需求不需要 Cloud HSM 或 Cloud EKM,请选择软件密钥。查看选择保护级别的指南
密钥材料 对于在 Google Cloud 上托管的密钥材料,请尽可能使用 Google 生成的密钥材料。如果您使用导入的密钥材料,请实现自动化操作和流程以降低风险
密钥用途和算法 所有 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 架构,并与您必须遵守的所有合规性要求进行比较。

后续步骤