《软件定义安全》之五：软件定义的安全架构

本文主要是介绍《软件定义安全》之五：软件定义的安全架构，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

第5章 软件定义的安全架构

1.软件定义安全架构

安全控制平台，主要负责安全设备的资源池化管理、各类安全信息源的收集和分析、与客户业务系统对接，以及相应安全应用的策略解析和执行。
安全应用是根据特定的安全需求所开发的程序，它利用安全控制平台的开放API实现相应的安全功能。
开放安全设备就是传统的网络和主机安全设备，如防火墙、IPS等，它们逻辑上都会在安全控制平台的管理下，形成各类资源池，对外提供相应的安全能力。

1.1 安全应用

安全应用的种类多种多样，如Web安全、访问控制或DDoS防护等；交付形态也呈现出多样性，如一个Web服务，或一个Web管理系统，甚至可以是一段Shell脚本。这些应用可以由安全企业开发，通过互联网下载到安全控制平台上；也可以由有开发能力的用户企业的运维团队开发。
因为安全控制平台提供了开放接口，所以安全应用可以调用安全控制平台的北向API。利用平台开发的接口，应用开发就比较方便，当平台提供的接口丰富而强大时，开发者很容易就拼装出可实现复杂逻辑的安全功能。
应用本身也可以对外提供接口，这样一个应用可以调用其他多个应用的功能，形成服务的编排，完成更复杂的业务流程。

1.2 安全控制平台

安全控制平台在软件定义安全架构中可以被看作一个安全操作系统，北向提供应用接口，南向提供设备资源池，隐藏了底层各类不同厂商的安全设备。东西向可以松耦合的方式，与IT系统对接，获得资产及其他知识信息，并管理各类主体。
上述的不同功能通常是由独立的模块实现的，这些模块可以分布式地部署在多个物理节点上，安全控制平台负责调度、管理和这些模块间的通信。

1.3 开放安全设备

由于安全设备类型多种多样（硬件或者虚拟机），功能特点、部署模式和工作方式也各有不同，因此不太可能抽象出如OpenFlow的控制协议。但至少可以做以下两件事情。

1. 总结不同产品功能需求的共性，列出通用的应用接口

1）基本信息接口：获得设备的基本信息，如版本号、主机名等。
2）配置接口：获取或设置设备的某些配置值，如网络接口、工作模式等。
3）策略接口：获取或下发设备发挥作用的某些安全策略，如防火墙的五元组、WAF的防护规则等。
4）日志接口：存储和获取设备上传的日志和告警信息。

2. 针对特定的一类设备，可以制定统一的协议标准。如防火墙，可以规定访问控制策略五元组的下发接口。

当然，安全的本质是攻防，安全设备不可能根据简单的固定模式规则，完全工作在数据平面，还是需要一些内置的判断和决策逻辑。真正做到安全控制和数据分离比较困难，那是不是不能实现软件定义安全呢？其实，可以将安全设备看成黑盒，上述提到的逻辑都是黑盒中的内置功能，只要安全设备提供了对外的应用接口，那么这些接口调用方就形成了控制平面。这是一种更高层面的控制和数据分离。

2.安全系统在SDN中如何工作

在概念上，软件定义安全架构强调通过将安全控制平面上移，使得安全防护策略自动下发，以提高安全效率。但考虑到借助SDN技术可以方便地调度流量，而结合NFV技术又可灵活管理安全资源，借助这些新技术，客观上简化了安全设备部署的难度，可在较短时间内搭建起安全解决方案。

2.1 网络流量分析

SDN控制器控制了全局范围内的网络设备，所以可以通过网络设备上传的PACKET_IN和定期查询设备上的流表，获得每个时刻内网络中的流量信息。
流量在控制器中可表现为两类字段：头部匹配字段和流量统计字段。前者包括源目的地址及FlowMatch中的各个字段，后者包括该流出现的包数PACKET_COUNT和字节数BYTE_COUNT。
下图所示是PACKET_IN数据包的组成。每次SDN控制器收到PACKET_IN后，可以解析出整个原始数据包PI，从而获得数据包头部的字段H。然后它会新建一条流记录record，并根据解析结果依次填充record中对应的头部匹配字段，最后将该流的PACKET_COUNT设为1，将BYTE_COUNT设为数据包的大小Lᴾ。

