Cloud Key Management Service 深度解释

本页面内容的上次更新时间为 2023 年 7 月,代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制,Google 的安全政策和系统今后可能会发生变化。

Google Cloud 秉承的基本原则是,Google Cloud 客户拥有其数据,并且应该控制数据的使用方式。

当您使用 Google Cloud 存储数据时,默认情况下您的数据会静态加密。使用 Cloud Key Management Service (Cloud KMS) 平台时,您可以更好地控制对数据进行静态加密的方式以及管理加密密钥的方式。

下表介绍了不同类型的 Google Cloud 密钥。

密钥类型 密钥管理 钥匙共享 自动轮替 价格
默认加密密钥 这些密钥仅由 Google 管理。 来自多个客户的数据可能会使用相同的密钥加密密钥 (KEK)。 有,请参阅默认静态加密 免费。
Cloud KMS 密钥 这些密钥由客户控制。 对客户而言是唯一的。 是(对于对称加密);否(对于非对称密钥)。请参阅密钥轮替 请参阅 Cloud Key Management Service 价格

本文档重点介绍 Cloud KMS 平台的内部工作原理。这些选项可帮助您保护存储在 Google Cloud 中的密钥和其他机密数据。本文档面向需要详细了解 Cloud KMS 架构、基础架构和功能的技术决策者。本文档假定您对加密概念和云架构有基本的了解。

Cloud KMS 设计支柱

通过 Cloud KMS,Google 可专注于提供可扩缩、可靠且高性能的解决方案,提供广泛的可控制选项。 Cloud KMS 受到以下五个设计要素的支持:

  • 客户控制:Cloud KMS 让您可以控制自己的软件和硬件密钥进行加密和签名。这一重要部分支持自带密钥 (BYOK) 和自持密钥 (HYOK)。
  • 访问权限控制和监控:借助 Cloud KMS,您可以管理各个密钥的权限,并监控这些密钥的使用方式。
  • 区域性:Cloud KMS 提供开箱即用的区域化功能。该服务配置为仅在所选的 Google Cloud 位置中创建、存储和处理密钥。
  • 备份:为了帮助防止数据损坏并验证数据能否成功解密,Cloud KMS 会定期扫描并备份所有密钥材料和元数据。
  • 安全性:Cloud KMS 提供强大的保护,可防止密钥遭到未经授权的访问,并且与 Identity and Access Management (IAM) 和 Cloud Audit Logs 控件完全集成。

关键材料的来源和管理选项

借助 Cloud KMS 平台,您可以通过中央云服务管理加密密钥,以直接使用或供其他云资源和应用使用。

下图显示了 Google Cloud 密钥产品组合,按照从 Google 控制的密钥材料到客户控制的密钥材料的排列。

Google Cloud 密钥组合。

上图中显示的选项如下:

  • 默认加密:Google 存储的所有数据均使用高级加密标准 (AES) 算法 AES-256 在存储层进行加密。我们生成和管理用于默认加密的密钥,客户无权访问密钥,也无法控制密钥轮替和管理。客户可以共用默认加密密钥。如需了解详情,请参阅默认静态加密

  • 使用软件生成的密钥的 Cloud KMS:使用 Cloud KMS,您可以控制 Google 生成的密钥。借助 Cloud KMS 软件后端,您可以灵活地使用由您控制的对称或不对称密钥对数据进行加密或签名。

  • Cloud KMS 与硬件生成的密钥 (Cloud HSM):搭配使用 Cloud KMS 和 Cloud HSM 后端,您可以获得生成并存储在 Google 拥有和运营的硬件安全模块 (HSM) 中的密钥。如果您需要硬件保护的密钥,可以使用 Cloud HSM 后端来帮助确保对称密钥和非对称密钥仅用于 FIPS 140-2 3 级验证的 HSM。

  • 支持密钥导入的 Cloud KMS:为了满足 BYOK 要求,您可以导入自己生成的自己的加密密钥。您可以在 Google Cloud 之外使用和管理这些密钥,并使用 Cloud KMS 中的密钥材料对存储在 Google Cloud 中的数据进行加密或签名。

  • 具有外部密钥管理器 (Cloud EKM) 的 Cloud KMS:如需满足 HYOK 要求,您可以创建和控制存储在 Google Cloud 外部的密钥管理器中的密钥。然后,将 Cloud KMS 平台设置为使用外部密钥来帮助保护静态数据。您可以将这些加密密钥与 Cloud EKM 密钥搭配使用。如需详细了解外部密钥管理和 Cloud EKM,请参阅可靠部署 Cloud EKM 服务的参考架构

您可以选择将 Cloud KMS 生成的密钥与其他 Google Cloud 服务搭配使用。此类密钥被称为客户管理的加密密钥 (CMEK)。借助 CMEK 功能,您可以生成、使用、轮替和销毁加密密钥,以帮助保护其他 Google Cloud 服务中的数据。

Google 的加密概念和密钥管理服务

本部分介绍了 Google 的多层密钥管理基础架构中密钥管理的一些术语。

密钥环、密钥和密钥版本

下图说明了密钥分组,并显示了密钥环和具有一个主要版本和多个先前版本的密钥。

