微软Azure机密云战略浅析

来源：乾越

本文是在原文《Confidential Compute on Azure with Kubernetes》的基础上进行了总结和分析。虽然这篇文章的产品部分更多地介绍了K8s类机密计算产品，但其中也有一定的篇幅介绍了Azure的机密云战略，其中一些关键观点有助于我们提升机密计算领域的视野。 本文按照以下顺序对其中的内容进行了重新梳理和总结：

• Azure的机密云战略；
• 来自Azure客户对机密计算的需求和应用场景；
• Azure的机密计算类产品。

最后，对Azure的机密云战略进行了思考。

战略

Azure在机密计算的巨大投入来自于其对机密计算的战略眼光：

• 根据分析师的预测，机密计算将快速增长，并可能成为端到端安全的标准，特别是对公共部门和银行、金融服务、保险、医疗保健、生命科学、国防和其他受监管行业的企业，或涉及关键基础设施的企业。
• 机密计算能够显著提升计算基础设施的安全水位和信任等级的天花板，为已有云产品赋能更高的信任等级和安全能力，迎合新的现代化计算模式的发展态势（AI和ML等），满足对云计算有较高安全水位和信任等级的用户需求。
• 从长远来看，一旦机密计算硬件变得广泛可用，预计机密计算将从提供数据保护的多方数据分析等专业领域的需求，转变为像对存储和传输中的数据提供一般性加密保护的标准需求，因为机密计算具备通用计算能力。
• 无论是云计算还是边缘计算，计算模式会从明文计算发展为机密计算。随着时间的推移，机密计算功能需要在Azure的计算基础设施平台上逐步得到全面普及。

客户

Azure的机密计算客户群体数量是业界最多的，因此他们给出的用户群体画像也是最能代表当前机密计算场景的真实客户群体和需求的：

• 客户希望能够完全控制数据的生命周期（包括存储、传输和使用中），并允许具有远程证明能力的客户对在云中运行的代码进行验证。
• 典型的客户群体和应用场景包括：
• 电信公司等受监管行业；
• 疾病诊断医疗机构，他们需要在机密环境中使用来自多家医疗服务提供商的数据，并在研究完成后，可以完全删除这些数据；
• 希望进行多方机器学习的零售和广告公司；
• 构建反洗钱系统的金融服务机构。

从客户视角来看，涉及多个参与方进行联合计算的场景是最通用的用户需求，比如原本两个彼此不信任的机构/组织/公司无法通过云服务在数据共享上进行合作，因为将隐私数据引入到云计算环境进行处理不符合安全合规的规定。现在由于机密计算能够提供远程证明以及内存机密性和完整性保护的能力，用户不必担心数据会离开机密计算硬件提供的TEE边界，或落入错误的实体手中。

产品

产品清单

• Azure具有使用Intel SGX、AMD SEV-SNP（处于公测阶段）、NVidia A100张量核GPU和Ampere保护内存等多种机密计算类云产品；
• Azure的GPU机密计算产品具备在CPU和GPU上TEE之间建立安全可信通道的能力，能够大幅度提升AI和ML等数据计算密集型工作负载在TEE中的执行效率；
• Azure Managed HSM云产品的后端是基于机密计算技术构建的；
• AMD SEV-SNP机密虚拟机产品使用托管在Azure Key Vault和Azure Managed HSM中的密钥实现系统的加密引导（即全盘加密），确保用户的敏感应用能够零修改地部署到计算环境中；
• 现在可以在AMD机密虚拟机上通过Azure虚拟桌面在云中运行Windows 11；
• SQL Azure原本具备基于Intel SGX提供的可选加密特性，现在用户可以在AMD机密虚拟机上运行SQL Server IaaS；
• Azure Databricks的机密计算版本会在今年发布；
• 对于正在使用开放的Confidential Consortium Framework构建去中心化网络的用户，可能涉及多个组织的参与：新的Azure托管型Confidential Consortium Framework（基于Azure机密计算构建，目前处于邀测阶段）能够免去一个组织必须自行搭建运行该网络的基础设施。

机密容器类产品

