李保珲, 李 斌, 任 望, 杨 光, 王永涛, 杜宇鸽, 张 鹏2*中国信息安全测评中心 系统评估处 北京 中国 00085

2中国科学院信息工程研究所 信息内容安全国家工程实验室 北京 中国100093

1 引言

云计算以资源聚合和虚拟化、应用服务和专业化、按需供给和灵便使用的服务模式, 提供高效能、低成本、低功耗的计算与数据服务。它是万物互联时代信息基础设施与应用服务模式的重要形态, 是新一代信息技术集约化、规模化与专业化发展的必然趋势。国家《“十三五”战略性新兴产业发展规划》(〔2016〕67 号)明确提出云计算等技术“将广泛渗透于经济社会各个领域, 信息经济繁荣程度成为国家实力的重要标志”, 应“推动云计算等技术向各行业全面融合渗透”。

然而, 作为一种新兴的资源利用方式, 云计算模式将租户数据的所有权和控制权分离, 使得云租户对其数据和业务系统的控制能力减弱。这种控制权旁落的状况导致云租户在云中的程序或数据容易被其他云内其他租户或云服务商篡改、分析或窃取,对云租户安全构成极大风险, 文献[1]将这一问题称为云的可信性问题, 本文沿用这一称谓。在这方面,云租户程序或数据遭受其他云租户或云服务商威胁的事件频发, 仅举几例说明之：

1. 文献[2]中, 云管理员利用其便利条件成功删除或篡改了云租户的虚拟机登录密码; Google曾经为此类原因辞退了2位恶意内部员工[3];

2. 文献[4]基于 Cache的侧信道攻击方式, 成功获取了位于同一物理机上其他虚拟机的密钥信息;

3. 攻击者利用 Hypervisor的漏洞, 成功获取了同一物理机上其他虚拟机的控制权[5];

4. 云服务提供商可以在未经云租户授权的情形下, 轻易捕获客户虚拟机的内存以及虚拟寄存器等数据[6]。

早在2010年，云安全联盟已经将该类攻击认定为云计算的七大安全威胁之一[7]，另外，在一项调查研究中，76%的受调查者认为，云服务商内部员工执行攻击行为是非常可能且时常发生的[8]。可以看出，云服务的推广和普及力度，很大程度上取决于云计算的可信性。为此，产业界和学术界都在不断地提出相应的安全机制和解决方案，以消除云租户的顾虑，让企业和个人大规模地使用云计算服务。这些方法多数采用一些系统伴随策略，比如采用以流量监测为关键技术的防火墙、入侵检测和病毒防范等附加技术确保安全，然而，这些措施并没有触及云不可信问题的根源，而且以封堵、查杀等为主要手段的措施容易失效；更进一步，与其依赖外部监测等措施将威胁挡在外面，不如提升系统自身机制的安全性，使威胁无计可施，已有工作开始致力于这方面的研究和实践[9]。基于该认识，本文旨在从云计算资源管理机制这一视角出发，对云计算面临的根源性可信威胁、研究现状及解决方案进行一个全面的论述，并通过总结分析，从根本上找出提升云计算可信性的研究方法。

本文的第二部分剖析了云资源共享机制对云计算可信性提出的挑战；紧接着，阐述了围绕这些不可信因素开展的研究工作，并进行了总结分析；然后，给出了从根本上提升云计算可信性的若干建议并进行了展望，最后，总结全文。

2 资源共享形成的云可信威胁分析

云计算的根本特性就是通过资源共享机制满足多租户的弹性可扩展等需求。然而, 本文认为恰恰是当前云计算的资源共享机制是威胁云计算可信性的根本原因之一, 下面予以详细分析。

