ACM通信

实践

迈向机密云计算

作者:Mark Russinovich, Manuel Costa, Cédric Fournet, David Chisnall, Antoine Delignat-Lavaud, Sylvan Clebsch, Kapil Vaswani, Vikas Bhatia
ACM通信，2021年6月，第64卷第6期，54-61页
10.1145 / 3453930
评论

尽管在很大程度上是由规模经济驱动的，但现代云计算的发展也提高了安全性。大型数据中心提供综合可用性、可靠性和安全保证。确保操作系统、数据库和其他服务具有安全配置的运营成本可以在所有租户之间分摊，从而允许云提供商雇佣负责安全的专家;这对于较小的企业通常是不可实现的，因为系统管理员的角色经常与许多其他角色合并在一起。

云数据中心还受制于严密的物理安全:拥有物理访问权限的人数是有限的，对他们访问权限的控制在大型云提供商的数据中心比在办公场所更严格——经常容易受到内部威胁，例如心怀不满的前员工带着敏感数据或物理媒体的副本离开(包括现场备份)。

云提供商使用与租户相关的密钥系统地加密传输中的数据(在网络上)和静止的数据(在磁盘和备份上):即使攻击者获得了数据中心的访问权限，他们也无法看到租户数据的明文，除非他们也设法泄露了自己的托管密钥。这种增加云安全的趋势将继续下去;下一步是保密计算，将硬件强制加密保护扩展到使用中的数据(即在计算期间)。

回到顶部

信任云

租户为什么要从表面上相信云的安全保证呢?租户在不同程度上信任提供者。一些人可能完全相信它能保护他们的数据安全。有些人可能担心其他租户、软件bug或内部攻击(例如，来自数据中心技术人员)。有些可能需要遵守严格的隐私法规。一些人可能还怀疑提供商执行其声明的安全政策的意愿或能力——例如，保证他们的数据在没有他们的同意下永远不会被使用——甚至担心在云服务运行的司法管辖区受到传票和其他法律攻击。为了解决这些问题，租户越来越多地期望:

• 为敏感工作负载提供最少的硬件、软件和可操作的可信计算基础(TCBs)。
• 技术实施，而不仅仅是业务策略。
• 担保、剩余风险和他们获得的缓解措施的透明度。

通过允许租户对用于运行云工作负载的TCB进行完全控制，机密计算满足了这些期望:机密计算允许租户精确地定义可以访问其工作负载(数据和代码)的所有硬件和软件，并提供技术机制来可验证地执行这一保证。简而言之，租户对他们的秘密拥有完全的控制权。

特别是，机密计算可以使工作负载对云提供商不透明，因为租户可以使用这种精确级别的控制来防止管理程序和其他云托管基础设施访问他们的机密。这可以防止来自云结构及其运营商的攻击，并补充了更传统的安全目标，即保护云结构免受潜在恶意租户的攻击。

这种级别的控制不仅仅是阻止云托管基础设施的访问:它允许租户指定一组特定的秘密只能由特定的代码模块处理。这种能力非常强大，因为它可以用来设计具有减少攻击面的弹性系统。对置于机密云服务中的信任进行精确控制，可以在互不完全信任的多方之间实现有用的场景。例如，租户可能反过来为自己的客户部署具有强隐私保证的服务;竞争各方可以联合配置和运行多方云计算(如数据分析或机器学习)，并对其池数据的使用提供强有力的技术保证。

向保密计算的转变是整个行业努力的一部分。机密计算联盟成立于2019年，包括阿里巴巴、AMD、Arm、谷歌、华为、英特尔、微软、英伟达、甲骨文、红帽等许多公司。联盟的存在是基于这样一种认识:要想过渡到所有云服务都默认使用保密计算的世界，将需要栈的所有级别都付出大量努力，从硬件开始，包括管理程序、操作系统内核和云服务。

回到顶部

保密计算平台

让我们看看受信任的执行环境、动态实现、盲管理程序和各种平台抽象。