Azure的很多机密计算类云产品是基于托管型机密PaaS服务构建的，同时也为用户提供具备容器编排能力的AKS机密集群。 此外，Azure希望在为用户保持原生的K8s使用体验的同时，能够提供多种隔离粒度，以及数据安全和保护机制。

节点级机密容器AKS

AKS用于满足有容器编排能力的客户需求：

• AKS早在2020年，就已经支持了机密计算：
• Azure AKS是第一个使用Intel SGX虚拟化技术运行基于Open Enclave SDK构建的容器化应用程序的K8s云服务，且各种Anjuna、Edgeless、Fortanix或SCONE等第三方工具也提供了对AKS的支持。
• 安全消息服务Signal使用AKS中的Intel SGX节点存储用户联系信息，Signal和Microsoft的管理员都无法查看这些信息。
• 如今，AKS又是第一个支持AMD SEV-SNP机密计算的云服务。机密虚拟机节点池现在可以使用AMD机密虚拟机来运行容器，或者通过向现有AKS集群添加机密虚拟机节点池。
• 机密AKS集群属于节点级机密容器的范畴。其价值包括：
• 机密AKS集群对于在自己的基础设施上使用基于Kubernetes的应用程序的客户来说是一个很有吸引力的选择，因为他们的计算基础设施不太可能具备机密计算的能力，因为实现机密计算的服务器硬件非常新。
• 由于用户担心隐私、安全合规性或数据法规，用户可以提升和转移他们不太愿意使用的应用程序。“我的愿望是，我如何将更多的工作负载转移到公共云，因为我默认希望它在那里：将整个容器的工作负载保持原样，我甚至不必考虑它，因为它是内存加密保护的。”
• 这适用于运行代码构建代理和代码签名以实现软件供应链安全的IT组织，适用于金融机构执行数据处理管道以动态容器化作业，适用于电信提供商以满足Schrems II和其他数据监管合规性。比如说，微软的内部代码签名服务运行在AKS中提供的机密虚拟机环境中。
• 如果用户想自己在Azure上运行Kubernetes，可以使用机密计算虚拟机来托管它，并自己管理Kubernete。一些客户使用AKS Engine或Kubernetes Cluster API Provider for Azure来实现这一点，但Azure反馈：大多数客户都希望Azure将机密计算的安全性和虚拟化的隔离性直接添加到我们托管的AKS中，即这些客户隐式信任CSP。
• AKS支持异构集群，即非所有节点池都是机密虚拟机。如果用户只需要在特定节点上处理敏感数据，则不必将整个集群变成机密集群。

• 机密节点池与完整的AKS功能集共同协作，支持如自动缩放、AKS插件、Azure CNI、Azure Defender for Containers等特性。它们使用自定义的Ubuntu 20.04镜像（Microsoft正在与Canonical合作，确保Ubuntu支持所有Azure机密服务）；另外Windows Server节点很快就会出现。
• 除了使用内存加密技术对使用中的数据提供加密保护外，用户还能够通过远程证明，确信其工作负载部署在预期的环境中，并且只有用户放入这些容器中的内容才在该环境中运行。

Pod级机密容器Kata

鉴于节点级机密容器AKS无法提供多租隔离的缺点，Azure已经开始关注Kata机密容器技术栈，但细节信息还不多。

• 在今年的Kubecon+CloudNativeCon上，Azure宣布了即将推出的AKS中Kata Containers支持的邀测版本。这为同一集群上的不同工作负载提供了更高的隐私保护与安全隔离。
• Azure希望通过部署Kata机密容器为机密AKS提供统一的隔离技术。

实例级机密容器ACI

机密ACI（Azure容器实例）适用于没有容器编排需求的隔离容器场景，如机器学习、AI工作负载、或短生命周期的工作负载，它提供了serverless的机密计算能力。目前处于邀测阶段。

• 带有机密计算能力的ACI不需要用户修改容器镜像，Hypervisor会为每个容器组提供了具有内存加密的guest运行环境。
• 每个ACI实例支持独立的attestation，验证容器是否只运行了预期的组件。
• Azure表示ACI这种形态非常受数据科学家的欢迎，他们通常会部署Python容器并与Azure Machine Learning一起使用，这可以在不修改代码的情况下提供机密性保护，因为修改代码可能会影响模型精度。