对目标成功实施攻击的前提是在遵守系统规则的基础上, 借助攻击者和攻击对象之间共享的媒介资源建立接触关系; 反之, 若攻击对象不在攻击者的攻击半径内, 则攻击将无法成功实施。仅举四例说明之： 第一, 以经典的两台物理机通过网线连接的网络攻击场景为例, 攻击者只有通过共享的物理网络资源将探测或攻击代码传输至受害者才能成功实施攻击; 第二, 以用户态的栈缓冲区溢出攻击, 攻击者只有借助共享的内存地址空间,将程序控制流转移至shellcode才能成功实现攻击;第三, 以内核态的攻击为例, 在这种情况下, 所有的内核代码通过共享的段寄存器等资源, 实现了共享内核地址空间, 因此, 一旦攻击者突破了内核中的某一薄弱点, 便会导致基于段等安全机制的保护功能失效, 从而能够访问内核的剩余部分; 第四, 以云计算的集中运维所形成的恶意内部人员问题为例, 所有的云计算中心在空间共存于云服务提供商的机房中, 且接受相同内部人员的运行和维护, 这就对恶意内部人员作恶形成了便利条件。

需要指出的是, 本文所指的资源共享是广义的,主要包括两种共享方式： 一种是时间上的复用, 如多个vCPU共享同一个物理CPU、相同内容的内核代码共享同一物理地址的内存空间, 多个进程共享同一 Cache, 多租户共享运维人员在时间的体现; 另一种是空间上的共存, 比如不同程序内容占用不同的物理地址内存空间, 内核态代码共享同一特权空间等。

相比普通网络环境, 云环境中共享资源更多、力度更强, 范围覆盖了网络、寄存器、内存、硬盘等物理资源, 因此, 云中的攻击途径更加丰富多样。表 1列举了由于资源共享所能进行的攻击。

可以看出, 资源共享是形成安全问题的根本原因, 也是云可信性缺失的根本因素。与此同时,云计算是在现有虚拟化、高速网络、分布式计算等众多信息技术基础之上整合而成的一种计算模式。虽然, 现有的虚拟化资源管理器满足小规模及相对封闭环境的部署需求, 但令人失望的是, 其并没有针对大规模及相对开放的商业部署环境提供或设计足够的安全特性及机制[10], 直接造成了云的资源共享和集中运维等模式存在严重缺陷。因此,深入分析当前的虚拟化资源管理器的资源共享机制对于提升云计算的可信性具有重要的理论、指导和实践意义。

表1 云中资源共享所形成的安全问题举例Table 1 Problems caused by resource sharing in cloud

其实, 从本质上来看, 资源共享形成的安全问题主要表现两个方面：

首先, 为了支持多租户共享CPU、内存、硬盘等资源, 不得不引入资源管理器等软件来执行资源分配、回收、隔离及调度等功能; 但是, 这使得云软件栈更为复杂, 可信基的扩大增加了脆弱性出现的概率。同时, 资源管理器一般具有较高权限, 因此, 其造成的安全问题威胁也更大, 本文将这类问题称为资源管理机制实现的脆弱性问题。

其次, 如前面分析, 资源共享运行机制本身也能形成一些列的安全问题, 如基于共享 Cache和内存所造成的侧信道攻击, 再比如恶意内部人员问题,本文将这类问题称之为资源管理机制本身的问题。

下面, 分别针对这两种问题的相关研究进行分析。

3 国内外研究现状及分析

近年来, 云计算的可信性越来越成为制约云计算快速大规模推广实施的瓶颈, 本文主要就资源管理机制实现的脆弱性问题和资源管理机制本身的问题进行分析。对于后者中的集中运维问题, 因其人为因素比较突出, 本文拟将其单独讨论。故, 下文分别针对资源管理机制本身的问题、恶意内部人员以及资源管理机制实现的脆弱性问题三类不可信安全风险的相关研究工作进行分析。

3.1 研究现状

3.1.1 资源管理机制本身的问题

资源管理主要解决资源的分配、回收、共享和隔离等问题。在资源隔离方面，Hypervisor和内核提供了多种隔离措施，如在GDT、LDT中，均有自己的段界限等属性，同时还设计了基于段的特权级保护模式（CPL、RPL、DPL、IOPL）、并限制某些特殊指令的使用，如lgdt、lidt及cli等，这是对描述符所描述对象的隔离保护；在分页隔离机制中PDE和PTE中的R/W和U/S等提供了页级隔离方法，同时分页机制将线性地址与物理地址加以映射，提供了对物理地址的保护。在资源共享方面，云资源的共享主要包括时间上的复用和空间上的共存两种方式，下面从这两方面进行详细分析。