一旦流表下发，匹配的数据包将直接被转发，SDN控制器默认是不会获知这些流的统计信息的，所以需要定期向网络设备发送OFPT_STATS_REQUEST请求，以获取这些流表的包数和字节数。

2.2 网络流量控制

SDN技术除了可以统计流量信息外，一个更重要的作用是控制网络的流量，包括对流量的放行、阻断、重定向和镜像等。
在OpenFlow SDN中，SDN控制器可以向网络设备下发FLOW_MOD指令，通过动作actions对匹配的流量进行控制。假设某交换机上有10个端口，节点A连在端口1；节点B连在端口8；一个虚拟IPS输入口连在端口3，输出口连在端口4。当节点A向节点B发送数据包时，如果要对其进行控制，则下发FLOW_MOD指令。其中，Match=A→B，动作actions如下表所示。

场景	流表	说明
1	import=1,A->B,actions=DROP	丢弃所有A到B的流量
2	import=1,A->B,actions=output:8	允许所有A到B的流量
3	import=1,A->B,actions=output:3import=4,A->B,actions=output:8	将所有A到B的流量牵引到虚拟IPS，处理之后，如果行为正常，则发送到B
4	import=1,A->B,actions=output:3,8	将所有A到B的流量镜像到虚拟IPS，进行异常行为检测

场景1中，动作为“DROP”，此时交换机将丢弃相应的数据包。
场景2中，动作为输出到某一个端口，此时交换机将其发送到相应端口。如果该端口是目的主机所在端口，则为正常转发（此处B连接端口8）。
场景3中，动作也是输出到某一个端口，但该端口（端口3）不是目的主机所在端口，而是一个中间设备IPS，则表明将该数据包牵引到IPS，等安全处理完毕后，再将数据包从IPS输出口（端口4）发出；然后根据第二条流表，交换机将其发送到端口目的地。
场景4中，动作为输出多个端口，此时交换机将数据包同时发向这些端口，端口8为目的节点B所在端口，端口3为IPS输入口所在端口，所以能同时实现正常转发和流量镜像的异常检测。

3 利用SDN和NFV进行安全管理

SDN技术可以被用于控制流量，结合NFV动态管理虚拟设备的特性，就能设计一种全新的安全防护模式：安全系统在运行时动态确定安全基线；并根据当前的安全需求、风险和威胁，将需要处理的数据流依次经过安全资源池的一个或多个设备，组成一条虚拟的防护链。

3.1 SDN/NFV在云中的应用

OpenStack环境中可集成自动Web防护，用户只需从管理界面的Web安全应用中选择一个vWAF，并拖动到运行某个Web应用的虚拟机上，然后配置vWAF的标识、部署模式，即可完成对该服务器的Web防护。

后台由安全控制平台进行了一系列复杂的处理：

Ⓐ 安全控制平台向OpenStack或负责管理虚拟安全设备的Agent发送指令，根据用户的需求，启动若干个vWAF。
Ⓑ 安全控制平台向SDN控制器下发流指令，要求将虚拟网关处所有到Web服务器的HTTP流量重定向至vWAF输入口所在的交换机端口。此时SDN控制器根据虚拟路由器与目的交换机端口间的拓扑计算一条路径，并向该路径上的交换机下发FLOW_MOD指令，实现流量牵引。

---

如果vWAF是透明代理模式，则vWAF可处理流经的所有数据包，那么FLOW_MOD只需指定output端口。
如果vWAF是反向代理模式，并只处理目的地址为vWAF输入口地址的数据包，由于网关处的流量目的地是Web服务器，vWAF是不会进行处理的。此时安全控制平台的流牵引指令中需加入重写目的地址的信息，而FLOW_MOD指令除了指定下一跳的端口外，还应在第一跳将数据包的目的地址改写为vWAF的IP和端口。

---

Ⓒ vWAF启动后向安全控制平台注册，后者向vWAF下发防护策略，告知应防护某Web站点，并启用如XSS、SQL注入等防护模板。

OpenStack中的Web防护流程

3.2 多设备的串联服务链

使用服务链实现安全功能时，在方案制定时，云服务商和安全厂商需要界定清楚网络管理和安全管理的边界。否则，安全控制平台在不了解网络业务流量的情况下，贸然下发流量控制指令，会给网络管理带来不可控的因素。一个可行的设计方案如下：

