控制数据流 确保云安全.docVIP

控制数据流 确保云安全 　　云计算特有的虚拟化、多租户与跨域共享等特点给企业信息安全带来了前所未有的挑战，而从数据流的角度来考虑不失为解决云安全的一个方法。 　　云计算是一种基于互联网使用或交付服务的技术或商业模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云计算一经推出，就受到了业界极大推崇，并推出了一系列基于云计算平台的服务。然而在云计算服务中安全问题一直令人担忧，云计算特有的数据和服务外包、虚拟化、多租户和跨域共享等特点，给安全带来了前所未有的挑战。本文在考虑云计算技术、云计算模型与体系架构等方面对云安全的影响之外，从数据流的角度来探讨云计算平台下的安全问题。 　　云平台下数据流向的分类 　　从云平台数据流的方向来看，大致可分为以下几类（如图1所示）。 　　1.外部访问虚拟机实例。外部用户访问虚拟机上发布的业务，流量走向为：互联网进入 - 云平台核心区 - 云平台接入区 - 物理机网卡 - 虚拟机实例。 　　2.虚拟机实例访问外部。由虚拟机访问互联网，流量走向与上一种情况相反，虚拟机实例 - 物理机网卡 - 平台接入区 - 云平台核心区 - 互联网。 　　3.跨物理机的虚拟机实例之间访问。虚拟机实例1-物理机1网卡-接入交换机1-核心交换-接入交换机2-物理机2网卡-虚拟机实例3。 　　4.同一物理机上的各虚拟机实例之间互相访问（隐蔽信道）。流量路线为：物理机1上的虚拟机实例1访问虚拟机实例 2。 　　5.物理机和虚拟机实例之间的访问（虚拟机逃逸）。为物理机和虚拟机实例之间的双向流量，物理机与虚拟机实例互相访问。 　　不同数据流向适用不同防护方法 　　针对外部访问虚拟机实例的情形，此种情况下与传统IDC的防护思路一样，不同之处在于部分串联设备部署方式需要考虑调整。一是因为云平台扁平化是趋势，能少串一个设备是一个设备；二来设备吞吐向来也不是云计算的优势，云平台下数十G的链路串上去也载荷过大，可以考虑旁路部署按需防护。 　　针对虚拟机实例访问外部的情形，通常云平台虚拟机实例用来对外提供服务的情况和案例比较多，较少有主动访问互联网的情况。不过有一种较为常见的场景就是虚拟机被攻击者控制后用作跳板，往外进行大流量的分布式拒绝服务攻击。在这种情形下一方面会消耗服务器的CPU资源，另一方面也会消耗云平台的大量带宽。因此有必要对由内往外的流量进行监测，这里就可以使用NTA，将进行分布式拒绝服务攻击的虚拟机实例路由直接丢弃。 　　针对跨物理机的虚拟机实例之间访问的情形，由于跨物理机的虚拟机实例访问会经过传统的交换机，因此该场景下可采用传统的安全措施来进行防护，如访问控制列表、入侵检测系统、入侵防御系统等。如果没有这类需求，可直接通过划分VLAN的方式隔离。 　　针对同一物理机和虚拟机之间的访问（虚拟机逃逸）的情形，由于Hypervisor存在一些已知的漏洞，这就为攻击者从已控制的虚拟机利用 Hypervisor的漏洞渗透到Hypervisor 提供了可能。虽然利用这种方式的技术难度相对较高，但是由于所有的VM都由Hypervisor来控制（启动、停止、暂停、重启虚拟机，监控和配置虚拟机资源等），因此危害相当大。要解决这个问题必须得修复Hypervisor的漏洞，这一方面依赖于能否发现这些已知漏洞（可采用漏洞扫描工具或渗透测试服务），另一方面依赖于虚拟化厂商提供的补丁。同时，笔者认为可以采用VEPA或者类似VEPA之类的技术，将VM到Hypervisor的双向流量引出到外部的交换机转发，这样就为监测这类攻击提供了可能。 　　同一物理机上的不同虚拟之间互访 　　针对同一物理机上的虚拟机实例之间访问（隐蔽信道）的情形，常见的虚拟化软件缺省采用VEB（即vSwitch）来完成同一个物理机上的虚拟机实例之间通信。由于多数 vSwitch 只进行二层转发，导致虚拟机实例互访流量不可见，固而是云平台下的一大安全隐患。 　　vSwitch的转发过程为：正常情况下，vSwitch处理过程与传统交换机类似，如果从物理网卡收到报文，查询MAC表转发。如果从虚拟机实例收到报文，目的MAC在外部则从物理网卡转发，在内部则查询MAC表转发。 　　目前的思路有两种：一种是通过 vSwitch来解决。vSwitch在二层转发基础上还可实现其他功能，根据VMware公布的资料，至少包括VLAN、安全功能、流量管理、甚至负载均衡等功能，但是由于实现这些功能需要消耗大量服务器的CPU资源，使用效果有待考验。 　　另一种解决办法是采用IEEE标准组织提出的802.1Qbg EVB（边缘虚拟桥技术）和802.1Qbh BPE（桥接口扩展标准技术）两条标准。这里主要探讨应用范围更广的802.1Qbg EVB，其包含了传统的