从数据流的走向看云安全问题如何解决

 以往大家更多是从云计算技术、云计算模型\体系架构等方面来对云安全进行研究和探讨，本文将从另外一个角度——从数据流的走向来探讨一下云计算，尤其是云计算平台下的安全问题。

为达日等地区用户提供了全套网页设计制作服务，及达日网站建设行业解决方案。主营业务为成都网站设计、成都网站制作、达日网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

一. 云平台下数据流向的大致分类

从云平台数据流的方向来看，大致可分为以下几类：

[[137708]]

图1 云平台下数据流的大致分类

外部访问虚拟机

外部用户访问虚拟机上承载的业务，流量由互联网进入——核心——接入——物理机网卡——虚拟机。

虚拟机访问外部

由虚拟机访问互联网，流量方向与上一种情况刚好相反，虚拟机——物理机网卡——接入——核心——互联网。

跨物理机的虚拟机之间访问

VM 1——物理机1网卡——接入交换机1——核心交换机(可有可无)——接入交换机2——物理机2网卡——VM 3。

同一物理机上的各虚拟机之间互相访问(隐蔽信道)

物理机1上的VM 1访问VM 2。

物理机和虚拟机之间的访问(虚拟机逃逸)

物理机和虚拟机之间的双向流量，物理机与VM相互访问。

#p#

二. 从数据流向分类看云安全

外部访问虚拟机

此种情况下与传统IDC的防护思路一样，就不详述了，只是部分串联设备部署方式需要考虑调整。一是因为云平台扁平化是趋势，能少串一个设备是一个设备，二来设备吞吐向来也不是安全设备的优势，云平台下动则10G、40G的链路串上去也吃不消，所以可以考虑旁路部署，按需防护。

虚拟机访问外部

通常云平台虚拟机用来对外提供服务比较多，较少有主动访问互联网的需求。不过有一种较为常见的场景就是虚拟机被攻击者控制后用作跳板，往外进行大流量的 ddos攻击。这种情形下一方面会消耗服务器的CPU资源，另一方面也会消耗云平台的大量带宽。因此有必要对由内往外的流量进行监测，这里就可以使用 NTA(网络流量分析系统)，一旦发现由内往外的DDoS攻击则可以将进行攻击的源IP路由直接丢弃，中断该IP的对外访问。

跨物理机的虚拟机之间访问

由于跨物理机的虚拟机访问会经过传统的交换机，因此该场景下可采用传统的安全措施来进行防护，如ACL、IDS等;如果没有这类需求，可直接通过VLAN划分的方式隔离。

同一物理机上的虚拟机之间访问(隐蔽信道)

常见的虚拟化软件缺省采用软件VEB(又称vSwitch)来完成同一个物理机上的虚拟机之间通讯，由于多数vSwitch只进行二层转发，导致VM互访流量不可见，是云平台下的一大安全问题。

先说说vSwitch的转发过程，正常情况下，VSwitch处理过程与传统交换机类似，如果从物理网卡收到报文后，查MAC表转发;如果从虚拟机收到报文，目的MAC在外部则从物理网卡转发，在内部则查MAC表转发，如下图所示：

[[137709]]

图2 vSwitch转发

目前的思路有两种，一种是通过vSwitch来解决。vSwitch在二层转发基础上还可实现其它功能，从VMware的介绍来看至少包括VLAN、安全功能、流量管理、甚至负载均衡等功能，但是由于其实现这些功能需要消耗服务器大量的CPU资源，使用效果如何还有待考验。

另一种解决办法是采用IEEE标准组织提出的802.1Qbg EVB(Edge Virtual Bridging)和802.1Qbh BPE(Bridge Port Extension)两条标准，这两条标准可以将虚拟机内部的流量引出到虚拟机外部，这样就可以采用传统的安全防护手段来解决隐蔽信道下的安全问题。这里主要探讨一下应用范围更广的802.1Qbg EVB，其包含了传统的vSwitch功能的VEB模式、VEPA(Virtual Ethernet Port Aggregator)和Multi-Channel。VEB上面已经说过了，简单说下另外两种处理方式。

一种是VEPA。VEPA组件从VM1接收到数据后，先转发到物理网卡，物理网卡不管三七二十一先转发出去到接入交换机，再由接入交换机根据MAC表原端口转回，VEPA收到从接入交换机来的报文才查表进行内部转发，最终数据到达VM2和VM3，如下图所示：

[[137710]]

图3 VEPA转发

通过这种方式可以将所有VM之间的交互数据通过接入交换机上进行转发，因此可以在交换机上实施访问控制策略，隔离不相关的业务，对流量进行分析实现入侵检测和审计等功能。

#p#

另一种是通道技术(Multichannel Technology)，多通道技术方案将交换机端口或网卡划分为多个逻辑通道，并且各通道间逻辑隔离。每个逻辑通道可由用户根据需要定义成VEB、 VEPA或Dircetor IO(基于网卡SR-IOV技术实现的硬件VEB技术，减小了CPU的开销，但是与软件VEB存在相同的问题)的任何一种。每个逻辑通道作为一个独立的到外部网络的通道进行处理。多通道技术借用了802.1ad S-TAG(Q-IN-Q)标准，通过一个附加的S-TAG和VLAN-ID来区分网卡或交换机端口上划分的不同逻辑通道。如下图所示，多个VEB或 VEPA共享同一个物理网卡。

[[137711]]

图4 多通道转发

因此从理论上来说，虚拟机之间可以套用安全域划分的概念，依靠多通道技术进行合理的虚拟安全域划分，同一个虚拟安全域内采用VEB技术，域内虚拟机互访不受限制，保证了足够的交换性能;虚拟安全域之间采用VEPA技术，将流量引到交换机上，部署访问控制与流量监控策略等;对于单独的安全域，尤其是独立业务的虚拟机，采用Dircetor IO，与其它虚拟机流量隔离，直接转发到外部，在外部交换机上监控其流量。

同一物理机和虚拟机之间的访问(虚拟机逃逸)

由于Hypervisor(Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享一套基础物理硬件，也可以看作是虚拟环境中的”元”操作系统)存在一些已知的漏洞，这就为攻击者从已控制的虚拟机利用Hypervisor的漏洞渗透到Hypervisor提供了可能。虽然利用这种方式的技术难度相对较高，但是由于所有的VM都由Hypervisor来控制(启动、停止、暂停、重启虚拟机;监控和配置虚拟机资源等)，因此危害相当大。要解决这个问题必须得修复Hypervisor的漏洞，一方面依赖于能否发现这些已知漏洞(可采用具备虚拟化检测能力的漏扫工具或专业的渗透测试服务)，另一方面依靠于VM厂商是否能够及时提供补丁。同时个人猜想是否可以采用VEPA(从能查到的资料来看都是VEPA如何解决VM之间的流量问题的)或者类似VEPA之类的技术，将VM到Hypervisor的双向流量引出到外部的交换机转发一下，这样就为监测这类攻击提供了可能。

三. 小结

总的来说，本文简单地从数据流的走向来探讨了一下云计算，尤其是云计算平台下的安全问题和解决思路，对于云计算平台下的安全问题除了云计算技术引发的特定的安全问题外(隐蔽信道、虚拟机逃逸、虚拟化漏洞等)，其它的安全问题基本都可以用传统的思路来解决。

名称栏目：从数据流的走向看云安全问题如何解决
网站网址：http://www.shufengxianlan.com/qtweb/news14/529664.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联