硬件基础:可信执行环境。在堆栈的最低级别，硬件必须能够提供TEE(可信执行环境)，将给定机密工作负载的代码和数据与系统中运行的任何其他代码(包括在最高权限级别上运行的代码)隔离开来。当数据流入和流出TEE时，硬件还必须支持对它的所有I/O进行加密，并且能够测量和签署TEE的内容，以产生可验证的证据，证明它是安全的。这反过来又需要信任的硬件根源保存平台根秘密和签名密钥，以及一个公开密钥基础设施来批准这些密钥。值得庆幸的是，这些功能通常可以安装到现有平台的新一代中，因此它们可以用于保密模式，而不需要专门的硬件和软件。

隔离。为了保密性和完整性，在TEE中运行的软件必须安全，不受系统其他部分的窥探或干扰。这可能涉及到防护和锁定机制，以防止在加载和测量可信代码后对其进行更改，并为TEE专门使用诸如核心或内存缓存之类的资源以减少侧通道。许多tee对它们的所有状态或存储在可信紧耦合内存之外的部分使用加密。侧通道，如Spectre和Meltdown系列漏洞或差分功率分析，有可能穿透隔离。tee的完整硬件/软件堆栈必须针对威胁模型范围内的任何威胁提供防御—例如，推测负载加固^3.在编译器中，或安全缓存^8，13以及安全投机机制^9，14在硬件。其中一些防御可能完全建立在软件级别——例如，通过使用数据跟踪无关的数据结构。⁵

信任的硬件根源。保护必须植根于硬件;否则，云运营商可以通过在软件中模仿tee轻松打破隔离。每个具有tee功能的设备必须具有唯一的身份，并使用硬件秘密进行加密保护。例如，在设备的制造过程结束时，可以在设备内部的保险丝库中采样和记录这个秘密，制造商可以获取相应的公钥来颁发平台证书。可信平台模块(tpm)提供了一个早期的离散信任根示例，对物理攻击的保护有限。谷歌最近发布的OpenTitan核心和微软的pluto子系统是更高级的集成硬件信任基础的例子。Pluton最初是为Xbox One游戏主机创建的，因此有很长一段时间被大规模部署到潜在的敌对环境中。它还集成到Azure Sphere IoT(物联网)设备中，并已被授权给主要的CPU供应商(AMD、英特尔和高通)，在那里它最初提供TPM接口，并可以为机密计算系统提供信任的硬件根源。

尽管信任的硬件基础现在已经很好地建立起来了，但它们传统上保护在设备上提供服务的人(游戏邦注:游戏发行商或云提供商)不被滥用，而机密计算进一步要求它们保护第三方免受攻击者的攻击，攻击者拥有对设备的物理访问权或对设备非机密部分的逻辑访问权。例如，允许云提供商签署的固件直接访问硬件秘密的机制违反了保密计算的承诺。

认证。认证是在机密计算中建立信任的机制。与加密消息传递系统一样，没有完整性的机密性是不够的。如果你不能保证它真的存在，那么以云提供商无法检查或篡改的方式运行软件是没有用的是您期望运行的软件。

认证使用由信任的硬件根维护的硬件秘密派生的密钥来签署证据，证明TEE处于由真实硬件设备保护的已知良好状态。这个证据类似于安全引导签名:TEE的一组测量值，例如，初始内存内容的散列和各种安全关键寄存器的状态。在接收和验证这些证据之后，远程用户或软件组件可以确定TEE的完整性，然后通常会建立一个加密通道来部署秘密并控制TEE内部的计算。

硬件进步:动态TEE实现。物理隔离是保证机密性和完整性的最简单方法—例如，通过使用带有简单I/O接口的隔离核心。这是苹果的Secure Element (iOS设备和最近的mac设备中都有)所采用的路线。当TEE中运行的代码具有预先知道的计算和存储需求，并且由单个供应商提供时，这就足够了。在具有弹性需求和许多租户的云环境中，这是不够的:云结构必须能够创建可变大小的tee，能够在单个系统上托管多个tee，并且能够动态地向tee分配/释放资源。

作为保密计算工作的一部分，tee在过去几年里已经可以在大多数通用处理器上使用。Arm的TrustZone提供了一个早期的TEE实现，允许在启动时将内存分配给两个世界中的一个——安全的或正常的——并允许安全世界中的一个小型的、受信任的内核提供独立的进程。在这个模型中，所有安全世界的组件都必须信任安全内核(如果存在的话，还必须信任安全管理程序)，但是它们不必信任正常世界的管理程序和操作系统内核。