需要说明的是，作为物理存储逻辑表示方法呈现的存储虚拟化设备一般只是作为单纯的数据存取载体存在、不直接参与运算过程，更进一步的，攻击一般是由运算过程中的控制流非法转移等因素形成，也就是说攻击较少发生在单纯的数据存取载体内。因此，本文不将存储虚拟化作为研究重点。另外，由于PaaS和SaaS层的资源利用方式一般是基于IaaS层的Hypervisor或内核的资源管理机制实现的，比如，在阿里ECS云虚拟机中安装应用软件，该SaaS层服务便主要是利用了底层Hypervisor与内核的资源管理接口。综上，囿于篇幅等原因，本文重点探讨IaaS层的计算资源共享问题。

基于时间复用的资源共享问题

时间上复用是实现资源共享的主要方式之一。以内存为例，云服务提供商为了提高物理内存的使用率，会将内容重复的内存部分以共享的形式提供服务[13]，但对这种共享方式来说，这种共享方式对读操作的影响不大，但对于写操作便会执行写时复制[14]等操作；再以共享CPU资源为例，CPU硬件虚拟化技术就是通过上下文切换机制实现的，也就是保存上一虚拟机的运行时状态，然后进入下一虚拟机状态，实现了不同虚拟机之间在时间维度的切换与复用。特别的，由于时间上复用内存或cache，进程切换等时刻便会执行内容重载操作[15]，一方面，是否存在重载操作可导致执行时间的变化；另一方面，上下文切换时的剩余数据也可导致信息泄露，这两者最终可形成侧信道攻击。比如最近爆发的Meltdown和 Spectre漏洞便是在时间复用上缺少了相应的保护措施而形成的。需要指出的是，在非虚拟化环境中，也存在类似的侧信道攻击，如文献[16,17]已经在不同进程间分别成功实现了RSA、AES等秘密数据的获取。由于对基于内存的侧信道攻击所能获取的信息和案例少，故本文主要对基于 Cache的侧信道攻击进行分析。

基于 cache的侧信道攻击可以分为时间驱动和行踪驱动两种，其中，前者对攻击的条件要求较高，如不需要同驻等，但由于噪音数据的来源多且数量大，故其需要采集的数据较多；后者对攻击条件比较严格，如要求同驻等，但由于噪音数据来源少且数量小，故需要采集的数据相对较少。早在2012年，文献[18]便在Amazon云上分别实现了前述两种类型的侧信道攻击，如跨虚拟机的键盘操作监控、cache负载测量。HomeAlone[19]也基于类似的机理，设计了验证云租户虚拟机是否运行在物理隔离的处理器上。

