云计算安全问题研究与探讨

李玮

（中国移动通信集团设计院有限公司，北京 100080）

云计算是继计算机、互联网出现之后的又一次信息领域革新。虽然在理论方面的研究还略显单薄，但是其弹性供给、集约化和专业化的优势却引起了广泛关注和投资热情。亚马逊、谷歌、微软等老牌互联网或者软件公司更开始以云计算服务提供商的新面貌示人。云计算及其相关应用连续5年平均22%的强劲增长，也给相关行业甚至整个社会带来了巨大震动。在我国，无论是3家传统的电信运营商、还是希望利用现有外围需求拓宽业务领域的电子商务公司，都纷纷力争抢占云计算服务的制高点，为新老客户提供云计算、云存储等基础设施服务以及其它增值服务。

虽然各界都一致认为云计算有着巨大的增长空间，但在推广中依然面临着用户认可度不高、运营经验不足、产业链不完善等诸多问题。除了相关法律和规范不健全、用户的理念接受需要过程之外，商务流程的重新设计、原有程序的平滑迁移也是影响云计算推广的原因。在诸多不利因素中，云计算的安全性问题一直排在首位。因此，有必要在研究云计算技术架构和面向社会服务模式的同时，也要从企业数据、社会信息安全的角度，深入研究和探讨云计算时代所面临安全威胁、安全风险和应对措施。

1 云计算安全概述

云计算应用中，其信息安全的基本属性和安全需求不变，信息保障的安全观也没有变化，依然是要保护信息系统或信息网络中的信息资源免受各种类型的威胁、干扰和破坏。但之所以把安全问题放在首位，主要是传统互联网时代的一些成熟安全解决方案已经不再适用于云计算应用环境，主要表现在：

（1）虽然云计算以虚拟化技术为主，但是也综合了并行计算、分布计算、网格计算等，整个体系架构异常复杂。加之各主流提供商在云计算的服务模型、部署方式、物理位置、计费管理上各不相同，在理论方面没有突破的情况下，安全防护工作变得更加艰难；

（2）云计算中心部署的集中化和安全防护的专业化、集中化优势，被云计算的大规模、开放性以及技术不成熟等特点所削弱，在某些极端的情况下，甚至被逆转为劣势。

从现有的技术资料和已经曝光的安全事件来看，互联网时代中传统的安全威胁在云计算服务中同样存在，而且伴随着云计算特有的巨大规模和前所未有的开放性与复杂性，还出现了一些新的安全挑战；而从用户自身角度而言，其安全风险不是减少而是增大了。例如2009年3月，Google Docs系统出现了错误，导致他人可以访问用户的私密文件。受该事件影响，美国电子隐私信息中心(EPIC)向联邦贸易委员会强烈建议，由于Google对于安全威胁防范不足，因此在拿出切实可行的安全保护方案前须终止提供该项服务。2009年2月和7月，亚马逊的“简单存储服务(简称S3)”两次中断导致依赖于网络单一存储服务的网站被迫瘫痪等。这些安全事件又进一步加剧了人们、尤其是重要企业客户对云计算安全风险的看法。国际知名咨询调研公司IDC给出的调研统计结果表明，云计算面临的最大挑战和用户最关注的问题依然是安全问题，高达74.6%，远远高出对于性能和可用性等其它指标的关注。埃森哲公司对这一问题的调查也得出了同样的结论：其中中国企业对云计算安全性的关注度为59% ，而其他国家也达到41%。

2 云计算应用中存在的安全问题

前面已经提到，互联网时代中传统的安全威胁在云计算服务中同样存在。2009年，云安全联盟CSA（Cloud Security Alliance）发布《云计算关键领域安全指南》并更新到版本2.1。该指南主要从攻击者角度总结出云计算环境可能面临的12个关键安全域。之后CSA又发布了一份云计算安全风险简明报告，将安全指南浓缩为7个最常见、危害程度最大的安全威胁。下面，按照从低到高、由内及外等层次一一列出：

