Google Cloud 中的传输加密

这是关于 Google 如何通过加密来保护您的数据的第三份白皮书。之前我们还发布了 Google Cloud Platform 中的静态加密G Suite 加密。您可能发现,阅读另外这两个文档也有助于了解 Google 使用加密技术的情况。本白皮书将更详细地介绍 Google Cloud(包括 Google Cloud Platform 和 G Suite)中的传输加密相关信息。

在所有 Google 产品中,我们都努力保护客户数据,并尽可能透明地披露我们保护客户数据的方式。

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

播放按钮

Google Cloud 的传输加密

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

  • Google 采用多种安全措施来确保传输过程中数据的真实性、完整性和私密性。
  • 如果数据将移出物理边界,脱离 Google 或 Google 代表方的控制范围,Google 会在一个或多个网络层对传输中的所有数据进行加密和身份验证。如果传输中的数据位于物理边界内部,由 Google 或 Google 代表方掌控,我们通常会对这些数据进行身份验证,但不一定会加密。
  • 根据正在建立的连接,Google 会对传输中的数据应用默认保护。例如,我们使用传输层安全协议 (TLS) 保护用户与 Google 前端 (GFE) 之间的通信。
  • Google Cloud 客户如要求在 WAN 上进行额外的数据加密,可以选择在数据从用户移动到应用或从虚拟机移动到虚拟机时提供进一步的保护。这些保护措施包括 IPsec 隧道、Gmail S/MIME、托管式 SSL 证书和 Istio。
  • Google 积极与业界合作,帮助将传输加密功能推广到世界各地供每个人使用。我们有数个开源项目,鼓励在互联网上广泛使用传输加密和数据安全功能,包括证书透明度、Chrome API 和安全 SMTP。
  • Google 计划在传输加密领域继续保持业界领先地位。为此,我们专门调拨资源开发和改进加密技术。我们在这方面的工作硕果累累,包括在密钥透明度和后量子加密领域实现创新。

简介

安全性通常是用户选择公有云服务商时的一个决定性因素。在 Google 看来,安全性具有极端的重要性。我们孜孜不倦地保护您的数据:无论这些数据是通过互联网传输、在 Google 的基础架构内移动,还是存储在我们的服务器上。

Google 安全策略的核心是身份验证、完整性和加密,对于静态数据和传输中的数据均适用。本文将介绍我们在 Google Cloud 中采用的传输加密方法。

对于静态数据,请参阅 Google Cloud Platform 中的静态加密。如需大致了解各种 Google 安全机制,请参阅 Google 基础架构安全设计概述

受众群体:本文档面向正在使用或考虑使用 Google Cloud 的首席信息安全官 (CISO) 和安全运营团队。

前提条件:除了本简介之外,我们还假定读者对加密密码学原语具有基本的了解。

身份验证、完整性和加密

Google 采用多种安全措施来确保传输过程中数据的真实性、完整性和私密性。

  • 身份验证:我们会验证数据源、人员或过程以及目标位置。
  • 完整性:我们会确保您发送的数据原封不动地到达目的地。
  • 加密:我们会确保您的数据在传输过程中无法识别,以保持其私密性。加密是使清晰易辨的数据(明文)变得无法辨认(密文)的过程,目的是确保只有经数据所有者授权的各方才能访问明文。 加密过程中使用的算法是公开的,但解密密文所需的密钥是私密的。传输加密通常使用非对称密钥交换(例如基于椭圆曲线的 Diffie-Hellman)来建立用于数据加密的共享对称密钥。要详细了解加密,请参阅《现代密码学简介》(Introduction to Modern Cryptography)

加密可用于保护三种状态的数据:

  • 静态加密通过加密存储的数据,防止您的数据受到系统入侵或数据渗漏的危害。高级加密标准 (AES) 通常用于加密静态数据。
  • 传输加密:当数据在您的网站与云服务商之间或在两个服务之间移动时,如果通信遭到拦截,则可保护您的数据。这种保护是通过在传输之前加密数据,对端点进行身份验证,并在抵达时解密和验证数据来实现的。例如,传输层安全协议 (TLS) 通常用于加密传输中的数据以实现传输安全性,而安全/多用途网际邮件扩充协议 (S/MIME) 通常用于实现电子邮件安全性。
  • 正在使用的加密:在服务器使用数据运行计算时保护您的数据,例如同态加密。

安全策略种类繁多,而加密是其中一种。在建立连接并进行身份验证后,传输加密通过以下方式保护您的数据免受潜在攻击:

  • 无需信任通常由第三方提供的较低层网络
  • 减少潜在的攻击面
  • 在通信被拦截时,阻止攻击者访问数据

有了充分的身份验证、完整性和加密,在用户、设备或进程之间传输的数据即使处于恶意环境中也能获得保护。本文的其余部分介绍 Google 采用什么方法加密传输中的数据,以及在哪种情况下应用此方法。

Google 的网络基础架构

Google 网络的物理边界

如果数据传到由 Google 或 Google 代表方控制的物理边界的外面,Google 会对传输中的数据应用不同的保护措施。物理边界是指由 Google 或 Google 代表方控制的物理空间的屏障,我们可以确保在其中配置严格的安全措施。对这些位置的物理访问受到限制和严密监控。只有一小部分 Google 员工可以访问硬件。在这些物理边界内传输的数据通常会经过身份验证,但默认情况下可能不会加密 - 您可以根据威胁模型选择要应用哪些额外的安全措施。

