面向云环境的软件定义访问控制框架

魏 伟，秦 华，刘文懋

(1.北京工业大学 信息学部，北京 100124；2.北京神州绿盟科技股份有限公司 创新中心，北京 100089)

0 引 言

随着云平台的不断普及，加大了数据泄露和网络遭受攻击的风险，一方面对于跨网络访问(即南北向流量)来说，需要解决的问题是如何应对来自内部虚拟环境的错综复杂的流量。内部环境会多个租户，每个租户又可能会同时拥有多个网络。另一方面，对于子网内部流量(即东西向流量)，用户资源和敏感数据分布在多个不同的计算节点中，计算节点内部虚拟机之间存在大量的二层流量交换，这种二层交换通常会通过GRE或VxLAN隧道传输，这样对于外部的物理防火墙来说是透明的，只能通过虚拟化技术将虚拟防火墙引入二层环境解决。应对租户内部网络虚拟机不同的业务场景和多样的安全需求，如何进行更细粒度的访问控制是一个亟待解决的关键问题。

传统的网络安全解决方案已经不能满足云环境下的要求，如何适应虚拟化环境，这让信息安全面临巨大的挑战。在云计算时代，虚拟化已经成为安全产品的必备功能，研究针对云环境虚拟化的安全防护解决方案迫在眉睫。

1 工作基础

Gartner率先提出了软件定义安全(software defined security)，提出将传统的安全设备通过虚拟化技术形成虚拟化安全资源池，在上层统一通过软件定义方式进行自动化的业务编排和资源管理，以此实现一种灵活的安全防护框架。软件定义与安全的结合现已成为业界的前沿发展热点。近年来，在访问控制的研究中，出现了不少新的模型，如Gartner提出的自适应访问控制(adaptive access control)[6]模型，CSA的软件定义边界(software defined peri-meter，SDP)[7]，等等，它们与以往基于角色的访问控制(role based access control，RBAC)不同，通过软件定义的方式，新模型提高了控制的灵活性，还可提供更清晰的认证语义和更丰富的访问控制决策。总之，各种传统访问控制模型通过主客体和上下文环境的各种因素，综合决策系统内资源的访问控制。但是云环境较为复杂，要求灵活度更高，控制粒度更细，还必须实现在云环境中的集中控制。所以必须要研究新的访问控制模型来适应云环境。

OpenStack中的Neutron项目主要实现了云环境中的网络虚拟化功能，它现有OVS、linux bridge和SDN等多种实现机制，可实现GRE、VxLAN、VLAN与flat network这4种类型的网络，基本满足了现代云计算环境的网络功能需求。

如图1所示，在neutron原生的L3层网络，在网络节点通过命名空间(namespace)隔离租户的三层网络流量，命名空间qrouter内部使用iptables实现路由转发、SNAT地址转换、floating IP等功能，还实现了简单的防火墙即服务(firewall as a service，FWaaS)。其通过开放的API向防火墙下发安全策略。FWaaS主要用来控制云环境中的南北向流量。Neutron为FWaaS定义了一套API，用于管理访问控制服务及其策略，可用于自动化的防火墙业务上线。

如图2所示的Neutron原生二层网络实现了VLAN网络类型，在虚拟机到虚拟交换机之间，数据流量会经过qbr、br-int等虚拟网络设备，虚拟设备之间采用TAP、Veth pair等手段逻辑链接，qbr是一个支持iptables实现的Linux bridge设备，以此实现简单的安全组(security group)。br-int是由OpenVSwitch实现的虚拟交换机，它的主要功能是将这一台物理设备上的所有虚拟机连接在一起，还通过L2-agent向虚拟交换机下发流表的方法，用vlan id标识不同租户间的流量，实现简单的二层租户网络流量隔离。

图1 Neutron原生三层网络

Neutron提供了良好的扩展性，我们可通过定制相应agent与driver的方法，加固neutron的安全能力，实现更完善的访问控制。

2 面向云环境的访问控制框架

云计算环境可以分为内外两个部分：云计算内部环境是虚拟的SDN网络，外部环境为虚拟化环境外的传统物理网络环境。访问控制框架必须覆盖内外两个环境的融合网络，形成统一的访问控制策略。以此为依据，本文设计了如图3所示的访问控制框架，重点解决云环境内部的访问控制问题。

图3 面向云环境的访问控制框架

2.1 防火墙即服务

Neutron网络节点通过命名空间(Namespace)隔离不同租户的流量，命名空间内部使用iptables实现NAT和访问控制功能。iptables可以定义多条规则，形成规则链，共同发挥作用，还可以将多条规则链组成一个列表，实现某一方面的访问控制功能。

