Google Cloud 的传输中加密

此内容的上次更新时间为 2025 年 4 月，反映了当时的实际情况。由于我们会不断改善对客户的保护机制，Google 的安全政策和系统今后可能会发生变化。

在 Google，我们的安全控制措施可帮助保护您的数据，无论这些数据是通过互联网传输、在 Google 的基础架构内转移，还是存储在我们的服务器上。Google 安全策略的核心是身份验证、完整性和加密，对于静态数据和传输中的数据均适用。本文介绍了我们如何设计Google Cloud 来加密通过互联网传输的数据以及在 Google 网络内传输的数据。本文档不适用于通过客户数据中心网络和 Google 数据中心网络之间的互连传输的数据。

传输加密使用各种技术来帮助保护数据，包括传输层安全协议 (TLS)、BoringSSL、应用层传输安全 (ALTS) 和 PSP 安全协议。 除了 Google 提供的默认保护之外，您还可以通过添加加密选项（例如 IPsec、托管式 TLS 证书和 Cloud Service Mesh）来进一步保护数据。

本文档面向正在使用或考虑使用 Google Cloud的首席信息安全官 (CISO) 和安全运维团队。本文档假定读者对加密和加密原语具有基本的了解。

身份验证、完整性和加密

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

  • 身份验证用于验证连接中对等方（人员或进程）的身份。
  • 完整性可防止您发送的数据在来源和目标之间传输时被更改。
  • 加密使用密码学技术，确保您的数据在传输过程中无法被读取，并保持其保密性。

当数据在最终用户与 Google Cloud 之间或在两个服务之间移动时，如果通信遭到拦截，传输加密可帮助保护您的数据。传输加密会在传输之前对端点进行身份验证并加密数据。到达时，接收方会解密数据并验证数据在传输过程中是否未被修改。

安全策略种类繁多，而加密是其中一种。传输加密可保护您的数据免受潜在攻击者的侵害，并使 Google、 Google Cloud 客户或最终用户无需信任网络的较低层。

流量路由方式

本部分介绍最终用户的请求如何传到相应的Google Cloud 服务或客户应用，以及流量如何在服务之间路由。

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

客户应用是指托管在 Google Cloud 上的应用，您（作为 Google 客户）可以使用 Google Cloud服务构建和部署此类应用。托管在Google Cloud 上的客户应用或合作伙伴解决方案不被视为 Google Cloud 服务。例如，您使用 Cloud Run、Google Kubernetes Engine 或 Compute Engine 中的虚拟机构建的应用是客户应用。

下图显示了从最终用户到 Google 的流量路径、Google 网络内的路径以及每个连接的安全措施。系统会显示以下流量路径：

  • 互联网上的最终用户到 Google Cloud 服务（在图表中标记为 A）
  • 互联网上的最终用户到Google Cloud 上托管的客户应用（在图表中标记为 B）
  • 虚拟机到虚拟机（在图表中标记为 C）
  • 虚拟机到 Google Front End (GFE)（在图表中标记为 D）
  • GFE 到 Google API 和服务（在图表中标记为 E）
  • Google Cloud 服务到 Google Cloud 服务（在图表中标记为 F）

Google 的流量路径。

最终用户与 Google 之间的传输加密

以下部分详细介绍了上图中所示的最终用户路由请求。

最终用户到 Google Cloud 服务

Google Cloud 服务（例如 Cloud Storage 或 Compute Engine）是我们向客户提供的云服务，在我们的生产环境中运行。Google Cloud 服务使用称为 Google Front End (GFE) 的全球分布式系统接收来自世界各地的请求。GFE 会终止传入的 HTTP(S)、TCP 和 TLS 连接的流量，针对 DDoS 攻击提供反制对策，将流量路由到Google Cloud 服务本身并进行负载均衡。全球各地都有 GFE 入网点，这些站点通过单播或任播通告路径。

GFE 通过 Google 的网络将流量从最终用户路由到Google Cloud 服务，以及从最终用户路由到托管在 Google Cloud 上并使用 Cloud Load Balancing 的客户应用。

客户端通过 HTTPS、HTTP/2 或 HTTP/3 向 Google Cloud 服务发送的请求会通过 TLS 进行保护。GFE 中的 TLS 是通过 BoringSSL 实现的，后者是 Google 维护的 TLS 协议的开源实现。BoringCrypto 是 BoringSSL 的核心，已通过 FIPS 140-3 级别 1 验证。

GFE 会与客户端协商业界标准的加密参数，包括前向安全密钥协商。对于较旧且性能较低的客户端，GFE 会选择客户端提供的最强大的旧版加密原语。

最终用户到 Google Cloud上托管的客户应用

您可以使用直接连接或通过负载均衡器将最终用户流量从互联网路由到托管在 Google Cloud 上的客户应用。当流量直接路由时，流量会路由到托管应用的虚拟机服务器的外部 IP 地址。

您可以将 TLS 与外部应用负载均衡器或外部代理网络负载均衡器搭配使用，以连接到在 Google Cloud上运行的应用。使用第 7 层负载均衡器时，最终用户与负载均衡器之间的连接默认使用 TLS 进行加密（前提是最终用户的客户端应用支持 TLS）。GFE 会使用自行管理的或 Google 管理的 TLS 证书终止最终用户的 TLS 连接。如需详细了解如何自定义证书，请参阅 SSL 证书概览。如需在负载均衡器与托管客户应用的虚拟机之间启用加密，请参阅从负载均衡器到后端的加密。