密钥分组图。

上图显示的关键概念如下:

  • 密钥:一个已命名对象,表示用于特定用途的加密密钥。随着新密钥版本的创建,密钥材料(用于加密操作的实际位)会随着时间的推移而改变。您可以在资源层次结构的密钥级层分配 IAM 允许政策。

    密钥用途和密钥的其他特性通过该密钥进行关联和管理。因此,密钥是了解 KMS 使用情况的最重要对象。

    Cloud KMS 同时支持不对称密钥和对称密钥。对称密钥用于创建或验证 MAC 签名,或者用于对称加密,以保护某些数据主体。例如,您可以使用 GCM 模式下的 AES-256 来加密明文块。非对称密钥可用于非对称加密或不对称签名。如需了解详情,请参阅支持的用途和算法

  • 密钥环:用于对密钥进行分组,以便进行整理。密钥环属于 Google Cloud 项目,并且位于特定位置。密钥会从其密钥环继承允许政策。通过将具有相关权限的密钥分组为具体的密钥环,您可以在密钥环级别授予、撤消或修改这些密钥的权限,而无需单独对每个密钥执行操作。密钥环可提供便利性和分类功能,但如果密钥环的分组对您没有用,您可以直接管理密钥的权限。通过标记,您可以根据资源是否具有特定的标记有条件地允许或拒绝政策。您可以在资源层次结构中的密钥环级别应用标记。

    为防止资源名称发生冲突,您不能删除密钥环或密钥。密钥环和密钥没有可结算费用或配额限制,因此它们的持续存在不会对费用或生产环境限制产生任何影响。

  • 密钥元数据:资源名称、KMS 资源的属性,例如允许政策、密钥类型、密钥大小、密钥状态以及从密钥和密钥环派生的任何数据。

  • 密钥版本:在某个时间点与密钥关联的密钥材料。密钥版本是包含实际密钥材料的资源。系统会从版本 1 开始按顺序为各版本编号。轮替密钥时,系统会使用新的密钥材料创建新的密钥版本。同一逻辑密钥在一段时间内可以有多个版本,这意味着,您的数据将使用不同的密钥版本进行加密。对称密钥具有主要版本。默认情况下,主要版本用于加密。当 Cloud KMS 使用对称密钥执行解密时,会自动识别执行解密所需的密钥版本。

软件密钥层次结构

下图说明了 Cloud KMS 和 Google 内部密钥库的密钥层次结构。Cloud KMS 使用 Keystore(Google 的内部密钥管理服务)来封装 Cloud KMS 加密密钥。密钥封装是使用一个密钥加密另一个密钥的过程,加密后便可以安全存储或通过不受信任的渠道进行传输。Cloud KMS 使用与密钥库相同的信任根。

内部密钥层次结构图。

上图中显示的密钥层次结构如下所示:

  1. 数据加密密钥 (DEK) 用于对数据区块进行加密。
  2. 密钥加密密钥 (KEK) 用于加密或“封装”DEK。所有 Cloud KMS 平台选项(软件、硬件和外部后端)都可让您控制 KEK。KEK 存储在 Cloud KMS 中。
  3. KMS 主密钥会对 KEK 进行加密。KMS 主密钥存储在密钥库中。每个 Cloud KMS 位置在密钥库中都有单独的 KMS 主密钥。Cloud KMS 中的 KEK 受营业地点的 KMS 主密钥保护。每个 Cloud KMS 服务器都会在启动时提取 KMS 主密钥的副本作为硬依赖项,并每天检索 KMS 主密钥的新副本。KMS 主密钥会定期重新加密。
  4. KMS 主密钥受密钥库中的密钥库主密钥保护。
  5. 密钥库主密钥受根密钥库主密钥保护。

如需详细了解密钥库,请参阅《静态加密》白皮书中的密钥管理

主要操作限制

Cloud KMS 的运行方式如下:

  • 项目:Cloud KMS 资源属于 Google Cloud 项目,就像所有其他 Google Cloud 资源一样。您可以将数据托管在 Cloud KMS 密钥所在项目以外的另一个的项目中。为遵循在关键管理员和数据管理员之间实现职责分离的最佳实践,您可以从密钥项目中移除所有者角色。
  • 位置:在项目中,系统会在某个位置创建 Cloud KMS 资源。如需详细了解位置,请参阅地理位置和区域
  • 一致性:Cloud KMS 使用强一致性或最终一致性传播对密钥、密钥环和密钥版本的操作。如需了解详情,请参阅 Cloud KMS 资源一致性

Cloud KMS 平台概览

Cloud KMS 平台支持多种加密算法,并提供使用外部、硬件和软件支持的密钥进行加密和数字签名的方法。Cloud KMS 平台已与 Identity and Access Management (IAM)Cloud Audit Logs 集成,因而您可以分别管理各个密钥的权限,并审核这些密钥的使用方式。

Cloud KMS 架构图。

