论文部分内容阅读
【摘要】目前，云计算应用的安全都是通过在虚拟机监控器中添加软件层来对云计算应用进行保护的，然而此种云计算应用保护技术在需要保护的云计算应用非常密集时，云计算应用的执行效率就会非常低，而且单一的保护模块一旦出现故障，云计算应用就会得不到保护。针对这一问题，提出一种基于多处理器虚拟化的云计算应用安全保护模型，该文运用了硬件辅助虚拟化的技术，将云计算应用安全保护系统直接控制部分硬件资源，作为与VMM对等协作的独立系统运行，同时构造出多个独立的保护系统用于负载平衡及故障替换。通过测试表明，该模型在很大程度上满足了云计算应用安全保护密集的需求。
【关键词】云计算虚拟化云计算应用安全多处理器对等协作
云计算作为未来IT业主要趋势之一，正迅速在企业级应用中普及。它体现了“网络就是计算机”的思想。将大量可规模化计算资源、存储资源与软件资源链接在一起，形成巨大的共享虚拟IT资源池，通过对于大规模资源的高效灵活调度为远程计算机用户提供按需动态扩容和收缩的计算服务，同时也为云服务提供商提供了巨大的资源优化调度空间，用规模化的效应最大程度地降低了成本。云计算是将资源以网络服务的形式提供给用户，将用户从复杂繁琐的IT软硬件维护中解放出来，而且，远程用户可以随时随地或得服务，打破了时间和地域的限制。
出于对数据安全的考虑，云计算出现了四种子模型，即为私有云，公共云，社团云以及混合云。私有云是对企业内部IT资源的虚拟化和自动化管理，是企业内部计算资源的整合，面向内部用户，云的规模由内部资源的总量决定，而且所有数据仍旧由企业自己管理，这种云规模比较有限，只能享受部分云计算的优势。公共云是云计算的设计最终模型，公共云也称为第三方云，有着更大的灵活性和成本优势。企业可以将计算和存储外包给云服务提供商，不需自己购买设备和投入专业人员来做云系统维护，而且还能在计算需求变化时灵活地增减云资源的租用。但是，将计算和存储外包给云服务商，就意味着将数据也外包给了第三方—云服务提供商，这样数据的私密性就得不到保证了，这是与私有云的最大区别，也是现在大部分云计算应用局限于私有云的原因，然而公共云是云计算的最终模型。社团云是几个有共同应用需求的组织共同组建的半公共云，它比私有云有更大的资源优化空间，比公共云有更小的风险。混合云是私有云和公共云的混合，即用户将私密性数据和业务运行在私有云中，将非私密性数据和业务运行在公共云中。这四类云中，公共云是云计算的设计初衷，也有着最大的灵活性和成本优势，本文主要目标是研究分析公共云中云计算应用的安全。
用户数据在云服务器端有两种存储形式，静态存储和动态计算。静态数据以存储为目的，不需要参与运算，只是利用云的存储功能，因此静态数据能够用密码学加密技术进行保护。动态数据可能存在于内存、网络或缓存等介质中，参与运算。动态数据在参与运算时需要还原成明文形式，现在还没有技术能让数据在加密的状态下进行运算，因而私密数据在云端至少有一部分时间是以明文形式存在的。在这段以明文形式存在的时间里动态数据就有可能泄露，因为云计算服务是通过因特网提供给用户的，云服务是始终在线的，因而来自网络的攻击可能通过用户虚拟机的网络接口进行入侵，攻破用户虚拟机的操作系统，进而访问用户进程所占的内存空间。
现有的云计算应用的安全机制都是基于虚拟机技术之上的，通过在虚拟机监控器中添加软件层来对云计算应用进行保护。比如已经实现了的chaos系统[5-7]。然而此种云计算应用保护技术已经在一定程度上影响了计算密集型的应用的执行效率[9]。所以在需要保护的云计算应用非常密集的云平台上，就严重影响云计算应用的执行效率了，而且单一的云计算应用保护模块一旦出现故障，云计算应用就得不到保护了。
本文提出并实现了一种基于多处理器虚拟化的云计算应用安全模型，此模型运用了硬件辅助虚拟化的技术，将云计算应用安全保护系统直接控制部分硬件资源，作为与VMM对等协作的独立系统运行，同时构造出多个独立的保护系统用于负载平衡及故障替换。
一、安全保护模型的系统结构描述
集成在虚拟机监控器中的保护技术远远不能满足云计算应用保护密集型的云计算平台，本系统采用硬件划分方式，使云计算应用的保护模块直接控制部分硬件资源，将其从虚拟机监控器中移植出来转换为具备特权的CAPPM，与VMM形成对等协作的结构。控制主体有两部分组成，VMM和CAPPM。VMM负责虚拟化，CAPPM负责保护云计算应用，存在多个CAPPM，每个CAPPM控制一个AP，VMM控制BSP和其余AP。如图1所示。
将云计算应用保护模块从虚拟机监控器中移植出来转换为与VMM对等协作的独立系统，一方面大大增强了对云计算应用保护密集的云平台的云计算应用保护的响应速度，另一方面，一旦某个保护系统出现故障，其他保护系统可以继续提供保护而且多个CAPPM可以进行负载均衡。
二、模型实现的关键细节
整个模型实现的关键细节包括：硬件资源划分，VMM初始化，CAPPM构造，VMM-CAPPM通信。
2.1硬件资源划分
为了实现VMM和CAPPM之间的协作，首先要对两个系统进行隔离，包括硬件资源的隔离和地址空间的隔离，避免两者在硬件控制上产生冲突，同时需要考虑采用适当的共享措施保证VMM和CAPPM之间的交互。
硬件资源可分为独占性资源和可共享资源，不同资源的分配原则也不同，独占性资源需要明确指定其唯一的控制主体，不允许存在交叉的控制现象，可共享资源需要对资源进行细粒度分区，指派给多个控制主体，但需要保证同步。VMM和CAPPM之间的硬件划分如表1所示。
2.1.1处理器划分与实现
处理器的划分应该根据不同主体的负载情况，VMM负责为上层虚拟机提供运行环境，需要协调多个虚拟机对处理器的共享使用，而且，虚拟机之间的通信是很少的，因此处理器越多，虚拟机之间的并行度越高，云平台上的客户虚拟机执行效率就越高，也就越接近单机上的真实物理计算环境，而CAPPM只提供对云计算应用的安全保护功能，并且保护模块对处理器的要求也不是很高，所以每个CAPPM控制一个处理器，VMM控制其余的所有处理器。 系统中的多处理器信息在开机后由BIOS检测并存放在特定的物理内存空间中，根据多处理器启动协议，首先运行BSP，系统中的其他AP处于睡眠状态，等待BSP的唤醒，BSP上运行VMM，VMM从BIOS数据区中获得完整的多处理器信息，识别需要分配给CAPPM的AP。
2.1.2物理内存划分与实现
为了实现VMM和CAPPM地址空间的隔离以及数据交互。需要将整个物理内存划分为3个部分，分别是VMM管理区、CAPPM管理区、共享区，共享区只能被访问而不参与分配，管理区则需参与内存管理器的动态分配和回收。VMM根据E820内存信息获得整个物理内存的布局状况，在此基础上VMM对不可分配的区域进行限制。通常采用基于位图的管理方式来控制内存的使用，对VMM不可分配的区域相应的位图进行标记，表示此段内存区间也被保留，从而实现VMM和CAPPM内存区域的隔离。
2.1.3中断路由
外部中断有两种情况，一是IOAPIC递交的设备中断，二是AP产生的处理器间中断。通过中断源对应的中断向量可以区分这两种外部中断，第二种中断跟VMM与CAPPM通信有关将在后面讨论。我们需要把所有的第一种中断首先递交给VMM，然后VMM根据中断来源做出进一步处理，或直接在内部处理，或递交给CAPPM处理。
多处理器平台上的中断不再通过单处理器的中断控制器8259A向处理器递交，而是通过IOAPIC将中断递交给特定的处理器，通过对IOAPIC设置，可以实现将所有的外部中断首先递交给VMM。IOAPIC包括了一组中断重定向表，一个外部中断对应重定向表中的一项，通过重定向表将外部中断发到指定的LAPIC，最后VMM通过操作LAPIC中的中断命令寄存器将外部中断递交给CAPPM。
2.2CAPPM构造
CAPPM作为一个的独立系统为云计算应用提供安全保护。作为一个和VMM对等协作的独立系统，CAPPM也将运行在VMX根模式下，重新为CAPPM编写操作系统没有必要，我们可以借助开源的操作系统，对其进行添加和修改，将云计算应用保护模块添加到开源的操作系统的内核中。Linux是最好的选择，因为CAPPM目前只提供云计算应用保护这一功能，所以我们可以对最初的Linux版本（例如linux0.11版本）进行添加和修改。CAPPM的构造主要包括处理器控制、内存限制和启动。
2.2.1CAPPM处理器控制
CAPPM运行改造后的Linux系统，处理器控制主要是防止CAPPM去管理其余的处理器，我们是选择最初的Linux版本进行修改的，最初的Linux版本本来就不支持多处理器，所以CAPPM不会去管理其余的处理器。
2.2.2CAPPM内存限制
整个物理内存被VMM和CAPPM分区管理，需要对CAPPM能够探测、分配使用、访问的范围进行限制。由于E820探测出的是完整的内存布局信息，因此需要对CAPPM的E820信息进行修改来控制CAPPM访问的限制，分配限制则通过对CAPPM的内存位图进行修改。
2.2.3CAPPM启动
传统的操作系统是由Bootloader加载并启动，VMM是第一个启动的系统，它的启动可以由Bootloader完成。CAPPM是在VMM的控制下启动的，并且机器的运行环境也发生了改变，如物理内存布局等，因此需要VMM根据启动协议的要求和当前资源的分配情况，模拟出Bootloader的行为并启动CAPPM。
2.3VMM-CAPPM通信实现
在VMM和CAPPM通信之前首先采用了轮询的负载均衡算法选择与哪个CAPPM进行通信。VMM和CAPPM通过同步通信的方式进行通信，以处理器间中断完成消息通告，并通过一块共享内存完成数据的传输。VMM-CAPPM通信实现主要包括共享内存组织结构设计和通信处理流程构造
2.3.1共享内存组织结构
由于共享内存空间有限，在传递大量数据时需要提供复用机制，保证数据在共享区内的可靠传递，因此需要对共享内存区域进行组织。我们把共享内存划分为控制区和数据区，控制区存放公开控制指针，数据区则以环的形式组织。
2.3.2通信处理过程
通信的关键在于数据的发送方式和接收方式，发送数据相对容易实现，可以先将数据放置到共享内存，然后以处理器间中断完成消息通告。接收数据则需要考虑IPI丢失、缓冲区溢出、同步等问题。
三、模型评估
基于多处理器虚拟化的云计算应用安全保护模型，将云计算应用保护模块集成在Linux内核中直接控制部分硬件成为独立的系统，实现了VMM和CAPPM之间的对等协作，然而采用对等协作方式之后，随着CAPPM系统个数的增加，云计算应用保护密集的云平台上的需要保护的云计算应用执行效率会不会也随之而提高，然而模型的稳定性会不会降低，这些问题是模型评估的主要方面，需要搭建相应的测试环境，对上述问题进行严格的测试。
对于硬件需要具备两个以上的处理器核，并且支持硬件虚拟化的处理器，和具备较为充足地址空间的内存，因此我们选择Intel的支持虚拟化的多核心处理器和4GB内存，对于软件CAPPM我们采用chaos系统和Linux 0.11内核开发而成，虚拟机监控器则采用支持硬件虚拟化的Xen。
我们构造了含有不同CAPPM系统个数的协作模型，编写了性能测试程序对我们构造的模型进行性能测试，此性能测试主要测试模型在云计算应用保护密集时，随着CAPPM系统个数的增加，需要保护的云计算应用的平均执行效率的变化以及模型稳定性的变化。
如图2所示随着CAPPM系统个数的增加，模型的稳定性基本保持不变。说明了模型的可行性。
如图3所示随着CAPPM系统个数的增加需要保护的云计算应用的平均执行效率在逐渐提高，然而由于用于测试的机器中的处理器个数有限并没有测试出CAPPM个数一直增长，云计算应用的平均执行效率会怎样变化。
四、结束语
本文提出了基于多处理虚拟化的云计算应用保护技术，将集成在虚拟机监控器中云计算应用保护模块移植出来，让其集成在Linux内核中成为与VMM对等协作的独立系统，在一定程度上解决了云计算应用保护密集型的云计算平台的需求。然而由于用于测试的机器中的处理器个数有限并没有测试出CAPPM个数一直增长，云计算应用的平均执行效率会怎样变化。
参考文献
[1]冯登国，张敏，张研等.云计算安全研究[J].软件学报，2011，22（1）：71-83.
[2]房晶，吴昊，白松林.云计算安全研究综述[J]. China Academic Journal Electronic Publishing House，2010年第九期.
[3]陈全，邓倩妮.云计算及其关键技术[J].计算机应用，2009年9月第九期.
[4]张云勇，陈清金，潘松柏等.云计算安全关键技术分析[J]. China Academic Journal Electronic Publishing House.
【关键词】云计算虚拟化云计算应用安全多处理器对等协作
云计算作为未来IT业主要趋势之一，正迅速在企业级应用中普及。它体现了“网络就是计算机”的思想。将大量可规模化计算资源、存储资源与软件资源链接在一起，形成巨大的共享虚拟IT资源池，通过对于大规模资源的高效灵活调度为远程计算机用户提供按需动态扩容和收缩的计算服务，同时也为云服务提供商提供了巨大的资源优化调度空间，用规模化的效应最大程度地降低了成本。云计算是将资源以网络服务的形式提供给用户，将用户从复杂繁琐的IT软硬件维护中解放出来，而且，远程用户可以随时随地或得服务，打破了时间和地域的限制。
出于对数据安全的考虑，云计算出现了四种子模型，即为私有云，公共云，社团云以及混合云。私有云是对企业内部IT资源的虚拟化和自动化管理，是企业内部计算资源的整合，面向内部用户，云的规模由内部资源的总量决定，而且所有数据仍旧由企业自己管理，这种云规模比较有限，只能享受部分云计算的优势。公共云是云计算的设计最终模型，公共云也称为第三方云，有着更大的灵活性和成本优势。企业可以将计算和存储外包给云服务提供商，不需自己购买设备和投入专业人员来做云系统维护，而且还能在计算需求变化时灵活地增减云资源的租用。但是，将计算和存储外包给云服务商，就意味着将数据也外包给了第三方—云服务提供商，这样数据的私密性就得不到保证了，这是与私有云的最大区别，也是现在大部分云计算应用局限于私有云的原因，然而公共云是云计算的最终模型。社团云是几个有共同应用需求的组织共同组建的半公共云，它比私有云有更大的资源优化空间，比公共云有更小的风险。混合云是私有云和公共云的混合，即用户将私密性数据和业务运行在私有云中，将非私密性数据和业务运行在公共云中。这四类云中，公共云是云计算的设计初衷，也有着最大的灵活性和成本优势，本文主要目标是研究分析公共云中云计算应用的安全。
用户数据在云服务器端有两种存储形式，静态存储和动态计算。静态数据以存储为目的，不需要参与运算，只是利用云的存储功能，因此静态数据能够用密码学加密技术进行保护。动态数据可能存在于内存、网络或缓存等介质中，参与运算。动态数据在参与运算时需要还原成明文形式，现在还没有技术能让数据在加密的状态下进行运算，因而私密数据在云端至少有一部分时间是以明文形式存在的。在这段以明文形式存在的时间里动态数据就有可能泄露，因为云计算服务是通过因特网提供给用户的，云服务是始终在线的，因而来自网络的攻击可能通过用户虚拟机的网络接口进行入侵，攻破用户虚拟机的操作系统，进而访问用户进程所占的内存空间。
现有的云计算应用的安全机制都是基于虚拟机技术之上的，通过在虚拟机监控器中添加软件层来对云计算应用进行保护。比如已经实现了的chaos系统[5-7]。然而此种云计算应用保护技术已经在一定程度上影响了计算密集型的应用的执行效率[9]。所以在需要保护的云计算应用非常密集的云平台上，就严重影响云计算应用的执行效率了，而且单一的云计算应用保护模块一旦出现故障，云计算应用就得不到保护了。
本文提出并实现了一种基于多处理器虚拟化的云计算应用安全模型，此模型运用了硬件辅助虚拟化的技术，将云计算应用安全保护系统直接控制部分硬件资源，作为与VMM对等协作的独立系统运行，同时构造出多个独立的保护系统用于负载平衡及故障替换。
一、安全保护模型的系统结构描述
集成在虚拟机监控器中的保护技术远远不能满足云计算应用保护密集型的云计算平台，本系统采用硬件划分方式，使云计算应用的保护模块直接控制部分硬件资源，将其从虚拟机监控器中移植出来转换为具备特权的CAPPM，与VMM形成对等协作的结构。控制主体有两部分组成，VMM和CAPPM。VMM负责虚拟化，CAPPM负责保护云计算应用，存在多个CAPPM，每个CAPPM控制一个AP，VMM控制BSP和其余AP。如图1所示。
将云计算应用保护模块从虚拟机监控器中移植出来转换为与VMM对等协作的独立系统，一方面大大增强了对云计算应用保护密集的云平台的云计算应用保护的响应速度，另一方面，一旦某个保护系统出现故障，其他保护系统可以继续提供保护而且多个CAPPM可以进行负载均衡。
二、模型实现的关键细节
整个模型实现的关键细节包括：硬件资源划分，VMM初始化，CAPPM构造，VMM-CAPPM通信。
2.1硬件资源划分
为了实现VMM和CAPPM之间的协作，首先要对两个系统进行隔离，包括硬件资源的隔离和地址空间的隔离，避免两者在硬件控制上产生冲突，同时需要考虑采用适当的共享措施保证VMM和CAPPM之间的交互。
硬件资源可分为独占性资源和可共享资源，不同资源的分配原则也不同，独占性资源需要明确指定其唯一的控制主体，不允许存在交叉的控制现象，可共享资源需要对资源进行细粒度分区，指派给多个控制主体，但需要保证同步。VMM和CAPPM之间的硬件划分如表1所示。
2.1.1处理器划分与实现
处理器的划分应该根据不同主体的负载情况，VMM负责为上层虚拟机提供运行环境，需要协调多个虚拟机对处理器的共享使用，而且，虚拟机之间的通信是很少的，因此处理器越多，虚拟机之间的并行度越高，云平台上的客户虚拟机执行效率就越高，也就越接近单机上的真实物理计算环境，而CAPPM只提供对云计算应用的安全保护功能，并且保护模块对处理器的要求也不是很高，所以每个CAPPM控制一个处理器，VMM控制其余的所有处理器。 系统中的多处理器信息在开机后由BIOS检测并存放在特定的物理内存空间中，根据多处理器启动协议，首先运行BSP，系统中的其他AP处于睡眠状态，等待BSP的唤醒，BSP上运行VMM，VMM从BIOS数据区中获得完整的多处理器信息，识别需要分配给CAPPM的AP。
2.1.2物理内存划分与实现
为了实现VMM和CAPPM地址空间的隔离以及数据交互。需要将整个物理内存划分为3个部分，分别是VMM管理区、CAPPM管理区、共享区，共享区只能被访问而不参与分配，管理区则需参与内存管理器的动态分配和回收。VMM根据E820内存信息获得整个物理内存的布局状况，在此基础上VMM对不可分配的区域进行限制。通常采用基于位图的管理方式来控制内存的使用，对VMM不可分配的区域相应的位图进行标记，表示此段内存区间也被保留，从而实现VMM和CAPPM内存区域的隔离。
2.1.3中断路由
外部中断有两种情况，一是IOAPIC递交的设备中断，二是AP产生的处理器间中断。通过中断源对应的中断向量可以区分这两种外部中断，第二种中断跟VMM与CAPPM通信有关将在后面讨论。我们需要把所有的第一种中断首先递交给VMM，然后VMM根据中断来源做出进一步处理，或直接在内部处理，或递交给CAPPM处理。
多处理器平台上的中断不再通过单处理器的中断控制器8259A向处理器递交，而是通过IOAPIC将中断递交给特定的处理器，通过对IOAPIC设置，可以实现将所有的外部中断首先递交给VMM。IOAPIC包括了一组中断重定向表，一个外部中断对应重定向表中的一项，通过重定向表将外部中断发到指定的LAPIC，最后VMM通过操作LAPIC中的中断命令寄存器将外部中断递交给CAPPM。
2.2CAPPM构造
CAPPM作为一个的独立系统为云计算应用提供安全保护。作为一个和VMM对等协作的独立系统，CAPPM也将运行在VMX根模式下，重新为CAPPM编写操作系统没有必要，我们可以借助开源的操作系统，对其进行添加和修改，将云计算应用保护模块添加到开源的操作系统的内核中。Linux是最好的选择，因为CAPPM目前只提供云计算应用保护这一功能，所以我们可以对最初的Linux版本（例如linux0.11版本）进行添加和修改。CAPPM的构造主要包括处理器控制、内存限制和启动。
2.2.1CAPPM处理器控制
CAPPM运行改造后的Linux系统，处理器控制主要是防止CAPPM去管理其余的处理器，我们是选择最初的Linux版本进行修改的，最初的Linux版本本来就不支持多处理器，所以CAPPM不会去管理其余的处理器。
2.2.2CAPPM内存限制
整个物理内存被VMM和CAPPM分区管理，需要对CAPPM能够探测、分配使用、访问的范围进行限制。由于E820探测出的是完整的内存布局信息，因此需要对CAPPM的E820信息进行修改来控制CAPPM访问的限制，分配限制则通过对CAPPM的内存位图进行修改。
2.2.3CAPPM启动
传统的操作系统是由Bootloader加载并启动，VMM是第一个启动的系统，它的启动可以由Bootloader完成。CAPPM是在VMM的控制下启动的，并且机器的运行环境也发生了改变，如物理内存布局等，因此需要VMM根据启动协议的要求和当前资源的分配情况，模拟出Bootloader的行为并启动CAPPM。
2.3VMM-CAPPM通信实现
在VMM和CAPPM通信之前首先采用了轮询的负载均衡算法选择与哪个CAPPM进行通信。VMM和CAPPM通过同步通信的方式进行通信，以处理器间中断完成消息通告，并通过一块共享内存完成数据的传输。VMM-CAPPM通信实现主要包括共享内存组织结构设计和通信处理流程构造
2.3.1共享内存组织结构
由于共享内存空间有限，在传递大量数据时需要提供复用机制，保证数据在共享区内的可靠传递，因此需要对共享内存区域进行组织。我们把共享内存划分为控制区和数据区，控制区存放公开控制指针，数据区则以环的形式组织。
2.3.2通信处理过程
通信的关键在于数据的发送方式和接收方式，发送数据相对容易实现，可以先将数据放置到共享内存，然后以处理器间中断完成消息通告。接收数据则需要考虑IPI丢失、缓冲区溢出、同步等问题。
三、模型评估
基于多处理器虚拟化的云计算应用安全保护模型，将云计算应用保护模块集成在Linux内核中直接控制部分硬件成为独立的系统，实现了VMM和CAPPM之间的对等协作，然而采用对等协作方式之后，随着CAPPM系统个数的增加，云计算应用保护密集的云平台上的需要保护的云计算应用执行效率会不会也随之而提高，然而模型的稳定性会不会降低，这些问题是模型评估的主要方面，需要搭建相应的测试环境，对上述问题进行严格的测试。
对于硬件需要具备两个以上的处理器核，并且支持硬件虚拟化的处理器，和具备较为充足地址空间的内存，因此我们选择Intel的支持虚拟化的多核心处理器和4GB内存，对于软件CAPPM我们采用chaos系统和Linux 0.11内核开发而成，虚拟机监控器则采用支持硬件虚拟化的Xen。
我们构造了含有不同CAPPM系统个数的协作模型，编写了性能测试程序对我们构造的模型进行性能测试，此性能测试主要测试模型在云计算应用保护密集时，随着CAPPM系统个数的增加，需要保护的云计算应用的平均执行效率的变化以及模型稳定性的变化。
如图2所示随着CAPPM系统个数的增加，模型的稳定性基本保持不变。说明了模型的可行性。
如图3所示随着CAPPM系统个数的增加需要保护的云计算应用的平均执行效率在逐渐提高，然而由于用于测试的机器中的处理器个数有限并没有测试出CAPPM个数一直增长，云计算应用的平均执行效率会怎样变化。
四、结束语
本文提出了基于多处理虚拟化的云计算应用保护技术，将集成在虚拟机监控器中云计算应用保护模块移植出来，让其集成在Linux内核中成为与VMM对等协作的独立系统，在一定程度上解决了云计算应用保护密集型的云计算平台的需求。然而由于用于测试的机器中的处理器个数有限并没有测试出CAPPM个数一直增长，云计算应用的平均执行效率会怎样变化。
参考文献
[1]冯登国，张敏，张研等.云计算安全研究[J].软件学报，2011，22（1）：71-83.
[2]房晶，吴昊，白松林.云计算安全研究综述[J]. China Academic Journal Electronic Publishing House，2010年第九期.
[3]陈全，邓倩妮.云计算及其关键技术[J].计算机应用，2009年9月第九期.
[4]张云勇，陈清金，潘松柏等.云计算安全关键技术分析[J]. China Academic Journal Electronic Publishing House.