Intel的SGX(软件保护扩展)在这方面更进一步，提供了在用户模式进程的虚拟地址空间中创建独立内存区域的能力。根据资源限制，可以在引导后动态创建任意数量的区域。区域内的代码和数据通过CPU实现的访问控制检查来防止软件攻击:hypervisor和内核不能看到或篡改区域内的数据。这些区域还通过内存加密来防止物理攻击者:无论何时使用的数据离开CPU缓存，在写回内存之前都会被加密。

如果您只想保证机密性，而不想在访问内存总线的对手进行重放攻击时保证加密的完整性，那么内存加密开销很低。Xbox 360和之后的型号自发布以来就使用了AES(高级加密标准)进行内存加密，为游戏提供了足够的带宽和延迟，这是现代cpu上要求最高的工作负载。主流cpu的内存控制器现在也获得了类似的功能，包括对不同内存区域的不同键的支持。保护大规模内存完整性不受物理攻击的代价更大;减少这种开销的方案是一个积极的研究领域。

SGX的隔离内存区域是小型tcb服务的理想选择，¹⁰但是使用它们来运行完整的虚拟机(VM)机密性是具有挑战性的，因为它们缺乏对多个地址空间和特权和非特权模式分离的支持。这导致AMD开发了另一种类型的TEE，专注于vm级别的隔离。AMD处理器经历了一系列的设计迭代，目的是将管理程序完全从信任边界中移除。他们的第一步，安全加密虚拟化(SEV)自动加密虚拟机使用的内存。接下来，SEV_ES(带有加密状态的SEV)在向管理程序的每次转换中添加VM寄存器状态的加密。最后，SNP(安全嵌套分页)提供了一个额外的保证，即管理程序不能通过篡改虚拟内存映射来破坏内存完整性，从而在机密VM上执行完整性或重放攻击。综合起来，这些特性保证了hypervisor不能读取或篡改VM状态(也就是说，hypervisor不在TCB中)。Intel最近宣布的TDX(信任域扩展)提供了一套类似于SNP的安全保证，它的目标是全面的vm级机密性。

最后，一些重要的工作负载需要专门的处理器，如gpu、fpga(现场可编程门阵列)和其他加速器。这些设备还可以增强TEE功能，具有很大的设计空间。¹²例如，一些加速器可能有大内存(例如，高带宽内存)，由物理包装保护，使加密不那么重要。在许多情况下，加速器可以一次分配给单个租户，这消除了攻击并进一步简化了它们的设计。

为了安全有效地使用这些设备，I/O总线还需要进行更改。大多数当前的系统都假定I/O总线是可信的，但这对于嵌入式系统来说是个问题:直到最近，大多数汽车使用的CAN(控制器区域网络)总线都不执行任何端到端认证，这使得媒体播放器等受损害的组件可以假装来自引擎管理系统发送消息。类似地，PCI(外围组件互连)总线规范假定所有端点都是可信的，从而允许恶意设备欺骗发起者ID，例如，但是机密加速器需要一种机制来在设备和主机tee之间建立端到端安全通道，并集成设备和主机之间的加密。

---

公开机密计算硬件需要更改云结构的系统层。

---

虚拟化进步:盲管理程序。公开机密计算硬件需要更改云结构的系统层。这包括更改管理程序以处理它不能看到VM状态的约束。主流管理程序设计遵循分层信任模型。hypervisor完全受客户机信任，负责在上下文开关之间存储客户机状态，并拥有对客户机内存的完全访问权。

大多数半虚拟化设备接口的设计都是基于这样的假设:任何来宾内存都可以用作DMA(直接内存访问)缓冲区的虚拟等等物。随着AMD SEV的出现，这些假设在主流硬件上不再成立。内存加密意味着管理程序必须为来宾程序可以使用的反弹缓冲区提供一个区域。Linux通过软件IOTLB(输入/输出转换后备缓冲区)驱动程序支持SEV的这种操作模式。

在执行从TEE内部到周围环境的显式域转换时，硬件实现通常会保留寄存器上下文。对于异步出口通常不是这样，因为异步出口可能会泄露敏感信息。在管理程序是受信任的模型中，此信息对于处理VM退出可能很有用。当系统管理程序不受信任时，要么必须对其进行修改，使其不能利用该特性，要么必须添加垫片层以清除信息。