上图显示了 Cloud KMS 平台的以下主要组成部分。

  • 管理员使用 Cloud 控制台或 Google Cloud CLI 访问密钥管理服务。
  • 应用通过实现 REST APIgRPC客户端库来访问密钥管理服务。应用可以使用启用了 CMEK 的 Google 服务。CMEK 则使用 Cloud Key Management Service API。如果您的应用使用 PKCS #11,您可以使用 PKCS #11 库将其与 Cloud KMS 集成。

  • 借助 Cloud KMS API,您可以使用软件、硬件或外部密钥。 基于软件和基于硬件的密钥都使用了 Google 的冗余备份保护功能。

  • 如果您使用的是硬件密钥,Google Cloud 中经过 FIPS 140-2 3 级认证的 HSM 会存储密钥。如需详细了解我们的认证,请参阅证书 #4399

  • Cloud KMS 使用 Google 的内部数据存储区来存储加密的客户密钥材料。此数据存储区具有高可用性,并支持 Google 的许多关键系统。请参阅Datastore 保护

  • 独立备份系统会定期将整个数据存储区备份到在线存储空间和归档存储空间。此备份可让 Cloud KMS 实现其持久性目标。请参阅 Datastore 保护

FIPS 140-2 验证

Cloud KMS 加密操作由通过 FIPS 140-2 验证的模块执行。保护级别为 SOFTWARE 的密钥和使用这些密钥执行的加密操作符合 FIPS 140-2 1 级。这些加密操作使用 BoringCrypto,这是 Google 维护的开源加密库。保护级别为 HSM 的密钥和使用这些密钥执行的加密操作符合 FIPS 140-2 3 级。

Google 基础架构依赖项

Cloud KMS 平台元素会以生产环境 Borg 作业的形式运行。Borg 是 Google 的大型集群管理器,用于处理 API 传送作业和批处理作业。

如需了解我们物理和生产基础架构的安全性,请参阅 Google 基础架构安全设计概览

Cloud KMS API 传送作业

Cloud KMS API 传送作业是生产环境 Borg 作业,用于传送客户管理和使用其密钥的请求。Cloud KMS API 传送作业还可以处理客户请求的延迟操作,例如按计划轮替密钥、创建非对称密钥和导入密钥。这些传送作业在提供 Cloud KMS 的每个 Google Cloud 区域内运行。每个作业都与单个区域关联,并且配置为仅访问地理位置位于关联 Google Cloud 区域内的系统的数据。

Cloud KMS 批处理作业

Cloud KMS 平台还维护许多批处理作业,这些作业按不同的时间表以生产环境 Borg 作业的形式运行。批处理作业特定于区域,仅从关联的 Google Cloud 区域中汇总数据并在其中运行。这些作业执行的任务包括:

  • 统计用于客户结算的有效密钥数量。
  • 汇总来自 Cloud KMS 公共协议缓冲区 API 的资源,并将元数据转发到 Cloud Asset Inventory。此上下文中的资源是指由 Cloud KMS 管理的任何资源,例如密钥和密钥环。
  • 汇总所有资源并报告信息以进行业务分析。
  • 截取数据快照以实现高可用性。
  • 验证存储在底层数据存储区中的所有数据均未损坏。
  • 在轮替 KMS 主密钥时重新加密客户密钥材料。

Cloud KMS 密钥快照程序

为了保持高可用性,Cloud KMS 平台会在托管 Cloud KMS API 服务器任务的共享服务的每个实例中,保留一个冗余数据存储区。每项共享服务都会部署自己的快照程序服务实例。这种冗余性使得服务高度独立,因此在一个可用区发生的故障对其他可用区的影响有限。当 Cloud KMS API 作业需要执行加密操作时,会同时查询主数据存储区和本地快照程序作业。如果主数据存储区运行缓慢或不可用,并且快照的存在时间不超过两个小时,则系统可能会通过快照提供响应。系统会创建快照,以作为针对每个区域持续运行的批处理作业的输出。快照驻留在与密钥材料关联的云区域。

客户端-服务器通信

Google 使用应用层传输安全 (ALTS) 来帮助为使用 Google 远程过程调用 (RPC) 机制的客户端-服务器通信提供安全性。

如需了解详情,请参阅服务到服务的身份验证、完整性和加密

Cloud KMS 平台架构

本部分介绍有关密钥材料的安全性数据存储区保护的架构详情。

密钥材料的安全性

在 Cloud KMS 中,密钥材料无论是在静态存储时还是在传输过程中,始终受加密保护。只有在下列情况下,密钥材料才会被解密:

  • 当客户使用时。
  • 当 Google 用于保护客户密钥材料的内部密钥被轮替或由系统检查其完整性时。

发送给 Cloud KMS 的客户请求在传输过程中会被加密,所使用的协议为客户与 Google Front End (GFE) 之间的传输层安全协议 (TLS)。

所有 Cloud KMS 作业之间都会进行身份验证,无论是在 Google 数据中心内部还是在数据中心之间。

Google 的政策是确保作业仅使用以可验证方式构建、测试和审核的源代码。 Binary Authorization for Borg (BAB) 会在操作级别强制执行此政策。

Cloud KMS API 作业可以访问密钥元数据(例如允许政策或轮替周期)。如果 Google 员工具有正当且有据可查的业务理由(例如 Bug 或客户问题),也可以访问密钥元数据。这些访问事件会在内部记录,与 Access Transparency 涵盖的数据相关的日志也会提供给符合条件的客户。

