默认对静态数据进行加密

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

Google 的全面安全策略包括静态数据加密，可帮助保护客户数据免遭攻击者的攻击。我们使用一种或多种加密机制对所有 Google 客户内容进行加密，客户不需要执行任何操作。本文档介绍了我们在 Google 基础设施和 Google Cloud 中采用的默认静态加密方法，以及我们如何使用此方法来进一步确保客户内容的安全。

本文档面向当前正在使用或考虑使用 Google 的安全架构师和安全团队。本文档假定您对加密和密码学原语有基本的了解。如需详细了解加密，请参阅现代密码学简介。

静态加密是指用于帮助保护存储在磁盘（包括固态硬盘）或备份介质上的数据的加密手段。Google 存储的所有数据均使用高级加密标准 (AES) 算法 AES-256 在存储层进行加密。我们使用通用加密库 Tink（其中包含 FIPS 140-2 验证的模块（名为 BoringCryptoBoringCrypto）在 Google Cloud 中一致地实现加密。

我们拥有并管理默认静态加密中使用的密钥。如果您使用 Google Cloud，则可以通过 Cloud Key Management Service 创建自己的加密密钥，并使用这些密钥为数据添加信封加密。使用 Cloud KMS，您可以创建、轮替、跟踪和删除密钥。如需了解详情，请参阅 Cloud Key Management Service 深入探究。

静态加密如何有助于保护数据

静态加密是涉及范围更广的安全策略的一部分。加密具有以下优势：

  • 在数据落入攻击者之手时，帮助确保攻击者在无法访问加密密钥时无法读取数据。也就是说，即使攻击者拿到了包含客户数据的存储设备，他们也无法理解或解密数据。
  • 通过削减硬件和软件堆栈的较低层级，帮助缩小受攻击面。
  • 充当关卡，因为集中管理的加密密钥将数据访问权限的实施和审核集中到了一起。
  • 有助于缩小攻击面，因为企业可以将保护策略重点放在加密密钥上，而无需保护所有数据。
  • 为客户提供了重要的隐私保护机制。数据经过静态加密后，会限制系统和工程师对数据的访问权限。

什么是客户数据？

根据 Google Cloud 服务条款中的定义，“客户数据”是指客户或最终用户通过其账号下的服务提供给 Google 的数据。

客户内容是您自行生成或提供给我们的数据，例如存储在 Cloud Storage 存储桶、永久性磁盘卷和 Compute Engine 使用的磁盘快照中的数据。本文档主要介绍此类客户数据的默认静态加密。

客户元数据是指有关客户内容的数据，包括自动生成的项目编号、时间戳、IP 地址、Cloud Storage 中对象的字节大小或 Compute Engine 中的机器类型。客户元数据会受到合理的保护，以满足一贯的性能和持续运行的需要。本文档不侧重于元数据保护。

客户内容和客户元数据共同构成客户数据。

静态数据的默认加密

Google 使用一种或多种加密机制对以静态方式存储的所有客户内容进行加密，客户不需要执行任何操作。以下部分介绍了我们用于加密客户内容的机制。

多层级加密

Google 使用多层加密机制来保护数据。这种加密机制提高了数据保护的冗余度，让我们能够根据应用的需要选择最佳方法。

下图显示了通常用于保护 Google 生产数据中心内的用户数据的多层加密机制。所有用户数据要么采用分布式文件系统加密，要么采用数据库和文件存储加密；Google 生产数据中心内的所有数据要么采用存储设备加密，要么采用数据库和文件存储加密。

多层加密。

硬件和基础设施层级加密

所有 Google 存储系统都使用类似的加密架构，但实现细节因系统而异。我们会将数据分割为多个子文件块进行存储；每个块的大小可以达到数个 GB。每个块都使用单独的数据加密密钥 (DEK) 在存储级别进行加密：两个块不会具有相同的 DEK，即使它们属于同一客户或存储在同一台机器上。（Datastore、App Engine 和 Pub/Sub 中的一个数据块可能包含多个客户的数据。）

如果数据块发生更新，系统会使用新密钥对其进行加密，而不是重复使用现有密钥。这种数据分区方式（每个分区都使用不同的密钥）意味着即使发生潜在的 DEK 破解，“破解范围”也仅限于那一个数据区块。

Google 会在数据写入数据库存储系统或硬盘之前对数据进行加密。加密是所有 Google 存储系统的固有功能，而不是后期添加的功能。