由于全球互联网的规模,我们无法在 WAN 中的光纤链路,或由 Google 或代表 Google 控制的物理边界之外的任何地方配置相同的物理安全控制。因此,我们会在物理信任边界之外自动实施额外的保护措施。这些保护措施包括传输中的数据加密。

流量路由方式

上一部分介绍了 Google 网络的物理边界,以及我们如何对此边界之外发送的数据应用不同的保护。要全面了解 Google 传输加密的工作原理,还需要介绍流量在互联网中的路由方式。本节将介绍最终用户的请求如何传到相应的 Google Cloud 服务或客户应用,以及流量如何在服务之间路由。

Google Cloud 服务是指我们为客户提供的模块化云服务。这些服务包括计算、数据存储、数据分析和机器学习。例如,Google Cloud Storage 和 Gmail 都是 Google Cloud 服务。客户应用是指托管在 Google Cloud 上的应用,Google 客户可以使用 Google Cloud 服务构建和部署此类应用。托管在 Google Cloud 上的客户应用或合作伙伴解决方案不被视为 Google Cloud 服务1。例如,您使用 Google App Engine、Google Kubernetes Engine 或 Google Compute Engine 中的虚拟机构建的应用是客户应用。

下面讨论的五种路由请求都显示在图 1 中。此图显示了各个网络组件之间的交互以及每个连接所配置的安全措施。

最终用户(互联网)到 Google Cloud 服务

Google Cloud 服务使用称为 Google 前端 (GFE) 的全球分布式系统接收来自世界各地的请求。GFE 会终止传入的 HTTP(S)、TCP 和 TLS 代理流量,针对 DDoS 攻击提供反制对策,将流量路由到 Google Cloud 服务本身并进行负载平衡。全球各地都有通过单播或任播通告路由的 GFE 站点。

流向 Google Cloud 服务的 GFE 代理流量。GFE 通过我们的网络主干将用户的请求路由到 Google Cloud 服务。当这些通信离开由 Google 或 Google 代表方控制的物理边界时,此类从 GFE 连接至 Google Cloud 服务前端或客户应用前端的连接将经过身份验证和加密。图 1 显示了这种交互(标记为连接 A)。

最终用户(互联网)到 Google Cloud 上托管的客户应用

可采用多种方法将互联网中的流量路由到您在 Google Cloud 上托管的客户应用。路由流量的方式取决于您的配置,如下所述。图 1 显示了这种交互(标记为连接 B)。

  • 使用 Google Cloud HTTP(S) 或 TCP/SSL 代理 Load Balancer 外部负载平衡器:Google Compute Engine 虚拟机上托管的客户应用可以使用 Google Cloud Load Balancer (GCLB) 服务终止 HTTP(S)、TLS 或 TCP 连接以及将此流量代理、路由和分发到其虚拟机。这些负载平衡器服务由 GFE 实现,就像 GFE 为 Google Cloud 服务终止和路由流量一样。当 GCLB 在 GFE 之间路由流量时,系统会对连接进行身份验证,并在流量离开由 Google 或 Google 代表方控制的物理边界时进行加密。当 GCLB 在 GFE 和托管客户虚拟机的物理机之间路由流量时,系统会对此流量进行身份验证,并在其离开由 Google 或 Google 代表方控制的物理边界时进行加密。

    对于 HTTPS 负载平衡器,系统会使用客户为负载平衡器提供的证书并通过 TLS 或 QUIC 对最终用户和 GFE 之间的连接进行加密和身份验证。对于 HTTP 负载平衡器,系统不会对最终用户和 GFE 之间的连接进行加密或身份验证。对于 SSL 负载平衡器,系统会同样使用客户提供的证书并通过 TLS 对最终用户和 GFE 之间的连接进行加密。对于 TCP 负载平衡器,最终用户和 GFE 之间没有加密。但客户的应用可以在最终用户和虚拟机之间使用自己的加密。

  • 使用外部 IP 或网络负载平衡器 IP 直接连接到虚拟机:如果通过虚拟机的外部 IP 或通过网络负载平衡 IP 进行连接,则连接不会经过 GFE。默认情况下,此连接不会加密,其安全性由用户自行负责。

  • 使用 Cloud VPN:如果您通过 VPN 从本地主机连接到 Google Cloud 虚拟机,出入本地主机的连接会依次传到本地 VPN、Google VPN,再到 Google Cloud 虚拟机;连接不会经过 GFE。从本地 VPN 到 Google VPN 的连接由 IPsec 保护。当这些通信离开由 Google 或 Google 代表方控制的物理边界时,系统会对从 Google VPN 到 Google Cloud 虚拟机的连接进行身份验证和加密。

  • 使用 Cloud 专用互连:如果通过专用互连进行连接,此连接会直接出入本地主机,不经过 GFE。默认情况下,此连接不会加密,其安全性由用户自行负责。您可以使用传输层安全 (TLS) 第 7 层加密协议来加密通过专用互连传输的应用流量。

虚拟机到虚拟机

使用 RFC 1918 专用 IP 地址在我们的网络主干上进行虚拟机到虚拟机的路由,可能需要在由 Google 或 Google 代表方控制的物理边界之外路由流量。虚拟机到虚拟机的路由示例包括:

  • Compute Engine 虚拟机向彼此发送请求
  • 客户虚拟机连接到 Google 托管的虚拟机(如 Cloud SQL)

