在云数据中心中实施等级保护

　　当用户进行云数据中心建设时，如果同时需要参考等级保护的相关要求进行整改，那么用户是否会面对这样的痛苦：云数据中心在引入虚拟化技术后，不同业务的边界延伸到服务器内部，这使得分级分域隔离的等级保护建设思路面临无法落地的尴尬。为此，笔者提出一个简易可行的办法，保障用户在云数据中心中依然可以实施等级保护的分级分域隔离。

　　对于云数据中心，在实施等保的过程中，如何防范安全区域边界环境的攻击往往是难点。有别于传统的攻击方式，由于增加了虚拟化层面的部署，边界受攻击的范围也随之增加。为此，我们必须要考虑三个方向的攻击。

　　一是由外向内的攻击：由外部网络向云数据中心内部发起的攻击；

　　二是由内向外的攻击：由云数据中心向外部网络发起的攻击；

　　三是由内向内的攻击：云数据中心内部同一台物理服务器VM（虚拟机）之间的攻击。

　　对于“由外向内的攻击”和“由内向外的攻击”，采用传统网络环境中网络设备、服务器等物理设备之间较成熟的边界安全控制机制即可实现（这就是常说的云数据中心南北向流量）。

　　但对于“由内向内的攻击”这种特殊的新环境（这就是常说的数据中心东西向流量），由于在云计算环境中同一台物理设备中各VM间的网络通信都是采用虚拟以太网交换技术VEB（Virtual Edge Bridge）在虚拟化平台内部来处理，各VM之间的网络流量不会经过物理网络环境，这就导致在物理网络安全设备上对这部分不可见网络流量的检测、分析和控制措施将完全失效。这样的后果就是在各VM之间可能形成隐蔽信道而被攻击者利用。因此，如何解决VM之间流量可见性问题，是需要探讨的。目前业界面对该问题主要有两类思路。

　　安全设备虚拟化

　　把安全设备虚拟化，部署到虚拟环境中，使其在虚拟平台内部解决流量可视化的问题，在虚拟平台内部做防护。对此，VMware已经有了解决思路，它把对虚拟环境下安全问题的研究方向集中在了其数据中心虚拟化平台VMware vSphere的两个套件上：VMsafe和vShield。

　　VMware VMsafe是一组特殊的应用程序通用接口组件（API），专门构建于VMware ESXi中。利用它可以使合作伙伴或者第三方安全厂商开发相应的虚拟化安全产品（如虚拟化Firewall、虚拟化IDS/IPS等）。这些虚拟化的安全产品直接部署于Hypervisor上的一个具备特殊权限的VM中，该VM可以直接访问Hypervisor中的数据，因此，可用来监视和控制各VM之间接收和发送的网络流量。

　　VMware vShield是为了保护虚拟化数据中心平台VMware vSphere免遭攻击和误用而基于VMsafe API开发的关键安全组件，我们可以理解为保护VM和分析虚拟平台内部网络流量的虚拟化防火墙。安全管理员可以利用vShield各个安全模块部署配置虚拟机环境中的各项安全策略。比如： vShield Zones（虚拟防火墙防护）、vShield APP（VM之间入侵防御、流量分析等应用层防护）、vShield Edge（VM外围网络安全边界防御）、vShield agents（虚拟机扫描终端）等。

　　另外，Xen虚拟化平台也有类似的安全机制，在Xen Hypervisor上有一个具备管理接口的特权VM（Domain 0）。作为Xen Hypervisor的扩展，Domain 0可以直接访问Hypervisor中的数据，同时监视和控制其它VM实例（Domain U）之间的网络流量。

　　但此类方案的缺点在于：安全设备占用服务器的资源，且受制于虚拟操作系统，因此在灵活性上受到很大的制约。

　　虚拟环境内部流量牵引至物理网络

　　如果能把虚拟平台内部的“不可见”流量牵引至物理环境，那么这部分流量对于传统安全防护设备来说就“可见”了，就可以采用传统的安全防护措施处理虚拟平台内部的攻击。而且这样做的好处是安全设备不会占用服务器自身的计算资源，且安全设备有着更高的可扩展性，从而实现更经济、更有效的安全隔离与防护，这种思路在业界也已经有了多种方案。

　　1.vSwitch引流方案

　　在VMware ESX/ESXi环境下，我们也可以使用内置的vSwitch（虚拟交换机）来实现流量牵引。vSwitch是由VMware ESX/ESXi内核提供，是一个虚拟化的交换机，主要用于同一台物理服务器VM之间互联。一个ESX/ESXi环境下可以配置多个vSwitch，每个vSwitch可以使用一块或多块物理服务器的物理网卡，但是一块物理网卡只能对应一个专属的vSwitch。ESX/ESXi部署后会默认安装第一台虚拟交换机vSwitch0，用于虚拟机主控台。

　　利用vSwitch的上述特性，如果为同一个物理服务器上的多个VM分别配置给不同的vSwitch，那么每一个vSwitch之间的通信流量肯定都是相互隔离的。如图2所示，如果一个vSwitch上的VM需要与同一台物理服务器上的另一个vSwitch上VM通信，那么这部分流量就必须经过所对应的物理网卡，从而将流量牵引至物理网络，这样就能使用传统的网络安全防护机制来对VM之间的流量进行监控与防护。

　　2.VEPA引流方案

　　利用vSwitch与物理网卡配合的方式可以牵引出虚拟平台内部不同vSwitch下VM之间流量，那么同一个vSwitch下各VM之间的网络流量如何处理，是否能够牵引出物理网络？这又是一个新问题。

　　目前业界已经有了边缘虚拟桥接EVB（Edge Virtual Bridging）标准，即IEEE 802.1Qbg标准。标准中的虚拟以太端口汇聚器VEPA（Virtual Ethernet Port Aggregator）技术就是解决将VM之间产生的网络流量全部牵引至与服务器外部上联的物理交换机进行处理转发的问题。也就是说在VEPA环境下，虚拟环境内部VM之间网络通信流量不会再采用VEB（可以理解为vSwitch）机制在虚拟化平台内部来处理，而是被强制牵引至服务器物理网卡外部，由网卡上联的VEPA交换机接收并处理后才转发回虚拟平台内部。

　　与vSwitch技术方案类似，VEPA牵引流量的方案采用纯软件方式即可实现。

　　3.VN-Tag引流方案

　　除了VEPA技术之外，思科的私有虚拟化网络控制协议VN-Tag（目前是IEEE 802.1 Qbh）也能够实现将虚拟平台内部VM之间流量牵引至外部物理交换机来处理转发，实现方式主要是在传统以太网帧基础上增加VN-Tag帧头以标识每个VM所绑定的虚拟接口。但是与VEPA技术方案不同的是，VN-Tag技术的实现会受到服务器物理网卡和交换设备硬件支持的制约。

　　山石网科政府行业技术总监 杜旭晖