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 是一项具有冗余性的全球分布式服务。
  • 存储在 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) 推荐用于长期存储用途(从 2015 年 11 月起),以及 (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 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。

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 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 保存的密钥会进行备份以用于灾难恢复,而且可恢复期限没有限制。

KMS 中的访问控制列表 (ACL) 会根据每个密钥的政策,分别对每个 KEK 的使用进行管理。只有已获授权的 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 主密钥”的根密钥的保护,该密钥将所有 KEK 封装在 KMS 中。此 KMS 主密钥采用 AES256 加密算法4,而且它本身存储在另一个称为“根 KMS”的密钥管理服务中。根 KMS 存储的密钥数量要少得多(大约十几个)。为了提高安全性,根 KMS 不在常规生产机器上运行,而是仅在每个 Google 数据中心的专用机器上运行。

根 KMS 也有自己的根密钥,它称为“根 KMS 主密钥”,而此根密钥也是采用 AES256 加密算法4,存储在点对点基础架构中,即储存在会全局复制这些密钥的“根 KMS 主密钥分发服务器”上。根 KMS 主密钥分发服务器仅将密钥保存在根 KMS 所在专用机器的 RAM 中,并使用日志记录来验证使用是否正确。对于根 KMS 的每个实例,都会运行根 KMS 主密钥分发服务器的一个实例。(根 KMS 主密钥分发服务器仍处于逐步实施阶段,旨在替换以类似方式运行但不是点对点的系统。)

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

根 KMS 主密钥还会备份在安全硬件设备上,以应对根 KMS 主密钥分发服务器的所有实例同时重启的情况;安全硬件设备存储在高度安全区域的实体保险箱中,而这些区域位于两个在物理上分离的全球 Google 地理位置。仅当所有分发服务器实例一起关闭时才需要此备份;例如,全局重启时。可以使用这些保险箱的 Google 员工不到 20 名。

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

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

总结:

  • 数据会分成区块并使用 DEK 进行加密
  • DEK 使用 KEK 进行加密
  • KEK 存储在 KMS 中
  • KMS 在全球数据中心的多台机器上运行
    • KMS 密钥使用 KMS 主密钥进行封装,而 KMS 主密钥存储在根 KMS 中
  • 根 KMS 的数量远少于 KMS,仅在每个数据中心的专用机器上运行
    • 根 KMS 密钥使用根 KMS 主密钥进行封装,后者存储在根 KMS 主密钥分发服务器中
  • 根 KMS 主密钥分发服务器是在专用机器上的 RAM 中全球并发运行的点对点基础架构;每个分发服务器从其他处于运行状态的实例获取其密钥材料
    • 如果分发服务器的所有实例都关闭(完全关闭),则主密钥存储在(其他)安全硬件中,而安全硬件存放在数量有限的 Google 网点的(实体)保险箱中
    • 根 KMS 主密钥分发服务器处于逐步实施阶段,旨在替换以类似方式运行但不是点对点的系统

全球可用性和复制

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

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

根 KMS 在每个数据中心的几台专用于安全运营的机器上运行。根 KMS 主密钥分发服务器也在这些机器上运行,与根 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 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 万条消息,则轮替的时间会提前。并非单个客户所独有。
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页