Cloud Key Management Service 深度解释

作者Sonal Shah、Il-Sung Lee、Walter Poupore、Hunter Freyer、Honna Segel、Dwight Worley

致谢Adrian Sears、John Randolph、Tim Dierks、Chris Rezek、Stanley McKenzie、Kevin Plybon、David Hale、Sergey Simakov、David U.Lee、Carrie McDaniel、Anton Chuvakin、Dave Tonisson

最后更新时间:2020 年 4 月。

1. 简介

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

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

借助 Cloud KMS 平台,Google Cloud 客户可以通过中央云服务管理加密密钥,以直接使用或供其他云资源和应用使用。Cloud KMS 针对密钥来源提供以下选项:

  • Cloud KMS 软件后端让您可以灵活地使用您控制的对称密钥或不对称密钥 (Cloud KMS) 加密数据。
  • 如果需要硬件密钥,可以使用 Cloud HSM 来帮助确保对称密钥和不对称密钥只会用在经过 FIPS 140-2 3 级验证的硬件安全模块 (HSM) 中。
  • 如果您需要使用自己生成的密钥,Cloud KMS 让您可以导入自己的加密密钥
  • 您可以选择将 Cloud KMS 生成的密钥与其他 Google Cloud 服务搭配使用。此类密钥被称为客户管理的加密密钥 (CMEK)。借助 CMEK 功能,您可以生成、使用、轮替和销毁用于帮助保护其他 Google Cloud 服务中数据的加密密钥。
  • 借助 Cloud External Key Manager (Cloud EKM),您可以在 Google Cloud 外部的密钥管理器中创建和管理密钥,然后设置 Cloud KMS 平台以使用外部密钥来帮助保护存储中的数据(静态数据)。您可以将 CMEK 与 Cloud EKM 密钥搭配使用。目前,Cloud EKM 超出了本白皮书的说明范围。

Google 还支持在 Compute Engine 和 Cloud Storage 中使用客户提供的加密密钥 (CSEK),用 API 调用中提供的密钥来解密和加密数据。CSEK 超出了本白皮书的说明范围。如需了解详情,请参阅在线文档

“KMS 产品组合图”

通过 Cloud KMS,Google 可专注于提供可扩缩、可靠且高性能的解决方案,在使用方便的平台上提供最广泛的可控制选项。Cloud KMS 的设计有五大重点:

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

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

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

本部分说明了 Google 多层密钥管理基础架构环境中一些密钥管理术语和定义。

2.1. 密钥、密钥版本和密钥环

本部分介绍了密钥、密钥版本以及如何将密钥分组为密钥环。下图展示了密钥的分组方式。相关定义紧跟在图表后面。

“密钥分组图。”

  • 密钥:一个已命名对象,表示用于特定用途的加密密钥。随着新密钥版本的创建,密钥材料(用于加密操作的实际位)会随着时间的推移而改变。

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

    Cloud KMS 同时支持不对称密钥和对称密钥。对称密钥用于对称加密,以保护某些数据主体,例如,在 GCM 模式下使用 AES-256 可加密一个明文块。不对称密钥可用于不对称加密或创建数字签名。如需了解支持的用途和算法,请参阅 Cloud KMS 文档。

  • 密钥环:用于对密钥进行分组,以便进行整理。密钥环属于 Google Cloud 项目,并且位于特定位置。密钥会继承其所属密钥环的 IAM 政策。通过将具有相关权限的密钥分组为具体的密钥环,您可以在密钥环级别授予、撤消或修改这些密钥的权限,而无需单独对每个密钥执行操作。密钥环可提供便利性和分类功能,但如果密钥环的分组对您没有用,您可以直接管理密钥的权限。

    为防止资源名称发生冲突,不能删除密钥环。密钥环和密钥没有可结算费用或配额限制,因此它们的持续存在不会对费用或生产环境限制产生任何影响。如需详细了解如何删除密钥和密钥材料,请参阅本白皮书后面有关删除的部分。

  • 密钥元数据:资源名称、KMS 资源的属性,例如 IAM 政策、密钥类型、密钥大小、密钥状态以及根据上述内容派生的任何数据。密钥元数据的管理方式可以不同于密钥材料。

  • 密钥版本:表示在某个时间点与密钥关联的密钥材料。密钥版本是包含实际密钥材料的资源。系统会从版本 1 开始按顺序为各版本编号。轮替密钥时,系统会使用新的密钥材料创建新的密钥版本。同一逻辑密钥在一段时间内可以有多个版本,从而限制了任何单个版本的使用。对称密钥将始终有一个主要版本。默认情况下,此版本用于加密。当 Cloud KMS 使用对称密钥执行解密时,会自动识别执行解密所需的密钥版本。