虚拟机到虚拟机的连接在物理边界内需要进行身份验证,如果离开物理边界,则需要进行加密。使用公共 IP 地址的虚拟机到虚拟机的流量默认不加密,其安全性由用户自行决定。图 1 显示了这种交互(标记为连接 C)。

虚拟机到 Google Cloud 服务

如果虚拟机将请求路由到 Google Cloud 服务,该请求将路由到 GFE(除非 Google Cloud 服务在 Google 管理的虚拟机上运行,如上所述)。GFE 接收该请求,然后路由该请求,路由的方式与来自互联网的请求的方式相同:对于从虚拟机到 Google Cloud 服务的流量,这将通过专用的 Google 路径路由到用于 GFE 的同一公共 IP。专用 Google 访问通道允许没有公共 IP 的虚拟机访问 Google App Engine 上托管的某些 Google Cloud 服务和客户应用。(请注意,如果虚拟机连接到托管在 Google Compute Engine 或 Google Kubernetes Engine 上的客户应用,系统会按路由来自互联网的请求的方式,通过外部路径路由相关流量。) 图 1 显示了这种交互(标记为连接 D)。Compute Engine 虚拟机到 Google Cloud Storage 或机器学习 API 的连接就属于这种路由请求。默认情况下,Google Cloud 服务支持使用 TLS 保护这些连接2。从虚拟机到 GFE 的连接就配置了这种保护。从 GFE 到服务的连接会进行身份验证,且连接在离开物理边界时会进行加密。

Google Cloud 服务到 Google Cloud 服务

从一个生产服务路由到另一个生产服务会在我们的网络主干上进行,并且可能需要在由 Google 或代表 Google 控制的物理边界之外路由流量。图 1 显示了这种交互(标记为连接 E)。此类流量的一个示例是触发 Google Cloud Functions 的 Google Cloud Storage 事件。生产服务之间的连接在物理边界内会进行身份验证,如果离开物理边界则会进行加密。

图 1:默认情况下的保护和 Google 网络上的叠加选项

默认情况下的传输加密

Google 使用各种加密方法(包括默认方法和用户可配置的方法)加密传输中的数据。使用的加密类型取决于 OSI 层、服务类型和基础架构的物理组件。下面的图 2 和图 3 展示了 Google Cloud 为第 3、4 和 7 层配置的可选和默认保护。

图 2:Google Cloud 第 3 层和第 4 层的默认保护措施和各种选项

图 3:Google Cloud 第 7 层的默认保护措施和各种选项3

本部分的其余部分介绍 Google 用于保护传输中的数据的默认保护。

用户到 Google 前端的加密

如今,许多系统使用 HTTPS 在互联网上进行通信。 HTTPS 借助 TLS 连接来定向该协议以提供安全性,从而确保请求和响应的真实性、完整性和私密性。要接受 HTTPS 请求,接收者需要具有公钥/私钥对和 X.509 证书,以便从证书授权机构 (CA) 进行服务器身份验证。密钥对和证书通过证明接收者拥有用户请求欲前往的域名,在应用层(第 7 层)保护请求。以下各小节介绍用户到 GFE 加密的组成部分,即:TLS、BoringSSL 和 Google 的证书授权机构。回想一下,并非所有客户路径都通过 GFE 进行路由;值得注意的是,GFE 用于从用户到 Google Cloud 服务的流量,以及从用户到 Google Cloud 上托管的使用 Google Cloud Load Balancing 的客户应用的流量。

传输层安全协议 (TLS)

当用户向 Google Cloud 服务发送请求时,我们会保护传输中的数据;使用 HTTPS 和来自网络(公共)证书授权机构的证书提供身份验证、完整性和加密。系统会使用传输层安全协议 (TLS) 或 QUIC 加密在传输过程中的由用户发送到 GFE 的任何数据。GFE 会根据客户端能够支持的内容与客户端协商特定的加密协议。如有可能,GFE 会协商更为现代的加密协议。

GFE 的扩缩型 TLS 加密不仅适用于最终用户与 Google 的互动,还可以促进 API 通过 TLS 与 Google(包括 Google Cloud)的互动。此外,我们的 TLS 加密还在 Gmail 中用于与外部邮件服务器交换电子邮件(详情请参阅在 Gmail 中要求使用 TLS)。

Google 在 TLS 的采用和强化实现方面均处于行业领先地位。正因如此,我们默认启用了 TLS 的众多安全功能。例如,从 2011 年以来,我们一直在 TLS 实现中使用正向加密。正向加密可确保用于保护连接的密钥不被留存,因此即使攻击者拦截并读取了一条消息,也无法读取之前的消息。

BoringSSL

BoringSSL 是 TLS 协议的开源实现,由 Google 维护并从 OpenSSL 分支出来,接口方面几乎完全与 OpenSSL 兼容。Google 从 OpenSSL 分支出 BoringSSL 是为了简化 OpenSSL,以提供给内部使用,同时更好地支持 Chromium 和 Android 开源项目。BoringCrypto 是 BoringSSL 的核心,已通过 FIPS 140-2 级别 1 验证。

GFE 中的 TLS 通过 BoringSSL 实现。表 1 显示了与客户端通信时 GFE 支持的加密协议。

协议 身份验证 密钥交换 加密 哈希函数
TLS 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

