Google Cloud 中的静态数据加密

本文包含的内容在 2017 年 4 月前均正确无误,代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制,Google Cloud 的安全政策和系统今后可能会发生变化。

“播放”按钮

Google Cloud 静态加密

面向首席信息官级别领导者的摘要

  • Google 采用了多层加密措施来保护 Google Cloud 产品中的静态客户数据。
  • Google Cloud 使用一种或多种加密机制对以静态方式存储的客户内容进行加密,客户不需要执行任何操作。不过,存在一些无关紧要的例外情况,此文档中做了进一步说明
  • 数据会拆分为区块进行存储,每个区块使用唯一的数据加密密钥 (DEK) 进行加密。这些 DEK 会与数据一起存储,并使用密钥加密密钥 (KEK) 进行加密(又称“封装”)。KEK 是在 Google 的集中式 Key Management Service (KMS) 内存储和使用的专有密钥。Google 的 Key Management Service 是一项具有冗余性的全球分布式服务。
  • 存储在 Google Cloud 中的数据在存储层采用 AES256 或 AES128 进行加密。
  • Google 使用通用加密库 Tink,在几乎所有 Google Cloud 产品中以一致的方式实现加密。这是一个广泛使用的通用加密库,因此只需组建一个小型密码学专家团队就能妥善实施和维护其受到严格控制和审查的代码。

简介

对许多个人和公司而言,安全性是他们选择公有云服务商时的一个决定性因素。在 Google 看来,安全性是重中之重。我们非常重视安全和隐私,对保护您的数据不遗余力 - 无论这些数据是通过互联网传输、在我们的数据中心之间转移,还是存储在我们的服务器上。

我们的全面安全策略的核心是采用传输中加密方法和静态加密方法,确保角色和服务只有在经过审核并获得对加密密钥的访问权限后才能访问数据。本文介绍 Google 在 Google Cloud 中对静态数据采用的加密方法,以及 Google 如何使用此方法来进一步确保您的信息安全。

本文档面向当前正在使用或考虑使用 Google Cloud 的首席信息安全官 (CISO) 和安全运营团队。除了简介之外,本文档假定读者对加密和密码学原语具有基本的了解。

什么是加密

加密是一个过程,该过程将输入的可辨读数据(通常称为明文)进行转换,然后输出只透露极少量或完全不透露明文相关信息的密文。使用的加密算法是公开的,例如高级加密标准 (AES),但具体执行方式取决于密钥,而密钥是保密的。如需将密文解密回其原始形式,您需要使用该密钥。在 Google,使用加密来保持数据机密性的做法通常会与完整性保护机制相结合;有权访问密文的人在不知道密钥的情况下既不能理解密文,也不能进行修改。如需了解有关密码学的更多信息,请参阅现代密码学导论 (Introduction to Modern Cryptography)。

本白皮书重点介绍静态数据加密。“静态数据加密”是指为保护磁盘(包括固态硬盘)或备份介质上存储的数据而进行的加密。

为何加密有助于保护客户数据

加密是涉及范围更广的安全策略的一部分。加密为保护数据增加了一层深度防御措施,它可确保即使当数据意外落入攻击者之手,如果攻击者没有同时获得加密密钥,他们也不能访问数据。也就是说,即使攻击者拿到了包含您数据的存储设备,他们也无法理解或解密数据。

静态数据加密相当于“移除了”硬件和软件栈的较低层级,因此缩小了攻击面。即使这些较低层级被破解(例如,通过实际访问设备),只要采取了足够的加密保护,设备上的数据也不会被破解。加密还相当于设立了一处“咽喉要道”,集中管理的加密密钥将数据访问权限的实施和审核集中到了一起。

加密为 Google 确保客户数据隐私提供了一种重要机制,客户无需提供对数据内容的访问权限,便可让系统处理数据(例如备份),并为工程师支持我们的基础架构提供便利。

我们将哪些内容视为客户数据

根据 Google Cloud 服务条款中的定义,“客户数据”是指 Google Cloud 客户(或按照这些客户的指示行事的其他相关方)在通过客户的帐号使用 Google Cloud 服务期间,直接或间接向 Google 提供的内容。客户数据包括客户内容和客户元数据。

“客户内容”是 Google Cloud 客户自己生成或提供给 Google 的数据,例如存储在 Cloud Storage 中的数据、Compute Engine 使用的磁盘快照以及 Cloud Identity and Access Management 政策。本白皮书的重点就是静态客户内容加密。

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

