近两年，云计算发展迅猛，新建的IDC如政务云，行业云，绝大部分都是云机房。云计算是大势所趋已经毫无疑问，已开始遍地开花。
云带来的安全挑战
关于云环境下如何做网络安全防护，常听见一种观点：云是颠覆性的，传统硬件安全设备完全不适用云环境。
那么，云来了，安全盒子到底该怎么办？
从本质上来说，对于网络安全设备，云带来的最直接挑战有两个：
- 主机虚拟化
- 网络虚拟化
云主机虚拟化带来的挑战
传统机房里面，每个租户的服务器是看得见摸得着的。在云环境下，租户的服务器变为了一个个运行在硬件服务器上的虚拟机，一个租户的虚拟机，可以位于不同的硬件服务器上，这是形态的变化，会引起租户的边界，从传统物理边界，变为动态、虚拟的逻辑的边界。
另外，因为一些历史原因会出现软硬件资源混合的情况。某些服务器不方便虚拟化，如历史遗留的数据库服务器，就需要和虚拟资源一起组成租户的计算资产。
最后，不同虚拟化厂家，如vmware，citrix，Hawei，H3C，各家的hipervisor系统不兼容，也会给安全厂商带来适配的工作量。安全厂家如果要以虚拟的形态运行在虚拟环境里面，需要适配不同平台的虚拟机格式。
因此，传统安全硬件要继续发挥作用，首先就要能够识别和保护虚拟的资产域，并且以动态的方式，切入到虚拟计算环境里面去。
另外，现在的运营商也不喜欢硬件盒子了。毕竟专用的盒子，利用率低，又互不兼容，运营商希望用通用的X86服务器来运行虚拟的安全设备，类似NFV，来提升经济性，可扩展性，以及适应业务快速可变的要求。
网络虚拟化带来的挑战
如果按照vmware 1999年发布VMware WorkStation算起, OS虚拟化的发展时间已经不短了。但是，仅仅是服务器形态的虚拟化，还不足以支持云的发展。在云环境下，要满足云的虚拟性、动态性，还需要将网络也虚拟化。
第一个问题是传统vlan的4K问题。传统vlan因为tag字段位数限制，只能支持最多4k个vlan。但是在云环境下，租户的数量非常多，4K上限是不能满足租户数量的要求的。基于这个目的，扩展vlan tag字段位数，重新对ip报文做wrap，以便于支持更多的租户容量，采用类似vxlan这种方式来划分网络是主流方式。对传统安全盒子来说，首要问题就是能识别vxlan报文。另外vxlan带来的不仅仅是报文tag改变这一点点内容，vxlan带来的相关的网络控制方式改变，调度，如服务链、SDN等等，也都是安全盒子需要去适应的。
另外，云环境下业务动态变化非常频繁，靠传统硬件去动态开通或者销毁一个业务，显然是不行的。之前大家只知道需要把服务器虚拟化，后来随着云虚拟机数量规模的扩大，大家逐渐意识到光服务器虚拟化还不够，需要把网络部分也虚拟化，软件化，并自动化。举个例子：某租户需要开通一个业务需要一台路由器，过一段时间又不需要了，硬件路由器可以满足这样的频繁变化吗？硬件盒子，必须要也可以动态灵活的部署进去才行啊。
再加上云环境为了满足虚机动态迁移，需要在一个大二层，传统二层设备没办法支持这么巨大的mac表项，这一块也需要新的二层技术，如vxlan的支持。传统网络显然不行的。
还有，租户都有自己的vpc，IP地址范围很可能是重叠的。传统硬件设备大部分是不支持这个的，大部分不具备硬件设备虚拟为多个硬件设备的功能的。租户是逻辑的、虚拟的，是接在“逻辑交换机”上的。逻辑交换机本身就不位于任何一个固定位置，是通过计算机节点overlay的方式，分布式部署的。因此，对多租户的安全检测能力，是传统安全盒子不具备的，这显然无法适应云安全的要求。
最后，SDN控制网络，控制和转发平面分离，也使得云环境的网络和传统网络大大不一样。传统盒子如何接入如何适配新的网络架构，这个也是需要有一个重大改变的。之前安全盒子通过策略路由、桥接、分光镜像等方式接入网络做安全检测的方式，在SDN网络架构下已经不能适用了。传统安全盒子，需要按照新型网络的控制方式，来接入业务流量。否则，就完全不能发挥作用。
总结
上述挑战，传统安全盒子通过交换机、路由器、分光器等物理方式接入租户网络的方式，在云环境下就失效了。要继续发挥作用，传统硬件必须要解决在云环境下的接入问题，要做到看得见、认得出、防的住，才行。
除了接入问题，安全盒子还需要适应云的弹性。硬件固定性能的盒子不容易弹性扩展，在云里面，安全也要像计算资源一样，可以动态的、弹性的扩展。
总的来说，云是利用资源的新的方式，安全本质并没有发生变化。但是，安全发挥作用的方式，需要根据云的变化而调整，才能继续有效。
什么是东西向流量
凡提到云防护，必然会听见“东西向防护”这个词。那么，什么是东西向流量？
下面这幅图，是传统IDC的流量走向：
可以看到，大部分业务流量，都是从外到内为主，安全防护设备，也集中在由外到内的防护路径上，我们称之为“南北向”防护。
IDC云化以后，服务器的规模，包括虚拟机的数量，都扩大了很多。横向的虚机密度大大增加，也因此衍生出租户和各种复杂的网络虚拟设备，如下图：
传统IDC的安全问题，主要集中在①这个位置。云化以后，流量问题复杂化了，衍生出②、③、④、⑤这几个新的情况，防护也因此而有所不同。
在云网络内部，租户之间是隔离的，互相访问要通过vpn或者隧道访问。租户内部可以划分不同的子网，子网之间，子网内部虚拟机之间，虚拟到外部，外部到虚拟机，都会产生访问流量，安全问题也由此而生。
重要的是，这些流量往往产生在云内部，甚至不出服务器（如同一服务器内部虚机之间的流量）。因此这些流量，对传统硬件盒子不可见，从而也无法防护。这些流量，会成为一个真空地带，一旦发生安全问题，如虚机中木马或者病毒，将会迅速在云内部蔓延，并难以进行防护控制。这种情况是非常可怕的。根据《云等保增补方案》同等防护的原则，云内部流量也需要进行同等安全强度的防护，防护缺失是无法接受的。
综上，南北向流量，主要是指外部公网进出云计算内部的流量。东西向流量，主要是指租户内部虚拟机的访问所产生的流量。注意，东西向流量在这里是泛指租户相关的流量，并不仅仅是从外到内的流量。如果外部流量访问虚拟机，需要按照不同租户的策略来防护，此刻也称之为“东西向”。
南北向防护，传统方案都可以继续有效。而东西向防护，是云化后的机房新增加的需求。本文后面的讨论，主要集中在东西向防护方案。
现有东西向防护方案
凡是解决方案，出发点都是根据安全厂商自身情况优先考虑。同样的，对客户而言，“反厂商绑架”也是自然的诉求。
虚拟OS厂商的方案
虚拟OS厂商，指的是虚拟系统厂家。这类厂家因为掌握了虚拟操作系统，所以自然考虑从虚拟系统本身入手来构建安全方案。通用的示意图如下：
虚拟操作系统厂家，通过在虚拟系统网卡之上增加驱动过滤层，将虚拟机的流量截获，将流量导向系统内置安全模块，或第三方的安全虚拟机，进行安全防护。
从上图可以看出，对内部流量的防护，利用了计算节点本身的计算能力进行，流量在出计算节点之前，就得到了有效的防护。
这种方式有他的优缺点。优点是，在靠近虚拟机的位置进行防护，能够在最短路径上防护，同时流量不出计算节点，不会对云内部骨干网络，造成额外的流量负担。另外随着虚拟OS的部署，安全能力随之部署，在部署上也会比较便利。
缺点也很明显，首先是第三方安全厂商必须获取虚拟OS的防护API授权，才能引入自己的安全虚机，如vmware的nsx认证。对于虚拟OS厂商来说，自然不愿意第三方碰自己的蛋糕。比如vmware的NSX模块，终端用户须付费购买，第三方安全厂商须通过商业认证。只有同时满足这两个条件，用户才可以用到想要的安全厂商的安全能力。
另外一个缺点是安全模块和安全虚机运行在计算节点，会占用计算资源。对于计算资源紧缺型的用户，或许无法接受。同时安全能力和计算能力混合在一起，出现问题的时候，排查责任也会有较高的复杂度，互相依赖交叉的情况，会对虚拟OS厂商和安全厂商造成同时困扰。
最后一个缺点，是安全虚机厂商多样性也会有问题。不同厂家的安全虚机，要同时出现在同一个计算节点上，技术上会有很大的问题。从客户长远利益考虑，客户需要一个比较好的，兼容各个安全厂商的安全架构，或者说良好的生态圈。
网络厂商的方案
这类厂商，以传统网络数通厂家为主。云化，不仅仅需要服务器虚拟化，也需要网络的虚拟化。流量可以在计算节点的驱动层捕获，也可以在网络层面捕获。我们知道，业务流量在哪里，安全问题就在哪里。因此对于网络安全盒子来说，在网络层面接入才是正道。
如上图所示，SDN网络，控制面和转发面分离，通过控制器来集中控制所有流量的转发。在SDN网络内部，可规划安全区。在安全区域，安全虚拟机或安全设备，可注册为服务节点。在SDN协议字段里，通常有服务字段。通过设置服务字段的值，即可控制任意的流通过指定的服务节点。
那么，安全盒子的部署，在这种情况下，也简单了。只要把安全盒子或者安全虚机，部署在服务区域，并注册为标准服务节点，即可利用SDN的服务编排能力，“指挥”任意流量，经过相应的安全节点，从而完成安全防护。
同时，SDN也有强大的网络控制力，可以实现流量镜像到服务节点，以及把服务节点的虚拟机工作口，绑定到用户VPC从而完成扫描类任务。
因为流量调度，通过网络进行了横向迁移，此刻可能大家会担心对网络带宽占用问题。为因对此问题，SDN网络内部增加了横向交换机的密度，所谓spine-leaf架构，通过增加横向带宽，来满足流量横向迁移的能力。
这种方式的优点很明显：通过设置服务节点，将流量通过网络调度的方式，进行服务编排，可以很方便的接入第三方厂商的传统盒子以及安全虚机。同时，因为通过网络控制器来进行流量牵引，可以自然兼容大部分hipervisor OS厂家——因为引流和虚拟OS没有关系。
缺点主要是增加了横向流量，会增加一部分网络建设的开销。另外在网络时延方面，不如内置在计算节点的方式。最后，采用这种方式，网络设备必须是支持服务编排的SDN网络，这对于采用传统网络方式的客户，增加了改造费用。
传统终端安全厂商的方案
传统终端安全厂商，优势在于有安全终端，劣势在于没有网络产品，也没有虚拟操作系统产品。那么，自然会从自身优势出发，在虚拟机操作系统内想办法来构建安全能力，如下图：
即：通过在虚拟机操作系统内，安装安全代理（通过虚拟机模板部署），以及在HiperVisor OS内安装安全模块，或称之为“无代理”方式，通过在HiperVisor系统底层以及虚拟机操作系统驱动层，捕获数据流以及文件内容，来实现安全防护。一般可实现杀毒、文件监控、网络防护等功能。
这种方式的优点在于，通过在虚拟机操作系统部署安全代理，避免了必须依赖虚拟OS以及SDN网络，而直接实现了流量捕获以及防护。另外，也可以充分利用计算节点的计算能力，无需额外增加安全硬件资源的投入，也不会引起流量的横向调度。
缺点主要有三个：一个是在客户虚拟机上安装代理，会有信任问题。如果客户数据比较敏感，可能不愿意安装第三方的程序在自己的虚拟机内；另外，如果要按照不同租户不同策略来进行防护，还是需要一个集中的管理中心和虚拟系统用户数据库进行对接，以便于识别租户以及下发相应的策略。第三个缺点是防护能力的多样化会有问题，即：很难在这样高度集成的架构内，开放的引入各家厂商的安全能力。
网络安全厂商的方案
网络安全厂家，既没有SDN产品，也没有虚拟OS产品。在这种情况下，往往会选择一个中立的态度来构建云内的安全解决方案。
网络安全厂商，优势在于安全产品线很全，可以很快的将安全盒子，虚拟化为各种安全虚机，并池化。如下图：
通过在标准x86服务器上，安装各类虚拟机，并形成安全池集群；然后，根据租户的需求，构建虚拟的安全能力，如虚拟WAF，虚拟IPS，以对应虚拟资源的概念。这样做可以将以前安全盒子专属硬件才能提供的能力，灵活的虚拟化到通用硬件，客无须再采购专用硬件，可就地利用虚拟服务器来作为安全池的部署环境，甚至利用现有的虚拟资源池来部署安全虚机。
那么剩下的，就是通过各种方式，将流量往安全池牵引，以实现安全防护。具体的引流方式，需要结合用户网络环境来实现。比如通过SDN API引流，通过传统路由器进行策略路由方式引流，通过虚拟/传统交换机镜像口引流，以及在计算节点内安装引流代理，通过代理方式引流。如下图：
上图的微代理，可以看作一个特殊的虚拟交换机。如果VM2需要被防护，那么只需要拆除VM2和原有虚拟交换机的连接，并将VM2的虚拟网卡，连接到微代理，微代理用TRUNK的方式再连接到虚拟交换机上，这样便不会破坏原有VM2的VLAN拓扑。然后，所有VM2的流量就会经过微代理，即使是同一个计算节点内虚机之间的互访流量，也会被微代理截获。截获后的流量，通过隧道送往安全池过安全策略，然后发回原有微代理进行正常转发。
这种方式的好处在于，通过池化安全能力，可以构建弹性、多样化且开放的安全池，方案本身符合云的特性。同时利用各种引流手段，能够灵活的实现安全防护。
缺点在于，引流方式会带来额外的带宽占用和延时。同时，需要对接不同的客户网络方案，对接成本较大。
总结
综上，可看出目前云环境下，缺乏统一的网络安全设备部署环境，目前局势还有点混乱。从另一个侧面，也看出虚拟化发展过程中，基础设施对于安全方面考虑的缺失。
关于变化和发展
安全能力池化
传统的安全能力，都是通过固定的硬件盒子的形式提供的。在云时代，这种情况将发生变化。固化的安全能力，不能匹配云防护的要求。安全能力池化，首先是将传统的安全能力（引擎）虚拟化，其次是可弹性伸缩的安全池，最后能适应云环境的部署方式。云环境都是有租户的，那么云平台除了提供基础安全能力以外，也需要提供不同租户需求的不同安全能力套餐，并做到可运营。这样做的原因，本质是为了匹配云的特点：弹性，敏捷，虚拟化，可运营。
未来，传统硬件盒子的份额，可预见会持续下降，虚拟化安全产品的份额则会持续提高，此消彼长。传统盒子为了适应虚拟化，数通部分的模块会退化，引擎部分会持续强化。
在安全池基础上，需要有一个运营平台，对安全池进行统一管理，对安全业务进行灵活的开通、计费，并按照租户查看报表，以及云内部整体态势等功能。传统盒子的安全视角，是基于设备的。云安全池的视角，是基于运营平台的，安全盒子（虚机），只是平台下的一个基础模块。
最后，安全池是软件不是硬件，安全池泛指所有安全能力的集合，包含以安全硬件、安全虚机等组成的混合能力的“池”。
内嵌模式和外置模式互为补充
内嵌模式，指的是安全池内置在计算节点内，充分利用计算节点的计算能力进行安全防御的模式，简单可认为如下图所示：
外置模式，正好相反，安全能力放在单独的通用服务器内，如下图所示：
关于这两种方案的优劣势，争论很多。总的来说，内置式的最大优点，是充分利用计算节点进行就近防御。外置式最大优点，是有单独的安全能力空间，不占用计算资源。
不论安全厂商如何声称哪种方案好，从技术角度看，这两种方式实际上是互补的。外置安全池，更适合通过网络调度能力比较强的场合，以及以网络流量防护为主的场合；但是对于网络调度能力弱，需要结合local防护的场合，就适合内置方式。比如HWAF，本地杀毒，就近阻断，以及想在宿主机OS上搞点事情的场合。
外置和内置模式，都有对方干不了的事儿。从技术角度看，互补能够形成最完整的解决方案，缺一不可。无论目前坚持哪一派的厂商，最终都会走到这条路上来。从看见的客户实际需求，以及大厂的收购路线，都能印证这个趋势。
平台为王
传统盒子都是以卖盒子为主要销售模式。云机房，不但需要虚拟化的安全盒子（池），还需要处理和虚拟系统的对接以获取租户信息、vxlan信息，SDN引流对接；另外从运营模式看，云平台除了提供基础防护，更重要的是提供满足租户多样化需求的可运营的平台，并满足增值收入。
传统机房只需要安全盒子接入，最多加个网管软件，即可完成销售。对云安全来说，这是不够的，需要提供平台能力，通过将虚拟化能力引入平台，并将平台和云平台的对接，从而提供云防护能力。
云安全平台的模式和盒子不一样，平台模式是平台先行，盒子和虚机随后逐步建设。从这个角度看，得平台者得天下。平台模式示意图简单如下所示：
前提和假设：
本文主要讨论“当下的”私有云安全，公有云不在此文范围内。
如果您需要了解更多内容，可以
加入QQ群：570982169
直接询问：010-68438880