每个数据块都有一个唯一标识符。访问控制列表 (ACL) 有助于确保每个块只能由已获授权的角色使用 Google 服务进行解密，并且授权角色仅会在该时间点获得访问权限。此访问限制有助于防止未经授权访问数据，从而加强数据安全性和隐私性。

每个区块都分布在我们的存储系统中，并以加密形式进行复制，以便于备份和灾难恢复。如果攻击者想要访问客户数据，则必须要知道并能够访问两件事：与他们想要的数据相对应的所有存储块，以及与这些存储块相对应的所有加密密钥。

下图显示了数据如何上传到我们的基础设施，然后分成加密的块以进行存储。

数据上传方式。

我们使用 AES 算法对静态数据进行加密。存储级别的所有数据都由 DEK 加密，DEK 默认使用 AES-256，但在 2015 年之前使用 AES-128 创建的少量永久性磁盘除外。AES 被广泛使用，因为 AES-256 和 AES-128 均被美国国家标准与技术研究院 (NIST) 推荐用于长期存储用途，并且 AES 通常包含在客户合规性要求中。

存储设备层级加密

除了存储系统级加密之外，数据还会在存储设备级使用 AES-256（适用于硬盘驱动器 (HDD) 和固态硬盘 (SSD)）进行加密，并使用单独的设备级密钥（与在存储级别加密数据所用的密钥不同）。少量旧式普通硬盘使用 AES-128。Google 使用的固态硬盘为用户数据单独使用 AES-256。

备份加密

我们的备份系统可确保数据在整个备份过程中保持加密状态。此方法可避免不必要的明文数据暴露。

此外，备份系统还使用专属的 DEK 对大多数备份文件进行独立加密。DEK 派生自存储在密钥库中的密钥和备份时为每个文件随机生成的种子。对于备份中的所有元数据会使用另一个 DEK，此密钥也存储在密钥库中。

存储中的数据符合 FIPS 要求

Google 在生产环境中使用 FIPS 140-2 验证的加密模块（证书 4407）。

密钥管理

由于 Google 的密钥很多，且需要提供低延迟、高可用性的服务，因此 DEK 存储在用其加密的数据附近。DEK 使用信封加密技术，通过密钥加密密钥 (KEK) 进行加密。这些 KEK 并非特定于客户；每项服务都有一个或多个 KEK。

这些 KEK 集中存储在密钥库中，后者是一个专为存储密钥而构建的存储区。使用较少数量的 KEK（相较于 DEK），再加上集中式密钥库，使得管理 Google 规模的数据存储和加密成为可能，同时还让我们可以集中跟踪和控制对数据的访问。

在 Google Cloud 中，每个客户都可以拥有共享资源和非共享资源。共享资源的一个示例是 Compute Engine 中的共享基础映像。对于共享资源，多个客户引用同一个副本，该副本由单个 DEK 加密。非共享资源会被拆分为数据块，并使用与其他客户使用的密钥不同的密钥进行加密。即使是同一位客户所拥有的同一部分数据，保护其各块的密钥也各不相同。有些服务（例如 Datastore、App Engine 或 Pub/Sub）除外，在这些服务中，多位客户的数据可能会使用相同的 DEK 进行加密。

生成 DEK

存储系统使用 Google 的通用加密库生成 DEK。然后，DEK 通常会发送到密钥库，以使用该存储系统的 KEK 进行封装，然后再将封装的 DEK 传递回存储系统与数据块保存在一起。如果存储系统需要检索加密数据，则会检索封装的 DEK 并将其传递给密钥库。密钥库随后会验证此服务是否有权使用 KEK，如果有权使用，则解封装并将明文 DEK 返回给服务。该服务随后使用 DEK 将数据块解密为明文并验证其完整性。

所有 Google Cloud 存储系统都遵循此密钥管理模型，但大多数系统还会实现额外的存储方 KEK 级别，以创建密钥层次结构。这样一来，系统就可以使用最高级别的 KEK（存储在密钥库中）作为其信任根，从而提供低延迟。

生成 KEK

用于加密数据块的大多数 KEK 都在密钥库内生成，其余的 KEK 则在存储服务内生成。为了保持一致性，所有 KEK 都通过由 Google 构建的随机数字生成器 (RNG)，使用 Google 的通用加密库生成。此 RNG 基于 NIST 800-90Ar1 CTR-DRBG，可生成一个 AES-256 KEK。（过去采用的是 AES-128 标准，现在仍有一些此类密钥用于数据解密。）

