SDN(软件定义网络)灵活的流量调度能力和开放的可编程能力，结合NFV(网络功能虚拟化)的网络功能管理和服务编排，构建一个完整的、开放的虚拟化网络平台。将此安全架构与云平台进行对接，通过两个控制平台层面的交互，实现资产以及防护策略的一致性，然后通过网络将资源层打通，实现流量的灵活调度，完成整个虚拟化环境的安全防护。
一、背景
云计算近年来已经得到了众多用户的认可，很多客户已经或者正在规划将其业务系统进行不同规模的云化。在这个过程中，除了用户广泛关注的云计算系统的稳定性、性能、隔离等问题之外，云上业务的安全性也是越来越受到用户的重视。
从管理模式上看，传统的IT系统通常有着唯一的运营使用单位，这样系统提供方和用户之间就有了清晰的安全职责划分，一旦系统出现安全隐患或者安全事件，会有明确的责任人处置。在云计算的这种以服务为核心的模式下，整个IT系统会面临云服务提供方、云租户和云用户多方的关系，如何明确各自的职责，是确保云计算系统安全的一个重要的前提。
从技术上看，云计算采用资源池化的方式为用户提供服务，用户的计算、存储、网络等资源，都能够根据具体的需求进行动态的扩容和收缩，这样传统的安全集中投入的方式就很难满足云计算中资源的按需扩展需求。另外，不同租户对安全的需求也存在很大的差异化，如何满足这种差异化的安全服务需求也是一项很大的挑战。
除此之外，在虚拟化环境中，现有的物理安全机制可能根本无法检测到恶意攻击。如下图所示，虚拟机vm1和vm2是同一租户同一子网的两台虚拟主机，存在于同一台物理主机内，那么两者之间的通信仅存在于vm1、虚拟交换机vSwitch和vm2之间，流量根本就不会出宿主机，那么恶意的流量自然也就无法被外部的安全设备所识别到。
如果虚拟机之间通信的数据包出了宿主机，现有的安全机制就能解决云中网络的安全问题了吗?也未必。下面这张图展示的是通常云计算系统的一个简易的部署逻辑图，在云网络中，通常是通过vlan + vxlan/gre这种方式实现租户隔离的，那么当同一子网的两台虚拟主机vm1和vm4在不同的物理主机内，虽然两者之间的通信会经过外部的防火墙，但由于物理主机之间通过隧道相连，如果防火墙只是简单的部署在物理交换机一侧，那么它只能看到vm1到vm2的数据包，而不能去掉隧道的头部，解析vm1到vm2的流量。
从上述两个场景可以看出，单从技术的角度来看，传统的安全设备、安全防护方案在云计算这种新的计算模式下，是无法实现网络安全的检测和防护的。
从法律和合规的角度看，国内外的云安全标准机构近年来也是陆续发布了多个云安全的相关标准，比如云安全联盟(CSA)发布的《身份管理与接入控制指导建议书》(白皮书)、《如何保护云数据》(白皮书)，美国国家标准技术研究所(NIST)发布的《云计算安全障碍与缓和措施》(标准草案)、《公共云计算中安全域隐私》(标准草案)，CSA大中华区C-STAR Tech标准工作组发布的《云计算安全技术要求》(草案)，以及国内等保标准里的《信息系统安全等级保护 云计算安全扩展要求》(草案)、《信息系统安全等级保护 云计算安全扩展测评要求》(草案)等。如何建设云计算系统的安全措施，保证符合法律和合规的要求，也是用户业务云化面临的一个重要的问题。
国内外云安全标准机构
那么回到安全本身，从攻防的角度来看，云安全和传统的安全其实并没有本质的区别，传统安全面临的最大挑战是需要保护资产的动态性、软件化、移动化使得以往固定的环境会随着业务和环境的变更而快速变化。
面对云环境中常态化的变化问题，安全机制部署和安全策略配置完毕后长期不变的时代将一去不复返。安全方案也要能够随着云环境中计算和网络相关资源的变化而动态调整，主要体现在：
- 安全设备的形态需要发生变化;
- 如何在虚拟化的网络内部部署相应的安全机制;
- 能够根据需求，进行按需分配;
- 能够自动化的进行动态扩容和收缩;
二、软件定义
1. SDN
软件定义网络(Software Defined Networking，SDN)提出了一种全新的网络架构，能够通过逻辑上集中的控制平面，实现网络管理、控制的集中化、自动化。那么SDN和安全又有什么样的关系呢?
要解答这个问题，我们首先来看一下SDN的本质，SDN是一种架构，一种思想。根据这种思想可以总结出三个本质的属性：控制与转发分离、集中化的网络控制、开放的编程接口。
控制与转发分离，使得逻辑上集中的控制平面能够拥有全网的完整视图，这样控制平面就能够看到任何正常的、或者不正常的流量;集中化的网络控制，使得控制平面能够控制任何流量能走、不能走、怎么走;开放的编程接口能够将上述所有的操作实现可编程以及自动化。这样看来，SDN天然的就为网络的安全问题提出了很好的解决办法。当然，斯坦福大学最初提出OpenFlow也是在某种程度上为了解决安全问题。
下面这张图是盛科网络早期的时候提出的一种基于SDN的安全解决方案，在该方案中，将SDN交换机部署至机房入口路由的位置，方案中将其作为LB使用。IDS、IPS、FW等安全设备全部连接到这个SDN交换机上，SDN控制器根据需求，向交换机下发相应的流表策略，使特定的流量经过特定的安全设备进行安全检测/防护。当然这种方案还可以将同一条流依次调度到不同的安全设备，实现安全服务链。
2. NFV
传统的网络服务，通常是采用各种各样的私有专用网元设备实现不同的网络/安全功能，比如深度包检测DPI设备、防火墙设备、入侵检测设备等。网络功能虚拟化(Network Function Virtualization，NFV)利用IT虚拟化技术，将现有的各类网络设备功能，整合进标准的IT设备，如高密度服务器、交换机、存储等，通过管理控制平面，实现网络/安全功能的自动化编排。下图是欧洲电信标准化协会(ETSI)为NFV制定的参考架构，从图中可以看出，该参考架构将NFV基本分为了三层：NFV-I(Infrastructure)，VNF-M(Manager)和NFV-O(Orchestrator)。
NFV-I提供了虚拟化网络功能(Virtualized Network Function，VNF)运行所必须的基础设施，通常这些基础设施是在硬件的计算、存储、网络之上，利用虚拟化技术形成的虚拟化资源，这些虚拟化资源通过虚拟化基础设施管理模块(Virtualized Infrastructure Managers，VIM)进行管理和分配。得益于云计算IaaS体系的发展和完善，NFV-I可以通过OpenStack、VMware、AWS等云计算平台来进行集成实现。
VNF-M即各种虚拟化的网络功能层，通过VNF+EMS实现多种虚拟网元的网络功能，这些VNFs由VNF-M进行统一的管理。NFV-I我们可以理解为是一个基础设施的资源池，那么VNFs就是一个虚拟的网络功能资源池。
NFV-O是最上面的业务层，根据OSS/BSS的业务逻辑和业务需求，NFV-O动态的对下层的VNFs进行编排，以满足业务系统对不同网络功能的需求。
VNF-M和NFV-O共同组成了NFV架构中的管理编排域，简称为MANO，MANO负责对整个NFV-I资源的管理和编排，负责业务网络和NFV-I资源的映射和关联，负责OSS业务资源流程的实施等，MANO内部包括VIM，VNF-M和Orchestrator三个实体，分别完成对NFV-I，VNFs和NS(Network Service)三个层次的管理。
下图是OSM(Open Source MANO)技术白皮书中对于MANO在NFV架构中位置的描述，其中红色的部分为MANO的实现。
从上面的描述和SDN/NFV的架构可以看出，NFV更多强调的是网络功能的管理和服务编排(MANO)，其重点应该是在功能层面。而SDN更强调的是集中化的网络管理和控制，重点应该是在流量层面。
SDN和NFV之间并不存在依赖关系，可以相互独立的部署运行。但是二者之间又有着很强的互补性，SDN灵活的流量调度能力和开放的可编程能力，可以使NFV的部署性能增强，简化互操作性;NFV又能为SDN的应用提供良好的使用场景和基础设施支持。这样二者融合在一起，就可以实现一个完整的、开放的虚拟化网络平台。
3. 基于SDN/NFV的安全架构
基于SDN/NFV技术，可以构建一个完整的、开放的虚拟化网络平台，那么能否在此基础上，整合构建出一个虚拟化的安全解决方案呢?答案当然是肯定的。
如下图所示，就是一种基于SDN/NFV的安全方案架构图，除去计算、存储、网络等硬件基础设施之外，整个架构自底向上共分为资源池、安全控制平台和安全应用三个层次。
资源池是各种安全防护功能的集合，具体可以包括但不限于：(1)安全预防类功能：系统漏洞扫描(vRSAS)、web漏洞扫描(vWVSS)等;(2)安全检测类功能：网络入侵检测系统(vNIDS)、网络流量分析系统(vNTA)等;(3)安全防护类功能：网络入侵防御系统(vNIPS)、下一代防火墙(vNF)等;(4)安全响应类功能：安全审计系统(vSAS)、堡垒机等。
在设备形态上，安全资源池内的安全功能既可以是依托虚拟化的安全设备(VNFs)，也可以是传统的硬件安全设备;在基础设施层面，既可以采用独立的安全节点进行部署，也可以依托OpenStack、VMware、FusionSphere等云计算IaaS平台。具体可参考下面的示意图。
安全控制平台则包括了NFV架构中的VI-M、VNF-M和NFV-O，具体到功能层面和NFV架构中的类似，比如VI-M用来管理安全资源池的基础设施资源，同时负责跟网络系统的SDN控制器进行对接;通过VNF-Manager/Agent的方式，实现各个安全功能的管理;通过NFV-O提供北向的应用接口。
安全应用则根据安全控制平台提供的接口，实现多种安全服务，这里拿上述架构中的三类安全应用举例来简要说明。
首先就是单个的安全功能应用(Sec APP)，比如web防护，用户通过这个应用，直接配置需要防护网站的域名、勾选相应的防护策略，实现安全功能的服务化。其次就是安全大数据的应用，通过安全控制平台收集的日志、告警等信息，实现态势感知、数据分析等内容。最后就是安全服务编排，依托安全控制平台的NFV-O编排器，根据安全防护需求，制定相应的安全编排策略。
三、云安全实践
那么这种基于SDN/NFV的安全架构应该怎么样来集成到业务系统进行安全防护呢?要回答这个问题，我们先把使用场景分为两类：(1)云计算、软件定义数据中心这类的系统/平台;(2)NFV系统。
对于第一类场景，可以直接将上述安全架构和云平台进行对接，通过两个控制平台层面的交互，实现资产以及防护策略的一致性，然后通过网络将资源层打通，实现流量的灵活调度，完成整个虚拟化环境的安全防护。
对于第二类场景，一方面，可以按照第一类场景的方式进行设计，即两个控制平台进行对接;另一种方式则是将安全资源池集成到NFV的VNFs内部，与NFV共用VI-M、VNF-M和NFV-O，这样的话安全和网络就实现了深度的整合，同时也带来了高耦合的风险问题。
下面我们从第一个场景着手，看一下绿盟科技是如何设计其安全解决方案的。如下图所示，是方案的整体架构图，主要分为4个部分，最下面的VNFs，也就是安全的资源池，这里的安全功能提供者既可以是绿盟的设备，也可以是第三方厂商的设备，设备之间通过SDN网络实现互联。SIEM系统主要是用来收集下层安全设备的日志和告警等信息，提供威胁分析的数据来源。安全资源池控制器一方面负责VNFs的管理控制，同时还负责与云平台进行适配。最上面是云安全管理平台的门户，为用户提供安全服务和运维服务等多个使用门户。
绿盟科技云安全解决方案为用户云上业务提供预防(RSAS、BVS等)、检测(NIDS等)、保护(NIPS、NF等)和响应(SAS、ESP等)全系列的安全服务。近年来，先后在政府、金融、能源、教育、运营商等众多行业落地应用，解决了用户南北向和东西向流量安全问题。
如下图所示，为某运营商提供南北向和东西向安全服务，绿盟云安全管理平台与客户云计算系统对接，通过外置安全资源池和内置资源池结合的方式，将南北向流量和东西向流量进行调度，完成安全检测和防护。
四、总结
云计算越来越多的得到人们的认可，随之而来的就是其安全问题也是引起了更多人的关注。从今年的互联网安全大会我们可以看出，两个云安全分论坛，三分之一左右的参展商是解决云安全问题的，其中很大的比重是创业公司，排除商业因素，单从创业公司的着手点也可以看出，云安全在整个安全行业所占的比重也是越来越大的。
云计算系统较传统的IT系统，既涉及到管理模式、服务模式的创新，同时又涉及到虚拟化、隔离等技术层面的创新，因此其安全的着手点也是千姿百态。本文主要针对云上业务的安全，分析并展示了基于SDN/NFV技术的云安全实践方案。
【本文是51CTO专栏作者“绿盟科技博客”的原创稿件，转载请通过51CTO联系原作者获取授权】