如图4所示，当一个数据包要访问某个客体资源时，会先经由iptables进行检查。检查通过则接受(ACCEPT)进入本机取得资源，如果检查不通过，则可能予以丢弃(DROP)，规则是有顺序的，例如当数据包进行Rule01的检查，如果比对结果符合，则对这个数据包进行Action 1的操作，而不会再进行Rule 02,Rule 03等规则的匹配。

图4 iptables数据包检查过程

iptables的一大缺点是依赖线性匹配，当大于500条规则时，匹配效率就会明显下降。且iptables不能进行应用层等更高级别的过滤。可以说openstack仅采用这种底层实现是难以应对高并发大流量的过滤，与更细粒度更智能的监控的。

本框架对neutron的原生FWaaS实现机制进行了改进，主要是在neutron的L3层替换其原有的qrouter namespace,将其底层实现方面，根据SDS的原则，引入开放了RESTful API的虚拟化防火墙(virtual firewall，vFW)，这些虚拟防火墙镜像可由第三方厂商定制，有利于产品在云环境中快速上线，形成虚拟防火墙资源池，由资源池管理模块bootagent统一维护并管理，vFW底层功能实现替换ipta-bles规则。将vFW做为内部虚拟化网络的安全网关，可以大大提高云环境虚拟边界处的访问控制能力。

如图5所示，实现方法是采用“借壳”Namespace的方式，qrouter Namespace仅保留获取元数据的功能，其余原neutron l3层的功能则统一由vFW实现。当用户发出创建路由器的请求时，会在防火墙资源池中为租户启动一台vFW，并为其通过DHCP分配管理口IP，还会创建这个vFW独占的OVS进出口网桥(以此来实现租户隔离)。此时vFW与用户创建的路由是一一对应的，当用户进行与路由相关的网络操作时，经过改进的neutron l3-agent模块会将用户的请求通过RESTful API发送给路由对应的vFW，由vFW内部进行功能实现。当租户有多个网络时，设计的interface driver模块会凭借vFW的三层子接口功能，以VLAN tags来实现网络隔离，在统一入口处设置为trunk，识别来自不同网络的流量。

在访问控制功能实现方面，通过替换neutron fwaas driver实现了由neutron API到vFW RESTful API的转换，以安全五元组的形式在vFW内创建相应客体并生成相应的安全规则。将南北向流量统一由vFW做访问控制。由此实现安全网关的功能。

2.2 微分段

在虚拟化环境中，越来越多的流量出现在租户内部网络中，这是租户业务发展所决定的。此外在云环境中，租户可能会在同一个网络中同时部署WEB服务器和数据库服务器，也有可能存在一个租户下面多个部门或员工申请的虚拟机部署在同一个网络中。这种情况下，攻击者一旦攻破了某个VM，则很可能进而攻击其它网络内部的服务器，因为防火墙一般是部署在网络之间，此时访问控制策略无法生效，内部服务器群会完全暴露给攻击者。

图5 VFW实现FWaaS

如图2所示，对于虚拟网络内部的东西向流量，OpenStack原生安全组使用linux bridge放在虚拟机的进出口，对租户网络内部所有的虚拟机流量进行统一的访问控制，其实这并不是严格意义上的东西向流量的访问控制，在租户网络内部，不同的虚拟机有不同的安全需求与业务需求。原生方案统一在虚拟机的进出口做访问控制是无法灵活解决上述问题的。

作为一种解决东西向流量访问控制的思路，微分段(micro-segmentation)技术近年被提出，它将租户网络中的多个虚拟机划分为一个分段(segment)，并在这些分段边界上部署访问控制机制。分段方法比较灵活，可以是一个虚拟机，也可以是满足某种条件的多个虚拟机的集合，所以就可以在一个网络中按需地划分出若干个微安全域，然后在这些微安全域的分段边界部署安全策略。这与传统的边界划分不同的是，微分段可以是一个虚拟网络中的任意一部分，如果在微分段间部署安全策略，则可以监控到二层网络中的流量。我们可以根据虚拟机不同的安全需求将他们分为不同的组，在组之间再做细粒度的访问控制。

还可以通过结合服务链(services chain)进行更高级的访问控制。服务链是指利用SDN技术，将流量经过多个设备，分别进行不同目的的检查、防护或其它功能的实现。在传统访问控制的场景中，规则一般通过RBAC或ABAC来制定，总体而言缺少上下文感知，在发生威胁时无法及时调整控制规则。在云环境中，攻击威胁会发生在很短时间中，这就要求策略调整非常及时。通过服务链，我们可以按需地在虚拟或物理位置部署各种虚拟安全设备，流量根据上层的编排依次经过预先启动好的虚拟设备，当安全检测设备发现可疑的攻击时，可通知防火墙实时调整访问控制策略。

