构建机密AI工厂的零信任架构

原创

用户11764306

发布于 2026-04-17 18:22:24

1460

为机密AI工厂构建零信任架构

2026年3月23日

作者：Hema Bontha, Manuel Huber, Matheen Raza

人工智能正从实验阶段走向生产阶段。然而，大多数企业所需的数据存在于公共云之外，这包括患者记录、市场研究等敏感信息，以及包含企业知识的遗留系统。使用私有数据与AI模型存在风险，且隐私和信任问题常常阻碍AI的采用。

构建下一代AI工厂——专注于大规模生产智能的高性能基础设施——的企业必须建立在零信任基础之上。这种安全架构通过使用硬件强制的可信执行环境（TEE）和加密证明，消除了对底层主机基础设施的隐式信任。本文描述了将零信任基础集成到AI工厂所需的全栈架构。

本地部署要求通常限制企业只能构建自己的模型或使用开源模型来处理代理式AI工作负载。为了实现AI的承诺，组织必须在其运营的基础设施上部署多样化的模型（包括专有模型），同时不向管理员、hypervisor或主机操作系统暴露敏感数据或模型权重。另一方面，模型提供商需要加密保证，确保其知识产权即使在自身受控环境之外部署时也无法被提取。

机密计算通过解决信任困境提供了这种保证——传统模式要求每个角色都给予隐式信任，而无需实际验证信任。

AI工厂的信任困境

在共享基础设施上部署专有前沿模型会在AI工厂的关键利益相关者之间造成三方信任困境：

模型所有者 vs. 基础设施提供商：模型所有者需要保护其专有知识产权（模型权重、算法逻辑），无法信任主机操作系统、hypervisor或根管理员不会检查、窃取或提取其模型。
基础设施提供商 vs. 模型所有者/租户：基础设施提供商（运行硬件和Kubernetes集群的一方）无法信任模型所有者或租户的工作负载是良性的。它可能包含恶意代码、尝试权限提升或破坏主机安全边界。
租户（数据所有者） vs. 模型所有者和基础设施提供商：数据所有者必须确保其敏感的、受监管的数据保持机密。他们无法信任基础设施提供商不会在执行过程中查看数据，也无法信任模型提供商不会在推理过程中滥用或泄露数据。

这种循环的信任缺失源于一个根本问题：在传统计算环境中，数据未加密，导致敏感数据和专有模型以明文形式暴露给内存和系统管理员。机密计算通过确保数据和模型在整个执行生命周期中都受到加密保护来解决此问题。

使用机密容器实现安全AI工厂

机密计算提供了硬件基础。机密容器（CoCo）将其操作化以适用于Kubernetes。

CoCo使Kubernetes Pod能够运行在硬件支持的可信执行环境（TEE）中，而无需重写应用程序。Pod不再共享主机内核，而是透明地封装在轻量级、硬件隔离的虚拟机（VM）中——使用Kata Containers——在保留云原生工作流的同时强制执行强隔离边界。

对于模型提供商而言，最大的风险是基础设施所有者窃取专有模型权重。CoCo通过将主机操作系统和hypervisor从信任等式中移除来解决此问题。当模型部署时，它保持加密状态，直到硬件通过称为远程证明的过程在数学上证明安全区是安全的。只有这样，密钥代理服务（KBS）才会将解密密钥释放到受保护内存中，确保模型永远不会以明文形式暴露给主机。

零信任AI工厂的开放参考架构

某机构为CoCo软件堆栈提供了参考架构。这是一个标准化蓝图——与Kata Containers等开源项目组件及机密容器社区合作开发——用于在裸金属基础设施上构建零信任AI工厂。它定义了如何结合硬件和软件，以安全部署前沿模型，同时不向主机环境暴露其数据或权重。

该架构的核心支柱包括：

