阿里云 Confidential Al 最佳实践
内容分析:
1. 需求背景介绍
2. 大规模场景下面临的系统及安全风险
3. 计算栈的共享职责模型与用户信任边界的冲突
4. 传统计算、存储和网络安全技术中存在用户信任成本较高的问题
5. Confidential AI 方案实施模式
6. 基于CAI技术的阿里云Confidential Cloud Computing架构
7. Confidential AI on EGS DEMO
8. 阿里云全面应用Confidential AI
9. 完备的机密计算远程证明过程
10.发布《机密计算保障人工智能系统安全研究报告》
11.Confidential AI总结
大家好,我是阿里云飞天实验室操作系统同时兼顾龙溪社区云原生机密计算 SIG Owner 的乾越。关于我的真名跟花名的问题,因为我是做安全的,所以对外宣传自己用花名是一个很好的标识化的方式。今天主要给大家介绍一下阿里云以 Confidential AI 技术框架为导向,分享一下在阿里云上的商业化实践以及在开源社区的工作。副标题比较长,但是重要的点就是识别到一种新的计算模式叫 Confidential Cloud Computing , 在这种模式下面能够为端云一体 AI 推理安全与隐私保护场景需求提供非常好的解决方案,甚至可以形成一种新的商业化模式,促进云计算,尤其公有云和云新的变革。今天给大家分享一下最新的研究成果。
01.需求背景介绍
首先是需求背景。在 AI 浪潮下很多企业希望把最新的 AI 能力引入工作流中提升企业实现商业化的技术竞争力。消费电子类的端侧很喜欢做前沿性的东西。如 AI 手机、AIPC 车载引入云端的大模型推理能力。Apple 公开的 Apple Intelligence 框架可以利用多终端接受用户的推理请求,他的端侧调度框架可以根据推理请求在本地利用端侧小模型做推理响应用户请求或调用原云端大模型做更复杂的推理请求。端云一体AI推理注定要求端侧水位的安全。云端能否做到跟端侧一样的安全跟隐私保护水位?端侧的用户希望云端把安全跟隐私做的比以前还要高,不只依赖于传统的基础设施安全能力,而是面向用户安全隐私的能力。根据实际用户的接触大概目前有两类对端云一体方案比较感兴趣。
一类是以模型使用者的角色来描述这类用户。他典型的诉求是用户或者是端侧的推理提示词发到云上去做 AI 推理能不能保护用户的隐私数据,也就是推理提示词的安全跟敏感度。
另外一类是使用训练模型,尤其是训练基础模型或做翻镇模型的提供者,模型自身是有知识产权保护的。如果上云去给终端用户做推理,模型上了一个不是受控的计算技术设施,模型作为敏感数据怎么保护是模型提供者的诉求。
针对这两类诉求在实现手段上就是分为两个决策。自建 AI Infra 算力更强调整个数据流里面有一大部分是由我控制,这个是传统的专有云方案。另一类是能不能用公有云,即租赁 AI Infra 算力的一种方案。这种方案必然要给这类用户打造一个通用性比较强的通用架构,让算力和成本能够压到最低,同时还能提供安全跟隐私保护。这样的要求明确的注定了对公有云用户尤其是使用AI场景用户,能够有一个更强力的安全基础设施,区别于传统的安全能力。
02.大规模场景下面临的系统及安全风险
在技术角度如果有 AI 计算平台基础设施模型有4类典型角色。代表平台拥有者有模型提供者和模型使用者两个角色,如果方案更加灵活化,还有工作负载提供者典型使用云做 AI 推理流程。即模型提供者先注册模型数据。在这个过程中会担心模型是否会以明文形式被分享给计算基础设施造成知识产权的泄露。
第二点是工作负载提供者可能部署推理服务,如果部署以容器镜像形式推理服务是否有可能会窃取转发模型数据和推理提示词恶意行为的潜在风险。推理服务启动后就要对外提供服务。在初始化过程中要先从云存储把之前模型提供者上传的模型拉到计算环境中准备执行。最后是模型提供使用者从浏览器访问特地服务端节点。
在使用 AI 服务过程中必然要通过发送提示词来实现推理过程。提示词本身以及 AGC 返回的结果本身的知识产权保护还有隐私保护应该怎么做。AI 流程里面几乎方方面面都提到了安全和隐私保护问题,这些问题传统的安全技术都提供了安全能力,但是安全跟信任是不一样的概念。隐私保护和可信问题对于传统的云计算基础设施尤其是已经提供的安全能力是不够的。
03.计算栈的共享职责模型与用户信任边界的冲突
左边是简化过的云计算基础设施计算站。左边标注了黄色虚线部分是用户的执行环境即信任边界。信任边界是用户提出来的。信任边界面有很多组件,其实是云提供的。云提供这些能力是因为右边有一个云的共享职责边界,即 IaaS、PaaS、FaaS 等其他形态。这些形态其实都是固有的、定型的边界。这些边界直接决定了各个产品的交付界面是什么样的。如在IaaS共享边界里面,像虚拟机类 Guest 固件、GuestOS 等底层组件的运维跟部署工作都是云厂商完成,不是让用户完成。
在今天用户强调执行环境安全可信和强力的隐私跟安全保护由 CSP 部署的 Guest 固件,取决于计算环境本身要处理的数据敏感度有多高。结合提示词保护跟模型保护两个角色的敏感数据都要进到执行环境里。就是量变引起质变的过程。个人网站数据或中小企业数据可能不是那么敏感,那么用传统的安全技术虚拟化隔离。由于数据敏感度太高所以用户对执行环境,尤其是执行环境内的很多组件不完全相信云厂商提供。所以形成了一个很明显的悖论,即使用云计算来降低成本调用大模型,但是又担心敏感数据被云厂商基础设施或者执行环境处理,有隐私和可信任的问题。
04.传统计算、存储和网络安全技术中存在用户信任成本较高的问题
传统计算存储网络都有对应的安全技术。举例说明为什么安全跟信任问题在今天是需要解耦的。安全是不能量化的安全,安全是相对的只有相对安全或相对不安全,安全没有做到多少分或做到什么级别的说法,这并不准确。信任在更早的时候就被定义为有信任级别,所以信任是可以量化的。
在存储计算三个层面都提到了传统的安全技术做到了安全,但是没有解决信任问题。如 TLS 协议足够安全。云上几乎所有的 API 调用都是走 HTPS 基于 TRS ,但 TRS 本质是服务端签发 CA 证书。如果服务端的计算执行环境已经被攻破了,任何一个用户连到服务是无法察觉到聚集性环境的可信状态已经被破坏。继续以被攻破的系统,或者说能够被平台基础设施管理恶意关联渗透过的系统进行通信,在里面布模型、发提示词安全跟隐私保护是达不到的。如存储安全和落盘加密能力。传统云安全拥有访问权,Guest 是可以轻易当不 GA 内存的,隐私数据还有敏感数据在内存里是能够明文被盗出来怎么办?
05. Confidential AI 方案实施模式
面对以上问题把云端AI推理模式做成一种通用的模型来描述。使用这个模型解决目前观察到的两类用户需求。
第一是云平台提供的推理环境。在推理环境里面运用 TEE 这种安全可信的硬件技术,包括 CPU TEE 和 GPU TEE 。里面有一个机密虚拟机计算站和普通虚拟机里的组件功能是类似的。
左边的模型使用者如果在端侧有一个执行环境本身运行了一个小的操作系统,里面内置推理框架。
右边是模型提供者有一个网络隔离的 IDC 或其他的计算基础设施,完成了模型的训练。他们的诉求都是把各自的数据发到推理环境集中处理跟计算,精密计算能够保证中间的执行环境,CPU TEE 和 GPU TEE 即蓝色部分是内存加密安全隔离,即使有特权也无法渗透到基础设施,从物理机上直接访问 CPU TEE 和 GPU TEE 内存的内容,两边中间的传输的过程也利用了 CPU TEE 和 GPU TEE 的远程证明能力建立端到端的安全的传输。
实际用户诉求是准备怎么使用这个架构。第一个模式是推理提示词拟态出域模式。在这个模式下,端侧用户的主要需求是借助云端的算力做推理,既然要做推理,提示词要注入设备出域,云端利用机密提供密态计算的能力。模型提供用户可能用通意,也有可能使用第三方甚至自己的模型。这种情况下主要是保护端侧的推理示词的敏感信息保护。
第二种模式是模型密态出域。模型提供者要把模型放到中间的执行环境推理。需求本质仍旧来自推理使用者即客户端的需求。这个场景里面模型使用者的想法还是用大模型做推理。因为合规原因,即使能提供密态计算能力,还是不希望提示词出域,希望提示词运行部署出现在自己控制的IDC网络里。要求模型提供者不能调你公有云的大模型服务。把模型输出到私有云计算环境里面。模型提供要求把模型密探出去,运行在机密的环境里面做推理,服务推理请求。模型提供者要保护知识产权以密态形式输出到特定环境。
06.基于CAI技术的阿里云Confidential Cloud Computing架构
这张图是已经完全商用化的 ConfidentialAI 的技术架构。这张图已经做了非常大的简化。本人已经做了 5 年,从机密信息、机密容器技术、SGST 、CSV , 远程证明也都做过。我最大感受就是,要实现这么一套框架确实不太容易。尤其 Confidential AI 的组建其实做了四五年。因为这些组件是从两三年前,甚至更早做的积累,尤其在 Confidential Coco 开源社区。在这个开源社区贡献了大量和机密容器相关的组件。但是最近一年发现AI场景的推理的安全与隐私保护的需求变得旺盛,能不能复用在机密容器社区做的一些组件,以一种很有意思的方式结合起来保护的端云一体的推理。去年年底预测到可能会有这样的场景,所以提前脱离了 Coco 社区,把一些核心组件拿出来构成了 Confidentual AI 架构。
现在全球大概有4家公司在做类似的技术,一个是苹果背后的 Apple Intelligence , 这是大家在前端能看得见摸得着的。它背后用的苹果的 PCC 云架构,它的端云一体方案基本上跟这个架构是类似的。还有一个是微软的 Ager , 他们也是最近出了一个 Preview 版本的 AI 推理 Mass 服务,差不多也是类似的架构。国内是我们和另外一家,方案不太确定,但是可能是类似的。
07.Confidential AI on EGS DEMO
简单给大家介绍一下这个 DEMO 。用户登录到阿里云上一个异购TEE节点先检查环境是不是开启了相关的机密计算技术,如 CPU TEE 是 TDX ,GPU 开启了 CC 机密计算模式。在这个环境里面因为是ACS 所以要自己部署外组件,提交关键性的配置参数在机密节点里面,机密虚拟机运行 Confidential AI 的 Side Car 服务,推理服务也部署起来。
如果用户因为负载均衡在多个节点拉同一个模型做推理,那么在第二个节点拉同样模型时会加速。没有做其他任何额外优化,只做了缓存有大概 23% 的性能提升。因为篇幅有限且远程证明足够复杂,所以就不细解了。可以认为远程证明就是从技术手段证明计算环境是安全可信。
最后一步,用户要在客户端侧部署一个 TNG 的推理网关。最终完成部署以后就可以访问节点了。中间绿色空件是在 TNG Client 注入的并不是浏览器插件,也不是改了前端代码。前端代码是个通用框架。通过 TNG 注入前端代码展示现在推理过程是远端是一个机密计算保护的环境,这种方案足够灵活,跟浏览器具体的框架没有关系,可以做到前端跟后端代码零修改。如果推理用户要访问的远程证明的推理服务执行环境本身可信度遭到破坏,实际上可以在发推理请求之前,访问这个节点的时候就能发现问题。防止把推理提示词意外泄露给一个不可信的环境。
08.阿里云全面应用Confidential AI
我们在云栖大会上官宣了 Confidential AI 。在 12 月份陆续有IaaS 产品和 PaaS 型产品支持 Confidential AI 。EGS 那种 IaaS 型是典型的买了实例,要SSH黑屏运维操作的那种。EGS 这种 IaaS 型产品虽然步骤稍微复杂一点,但是它给用户一个充分的自由空间去控制所有的 Confidential AI 底层细节。
另外一种是 Service 型,叫作 Service 推理服务产品,属于派产品线,叫 EAS 。这个形态今天没有录 DEMO ,但是它会比 EGS 会简单,基本买了实例以后,EGS DEMO 中所有用户需要配的那些东西,用户都不用配了,直接就是开出实例。用户直接浏览器输入推理服务端点就可以做推理。
09.完备的机密计算远程证明过程
因为这次演讲的介绍跟供应链有关,所以另外一个演讲里面提到了Confidential AI 机密计算跟供应链安全方法论的关系。所以稍微说明一下,这个技术细节其实经过了大幅度简化,但是我觉得有必要说清楚一点,就是今天精密计算如何通过远程证明技术向用户真的证明执行环境是安全可信的。刚才提到有很多组件因为传统的云服务部署模式导致那些组件不能由用户控制跟部署必须由云部署。
云厂商既然既然不是用户特别信任的对象,那他部署组件用户又怎么相信?如果用户自己部署,增加运维成本。如果用户用这厂商的东西,用户怎么相信?这个问题本质上在过去 20 年可信计算 TPM 时代本来应该解决的,但是由于各种各样原因没有解决。机密计算复用了类似可逆计算远程证明那套思路解决问题。思路就是软件供应链方法论。供应链本质上是由 Builder 的 CCD Pipeline 生成真正的制品,如Banner RPM 镜像等容器镜像。
其实这个 Pipeline 完全也可以有足够的元数据生成,尤其是缩塞架构里面的 Provence 出处信息。 右边是一坨乱七八糟的东西叫制品出入信息,这个信息定义了其中一个比如在 CVM 中运行的软件的 GAS 仓库源码的分支、关键的完整性、度量值、构建环境、动作阐述以及构建步骤。有这些出处信息以后,把信息打到给用户提供的可验证执行环境或可重复构建环境。这个环境里的逻辑,能够分析 Provence 信息,提取出关键信息在环境里面执行重复构建,用源码构建。这个过程需要确保能够构建出的Bay能够跟实际,比如阿里云实际提供的 GAS 镜像部署到用户心中镜像等构建过程的环境是一致的。
虽然两个环境不是同一个环境,由于环境的参数都是一样的,且这个构建的原信息是一致的。
虽然物理上是两个不同环境,但是构建出的Banary是一致的。因为Banary一致,所以通过远程证明过程,远程证明请求里发送过来的是实时度量的,Banary的度量值本质上是一堆Hash。
这些Hash远程证明核心要做的就是把这些Hash提取出来,跟一个可信参考值做比较,来证明这些关键组件是不是可信的。如果没有这套环境,让用户写个验证策略,用户怎么知道运行远端运行环境Cernel的Hash是这个值,隐匿RD是那个值,没办法定义。
虽然提供这个能力,但没法写策略,就无法向用户充分证明。但是当时没能把这个问题以一种自动化的方式解决掉。那么能不能利用软件供应链、自动化流水线、可溶构建Hash值。这些源码都在可以控制可重构建环境里。
如果对环境里的软件有任何质疑可以审计,至少提供了审计可能性,有审计可能性从安全角度来说倒逼威慑云厂商或软件 SV ,不敢再提供的源码层面上投毒。要把整个这套机制完全自动化,避免终端用户使用远程证明服务时手动填写配置参考值。
10.发布《机密计算保障人工智能系统安全研究报告》
开源社区做产品毕竟是一个安全类的东西,是人性化的东西。大家做一些合规性工作时,大家都是说我今天是 0 分,磨一磨做个 60 分赶紧交卷过合规就结束了。很少有人主动为了通过一个合规,好好做一个 80 分 90 分的成绩通过合规。合规既然这么被动,那就提前做这个技术,不能在合规上推广这个东西,把它做成一个标准框架。
刚才也说了,全球现在4家公司在做类似东西,以后可能会更多。再结合我们设计的东西跑在用户执行环境里。提供干净的框架,让用户证明开源的目标要比传统开源的好处多。就是必须要开源,甚至在这个场景要强制开源。在这种情况下强制开源,现在定义的是这个框架,再过几年这个模式真的形成了。现在的优势等,在三四年以后可能都稀释成标准的能力。各家可能在做框架、做服务的时候,不再是拼谁有 Confidential AI 框架,谁的框架做的更好,可能拼的是真正的是闭源的那部分或者是用户控制部分或者在综合的 TOC 的优势。既然能预见到未来技术的走向,那就提前作为先吃螃蟹的人,把这个技术往国际化国内的标准去做。
11.Confidential AI总结
因为今天时间有限,精密计算没有在底层技术上解释,或者是说明它提供了一个强的硬件隔离性。不管是基于密码学的数据隔离,还是基于私有内存的访问控制隔离。有了硬件保证的强隔离性,就可以一定程度上相信即使是远端的执行环境消费了敏感数据,即使是有特权恶意的管理员或者是入侵到基础设施的攻击者也没办法直接访问到TEE或者可信执行环境内的敏感数据。这是今天做 Confidential AI 能做到安全跟隐私保护的硬件安全依赖的前提。
第二点是过去的安全观念。可能数据安全很多时候还靠合规跟法律保护,大不了数据泄露了 SRA 赔一笔钱。但是在 AI 大模型场景下,用户是不希望数据泄露的,即便赔了钱也难以弥补损失。
用户主观上其实正在寻求一种更好的安全跟隐私保护的技术。所以我们也希望利用 Confidential AI 机密计算这套框架,能够真真正正不再依赖于防君子不防小人的这种方式,而是真正从技术上证明数据是仅被在执行环境里用于预期的目的,不会拿数据做安全跟隐私承诺之外的事情。这件事情今天在技术上是具备了可能性的。这种方式其实在降低信任成本的。信任成本应该以前很少人提过,但是用云计算的安全能力、执行环境安全性,就是在严重依赖云提供的安全技础设施的保障。
如果云基础设施的安全被攻破,或者主动作恶,那么数据安全性毫无安全可言。所以哪怕不使用云只要逻辑、数据处于一个不可控的环境,其实就是对那个环境的拥有者有信任成本。如何降低信任成本也是机密计算能抗分热技术正在解决的问题。
还有一点就是这个技术本身是具有普适性的。用户很多时候不是终端用户而是有一定开发能力的用户。这类有开发能力用户用了这个技术,在给终端用户开发的产品里面是能够直接继承提供的安全跟隐私堡保护的,它可以利用提供高安全隐私保护区去吹他的应用也具备同样的安全跟能力。这是一个比较大的技术飞跃,叫 Confidential AI Service 。
其实我们其实自下而上在龙溪社区搞了一堆这样那样的东西。但是其实大多数东西都是在上游开源社区合作的,而不是仅在龙溪社区去做。所以我们希望自己做的东西不仅是服务龙溪社区,而是服务整个业界的。关于 Confidential AI 我们预计可能在一月份会在龙溪社区发布一个开源的方案。开源方案其实可以为很多如 ODM 用你的硬件,然后搭载一个 OS 。
OS 根据用户可以选择,然后在上层使用一个解决方案。这个解决方案虽然是开源的是参考实现,但是至少让用户能够看得见,摸得着,能够体验到今天这套硬件以及里面的机密计算能力是怎么保证工作负载的,它可以依据你的参考实验实现自己定制跟商业化逻辑。这个解决方案对卖硬件也是一个很好的优势。我的演讲就到此结束,大家可以扫一下二维码进群,谢谢大家。