对于该类攻击的隔离及防御方法可以分为以下几类。一是在硬件层面设计新型的cache结构[20,21]，实现资源隔离，比如文献[20]引入了分割锁缓存和随机变换缓存以此来增加推理信息的复杂度。然而，由于工艺复杂度和性能消耗大等因素，我们发现这些新兴的 Cache结构并没有出现在主流的处理中，也没有得到大规模流行。二是针对AES等密码算法的攻击，通过在软件层面重构相关密码算法的实现过程，实现了抵御基于cache的时间侧信道密码实现算法[22,23]；但是这种方法的适用面较窄，不具备通用性和可推广性，在近几年并没有获得大规模应用，预计在可预见的未来是不会大规模普及的。三是在现有硬件特性的基础上，通过在软件层面上设计新型的Cache利用机制，并以此确保Cache的安全利用。如 PLcache[24]通过对每一个 cache行引入一 bit标识，实现了动态cache划分；CAT[25]利用cache划分机制，将cache划分为不同的区域，可以有效抵御基于Last-level cache的攻击。然而，这种方法无法抵御基于划分后子区域的time-channel攻击。为此，CATalyst在其基础上进行了改进，其利用 CAT将cache划分安全和不安全区域，其中，不安全区域是由硬件管理且可以被任意应用使用，安全区域是由软件管理且只允许 cache-pinned的安全页内容载入该部分，从而将cache做成一个软硬件综合管理的混合体；文献[26]基于page coloring技术实现cache的安全利用。与之类似，文献[27]提出了依据cache的大小，将物理内存划分为不同的区域，然后将不同的物理内存映射至不同的cache，如此实现物理隔离，但是这种物理隔离的实现方法由于粒度粗、违背了资源共享的初衷，因此，其对性能的影响较大。文献[28]通过动态重映射和延长cache索引等技术可有效的抵御基于 Cache的侧信道攻击，也具有一定的通用性，但是，Cache的作用就是为了解决CPU运算速度和内存读写速度不匹配的问题，这就要求Cache的设计在缓存大小有限的前提下实现较低的缺失率、较高的复用率，然而，该方法却在较大程度上降低了 Cache的使用效率，也因此对整个系统的性能造成很大影响。四是通过作业调度、物理资源隔离等方式，实现程序在时间或空间上的隔离执行，比如，文献[29]基于强制VM的确定执行来防止此类攻击的成功发生，但是这种方法需要对云计算中心的改动很大，且延长了任务执行时间，其有效性值得商榷。文献[30]通过虚拟机的放置策略进行限制，比如，通过将物理机上的CPU等资源划分为不同的域，与此同时，同类或属于同一部门的虚拟机放置在同一隔离域，以此避免cache的共享。但是，这种方法违背了云计算资源共享的特性，降低了资源利用率和计算性能。

基于空间共存的资源共享问题

空间上共存是实现资源共享的另一种主要方式，如多虚拟机共享同一物理内存、多文件共享同一硬盘存储空间。由于多实体共享同一物理设备，隔离机制本身的脆弱性等问题，容易形成隔离失效等问题（如栈缓冲区溢出攻击便实现了临近数据的覆盖），势必会形成共享实体之间的互相访问，导致实体之间的互相干扰，安全和功能便出现问题了。比如，为了实现同驻物理机上各虚拟机之间内存资源的隔离，Xen设计了影子页表等机制，达到了为各虚拟机划分独立地址空间的目的；再比如，为了实现硬盘资源的隔离，多数虚拟化机制设计了基于映像文件的方式来隔离不同的虚拟磁盘文件，也就是在宿主操作系统上建立一个文件来保存虚拟机的操作系统等文件，比如，VirtualBox的vdi文件，VMware的vmdk文件等。由于内存历来是攻防关注的重点，故下文重点对各虚拟机或各进程共享的内存资源进行分析。

其实，从本质上来看，系统虚拟化环境中的多虚拟机内存资源复用方式和非虚拟化环境中的多进程内存资源复用方式是相似的，比如，KVM就是借助 Linux内核本身的多进程共享机制会虚拟机提供隔离的内存资源；再比如，Xen的影子页表技术和Linux内核中基于页表的地址转换技术并无本质不同，如这两种方式都需要采用基于段和页等机制的隔离措施[31]保证空间共存各部分的隔离。另一方面，分析常见的虚拟机逃逸等攻击方式可知，这类攻击与传统基于内核漏洞的攻击类似，其一般基于虚拟机管理器的缓冲区溢出、竞争条件、释放后复用等内存破坏方面漏洞，可以改变程序的控制流（比如，更改函数返回地址）或者关键数据（比如函数指针列表、跳转表等），达到改变程序执行流程、突破原有的隔离机制以实现对 Hypervisor或者其他虚拟机的攻击。比如，文献[32]便是基于释放后复用攻击实现逃逸的。因此，本文将Linux内核的多进程和系统虚拟化的多虚拟机内存资源共享技术归为一类来进行分析。由于篇幅限制，本文就主要的防御机制进行分析。

栈缓冲区溢出是突破限定区的常见攻击途径之一，其通过覆盖临近区域内容，可以实现代码注入、程序控制流转移等。文献[33]将栈段设计为不可执行，从而在一定程度上阻止了注入代码获得执行权限；然而，这种方式难以组织return-into-libc[34]的攻击方式。为此，Pax[35]所有数据内存页上代码获得执行权限，并且设计了额外的措施来阻止该种攻击方式。与之不同，文献[36]设计了基于金丝雀的保护措施，也就是在栈中的特定位置植入探测数据，通过检测该数据是否发生变化来判断是否发生了缓冲区溢出攻击。