如需配置双向 TLS (mTLS)，请参阅双向 TLS 概览。对于 GKE 和 Compute Engine 上的工作负载，请考虑使用 Cloud Service Mesh，以便使用 mTLS 进行双向身份验证（客户端和服务器），并使用您管理的证书加密传输中的通信。

对于 Firebase Hosting 和 Cloud Run 自定义网域，请考虑使用我们的免费自动化 TLS 证书。通过 Cloud Run 自定义网域，您还可以提供自己的 SSL 证书并使用 HTTP 严格传输安全协议 (HSTS) 标头。

Google 网络中的传输加密

Google Cloud 在 Google 网络中加密传输中的客户数据，除非本部分另有说明。

Google AI 超级计算机中连接 TPU 或 GPU 的专用超高性能互连与本文档中所述的网络是分开的。在 Google Cloud中，这些超高性能互连是用于 TPU 的 ICI 和用于 GPU 的 NVLink。如需了解详情，请参阅 TPU 架构和 GPU 机器类型。

使用外部 IP 地址连接到虚拟机的流量会离开 Google 的网络。您需要自行配置这些连接的加密。

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

Google Cloud的虚拟网络会对虚拟机之间的流量进行加密、完整性保护和身份验证。

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

每对通信主机都使用受 ALTS 保护的控制隧道建立会话密钥，以进行经过身份验证、完整性受保护且加密的通信。会话密钥用于加密这些主机之间的虚拟机到虚拟机的通信，并且会话密钥会定期轮替。

VPC 网络中的虚拟机到虚拟机的连接，以及 Google 生产网络中的对等互连 VPC 网络均经过完整性受保护和加密。这些连接包括客户虚拟机之间以及客户和 Google 管理的虚拟机（例如 Cloud SQL）之间的连接。流量的路由方式中的图表显示了这种互动（标记为连接 C）。请注意，由于 Google 会根据内部 IP 地址的使用情况自动启用加密，因此使用外部 IP 地址的虚拟机之间的连接不会自动加密。

Google Cloud的虚拟网络会对虚拟机之间的所有流量进行身份验证。这种通过安全令牌实现的身份验证可以防止遭入侵的主机受到网络上仿冒数据包的攻击。

安全令牌封装在隧道头中，其中包含有关发送者和接收者的身份验证信息。发送主机的控制平面设置令牌，而接收主机验证令牌。 每个流都预先生成有安全令牌，由令牌（包含发送者的信息）和主机密钥组成。

与 Google API 和服务的连接

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

大多数 Google API 和服务都托管在 GFE 上。虚拟机到 GFE 的流量使用外部 IP 地址访问 Google Cloud 服务，但您可以配置专用访问通道，以避免使用外部 IP 地址。从 GFE 到服务的连接会进行身份验证和加密。

某些服务（例如 Cloud SQL）托管在 Google 管理的虚拟机实例上。如果客户虚拟机使用外部 IP 地址访问 Google 管理的虚拟机实例上托管的服务，则流量会保留在 Google 的生产网络中，但由于使用外部 IP 地址而不会自动加密。如需了解详情，请参阅 Google Cloud 虚拟网络身份验证和加密。

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

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

Google 的基础架构使用 ALTS 对从 GFE 到 Google Cloud 服务以及从一个 Google Cloud 服务到另一个 Google Cloud 服务的连接进行身份验证、完整性检查和加密。

ALTS 使用基于服务的身份进行身份验证。在 Google 的生产环境中运行的服务会获得凭证，以声明其基于服务的身份。从其他服务创建或接收 RPC 时，服务使用其凭证进行身份验证。ALTS 会验证这些凭证是否由 Google 的内部 CA 签发。Google 的内部 CA 与 Certificate Authority Service 无关，并且不受其影响。

ALTS 使用加密和加密完整性保护来保护流量，这些流量用于在 GFE 与在 Google 生产环境中运行的服务之间以及在这些服务之间传输 Google Cloud 数据。

ALTS 还用于在 RPC 机制中为 GFE 与 Google Cloud 服务之间的流量封装其他第 7 层协议（如 HTTP）。此保护措施有助于隔离应用层，避免对网络路径安全性的任何依赖。

传输加密方法

以下部分介绍了 Google 用于加密传输中的数据的一些技术。

使用 PSP 进行网络加密

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

PSP 旨在满足大规模数据中心流量的要求。 Google 基础架构使用 PSP 来加密数据中心内部和数据中心之间的流量。PSP 还支持 UDP 等非 TCP 协议，并为每个连接使用唯一的加密密钥。

应用层传输安全

ALTS 是 Google 开发的双向身份验证和加密系统。ALTS 可为在 Google 生产环境中运行的服务之间传输的数据提供身份验证、保密性和完整性。ALTS 包含以下协议：

  • 握手协议：客户端启动椭圆曲线和量子安全密钥交换的组合。在握手结束时，相关服务会通过交换和验证签名证书来相互验证身份，并计算共享流量密钥。支持用于派生共享流量密钥的算法包括 NIST 后量子算法 ML-KEM (FIPS 203)。如需了解详情，请参阅后量子加密。

  • 记录协议：服务间数据在传输过程中使用共享流量密钥进行加密。默认情况下，ALTS 会对所有流量使用 AES-128-GCM 加密。在 Google 最低级别的存储系统内传输的数据使用 AES-256 加密，ALTS 提供 AES 消息身份验证。ALTS 中的加密由 BoringSSL 或 PSP 提供。此加密已通过 FIPS 140-2 级别 1 或 FIPS 140-3 级别 1 验证。

ALTS 证书的根签名密钥存储在 Google 的内部 CA 中。

后续步骤