Google 的默认加密方式

静态数据加密

多层级加密

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

加密层图表

图 1:我们采用多重加密机制来保护存储在 Google Cloud 中的数据。几乎所有文件不是采用分布式文件系统加密,就是采用数据库和文件存储加密;几乎所有文件都采用存储设备加密。

存储系统层级加密

如需了解 Cloud Storage 加密机制的具体运作方式,必须先了解 Google 如何存储客户数据。我们会将数据分割为多个子文件区块进行存储;每个区块的大小可以达到数个 GB。每个区块使用单独的加密密钥在存储系统级进行加密:两个区块不会共用同一个加密密钥,即使这两个区块属于同一个 Cloud Storage 对象、归同一位客户所有或者存储在同一台机器上,也是如此1。如果数据区块发生更新,系统会使用新密钥对其进行加密,而不是重复使用现有密钥。这种数据分区方式(每个分区都使用不同的密钥)意味着即使发生潜在的 DEK 破解,“破解范围”也仅限于那一个数据区块。

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

每个数据区块都有一个唯一标识符。访问控制列表 (ACL) 确保每个区块只能由已获授权的角色使用 Google 服务进行解密,并且授权角色仅会在解密那一刻获得访问权限。这可以防止对数据的未授权访问,从而加强数据的安全性和隐私性。

每个区块都分布在 Google 的存储系统中,并以加密形式进行复制,以便于备份和灾难恢复。如果有不良意图的个人想要访问客户数据,则必须要知道并能够访问 (1) 与他们需要的数据相对应的所有存储区块,以及 (2) 与这些区块相对应的加密密钥。

“存储在加密区块中的数据”示意图

图 2:在 Google,数据会被分割到多个加密区块进行存储。

Google 使用高级加密标准 (AES) 算法对静态存储的数据进行加密。AES 的使用范围极广,原因在于 (1) AES256 和 AES128 均被美国国家标准与技术研究院 (NIST) 推荐用于长期存储用途(从 2019 年 3 月起),以及 (2) AES 通常会被纳入客户合规性要求。

几乎在所有情况下,存储在 Cloud Storage 中的数据都会在存储系统级使用 AES(在伽罗瓦/计数器模式 (GCM) 下)进行加密。此加密方法在 Google 维护的 BoringSSL 库内实现。在 OpenSSL 暴露出许多缺陷后,我们从 OpenSSL 分支出了这个库以供内部使用。某些特定情况下,AES 在密码分组链接 (CBC) 模式下搭配哈希消息身份验证码 (HMAC) 用于身份验证;对于某些复制文件,AES 在计数器 (CTR) 模式下搭配 HMAC 使用。(如需了解有关算法的更多详细信息,请参阅后文中的章节。)在其他 Google Cloud 产品中,AES 在多种模式下使用。

存储设备级加密

除了上面介绍的存储系统级加密之外,多数情况下,还会使用单独的设备级密钥(与在存储系统级加密数据所使用的密钥不同),在存储设备级对数据进行加密:对于硬盘 (HDD),至少使用 AES128 加密;对于新型固态硬盘 (SSD),使用 AES256 加密。随着旧设备被逐步替换,未来将仅使用 AES256 进行设备级加密。

备份加密

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

此外,备份系统还使用专属的 DEK 对每个备份文件进行独立加密,此密钥源自存储在 Google KMS 中的密钥与备份时为每个文件随机生成的种子的组合。备份中的所有元数据会使用另一个 DEK,此密钥也存储在 Google 的 KMS 中。(如需了解有关密钥管理的更多信息,请参阅后文中的章节。)

是否存在数据未进行静态加密的情况?

Google Cloud 会利用一种或多种加密机制来加密静态存储的客户内容,而无需客户执行任何操作,但存在以下例外情况。

  • 来自 Compute Engine 中虚拟机的串行控制台日志;我们正在着手解决此问题
  • 进程意外失败时写入本地硬盘的核心转储信息;我们正在着手解决此问题
  • 写入本地磁盘的调试日志;我们正在着手解决此问题
  • 存储系统使用的临时文件;我们正在着手解决此问题
  • 可能包含客户内容和客户元数据的一些日志;我们已经计划解决此问题

此类数据仍然受到 Google 的其他安全基础架构的全面保护,并在几乎所有情况下,仍会受到存储系统级加密机制的保护。

密钥管理

DEK、KEK 和 Google 的 KMS