2.2. 密钥层次结构

下图展示了 Google 内部密钥管理服务的密钥层次结构。Cloud KMS 使用 Google 的内部 KMS,因为 Cloud KMS 加密的密钥由 Google KMS 封装。Cloud KMS 使用与 Google KMS 相同的信任根。相关定义在图表之后。

“内部密钥层次结构图”

  • 数据加密密钥 (DEK):用于加密数据的密钥。
  • 密钥加密密钥 (KEK):用于加密或“封装”数据加密密钥的密钥。所有 Cloud KMS 平台选项(软件、硬件和外部后端)都可让您控制密钥加密密钥。
  • KMS 主密钥:用于加密 KEK 的密钥。此密钥分布在内存中。KMS 主密钥备份在硬件设备上。此密钥负责加密您的密钥。
  • 根 KMS:Google 的内部密钥管理服务。

2.3. 运维

  • 项目:Cloud KMS 资源属于 Google Cloud 项目,就像所有其他 Google Cloud 资源一样。您可以将数据托管在 Cloud KMS 密钥所在项目以外的另一个的项目中。此功能可支持对密钥管理员和数据管理员之间进行职责分离的最佳做法。
  • 位置:在项目中,系统会在某个位置创建 Cloud KMS 资源。如需了解详情,请参阅地理位置和区域

3.Cloud KMS 平台概览

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

“Cloud KMS 架构图。”

上图显示了 Cloud KMS 平台的主要组成部分。管理员通过以下方式访问密钥管理服务:使用 Google Cloud Console 或 gcloud 命令行工具,或者通过实现 REST 或 gRPC API 的应用。应用使用 REST APIgRPC 访问密钥管理服务。应用可以使用启用了 CMEK 的 Google 服务。CMEK 则使用 Cloud KMS API。借助 Cloud KMS API,您可以使用软件 (Cloud KMS) 或硬件 (Cloud HSM) 密钥。基于软件和基于硬件的密钥均利用 Google 的冗余备份保护机制。

借助 Cloud KMS 平台,您可以在创建密钥时选择保护级别,以确定由哪个密钥后端创建密钥并对该密钥执行所有后续加密操作。Cloud KMS 平台提供了两个后端(不包括 Cloud EKM),它们在 Cloud KMS API 中显示为 SOFTWAREHSM 保护级别。保护级别 SOFTWARE 适用于可由软件安全模块解除封装以执行加密操作的密钥。保护级别 HSM 适用于只能由硬件安全模块解除封装的密钥(硬件安全模块使用密钥执行所有加密操作)。

Google Cloud 支持将 CMEK 用于多项服务,包括 Cloud Storage、BigQuery 和 Compute Engine。CMEK 让您可以使用 Cloud KMS 平台管理这些服务用于帮助保护数据的加密密钥。

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

3.1. 环境和依赖项

本部分详细介绍了运行 Cloud KMS 平台的 Google 基础架构以及基础架构使用的通信协议。

3.1.1. Cloud KMS Borg 作业

Cloud KMS 平台元素会以生产环境 Borg 作业的形式运行。Borg 是 Google 的大型集群管理器,用于处理 API 传送作业和批处理作业。如需详细了解我们物理和生产环境基础架构的安全性,请参阅 Google 基础架构安全设计概览