除了栈缓冲区溢出外，堆缓冲区是黑客的第二类攻击点。为此，Windows XP SP2采用了不可执行堆、堆 cookie和堆管理元数据安全断开等机制应该该类问题。格式字符串溢出是黑客的第三类攻击点。FormatGuard[37]和 GUN C 库的 FORTIFY_SOURCE均提供了相应的保护机制，比如，FormatGuard通过静态分析输入输出类函数参数等技术降低了格式字符串攻击的成功率。

其实，攻击者在进行攻击之前，需要充分掌握进程空间的地址布局，固定的地址空间布局就使得攻击者容易掌握该类信息。基于此，文献[38]等提出了地址空间随机布局的防御机制，加大了攻击获取该类信息的难度，也因此提升了成功攻击的难度。然而，攻击者设计了堆喷射和动态代码产生喷射等技术[39]来应对这种防御措施。为此，文献[40]提出了新型的防御方法INSeRT，其通过组合随机化机器指令核心要素以及随机植入特定陷入代码段等机制，实现了该类攻击的有效防御，且性能损耗小于5%。

3.1.2 恶意内部人员

内部人员能够成功作恶的途径有两个： 一是利用管理软件集中且复杂的缺陷发现安全漏洞实现登录, 比如, 文献[41]指出, 若恶意内部人员获取Hypervisor的特权, 可执行内存扫描攻击; 二是利用自身所处地位的优势违规对云资源进行操作, 比如,文献[41]指出, 若可直接接触云存储服务器, 可篡改镜像模板或未加密快照等。下面分别对这两方面进行分析。

管理软件集中且复杂

对于管理软件栈集中且复杂问题, Disaggregated Xen[42]将 Dom0中新建客户虚拟机的代码转至独立的虚拟机DomB(Dom Builder)中, 利用客户操作系统良好的隔离特性将客户虚拟机建立代码中的脆弱点封闭在该虚拟机中, 从而不会对其他虚拟机造成影响。Xoar[43]将Dom0分解为7类不同功能的虚拟机,以此达到更好地隔离故障和减小攻击面的目的。与之类似, SSC[44]也是通过将 Dom0分解为称为“UDom0”的多个管理虚拟机, 并且在这些UDom0上设置了隔离策略。然而, 一方面, 这些工作只是简单的对 Dom0进行功能分解, 并没有对分解后的各子部分仍可能面临的安全风险进行防范, 因此, 对Dom0的安全提升作用有限。与前述分割思路不同,文献[45]一方面简化虚拟机启动程序、降低了虚拟机启动过程中与Hypervisor的交互次数, 另一方面,将集中式操作简化、转变为分布式操作, 既提升了虚拟机的启动速度, 也提升了虚拟机的安全性, 该项工作为解决“隔离与性能”这个矛盾提供了有益参考。

除此之外, 还有部分工作集中在基于云租户可控的加密等措施保证云租户隐私即便被拿走, 恶意内部人员也无法看懂。在这方面, CryptDB[46]、Mylar[47]以及ShadowCrypt[48]等提供了对云服务商透明的云租户数据加密机制, 可有效预防恶意内部人员的内部威胁; Over-encryption[49]等设计了依赖云服务商配合的云租户数据加密服务, 在数据到云服务商之前已经过加密, 故可有效预防云服务商内部人员偷窥或窃取用户隐私。但是, 这类方法一方面需要较大的计算资源, 另一方面针对云租户程序的攻击无能为力。

违规操作

CSA对此在管理层面上提出了若干建议, 比如控制供应链管理、建立良好的违规通报制度, 也有部分安全公司提出利用云堡垒机技术来支撑管理[50],然而, 对于部分高级别员工存在有利条件越过网络限制, 通过直接接触服务器等实施恶意行为, 不能有效应对“最后一公里”的安全风险。