（1）基础设施共享问题:攻击者获取laaS供应商的非隔离共享基础设施的不受控制访问权；

（2）未知的风险:未知的安全漏洞、软件版本、安全实践、代码更新等；

（3）不安全的接口和API:接口质量和安全没有得到保障以及第三方插件的安全；

（4）账户或服务劫持:攻击者获得云服务用户的凭据，导致云服务客户端问题；

（5）数据丢失或泄漏:云中不断增长的数据交互放大了数据丢失或泄漏的风险；

（6）不怀好意的内部人员:从组织内部发起攻击，如果公司使用了云服务，威胁将会进一步放大；

（7）滥用和恶意使用云计算:利用云服务发送垃圾邮件或传播恶意代码等恶意活动。

较早时间，美国信息技术研究和咨询公司Gartner也发布了《云计算安全风险评估》报告。该报告主要从云服务提供商的安全能力角度及其潜在情况或事件下受威胁程度提出云计算环境下的安全风险，主要包括：

（1）特权用户接入:供应商的管理员处理敏感信息的风险；

（2）可审查性:供应商拒绝外部审计和安全认证的风险；

（3）数据位置:数据存储位置未知的隐私风险；

（4）数据隔离:共享资源的多租户数据隔离；

（5）数据恢复:供应商的数据备份和恢复能力；

（6）调查支持:供应商对不恰当或非法行为难以提供取证支持；

（7）长期生存性:服务稳定性、持续性及其迁移。

如果仅从字面上简单理解云计算的安全威胁和安全风险，上面列出的条目在互联网时代的IDC（互联网数据中心）就都已经出现，并且传统的安全模型和防御体系也有较为完善的理论指导和实践方案，在物理层面、系统层面、网络层面、甚至Web应用层面已经有了比较成熟的安全产品。那么是否可以完全照搬这些互联网安全解决方案而直接运用到云计算体系中吗？答案是否定的。下面，我们从云计算安全模型和关键技术等方面进行说明。

3 云计算安全模型介绍

由于当前正处于从传统互联网或者IT应用环境向云计算应用发展的关键时期，统一规划和整体考虑云计算安全离不开云计算安全模型的指导。所谓云计算安全模型，就是从安全管控的角度建立的云计算模型，用以描述不同属性组合的云服务架构，并实现云服务架构到安全架构之间的映射，为风险识别、安全控制和技术实现提供依据。

信息安全领域已经开始着手从不同角度建立云计算安全模型，虽然存在争议，也缺乏大规模实践的验证，但在学术界和产业界的共同推动下，这些来自各方的云计算安全模型正在为云计算应用安全做着有益的探索。

3.1 CSA模型

当前，美国国家标准与技术研究所（NIST，National Institute of Standards and Technology）给出的3种服务模型已经被广泛接受并成为业内的事实规范。这3种服务模式包括：基础设施即服务IaaS(Infrastructure as a Service)模式、平台即服务PaaS（Platform as a Service）模式和软件即服务SaaS（Software as a Service）模式。例如亚马逊公司提供的以亚马逊网络服务（AWS）为框架的服务器、存储、带宽、数据库，以及信息接口的资源服务模式，就是比较典型的IaaS模式；而微软公司的Azure服务平台提供一系列可供开发的操作系统，也看作是一种PaaS服务模式。

根据其所属层次的不同，针对上述3类服务模式，CSA提出了基于基本云服务的层次性及其依赖关系的安全参考模型，如图1所示。该模型主要反映了从云服务模型到安全控制模型的映射。该安全模型的突出特点是提供商所在的等级越低，云计算用户所要自行承担的安全能力和管理职责就越多。进而言之，CSA模型是可以允许用户有条件获取所需安全配置信息以及运行状态信息的，也允许用户部署实施自有专用安全管理软件来保证自己数据的安全。