例如，考虑第二级地址转换中的页面错误。在传统系统中，管理程序接收一个trap，其中包含完整的寄存器上下文和一个指定故障地址的异常寄存器。然后，它可以杀死VM，发出一个upcall请求VM的内核处理它，或者从后备存储中插入缺失的页。在保密计算系统中，这将允许管理程序单步执行并查看每一步的寄存器状态。至少，管理程序必须只接收经过加密和完整性保护的寄存器状态版本，但是即使知道错误地址也可能泄露过多的信息。在更安全的设计中，TEE内部的垫片层将接收异步退出，并决定是发出一个超调用来填充缺失的页面，还是简单地将故障通知内核。然后，此代码可以执行与此类退出频率相关的策略，以减轻来自管理程序的可能攻击。

值得注意的是，当硬件隔离不可用时，可以通过信任管理程序来创建一种TEE形式。这是Windows基于虚拟的安全的基础，在Windows Server 2016和Windows 10中引入，其中关键组件通过Hyper-V与Windows内核隔离运行。这可以支持与其他tee相同的抽象，包括类似SGX的隔离内存区域，但具有较弱的威胁模型:在这种设计中，管理程序仍然是可信的。这与亚马逊的Nitro Enclaves最近使用的方法类似。¹

平台抽象:机密vm、机密容器、飞地。系统层通过一组平台抽象向开发人员和用户公开机密计算硬件:机密vm、机密容器和飞地。

机密虚拟机允许租户拥有完全向后兼容的虚拟机体验，运行现有的未修改的应用程序。在后台，系统记录和检查认证，以验证安全保证，并使其可审计。在tee中放置整个vm对于快速、轻松地采用非常重要，但它也会导致一些问题。例如，虚拟机的管理员对虚拟机具有完全的读写权限，这在很多情况下过于粗糙。另一个问题是VM的TCB很大:VM映像不仅仅是一个内核和一个应用程序;它包括大量的系统服务。在最坏的情况下，这可能比在现有的云基础设施上运行软件更安全，但可能有更好的解决方案。

机密容器允许租户对TCB有更好的控制程度，并可以秘密地运行新的或现有的集装箱应用程序。在过去的几年里，容器已经成为在云中部署软件的一种常见方式。具体的技术各不相同，但容器通常是一个小型(通常是分层或虚拟的)文件系统，其中包含运行单个程序所需的最小值。

---

在一个理想的世界里，为安全而编写的软件应该专注于最小的TCB。为了让开发人员完全控制TCB，机密计算平台公开了飞地抽象。

---

最佳实践建议在每个容器中运行单个微服务。然后，编制基础设施支持部署协作微服务容器的团队。这有几个优点:可以将容器配置为具有比完整的保密VM更小的TCB，并且可以在VM管理员无法访问它的情况下运行保密容器。为容器提供隔离的TEE可能仍然基于vm级别的隔离机制(SNP、TDX等)，也可能基于进程级别的隔离。(Haven等系统²和SGXLKL¹¹[Linux内核库]采用库操作系统和Exokernel世界的思想，在SGX内存区域内运行Windows或Linux库操作系统。)

微服务的容器部署引入了复杂的认证问题:编制框架需要为这些服务提供足够的状态，以便它们能够获得密钥，它们还需要管理用于建立整个微服务集的标识的协议。

在一个理想的世界里，为安全而编写的软件应该专注于最小的TCB。为了让开发人员完全控制TCB，机密计算平台公开了飞地抽象。飞地是完全灵活的。它们可以容纳开发人员希望放入的尽可能少或尽可能多的代码——例如，它们可以容纳处理信用卡信息的单个函数或秘密信号处理算法。

与容器一样，enclave的实际硬件级隔离机制可能是VM级或进程级隔离。例如，VM级隔离可用于创建向基本VM公开简单enclave接口的sidecar VM。开发人员可以设计服务，将具有不同特权的代码划分为不同的飞地。每个飞地应被限制只能访问执行其功能所必需的数据。遵循这个最小特权原则需要开发人员做重构服务的额外工作，但是它产生了最高的安全性和最具弹性的应用程序。