另外, 研究发现, 恶意内部人员一般伴随着明显的心理学波动或者消极的社会言论, 因此, 部分工作监控并分析内部人员的心理状态变化, 预测其恶意入侵倾向[51,52]。还有部分工作对内部人员使用云平台服务的日志信息和行为轨迹进行分析, 挖掘其个人特征和使用意图[53,54]。

3.1.3 资源管理机制实现的脆弱性问题

虚拟机管理器是云进行资源管理的主要部件,而且其功能也是越来越丰富。以被广泛使用的 Xen为例, 其提供虚拟机管理、调度、指令模拟、事件通道、内存管理等功能, 其代码量也从 2.0版本的约45K行飙升至约270K行, 这样的一个代码量势必会有大量的漏洞[9]。下面分别对主要的 Hypervisor重构、Hypervisor完整性验证等方法进行分析。

重构Hypervisor

针对此类攻击最直接的想法是将不必要的功能分割出去以缩减 Hypervisor的代码规模, 通过减少可信基来降低脆弱性出现的概率。在这方面, No-Hype[55]充分利用CPU和I/O设备等硬件的特性, 取代了部分由软件支持的 Hypervisor部分功能, 但是这种设计方式丧失了虚拟化技术便利资源管理的特性; Nova[56]将 Hypervisor重构为多个独立且运行于用户模式的Hypervisor, 只有小部分特权指令运行于内核模式, 限制虚拟机只能攻击其所属的Hypervisor。但是这些方法只支持静态缩减, 不能在虚拟机运行过程中动态缩减。为此, Min-V[57]构建了两类场景： 一类是具有完整 Hypervisor功能的启动环境, 另一类是关闭部分虚拟功能的生产环境。为了进行动态缩减, 其首先在完整的 Hypervisor启动环境上启动一个客户虚拟机, 生成这个虚拟机的快照后将其迁移到生成环境中, 实现了 Hypervisor中无用代码的动态删除。与上述思路不同, Cloudvisor[58]对 Xen的软件架构进行了重置, 其利用嵌套虚拟化技术将将Xen和Dom0置于非root模式, 将Xen及Dom0和具有更高权限的Cloudvisor划分在不同的特权空间, 这样, 当Xen和Dom0在执行特权操作时便会陷入 Cloudvisor执行安全检查。H-SVM[59]和HyperWall[60]将内存管理和安全保护进行了分离,Hypervisor不能任意访问所有内存, 比如, 一旦内存页划分给客户虚拟机之后, 通过硬件机制确保在该虚拟机非授权的情形下不能被 Hypervisor访问。然而, 一方面, 频繁的上下文切换会对性能产生一定程度的影响; 另一方面, 只解决了恶意Hypervisor这单个因素对guest OS的攻击; DeHype[61]和HyperLock[62]以为每一个客户虚拟机分配一个 KVM实例的方式实现隔离, 将客户虚拟机的影响范围仅限于其所属的KVM实例中, 但这种方法性能损耗大且占用的资源也较多; 与之类似, 文献[9]通过每个客户虚拟机都分配相应Hypervisor运行空间的方法,限制恶意云租户无法通过 Hypervisor的脆弱性攻击其他云租户虚拟机, 但其并没有考虑如何保障隔离后各Hypervisor子部分的安全性。文献[63]为敏感应用程序开辟出一块受保护内存, 并结合加密措施,让应用程序的执行受限在该范围内; 当需要和外界程序交互时, 需进行边界安全检查等。

监控Hypervisor的完整性

在确保 Hypervisor完整性方面, 文献[64, 65]基于TPM等技术可实现对Hypervisor启动时完整性的测量, 但是这类方法对运行时的完整性却无能为力。为此, 部分研究工作基于特定的硬件特性对运行时的 Hypervisor完整性进行保护。在这方面, Hyper-Guard[66]和HyperCheck[67]提供了对运行时Hypervisor完整性的测量方法, 但是, 这两者都依赖于 CPU的 SMM 模式, 因此, 难以获得全部Hypervisor运行时的上下文信息; HyperSentry[68]利用系统管理模式(System Management Mode, SMM)来保护 Hypervisor的控制流, 虽然能够获取完整性所需的全部信息, 但其除了需要SMM的支持外, 也需要IPMI(Interface Platform Management Interface)的支持, 因此, 其对硬件的要求较高。