3.1.1.1.Cloud KMS API 传送作业

Cloud KMS API 传送作业是生产环境 Borg 作业,用于传送客户管理和使用其密钥的请求。这些传送作业在提供 Cloud KMS 的每个 Google Cloud 区域内运行。每个作业都与单个区域关联,并且配置为仅访问地理位置位于关联 Google Cloud 区域内的系统的数据。如需详细了解密钥驻留,请参阅本白皮书稍后所述的区域性

3.1.1.2. Cloud KMS 批处理作业

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

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

为了保持高可用性,Cloud KMS 平台会在托管 Cloud KMS API 服务器任务的共享服务的每个实例中,保留一个冗余数据存储区。每项服务都会部署自己的快照程序服务实例。这种冗余性使得服务高度独立,因此在一个可用区发生的故障对其他可用区的影响有限。当 Cloud KMS API 作业需要执行加密操作时,会同时查询主数据存储区和本地快照程序作业。然后,Cloud KMS API 会使用首先成功完成请求的作业。为了防止快照流水线中出现延迟,进而可能导致传送过于陈旧的数据,如果数据存在的时间超过两个小时,则 API 服务器不会使用快照程序作业生成的结果。系统会创建快照,以作为针对每个区域持续运行的批处理作业的输出。快照驻留在与密钥材料关联的云区域。

3.1.2. 客户端-服务器通信

Google 使用应用层传输安全 (ALTS) 来为使用 Google 远程过程调用 (RPC) 机制的客户端-服务器通信(传输加密)提供安全保障。ALTS 提供以下各项:

  • 应用的点对点身份验证协议
  • 记录加密协议
  • 公开通过身份验证的用户以进行授权的 API

ALTS 握手和记录加密协议类似于传输层安全 (TLS) 握手记录协议。为了针对 Google 的生产环境进行优化,ALTS 做了不同的权衡,并且 ALTS 已完全集成到整个生产环境硬件和软件栈中。如需了解详情,请参阅本白皮书稍后所述的 Cloud KMS 平台运营环境

4. Cloud KMS 平台架构详情

本部分将从密钥材料的安全性数据存储区保护机制开始,逐步深入探讨架构详细信息。接着再详细说明密钥材料来源的选项:

本部分还介绍了 CMEK 的选项。

为了让您能够动态地了解之前介绍的架构结构的使用方式,本白皮书介绍了 Cloud KMS 请求的生命周期,包括有关销毁密钥材料的内容。

4.1. 密钥材料的安全性

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

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

发送给 Cloud KMS 的客户请求在传输过程中会被加密,所使用的协议为客户与 Google Front End (GFE) 之间的传输层安全协议 (TLS)。之前在有关客户端-服务器通信的部分介绍的应用层传输安全 (ALTS) 用于 Cloud KMS 作业及其在不同数据中心的后端之间的加密。本白皮书稍后所述的 Cloud KMS 请求的生命周期部分详细介绍了 ALTS 和传输加密。

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

Google 的政策是确保作业仅使用以可验证方式构建、测试和审核的源代码。Binary Authorization for Borg (BAB) 在操作级别执行此政策,此安全文档中对此有详细介绍。

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

但是,Cloud KMS API 作业无法访问密钥材料,用户也无法通过 API 接口或其他界面导出或查看密钥材料。Google 员工无权访问未加密的客户密钥材料。密钥材料还通过 Root KMS 中的主密钥另外进行了加密,该主密钥任何个人都无法直接访问。

4.2. 数据存储区保护机制

本部分介绍了 Google KMS 如何保护密钥数据。

4.2.1.主密钥

Cloud KMS 使用主密钥封装所有静态客户密钥。每个 Cloud KMS 服务器都会在启动时提取主密钥的副本作为硬依赖项,并每天检索主密钥的新副本。主密钥会定期重新加密。

4.2.2. 轮替政策

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

4.2.3. 数据驻留