3.2 企业界模型

在国内，一些大型的IT设备制造企业也不约而同推出云计算整体解决方案以及相关云计算安全服务模型。与CSA模型不同的是，这些云计算安全模型更加偏重于具体的产品解决方案，而没有上升到理论层面。虽然在具体工程中已经有实践应用，但是基本上还是采用传统网络安全技术作为主要的防御力量，在针对云计算应用的响应速度、系统规模等方面的安全要求依旧没有本质上的突破。图1描述了一个简约的、面向工程的云计算安全模型。

3.3 其它模型

我国的一些科研机构也发布了相关的云计算的安全模型。在中科院软件提出的模型中，整个云计算安全技术模型被分为3个部分：云计算用户端安全对象、云计算安全服务体系和云安全标准体系。另外，还有Jericho Forum提出的安全协同模型。它从数据的物理位置、云计算技术和服务的所有关系状态、应用资源和服务时的边界状态、云服务的运行和管理者4个影响安全协同的维度上分类16种可能的云计算形态。

图1 CSA云计算安全模型

当然，还有很多云计算安全模型都在探索和验证当中，但是这些模型都把技术关注点更多地放在用户数据安全与隐私保护；各层次资源的提供者、管理者、使用者的安全防护措施的统一；云计算安全监管体系的建立等方面，这也从另外角度说明了采用传统专一严格为原则搭建的安全模型已经不合时宜了。

图2 国内IT企业云计算安全模型

4 云计算中的关键安全技术

由于在云计算应用场景中，传统的安全威胁，如网络病毒、漏洞入侵、内部泄漏、网络攻击等依旧存在，因此这些安全威胁仍需要使用防病毒软件、入侵检测、4A、抗DDoS等技术或者安全设备去实现对云的保护。而与此同时，云计算的逐步应用正直接或者间接影响信息安全领域的进程，一些新兴的安全技术也在慢慢兴起。下面，我们简单列举一些云计算安全中使用到的一些关键技术。

4.1 主机虚拟化安全

从现在产业趋势来看，由于IaaS服务模式技术相对成熟，因此从IaaS入手整合计算、存储、网络资源，再逐步发展PaaS、SaaS等其它各种云服务能力已经是云计算服务建设的主流思路。而基于虚拟化技术的弹性计算，正是IaaS的基础，因此主机虚拟化安全是IaaS建设方案中需要重点考虑的问题。

在主机虚拟化中，Hypervisor和虚拟机这两个最主要的部分的安全性是最为重要的。

虚拟机管理器Hypervisor是用来运行虚拟机的内核，代替传统操作系统管理着底层物理硬件，是服务器虚拟化的核心环节，其安全性直接关系到上层的虚拟机安全。如果虚拟机管理器的安全机制不健全，被某个恶意虚拟机其漏洞或者某个协议端口获取了高级别的运行等级，就可以比操作系统更高的硬件调配权限，从而给其他客户带来极大的安全隐患。

在IaaS中，一台物理机器往往被划分为多台虚拟机器进行使用。由于同一物理服务器的虚拟机之间可以相互访问，而不需要经过之外的防火墙与交换机等设备，因此虚拟机之间的攻击变得更加容易。如何保证同一物理机上不同虚拟机之间的资源隔离，包括CPU调度、内存虚拟化、VLAN、I/O设备虚拟化之间，是当前IaaS服务模式下首要解决的安全技术问题。

4.2 海量用户的身份认证

在互联网时代的大型数据业务系统中，大量用户的身份认证和接入管理往往采用强制认证方式，例如指纹认证、USB Key认证、动态密码认证等。但是在这种身份认证和管理主要是基于系统自身对于用户身份的不信任作为主要思想而设计的。在云计算时代，因为用户更加关心的云计算提供商是否按照SLA实施双方约定好的访问控制策略，所以在云计算模式下，研究者开始关注如何通过身份认证来保证用户自身资源或者信息数据等不会被提供商或者他人滥用。当前比较可行的解决方案就是引入第三方CA中心，由后者提供为双方所接受的私钥。