如图6所示，如果要部署应用程序的服务器，我们可以提供防火墙和负载均衡设备来提供安全性和可用性，将它们组成服务链并部署在组的边界处，边界处可定义策略，流量经过IDS的检测，将符合相应条件的流量重定向到服务链，经过多个设备处理可访问到应用程序组，检测到有威胁的流量，则可直接配置规则拒绝访问的请求。

3 实验与验证

本实验拟在100 Mbps以太网的网络环境下，测量ip-tables与VNF两种底层实现方案在64 bytes、128 bytes、256 bytes、512 bytes和最大1518 bytes这5种RFC2544定义的标准帧长数据在满负载情况下的稳定性表现。通过本文之前的分析可知，iptables解决方案在大量安全规则的情况下会出现性能下降的现象，为此，本文计划采用100条安全规则与500条安全规则两种规模规则集分别对比两种解决方案性能情况。

图6 结合服务链的微分段

实验环境统一在虚拟化云平台中进行，在云平台中创建两个网络，并在每个网络中都启动一台虚拟机分别是VM1与VM2，虚拟路由器作为三层实现将两个网络相连，作为FWaaS解决方案，正是在此路由器的位置，其原生底层实现是iptables，之后被替换为第三方的虚拟防火墙VNF，为了进行性能测试，Ixchariot的客户端软件需要在VM1和VM2上安装，因此两台虚拟机可作为流量通道的两端，确保之间的流量都经过了FWaaS过滤，将Ixchariot控制台安装在其中一台虚拟机VM1上，以此定制流量并获取测试结果。

按照上述实验方案，执行性能测试，可在Ixchariot控制台得到输出结果，记录5种帧长在两种解决方案环境条件下的每次获得的平均流量带宽值(单位：Mbps)，总共两种规模的安全规则集总会产生20个数据，整理可得表1与表2两组实验结果。

表1 100条规则规模条件下平均带宽/Mbps

表2 500条规则规模条件下平均带宽/Mbps

将所得数据除以100 Mbps的理论带宽值，所得百分比即为吞吐量，将数据再次经过处理，以横坐标轴为帧长，纵坐标轴为换算好的系统吞吐量，分别作图并分析两种规模集下的两种解决方案的性能优劣。

如图7所示，在100条规则的规模条件下，两种解决方案性能相近，iptables在同长度帧长的条件下，比VNF方案更早的达到接近100%的系统吞吐量。在规则规模较小的情况下，VNF在规则匹配算法方面，没有太多发挥空间。iptables在实现方面更靠近硬件底层，而VNF的实现建立在虚拟化的基础上，需要借助hypervisor层面的管理与优化，且在网络连接等方面比iptables原生方案更加复杂，对比可发现VNF方案会使数据流量再多经过两次OVS网桥(即防火墙的入口网桥Nf-in-XXX)，故iptables在对于系统资源的利用率方面占优，在规则较少的情况下性能比VNF有微弱的性能优势，但是VNF比起iptables有着更强大的功能，在差距不明显的情况下，如需更重视系统安全性，建议忽略微小的性能损失，采用VNF方案。且对于云环境来说，访问控制策略繁多复杂，策略规则的数量规模相对庞大，本框架也主要应用于大规模安全规则的条件。

图7 100条规则规模条件下两种解决方案性能对比

如图8所示，在500条规则的测试条件下，VNF方案在安全过滤规则算法方面的优势明显，在相同帧长的情形下VNF体现出明显的性能优势，主要是摒弃了iptables机械的链式匹配过滤算法，安全规则规模剧增后，包过滤处理能力优势明显，能高效且完善的解决云环境中的访问控制问题。

图8 500条规则规模条件下两种解决方案性能对比

4 结束语

云计算技术的兴起给网络架构带来了深刻的变革，传统的实体防火墙能够监控传统数据中心网络中的流量从而进行安全防护，并且能都做到一定的业务隔离。但是在云计算环境中，物理防火墙无法部署在模糊的安全边界，云平台管理者也无法做到对云中资源的隔离与防护。

本文通过软件定义的方式，在Neutron项目的基础上，设计出一套适用于云环境的访问控制框架，对于南北向流量采用FWaaS方式，引入虚拟安全网关，能够识别来自虚拟网络的复杂流量并准确进行控制策略的定制与下发。对于东西向流量，采用微分段加服务链的方式，能进行更细粒度的访问控制，并能够根据多变的安全威胁，进行快速的安全策略调整。