无法通过 API 接口或其他界面导出或查看解密的密钥材料。Google 员工无权访问未加密的客户密钥材料。此外,密钥材料还通过密钥库中的主密钥进行了加密,该主密钥任何个人都无法直接访问。在 HSM 上,Cloud KMS API 作业绝不会访问处于解密状态的密钥材料。

数据存储区保护机制

Cloud KMS 的数据存储区具备高度可用性和耐用性,而且受到保护。

可用性。Cloud KMS 使用 Google 内部数据存储区,该存储区不但高度可用,而且支持多个 Google 关键系统。

耐用性。Cloud KMS 使用经过身份验证的加密功能将客户密钥材料存储在数据存储区中。此外,所有元数据都使用基于哈希的消息身份验证代码 (HMAC) 进行身份验证,以确保其在静态存储中没有被更改或损坏。批处理作业每小时会扫描一次所有密钥材料和元数据,并验证 HMAC 是否有效以及密钥材料是否可以成功解密。如果有任何数据被损坏,Cloud KMS 工程师会立即收到提醒,以便采取措施。

Cloud KMS 对数据存储区使用多种类型的备份:

  • 默认情况下,数据存储区会将每行的更改历史记录保留四天。在紧急情况下,可以延长此生命周期以提供更多时间来解决问题。
  • 数据存储区每小时会记录一次快照。如有必要,可以验证快照并将其用于恢复。这些快照会保留四天。
  • 系统每天都会将完整备份复制到磁盘和归档存储。

Cloud KMS 团队记录了恢复备份的过程,以便在服务端发生紧急情况时减少数据丢失。

备份。 Cloud KMS 数据存储区备份位于关联的 Google Cloud 区域中。这些备份均采用静态加密。 系统会根据访问理由(例如您向 Google 支持团队提交的工单号)限制对备份中数据的访问,并且人工访问会记录在 Access Transparency 日志中。

保护。在 Cloud KMS 应用层,密钥材料会在存储之前进行加密。有权访问数据存储区的工程师无权访问明文客户密钥材料。此外,数据存储区在写入永久存储空间之前,会对其管理的所有数据进行加密。因此,在无权访问底层存储层(包括磁盘或归档存储)的情况下,即使无权访问存储在 Keystore 中的 Datastore 加密密钥,也不允许访问已加密的 Cloud KMS 数据。

轮替政策。密钥轮替是处理密钥材料的公认最佳做法的一部分。用于保护 Cloud KMS 数据存储区的密钥有一个轮替政策。密钥轮替政策也适用于封装 Cloud KMS 主密钥的密钥库主密钥。密钥库主密钥预定的密文存在时间上限为 90 天,客户端缓存密钥存在时间上限为 1 天。Cloud KMS 每 24 小时刷新一次 KMS 任务中的 KMS 主密钥,并每月会重新加密所有客户密钥一次。

数据驻留。每个 Cloud KMS 数据存储区的基础数据只会保留在与该数据关联的 Google Cloud 区域内。此规则也适用于多区域位置,例如 us 多区域。

密钥创建后的可用性

Cloud KMS 允许在 Cloud KMS 数据存储区提交创建密钥的事务后,以及在存储层确认创建密钥之后,立即使用该密钥。

密钥后端

使用 Cloud KMS 创建密钥时,您可以选择保护级别,以确定哪个密钥后端创建密钥并执行所有未来针对该密钥的加密操作。后端在 Cloud KMS API 中公开为以下保护级别:

  • SOFTWARE:适用于可能由软件安全模块解封以执行加密操作的密钥。
  • HSM:适用于只能由使用密钥执行所有加密操作的 HSM 解封装的密钥。
  • EXTERNALEXTERNAL-VPC:适用于外部密钥管理器 (EKM)。EXTERNAL-VPC 可让您通过 VPC 网络将 EKM 连接到 Google Cloud。

Cloud KMS 软件后端:软件保护级别

保护级别 SOFTWARE 适用于在软件中执行加密操作的密钥。本部分详细介绍了此级别的实现方式。

算法实现

对于软件密钥,Cloud KMS 使用 Google 的 BoringSSL 实现中的 BoringCrypto 模块 (BCM) 进行所有相关的加密工作。BCM 通过了 FIPS 140-2 验证。Cloud KMS 二进制文件是根据此模块经过 FIPS 140-2 1 级验证的加密原语构建的。本模块涵盖的最新算法列在密钥用途和算法中,包括使用 AES256-GCM 对称和 RSA 2048、RSA 3072、RSA 4096、EC P256 和 EC P384 不对称加密密钥进行的加密、解密和签名操作。

随机数的生成和熵

生成加密密钥时,Cloud KMS 会使用 BoringSSL。FIPS 140-2 要求使用自己的 PRNG(也称为 DRBG)。在 BoringCrypto 中,Cloud KMS 只使用 CTR-DRBG 搭配 AES-256。这为 RAND_bytes 提供了输出,而 RAND_bytes 是系统其余部分获取随机数据的主要接口。此 PRNG 源自 Linux 内核的 RNG,而后者自己又源自多个独立的熵源。这种来源关系包括来自数据中心环境的熵事件,例如磁盘寻道和内部数据包到达时间的精细测量结果,以及源自 Intel RDRAND 指令的熵事件(如果有)。如需详细了解适用于 BoringSSL 的随机数生成器的行为(符合 FIPS 的模式),请参阅 RNG 设计