对于 Intel 和 AMD 处理器，RNG 源自 RDRAND 指令和 Linux 内核的 RNG。反过来，Linux 内核的 RNG 源自多个独立的来源，包括 RDRAND 和数据中心环境的 entropic 事件（例如，磁盘寻道和内部数据包到达时间的精细测量）。对于 Arm 处理器，RNG 源自 Linux 内核的 RNG。

DEK 可使用 AES-256 或 AES-128 标准的 KEK 进行封装，具体取决于使用的 Google Cloud 服务。我们目前正在努力将 Google Cloud 服务的所有 KEK 升级到 AES-256。

KEK 管理

密钥库专门用于管理 KEK。根据设计，存储系统使用的 KEK 无法从密钥库中导出；使用这些密钥进行的所有加密和解密操作必须在密钥库内完成。此设计有助于防止数据泄露和滥用，可让密钥库在使用密钥时创建审核跟踪。

密钥库可定期自动轮替 KEK，并使用 Google 的通用加密库生成新密钥。虽然我们在谈论 KEK 时经常将它视为一个密钥，但实际上我们用来保护数据的是一组密钥：一个用于加密的密钥和多个用于解密的历史密钥组成的集合。历史密钥的数量取决于密钥轮替时间表。KEK 会进行备份以用于灾难恢复，且密钥恢复期限没有限制。

KEK 的使用由密钥库中的 ACL 根据每个密钥的政策分别进行管理。只有已获授权的 Google 服务和用户有权访问密钥。系统会按照需要密钥的单个操作分别跟踪每个密钥的使用情况。也就是说，每当用户使用密钥时，系统都会进行身份验证和记录。作为 Google 整体安全和隐私权政策的一部分，用户对数据的所有访问都是可审计的。

访问加密数据块的流程

当 Google 服务访问加密的数据块时，会发生以下情况：

  1. 服务针对其所需的数据调用存储系统。
  2. 存储系统会识别该数据的存储块（块 ID）以及块的存储位置。
  3. 对于每个块，存储系统都会拉取与该块一起存储的封装 DEK（在某些情况下，此过程由服务完成），并将其发送到密钥库进行解封装。
  4. 存储系统验证所识别的作业是否有权访问该数据块（根据作业标识符并使用块 ID）。密钥库验证存储系统是否获得了使用与该服务相关联的 KEK 以及将该特定的 DEK 解封的授权。
  5. 密钥库执行以下操作之一：
    • 将解封装的 DEK 传递回存储系统，由存储系统对数据块进行解密并将数据块传递给服务。
    • 在极少数情况下，将解封的 DEK 传递给服务。存储系统将加密的数据块传递给服务，由该服务对数据块进行解密并使用。

此过程在专用存储设备中会有所不同，在专用存储设备中，将由设备来管理和保护设备级 DEK。

下图展示了此过程。 为了对数据块进行解密，存储服务会调用密钥库来检索该数据块的解封装 DEK。

用于加密数据块的过程。

加密密钥层次结构和信任根

密钥库受到名为“密钥库主密钥”的根密钥的保护，该密钥会封装密钥库中的所有 KEK。此密钥库主密钥采用 AES-256 标准，它本身存储在另一个名为“Root Keystore”的密钥管理服务中。（过去，密钥库主密钥采用的是 AES-128 标准，现在仍有一些此类密钥用于数据解密。）为了提高安全性，根密钥库不会在常规的生产机器上运行，而是仅在每个 Google 数据中心内的专用机器上运行。

根密钥库又有自己的根密钥，称为根密钥库主密钥，该密钥也是 AES-256，存储在点对点基础架构中，名为根密钥库主密钥分发服务器，该副本在全球范围内复制这些密钥。（过去，根密钥库主密钥采用的是 AES-128 标准，现在仍有一些此类密钥用于数据解密。）根密钥库主密钥分发服务器只会将密钥保存在根密钥库所在的专用机器的 RAM 中，并根据日志记录来验证使用是否恰当。

启动根密钥库主密钥分发服务器的一个新实例时，系统会根据已运行分发服务器的主机名列表对其进行配置。分发服务器实例随后可以从其他正在运行的实例获取根密钥库主密钥。除了全球可用性和复制中介绍的灾难恢复机制之外，根密钥库主密钥仅存在于数量有限且受到特别保护的机器的 RAM 中。