3.2 讨论和总结

表 2总结了云计算可信性威胁与代表性思路及工作之间的对应关系。

表2 问题与相应工作对应关系Table 2 Relationship between problems and corresponding work

由表 2可以看出, 当前资源管理机制方法主要由四种：

(1) 改变当前的资源复用或管理机制, 弥补现有管理机制的不足, 从根本上去掉时间或空间上资源共享方式所能带来的威胁, 如重构Hypervisor、改变当前cache的复用策略、将管理虚拟机拆分为多个具有最小权限的虚拟机、增加不可执行的限制等。

(2) 打破原有的固定格局, 通过引入随机机制,利用多样性改变系统相似性、单一性, 利用动态性、随机性改变系统静态性、确定性[69], 最终实现攻击难度的提升并以此确保系统自身安全, 如文献[38]通过引入进程地址空间的随机布局机制极大地提升了攻击难度。

(3) 引入“边计算边防护”的运行模式, 实现系统的自我监测与防护, 如在应对资源管理机制实现的脆弱性问题时引入 Hypervisor完整性监控机制,比如文献[36]引入金丝雀等检测方法在运行时实现运行时溢出攻击监测, 文献[33]引入不可执行机制,在运行时阻止攻击程序获得可执行权限。

(4) 创新人员管理机制, 重视管理和政策法规在信息安全中的地位和作用, 限制内部人员工作方式和途径, 构建新型人力资源共享机制。

4 展望

云计算环境中资源共享的范围更广、力度更大,故处理好“共享与隔离”这对矛盾, 确保各虚拟机或进程之间的良好隔离是提升云可信性的途径之一。与此同时, 在确保安全的前提下, 还需要兼顾“安全与性能”这一矛盾[70], 从隔离性最高但慢到不实用的模拟执行, 到现代全虚拟化技术所采用的动态二进制翻译与硬件辅助虚拟化, 再到修改虚拟机系统的半虚拟化, 最后到共享内核、基于容器的操作系统级虚拟化,无一不是在安全隔离和性能的天平上寻找平衡点。因此, 统筹处理、综合考虑“共享与隔离”和“安全与性能”这两对矛盾是提升云计算可信性的关键所在。

结构是功能的物质基础[71]; 同时, 结构决定功能、性能、效能和安全性, 即一个确定功能可以有多种实现结构, 不同的实现结构具有不同的使用性能、效能和安全性[72]。然而, 当前云计算的基础结构通过层层迭代与合成构建在虚拟机上, 并在虚拟机上实现功能和性能, 以此来对应多样化、规模化、无确定模型表征的云计算应用需求, 难以达到高效能的需求;另一方面, 现有的计算机体系结构出于降低成本等方面的考虑, 去掉了成熟的安全机制, 如存储器的隔离保护机制、程序安全保护机制等, 导致程序可以被随意修改, 系统区域的数据可以随意修改[73]。为此, 本文认为应在深刻把握云中多样的资源共享形态及其在隔离前后不同场景及阶段矛盾特殊性的基础上,“必须借助计算体系结构和计算模式的技术创新去实现相对安全”[74], 设计相应的隔离方法及隔离后各子部分间新型矛盾的应对策略, 以此构建面向可信云计算的新型虚拟化资源安全管理机制。在这方面,本文抛砖引玉, 认为应首先关注如下问题：

(1) 研究Hypervisor安全计算体系结构

云租户之间的攻击一般是利用 Hypervisor的脆弱性成功实施的, 而大体量的 Hypervisor共享同一特权空间(如64位的X86, 共享根模式下的Ring-0特权空间)是其脆弱性较多的根本原因。文献[9]发现,75.39%的攻击直接与Hypervisor相关, 其余24.61%的攻击多数与Dom0中的QEMU和工具栈有关。

