本文档详细介绍了 Google Distributed Cloud (GDC) 网闸隔离配置传输加密。
面向首席信息官级别领导者的摘要
- GDC 采用多种安全措施来确保传输中的数据的真实性、完整性和机密性。
- 根据所建立的连接，GDC 会对 GDC 组件传输中的数据应用默认保护。例如，我们使用 TLS 保护用户与 GDC Cloud Service Mesh 入站流量网关之间的通信。
简介
在选择云服务提供商时，安全性通常是一个决定性因素。在 Google 看来，安全性是重中之重。我们不懈努力，保护您的数据，无论这些数据是通过您的网络传输、在 Google 的基础架构内转移，还是存储在我们的服务器上。
Google 安全策略的核心是身份验证、完整性和加密，对于静态数据和传输中的数据均适用。本文将介绍我们在 Google Distributed Cloud 网闸隔离配置 (GDC) 中采用的传输加密方法。
对于静态数据，请参阅静态加密。如需大致了解各种 Google 安全机制，请参阅 Google 基础架构安全设计概述。
受众群体：本文档面向正在使用或考虑使用 GDC 的首席信息安全官 (CISO) 和安全运维团队。
前提条件：除了本简介之外，我们还假定读者对加密和密码学原语具有基本的了解。
身份验证、完整性和加密
GDC 采用多种安全措施来确保传输中的数据的真实性、完整性和机密性。
- 身份验证：我们在网络层对数据目的地进行身份验证。来源由 GDC 管理的 AIS 进行身份验证。
- 完整性：我们会确保您发送的数据原样到达目的地，即防止未经授权的更改。
- 加密：我们会确保您的数据在传输过程中无法被读取，以保持其机密性。加密是使清晰易辨的数据（明文）变得无法辨认（密文）的过程，目的是确保只有经数据所有者授权的各方才能访问明文。加密过程中使用的算法是公开的，但解密密文所需的密钥是私有的。传输加密通常使用非对称密钥交换（例如基于椭圆曲线的迪菲-赫尔曼）来建立用于数据加密的共享对称密钥。如需详细了解加密，请参阅现代密码学简介。
加密可用于保护多种状态下的数据：
- 静态加密通过加密存储的数据，防止您的数据受到系统入侵或数据渗漏的危害。高级加密标准 (AES) 通常用于加密静态数据。
- 传输加密：当数据在您的网站与云服务商之间或在两个服务之间移动时，如果通信遭到拦截，则可保护您的数据。这种保护是通过在传输之前加密数据，对端点进行身份验证，并在抵达时解密数据以及验证数据未被修改来实现的。例如，传输层安全协议 (TLS) 通常用于加密传输中的数据以实现传输安全性，而安全/多用途网际邮件扩充协议 (S/MIME) 通常用于实现电子邮件加密。
安全策略种类繁多，而加密是其中一种。在建立连接并进行身份验证后，传输加密会通过以下方式保护您的数据免受潜在攻击者的侵害：
- 无需信任通常由第三方提供的较低网络层级
- 减少潜在的攻击面
- 在通信被拦截时，阻止攻击者访问数据
通过充分的身份验证、完整性和加密，可以在不安全的环境中保护在用户、设备或进程之间传输的数据。本文的其余部分将介绍 GDC 的传输中的数据加密方法及其应用场景。
GDC 网络基础设施
物理边界
物理边界是指由 Google 或 Google 授权代理方控制的物理空间的屏障，我们可以确保在其中配置严格的安全措施。对这些位置的物理访问受到限制、严密监控和审核。只有一小部分获批人员可以访问硬件。在这些物理边界内传输中的数据通常会经过身份验证和加密。
对于进出 GDC 物理边界的通信，我们采用强大的身份验证和加密技术来保护传输中的数据。
流量路由方式
如需了解 GDC 传输加密的工作原理，需要先介绍流量如何路由到 GDC 以及如何在 GDC 中路由。本部分介绍最终用户的请求如何传到相应的 GDC 服务或客户应用，以及流量如何在跨站点服务之间路由。
GDC 托管式服务是一种模块化私有云服务。这些服务包括计算、存储和机器学习。例如，GDC 对象存储区是一项由 GDC 代管式服务。客户应用是指托管在 GDC 上的应用，GDC 客户可以使用 GDC 服务构建和部署此类应用。托管在 GDC 上的客户应用或合作伙伴解决方案不被视为 GDC 托管式服务。例如，您使用 GDC 虚拟机、数据库服务和 Vertex AI 构建的应用是客户应用。
图 1 显示了不同类型的路由请求。图 1 显示了各个网络组件之间的交互以及为每种连接配置的安全措施。
图 1：站点间连接基础架构
最终用户（客户网络）到 GDC API 和代管式服务
对于托管在 Cloud Service Mesh 入站流量网关上的托管式服务，它们会使用 Cloud Service Mesh 入站流量网关接受来自客户网络的请求。Cloud Service Mesh Ingress Gateway 会代理传入的 HTTP(S) 流量，并将流量路由到 GDC 托管式服务本身并进行负载均衡。另一个防火墙层提供 DDoS 攻击对策，并具有入侵检测和防御功能。从 Cloud Service Mesh Ingress Gateway 到 GDC 代管式服务前端的连接会经过身份验证和加密。图 1 将这种交互显示为连接 A。
大多数 GDC API 和托管式服务都托管在 Cloud Service Mesh 入站流量网关上。不过，某些服务直接托管在 GDC 管理的第 4 层负载均衡器上。例如，DBS 数据库托管在 GDC 外部负载均衡器上。这些服务配置为使用 TLS 在应用层对连接进行身份验证和加密。图 1 将这种互动显示为连接 B。
最终用户（客户网络）到 GDC 上托管的客户应用
您可以通过多种方式将流量从客户网络路由到 GDC 上托管的客户应用。路由流量的方式取决于您的配置。
通过客户 API Gateway 公开客户应用
GDC 支持通过客户 API Gateway 公开客户应用。客户 API Gateway 服务使用户能够根据需要开发、部署、保护、管理和扩缩 API。图 1 将这种交互显示为连接 C。
通过客户外部负载均衡器公开容器化客户工作负载
GDC 支持通过外部负载均衡器公开由客户管理的容器化工作负载。GDC 允许相应人员配置入站流量和出站流量政策。图 1 将这种互动显示为连接 E。
公开虚拟机工作负载
GDC 支持向最终用户公开客户创建的虚拟机。GDC 允许相应人员配置入站和出站政策。图 1 将这种交互显示为连接 F。
GDC 跨站互连服务
从一个代管式服务路由到另一个托管式服务通常完全在 GDC 的物理边界内进行。在某些情况下（例如跨站点备份），数据会路由到 GDC 的物理边界之外。在这种情况下，数据既会在应用层（例如 TLS）进行加密，也可以在网络层进行加密。 图 1 将这种交互显示为连接 G。
虚拟机到虚拟机
GDC 内的虚拟机到虚拟机连接不会在网络层级进行加密。客户负责使用适当的加密协议或特定技术（例如 IPSec 隧道）对数据进行加密。
默认情况下的传输加密
GDC 采用多种加密方法（包括默认加密和用户可配置的加密）来保护传输中的数据。使用的加密类型取决于 OSI 层、服务类型和基础架构的物理组件。本部分介绍 Google 用于保护传输中的数据的默认保护。
本部分的其余部分介绍 Google 用于保护传输中的数据的默认保护。
用户到 Cloud Service Mesh Ingress 网关加密
如今，许多系统都使用 HTTPS 通过互联网进行通信。HTTPS 通过使用 TLS 连接来提供安全性，从而确保请求和响应的真实性、完整性和机密性。如需接受 HTTPS 请求，接收者需要有公钥/私钥对和 X.509 证书，以便从证书授权机构 (CA) 进行服务器身份验证。密钥对和证书通过证明接收方拥有请求所针对的域名，帮助在应用层（第 7 层）对用户的请求进行身份验证。以下各小节介绍用户到 Cloud Service Mesh 入站网关加密的组成部分，即：TLS、BoringSSL 和 GDC 可配置证书授权机构。
传输层安全协议 (TLS)
当您向 GDC 服务发送请求时，我们会保护传输中的数据；使用 HTTPS 和来自可信证书授权机构的证书提供身份验证、完整性和加密。系统会使用传输层安全协议 (TLS) 加密在传输过程中的由用户发送到 Cloud Service Mesh Ingress Gateway 的任何数据，这些数据用于 GDC 代管式服务。Cloud Service Mesh 入站网关会根据客户端可以支持的内容与客户端协商特定的加密协议。GDC Cloud Service Mesh 入站流量网关仅强制执行 FIPS 批准的算法，以提供更强大的安全性。
BoringSSL
BoringSSL 是 Google 维护的 TLS 协议的开源实现，从 OpenSSL 分支而来，在很大程度上与 OpenSSL 接口兼容。Google 从 OpenSSL 派生出了 BoringSSL，以简化 OpenSSL，既供内部使用，又可更好地支持 Chromium 和 Android 开源项目。BoringCrypto 是 BoringSSL 的核心，已通过 FIPS 140-2 级别 1 验证。
Cloud Service Mesh 入站流量网关中的 TLS 是通过 BoringSSL 实现的。表 1 显示了 GDC 在与客户端通信时支持的加密协议。
| 协议 | 身份验证 | 密钥交换 | 加密 | 哈希函数 |
|---|---|---|---|---|
| 传输层安全协议 (TLS) 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
表 1：在 Cloud Service Mesh 入站流量网关中为 GDC 服务实现的加密，以及在 BoringSSL 加密库中实现的加密
GDC 可配置证书授权机构
作为 TLS 的一部分，服务器在收到连接请求时必须向用户证明其身份。在 TLS 协议中，这种身份验证是通过让服务器出示包含其声称身份的证书来实现的。证书包含服务器的 DNS 主机名及其公钥。服务器提供的证书将由负责颁发事宜且受请求连接的用户所信任的证书授权机构 (CA) 进行签名。因此，请求与服务器建立连接的用户只需要信任根 CA 即可。如果服务器希望被广泛访问，则任何潜在的客户端设备都需要知道根 CA。客户端浏览器和设备会根据客户端运行的环境，配置一组其信任的根 CA。
GDC 的根 CA 取决于其部署环境以及该环境中客户的要求。
Cloud Service Mesh 入站流量网关到应用前端
两种情况：
- Cloud Service Mesh 入站流量网关终止 TLS，使用 Cloud Service Mesh Istio 证书重新加密 mTLS
- 从 Ingress 网关到 Istio Sidecar 应用前端的 mTLS
- Cloud Service Mesh 入站网关会终止 TLS，并使用配置的 CA 将 TLS 重新加密到其他服务器。
存储流量的网络加密
在 GDC 文件和块存储系统中，流量会在使用存储空间的应用与存储服务之间路由。这些数据在传输过程中会使用 IPSec 进行身份验证和加密。存储流量的客户端加密功能即将推出。 IPSec 传输模式用于文件和块流量与需要访问存储空间的主机之间。身份验证通过预共享密钥完成，该密钥在运行中生成并安全地存储在 GDC 中。建立 IPSec SA 后，系统会使用 IPSec 隧道交换信息。数据包使用 IPSec SA 中指定的符合 FIPS 标准的加密算法进行加密和解密。
服务到服务的身份验证、完整性和加密
在 GDC 基础设施的应用层（第 7 层），我们使用 mTLS 或 TLS 对从 Cloud Service Mesh Ingress 网关到服务以及从一个 GDC 服务到另一个 GDC 服务的 RPC 调用进行身份验证、完整性检查和加密。 在 GDC 中运行的每个服务都以服务账号身份运行，并具有关联的加密凭据。通过 Cloud Service Mesh 使用 mTLS 进行通信时，GDC 服务会使用客户端证书向其他服务进行身份验证。Cloud Service Mesh 会使用内部证书授权机构验证这些证书。通过 TLS 进行通信时（例如，与 GDC Kubernetes API 服务器通信），GDC 服务会使用 Kubernetes 服务账号令牌向服务进行身份验证。Kubernetes 服务账号令牌使用 Kubernetes API 服务器令牌颁发者的公钥进行验证。