对于飞地将呈现的接口，仍有很大的设计空间。OpenEnclave SDK,⁶最初来自微软，现在是机密计算联盟的一部分，提供C和c++环境，为针对几种类型的机密硬件的小型tcb开发提供了一个相对容易的起点。其他针对内存安全语言(如Rust)的sdk已经开始出现。

回到顶部

保密计算应用

机密计算使得将敏感的工作负载外包给云成为可能，它甚至引入了新的计算模式。例如，它支持安全和保密的多方计算，在这种计算中，可能互不信任的用户组可以运行联合计算并共享结果，而不必向彼此或向任何对执行计算的硬件有物理或逻辑访问权的人透露他们的私有输入。这将导致广泛的机密计算应用程序的开发——事实上，这些特性已经导致了多个应用程序领域的进步。

机密AI。机器学习算法对更多计算量和更大数据集的需求正在迅速增加。与此同时，它们的应用引发了重大的安全和隐私问题。云的弹性和可伸缩特性已经是这种类型计算的自然选择，但是机密计算使利用具有强大安全保证的云成为可能。

例如，在医疗和制药应用中，培训数据可能包括个人的私人保健记录，由此产生的模型可用于作出临床决定。在飞地内运行训练过程可确保其他人无法查看或修改数据。它还提供了完整性保证(以及健壮的审计日志)，以确保使用指定的软件堆栈在指定的记录上运行预期的训练算法。作为这些保证的一个特例，生成的模型可以被加密、签名，并配备密钥释放策略，以确保它只在另一个飞地内解锁，该飞地将强制执行特定的访问控制和使用限制。例如，飞地可以通过限制查询模型的次数和向其结果添加噪声来加强差异隐私。

例如，租户可以利用保密云计算为自己的客户提供医疗诊断服务，同时获得技术保证，不能窃取或滥用由专家第三方为此目的提供和维护的模型;它不能访问任何个人医疗信息来查询、存储或将模型用于任何其他目的。

机密数据库和分析。数据库系统存储和处理敏感和业务关键数据，如个人记录、财务信息和政府数据。未经授权访问这些数据可能会产生严重的后果，包括物理伤害、客户信任和竞争优势的丧失。当前的数据库系统提供了复杂的访问控制机制，例如基于角色的访问控制。这些机制在对抗更强的攻击者(例如对服务器具有管理或物理访问权限的攻击者)时的有效性有限。在一个常见的例子中，负责管理数据库的个人或外包团队代表着对公司的巨大内部威胁。因为这个个人或团队正在管理数据库系统，所以他们能够看到所有机密数据，即使他们不需要访问它。

在过去的几年里，加密数据库的概念被提出，作为一种加强加密访问控制的方法。在加密数据库中，数据在静止和计算期间都保持加密，使用的密钥甚至对数据库或服务器管理员都不可用。数据仅在数据所有者定义的信任边界内以明文显示。

加密数据库可以通过多种方式实现。一种方法(由CryptDB和其他相关系统提出)是使用部分同态加密方案对可信客户机上的数据进行加密。另一种方法是在受信任的执行环境(如Intel SGX enclave)中解密、处理和重新加密敏感数据。这种方法是由EnclaveDB提出的，⁷微软的SQL Server在“始终加密”特性中采用了相关的方法。从处理时将列数据流到飞地，到将所有敏感数据和查询放在飞地中，设计各不相同。基于tee的方法有可能提供更强的安全保证，例如查询处理的完整性和新鲜度、查询的机密性、防篡改审计等。它们也更加灵活(也就是说，它们允许任何类型的计算，并支持复杂的访问控制策略，例如基于属性的访问控制)。除了数据处理之外，TEE也是执行和审计细粒度键释放策略的自然选择。

机密多党合作。由飞地支持的安全和保密的多方计算⁵还可以促进数据集所有者之间的新型协作，从而成倍增加训练数据的数量。因此，多方模型可以在来自多家医院的联合数据集上进行训练，而不暴露组成数据集(通常受复杂的法规和商业考虑的影响)，而不是局限于来自单一医院的数据。尽管可以在不汇集数据集的情况下训练类似的模型，例如使用联邦学习或局部差异隐私，但这些替代方案将涉及算法更改、额外资源和效用损失。机密多方合作的场景存在于许多其他领域，包括金融、能源、气候研究和政府。

