东西向流量的安全检测和防护，在云安全体系中占据了重要的位置，如何有效的进行东西向流量的防护，成为了云安全研究的重要内容。本文从网络层面，详细总结了在对东西向流量进行防护时的多种流量牵引方法，并且结合业界一些主流的方案进行对比分析。
什么是东西向流量
通常在数据中心中，我们将其网络流量分为两种类型，一种是数据中心外部用户和内部服务器之间交互的流量，这样的流量称作南北向流量或者纵向流量；另外一种就是数据中心内部服务器之间交互的流量，也叫东西向流量或者横向流量。
早期数据中心的流量，80%为南北向流量，现在已经转变成80%为东西向流量。数据中心网络流量由“南北”为主转变为“东西”为主，主要是随着云计算的到来，越来越丰富的业务对数据中心的流量模型产生了巨大的冲击，如搜索、并行计算等业务，需要大量的服务器组成集群系统，协同完成工作，这导致服务器之间的流量变得非常大。
伴随着这种由业务引发的流量特性的变化，数据中心的网络架构也由典型的三层树型结构，转变为CLOS或者Spine-Leaf等大二层结构。这种大二层概念甚至不再局限于一个数据中心内部，而在数据中心之间也是逻辑上二层互通。
本文中我们谈到的东西向流量，更多的是指云计算系统内部的流量，也就是云中虚拟机之间通信的流量。这种流量既包括同一租户、同一子网内虚拟机之间的流量；也包括同一租户，不同子网间的流量；当然还可能是不同租户之间的通信流量。这里的云计算系统主要是指私有云，对于公有云，在原理上都是一样的。
为什么要进行东西向的流量牵引
这里提到的对东西向流量进行牵引，主要是解决云安全的问题。正如前文所描述的那样，云计算的数据中心，80%的流量为东西向流量，而传统的安全解决方案，通常是基于固定物理边界的安全防护，那么对应到云计算数据中心，也就是只解决了南北向流量的安全防护问题，对于东西向流量的安全防护，基本上是无能为力的。
这种无能为力可以概括为两个方面：一方面是“看不到”，比如同一宿主机内的两台虚拟机之间的流量；另一方面是“不认识”，比如封装了vxlan等隧道包头的数据流量。具体可参考“基于SDN/NFV的云安全实践”一文。
面对这个问题，当前厂商主要存在两种解决思路，一种就是把安全设备“放进去”，也就是将传统的“安全设备盒子”进行虚拟化，部署到云计算系统内部，这样就能够“触摸到”并且能够进行相应的安全防护；另一种思路就是把流量“引出来”，将需要检测和防护的流量，从云计算系统中牵引出来，经过相应安全设备的“清洗”之后，再将流量回注到业务系统之中。具体可参考《云来了，安全盒子怎么办？》一文。
无论是采用上述哪种方案进行东西向流量的安全防护，都不可避免的需要对业务流量进行牵引调度，使相应的流量通过对应的防护设备。这样的话，东西向流量的安全防护问题就从安全设备无法“看见”、无法“认识”流量，转化为如何动态高效的对东西向流量进行牵引调度。
据笔者的了解，现在国内主流安全厂商的东西向安全方案，均是通过这种流量牵引的方式实现安全防护。
流量牵引痛点
对于云计算IaaS层面的服务，其核心主要是提供相应的计算、存储、网络资源。对比这三大主要部分，计算和存储资源的虚拟化技术已经相对比较成熟和完善，但是网络的虚拟化相对来讲比较滞后。
因此，各云服务商（Cloud Service Provider，CSP）也就根据各自的特点，推出了多种不同类型的网络方案。比如VMware通常会使用虚拟交换机的原生模式，也有使用NSX的SDN方案。基于OpenStack的一些传统CSP可能会使用网络虚拟化的Neutron组件，激进一些的CSP甚至可能会使用DragonFlow、OpenDove等与Neutron集成的SDN方案。还有一些厂商会引入第三方独立的网络虚拟化和SDN方案。说的夸张一些，甚至可以说有多少家CSP，可能就有多少种虚拟化的网络方案。
而无论是云服务商，还是第三方独立的虚拟化网络厂商，在对其标准产品的云网络进行设计的时候，通常仅仅考虑到相应的业务需求，几乎很少有对安全产品如何接入进行设计。
我们再从用户的角度来看，通常用户在将其业务进行虚拟化上云的时候，第一步往往考虑的仅是其业务系统虚拟化，很少考虑安全问题，尤其是早期建设的一些私有云，基本上没有任何安全方面的设计，甚至网络的配置很多还都没有实现自动化。
那么对于这样的私有云如果要进行东西向流量的安全防护，实现东西向流量的牵引，必然会牵扯到对其现有网络方案的改动，那么假如碰巧网络方案又是第三方厂商提供的，那么就出现了云服务商、网络厂商、安全厂商共同来重构这个云网络，因此“三个和尚没水喝”的故事基本上很容易上演。
如何进行流量牵引
痛点归痛点，虽然东西向的流量牵引调度确实存在各种各样的难题，但是其安全防护也是无法逃避的，那么在标准化的方式出来之前（相信随着技术的发展，会有一种标准化的方式提出），各家厂商也根据各自的特点，相继提出了多种的流量牵引方案。
下面本文就结合业界主流的方案以及绿盟在东西向安全防护的经验积累，详细介绍几种流量牵引方案。
SDN引流
软件定义网络提出了一种将控制平面和数据平面分离的网络架构，在云计算环境中，SDN也越来越多的得到部署应用，比如典型的开源组合方案OpenStack+OpenDaylight。传统的通信/网络厂商，比如Nokia、Juniper等也推出了自己的一整套云计算网络SDN方案，SDN初创公司也有类似的全套方案，比如BigSwitch的BCF（Big Cloud Fabric）以及云杉网络的DeepFlow。
SDN逻辑上集中的控制器，有着全局的网络视图以及相应的流量信息，那么对于云内需要进行检测和防护的流量，可以通过SDN控制器自动化的进行流表项的下发，完成流量的牵引。
下面将以Nokia Nuage的SDN方案进行详细描述。下图中的VRS、VSC和VSD共同组成了其云网络的数据平面和控制平面，其中VRS是虚拟交换机，宿主机上的所有虚拟机全部挂在这个虚拟交换机上，宿主机之间的overlay网络则是通过vxlan实现，VSC和VSD组成了其整个网络的控制平面。
当需要对VM1和VM2之间的流量进行检测和防护时，用户可以在NCSS（NSFOCUS Cloud Security System）的安全控制平台发出防护请求，NCSS根据防护请求，将对应的流量牵引命令发送给VSC，VSC根据这个流量牵引请求，下发相应的流表项并进行流量牵引的配置，图示的流量牵引是通过GRE隧道实现的。这样就完成了东西向流量的牵引工作。
Nokia Nuage这种基于SDN的东西向流量牵引方案已经在中国移动北方基地、南方基地、集团公有云等项目部署运行，同时在中国电信和中国联通也有不同程度的落地应用。
下图是国内的SDN初创公司云杉网络推出的基于SDN的东西向流量防护方案，方案同样是基于SDN网络架构，通过SDN控制器的全网控制能力，实现流量监控以及流量牵引调度，结合绿盟等第三方安全厂商的专用安全设备，实现深度的安全监测和防护。由于方案在原理上存在相似之处，这里就不再展开介绍了。
API接口引流
API接口引流主要是指通过调用云计算系统的标准引流API，实现东西向流量的牵引调度。它和基于SDN引流的不同之处在于，基于SDN的网络厂商在为云计算系统提供网络设计和规划时，通常其标准方案和接口里，是不包含这种为了安全防护而存在的引流API的。那么如果要在SDN网络里实现通过API接口自动的进行流量牵引，需要SDN网络厂商与安全厂商进行一定程度的适配开发，从而实现整个引流过程的自动化。
这里的API接口引流，通常是通过云服务商提供的标准引流API实现的，典型的就是VMware提供的引流接口。云安全平台通过与Vmware的引流接口进行适配，实现整个东西向流量的牵引防护自动化。当然这种自动化的引流在VMware中典型的实现也是基于其SDN控制器NSX的。
当然，如果其VMware云平台不包括NSX，也可以通过手动配置实现对东西向流量向安全资源池的牵引调度，具体可以参考 硬件盒子在云中获取网络流量的方法
代理引流
对于云网络为非SDN网络的情况，如何实现东西向流量的牵引调度。这里主要介绍本节的代理引流和下节的微代理引流两种方式。
代理引流，顾名思义就是在云计算系统中，添加一个引流的代理，当然也有将其称作引流引擎、或者引流平台，其实实现的功能都是一样的。对于SDN网络中SDN控制器所做的相关引流操作，在这里完全由这个代理来实现。
安全控制平台将相应的引流请求发送至这个引流代理，引流代理根据虚拟机所在宿主机的位置以及虚拟机当前的网络情况，下发相应的引流指令，并且完成对应的网络配置，实现流量牵引。
这种引流方式，从原理来看，很容易理解。但是在实现上，也存在着很大的难度。因为引流代理在进行引流操作时，需要对云计算系统有着深入的理解和操作权限，这样每种代理对于云计算平台的耦合度就比较高，可移植性和可复制性比较差。
这种引流代理主要是为了实现东西向流量的安全防护而部署的，那么这个代理通常由安全厂商来提供，而代理所做的工作却是要对云计算系统的网络进行更改和操作，因此需要安全厂商和网络厂商有着紧密的合作才能够完成准确高效的流量牵引工作。
微代理引流
微代理和代理的区别主要体现在，代理是部署在计算节点的宿主机上，通过改变虚拟网络的相关配置，进而完成对应流量的牵引调度。微代理则是像传统的终端安全软件一样，部署在虚拟机内部，那么这个微代理就可以在虚拟机的网络协议栈或者网卡等层面对数据包进行修改或者标记，完成流量牵引的工作。代表性的厂商比如Kingsoft、Fortinet。
这种方式的优点在于，一方面不会对云计算系统的虚拟化网络做适配和修改，就可以完成流量牵引；另一方面，可以充分利用虚拟机的计算能力，无需额外增加安全相关的虚拟机投入。
这种方式，需要在客户的虚拟机内安装代理，那么会存在相应的信任问题，如果客户的数据比较敏感或者秘密等级比较高，通常不太会选择接受这样的方案。
总结
对于云计算中的东西向流量，引流防护已经成为了一种趋势，那么究竟该如何进行流量牵引，是一个难题。本文主要介绍了几种常见的引流方式和厂商的方案。
从本文的介绍可以看出，厂商在选择方案时，根据各自的技术积累和产品特性，会有不同的倾向性。比如云服务商，它可以决定整个云计算系统的设计，通常会选择API引流支持；对于网络厂商，它的优势在于有着云网络的设计和控制权，因此通常会选择SDN引流的支持；对于传统的杀毒厂商，它的技术积累主要存在于终端设备，那么它的方案可能会更倾向于微代理的方式。
比较尴尬的就是传统的安全厂商，所以安全厂商的方案通常是既支持SDN方式的引流，同时也可以做API引流的适配，如果云网络不是SDN的话，也可以通过代理或者微代理的方式。总结起来就是，既然安全厂商没有云计算系统的控制权，那么就会低姿态的进行多种支持和适配，凭借其专业的安全检测和防护优势，为云上的东西向流量提供安全保障。