每个 Cloud KMS 数据存储区的基础数据只会保留在与该数据关联的 Google Cloud 区域内。此规则也适用于多区域位置,例如 us 多区域。如需详细了解数据驻留,请参阅本白皮书稍后所述的区域性

4.3. 密钥创建后的可用性

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

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

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

4.4.1. 算法实现

对于软件密钥,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 不对称加密密钥进行的加密、解密和签名操作。

4.4.2. 随机数的生成和熵

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

4.5. Cloud KMS HSM 后端:硬件保护级别

Cloud HSM 服务向 Cloud KMS 提供硬件支持的密钥,使客户能够管理和使用受 Google 数据中心内全代管式硬件安全模块 (HSM) 保护的加密密钥。该服务具有高可用性,并且会自动横向扩容。密钥以加密方式绑定到定义了密钥环的 KMS 区域。使用 Cloud HSM,您创建和使用的密钥无法在位于创建密钥时指定的区域的 HSM 集群之外具体化。借助 Cloud HSM,您能够以可验证的方式证明您的加密密钥仅在一个硬件设备中创建和使用。现有 Cloud KMS 客户无需更改应用即可使用 Cloud HSM:可使用与 Cloud KMS 软件后端相同的 API 和客户端库访问 Cloud HSM 服务。

Cloud HSM 使用通过 FIPS 140-2 3 级验证且始终在 FIPS 模式下运行的 HSM。FIPS 标准指定了 HSM 使用的加密算法和随机数生成方式。

4.5.1. Cavium HSM

Caiumium HSM PCIe 卡已经过供应商验证,符合 FIPS 140-2 3 级。当前证书可应要求提供。

4.5.2. HSM 密钥层次结构

在下图中,Cloud KMS 显示在图的上半部分。Cloud HSM 会封装客户密钥,然后 Cloud KMS 会封装传递给 Google 数据存储区的 HSM 密钥。

“HSM 密钥层次结构图”

Cloud HSM 有一个密钥(未显示),该密钥控制 Cloud HSM 管理网域中的密钥材料迁移。一个区域可能有多个 HSM 管理网域。

HSM 根密钥有两个特征:

  1. 它是在 HSM 中生成的,在整个生命周期内始终不会离开明确定义的 HSM 边界。它可以复制到其他 HSM 或备份 HSM 中。
  2. 它可以用作密钥加密密钥,以直接或间接封装 HSM 使用的客户密钥。

由 HSM 根密钥封装的客户密钥可以在 HSM 中使用,但 HSM 永远不会返回客户密钥的明文;HSM 仅使用客户密钥进行操作。

4.5.3. 数据存储区保护机制

HSM 不会用作密钥的永久存储空间;它们仅在密钥被使用时存储密钥。由于 HSM 存储空间受限,HSM 密钥会进行加密并存储在 Cloud KMS 密钥数据存储区中。本白皮书稍后所述的数据存储区后端部分对此主题进行了详细介绍。

4.5.4. 轮替政策

Cloud HSM 的密钥保护策略涉及多种密钥。客户会轮替自己的密钥,并依赖于 Cloud KMS 轮替 HSM 密钥。

4.5.5. 预配和处理过程

HSM 的预配是在配备大量物理和逻辑保护措施(包括多方授权控制机制)的实验室中进行的,以帮助防止单方破坏。

Cloud HSM 的系统级不变量如下:

  1. 客户密钥无法提取为明文。
  2. 客户密钥不能移出来源区域。
  3. 对预配 HSM 的所有配置更改都通过多项安全防护措施加以保护。
  4. 系统会记录管理操作,并遵循 Cloud HSM 管理员和日志记录管理员之间的职责分离规定。
  5. HSM 的设计可防止在整个操作生命周期中被篡改(例如插入恶意硬件或软件修改,或者未经授权提取密文)。

4.5.6. 供应商控制的固件

HSM 固件由 HSM 供应商进行数字签名。Google 无法创建或更新 HSM 固件。来自供应商的所有固件均经过签名,包括用于测试的开发固件。

4.5.7. 区域性