因此, 应在分析 Hypervisor内部各模块权限大小、交互关系和现有硬件特性等多方面研究对Hypervisor划分策略和实现方法的影响, 同时注重研究 Hypervisor安全计算体系结构及相应的安全保障机制, 包括隔离策略和机制、各子部分的交互和通信方式、隔离后的安全保障机制等。

(2) 针对基于痕迹驱动的侧信道攻击设计按需可配置的Cache缓存隔离模型和安全复用机制

和时间驱动的攻击相比, 痕迹驱动的攻击具有获取数据精准、噪音数据小、推理简单等优点, 因此,其具有更大的威胁。文献[75]指出, 破解一个128AES的密码, 痕迹驱动只需要约500 000次数据采集, 而时间驱动的攻击却需要2pow(27.5)次数据采集。造成这种攻击的根本原因之一是因为攻击者可以通过直接接触、分析受害者所使用Cache的规律, 推断出受害者相应内存访问规律, 最终将蛮力攻击的搜索空间缩小、实现快速识别。

如果将含有关键信息的内存所对应的 Cache数据隔离开, 那么切断了攻击者直接接触受害者Cache数据的可能, 也致使其无法进行后续推理。基于这种思考, 在现有硬件结构的基础上, 研究融合时间复用和空间共存的新型 Cache缓存隔离模型和安全使用机制应对基于痕迹驱动的侧信道攻击, 包括Cache和内存的映射关系、隔离Cache的复用策略及Cache缓存一致性问题等。

(3) 构建管理虚拟机组计算模式

在很多云计算虚拟化资源管理系统中都有一个系统超级用户或系统管理员, 拥有对系统全部资源的存取和分配权, 所以它的安全至关重要。如果不加以限制, 有可能由于超级用户的恶意行为、口令泄密、偶然破坏等对系统造成不可估量的损失和破坏, 因此, 有必要对系统超级用户的权限加以分割和限制, 实现权限最小化原则, 并形成权限之间的制约机制。为此, 构建管理虚拟机中各功能之间的交互和依赖关系模型, 并基于此研究管理虚拟机组计算模式及其相应的安全保障机制以应对恶意内部问题, 包括各子部分的交互方式、权限策略和机制、隔离后的安全保障机制等, 最终从权限分割及最小化、互相制约、追溯问责等角度限制内部的恶意人员。

(4) 基于虚拟机自省的可信数据获取技术

审计、取证及问责是提升云计算可行的关键一步。当面临审计、取证、问责时, 云提供商为了逃避责任, 可能故意删除、修改日志, 审计的日志并不是原始记录信息, 从而导致可信证据缺失, 然而, 出现故障或发生安全事件时, 若没有足够的可信证据,则无法据此进行审计和问责。由此可见, 需设计云计算可信性数据采集、存储等机制以支撑审计、取证及问责, 包括设计云平台可信测评协议, 验证虚拟机从创建到撤销整个生命期中的可信性, 对云平台上收集的各种证据进行可信度量模型。

(5) 构建虚拟化资源安全管理架构的可信评价与验证模型

研究虚拟化资源安全管理架构的可信评价与验证模型, 包括计算效能影响评价模型及可信环境安全性验证方法, 实现安全计算体系结构或计算模式的性能和安全评价及验证、保障虚拟化资源安全管理架构在运行过程中的安全可信状态, 为设计有效的云计算虚拟化资源安全计算体系结构和计算模式提供理论和实践支持。

5 总结

针对现有云计算虚拟化资源管理机制对云可信性的影响, 本文首先分析了当前云计算资源管理机制及其安全隐患; 然后, 从资源管理机制本身的安全问题、资源安全机制的脆弱性问题以及恶意内部人员问题三个方面分析了国内外的研究现状; 紧接着, 分析认为, 计算体系结构和计算模式的创新是解决“共享与隔离”和“安全与性能”这两对矛盾的关键, 并提出了在这方面应优先着重解决的五个问题及若干思考; 最后, 总结全文。

致谢 感谢中国信息测评中心系统评估处的各位同事以及中国科学院信息工程研究所信息内容安全国家工程实验室相关老师和同学提出的有益建议。

感谢审稿专家和编辑部老师对本文提出的有益建议及指导。