用于对区块中的数据进行加密的密钥称为 DEK(数据加密密钥)。由于 Google 的密钥很多,且需要提供低延迟、高可用性的服务,因此这些密钥都存储在用其加密的数据附近。DEK 本身又使用 KEK(密钥加密密钥)进行加密(也称为“封装”)。每项 Google Cloud 服务都有一个或多个 KEK。这些 KEK 集中存储在 Google 的 KMS(密钥管理服务) 中,这是一个专为存储密钥而构建的存储区。只需少量 KEK(少于 DEK)并使用集中式 KMS,就能轻松管理整个 Google 中的数据存储和加密,同时还让我们可以集中跟踪和控制对数据的访问。

系统会将每位 Google Cloud 客户的所有非共享资源2拆分为多个数据区块,并使用客户专属的密钥进行加密3。即使是同一位客户所拥有的同一部分数据,保护其各区块的 DEK 也各不相同。

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

用于加密数据区块的大多数 KEK 都在 KMS 内生成,其余的 KEK 则在存储服务内生成。为了保持一致性,所有 KEK 都通过由 Google 构建的随机数字生成器 (RNG),使用 Google 的通用加密库生成。此 RNG 基于 NIST 800-90Ar1 CTR-DRBG,可生成一个 AES256 KEK4。此 RNG 源自 Linux 内核的 RNG,而后者又源自多个独立的熵源。这包括来自数据中心环境的熵事件,例如磁盘寻道和内部数据包到达时间的精细测量结果,以及源自 Intel RDRAND 指令(在 Ivy Bridge 和更新款的 CPU 上可用)的熵事件。

如上所述,存储在 Google Cloud 中的数据通过使用 AES256 或 AES128 的 DEK 进行加密;而存储在 Compute Engine 永久性磁盘中的任何新数据都会使用 AES256 进行加密。DEK 可使用 AES256 或 AES128 标准的 KEK 进行封装,具体取决于使用的 Google Cloud 服务。我们目前正在努力将 Cloud 服务的所有 KEK 升级到 AES256。

Google 的 KMS 专用于管理 KEK,在设计时便已考虑到安全性。根据设计,KEK 不可从 Google 的 KMS 导出;使用这些密钥进行的所有加密和解密操作必须在 KMS 内完成。此设计有助于防止数据泄露和滥用,可让 KMS 对密钥的使用情况进行审计跟踪。

KMS 可定期自动轮替 KEK,并使用 Google 的通用加密库生成新密钥。虽然我们在谈论 KEK 时经常将它视为一个密钥,但实际上我们用来保护数据的是一组密钥:由一个用于加密的密钥和多个用于解密的历史密钥组成,历史密钥的数量由“密钥轮替时间表”决定。KEK 的实际轮替时间表因服务而异,但标准轮替期限为 90 天。具体来说,Cloud Storage 每 90 天轮替一次 KEK,最多可存储 20 个版本,至少每 5 年要重新加密一次数据(虽然在实践中,数据重新加密的频率会高出许多)。KMS 保存的密钥会进行备份以用于灾难恢复,且密钥恢复期限没有限制。

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

当 Google Cloud 服务访问加密的数据区块时,会发生以下情况:

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

此过程在专用存储设备(例如本地 SSD)中会有所不同,在专用存储设备中,将由设备来管理和保护设备级 DEK。

“数据区块解密”示意图

图 3:存储服务调用 Google KMS 来检索该数据区块的解封装 DEK,对数据区块进行解密。

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

Google 的 KMS 受到名为“KMS 主密钥”的根密钥保护,该密钥会封装 KMS 中的所有 KEK。此 KMS 主密钥采用 AES256 标准4,它本身存储在另一个名为“Root KMS”的密钥管理服务中。Root KMS 中存储的密钥数量要少得多(大约有十几个)。为了提高安全性,Root KMS 并不在常规的生产机器上运行,而是仅在每个 Google 数据中心内的专用机器上运行。

Root KMS 也有自己的根密钥,称为“根 KMS 主密钥”,此根密钥同样采用 AES256 标准4,存储在名为“根 KMS 主密钥分发服务器”的对等互连基础架构中,这个基础架构会在全球范围内复制这些密钥。根 KMS 主密钥分发服务器只会将密钥保存在 Root KMS 所在的专用机器的 RAM 中,并根据日志记录来验证使用是否恰当。每一个 Root KMS 实例都会运行一个根 KMS 主密钥分发服务器的实例。(根 KMS 主密钥分发服务器仍处于逐步实施阶段,旨在替换以类似方式运行但并非点对点模式的系统。)

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