为了应对根密钥库主密钥分发服务器的所有实例同时重启的情况，我们还在安全的硬件设备上备份根密钥库主密钥。这些设备保存在实体保险箱中，分别位于地理位置分散的多个区域的高度安全区域中。仅当某个区域中的所有分发服务器实例同时关闭时才需要此备份。只有少数 Google 员工可以访问这些保险箱。

下图显示了加密密钥层次结构。加密密钥层次结构使用 DEK 保护数据块，该 DEK 使用密钥库中的 KEK 封装，而 KEK 又受到根密钥库和根密钥库主分发服务器的保护。

加密密钥层次结构。

摘要：密钥管理

以下列表总结了 Google 的密钥管理：

  • 对数据进行分块并使用 DEK 进行加密。
  • DEK 使用 KEK 进行加密。
  • KEK 存储在密钥库中。
  • 密钥库在全球数据中心的多台机器上运行。
  • 密钥库密钥使用密钥库根密钥进行封装，后者存储在根密钥库中。
  • 根密钥库比密钥库小得多，并且仅在每个数据中心内的专用机器上运行。
  • 根密钥库密钥使用根密钥库主密钥进行封装，后者存储在根密钥库主分发服务器中。
  • 根密钥库主密钥分发服务器是一个点对点基础架构，在全球各地专用机器的 RAM 中并发运行。每台机器都会从该区域中的其他正在运行的实例获取其密钥材料。
  • 如果一个区域的所有分发服务器实例都关闭，则主密钥存储在 Google 有限位置的物理保险箱中的不同安全硬件中。

全球可用性和复制

高可用性、低延迟和密钥可全球访问在每个层级都至关重要。需要具备这些特征，才能在 Google 使用 KMS。

出于这个原因，密钥库具有极强的可扩缩性，并且会在全球各地的数据中心中复制数千个副本。密钥库使用 Google 生产环境中的常规机器，它的许多实例在全球范围内运行，以支持 Google 的正常运作。因此，任何单个密钥操作的延迟都非常低。

根密钥库在每个数据中心的几台专用于安全操作的机器上运行。根密钥库主密钥分发服务器也在这些机器上运行，与根密钥库一一对应。根密钥库主密钥分发服务器使用 Gossip 协议提供分发机制。分发服务器的每个实例会定期随机选择一个其他实例来比较其密钥，并协调密钥版本中的任何差异。在此模型中，不存在 Google 的所有基础设施都需要依赖的中心节点；通过这种分发方法，我们可以维护和保护具备高可用性的密钥材料。

Google 的通用加密库

Google 通用加密库是 Tink，它已合并至我们的 FIPS 140-2 验证模块 BoringCrypto 中。Tink 可供所有 Google 开发者使用。一致地使用通用库意味着只需一个小型密码学专家团队就能实现和维护这一受到严格控制和审核的代码，因此不需要 Google 的每个团队都构建自己的加密机制。一个特殊的 Google 安全团队会负责为所有产品维护此通用加密库。

Tink 加密库支持各种加密密钥类型和模式，而且这些加密密钥类型和模式会受到定期审查，确保能够应对最新的攻击。

目前，我们使用以下加密算法对 DEK 和 KEK 进行静态加密。我们会不断改善功能并提高安全性，因此这些加密算法随时可能发生变化。

密码学原语 首选协议 其他受支持的协议
对称加密 AES-GCM（256 位）
  • AES-CBC 和 AES-CTR（128 位和 256 位）
  • AES-EAX（128 位和 256 位）
对称签名（与上面的 AES-CBC 和 AES-CTR 配合使用以进行身份验证） HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

该库中还存在其他过去曾经支持的加密协议，但是此表格中仅包括 Google 中主要使用的加密协议。

加密研究与创新

为了跟上加密技术的发展步伐，我们拥有一支优秀的安全工程师团队，负责追踪、开发和改进加密技术。我们的工程师参与标准化流程并维护广泛使用的加密软件。我们定期发布我们在加密领域的研究成果，以便每个人（包括普通大众）都可以从我们分享的知识中受益。

例如，在后量子加密研究方面，我们正在以下领域开展工作：

请注意，对称加密（使用 AES-128 或更高版本）仍然可以抵御量子攻击。

后续步骤