表 1:在 Google 前端为 Google Cloud 服务实现的加密,以及在 BoringSSL 加密库中实现的加密

Google 的证书授权机构

作为 TLS 的一部分,服务器必须在收到连接请求时向用户证明其身份。在 TLS 协议中,此身份验证是通过要求服务器提供包含其声明身份的证书来实现的。证书包含服务器的 DNS 主机名及其公钥。服务器提供的证书将由负责颁发事宜且受请求连接的用户所信任的证书授权机构 (CA) 进行签名10。因此,请求与服务器建立连接的用户只需要信任根 CA 即可。如果服务器希望向全球各地的用户提供访问权限,则需要向全球各地的客户端设备都告知根 CA。现在的大多数浏览器和其他 TLS 客户端实现都有自己的一组根 CA。在它们的“根存储区”中,这些根 CA 被配置为可信状态。

Google 在过去一直运营着自己的证书颁发 CA,供我们用于签署 Google 网域的证书。不过我们没有运营过我们自己的根 CA。现在我们的 CA 证书由多个广泛分布的根 CA 进行交叉签名,包括 Symantec(“GeoTrust”)和以前由 GlobalSign 运营的根(“GS Root R2”和“GS Root R4”)。

2017 年 6 月,我们宣布转为使用 Google 自己的根 CA。随着时间的推移,我们计划运营一个广泛分布的根 CA,它将为 Google 网域和我们的客户颁发证书。

根密钥迁移和密钥轮替

根 CA 密钥不会经常更改,因为迁移到新的根 CA 需要所有浏览器和设备嵌入对该证书的信任,但这需要很长时间。因此,即使 Google 现在运营自己的根 CA,但在过渡期间,我们在迁移到自己的根 CA 过程中,我们的旧设备仍将继续依赖多个第三方根 CA。

创建新的根 CA 需要一个关键仪式。在 Google,此仪式要求在 6 名可能获得授权的个人中至少有 3 人亲身前往碰面,使用存放在保险箱中的硬件钥匙。这些人在一个专用房间中碰面以生成一组密钥和证书,该房间通过气隙隔离的硬件安全模块 (HSM) 屏蔽电磁干扰。该专用房间位于 Google 数据中心的安全位置。其他控制措施(如物理安全措施、摄像机和其他监控人员)可确保该过程按计划进行。如果仪式成功,则生成的证书与样本证书相同,但发行者名称、公钥和签名不同。生成的根 CA 证书将提交给浏览器和设备根程序收录。此流程是为了确保相关私钥的隐私和安全性获得充分理解,以便能够持续使用密钥十年或更长时间。

如前所述,CA 使用其私钥来签署证书,并且这些证书会在启动用户会话中的 TLS 握手环节时验证身份。服务器证书通过中级 CA 签名,其创建过程与根 CA 的创建过程类似。中级 CA 的证书作为 TLS 会话的一部分进行分发,因此迁移到新的中级 CA 是较为容易的。此分发方法还使 CA 运营者能够将根 CA 密钥材料保持在离线状态。

TLS 会话的安全性取决于服务器密钥的受保护程度。为了进一步降低密钥泄露的风险,Google 的 TLS 证书有效期限制为大约三个月,并且证书大约每两周轮替一次。

之前曾连接到服务器的客户端可以使用私有票证密钥11通过简短的 TLS 握手恢复先前的会话,因此这些票证对攻击者非常有价值。Google 每天至少轮替一次票证密钥,并且所有资源中的密钥每 3 天就会过期。要详细了解会话密钥票证轮替,请参阅衡量 TLS 加密快捷方式对安全的危害

Google 前端到应用前端

在某些情况下,如流量的路由方式中所述,用户会连接到与所需服务和关联的应用前端不同的物理边界内的 GFE。发生这种情况时,用户的请求和任何其他第 7 层协议(如 HTTP)要么受 TLS 保护,要么被封装在使用应用层传输安全 (ALTS) 保护起来的 RPC 中,如服务到服务的身份验证、完整性和加密中所述。这些 RPC 已经过身份验证和加密。

对于 Google Cloud 服务,默认情况下使用 ALTS 保护 RPC。对于托管在 Google Cloud 上的客户应用,如果流量通过 Google 前端路由(例如使用 Google Cloud Load Balancer 时),则使用 Google Cloud 的虚拟网络加密功能保护路由到虚拟机的流量,如下一部分所述。

Google Cloud 的虚拟网络加密和身份验证

在流量离开我们的物理边界时,Google Cloud 的虚拟网络基础架构可以进行加密。加密在网络层执行,适用于同一虚拟私有云 (VPC) 内或对等 VPC 网络内的私有 IP 流量。

我们认为任何跨越不受 Google 或 Google 代表方控制的物理边界的网络都有可能受到活跃对手的攻击,他们可以窥探、注入或改变线路上的流量。当数据移动到我们无法控制的物理边界之外时,我们使用加密来确保通信的完整性和私密性。

我们使用伽罗瓦/计数器模式 (GCM) 下的高级加密标准 (AES) 和 128 位密钥 (AES-128-GCM) 在网络层实现加密。每对通信主机通过受 ALTS 保护的控制隧道建立会话密钥,以建立经过身份验证和加密的通信。会话密钥用于加密这些主机之间的所有虚拟机到虚拟机的通信,并且会话密钥会定期轮替。

