云计算的安全问题

前文所述,云计算并不能让企业非常放心地去使用它,原因是目前的云计算还有可能存在很多风险。本文仍将通过类比电力系统来说明云计算的各环节中存在的诸问题以及可能的解决方案。

 

前文已经讲过,云计算具备最基本的三个环节:分布计算节点,计算能力集群和再分配的云,计算能力的用户节点。这三个环节中的任意一个出现安全问题,或者任意两个的连接处出现安全问题,都有可能带来整个云的崩溃。由此可见,对于云计算的安全管理问题要远远比企业内部服务器或者是PC的安全管理来的更复杂。

 

首先,对于分布计算节点这个环节,安全管理要相对比较简单,这个环节的安全监管和目前企业内部服务器以及PC的传统意义上的安全监管类似,需要对每个分布计算节点进行普通的安全管理。在这个环节要至少保证分布计算节点被入侵的成功率尽量低。就像发电厂内的工作机组一样,单单一个发电机组不工作,对于社会的供电是不会有影响的。但是每个机组至少要有相应的防火或点检措施,保证大多数发电机都能正常工作。不过值得注意的是,后云计算时代的“终端即计算能力”模式中,分布计算节点可能已经不单单是数据中心里的计算节点,而可能就是一台在使用云的用户终端。那么这样的分布计算节点在我们的安全框架下是很难照顾到的。我们不能要求使用云的用户都在其终端上安装指定的安全模块。所以下一个环节的安全是非常重要的,它负责替分布计算节点做掩护。

 

那么,计算能力集群和再分配的云环节,也就是云计算的核心环节需要哪些安全措施呢。

  1. 首先是数据加密处理,由于云内数据最终运行在分布计算节点上,而前面讲分布计算节点的安全性不是百分百,因此万一有分布计算节点被入侵,被入侵节点内存中的用户数据将完全暴露。真的是一粒老鼠屎坏了一锅汤。所以云计算核心在分配计算任务前,数据需要经过加密。同样,在分布计算节点返回数据时,云计算核心也需要有相应的校验方式来确保数据没有被篡改。
  2. 其次是虚拟化安全性,整合后的资源通过虚拟化重新分配,而虚拟化的hypervisor有保证各虚拟系统/应用互不影响的义务。因此各虚拟系统/应用之间的通信将被划入本安全框架内,以防止某个虚拟系统或应用被破坏后,影响到云支持的其他服务的安全。就像电力系统中的区域性的电力控制能力,可以保证切断某个区域的电力,而不影响其他区域。在这方面,VMware和Citrix和安全供应商(reflex, Altor, Catbird)合作,提供了较为完善的hypervisor安全功能。
  3. 最后是对计算资源的保护,由于云计算核心对分布计算节点有很大的控制能力,而一旦云计算核心,比如任务分配系统,或是虚拟宿主等遭到入侵后,云内计算资源都面临很大的危险。因此需要在本环节加入主动防御功能,比如目前的蜜罐技术,通过设置诱饵来引诱入侵者主动攻击云内某些计算单元,以此避免有效计算单元的损失以及快速找出入侵者。

当然正如电力系统中的供电局一样,他需要负责协调两端电压以及灾害隔离来保证其两端以及自身的安全性。

 

最后,在计算能力的用户节点中,还是有可能面临一些由于云内安全不够或自身安全不够等引起的威胁。(注:这里的计算能力的用户节点不是指服务的最终用户,而是指使用云的那些服务。比如gmail的用户不是计算能力的用户节点,而gmail服务就是计算能力的用户节点了)

  1. 用户节点首先要有威胁隔离能力,这里的隔离是指,当使用同一个云的邻居用户被入侵后,通过该邻居对本用户节点产生的威胁被隔离。假如gmail服务和twitter服务都使用同一个云,当twitter的web服务虚拟主机被入侵后,想要通过twitter的web服务虚拟主机再入侵gmail的数据库虚拟主机的企图不会得逞。
  2. 防御宿主的攻击,宿主机在种种安全措施下虽然很安全,但是万一也被入侵的话,通过虚拟API就可以对用户节点造成很大的伤害。因此用户节点在给宿主机很大控制权的情况下,要保留拒绝管理的能力。当然这样的防御策略比较难制定,但却不可或缺。
  3. 灾害隔离能力,这是指在用户节点被破坏后,要有自动隔离不让本区域的灾害蔓延到其他用户节点,这就有点类似家庭电力系统的保险丝,通过保险丝来防止自家电力问题蔓延到邻居家或整栋建筑物内。

 

总之,云计算给安全领域带来了很多新的挑战,而这些挑战不可能由一家安全厂商或一个安全框架就能解决,因此云计算的安全性问题也给业界带来很多新的机遇。如果云计算在以上三个环节中能够保证高度安全性的话,云计算将会比传统计算具备更高的安全能力。就像电力革命之后的社会电力系统的安全性要远远高于某个企业内部维护的电力系统的安全性。

虚拟化的种类

虚拟化的方式多种多样,耳朵很熟悉的一些名字有:全虚拟化,类虚拟化,硬件虚拟化,混合虚拟化等等。这些不同的虚拟化方式,并不是根据同一个标准来分类的,以下介绍三种主要的分类方法,并相应介绍一些目前主流的虚拟化实现方式,以及对应的产品。

从虚拟平台的角度来划分的话,主要分为全虚拟化和类虚拟化:

  1. 全虚拟化是指VMM虚拟出来的平台是现实中存在的平台,因此对于客户机来说,并不知道自己是运行在虚拟的平台上。正因为此,全虚拟化中的客户机操作系统是不需要做任何修改的。
  2. 类虚拟化是指通过对客户机进行源码级的修改,让客户机可以使用虚拟化的资源。由于需要修改客户机内核,因此类虚拟化一般都会被顺便用来优化I/O,客户机的操作系统通过高度优化的I/O协议,可以和VMM紧密结合达到近似于物理机的速度。

 

对于全虚拟化来说,从虚拟化支持的层次划分,主要分为软件辅助的虚拟化和硬件支持的虚拟化:

  1. 软件辅助的虚拟化是指通过软件的方法,让客户机的特权指令陷入异常,从而触发宿主机进行虚拟化处理。主要使用的技术是优先级压缩和二进制代码翻译。

a)       优先级压缩是指让客户机运行在Ring 1级别,由于处于非特权级别,所以客户机的指令基本上都会触发异常,然后宿主机进行接管。

b)       但是有些指令并不能触发异常,因此就需要二进制代码翻译技术来对客户机中无法触发异常的指令进行转换,使之无法逃出宿主机的控制。

通过软件级的全虚拟化,可以让一台x86的物理机运行64位操作系统。更有胜者,通过IA64机型模拟古老的Mainframe虚拟机,从而把Mainframe机器的系统迁移至新机型中。

  1. 硬件辅助的虚拟化主要是由于在技术层面上用软件手段达到全虚拟化非常麻烦,而且效率较低,才由Intel等处理器厂商直接在芯片上提供了对虚拟化的支持。硬件直接可以对敏感指令进行虚拟化执行。比如Intel的VT-x技术。

 

从实现结构来看,主要分为Hypervisor型虚拟,宿主模型虚拟,混合模型虚拟:

  1. Hypervisor虚拟是指,硬件资源之上没有操作系统,而是直接由VMM作为Hypervisor接管,Hypervisor负责管理所有资源和虚拟环境支持。这种结构的主要问题是,硬件设备多种多样,VMM不可能把每种设备的驱动都一一实现,所以此模型支持有限的设备。目前主要的产品是VMware EX Server,是当前最高端和成熟的虚拟化产品。
  2. 宿主模型,是在硬件资源之上有个普通的操作系统,负责管理硬件设备,然后VMM作为一个应用搭建在宿主OS上负责虚拟环境的支持,在VMM之上再加载客户机。此方式由底层操作系统对设备进行管理,因此VMM完全不用操心实现设备驱动。而它的主要缺点VMM对硬件资源的调用依赖宿主机,因此效率和功能受宿主机影响较大。目前主要产品是VMware Server,Virtual PC/Server。
  3. 混合模型,是综合了以上两种实现模型的虚拟化技术。首先VMM直接管理硬件,但是它会让出一部分对设备的控制权,交给运行在特权虚拟机中的特权操作系统来管理(称之为Domain 0)。VMM和Domain 0合作搭建起虚拟环境,在其上运行客户虚拟机(Domain N)。这个模型还是具有一些缺点,由于在需要特权操作系统提供服务时,就会出现上下文切换,这部分的开销会造成性能的下降。目前主要产品有Windows 2008, Xen。

VMware迎娶SpringSource

8月17日VMware和SpringSource宣布前者收购后者的消息。从SpringSource的CEO Rod Johnson的blog上可以看出,待嫁的新娘SpringSource对于未来的郎君VMware非常满意,并表态说,自己的未来蓝图和夫君的不谋而合,从现在开始翻开人生的第二篇章(Rod在blog上的文章标题哦),一定会在PasS这条路上走出一个美好的未来。虽然SpringSource的娘亲,风投Peter Fenton(这个娘家实力可大了,twitter,JBoss,Xensource都在/曾在他旗下)觉得自家的闺女如果再养个年把,应该能吸引到更多阔少,这次VMware的聘金给的少了点,但是机不可失,过了这个村没这个店,在半推半就的状态下把女儿给嫁了出去。

而VMware方面没有具体的表态。让人不禁暗自猜测此次收购的意图。

首先可以肯定的是VMware准备大张旗鼓做些什么了。种种证据表明VMware已经不甘心在虚拟化和云计算的革新大潮来临之际再继续做一个软件供应商了。VMware提出了PaaS(平台即服务),并具备了vSphere这把利剑,与此同时还顺手从Google签走了几个云和搜索API的大牛,看来VMware可以在平台供应商的舞台上大战身手了。

其次从竞争对手的角度来看,有三个竞争对手促使VMware先下手为强,

  1. RedHat,杀手锏是RHEL+JBOSS+虚拟化。全方位的解决方案,在PaaS中,特别是开源的PaaS领域占有极大优势。可是Mr. VMware和Ms. SpringSource的全新组合有可能改变未来PaaS领域的格局,带来更多创新和商机。SpringSource把之前带给用户的快捷,实用的服务开发和部署能力注入VMware的云技术中,使未来的用户可能在云平台上也能轻松搞定应用的编译,运行和管理。而RedHat如果对应不力的话,在这方面可能完全失去优势。
  2. 微软的Windows7将提供完美的虚拟化方案,而Visual Studio也将提供在云环境下的快速应用部署功能。在此形式下,如果VMware还不提供更接近最终用户的应用部署方案的话,势必会沦落为Windows平台上的一个虚拟软件供应商。而VMware选择了开源的Spring,也正是通过差异化竞争,防止老情人微软的醋意大发。
  3. Google App Engine,最近App Engine的宕机并没有让其fans失望,反而在稳步的走向PaaS的模范之路。VMware在和Google做生意的同时,也学习到了Google的战略思维,在自己不具备开发App Engine的实力时,出手收购了SpringSource。虽然一个搞Java,一个搞Python,看似互不影响。但是挖墙脚的事情总让人不踏实,而谁知道呢,说不定这样的人员流动是在Google的默许之下呢?

最后再看看SpringSource对社区的承诺。几乎每个社区支持的商业化开源软件在换东家时都会向社区承诺其江湖义气。MySQL不也是吗?但是嫁了人的姑娘,即使在郎君允许下可以和以前的哥们情人见面,但是多少多了些限制,跟新郎官的roadmap不符的事情可就千万不能做了。