机密分类帐。在云数据中心中运行的通用应用程序需要一种方法来说服用户它们正在正确地运行。新的框架已经出现，以帮助开发人员构建这类新的可信应用程序。这些框架提供了一种简单的方法来构建运行在tee内部的可信应用程序，并生成其执行的可验证分类账。例如，CCF保密联盟框架(CCF)⁴提供防篡改分类帐和键值存储上的事务性更新。它被用来构建许多云服务，比如Azure Confidential Ledger，它提供了一个可篡改的、高性能的机密分类帐，应用程序可以使用它来存储通用日志记录，以实现可审核和可验证性。这些属性允许使用一类新的应用程序，这些应用程序需要相互不信任的各方之间的协调，以及由于法律原因需要可验证执行的应用程序。

受信任的应用程序通常使用TEE认证和安全消息传递通道。这让用户相信，他们正在以安全和保密的方式连接到正确的应用程序。CCF和其他类似框架还分发和复制应用程序逻辑的执行，以确保执行的活跃性和完整性，即使在系统中有一小部分节点是恶意的或被破坏的情况下也是如此。特别是，CCF支持拜占庭容错(允许任意恶意行为)和Crash容错配置。

回到顶部

基本的服务

可用性对于任何旨在广泛采用的安全技术都是至关重要的。很容易想象一个简单的配置开关，让租户为他们现有的工作负载开启“机密计算”，但这意味着什么呢?例如，对VM进行加密可以增加一些深度防御，但在很大程度上是安全剧院，除非加上一种可信任的机制来验证其内容:如果提供者控制初始VM，而租户没有机制来审查它，那么提供者仍然是完全可信的。

要获得有意义的端到端保护，工作负载输入和输出必须加密，相关的数据密钥必须只释放给分配给工作负载的TEE。这涉及跟踪被授权用于此工作负载的平台和代码，同时为平台和代码启用更新。为了方便起见，大多数租户可能会选择将这些任务委派给云服务。出于安全性考虑，这些服务本身必须部署在tee中，在诸如安全身份、键控和日志记录等核心功能上彼此依赖。

下一节概述机密计算生态系统的核心服务，以支持部署机密工作负载的承租者和贡献其代码的应用程序开发人员。

密钥管理和认证服务。如果机密服务需要访问任何持久数据(例如，VM磁盘映像)，那么它需要从某个地方检索密钥。对于传统的客户端磁盘加密，可以将其存储在TPM中，并通过租户输入密码短语来解锁。在云场景中，存储部分相对容易解决，要么通过Azure Key Vault之类的服务，通过托管的hms(硬件安全模块)解决，要么通过管理密钥存储的持久保密计算服务解决。然而，要求租户为他们启动的每个VM、容器或其他服务输入密码短语并不是一个可扩展的解决方案。

当租户授予对其数据的访问权时，他们将根据对包含在认证和其他可使用元数据中的信息的审查做出策略决策。这个过程可以由一个机密云服务自动化，例如Microsoft Azure认证:在机密计算开始时，新创建的TEE建立到认证服务的安全连接，并呈现它的认证材料。服务将它们与租户以前上传的授权策略进行检查，如果成功，则发出相应的凭据。TEE然后可以使用这些凭证访问租户数据。例如，它可以提供由认证服务发出的令牌，以便从HSM获得当前的解密密钥。

云提供商在一组经过授权的tee上运行认证服务，然后租户只需执行一次手动设置步骤(相当于输入密码短语)，并提供策略和凭证，以便服务可以代表其自动授权数千个vm。例如，在云内部，服务可以自动授权tee之间的迁移和从其加密检查点恢复。

为此，该服务为其数据中心提供的所有tee维护最新的、一致的平台证书缓存。它经常检查证书撤销，并可以管理，例如，为受信任的硬件一致部署固件或微码更新(通常需要新的证书集合)。因此，该服务可以支持精确的、有状态的策略声明，其形式是“此任务必须在SGX飞地内运行，在部署在德国Azure数据中心的Intel SGX v2.1平台上，在分配给租户的VM中运行，由今天有效的证书支持”，而不仅仅是“此任务必须在飞地内运行”。