Cloud HSM 后端:硬件保护级别

Cloud HSM 向 Cloud KMS 提供硬件支持的密钥。它可让您使用 Google 数据中心内全代管式 FIPS 140-2 3 级认证的 HSM 保护的加密密钥。与 Cloud KMS 一样,Cloud HSM 高可用性,具有弹性扩缩能力。现有 Cloud KMS 客户无需更改应用,因为他们可以使用与 Cloud KMS 相同的 API 和客户端库访问 Cloud HSM 后端。如需详细了解 Cloud HSM 后端,请参阅 Cloud HSM 架构

Cloud EKM:EXTERNAL 保护级别

借助 Cloud EKM,您可以使用由您控制的云端外加密密钥来加密数据。

保护级别为 EXTERNALEXTERNAL_VPC 的密钥在外部密钥管理系统中存储和管理。如需了解详情,请参阅可靠部署 Cloud EKM 服务的参考架构

密钥导入

建议您将在本地或 EKM 中创建的自己的密钥导入到云环境中。例如,法规可能会要求,用于加密云数据的密钥必须以特定方式或在特定环境中生成。借助密钥导入,您可以导入这些密钥并遵循法规义务。如需将签名功能扩展到云端,您还可以导入非对称密钥。

在密钥导入过程中,Cloud KMS 使用一种支持的导入方法生成封装公钥,即公钥/私钥对。使用此封装密钥加密您的密钥材料可保护传输中的密钥材料。

您使用封装公钥对要在客户端上导入的密钥进行加密。与公钥匹配的私钥存储在 Google Cloud 中,用于在公钥到达 Google Cloud 项目后解封装。您选择的导入方法决定了用于创建封装密钥的算法。密钥材料封装完毕后,您可以将其导入到 Cloud KMS 中的新密钥或密钥版本。

您可以使用保护级别为 HSMSOFTWARE 的导入密钥。对于 Cloud HSM,封装密钥的私钥部分只能在 Cloud HSM 内部使用。限定只能在 Cloud HSM 内部使用私钥部分可防止 Google 在 Cloud HSM 之外解封您的密钥材料。

客户管理的加密密钥 (CMEK)

默认情况下,Google Cloud 会对静态存储的所有客户数据进行加密,由 Google 管理用于加密的密钥。对于某些 Google Cloud 产品,您可以改用 Cloud KMS 来管理用于加密的密钥。CMEK 可用于外部、软件和硬件支持的密钥。Cloud KMS 让您可以控制密钥的许多方面(例如创建、启用、停用、轮替和销毁密钥),以及管理这类密钥的相应 IAM 权限。为了实施建议的职责分离,Cloud KMS 包含几个预定义的 IAM 角色,这些角色具有特定权限和限制,可以授予特定用户和服务帐号。

轮替 Cloud KMS 密钥不会重新加密关联的 CMEK 服务中的数据。相反,新创建的资源将使用新的密钥版本进行加密,这意味着不同版本的密钥可以保护不同的数据子集。例如,当与表关联的 Cloud KMS 密钥轮替时,BigQuery 不会自动轮替表加密密钥。现有 BigQuery 表将继续使用其创建时所用的密钥版本。新的 BigQuery 表使用当前的密钥版本。如需了解详情,请参阅每个产品的文档。

CMEK 组织政策可让您更好地控制 CMEK 在项目中的使用方式。通过这些政策,您可以控制那些包含 CMEK 密钥的服务和项目。

Google Cloud 支持将 CMEK 用于多项服务,包括 Cloud Storage、BigQuery 和 Compute Engine。如需查看 CMEK 集成和兼容 CMEK 的服务的完整列表,请参阅 CMEK 集成。Google 会继续在其他 Google Cloud 产品的 CMEK 集成方面保持投入。

Cloud KMS 请求的生命周期

本部分介绍 Cloud KMS 请求的生命周期,包括有关销毁密钥材料的讨论。下图展示了请求访问 us-east1us-west1 中的 Cloud KMS 服务实例的客户端,以及如何使用 Google Front End (GFE) 路由请求。

KMS 请求生命周期图。