启示

• 要实施机密云战略，需要一个云厂商自上而下进行推动，但即便云厂商没有执行该战略，也应该提前进行相关的技术布局，避免未来发生严重的战略踏空。
• 但要广泛意识到”传统的安全技术所能提供的数据安全防护能力其实已经不能满足当今运行在计算基础设施中的高价值数据所需的数据安全防护需求“这一点，尚需时日。
• 机密计算能够将数据的信任边界在逻辑上从数据拥有者扩展到了不可信的云计算基础设施上，将传统观点中认为的信任与计算基础设施存在物理绑定关系这一事实进行了解耦；机密计算能够尽可能地减少用户的信任成本，并具备满足用户完全控制数据全生命周期这一需求的能力。机密计算技术拥有的这些显著特点令其成为实现“机密云”的关键技术基础。
• 有些人的观点认为：机密计算提供的对计算基础设施的信任隔离这一安全水位假设得过高了。但从客户的角度来看，如果基础设施中存储着自己的高度敏感数据，客户就会认为这个安全假设非常合理。在过往的云信任模型中，客户往往是将CSP作为一个诚信的组织整体隐式信任的，但相信CSP的每一个内部人员都不会作恶或误操作是不现实的。此外，假设内部人员会主动做出恶意攻击的行为是威胁建模的重要组成部分，也是目前世界各国政府和行业在制定数据安全和隐私保护合规标准时所考虑的重要安全风险之一。
• 反驳上述观点的另一个例子：为什么当年互联网仿若一夜之前全都从HTTP切换到了HTTPS？因为在移动互联网时代，移动端用户的数据价值变高了，因此需要用更强的安全技术去保护与之价值匹配的数据。当时用TLS保护的是端到端的信道安全，而今天的机密计算TEE则保护的是服务端侧的运行环境。为什么需要保护执行环境？因为在如今的AI时代，运行在服务端侧执行环境中的数据的价值变高了：它们是花费巨大成本和训练算力通过大数据ML训练出来的模型，因此值得用安全性更高的机密计算技术去保护，毕竟模型的高附加值价值是用高成本换来的。正如Azure的机密计算产品经理所说：如果我们能够在一夜之间更新所有硬件，并拥有机密计算硬件TEE的功能，那将是非常棒的！
• 可以预见，随着GPU TEE技术的发展，ML模型训练也将大规模迁移到云上进行，这与“机密计算能够为训练环境提供隐私保护”这一前提条件密不可分。所有这些都将为机密计算带来前所未有的新场景。
• 在产品策略上，Azure没有因为机密计算的信任模型排除节点级机密容器产品，相反，Azure提供了节点级机密计算产品，如机密虚拟机和节点级机密容器，满足客户安全合规与隐私数据保护的需求，同时保持对先前云产品的兼容性（包括部署体感和业务代码零修改），利用机密计算技术增强已有云产品在安全/可信特性上的产品竞争力。做出这一决定的根本来自于Azure的机密计算用户的群体反馈：绝大多数用户反馈还是想用Azure提供的托管型K8s服务，言下之意就是Azure托管的K8s节点组件进入租户的TEE VM里并不是问题，因为当前阶段的大多数用户的主要诉求是相信Azure是诚信的，不会主动作恶，对Azure抱有隐式信任，不必严格遵守把CSP排除出TCB的信任模型，用TEE VM主要是防止外部威胁。
• 这种需求在趋势上其实迎合了从当前非机密计算信任模型到机密计算信任模型的平滑过渡，因此CSP可以在机密计算类K8s云产品中实施和非机密计算K8s类云产品一致的产品策略：节点级、Pod级、实例级，即一种在隔离性上逐层加码的渐进式产品策略，满足最广泛的用户群体对不同信任等级和安全水位的各种需求。

作者： 乾越
文章来源：乾越

推荐阅读

深入分析Linux kernel安全特性: 内核模块签名
预期功能安全专栏 | 智能汽车中人工智能算法应用及其安全综述
汽车安全之声 | 汽车智能化带来的安全新挑战及其应对思路
精品译文 | 域控制器（DC）ECU的功能安全性

更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
​