software

不信任，验证：在 Google Cloud 上构建端到端机密应用

发布: (2026年1月6日 GMT+8 10:56)
16 min read
原文: Google Developers Blog

Source: Google Developers Blog

2025年12月9日

在当今数据驱动的世界，许多有价值的洞察依赖于 敏感数据类别——无论是为个性化服务处理个人身份信息（PII），与合作伙伴共享机密数据集，还是分析敏感的金融信息。保护数据 **不仅在静止或传输时，而且在 处理期间 ** 已成为关键的业务需求。

虽然磁盘上的 数据‑静止 加密和网络上的 数据‑传输 加密是人们熟悉的问题，但 “数据‑使用中” 的挑战常常被忽视。这正是 机密计算 发挥作用的地方，它为数据在处理过程中的安全提供硬件级别的保护。

本文演示了如何利用 Google Cloud 的 Confidential Space ，让组织构建端到端的机密服务。我们将展示终端用户如何获得加密保证，确保他们的敏感数据仅由在安全、硬件隔离环境中运行的已验证代码进行处理——即使该服务是通过可扩展的负载均衡架构部署的。

大规模信任与保密的挑战

在现代可扩展的云环境中运行机密服务会带来两个关键挑战：

  1. 信任与透明度
    客户需要一种方式来验证处理其数据的代码的隐私属性。将整个应用程序开源可以解决此问题，但对于必须保护宝贵知识产权、专有算法或敏感 AI 模型的企业来说，这是不可行的。
    运营商如何在不泄露使其服务有价值的源代码的前提下，证明其服务是机密的？

  2. 可扩展性
    现代云应用程序旨在实现弹性和规模，通常在负载均衡器后面运行多个服务实例。

    • 在负载均衡器处终止 TLS 简化了密钥管理，但会在负载均衡器中暴露明文数据以进行检查和路由，破坏端到端的机密性并扩大受信计算基（TCB）。
    • 在每个后端服务器上终止 TLS 则需要在所有实例之间安全分发 TLS 私钥，使这些密钥成为工作负载攻击面的组成部分。

Source: …

用 Google Cloud Confidential Space 与 Oak Functions 锚定信任

该解决方案以坚实、硬件强制的基础开始：Google Cloud Confidential Space。它是基于最先进的机密计算硬件构建的强化可信执行环境（TEE）。它创建了一个硬件隔离的内存 enclave，代码和数据免受以下对象的影响：

  • 主机操作系统，
  • 其他租户，
  • 云服务提供商，
  • 甚至是云项目所有者。

它提供的关键原语是 attestation（证明）：平台签名的报告，证明环境的完整性以及在其中运行的任何 Open Container Initiative（OCI）容器的身份。

当无法实现完整工作负载透明度（例如专有代码）时，我们将在容器化、可验证的私有沙箱中运行应用逻辑：Oak Functions。该沙箱阻止业务逻辑代码：

  • 在 TEE 之外记录或存储数据，
  • 创建任意网络连接，
  • 除通过明确允许、受控的接口外，与不受信任的主机交互。

结果： 用户的信任锚定在定义明确、开源的沙箱（任何人都可以可复现地构建）以及沙箱开发者的背书上，而不是 其执行的具体逻辑。这简化了信任链：用户只需验证体积小、透明的 Oak Functions 容器镜像，而无需审查复杂的自定义应用程序。

建立对经认证的端到端加密 (Oak Session) 的信任

为了在负载均衡路径上实现可信连接，我们在标准网络层 TLS 之上叠加 应用层加密。为此我们使用 Oak Session，这是一款实现端到端加密会话协议的开源库。它直接在 enclave 内部的应用逻辑之间建立安全通道，即使通过负载均衡器等不可信中间件路由，也能保持安全。

Oak Session 的关键特性

  • 嵌套的端到端加密通道 – 在外层 TLS 连接内部打开一个加密通道，直接与机密工作负载通信。即使外层 TLS 连接在负载均衡器处终止，内部数据仍然受到保护。
  • Noise 协议框架 – 虽然可以使用 TLS 来实现嵌套通道，Oak Functions 选择了 Noise 框架，它提供了更大的灵活性和强大的密码学保证。

工作原理（高层流程）

  1. 认证 – Confidential Space 实例生成一份认证文档，证明其正在运行预期的 Oak Functions 容器。
  2. 验证 – 客户端验证该认证文档（签名、度量等），以确保正在与真实、未被篡改的 enclave 通信。
  3. 会话建立 – 使用 Oak Session（Noise），客户端和 enclave 进行相互密钥交换，生成仅 enclave 与客户端双方知晓的对称加密密钥。
  4. 数据传输 – 所有负载均使用该会话密钥加密，即使外层 TLS 连接在负载均衡器处终止，也能提供机密性和完整性。

综合使用

通过结合：

  • Google Cloud Confidential Space 用于硬件根植的隔离和证明，
  • Oak Functions 提供最小化、开源、可复现的沙箱，和
  • Oak Session 实现嵌套的端到端加密，

我们实现了一个 可扩展的机密服务，其能够：

  • 在整个生命周期内（静止、传输和使用时）保持数据隐私。
  • 让客户在不暴露专有代码的前提下验证机密性保证。
  • 支持负载均衡部署，且不会将可信计算基（TCB）扩展到负载均衡器。

参考资料

基于 Diffie‑Hellman 的安全通道协议

Noise 的一个关键优势是相较于完整的 TLS 堆栈更为简洁。我们对 Noise 握手及其产生的加密通道的实现大约只有 2.5 K 行代码，而 BoringSSL 则有 1.2 M 行代码。如此小的代码体积提供了更易审计的密码原语集合，使得正确实现和验证更加容易。