在网络层(第 3 层),Google Cloud 的虚拟网络会对虚拟机之间的所有流量进行身份验证。这种通过安全令牌实现的身份验证可以防止被入侵的主机受到网络上欺骗数据包的攻击。

在身份验证期间,安全令牌被封装在隧道头中,其中包含有关发送者和接收者的身份验证信息。发送端的控制平面12会设置令牌,而接收主机会验证令牌。每个流都预先生成有安全令牌,该令牌由令牌密钥(包含发送者的信息)和主机密钥组成。由 Google 或代表 Google 控制的物理边界的每个来源/接收者对都存在一个密钥。图 4 显示令牌密钥、主机密钥和安全令牌的创建方式。

图 4:安全令牌

物理边界密钥是 128 位的伪随机数,而主机密钥则是采用 HMAC-SHA1 从该伪随机数中派生出的。物理边界密钥通过一对物理边界的网络控制平面之间的握手进行协商,并且每隔几小时重新协商一次。用于单个虚拟机到虚拟机身份验证的安全令牌为 HMAC,派生自这些输入和其他输入,经协商后用于给定的发送者和接收者对。

服务到服务的身份验证、完整性和加密

在 Google 基础架构中,我们在应用层(第 7 层)使用应用层传输安全 (ALTS),针对从 GFE 到服务以及从服务到服务的 Google RPC 调用提供身份验证、完整性和加密。

ALTS 使用服务帐号进行身份验证。在 Google 基础架构中运行的每项服务都以具有相关加密凭据的服务帐号身份运行。从其他服务创建或接收 RPC 时,服务使用其凭据进行身份验证。ALTS 使用内部证书授权机构验证这些凭据。

在由 Google 或代表 Google 控制的物理边界内,ALTS 在“身份验证和完整性”模式下为 RPC 同时提供身份验证和完整性。对于由 Google 或代表 Google 控制的物理边界之外的 WAN 上的流量,ALTS 在“身份验证、完整性和私密性”模式下自动强制加密基础架构 RPC 流量。目前,路由到 Google 服务的所有流量(包括 Google Cloud 服务)都受益于这些相同的保护措施。

ALTS 还用于在基础架构 RPC 机制中为从 Google 前端移动到应用前端的流量封装其他第 7 层协议(如 HTTP)。此保护措施会隔离应用层,避免对网络路径安全性的依赖。

服务可以配置为仅在“身份验证、完整性和私密性”模式下接受和发送 ALTS 通信,即使在由 Google 或 Google 代表方控制的物理边界内也是如此。例如,Google 的内部密钥管理服务,它存储和管理用于保护 Google 基础架构中静态存储的数据的加密密钥。

ALTS 协议

ALTS 具有类似于双向 TLS 的安全握手协议。希望使用 ALTS 进行通信的两项服务可以使用此握手协议,在发送任何敏感信息之前进行身份验证并协商通信参数。该协议包含两个步骤:

  • 第 1 步:握手 客户端使用 Curve25519 启动与服务器的椭圆曲线 Diffie Hellman (ECDH) 握手。每个客户端和服务器的证书中均具有已 认证的 ECDH 公共参数,该证书在 Diffie Hellman 密钥交换期间使用。握手会产生可用于客户端和服务器的公共流量密钥。证书中的对等身份将呈现在应用层以用于授权决策。
  • 第 2 步:记录加密 使用第 1 步中的公共流量密钥,将数据安全地从客户端传输到服务器。ALTS 中的加密使用 BoringSSL 和其他加密库实现。加密最常见的是 AES-128-GCM,而完整性则由 AES-GCM 的 GMAC 提供。

下面的图 5 详细展示了 ALTS 握手。在较新的实现中,由进程帮助程序执行握手;但还是存在某些情况,由应用直接执行握手。

图 5:ALTS 握手

服务到服务的身份验证、完整性和加密一节的开头部分所述,ALTS 使用服务帐号进行身份验证,Google 基础架构上运行的每项服务都以具有相关加密凭据的服务身份运行。在 ALTS 握手期间,进程帮助程序访问私钥和每个客户端/服务器对在其通信中使用的相应证书。服务的服务帐号身份预配了私钥和相应的证书(已签名的 Protocol Buffer)。

ALTS 证书 存在多种 ALTS 证书:

  • 机器证书:为特定机器上的核心服务提供身份。它们大约每 6 小时轮替一次。
  • 用户证书:为 Google 工程师开发代码提供最终用户身份。它们大约每 20 小时轮替一次。
  • Borg 作业证书:为在 Google 基础架构中运行的作业提供身份。它们大约每 48 小时轮替一次。

根证书签名密钥存储在 Google 的内部证书授权机构 (CA) 中,该机构与我们的外部 CA 无关,并且不受其影响。

ALTS 中的加密

ALTS 中的加密可以使用各种算法来实现,具体取决于所使用的机器。例如,大多数服务使用 AES-128-GCM13。如需详细了解 ALTS 加密,请查看表 2。

机器 使用的消息加密  
最常见 AES-128-GCM  
Sandy Bridge 或更旧版本 AES-128-VCM 使用 VMAC 而非 GMAC,在这些旧版机器上的效率稍高一些。

表 2:ALTS 中的加密

大多数 Google 服务使用 ALTS 或用到 ALTS 的 RPC 封装。如果未使用 ALTS,则采用其他保护措施。例如:

  • 一些低级机器管理和引导服务使用 SSH
  • 一些低级基础架构日志记录服务使用 TLS 或数据报 TLS (DTLS)14
  • 一些使用非 TCP 传输的服务在由 Google 或 Google 代表方控制的物理边界内使用其他加密协议或网络级保护

