开发者俱乐部
标题: 新的云中逻辑边界迷雾重重？东西南北流量何去何从？——云中虚拟安全网关技术路线综述 [打印本页]
作者: xunadmin 时间: 2016-4-6 06:58
标题: 新的云中逻辑边界迷雾重重？东西南北流量何去何从？——云中虚拟安全网关技术路线综述
网络安全问题正越来越成为云计算发展的掣肘，传统网络的物理安全边界已经消失，新的云中逻辑边界该如何守护？业界云安全专家孟庆森及其研究团队将给出云中虚拟安全网关技术路线的发展现状和思考。
一、概述云计算是DT（Data Technology）时代的基础，它已经逐渐改变了传统IT行业格局。云中的安全威胁像达摩克利斯之剑悬挂在产业的上空，同时它也像一个巨大的迷宫一样让整个安全行业陷入思考。或以传统的方案适配融合到云中，或以创新的思路解决问题，不管是安全的巨头，亦或是专注于云安全的新兴厂商，至少目前还没有给出令人信服的方案，一切其实还并不明朗。本文无意对仍处在迷雾中的整个云中安全拨云见日，只关注以云中租户为中心的新逻辑防护边界。本文对云中安全生态进行了跟踪，对虚拟安全网关产品形态进行了技术调研，给出了主流的技术发展路线并总结了目前该技术领域所面临的挑战。
二、云计算生态云计算的生态格局（见图1）[1]已经完全不同于传统领域，传统生态链上的角色被打破，厂商需要重新组合资源实现转变。安全系厂商也不例外，甚至面临比其它厂商更为严峻的挑战。从架构图上看，云安全供应商属于应用开发商的一类，但是在新的框架体系内，与服务运营商和系统构建商等的关系越来越紧密。
三、租户要想理解云中新的逻辑安全边界，那么必须要理解租户（tenant），WIKI中定义：
Software Multitenancy refers to a software architecture in which a single instance of a software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.
摘自wiki multitenancy词条[2]
简单总结：“租户是一组具有相同属性用户的集合，在多租户的架构中，软件被设计成为每一个租户提供精细的资源共享和调度，是云计算中最重要的特征。”
私有的企业网络变成了云计算架构下的一个租户，物理的边界消失了，租户成为了云计算中的逻辑边界。不同的租户共享计算中心的资源，但又相互隔离，从表面上看起来完美极了。但从安全的角度去看，系统的漏洞、APT攻击和Dos攻击等一切都令人担忧。
租户的边界隔离防护成为云安全中很重要的组成部分，传统的硬件一体机形态的安全网关无法部署到云中去，虽然有个别厂商在硬件盒子上虚拟出多个网关来实现多租户的边界防护，但实际上无论从性能、流量牵引方式还是客户的实际需求都无法很好得到满足。租户的流量分为两类（图 2 租户流量分析）：
- 东西向流量：图中①，②分别代表租户内部的流量，称之为东西向；
- 南北向流量：图中③，④分别代表出租户的流量，称之为南北向；
虚拟网关作用：“以虚拟机的方式运行，部署在租户的网络中，可以对单个租户南北和东西向流量进行安全防护”。
那么把传统的安全网关直接虚拟化部署到云中，能覆盖云中安全防护需求吗？
- 传统网关产品可以透明接入也可路由部署，但在虚拟网络中（无论是VPC架构还是二层网络）都没有像物理环境那样简便部署虚拟安全网关的位置，流量如何经过安全网关是个难题；
- 云中80%的流量是东西向流量，如何让东西向流量经过安全网关，同样是个流量牵引的问题；
- 基础架构不同，产品适配方式和部署方式可能都有很大区别。如安全网关在VMware、Xen和KVM等环境下，都需要很多的适配工作，产品无法做到良好的普适性；
- 直接虚拟化出的产品，在性能、高可用、虚拟机迁移等关键指标方面无法满足云环境下要求；
- 物理环境下的安全运维是独立的，但在云环境下（无论是openstack、vmware、公有云、私有云和混合云）都对安全产品的运营方式提出了极大的挑战，不同的平台、环境和客户要求都不同，产品管理也难以做到普适性；
- …
以上仅仅是虚拟安全网关所碰到一些典型问题，在实际应用的过程中还有大量水土不服的症状需要解决。
四、技术路线虽然面临很多难题，但是学术界和产业界早已经开始了尝试、探索和产品化，Gartner在2013年关于虚拟防火墙的Competitive Landscape[3]中提到了有如下技术路线：
- Host Agent Method
主机代理方式，类似杀毒软件模式，在每一台VM上都需要安装，并且产品依赖于VM上的操作系统。此种模式提供杀毒和IPS，但不提供网络层的过滤。 - Virtual Switch Method
基于虚拟交换机的方式，在虚拟交换机上只能应用简单的ACLs，高级别的安全防护需要将流量牵引到防火墙上。 - Hypervisor-Based Controls Method
利用Hypervisor的API和联动机制来实现流量牵引，从而达到过滤和防护的目的。 - Non-Hypervisor-Based Controls Method
安全网关以虚拟机的方式运行，不依赖于hypervisor。但正如前面提到，将流量路由到防火墙上是个难题。
针对以上分类进行解读，主机代理方式超出了网络边界防护的范畴，不做重点解读；基于虚拟交换机的方式目前并不能做一些高级的安全防护，只能做一些简单的ACLs控制；而本文重点解读Hypervisor-Based Controls Method和Non-Hypervisor-Based Controls Method两种方式，并起将其重新细分，以脑图的方式给大家呈现一个更清晰的技术路线。
4.1 Non-Hypervisor-Based将安全网关以虚拟机的方式运行，虽然Gartner将其命名为Non-Hypervisor-Based，其实也不完全合理，从原理上来看，虽然只是以虚拟机的方式运行在云平台，貌似并不依赖于平台，但实际上针对不同的云平台，镜像还是需要做很多的适配工作，并不完全独立于hypervisor。从产业界来看，这种技术路线基本应用在openstack+kvm的环境组合中。本文将该技术路线继续细分，分别为Service chain, Service VM和Service type三大类。
4.1.1 Service chain服务链（service chain）：数据报文在网络中传递时，按照业务逻辑所要求的既定顺序，经过各种各样的服务节点，包括防火墙、入侵检测和负载均衡等。该技术主要利用SDN等技术来实现控制平面和数据平面的解耦，从而实现灵活的网络服务可编程。
目前基于服务链的虚拟安全网关产品化的方案在业界较少，原因是该方案过于依赖于云平台技术的发展（包括SDN和NFV等），而目前SDN等技术在云中还没有标准化，未到达普及和大规模商用的阶段。基于服务链的虚拟安全网关的技术路线目前主要集中在科研和实验室阶段。如Karamjeet Kaur[4]实现了基于SDN的防火墙系统；Hongxin Hu[5]在论文中实现了基于快慢转分别调度的方式，极大提高了数据在流经服务链时的效率；此外还有云平台厂商因为具备建设云平台的能力，利用service chain将自有的安全产品虚拟化并推出了相应的商业化的版本，但应用并不多。
本文认为基于服务链的技术路线是解决虚拟网关类产品在云中部署和业务统一编排的较优路线，随着SDN/NFV技术的发展以及标准和框架的完善，安全厂商需要提供更有竞争力的软件安全产品来迎合基础框架建设完成之后的爆发期。
4.1.2 Service VM
Service chain路线还未大规模商业化，那该如何解决将流量牵引到虚拟安全网关呢？各个厂商都利用手工或自动化脚本来更改租户默认网络配置，将安全网关接入到网络中。这种方式被广泛应用在公有云和openstack环境下的私有或专有云（如checkpoint）。本文暂且把其称为“服务虚拟机（service vm）”路线。
- 公有云基于租户的网关接入方式：将虚拟网关单臂部署，采用两次NAT的方式，来将流量牵引到网关上（见图4）。
- Checkpoint：在openstack的环境下，checkpoint的虚拟安全网关在创建子网时，手工将网关串联到到交换机上，实现对子网的防护（见图5）。这种方式更改了用户的网络拓扑，并且配置复杂。
图 5 Checkpoint网关在openstack环境下部署方案
- 东西向防护：国内有厂商利用手工添加交换机的方式，将防火墙透明串联在两台虚拟交换机之间来实现东西向流量防护。虽然实现了东西向防护，但对用户网络改造过大，并且当虚拟机迁移时，会频繁的修改用户的网络拓扑和配置，配置复杂且对稳定性有一定的影响。
Service vm的技术路线无论是南北向还是东西向流量防护都存在着改变云租户默认网络结构的情况，尤其是东西向流量防护，改动较大，存在一定的局限性。
4.1.3 Service insertion
以juniper、cisco和fortinet为代表的巨头通过开发包括虚拟交换机、路由器和安全网关在内一整套的网络套件（相当于openstack的neutron和VMware的NSX）来实现在云计算时代的转型，而这种方案类似openstack社区提出的service insertion技术。通过此技术来实现L4/7层服务框架，而FWaas（Firewall as a service）、LBaas(Loadbance as a service)等技术方案也逐渐发展起来，通过重载openstack提供的原生态的安全功能（如安全组、过滤规则等）来实现网关的高级别防护。比如Mcafee在openstack环境下替代了虚拟路由器来实现网关功能；Fortinet替代了虚拟交换机和路由器来将安全功能嵌入；国内某运营商在解决方案中也开发了虚拟安全路由器来实现安全网关的功能。但这种方式需要覆盖虚拟路由器，客户接受度还需要考察。
4.2 Hypervisor-Based这种方式主要利用云平台提供的API和服务框架来实现第三方安全产品的深度集成，目前主要应用在VMWare平台上，由早期VMSafe进化到现在的Service Composer方式。Palo Alto、Checkpoint和Fortinet都利用VMware提供的接口将自己产品编译成VMware的一个“安全进程”，从而来实现在NSX环境下南北向和东西向流量的防护。
这种方案是云平台厂商利用自己的优势地位，建立生态环境，使各个安全厂商进入并提供产品。这种方案定制工作量大，与云平台厂商耦合性强。
五、展望与总结虽然学术界和产业界做了很大的努力，但是目前的解决方案普遍还存在很多问题：
- 适应性：性能、高可用和虚机动态迁移等云环境固有特性难以满足；
- 普适性：目前的产品太过于依赖云平台，基本上每个厂商要想覆盖这块市场，就必须针对每一款云平台都研发相应的产品和适配技术，甚至公有云和私有云等解决方案都不相同，工作量巨大；
- 管理难题：目前用户普遍采用统一的云管平台来管理整个云平台，而安全产品的管理界面必须提供相应REST API来面向北向的管理。这部分的定制工作量也是很大的。
随着云计算的发展，对安全的需求也会越来越迫切，市场一定会倒逼产业界实现更利于云中安全的体系。
六、参考文献[1] 中国云计算生态系统白皮书(2014-2015)
[2] https://en.wikipedia.org/wiki/Multitenancy
[3] Competitive Landscape: Virtual Firewalls Published: 27 August 2013
[4] Building Stateful Firewall Over Software Defined Networking Karamjeet Kaur , Japinder Singh
[5] FlowGuard: Building Robust Firewalls for Software-Defined Networks Hongxin Hu, Wonkyu Han, Gail-Joon Ahn and Ziming Zhao In Proceedings of ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN 2014), Chicago, IL, USA, August 22, 2014
| 欢迎光临 开发者俱乐部 (http://xodn.com/) |
Powered by Discuz! X3.2 |