此生命周期中的步骤包括:

  1. 客户或代表客户运行的作业向 Cloud KMS 服务 https://cloudkms.googleapis.com 发出请求。DNS 会将此地址解析为GFE 的任播 IP 地址。
  2. GFE 提供其公共 DNS 名称的公开 IP 托管、拒绝服务 (DoS) 攻击保护,以及 TLS 终止。当客户发送请求时,系统通常将其路由到客户附近的 GFE,而不考虑客户请求的目标位置。GFE 会处理 TLS 协商,并使用请求网址和参数确定由哪个全球软件负载平衡器 (GSLB) 路由请求。
  3. 每个 Cloud KMS 区域都有一个单独的 GSLB 目标。如果请求到达位于 us-east1 的 Google 数据中心,而它是发往 us-west1 的,那么系统会在 us-east1us-west1 数据中心之间路由该请求。数据中心之间的所有通信都在传输过程中使用 ALTS 进行了加密,ALTS 会对 GFE 和 Cloud KMS 作业进行双向身份验证。
  4. 当请求到达 Cloud KMS 作业时,会先由一个框架处理,该框架可处理大部分通用于所有 Google Cloud 服务的工作。此框架会对用户进行身份验证,并执行多项检查以验证以下事项:
    • 客户拥有有效的凭据,可以进行身份验证。
    • 项目已启用 Cloud KMS API,并且具有有效的结算帐号。
    • 配额足以运行请求。
    • 客户在许可名单中,可以使用相关的 Google Cloud 区域。
    • VPC Service Controls 未拒绝请求。
  5. 这些检查通过后,框架会将请求和凭据转发到 Cloud KMS。Cloud KMS 会解析请求以确定正在访问哪些资源,然后向 IAM 确认,以了解调用者是否有权发出请求。IAM 还会告知 Cloud KMS 是否应将出现的请求写入审核日志。
  6. 对请求进行身份验证和授权后,Cloud KMS 会调用其区域内数据存储区后端以提取请求的资源。提取资源后,客户密钥材料将被解密以供使用。
  7. 有了密钥材料,Cloud KMS 会执行加密操作,并根据密钥的保护级别将密钥的封装版本转发到 Cloud KMS 软件后端、Cloud HSM 后端或 Cloud EKM 后端。
  8. 加密操作完成后,系统将通过与请求相同类型的 GFE 到 KMS 通道将响应发回给客户。
  9. 返回响应后,Cloud KMS 还会异步触发某些事件:
    • 填写审核日志和请求日志,并将其排入队列等待写入。
    • 发送报告以进行结算和配额管理。
    • 如果请求更新了资源的元数据,则系统将通过批处理作业更新将更改发送到 Cloud Asset Inventory

端到端数据完整性

Cloud KMS 让您可以计算密钥和密钥材料的校验和,以帮助确保它们不会损坏。这些校验和有助于防止数据丢失,这些数据可能会因硬件损坏或软件损坏而丢失。您可以借助帮助程序库验证密钥完整性。您可以使用帮助程序库向 Cloud KMS 提供由服务器验证的校验和来验证密钥完整性。此外,这些库还可让您接收校验和以验证客户端上的响应数据。

端到端数据完整性有助于保护您的环境免受以下威胁的侵害:

  • 传输过程中损坏;例如在发送数据时到数据受 TLS 保护之间的堆栈中损坏。
  • 端点与 KMS 之间的任何中间代理中的问题(例如,传入请求)。
  • Cloud KMS 架构中出现错误的加密操作、机器内存损坏或 HSM 损坏。
  • 与外部 EKM 通信期间发生损坏。

如需了解详情,请参阅验证端到端数据完整性

销毁密钥材料

密钥材料被视为客户数据,因此 Google Cloud 上的数据删除中所述的方法也适用于 Cloud KMS。当计划销毁周期结束且备份过期时,密钥材料会根据请求被销毁。(安排的销毁期结束后)仍存在于备份中的密钥材料只能用于区域灾难恢复,不能用于恢复单个密钥。此过程不保证适用于 Cloud KMS 控制范围之外的导入密钥的副本。

默认情况下,在从系统中逻辑删除密钥材料之前,Cloud KMS 中的密钥会处于已安排销毁软删除)状态 24 小时。您可以更改此时长。如需了解详情,请参阅“已安排销毁”状态的可变时长

虽然密钥材料被销毁,但密钥和密钥环无法删除。密钥版本也不能删除,但密钥版本材料可予以销毁,以使资源无法再使用。密钥环和密钥没有可结算费用或配额限制,因此它们的持续存在不会对费用或生产环境限制产生任何影响。

安排销毁某个密钥版本后,该密钥版本将无法用于加密操作。在等待删除期内,您可以恢复密钥版本,使其不会被销毁。

如果您误删除了已导入的密钥,可以将其重新导入。如需了解详情,请参阅重新导入已销毁的密钥

为避免意外删除密钥,请考虑以下最佳实践:

  • 创建不包含 cloudkms.cryptoKeyVersions.destroy 权限的自定义 KMS 角色。
  • destroy_scheduled_duration 字段更改为较长的时间段。
  • 监控关键销毁事件并添加提醒。例如,创建以下 Cloud Logging 过滤条件:

      resource.type="cloudkms_cryptokeyversion"
      protoPayload.methodName="DestroyCryptoKeyVersion"
    
  • 创建进程,在密钥被删除前停用密钥几天。

Cloud KMS 平台运营环境

Cloud KMS 平台的运营环境包括数据存储和安全政策、访问权限限制以及风险缓解策略,这些策略可在保护密钥材料的同时优化可靠性、耐用性和可用性。本部分介绍服务的操作结构、运营团队成员的责任、身份验证机制以及审核和日志记录协议。本部分同时适用于由软件和硬件支持的密钥功能。