虚拟机和 Google Cloud Platform 服务之间的通信使用 TLS 而非 ALTS 与 Google 前端通信。我们将在虚拟机到 Google 前端的加密中介绍这些通信。

虚拟机到 Google 前端的加密

虚拟机到 GFE 的流量使用外部 IP 访问 Google 服务,但您可以将专用 Google 访问通道功能配置为使用 Google 专用 IP 地址来处理请求。

与对待外部用户向 Google 发出的请求一样,我们默认支持从虚拟机到 GFE 的 TLS 流量。连接的发生方式与任何其他外部连接的发生方式相同。如需详细了解 TLS,请参阅传输层安全协议 (TLS)

用户可配置的传输加密选项

传输加密中介绍了 Google 为传输中的数据配置的默认保护措施。本部分介绍用户可以对这些默认保护进行的配置。

本地数据中心到 Google Cloud

TLS 使用 GCLB 外部负载平衡器

如果您的云服务使用 Google HTTPS 或 SSL 代理外部负载平衡器,则 GFE 会使用您预配和控制的 SSL 证书终止用户的 TLS 连接。如需详细了解如何自定义证书,请参阅我们的 SSL 证书文档

使用 Google Cloud VPN 的 IPsec 隧道

作为 Google Cloud 客户,您可以使用 Google Cloud VPN 并通过 IPsec VPN 连接(第 3 层)将您的本地网络安全地连接到 Google Cloud Platform 虚拟私有云 (VPC) 网络。两个网络之间传输的流量由一个 VPN 网关加密,然后由另一个 VPN 网关解密。这样可以在互联网上保护您的数据。此外,您还可以通过多个 VPN 网关设置多个负载平衡隧道。Google Cloud VPN 通过以下方式保护您的数据:

  • 从您的虚拟机到 Cloud VPN 的数据包保留在 Google 的网络中。如果这些数据包从由 Google 控制或 Google 代表方控制的物理边界传出,Google Cloud 的虚拟网络会对其进行加密。
  • 从 Cloud VPN 到本地 VPN 的数据包使用 IPsec 隧道进行加密和身份验证。
  • 从本地 VPN 到本地主机的数据包由您网络上配置的控件提供保护。

要设置 VPN,请在托管服务的 VPC 网络上创建 Cloud VPN 网关和隧道,然后允许网络之间的流量。您还可以选择在两个 VPC 之间设置 VPN。

您可以为 VPN 隧道指定互联网密钥交换15 (IKE) 版本,以进一步自定义网络。IKE 有两种版本可供选择,IKEv1 和 IKEv2,它们分别支持不同的加密。如果指定 IKEv1,Google 会使用 AES-128-CBC 对数据包进行加密,并通过 SHA-1 HMAC16 确保完整性。如果指定 IKEv2,Google 提供并支持多种加密方式。在所有情况下,Google Cloud VPN 都会协商对等设备支持的最安全的通用协议。有关设置 VPN 的完整说明,请参阅选择 VPN 路由选项文档。

IPsec 隧道的替代方案是 Google Cloud 专用互连。专用互连可在本地网络和 Google 网络之间提供直接物理连接和 RFC 1918 通信。默认情况下,通过此连接传输的数据不会加密,因此应在应用层对其提供保护(例如使用 TLS)。Google Cloud VPN 和 Google Cloud Interconnect 使用相同的连接点,因此您可以使用 IPsec VPN 加密和专用互连,但要实现此目的,您需要使用第三方解决方案。目前不支持 MACsec(第 2 层保护)。

用户到 Google 前端

托管式 SSL 证书:免费的自动化证书

在 Google Cloud 上构建应用时,您可以配置您所使用的 SSL 证书,以利用 GFE 对 TLS 的支持。例如,您可以在应用中终止 TLS 会话。此终止与使用 GCLB 外部负载平衡器的 TLS 中描述的 TLS 终止不同。

Google 还在 Firebase 托管Google App Engine 自定义网域中提供免费的自动化 SSL 证书。这些证书仅适用于 Google 托管的资源。通过 Google App Engine 自定义网域,您还可以提供自己的 SSL 证书并使用 HTTP 严格传输安全协议 (HSTS) 标头。

您的网域指向 Google 的基础架构后,我们就会请求并获取该网域的证书,以便进行安全通信。我们管理 TLS 服务器私钥(2048 位 RSA 或 secp256r1 ECC),并代表我们的客户续订证书。

在 Gmail 中要求使用 TLS

传输层安全协议部分所述,Gmail 默认使用 TLS。Gmail 会记录并显示电子邮件是否在 TLS 会话中执行了最后一次跳跃17。当 Gmail 用户与其他 Gmail 用户交换电子邮件时,电子邮件会受到 TLS 保护;在某些情况下,电子邮件直接在应用内发送。在这些情况下,Gmail 应用使用的 RPC 受 ALTS 保护,如服务到服务的身份验证、完整性和加密中所述。对于来自其他电子邮件提供商的传入邮件,Gmail 不会强制采用 TLS。Gmail 管理员可以将 Gmail 配置为要求所有传入和传出电子邮件都采用安全的 TLS 连接。

Gmail S/MIME

