Google Cloud Platform 的静态数据加密

本文于 2017 年 4 月撰写,所含内容以当时现状为准。鉴于我们仍会持续改善对客户的保护机制,Google Cloud Platform 的安全政策和系统未来可能会发生变化。

播放按钮

Google Cloud 静态数据加密

首席信息官级别的摘要

  • Google 采用多层加密机制来保护 Google Cloud Platform 产品中的静态客户数据。
  • Google Cloud Platform 会使用一种或多种加密机制来加密静态存储的客户内容,客户不需要执行任何操作。但仍有一些无关紧要的例外情况,本文将做进一步说明
  • 系统会将数据拆分为多个区块进行存储,每个区块都使用专属的 DEK 进行加密。这些 DEK 会与数据一起存储,并使用密钥加密密钥 (KEK) 进行加密(又称“封装”)。KEK 是在 Google 的集中式 Key Management Service 内存储和使用的专有密钥。Google 的 Key Management Service 是一项具有冗余性的全球分布式服务。
  • 系统会使用 AES256 或 AES128,在存储系统级对存储在 Google Cloud Platform 中的数据进行加密。
  • 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) 推荐用于长期存储用途(从 2015 年 11 月起),以及 (2) AES 通常会被纳入客户合规性要求。

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

存储设备层级加密

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

备份加密

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

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

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

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

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

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

密钥管理

数据加密密钥、密钥加密密钥和 Google 的 Key Management Service

用于对区块中的数据进行加密的密钥称为“数据加密密钥”(DEK)。由于 Google 拥有大量密钥,又必须确保低延迟和高可用性,因此会将这些密钥存储在所加密数据的附近。DEK 本身又会使用“密钥加密密钥”(KEK) 进行加密(或称“封装”)。每项 Google Cloud Platform 服务都有一个或多个 KEK。这些 KEK 集中存储在 Google 的 Key Management Service (KMS) 中,这是一个专为存储密钥而构建的存储区。只需少量 KEK(少于 DEK)并使用集中式密钥管理服务,就能轻松管理整个 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 的 Key Management Service (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 具有极强的可扩缩性,并且会在全球的 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 每个数据区块(通常为 256KB-8MB)
计算 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 每小时,最多 100 万条消息12

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 中的数据除外,在 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 中。
12 Cloud Pub/Sub 会每小时轮替用于加密消息的 DEK,但如果加密消息达到 100 万条,则轮替间隔会缩短。并非每位客户专用。
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页