根 KMS 主密钥还会在安全硬件设备上留一份备份,以应对根 KMS 主密钥分发服务器的所有实例同时重启的情况;这类安全硬件设备存储在实体保险箱中,而这些保险箱安放在 Google 全球两个物理分离的高度安全区域中。只有当所有分发服务器实例同时关闭时才需要此备份;例如,在全球性重启时。能够接触这些保险箱的 Google 员工不超过 20 名。

“Google 的加密层次结构”示意图

图 4:加密密钥层次结构使用 DEK 保护数据区块,该 DEK 使用 KMS 中的 KEK 封装,而 KMS 又受到 Root KMS 和根 KMS 主密钥分发服务器的保护。

总结:

  • 数据会分成区块并使用 DEK 进行加密
  • DEK 使用 KEK 进行加密
  • KEK 存储在 KMS 中
  • KMS 在全球数据中心的多台机器上运行
    • KMS 密钥使用 KMS 主密钥进行封装,而 KMS 主密钥存储在 Root KMS 中
  • Root KMS 中密钥的数量远少于 KMS 中的密钥,Root KMS 仅在每个数据中心的专用机器上运行
    • Root KMS 密钥使用根 KMS 主密钥进行封装,后者存储在根 KMS 主密钥分发服务器中
  • 根 KMS 主密钥分发服务器是在全球各地的专用机器 RAM 中并发运行的对等互连基础架构;每个分发服务器实例都会从其他正在运行的实例获取其密钥材料
    • 如果所有分发服务器实例都关闭(全球性关闭),则我们会将主密钥存储在(其他)安全硬件中,而这些安全硬件存放在有限几个 Google 网点的(实体)保险箱中
    • 我们正在逐步提高根 KMS 主密钥分发服务器的使用效率,未来将替换为以类似方式运行但并非点对点的系统

全球可用性和复制

高可用性、低延迟、密钥全球访问在每个层级都至关重要;只有具备这些特性,才能在整个 Google 范围内使用 KMS。

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

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

Google 的通用加密库

Google 的通用加密库是 Tink5,它使用 BoringSSL6 实现加密算法。Tink 可供所有 Google 开发者使用。由于此通用库可广泛使用,因此只需组建一个小型密码学专家团队就能妥善实施其受到严格控制和审查的代码,并不是每个 Google 团队都需要构建自己的加密机制。一个特殊的 Google 安全团队会负责为所有产品维护此通用加密库。

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

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

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

每个 Google Cloud 产品中的加密粒度

每项 Google Cloud 服务都会以不同的粒度级别将数据拆分以进行加密。

  Google Cloud 服务 客户数据加密的粒度8(即使用单个 DEK 加密的数据大小)
存储 Cloud Bigtable 每个数据区块(每个表分成多个数据区块)
Datastore 每个数据区块9
Firestore 每个数据区块9
Cloud Spanner 每个数据区块(每个表分成多个数据区块)
Cloud SQL
  • 第二代:每个实例,与在 Compute Engine 中一样(每个实例可以包含多个数据库)
  • 第一代:每个实例
Cloud Storage 每个数据区块(通常为 256 KB-8 MB)
计算 App Engine10 每个数据区块9
Cloud Functions11 每个数据区块9
Compute Engine
  • 每个磁盘分成多个数据区块
  • 每个快照组,具有各自快照范围,源自快照组主密钥
  • 每个映像
Google Kubernetes Engine 每个磁盘分成多个数据区块,适用于永久性磁盘
Container Registry 存储在 Cloud Storage 中,每个数据区块
大数据 BigQuery 每个数据集分成多个数据区块
数据流 存储在 Cloud Storage 中,每个数据区块
Datalab 存储在 Cloud Bigtable 中,每个笔记本文件
Dataproc 存储在 Cloud Storage 中,每个数据区块
Pub/Sub 每 30 天轮替一次9

Cloud 客户的其他加密选项

除了在 Google Cloud 中提供默认加密功能外,我们还致力于为客户提供其他加密和密钥管理选项,以进一步完善控制措施。

我们希望 Google Cloud 客户能够:

  • 始终都是其数据的最终监护人,并能够以最精细的粒度控制对该数据的访问和使用,确保数据安全性和隐私性
  • 使用与其当前本地加密相同的方式管理云托管数据的加密,或者最好能使用更好的方式
  • 对其资源拥有可证明且可审计的信任根
  • 能够进一步分离和隔离他们的数据,超出使用 ACL 所能达到的程度

