默认对静态数据进行加密

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

在 Google，我们全面的安全策略包含静态加密，这有助于保护客户的内容免遭攻击。我们使用一种或多种加密机制对所有 Google 客户静态内容进行加密，您无需执行任何操作。本文档介绍了 Google 基础架构和 Google Cloud 默认静态加密的方法，以及我们如何使用该方法来确保客户信息的安全性。

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

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

我们管理默认静态加密使用的密钥。如果您使用 Google Cloud，则 Cloud Key Management Service 可让您创建自己的加密密钥，该密钥可用于为您的数据添加信封加密。您可以使用 Cloud KMS 创建、轮替、跟踪和删除密钥。如需了解详情，请参阅 Cloud Key Management Service 深度解释。

静态加密如何帮助保护数据

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

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

什么是客户数据？

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

客户内容是您自行生成或提供给我们的数据，例如存储在 Cloud Storage 中的数据、Compute Engine 使用的磁盘快照，以及 IAM 政策。本文档重点介绍客户内容的默认静态加密。

客户元数据构成数据的其余部分。客户元数据可能包括自动生成的项目编号、时间戳、IP 地址、Cloud Storage 中对象的字节大小或 Compute Engine 中的机器类型。元数据会受到合理的保护，以满足一贯的性能和持续运行的需要。

静态数据的默认加密

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

多层级加密

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

下图展示了通常用于保护 Google 生产数据中心中用户数据的多层加密。对用户数据进行分布式文件系统加密或数据库和文件存储加密，并对 Google 生产数据中心中的所有数据采用存储设备加密。

多层加密。

硬件和基础架构层加密

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

如果数据块发生更新，系统会使用新密钥对其进行加密，而不是重复使用现有密钥。这种数据分区方式（每个分区都使用不同的密钥）可以降低只有潜在的数据加密密钥被破解的数据风险。

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 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 标准，现在仍有一些此类密钥用于数据解密。）

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

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，它本身存储在另一个名为“根密钥库”的密钥管理服务中。（过去，密钥库主密钥是 AES-128，而且其中一些密钥可用于解密数据。） 根密钥库存储的密钥数量要少得多（每个区域大约十二个）。为了提高安全性，根密钥库不会在常规的生产机器上运行，而是仅在每个 Google 数据中心内的专用机器上运行。

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

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

为了应对地区中的根密钥库主密钥分发服务器的所有实例同时重启的情况，根密钥库主密钥也会进行备份，这些信息存储在高度安全的物理保险箱中位于多个地理位置的受保护区域。仅当某个区域中的所有分发服务器实例同时关闭时才需要此备份。能够接触这些保险箱的 Google 员工不超过 100 人。

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

加密密钥层次结构。

密钥管理摘要

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

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

全球可用性和复制

每个级别的高可用性、低延迟和密钥访问在全球范围内至关重要。这些特性需要在 Google 的所有服务中使用。

因此，密钥库具有极高的可伸缩性，并且在全球的数据中心中有数以千计的副本。它在我们的生产队列中的常规机器上运行，密钥库实例在全球范围内运行以支持 Google 的操作。因此，任何单个密钥操作的延迟都非常低。

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

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 的主要用途。

加密研究与创新

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

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

后续步骤