证明

受信执行平台环境提供了一个签名报告，以确认其完整性以及在其硬件隔离内存区（enclave）中运行的工作负载的身份。Oak Session 是一个可组合的框架，允许断言（assertion）进行交换和验证。在 Confidential Space 的场景中，断言包括：

  • 绑定验证密钥（公钥）。
  • 会话令牌的签名，该令牌来源于嵌套加密握手。此签名可使用绑定验证密钥进行验证（见下文 Session Binding）。
  • 由 Google Cloud Attestation 服务签署的 Attestation JSON Web Token (JWT)。该 JWT 包含许多声明，其中 eat_nonce 字段中存放了验证密钥的指纹。

单独的 JWT 是建立平台身份、平台参数（系统镜像、环境配置等）以及工作负载本身身份的第一步。然而，仅凭 JWT 不足以保证安全——恶意运营者可能会窃取并在其他工作负载中重放它。绑定密钥和会话令牌能够防止这种情况，从而完整地构成安全保障。

Source: …

会话绑定

此关键步骤将安全通道连接到认证 JWT。

  1. 在握手期间，双方派生出一个 唯一的会话令牌，该令牌绑定到会话的密码学身份。
  2. enclave 使用私有 绑定密钥 对该令牌进行签名，该密钥在密码学上与其认证声明关联（通过包含验证密钥的指纹实现）。
  3. 通过验证此签名，客户端确认与之完成握手的实体正是硬件所认证的 完全相同的实体，从而防止 MITM 与重放攻击——即旧的或无效的认证被用于启动新的恶意会话。

在我们的示例中，我们使用 Noise 握手记录 的哈希。
对于 TLS 通道，会话令牌可以基于 导出密钥材料 (EKM) 创建。

虽然会话令牌可以直接放入 JWT 的 eat_nonce 中，但这将需要每个连接都进行一次认证，增加延迟并耗尽 每项目 5 QPS 的默认配额（配额详情）。引入绑定密钥可以将 JWT 请求与关键的服务流程解耦。

建立信任

以下是一个 JWT 令牌的摘录，展示了平台设置和工作负载身份。请注意其中包含了 OCI 注册表和镜像摘要。

{
  "aud": "oak://session/attestation",
  "iss": "https://confidentialcomputing.googleapis.com",
  "sub": "https://www.googleapis.com/compute/v1/projects/oak-functions/zones/us-west1-b/instances/oak_functions",
  "eat_nonce": "d3ee341dbbf8986b11e14db61bece35c02a18943ac6bbcd3868cb00676210fa4",
  "submods": {
    "container": {
      "image_reference": "europe-west1-docker.pkg.dev/oak-examples/c0n741n3r-1m4635/echo_enclave_app:latest",
      "image_digest": "sha256:2f81b55712a288bc4cefe6d56d00501ca1c15b98d49cb0c404370cae5f61021a"
    }
  }
}

验证步骤

  1. 验证 JWT – 检查其签名和过期日期。
  2. 将绑定验证密钥 与 eat_nonce 字段中的指纹匹配。
  3. 使用绑定验证密钥 验证会话令牌签名。
  4. 确认平台设置 以及 JWT 中的参数与预期值相符。
  5. 验证容器字段 是否符合预期值。

完成这些步骤后，客户端即可在平台、其配置以及工作负载方面建立信任。

管理预期的容器身份

Oak Functions 可以可重复构建，因此客户端可以在本地构建 OCI 镜像并将其摘要与 JWT 中的摘要进行比较。然而，由于 Oak Functions 会定期发布，不断重新构建并验证每个镜像变得不切实际。

经典的软件工程解决方案是 间接性：

  • 信任任何来源于 受信任的 OCI 注册表和仓库 的 OCI 镜像，且只有 Oak 团队可以向其发布。
  • 这种做法构成对镜像来源的 背书。

更高级的背书机制（例如签名的 provenance 声明）可以在此基础模型之上叠加，但核心思想仍然是：客户端信任注册表‑仓库对，而不是特定的镜像摘要，从而在保持安全性的同时简化验证。

Cosign 签名和 provenance 声明 – 一个广为人知的例子是 Cosign，它 在 Confidential Space 中原生支持。

结论：通往可信机密计算及其更远目标的路径

Google Cloud 的机密计算架构以及 Project Oak 开发的技术，为组织提供了两全其美的方案：标准的、可扩展的基础设施以及可验证的端到端数据机密性。下图展示了主要组件以及它们之间交互的顺序，直至通道打开为止。

Oak session diagram

Google Cloud 与 Project Oak 的开源安全工具合作，提供完整的解决方案，在标准、可扩展的云架构中保护您最敏感的使用中数据。

接下来：为安全生成式 AI 与代理体验提供动力

上述原则使您能够通过安全的数据协作解锁新的业务机会，并向客户和监管机构提供加密的、可审计的安全与隐私姿态证明——即使由于知识产权考虑（例如 AI、医疗保健、基因组研究），提供方的工作负载必须保持专有。

随着企业日益采用生成式 AI，保护专有模型、敏感提示以及 AI 代理处理的机密数据变得至关重要。借助 Confidential Space 中的 GPU，Google Cloud 将硬件防护扩展到高负载的 AI 工作负载。

想象一下，一个 AI 代理在处理您的机密企业数据并提供洞察。
通过将 Confidential Space 与运行开源模型（如 Gemma）的 GPU、Oak Functions 以及 Oak Session 相结合，您可以保护提示和响应，构建既强大 又 可验证安全和私密的代理体验。该框架提供了在高风险企业环境中部署生成式 AI 所需的信任。

行动号召

Back to Blog

相关文章

阅读更多 »