借助“客户提供的加密密钥”功能,客户可以将自主管理的现有加密密钥用于 Google Cloud。客户可在 Cloud StorageCompute Engine 中使用此功能来进行存储系统层加密。

客户还可以在 Google Cloud 上使用 Cloud Key Management Service 来管理自己的加密密钥。此产品允许客户管理应用层加密。

加密研究与创新

为了跟上加密技术的发展步伐,Google 拥有一支世界一流的安全工程师团队,负责追踪、开发和改进加密技术。我们的工程师参与标准化流程并维护广泛使用的加密软件。我们定期发布我们在加密领域的研究成果,以便行业中的每个人(包括普通大众)都可以从我们分享的知识中受益。例如,2014 年,我们发现了 SSL 3.0 加密中的一个重大漏洞(称为 POODLE);2015 年,我们又发现了 OpenSSL 中的一个高风险漏洞。

Google 致力于在云服务加密领域继续保持业界领先地位。在开发、实施和研究新的加密技术方面,我们的团队正致力于以下工作:

  • “部分同态加密”,允许在数据处于加密状态时对数据执行一些操作,因此在云中永远看不到明文数据,即使在内存中也是如此。这项技术现在正用于我们向大众开放的实验性加密 BigQuery 客户端
  • “格式和顺序保留加密”,允许在数据处于加密状态时对数据执行一些比较和排名操作。
  • “后量子加密”,允许我们将容易受到高效率量子攻击影响的现有加密原语替换为后量子候选方案,通常认为后量子候选方案能够更可靠地应对此类攻击。此处的主要焦点是研究基于格的公钥加密并设计其原型,包括关于后量子算法的 NIST 建议。基于格的加密技术目前被认为是后量子世界中最有可能使用的加密技术之一,尽管我们在应用此类加密技术方面,就最佳算法、具体参数和密码分析而言,仍处于早期阶段。虽然已知的量子算法削弱了对称密钥加密和 MAC,但是通过将密钥大小加倍,对称密钥加密和 MAC 仍然可以在后量子世界中升级到类似的安全位数。

其他参考信息

Google Cloud 安全性

如需了解关于 Google Cloud 安全性的一般信息,请参阅 Google Cloud 网站的“安全”部分

Google Cloud 合规性

如需了解 Google Cloud 合规性及合规性认证,请参阅 Google Cloud 网站的“合规性”部分,其中包括 Google 的公开 SOC3 审计报告

G Suite 安全性

如需了解有关 G Suite 加密和密钥管理的信息,请参阅 G Suite 加密白皮书。该白皮书涵盖了本文包含的大部分内容,但着重阐述 G Suite。在所有 G Suite 解决方案中,我们努力保护客户数据,并尽可能让我们保护客户数据的方式透明化。如需了解有关一般 G Suite 安全的更多信息,请参阅 G Suite 安全性和合规性白皮书

脚注

1 Datastore、App Engine 和 Pub/Sub 中的一个数据区块可能包含多个客户的数据。请参阅介绍各项服务的数据加密粒度的章节
2 (不适合进行这种资源拆分的)一个共享资源示例是 Compute Engine 中的共享基础映像,由于其共享特性,多个客户引用同一个副本,而该副本由单个 DEK 加密。
3 存储在 Datastore、App Engine 和 Pub/Sub 中的数据除外。在这些服务中,多位客户的数据可能由同一 DEK 加密。请参阅介绍各项服务的数据加密粒度的章节
4请注意,过去采用的是 AES128 标准,现在仍有一些此类密钥用于数据解密。
5Google 还使用了另外两个库:Keymaster 和 CrunchyCrypt。Keymaster 与 Tink 共用新的通用加密代码,但使用不同的密钥版本管理机制,并且支持的旧算法更多。我们正在将 CrunchyCrypt 与 Tink 合并。
6 在 Cloud Storage 的某些地方还在使用 OpenSSL。
7 这个库中还存在其他过去曾经支持的加密协议,但是此列表中仅包含 Google Cloud 中主要使用的加密协议。
8 指客户内容的加密粒度。这不包括客户元数据,例如资源名称。在某些服务中,所有元数据都使用单个 DEK 进行加密。
9并非每位客户专用。
10 包括应用代码和应用设置。App Engine 中使用的数据存储在 Datastore、Cloud SQL 或 Cloud Storage 中,具体取决于客户配置。
11 包括函数代码、设置和事件数据。事件数据存储在 Pub/Sub 中。