软件工程师、网站可靠性工程师和系统运维人员

软件工程师负责与其他利益相关方(如产品经理和网站可靠性工程师 (SRE))合作,共同设计系统并为 Cloud KMS 服务编写大量代码及进行测试。代码包括传送客户请求的主要作业,以及用于执行数据复制和结算等活动的次要作业。SRE 也可能会编写代码。但是,软件工程师和 SRE 职责是分开的;SRE 主要负责维护 Cloud KMS 作业的生产环境。SRE 通过工程和运营工作来衡量和实现可靠性。

系统运维人员负责 Cloud KMS 的构建和发布流程、监控、提醒以及容量规划。他们是处理 Cloud KMS 客户问题和服务中断的现场应急人员。例如,系统运维人员利用工具和自动化来最大限度地减少手动系统工作,以便专注于能够带来长期价值的工作。

系统运维人员的职责在标准操作程序中定义。系统运维人员在履行职责时无法访问客户密钥材料。

Cloud KMS 资源的区域性

为了帮助您满足任何密钥驻留要求,您可以在以下四种类型的 Google Cloud 位置之一创建 Cloud KMS 资源:

  • 区域位置由特定地理位置(例如爱荷华州)中的可用区组成。
  • 双区域位置由两个特定地理位置(例如爱荷华州和南卡罗来纳州)中的可用区组成。
  • 多区域位置由分布在一般地理区域(例如美国)中的可用区组成。
  • 全球位置由分布在世界各地的可用区组成。当您在全球位置创建 Cloud KMS 资源后,就可以在世界各地的可用区使用这些资源。

这些位置代表地理区域,针对给定资源向 Cloud KMS 发出的请求会在这些位置得到处理,相应的加密密钥也存储在这些位置。

如需详细了解可用的 Cloud KMS 位置,请参阅 Cloud KMS 位置

云区域和数据中心

Google Cloud 区域包含一个特定的数据中心或一组指定的数据中心,具体取决于您指定的是单区域、双区域、多区域还是全球。如需详细了解 Google Cloud 区域,请参阅 Google Cloud 位置

每个数据中心都配备了许多用于计算、网络或存储数据的机器。这些机器运行 Google 的 Borg 基础架构。

Google 数据中心有严格的物理安全要求。任何可能包含用户数据的实体空间的入口都需要配备工牌读取器和虹膜扫描器,用于对进入者进行身份验证。门户不会保持打开供多人进出;每个人都必须单独进行身份验证。不得将包带入或带出这些区域,除非是由安全人员检查后明确获得授权的透明包。如果要带入或带出任何可能传输或记录数据的电子设备,必须获得特殊权限。

密钥驻留

某些行业要求将加密密钥存放在特定位置。Cloud KMS 签署了包含数据驻留保证的数据位置条款。如 Cloud KMS 资源的区域性中所述,Cloud KMS 提供四种类型的区域位置来帮助您满足这些要求。

对于单区域、双区域或多区域位置,Cloud KMS 仅在该位置创建、存储和处理软件和硬件支持密钥以及密钥材料。Cloud KMS 使用的存储和数据处理系统配置为仅使用与密钥材料关联的 Google Cloud 区域中的资源。在双区域或多区域位置创建的密钥材料不会离开所选位置的边界。

对于全球区域,没有指定区域性保证。

Cloud KMS 不保证驻留密钥元数据、使用情况日志或传输中密钥材料。密钥元数据包括资源名称、Cloud KMS 资源的属性(例如密钥类型、密钥大小和密钥状态)、IAM 政策以及从元数据派生的任何数据。

使用 CMEK 时,无论您在支持 CMEK 的其他 Google Cloud 产品中选择的是自定义、双区域还是多区域位置,以下 Cloud KMS 地理位置限制都适用于您的密钥:

  • 对于特定区域:由于客户管理的 KMS 密钥的区域必须始终与其在特定 Google Cloud 服务中保护的资源的区域相关,因此可以保证单区域密钥和资源的驻留限制是兼容的,并且同时确保该限制的实施。
  • 对于双区域或多区域位置:用户可以为其密钥和 Google Cloud 资源选择 Google 定义的多区域,以保证驻留合规性。为确保此类地理驻留,请务必保证其他产品中的区域与您选择的 Cloud KMS 区域位置一致。

下表总结了 Cloud KMS 的密钥材料驻留。

区域类型 静态、使用中
单区域 常驻
双区域或多区域 常驻在构成双区域或多区域的区域

区域性监控

Google 的内部数据监控服务会主动监控密钥驻留情况。如果 Cloud KMS 检测到意外配置错误,或者密钥材料离开其配置区域的边界、存储在错误的区域或从错误的区域访问,则 Cloud KMS 会向 SRE 团队成员发送提醒。

高可用性

Cloud KMS 可以根据您选择的区域简化可用性要求。位置越精细,您必须构建的冗余就越多。对于可用性级别更高的应用,请使用多区域位置,而不是尝试构建自己的密钥复制系统。您必须在内置冗余功能与数据区域化需求之间取得平衡。

身份验证和授权

