传输加密

这是关于 Google 如何通过加密来保护您的数据的第三份白皮书。本白皮书将更详细地介绍 Google Cloud 和 Google Workspace 中的传输加密的相关信息。

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

本页内容的上次更新时间为 2022 年 9 月，代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制，Google 的安全政策和系统今后可能会发生变化。

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

  • Google 采用多种安全措施来确保传输中的数据的真实性、完整性和私密性。
  • 对于本白皮书中介绍的使用场景，在将数据将移出由 Google 或 Google 授权代理方控制的物理边界时，Google 会在一个或多个网络层对传输中的数据进行加密和身份验证。系统会对 VPC 网络与对等互连的 VPC 网络中的所有虚拟机之间的流量进行加密。
  • 根据正在建立的连接，Google 会对传输中的数据应用默认保护。例如，我们使用传输层安全协议 (TLS) 保护用户与 Google Front End (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 员工可以访问硬件。在这些物理边界内传输的数据通常会经过身份验证，但默认情况下可能不会加密。

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

流量路由方式

如需全面了解 Google 传输加密的工作原理，还需要介绍流量在互联网中的路由方式。本部分介绍最终用户的请求如何传到相应的 Google Cloud 服务或客户应用，以及流量如何在服务之间路由。

Google Cloud 服务是我们为客户提供的模块化云服务。这些服务包括计算、数据存储、数据分析和机器学习。例如，Cloud Storage 是一项 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）。

如果您使用的是外部应用负载均衡器或外部代理网络负载均衡器（使用 SSL 代理），请参阅从负载均衡器到后端的加密。

虚拟机到虚拟机

VPC 网络中的虚拟机到虚拟机的连接，以及 Google 生产网络中的对等互连 VPC 网络均经过身份验证和加密。这包括客户虚拟机之间以及客户和 Google 管理的虚拟机（例如 Cloud SQL）之间的连接。图 1 显示了这种交互（标记为连接 C）。 请注意，使用外部 IP 地址的虚拟机之间的连接不会加密。

与 Google API 和服务的连接

流量处理方式因 Google Cloud 服务的位置而异：

  • 大多数 Google API 和服务都托管在 Google Front End 前端 (GFE) 上；但是，某些服务托管在 Google 代管的实例上。例如，专用服务访问通道和适用于专用集群的 GKE 主实例托管在 Google 代管的实例上。

    借助专用 Google 访问通道，没有外部 IP 地址的虚拟机可以访问受支持的 Google API 和服务，包括 App Engine 上托管的客户应用。如需详细了解如何访问 Google API 和服务，请参阅服务的专用访问通道选项。

  • 如果一个 Compute Engine 虚拟机实例连接到另一个 Compute Engine 虚拟机实例的外部 IP 地址，则流量会保留在 Google 的生产网络中，但由于使用外部 IP 地址而不会加密。如果 Google 生产网络以外的系统连接到 Compute Engine 虚拟机实例的外部 IP 地址，系统会通过互联网路由流量。

    图 1 显示了外部路径（标记为连接 D）。此类路由请求的典型情况包括：

    • 从 Compute Engine 虚拟机到 Google Cloud Storage
    • 从 Compute Engine 虚拟机到机器学习 API

从虚拟机到 GFE，默认情况下，Google Cloud 服务支持使用 TLS 保护这些连接2。从 GFE 到服务的连接会进行身份验证，且连接在离开物理边界时会进行加密。 除了这些默认保护之外，您还可以应用信封加密。如需了解详情，请参阅加密数据。

Google Cloud 服务到 Google Cloud 服务

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

系统使用 ALTS 加密跨物理边界将用户的流量路由到 Google Cloud 服务。

图 1：VPC 网络上的默认保护措施和叠加的各种选项

默认情况下的传输加密

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

对于流向虚拟机以及跨边界的数据流量，第 3 层和第 4 层的加密选项会对其进行加密。

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

第 7 层的加密选项包括用于在虚拟机之间传输以及流向 Google Front End 的数据的选项。

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

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

用户到 Google Front End 的加密

如今，许多系统使用 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.3 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 SHA17
TLS 1.04     AES-256-CBC MD58
QUIC5     ChaCha20-Poly1305  
      3DES6  

表 1：在 Google Front End 为 Google Cloud 服务实现的加密，以及在 BoringSSL 加密库中实现的加密

Google 的证书授权机构

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

Google 在过去一直运营着自己的证书颁发 CA，供我们用于签署 Google 网域的证书。不过我们没有运营过我们自己的根 CA。现在我们的 CA 证书由多个广泛分布的根 CA 进行交叉签名，包括 DigiCert 和以前由 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 证书有效期限制为大约三个月，并且证书大约每两周轮替一次。

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

Google 前端到应用前端

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

对于 Google Cloud 服务，使用 ALTS 保护 RPC。对于托管在 Google Cloud 上的客户应用，如果流量通过 Google Front End 路由（例如使用 Google Cloud Load Balancer 时），则使用 Google Cloud 的虚拟网络加密功能保护路由到虚拟机的流量，如下一部分所述。

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

在网络层对同一 VPC 内或 Google Cloud 虚拟网络内的对等互连 VPC 网络之间的专用 IP 流量进行加密。

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

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

进行身份验证时，安全令牌被封装在隧道头中，其中包含有关发送者和接收者的身份验证信息。发送端的控制平面11会设置令牌，而接收主机会验证令牌。每个流都预先生成有安全令牌，该令牌由令牌密钥（包含发送者的信息）和主机密钥组成。由 Google 或 Google 授权代理方控制的物理边界的每个来源/接收者对都存在一个密钥。

图 4 显示了令牌密钥、主机密钥和安全令牌的创建方式。

安全令牌的组成部分可以包括令牌密钥和主机密钥及其依赖项。

图 4：安全令牌

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

虚拟机到 Google 前端的加密

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

默认情况下，我们支持从虚拟机到 GFE 的 TLS 流量。连接的发生方式与任何其他外部连接的发生方式相同。如需详细了解 TLS，请参阅传输层安全协议 (TLS)。

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

在 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 Front End 移动到应用前端的流量封装其他第 7 层协议（如 HTTP）。此保护措施会隔离应用层，避免对网络路径安全性的依赖。

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

使用 PSP 进行网络加密

PSP 安全协议 (PSP) 与传输无关，可实现每个连接的安全性，并且支持将加密分流到智能网络接口卡 (SmartNIC) 硬件。每当 SmartNIC 可用时，我们都会使用 PSP 对我们网络的传输中的数据进行加密。

PSP 旨在满足大规模数据中心流量的要求。我们使用 PSP 来加密数据中心内部和数据中心之间的流量。PSP 支持 UDP 等非 TCP 协议，并为每个第 4 层连接使用加密密钥。

如需详细了解如何使用 PSP，请参阅宣布大规模 PSP 的加密硬件分流现已成为开源项目。

ALTS 协议

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

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

下图详细展示了 ALTS 握手。在较新的实现中，由进程帮助程序执行握手；但在部分情况下，由应用直接执行握手。

客户端应用通过进程帮助程序与握手服务交互，通过密钥交换与服务器应用交互。

图 5：ALTS 握手

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

ALTS 证书 存在多种 ALTS 证书：

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

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

ALTS 中的加密

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

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

表 2：ALTS 中的加密

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

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

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

配置其他传输加密选项

您可以为 Google Cloud 和数据中心之间传输的数据或 Google Cloud 上托管的应用和用户设备之间传输的数据配置保护措施。

如果要将数据中心连接到 Google Cloud，请考虑以下事项：

如果您要将用户设备连接到 Google Cloud 中运行的应用，请考虑以下事项：

  • 配置您所使用的 SSL 证书，以利用 GFE 对 TLS 的支持。例如，您可以在应用中终止 TLS 会话。
  • 考虑可用于 Firebase Hosting 和 App Engine 自定义网域的免费自动 SSL 证书。通过 App Engine 自定义网域，您还可以提供自己的 SSL 证书并使用 HTTP 严格传输安全协议 (HSTS) 标头。
  • 对于 GKE 和 Compute Engine 上的工作负载，请考虑使用 GKE Enterprise Service Mesh，以便使用 mTLS 进行身份验证，从而确保所有 TCP 通信在传输过程中都经过加密。

如果您使用的是 Google Workspace，请配置 Gmail 以针对传出电子邮件启用 S/MIME，为内容和附件合规性设置政策，并为传入和传出电子邮件创建路由规则。

传输加密的研究与创新

多年来，我们参与了多项开源项目以及鼓励在互联网上使用传输加密的其他工作。

这些工作包括：

如需详细了解我们近期的贡献，请参阅与安全研究社区的协作。

后续步骤

脚注

1 合作伙伴解决方案包括 Cloud Launcher 中提供的解决方案，以及与合作伙伴合作构建的产品（例如 Cloud Dataprep）。
2 您仍然可以停用此加密，例如，对 Google Cloud Storage 存储分区的 HTTP 访问停用此加密。
3 在第 7 层未受保护的虚拟机到服务的通信在第 3 层和第 4 层仍然会受到保护。
4 对于仍在使用 TLS 1.0 这一协议版本的浏览器，Google 目前继续提供支持。请注意，到 2018 年 7 月，任何处理信用卡信息的 Google 网站将不再支持 TLS 1.0，因为支付卡行业 (PCI) 规定弃用 TLS 1.0。
5 如需详细了解 QUIC，请访问 https://www.chromium.org/quic。
6、7、8 我们支持 3DES、SHA1 和 MD5，以向后兼容某些旧版操作系统。
9 如果是链式证书，则 CA 是间接可信的。
10 这可以是会话票证 RFC 5077 或会话 ID RFC 5246。
11 控制平面是网络中承载信号流量并负责路由的部分。
12 之前使用过其他协议，但现已弃用。只有不到 1％ 的作业使用这些旧协议。
13 数据包 TLS (DTLS) 允许基于数据包的应用以防止窃听和篡改的方式进行通信，从而确保这些应用的安全。