安全/多用途互联网邮件扩展 (S/MIME) 是提供身份验证、完整性和加密的电子邮件安全标准。S/MIME 标准的实现要求在公共 CA 中托管与发送电子邮件的用户相关联的证书。

作为管理员,您可以配置 Gmail 以针对传出电子邮件启用 S/MIME,设置内容和附件合规性政策,并为传入和传出电子邮件创建路由规则。配置完成后,您必须使用 Gmail API 将用户的公共证书上传到 Gmail。对于 Gmail 外部的用户,必须交换 S/MIME 签名的初始邮件,以将 S/MIME 设为默认设置。

服务到服务和虚拟机到虚拟机的加密

Istio 是由 Google、IBM、Lyft 等开发的开源服务网格,用于简化服务发现和连接。Istio 身份验证可用于自动加密服务之间传输的数据,以及管理相关密钥和证书。您可在 Google Kubernetes Engine 和 Google Compute Engine 中使用 Istio。

如果要为工作负载实现双向身份验证和加密,可以使用 Istio 身份验证。具体来说,对于 Kubernetes 中的工作负载,Istio 身份验证允许集群级 CA 生成和分发证书,然后将证书用于 pod 到 pod 双向传输层安全协议 (mTLS)。

Google 如何帮助互联网加密传输中的数据

默认情况下的传输加密用户可配置的传输加密选项介绍了 Google Cloud 针对传输中的客户数据提供的默认保护和可自定义保护。此外,Google 还有几个开源项目,以及鼓励在互联网上广泛使用传输加密和数据安全功能的其他活动。

证书透明度

用户到 Google 前端的加密中所述,要提供 HTTPS,网站必须首先申请来自受信任的网络(公共)证书授权机构 (CA) 的证书。证书授权机构负责验证申请人是否已获得网域持有人的授权,并确保证书中包含的任何其他信息都准确无误。然后,系统会向浏览器提供此证书以对用户尝试访问的网站进行身份验证。为了确保 HTTPS 得到正确的身份验证,请务必确保 CA 仅颁发已经过网域持有人授权的证书。

证书透明度 (CT) 是 Google 于 2013 年 3 月发布的一项服务,旨在帮助网站运营商和网域持有人检测 CA 是否颁发了任何未经授权或不正确的证书。它为网域持有人、CA 和公众提供了一种机制,用于在可公开验证、仅允许追加操作的防篡改日志中记录他们看到的可信证书,或者记录他们颁发的证书(若为 CA)。任何人都可以检查这些日志中的证书,以确保信息准确无误,并且已经过授权。

证书透明度的第一个版本是在 IETF 实验版 RFC RFC 6962 中指定的。在开发证书透明度期间,Google 开源了许多工具,包括可以记录证书的开源日志服务器,以及用于创建证书透明度日志的工具。此外,Google Chrome 还要求必须公开披露某些证书,例如扩展验证 (EV) 证书或由之前有不当证书颁发记录的 CA 颁发的证书。从 2018 年起,Chrome 将要求披露所有新的受大众信任的证书。

作为网站运营商,您可以使用证书透明度来检测是否为您的网站颁发了未经授权的证书。有许多免费工具可以让您轻松完成此操作,例如 Google 的证书透明度报告Certificate SearchFacebook 的工具。即使您不使用证书透明度,许多浏览器现在也会定期检查证书透明度,以确保用户信任的用于访问网站的 CA 符合行业要求和最佳做法,从而降低颁发欺诈证书的风险。

增加 HTTPS 的使用

用户到 Google 前端的加密中所述,我们努力确保我们的网站和服务默认提供现代 HTTPS。我们的目标是在我们的产品和服务中实现 100% 加密。为此,我们每年发布一份 HTTPS 透明度报告,用于跟踪我们在所有资源(包括 Google Cloud)上实现此目标的进度。我们会不断攻克让我们难以在部分产品中支持加密的技术障碍,例如针对不支持 HTTP 严格传输安全协议 (HSTS)18 的浏览器或其他客户端的解决方案。我们在部分网站(包括 google.com 首页)中使用 HSTS,以允许用户仅通过 HTTPS 连接到服务器。

我们知道互联网上的其他网站也正在努力改用 HTTPS。我们尝试通过以下方式促进此举措:

2016 年,我们开始发布互联网上排名前 100 位的非 Google 网站的“互联网上 HTTPS 使用情况”指标。我们的目标是,通过这些指标提高认知度,为所有用户提高互联网的安全性。2017 年 10 月,Chrome 正式续签对 Let 's Encrypt 的财务支持,成为白金级赞助商。

更广泛地使用安全的 SMTP:Gmail 指标

大多数电子邮件使用简单邮件传输协议 (SMTP) 进行交换,但默认情况下,该协议发送电子邮件时不使用加密。要加密电子邮件,邮件提供商必须实现像 TLS 这样的安全控制机制。

用户到 Google 前端的加密中所述,Gmail 默认使用 TLS。此外,在 Gmail 中要求使用 TLS 一节介绍了 Gmail 管理员可以如何对传入和传出电子邮件强制使用 TLS 保护。与 Google 在 HTTPS 透明度方面所做的工作一样,Gmail 提供了 Gmail 传入电子邮件的 TLS 使用情况数据。这些数据显示在我们的更安全的电子邮件透明度报告中。

Google 与 IETF 及业界其他重要参与者合作,引领着 SMTP STS 的发展。SMTP STS 与 HTTPS 的 HSTS 类似,强制仅在加密隧道中使用 SMTP。

Chrome API

2015 年 2 月,Chrome 宣布仅向安全的来源19提供强大的新功能。这些功能包括处理私人信息和访问用户设备上的传感器。当时,我们以 Chrome 50 中的地理定位功能为切入点,开始针对不安全的来源弃用这些功能。

传输加密的持续创新

Chrome 安全用户体验

Google Chrome 是利用界面显示安全信息领域的行业领导者,用户能够快速了解与某网站的连接的安全性。通过这些信息,用户可以更好地决定共享数据的时间和方式。Chrome 进行了广泛的用户研究,并在经过同行评审的论文中分享结果。

为了进一步保护用户,Chrome 已宣布要在 2017 年年底之前将所有 HTTP 连接标记为不安全。从 Chrome 56 开始,如果 HTTP 页面包含带有密码或信用卡字段的表单,用户在默认情况下会看到警告。如果使用 Chrome 62,用户在 HTTP 页面上输入数据,以及在无痕模式下访问所有 HTTP 页面时,都会看到一条警告。最终,Chrome 会对通过 HTTP 提供的所有网页显示警告。

要查看 Chrome 中如何对用户显示特定的配置,您可以使用 BadSSL 工具

密钥透明度

广泛采用消息加密的一个重大阻碍是公钥交换所遇到的困难:如何以可靠方式找到与我通信的新用户的公钥?为帮助解决此问题,Google 于 2017 年 1 月推出“密钥透明度”(Key Transparency) 服务。这是一个开放式框架,提供了一种通用、安全和可审计的方式来分发公钥。该框架无需用户执行手动密钥验证。密钥透明度主要面向通信中用户公钥的分发,例如 E2E 和 OpenPGP 电子邮件加密。密钥透明度的设计基于从证书透明度CONIKS 中获得的见解,是一种新的密钥恢复和分发方法。

密钥透明度是一个开源开发项目,在实现中使用了大型 Merkle 树。密钥透明度验证允许帐号所有者查看与其帐号关联的密钥,以及该帐号活跃和稳定的时间。Google 的密钥透明度工作的长期目标是让所有人都能运行密钥透明度服务器,并将其轻松集成到任意数量的应用中。

后量子加密

Google 计划在传输加密领域继续保持业界领先地位。为此,我们已开始在后量子加密领域开展工作。利用这种加密,我们可以将易受有效量子攻击影响的现有加密原语替换为后量子候选方案,后者被认为能够更可靠地应对此类攻击。2016 年 7 月,我们宣布就部署此类算法的可行性开展了一项实验,具体做法是在 Chrome 开发者版本中使用新希望后量子加密算法。除了这项工作,Google 的研究人员还发表了关于其他实用的后量子密钥交换协议的论文

附录

详细了解 Google Cloud 安全性(包括我们的基础架构安全设计概述),以及 Google Cloud 合规性(包括公开的 SOC 3 审核报告)。

脚注

1 合作伙伴解决方案包括 Cloud Launcher 中提供的解决方案,以及与合作伙伴合作构建的产品(例如 Cloud Dataprep)。
2 您仍然可以停用此加密,例如,对 Google Cloud Storage 存储分区的 HTTP 访问停用此加密。
3 在第 7 层未受保护的虚拟机到服务的通信在第 3 层和第 4 层仍然会受到保护
4 TLS 1.3 尚未最终定稿。草稿版本仅供某些 Google 网域(例如 Gmail)用于测试。
5 对于仍在使用 TLS 1.0 这一协议版本的浏览器,Google 目前继续提供支持。请注意,到 2018 年 7 月,任何处理信用卡信息的 Google 网站将不再支持 TLS 1.0,因为支付卡行业 (PCI) 规定弃用 TLS 1.0。
6 如需详细了解 QUIC,请访问 [https://www.chromium.org/quic](https://www.chromium.org/quic)。
7, 8, 9 我们支持 3DES、SHA1 和 MD5,以向后兼容某些旧版操作系统
10 如果是链式证书,则 CA 是间接可信的。
11 这可以是会话票证 ([RFC 5077](https://tools.ietf.org/html/rfc5077)) 或会话 ID ([RFC 5246](https://tools.ietf.org/html/rfc5246))。
12 控制平面是网络中承载信号流量并负责路由的部分。
13 之前使用过其他协议,但现已弃用。只有不到 1% 的作业使用这些旧协议。
14 数据报 TLS (DTLS) 允许基于数据报的应用以防止窃听和篡改的方式进行通信,从而可确保这些应用的安全。
15 互联网密钥交换 (IKE) 是用于在 IPsec 协议套件中设置安全关联的一种协议。
16 HMAC-SHA-1 未被 [SHA-1 碰撞](https://shattered.io/) 损坏,例如 Google 研究人员发现的 SHAttered 碰撞。
17 对于 G Suite 企业版,此信息不会显示在界面中。网域管理员可以使用 [电子邮件日志搜索](https://support.google.com/a/answer/2604578) 检查其网域的数据。
18 HTTP 严格传输安全协议 (HSTS) 是一种具有以下作用的机制:允许网站声明自身只能通过安全连接访问;以及/或者允许用户定向其用户代理,以便仅通过安全连接与给定网站进行交互。
19 安全来源是与某些方案、主机或端口 [模式](https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features) 匹配的连接。