运行时，安全控制平台只需向云服务商的SDN控制器下发一条流量牵引指令，将源虚拟机VM1的流量重定向到安全设备，然后向安全厂商的SDN控制器下发若干指令，根据安全需求使流量经过一条服务链，完成检测和防护后，再将流量送回到目的虚拟机VM2。这种方案只将流量牵引到特定的若干安全节点，避免了安全厂商直接通过SDN控制器操纵全局的流量，理清了网络管理和安全管理的边界。
在这一条服务链中，用户可以自定义需要做哪些检测和过滤（如入侵检测，恶意流量清晰，访问控制等），以及检测和过滤的顺序。

3.3 VPC的安全管理案例

➊ VPC的安全需求

根据VPC的拓扑结构，其网络安全需求可以拆分为子网内的安全需求、子网间的安全需求和接入网关的安全需求3个子问题，从而分别进行解决，如下图：

1. 子网内的安全需求

由于同一子网内的虚拟机在物理上是集中的，且通常在子网内发生频繁的迁移，因此子网内提供一些轻敷在的检测功能即可，如基于网包包头的检测，以避免给租户的业务性能和虚拟机的在线热迁移带来额外的负担；而诸如对网包载荷进行检测等重负载的检测功能，仅需要在检测到可疑行为时动态开启。

2. 子网间的安全需求

由于不同子网内部署的服务器种类往往不同，因此对安全的需求也不同，此外，安全检测功能的组合、负载均衡和横向扩展会使安全服务的提供变得更加复杂。因此，子网间安全必须实现细粒度安全检测功能的高效提供和安全检测能力的横向扩展。

3. 接入网关的安全需求

租户的VPC网关是业务的关键节点。该节点易遭受来自互联网的大流量攻击，如DDoS。除此之外，云计算提供的“按需申请”和“按使用付费”方式，也使得云数据中心的恶意租户可能在短时间内租用大量资源，发起对同一个云数据中心内正常租户的大流量攻击。因此，接入网关安全非常必要且适合利用已有的硬件网络安全中间设备分担并加速安全检测功能。

➋ VPC的安全设计

系统架构的设计一方面需要考虑上述3个安全应用场景对安全机制独有的要求，以兼顾资源的使用效率和服务的灵活扩展；另一方面还需要仔细分析当前部署实际的限制。

1. 子网内安全

采用了“面向源端”的策略管理方法，它能够降低虚拟机在线热迁移过程中策略管理的复杂度。在此基础上，由于OpenFlow协议能够匹配网包L2~L4的包头域值，因此系统使用OpenFlow兼容软件交换机，在每个物理服务器的管理程序中部署子网内安全策略。对于网包包头的检测，如ACL和QoS策略，系统直接利用软件交换机的OpenFlow流表来执行策略；对于网包载荷的检测，系统根据业务状态动态配置细粒度的OpenFlow流表，按需将待检测的流量牵引到执行相应检测功能的虚拟机上。

2. 子网间安全

通过构建支持多种检测引擎的虚拟机集群，实现检测能力的扩展和检测功能的组合。检测引擎集群一般与租户的虚拟路由器部署在相同或相近的物理服务器上。系统引入监控负载调度器作为集群中多个检测引擎的前端。其主要负责网络L4~L7的流量分类，并维护连接表，为检测功能的组合和检测引擎的负载均衡提供支持。系统向云数据中心资源整合系统的网络服务请求一个安全子网，监控负载调度器将流量按照服务链指定的顺序依次牵引到相应的检测引擎上。此外，这种方式方便了相同类型的检测引擎接入或移出安全子网，从而可动态调节检测能力的大小。监控负载调度器的引入给系统控制平面带来了更高的灵活性。

3. 接入网关安全

系统使用硬件设备来加速安全检测。首先，接入网关的流量巨大，必须使用高性能的硬件设备来抵抗大流量的网络攻击。其次，由于网络虚拟化技术的使用，传统的硬件网络安全中间设备无法支持多租用的特性，因此难以在数据中心内部网络中发挥其功能。由于数据中心内所有租户的虚拟路由器都使用共享的地址空间连接到Internet，非常适合部署UTM或NGFW等硬件设备。最后，在实际部署应用中，不同租户对接入网关会定义相似的安全策略，因此更有利于充分发挥硬件设备的处理能力。

这篇关于《软件定义安全》之五：软件定义的安全架构的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---