客户密钥会因绑定到特定 HSM 根密钥而被分配到特定的地理区域。例如,专门在 us-west1 区域中创建的密钥无法迁移到 us-east1 区域或 us 多区域。同样,在 us 多区域中创建的密钥不能迁移到us-west1 区域或从中迁移出去。

4.6. Cloud KMS:密钥导入

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

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

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

导入的密钥可与 HSMSOFTWARE 保护级别搭配使用。

对于 Cloud HSM,封装密钥的私钥部分只能在 Cloud HSM 内部使用。限定只能在 Cloud HSM 内部使用私钥部分可防止 Google 在 Cloud HSM 之外解封您的密钥材料。

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

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

以下主题详细介绍了与支持 CMEK 的 Cloud KMS 平台集成的产品:

密钥轮替对所使用密钥版本的影响取决于产品如何实现 CMEK。通常,轮替 Cloud KMS 密钥不会重新加密关联的 CMEK 服务中的数据。例如,当与表关联的 Cloud KMS 密钥轮替时,BigQuery 不会自动轮替表加密密钥。现有 BigQuery 表将继续使用其创建时所用的密钥版本。新的 BigQuery 表使用当前的密钥版本。如需了解详情,请参阅每个产品的文档。

如需查看 CMEK 集成和兼容 CMEK 的服务的完整列表,请参阅此文档。Google 会继续在其他 Google Cloud 产品的 CMEK 集成方面保持投入。

4.8. Cloud KMS 请求的生命周期

为了让您能够动态地了解之前介绍的架构结构的使用方式,此部分介绍了 Cloud KMS 请求的生命周期,包括有关销毁密钥材料的内容。

“KMS 请求生命周期图”

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

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

4.9. 销毁密钥材料

白皮书介绍了如何删除 Google Cloud 中的数据。密钥材料被视为客户数据,因此白皮书中介绍的方法适用于 Cloud KMS。此外,由于 Google 绝不会在 Cloud KMS 之外共享密钥材料,因此当 24 小时待删除期结束且备份过期后,密钥材料会根据请求被销毁。此过程不保证适用于在 Cloud KMS 控制范围之外的导入密钥副本。

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

在密钥版本被安排销毁之后,将无法用于加密操作。在 24 小时内,用户可以恢复密钥版本,使其不被销毁。

5. Cloud KMS 平台运营环境

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

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

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

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

5.2. Cloud KMS 资源的区域性

您可以在以下四种 Google Cloud 位置中的任一种位置创建 Cloud KMS 资源:

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

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

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

5.2.1. 云区域和数据中心

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

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

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

5.2.2. 区域性

某些行业要求将加密密钥存放在特定位置。如上面的 Cloud KMS 资源的区域性中所述,Cloud KMS 提供四种类型的区域位置来帮助您满足这些要求。

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

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

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

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

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

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

Cloud KMS 数据驻留 静态、使用中
(单区域)
静态、使用中
(双区域/多区域)
软件密钥材料 常驻 常驻在构成双区域/多区域的区域。
硬件密钥材料 (HSM) 常驻 常驻在构成双区域/多区域的区域。

5.2.3. 区域性监控

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

5.3. 身份验证和授权

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
  • 检查客户是否列在适用的私有云区域的许可名单中。

5.4. 日志记录

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

5.4.1. Cloud 审核日志

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

5.4.2. Access Transparency 日志

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

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

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

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

5.4.3. 内部请求日志

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

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

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

5.5. 数据存储区后端

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 应用层,客户密钥材料会在存储之前进行加密。数据存储区工程师无权访问明文客户密钥材料。此外,数据存储区在将数据写入永久性存储区之前会对其管理的所有数据进行加密,因此,如果没有对数据存储区加密密钥(存储在 Google 内部 KMS 中)的访问权限,则在访问底层存储层(包括磁盘或磁带)时,将不允许访问加密的 Cloud KMS 数据。

6.更多详情

如需了解详情,请浏览以下资源:

白皮书:

其他文档: