虚拟化环境下的安全防护

虚拟化环境下的安全防护

数据中心里的虚拟机（VM）越来越多，VM之间流量交换的安全风险开始成为管理员的新麻烦。继上期阐述安全产品与安全管理平台的变化后，本期聚焦云时代虚拟化环境下对安全的需求以及相应技术方案的发展。

一、云计算时代虚拟化环境下的安全需求

虚拟化是目前云计算最为重要的技术支撑，需要整个虚拟化环境中的存储、计算及网络安全等资源的支持。在这个方面，基于服务器的虚拟化技术走在了前面，已开始广泛的部署应用。基于该虚拟化环境，系统的安全威胁和防护要求也产生了新的变化：传统风险依旧，防护对象扩大

一方面，一些安全风险并没有因为虚拟化的产生而规避。尽管单个物理服务器可以划分成多个虚拟机，但是针对每个虚拟机，其业务承载和服务提供和原有的单台服务器基本相同，因此传统模型下的服务器所面临的问题虚拟机也同样会遇到，诸如对业务系统的访问安全、不同业务系统之间的安全隔离、服务器或虚拟机的操作系统和应用程序的漏洞攻击、业务系统的病毒防护等；另一方面，服务器虚拟化的出现，扩大了需要防护的对象范围，如IPS入侵防御系统就需要考虑以Hypervisor和vCenter为代表的特殊虚拟化软件，由于其本身所处的特殊位置和在整个系统中的重要性，任何安全漏洞被利用，都将可能导致整个虚拟化环境的全部服务器的配置混乱或业务中断。

VM之间产生新安全访问风险

和传统的安全防护不同，虚拟机环境下同一个服务器上不同的VM可能属于同一个物理VLAN内，如果相邻VM之间的流量交换不通过外部交换机，而是基于服务器内部的虚拟交换网络解决，此时在不可控的情况下，网络管理员将面临两个新的安全问题（）：

1）如何判断VM之间的二层流量交换是规则允许范围内的合法访问还是非法访问？

2）更进一步，即使不同VM之间的流量允许交换，如何判断这些流量是否存在诸如针对应用层安全漏洞的网络攻击行为？

图1 VM虚拟机之间的安全风险

二、虚拟化环境下安全防护的方法

在利用现有的经验模型解决好当前存在的普遍性安全威胁后，现阶段虚拟化环境下的安全防护还需要重点考虑VM之间的流量安全。分析流量的转发路径，我们可以将用户流量划分成纵向流量和横向流量两个维度，并基于每个维度的安全需求提供有针对性的解决方案。

1.纵向流量的安全防护

这部分纵向流量包括从客户端到服务器侧的正常流量访问请求，以及不同VM之间的三层转发的流量。这些流量的共同特点是其交换必然经过外置的硬件安全防护层，我们也称之为纵向流量控制层，流量模型。

图2 纵向流量模型的主要内容

一方面，这些流量的防护方式，和传统的数据中心的安全防护相比没有本质区别，用户可以直接借鉴原有经验进行。如防护的设备类型仍然是以防火墙和入侵防御系统等产品为主，在部署的方式上要求防火墙或入侵防御设备具备INLINE阻断安全攻击的能力，部署的位置可以旁挂在汇聚层或者是串接在核心层和汇聚层之间，同时对于设备的性能可扩展和稳定性等常规指标也完全适用。。

另一方面，在虚拟化环境下的云安全部署，因为可能存在多租户*的服务模型，因此对于设备的虚拟化实现程度又有了更高的要求，除了常规的虚拟化实例进行转发隔离和安全策略独立配置外，还要求实现对于不同租户的独立的资源管理配置和策略管理.每个虚拟实例的管理员可以随时监控、调整本租户的策略的配置实现情况等。这些新的技术要求，对于虚拟化环境下的纵向流量防护有着重要的影响。

2. 横向流量安全防护

VM之间的横向流量安全是在虚拟化环境下产生的特有问题，在这种情况下，同一个服务器的不同VM之间的流量将直接在服务器内部实现交换，导致外层网络安全管理员无法对这些流量进行监控或者实施各种高级安全策略如防火墙规则或者入侵防御规则。图4展示了横向安全防护重点关注的流量模型。

在服务器的虚拟化过程中，以VMware为代表的虚拟化厂商，通过在服务器Hypervisor层集成vSwitch虚拟交换机特性，也可以实现一些基本的访问允许或拒绝规则，但是并没有也很难集成更高级的安全检测防护引擎，以实现VM之间的流量漏洞攻击的行为检测。要做到更深度的安全检测，目前主要有两种技术方式：基于虚拟机的安全服务模型，以及利用EVB技术实现流量重定向的安全检测模型，。

基于虚拟机的安全防护

在虚拟化技术推进的过程中，一些厂商很敏锐的观察到了VM之间直接交换流量无法通过外部防火墙等设备进行检测，因此想通过直接在服务器内部部署虚拟机安全软件，通过对VMware 开放的API接口的利用，将所有VM之间的流量交换在进入到vSwitch之前，先引入到虚拟机安全软件进行检查。此时可以根据需求将不同的VM划分到不同的安全域，并配置各种安全域间隔离和互访的策略。同时，一些技术能力强的软件厂商，还考虑在软件中集成IPS深度报文检测技术，判断VM之间的流量交换是否存在漏洞攻击。这种方式的优点是部署比较简单，只需要在服务器上开辟资源并运行虚拟机软件运行即可，但是其不足之处也很明显：

不足一：每个服务器需要有专门的资源来安装该软件，服务器流量越大，开启的功能如IPS 深度检测越多，对系统的资源占用就越大，不仅可能影响其它VM的性能，同时也导致服务器投资的增加；以常见的酷睿2双核双CPU服务器【4核】为例，虚拟化情况下服务器的CPU 利用率得到有效提升，对外可以提供的应用吞吐量有望达到800Mbps以上；同时根据现有的经验，基于双核CPU处理器的IPS应用其吞吐量维持在300Mbps左右；可以预见：如果利用该服务器进行虚拟化划分并使能安全虚拟机软件的话，至少需要划分出2个核来做安全虚拟机，才可以保证对300M的流量进行深度报文检测，而真正的应用虚拟机将只能利用剩余的2个核，这也意味着整个服务器的吞吐量将下降到300Mbps左右；要达到原定的应用交付性能，用户必须部署更多的服务器才能满足要求。

不足二：由于该防护模型需要安全软件厂商在Hypervisor层进行代码开发，其开发水平的差异将导致Hypervisor出现潜在的安全漏洞，并危及到整个虚拟机的正常运转。可以预见虚拟化厂商将不可能完全开放该API接口，这也意味着只有很少的厂商才能获得虚拟化厂商的许可并进行严格受控的软件集成；目前我们并没有看到具有影响力的安全厂商的成熟的虚拟化产品，整个生态系统未来如何发展将取决于虚拟机厂商对于API的开放程度以及安全软件厂商的成熟的开发能力，这些都存在很大的不确定性。

既然VM之间的流量交换一直在服务器内部，不利于安全策略的部署，也不利于管理界限的明晰，因此正在进行标准化EVB技术，计划通过VEPA等技术实现将这些流量引入到外部的交换