Google Cloud Platform 中的静态加密

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

“播放”按钮

Google Cloud 静态加密

面向首席信息官级管理层的概要

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

简介

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

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

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

什么是加密

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

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

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

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

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

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

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

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

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

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

Google 的默认加密方式

静态数据加密

多层级加密

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

加密层级图表

图 1:我们采用多层级加密机制来保护存储在 Google Cloud Platform 中的数据。对几乎所有文件都会实施分布式文件系统加密或数据库和文件存储加密,另外,对几乎所有文件还会实施存储设备加密。

存储系统层级加密

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

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

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

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

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

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

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

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

存储设备层级加密

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

备份加密

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

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

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

Google Cloud Platform 使用一种或多种加密机制,对以静态存储的客户内容进行加密,客户不需要执行任何操作。但还存在以下例外情况。

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

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

密钥管理

DEK、KEK 和 Google KMS

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

系统会将每个 Google Cloud Platform 客户的所有非共享资源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,而后者又源自多个独立的熵源。其中包括来自数据中心环境的熵事件,例如磁盘寻道和内部数据包到达时间的精密测量结果,以及在 Ivy Bridge 和更新款 CPU 上提供的 Intel RDRAND 指令

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

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

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

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

当 Google Cloud Platform 服务访问加密的数据区块时,将经历以下步骤:

  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”的 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 密钥使用根 KMS 主密钥进行封装,后者存储在根 KMS 主密钥分发服务器中
  • 根 KMS 主密钥分发服务器是一个点对点基础架构,在全球各地专用机器的 RAM 中并发运行;每个分发服务器实例都会从其他正在运行的实例获取其密钥材料
    • 如果所有分发服务器实例都关闭(全球性关闭),我们有存储在(不同的)安全硬件中的主密钥,这些安全硬件存放在有限的几个 Google 地点的(实体)保险库中
    • 我们正在逐步增加根 KMS 主密钥分发服务器的使用,目的是替换一个以类似方式运行但并非点对点的系统

全球可用性和复制

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

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

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 Platform 产品中的加密粒度

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

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

Cloud 客户的其他加密选项

除了在 Google Cloud Platform 中提供默认加密功能外,我们还致力于为客户提供其他加密和密钥管理方案,以进一步增强控制。

我们希望 Google Cloud Platform 客户能够:

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

藉由“客户提供的加密密钥”功能,客户可以在 Google Cloud Platform 中使用自己管理的现有加密密钥。客户可在 Google Cloud StorageGoogle Compute Engine 中使用此功能来进行存储系统层级加密。

客户还可以在 Google Cloud Platform 上使用 Google Cloud Key Management Service (Cloud KMS) 来管理自己的加密密钥。此产品可实现客户管理的应用层级加密。

加密研究与创新

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

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

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

其他参考信息

Google Cloud Platform 安全性

有关 Google Cloud Platform 安全性的一般信息,请参阅 Google Cloud Platform 网站的“安全”部分

Google Cloud Platform 合规性

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

G Suite 安全性

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

脚注

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