Cloud KMS 接受各种身份验证机制,例如 OAuth2、JWT 和 ALTS。无论采用哪种机制,Cloud KMS 都会解析提供的凭据以识别主账号(即通过了身份验证并且正在向请求授权的实体),并调用 IAM 以查看主账号是否有权发出请求以及审核日志是否已写入。

Cloud KMS 使用公共 Service Control API 的内部版本来管理服务的许多方面。在 Cloud KMS 作业处理请求之前,会首先向 Service Control API 发送检查请求,从而实施所有 Google Cloud 服务通用的多种控制措施,例如:

  • 检查您是否已激活 Cloud KMS API 以及是否拥有有效的结算帐号。
  • 检查是否未超出配额,并报告配额使用情况。
  • 强制执行 VPC Service Controls
  • 检查您是否列在适用的私有云区域的许可名单中。

配额管理

Cloud KMS 对向服务发出的请求设有用量限额(称为配额quotas)。Cloud KMS 包含以下配额:

  • 加密、解密或签名等操作的加密请求配额。
  • 获取密钥元数据或获取 IAM 政策等操作的读取请求配额。
  • 创建密钥或设置 IAM 政策等操作的写入请求配额。

系统会将这些配额计入与调用方关联的项目。这些配额也是全球配额,这意味着它们将应用于调用方在所有区域和多区域中的 KMS 用量。系统会针对所有保护级别评估这些配额。

Cloud HSM 和 Cloud EKM 具有额外的加密操作配额。除了加密请求配额之外,还必须满足这些配额。Cloud HSM 和 Cloud EKM 配额会对密钥所在的项目收费,并且会对每个位置强制执行配额。

请参考以下示例:

  • 使用 asia-northeast1 中的软件密钥调用解密需要一个(全局)加密请求配额单元。
  • us-central1 中创建 HSM 密钥需要一个单元的写入请求配额,而不是 HSM 配额。
  • 使用 europe 中的 EKM 密钥调用加密需要一个单元的(全局)加密请求配额,以及 europe 中一个单元的外部 KMS 请求配额。

如需详细了解可用的配额类型,请参阅 Cloud KMS 资源的用量配额。您可以在 Cloud 控制台中查看配额限制。初始配额限制是软性限制,您可以根据自己的工作负载需求请求调整

日志记录

有三种类型的日志与 Cloud KMS 关联:Cloud Audit Logs 日志、Access Transparency 日志和内部请求日志。

Cloud Audit Logs

Cloud KMS 会在 Cloud Audit Logs记录您的活动。您可以在 Cloud 控制台中查看这些日志。所有管理员活动(例如创建或销毁密钥)都会记录在这些日志中。您还可以选择为使用密钥的所有其他操作(例如,使用密钥加密或解密数据)启用日志记录。您可以控制日志的保留时长以及谁可以查看日志。

Access Transparency 日志

符合条件的客户可以选择启用 Access Transparency 日志,以便获得 Google 员工在客户 Google Cloud 组织中执行的操作的日志。借助 Access Transparency 日志以及 Cloud Audit Logs 中的日志,您可以了解哪些用户何时在何处执行了哪些操作。

您可以将 Access Transparency 日志与现有安全信息和事件管理 (SIEM) 工具集成,以自动执行这些操作的审核。这些日志会在 Cloud 控制台中与 Cloud Audit Logs 日志一起提供。

Access Transparency 日志条目包含以下类型的详细信息:

  • 受影响的资源和操作。
  • 操作的执行时间。
  • 执行该操作的原因。原因示例包括客户发起的支持(带案例编号)、Google 发起的支持、第三方数据请求和 Google 发起的审核请求。
  • 有关对数据采取操作的用户的数据(例如,Google 员工的所在地)。

内部请求日志

请求日志会为发送到 Cloud KMS 平台的每个请求存储一条记录。此记录包含有关请求类型(例如 API 方法或协议)和正在访问的资源(例如资源名称、密钥算法或密钥保护级别)的详细信息。这些日志不会存储客户明文、密文或密钥材料。在将新类型的数据添加到这些日志之前,专门负责隐私权审核的团队必须批准对所记录数据做出的更改。

当配置的存留时间 (TTL) 到期后,日志条目会被永久删除。

轮值的 Cloud KMS SRE 和工程师可以访问请求日志。如需人工访问日志以及进行任何会返回客户数据的访问活动,则必须具备正当且有据可查的业务理由。除了某些特定的例外情况,系统会记录人工访问情况,而且符合条件的客户可以在 Access Transparency 日志中访问这些记录。

监控

Cloud KMS 与 Cloud Monitoring 集成。借助此集成,您可以监控和构建信息中心,并针对许多 Cloud KMS 操作创建提醒。例如,您可以监控安排销毁密钥的时间,或者在加密操作超出您定义的阈值时监控和调整 Cloud KMS 配额。如需详细了解可用的 Cloud KMS 指标,请参阅将 Cloud Monitoring 与 Cloud KMS 搭配使用

此外,Security Command Center 还内置了 KMS 漏洞检测器。这些检测器有助于确保包含密钥的项目遵循我们推荐的最佳实践。如需详细了解 KMS 漏洞检测器,请参阅 Cloud KMS 漏洞发现结果

后续步骤