本文档详细介绍了 Google Distributed Cloud (GDC) 气隙加密传输。
面向首席信息官级别领导者的摘要
- GDC 采用多种安全措施来确保传输过程中数据的真实性、完整性和保密性。
- 根据正在建立的连接，GDC 会对 GDC 组件传输中的数据应用默认保护。例如，我们使用 TLS 保护用户与 GDC Cloud Service Mesh 入站流量网关之间的通信。
简介
安全性通常是用户选择云服务提供商时的一个决定性因素。在 Google 看来，安全性是重中之重。我们孜孜不倦地保护您的数据：无论这些数据是通过您的网络传输、在 Google 的基础架构内转移，还是存储在我们的服务器上。
Google 安全策略的核心是身份验证、完整性和加密，对于静态数据和传输中的数据均适用。本文将介绍我们在 Google Distributed Cloud air-gapped (GDC) 中采用的传输加密方法。
对于静态数据，请参阅静态加密。如需大致了解各种 Google 安全机制，请参阅 Google 基础架构安全设计概述。
受众群体：本文档面向正在使用或考虑使用 GDC 的首席信息安全官 (CISO) 和安全运维团队。
前提条件：除了本简介之外，我们还假定读者对加密和密码学原语具有基本的了解。
身份验证、完整性和加密
GDC 采用多种安全措施来确保传输过程中数据的真实性、完整性和保密性。
- 身份验证：我们在网络层对数据目标位置进行身份验证。来源由 GDC 管理的 AIS 进行身份验证。
- 完整性：我们会确保您发送的数据原样到达目的地，并受到保护，免遭未经授权的更改。
- 加密：我们会确保您的数据在传输过程中无法被读取，以保持其机密性。加密是使清晰易辨的数据（明文）变得无法辨认（密文）的过程，目的是确保只有经数据所有者授权的各方才能访问明文。加密过程中使用的算法是公开的，但解密密文所需的密钥是私密的。传输加密通常使用非对称密钥交换（例如基于椭圆曲线的 Diffie-Hellman）来建立用于数据加密的共享对称密钥。如需详细了解加密，请参阅现代密码学入门。
加密可用于保护多种状态的数据：
- 静态加密通过加密存储的数据，防止您的数据受到系统入侵或数据渗漏的危害。高级加密标准 (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 入口网关会代理传入的 HTTP(S) 流量，并将流量路由到 GDC 管理的服务本身并进行负载均衡。另一个防火墙层通过入侵检测和防御功能提供 DDoS 攻击对策。此类从 Cloud Service Mesh Ingress 网关到 GDC 代管式服务前端的连接将经过身份验证和加密。图 1 显示了这种交互（标记为连接 A）。
大多数 GDC API 和托管服务都托管在 Cloud Service Mesh 入站流量网关上。不过，有些服务直接托管在 GDC 管理的第 4 层负载均衡器上。例如，DBS 数据库托管在 GDC 外部负载均衡器上。这些服务配置为使用 TLS 在应用层对连接进行身份验证和加密。图 1 显示了这种交互（标记为连接 B）。
最终用户（客户网络）到 GDC 上托管的客户应用
您可以通过多种方式将客户网络中的流量路由到 GDC 上托管的客户应用。流量的路由方式取决于您的配置。
通过客户 API 网关公开客户应用
GDC 支持通过客户 API 网关公开客户应用。借助客户 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 入站流量网关的加密
如今，许多系统使用 HTTPS 在互联网上进行通信。HTTPS 使用 TLS 连接提供安全性，这可以确保请求和响应的真实性、完整性和保密性。如需接受 HTTPS 请求，接收者需要具有公钥/私钥对和 X.509 证书，以便从证书授权机构 (CA) 进行服务器身份验证。密钥对和证书通过证明接收者拥有用户请求欲前往的域名，在应用层（第 7 层）对用户请求进行身份验证。以下各小节介绍用户到 Cloud Service Mesh Ingress Gateway 加密的组成部分，即：TLS、BoringSSL 和 GDC 可配置的证书授权机构。
传输层安全协议 (TLS)
当您向 GDC 服务发送请求时，我们会保护传输中的数据；使用 HTTPS 和来自可信证书授权机构的证书提供身份验证、确保完整性并进行加密。用户发送到 GDC 代管式服务的 Cloud Service Mesh 入口网关的任何数据在传输过程中都会使用传输层安全协议 (TLS) 进行加密。Cloud Service Mesh 入站网关会根据客户端能够支持的内容与客户端协商特定的加密协议。GDC Cloud Service Mesh 入站流量网关仅强制执行 FIPS 批准的算法，以提供更强的安全性。
BoringSSL
BoringSSL 是 TLS 协议的开源实现，由 Google 维护并从 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 Gateway 到 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 入口网关到服务的 RPC 调用以及从一个 GDC 服务到另一个 GDC 服务的 RPC 调用提供身份验证、完整性和加密。 在 GDC 中运行的每项服务都以具有相关加密凭据的服务账号身份运行。通过 Cloud Service Mesh 使用 mTLS 进行通信时，GDC 服务会使用客户端证书向其他服务进行身份验证。Cloud Service Mesh 使用内部证书授权机构验证这些证书。通过 TLS 进行通信时（例如与 GDC Kubernetes API 服务器通信时），GDC 服务会使用 Kubernetes 服务账号令牌向服务进行身份验证。Kubernetes 服务账号令牌使用 Kubernetes API 服务器令牌签发者的公钥进行验证。