从云计算的角度来看，减少不同硬件产品的数量和确保软件跨所有设备的可移植性都很重要。X86虚拟机将愉快地在英特尔或AMD的硬件上工作，即使两者的虚拟化扩展是不同的。如果机密vm需要在AMD和Intel硬件之间以不同的方式实现，这将为采用增加一个重要的障碍。通过分解特定于硬件的细节，认证服务可以使其他服务独立于平台。例如，它支持对遗留hms的集成，而不需要为不同形式的机密飞地、vm和容器定制它们。

代码的透明度。远程认证允许租户(或他们信任的服务)为其计算验证平台和软件TCB，但它不能确保该TCB是可信任的。为此，理想情况下，租户应该收集并审查其应用程序、运行时sdk和库以及编译工具链的所有源代码的安全性。然后，他们将为自己的工作负载重新构建软件映像，并检查其散列是否与用于认证的散列匹配。这项任务是艰巨的，有以下几个原因:

• 它涉及许多来自不同来源的软件，甚至对于简单的应用程序也是如此。
• 该软件的部分可能是专有的或机密的，阻碍其审查。
• 现代构建系统对其环境中的细节非常敏感，从而产生不可复制的代码。
• 云计算鼓励敏捷开发，促进无缝代码更新，通常不需要重新启动应用程序。
• 可能需要紧急补丁来缓解新披露的漏洞，而且它们几乎不能等待每个受影响的应用程序的安全审查。

为了促进这项任务，或者至少分摊它的成本，代码透明服务可以安全地记录软件依赖关系、构建环境，以及用于机密计算的结果二进制文件。云提供商可以将此服务作为机密分类帐进行操作，系统地执行代码更新策略，对生成的二进制文件进行签名，并维护所有操作的公共的、不可更改的日志。因此，租户可以配置云认证和密钥管理服务，为机密应用程序授权任何这样的签名二进制文件。

例如，租户可以配置代码透明服务，以自动安装来自知名软件供应商的紧急补丁，前提是这些补丁被正确签名并发布在其指定的GitHub项目的发布分支上。(更保守地说，它们可能还需要云提供商或指定的专家签署认可。)即使补丁被破坏了，该服务至少会提供一个强大的审计跟踪，以便在事后进行审查。软件供应商可能仍然能够破坏租户的安全保证，但不能在不危及其声誉的情况下这样做。代码透明服务还可以用来减轻软件供应链攻击，因为它为软件材料清单(SBoM)提供了可审计的来源和保管链。

回到顶部

机密计算是云计算的未来

机密计算通过授权租户远程控制其工作负载的tcb，在云中提供了强大的安全保证:它明确地说明(最小)他们仍然需要信任的硬件、软件和服务;此外，它还提供强大的技术保护，防止来自其他租户甚至云提供商的攻击。这使租户能够为其最敏感的数据开发和部署自己的机密应用程序。

保密云计算还处于初级阶段，但我们相信它最终会变得无处不在，就像其他隐私和完整性机制(如TLS和静止的加密)一样。用于机密计算的硬件(cpu、fpga和加速器)应该以快速的速度发展，这是整个行业旨在提供开放、健壮、标准化、平台无关功能的大规模协调努力的结果。当这些可用时，它们将构成云结构的基础，该云结构将由小型TCBs分隔，其中每个组件将只能访问执行其功能所需的信息。

这个基础将支持运行机密vm，以及更高级别的平台服务。虽然有些服务可能永远不会以完全保密的模式运行，但它们将从新的、更安全的基础中受益。随着软件工程工具朝着支持分隔的默认保密开发的方向发展，这些保证将很容易添加。

想象一下这样一个未来，终端用户可以完全和可验证地控制他们的数据如何被任何云服务使用。如果他们希望他们组织的文档被索引，一个机密索引服务可以保证他们组织之外的任何人都不会看到这些数据。一个保密的视频会议服务可以保证端到端加密，而不牺牲记录会话或提供记录的能力，将输出发送到一个保密的文件共享服务，除了组织的设备或保密的虚拟机之外，任何地方都不会出现未加密的情况。一个机密电子邮件系统同样可以在不损害搜索或编辑辅助功能的情况下保护隐私。最终，保密计算将使许多创新的云服务成为可能，同时允许用户保留对其数据的完全控制。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc.

---

没有发现记录