4.3 隐私保护与数据安全

用户隐私保护和数据安全主要包括各类信息的物理隔离或者虚拟化环境下的隔离；基于身份的物理或者虚拟安全边界访问控制；数据的异地容灾与备份以及数据恢复；数据的加密传输和加密存贮；剩余信息保护等。在云计算应用中，数据量规模之巨已经远远超出传统大型IDC数据规模，同时不同用户对于隐私和数据安全的敏感度也各不相同。这里，我们主要讲一下用户最常面临和关心的加密传输和加密存储。

在云计算应用环境下，数据传输加密可以选择在链路层、网络层、传输层、甚至应用层等层面实现。主要的技术措施包括IPSec VPN、SSL等VPN技术，保证用户数据在网络传输中机密性、完整性和可用性。对于云存储类服务，一般的提供商都支持对数据进行加密存储，防止数据被他人非法窥探。一般会采用效能较高的对称加密算法，如AES、3DES等国际通用算法，或我国国有商密算法SCB2等。

在云计算中，如网盘等虚拟存储的应用也是非常常见的。在这种情况下，如果只是对退租用户VM磁盘中文件做简单的删除，而下一次将磁盘空间（逻辑卷）重新分配给其他租户时，就可能会被恶意租户使用数据恢复软件读出磁盘数据，而导致先前租户的数据泄漏。因此在进行存储资源回收时，需要使用软件技术对逻辑卷的每一个物理Bit位进行清“零”覆写，保证磁盘空间重新分配给其他租户时不能通过软件方式恢复其原有数据。

4.4 其它一些安全技术措施

当然，在云计算应用环境中，还有其它一些安全技术。例如PaaS服务商提供的开发平台以API方式提供各种编程环境，就可能由于API接口质量和安全没有得到保障而带来平台的平台可靠性、平台可用性、平台完整性等一系列安全问题。目前的技术解决方案有平台升级和Parley—X保护等。再例如SaaS服务模式主要面临安全问题就是软件漏洞，因此主要的解决技术仍然是软件补丁、版本升级等。

科研人员也在不断研究以用户为中心的、而非以云计算提供商为中心的信任模型。一些安全公司也在研发基于客户端的隐私或者用户数据管理工具，帮助用户控制自己的敏感信息在云端的存储和使用。

5 未来与展望

云计算环境的复杂性和高度动态变化性使得云计算安全管理更为复杂。当前，大多数业内专家都赞同传统的信息安全管理标准如ITIL、ISO/IEC 20000、ISO/IEC 27001/27002等仍可以辅助云计算安全管理和云安全控制框架的建立。当然，如何建立以安全目标验证、安全服务等级测评为中心的云计算安全服务标准及其测评体系；如何建立可控的云计算安全监管体系也是需要进一步深入研究的。

现有云计算解决方案呈现封闭化、私有化、定制化的特征，但随着云计算技术无序和爆炸式地发展，云计算安全领域还将面临更多问题。从现有的技术水平分析，既然无法依靠传统立体防御、深度防御的中心思想解决云计算时代的信息安全保障问题，那么依靠云计算自身所特有的规模化、动态化、弹性化、快速部署计算来解决可能才是最终的解决方案。换句话说，把传统“顶盔掼甲”、借助外部力量进行防御向“强身健体”、挖掘自身潜力进行防御的思想转换是解决云计算安全问题的一条可行之路。

[1]冯登国，张敏，张妍，徐震.云计算安全研究[J].软件学报,2011,22(1).

[2]陈龙，肖敏.云计算安全：挑战与策略[J].数字通信，2010,(6).

[3]CSA．Security guidance for critical areas of focus in cloud computing V2．1[EB／OL]．[2010-05—10]．http://www．Cloud security alliance.org／guidance.