硬件信任根：使用CPU TEE搭配某机构机密GPU（如某机构Hopper或某机构Blackwell），用于硬件加速、内存加密的AI工作负载。
Kata Containers运行时：将标准Kubernetes Pod封装在轻量级、硬件隔离的Utility虚拟机（UVM）中，而不是共享主机内核。
加固的微型Guest环境：使用无发行版的最小化Guest操作系统，包含精简的根文件系统和某机构运行时容器（NVRC）以实现安全的init系统，从而减少VM内部的攻击面。
证明服务：在向Guest释放敏感模型解密密钥或秘密之前，通过加密证据验证硬件。这需要一个远程证明框架，其中应包含密钥代理服务（KBS）。
机密工作负载生命周期：促进加密和签名的镜像（容器、模型、构件）直接安全拉取到加密的TEE内存中，防止静态或传输中的暴露。并启用细粒度策略来保护Guest与不可信基础设施层之间的接口。
原生Kubernetes和GPU操作符集成：使用标准Kubernetes原语和某机构GPU操作符管理此堆栈，实现“直接迁移”式部署，无需重写部署清单或AI应用程序。

威胁模型与信任边界

CoCo在严格的威胁模型下运行。基础设施层——包括主机操作系统、hypervisor和云提供商——被视为不可信。

CoCo不再依赖基础设施管理员来强制执行安全控制，而是将信任边界转移到硬件支持的TEE。AI工作负载在加密的虚拟化环境中运行，主机无法检查内存内容，并且只有在执行环境证明其完整性后才释放秘密。理解哪些受到保护、哪些不受保护至关重要。

CoCo保护的内容

CoCo为执行期间的机密性和完整性提供了强有力的保证，包括：

数据和模型保护：内存加密防止主机在工作负载运行时访问敏感数据、模型权重或推理负载。
执行完整性：远程证明在释放秘密或模型解密密钥之前，验证工作负载是否在具有预期软件度量的可信环境中运行。
安全的镜像和存储处理：容器镜像在加密的Guest环境内部被拉取和解包，确保主机基础设施无法检查或篡改应用程序代码或模型构件。
防范主机级访问：特权主机的操作（如内存检查、磁盘抓取或管理调试工具）无法暴露工作负载内容。

CoCo不保护的内容

某些风险仍处于架构范围之外，例如：

应用程序漏洞：机密执行确保经过验证的软件在安全区内运行，但无法防止应用程序内部的漏洞。
可用性攻击：平台保证机密性和完整性，但基础设施操作员可以通过拒绝调度或终止工作负载来中断服务。
非硬件安全区：该模型依赖于硬件支持的TEE，不适用于基于软件的隔离机制。
网络和存储安全：应用程序之间的网络连接不在CoCo信任边界覆盖范围内。应用程序必须建立自己的安全通道以防止传输中数据暴露，并使用适当的机密存储机制。

使用复合证明的安全模型部署

此端到端工作流基于远程证明程序（RATS）架构，支持在TEE内安全释放密钥以部署加密模型：

启动：当工作负载需要秘密（如模型解密密钥）时，Kata VM内部的证明代理（AA）与外部密钥代理服务（KBS）启动认证握手。
证据收集：AA从TEE收集加密硬件证据（例如CPU quotes或某机构GPU报告），并将其发送到KBS。
委托验证：KBS将此证据转发给证明服务（AS）。
验证：AS根据安全策略和参考值提供商服务（RVPS）提供的“已知良好”度量评估证据。对于专用硬件，AS充当代理并将验证委托给外部供应商服务，如某机构远程证明服务（NRAS）或某机构Trust Authority。
令牌颁发：如果环境在数学上证明其安全且未被篡改，KBS将证明结果令牌和会话ID返回给Guest的AA。
安全密钥释放：AA使用此令牌请求特定的秘密。KBS从其后端（如密钥管理服务）检索秘密，并将其安全地传递给Guest VM内部的机密数据枢纽（CDH）。
执行：CDH将明文秘密直接暴露给AI容器，允许模型仅在受保护内存内部解密。