云安全三大趋势：纵深防御、软件定义安全、设备虚拟化

云安全三大趋势：纵深防御、软件定义安全、设备虚拟化

摘要：传统IT架构发展到云架构的今天，传统信息安全的分散割据化、对应用的封闭化、硬件盒子化已不再适合新一代应用的需求。未来信息安全与应用的跨界融合是主流方向，而这种融合又催生了信息安全三个维度的发展方向。

本文从当今信息安全产业割据化、封闭化、硬件化的三个特点入手，结合典型云平台架构分析了信息安全和云平台之间日趋严重的鸿沟，并提出了对应的解决思路，即信息安全的三个发展趋势：信息安全自身发展的纵深防御（Defense in Depth）、由应用与信息安全二者融合驱动的软件定义信息安全（SoftwareDefined Infomation Security）、由虚拟化技术和信息安全二者结合驱动的安全设备虚拟化（SecurityDevice Virtualization），这三者结合后形成了一套更安全、敏捷、经济的云平台安全体系。

一、 传统信息安全和云计算的兴起

在传统的信息安全时代主要采用隔离作为安全的手段，具体分为物理隔离、内外网隔离、加密隔离，实践证明这种隔离手段针对传统IT架构能起到有效的防护。同时这种隔离为主的安全体系催生了一批以硬件销售为主的安全公司，例如各种FireWall（防火墙）、IDS/IPS（入侵检测系统/入侵防御系统）、WAF(Web应用防火墙)、UTM(统一威胁管理)、SSL网关、加密机等。在这种隔离思想下，并不需要应用提供商参与较多信息安全工作，在典型场景下是由总集成商负责应用和信息安全之间的集成，而这导致了长久以来信息安全和应用相对独立的发展，尤其在国内这两个领域的圈子交集并不大。结果，传统信息安全表现出分散割据化、对应用的封闭化、硬件盒子化的三个特征。

但随着云计算的兴起，这种隔离为主体思想的传统信息安全在新的IT架构中已经日益难以应对了。在NIST(美国国家标准技术研究所)的规范中云计算被分为三层，SaaS解决了应用软件的即买即开即用，IaaS解决了承载应用所需计算资源的动态变化，而PaaS解决应用在全生命周期变化所带来的问题。本文重点分析更为基础的IaaS和PaaS。

二、 公有云场景下隔离原则失效，纵深防御是必然趋势

公有云的典型场景是多租户共享，但和传统IT架构相比，原来的可信边界彻底被打破了，威胁可能直接来自于相邻租户。当然聪明的人们在小心翼翼的设计，防止虚机逃逸、防止租户间网络监听、防止每个单点功能上的漏洞，但是例外情况总是会有的。

在典型开源IaaS平台-OpenStack应用场景中，很多租户通过Hypervisor(虚拟机监视器)共享同一个物理操作系统的计算资源，在一张共享的二层网络上实现网络的区隔。以OpenStack的G版本为例，攻击者一旦通过某0day漏洞实现虚拟逃逸到宿主机（即OpenStack中的Nova节点），攻击者就可以读取这台宿主机上所有虚拟机的内存，从而可以控制这台宿主机上的所有虚拟机。同时更致命的是，整个OpenStack节点间通讯的API默认都是可信的，因此可以从这台宿主机与集群消息队列交互，进而集群消息队列会被攻击者控制，最终一举端掉整个OpenStack集群。

接着说PaaS，主流PaaS普遍采用进程隔离的container技术(例如Linux内核中的lxc)，这种技术的安全成熟度还不如Hypervisor，攻击原理同上述OpenStack，这里暂不展开。从功能上，主流PaaS一般针对应用的源代码管理、持续集成、部署、运维做自动化处理，而从安全角度看这意味着可信边界的弱化，比如说一旦持续集成这个节点被攻击者控制，后续的部署、生产环境运维都会直接暴露给攻击者。因此，云的快速和自动化在这里是一把双刃剑，如果存在漏洞，危害的发生同样很快。

再说大数据，安全圈有种说法，“大数据时代最先受益的是骇客”。以前还要逐个攻破，现在数据集中了，直接可以一锅端了。集中化的大量数据，带着N个副本存储在不同的IDC，在大量的分布式节点上计算着，数据的所有者如何确保自己的数据是安全的？大数据加上公有云，如果缺乏有效的安全防护，将会成为骇客们的盛宴。

因此从信息安全自身发展来看，纵深防御(Defense in Depth，以下简称DiD)是经典信息安全防御体系在新IT架构变革下的必然发展趋势。原有的可信边界日益削弱、攻击平面也在增多，过去的单层防御(Single Layer Defense)已经难以维系，而纵深防御体系能大大增强信息安全的防护能力。纵深防御两个主要特性是【观点来自@phreaker】：

1. 多点联动防御

在过去的安全体系，每个安全节点各自为战，没有实质性的联动。而如果这些安全环节能协同作战、互补不足，则会带来更好的防御效果。例如FireWall、IDS/IPS、WAF、UTM、SIEM(安全信息和事件管理)等之间的有机联动，可以更加准确的锁定入侵者。

2. 入侵容忍技术（Intrusion Tolerance Technology）

以OpenStack为例，我们假设虚拟逃逸是存在的。因此我们的设计原则是：即使攻击者控制了某台Nova节点，我们会通过安全设计手段避免攻击者进一步攻击OpenStack消息队列，或攻击这台Nova的其他虚机。

现状信息安全产业，普遍是单层防御，而非纵深防御，其中一个原因由于安全厂商的分散割据化造成的，例如FireWall、IDS/IPS、WAF、UTM、SIEM、PKI(公钥基础设施)、SSL网关、代码审计、终端安全、加密机等不同厂商，同时这种安全厂商的分散割据化现状也会阻碍纵深防御的进一步发展。如何把分散割据的各安全厂商的能力有效整合形成联动，是需要我们深思的，也许接下来要探讨的软件定义信息安全会是一个手段。

三、 安全设备的封闭化阻碍了安全发展，未来安全设备的开放化是趋势

在过去的许多年，传统安全厂商呈现了封闭化特征。虽然设计了大量安全软件，例如FirwWall中的规则实现、IDS中的业务逻辑，但这些软件并不是为用户设计的，而是被安全厂商写死在安全硬件设备中、作为软硬件捆绑的一体化对外服务。这样导致了用户无法灵活的利用安全软件来结合自己的业务场景做深入结合，例如针对特定应用场景下的流量清洗。同时传统安全厂商的这种封闭性，也阻碍了各个安全设备之间联动整合，进而难以形成联动防御。

封闭化的安全设备，从某种意义上维护了传统安全厂商的利益，但是却损害了用户的利益。而从用户的角度来看，未来安全设备的开放化、可编程化很可能是个趋势，软件定义信息安全（Software Defined InfomationSecurity，以下简称SDIS）这个概念正是为用户的这种诉求而生。SDIS强调安全硬件设备的可编程化，这样使得用户可以灵活的把安全硬件设备和应用场景化、深入结合、联动防御。所谓Software Defined，不仅是应用软件与安全设备的API级互动，更重要的是各安全设备之间、或纵深防御大脑系统与安全设备之间的API级联动，这样才能有效的构建纵深防御。从这一点上，也可以说SDIS为构建纵深防御体系提供了可能。而从应用软件威胁的角度看，新的攻击方式是更加高级、上层的方式。例如针对某电商网站高价值商品的恶意下单攻击，具体做法是网站一搞促销，攻击者就用注册好的账号抢光高价值商品、但却延迟支付，对付这种攻击方式的一种解决思路就是让应用软件的恶意下单检测模块与FireWall互动。

Software Defined的精髓在于打破了安全设备的生态封闭性，在尽量实现最小开放原则的同时，使得安全设备之间或安全设备与应用软件有效地互动以提升整体安全性，而非简单理解为增加了安全设备的风险敞口。事实上在传统安全设备的封闭生态下，如果违反了最小开放原则或存在其他缺陷，即使是一个不开放API的安全设备盒子也同样有可能存在漏洞。而SDIS恰恰是为了提升系统的整体安全性，而对个体安全设备做了必要的API开放。

SDIS不是一个具体的技术（相比较而言，SSL网关、WAF、加密机是具体的技术），SDIS是一种应用信息安全的设计理念，是一种架构思想，这种思想可以落地为具体的架构设计。基于SDIS的设计理念，用户的意志最重要，传统安全设备厂商按照约定的SDIS规范（SDIS规范由甲方联盟主导制定）提供细分领域的专业安全设备，同时市场上也会出现一些符合SDIS规范的白牌安全设备，用户通过API级的互动，深度整合这些安全设备形成一个有机的整体，提升了整体安全性。举个例子，实时采集环境中所有安全设备的日志，经过一个智能的大脑系统分析（例如Splunk），是可以得出更有意义的结论，进而反馈给相关的安全设备。对用户的另外一个好处是，如果SDIS驱使安全设备开放了标准接口，进而会培养一批市场上的垂直领域的专业安全服务商、或白牌安全设备厂商，那么传统安全设备厂家再也不能大包大揽了，用户从此不再被安全设备厂家绑架。

如果对比流行的网络技术-SDN(软件定义网络)，SDIS技术架构也许会有如下模块：SDIS南向接口（安全设备与大脑系统的API）、信息安全大脑系统（类似SDN的Controller）、SDIS北向接口（用户与大脑系统的接口或界面）。再从软件定义信息安全SDIS的概念命名来看，软件二字既可以是应用软件，也可以是纵深防御的大脑系统。

四、 虚拟化技术和安全设备的结合，驱动了云上的安全设备虚拟化、混合化

传统安全厂商有硬件化的偏好，尤其是在国内，安全厂商倾向于做成盒子形式销售，而非卖软件+服务。典型的做法是，某安全厂商研发一套安全软件，但把软件预装在一台2U的Linux服务器上，再贴牌销售。除了加密机等几种特例，大多数的安全设备盒子并非特别针对硬件的定制或加速，其实就是把软件和硬件搭配在一起而已。

而到了云平台上，成千上万的多租户共享着相同的物理资源，这种安全硬件盒子的方式已经难以满足需求了。也许对一个传统安全从业人员来说，公有云是一个安全令人堪忧的事物，但现状是谁也无法阻挡公有云的蓬勃发展。因此在云平台上我们只能顺应这种潮流，对传统安全的硬件化进行必要的创新，在确保安全的前提下把安全软件从硬件盒子里搬出来放到云中，这就是安全设备虚拟化（SecurityDevice Virtualization，以下简称SDV）。SDN是安全硬件的软化（例如Hypervisor化、或container化、或进程化），也即利用各种不同的虚拟化技术，借助云平台上标准的计算单元创造一个安全设备。

SDV带来的好处是大大降低了成本、同时提高了敏捷度、降低了成本、甚至提高了并发性能（比如利用scale out的横向扩展和云资源的弹性扩容）。但我们也要认识到，和硬件安全设备相比，SDV增加了攻击平面、降低了可信边界，需要我们小心翼翼的设计SDV的整个技术架构、在全生命周期中谨慎管理虚拟化安全设备，以避免带来新的威胁。

事实上，云平台上的SDV也是一个被迫的选择，举个例子，假如如果没有SDV，整个云平台使用一台高性能硬件WAF去一刀切式的防护云端的一万个网站，针对不同业务的网站很难有效的定制规则，无疑是形同裸奔。与其裸奔，倒还不如有虚拟化的WAF实例针对不同业务的网站做有针对性的防护。当然在某些场景下，我们可以把传统硬件安全设备和虚拟化安全设备做一个混合部署，把安全性和经济性巧妙地结合起来。

五、 DiD、SDIS、SDV三者是正交的，融合设计后能能形成完整的安全体系

在云平台上，纵深防御(DiD)、软件定义信息安全(SDIS)、安全设备虚拟化(SDV)三者既是相互独立的、正交的，又相互发生联系。如下图所示：

软件定义信息安全（SDIS）和安全设备虚拟化（SDV）容易混为一谈，因此我们再做个进一步分析。SDIS强调安全设备的打破封闭性、提高可编程性，同时尽量收紧安全边界（例如API最小开放、API调用有身份认证），SDIS强调各安全设备之间、或应用与安全设备的互动，以形成防护效果最大化。而SDV是从硬件虚拟化的角度来看的，纯粹是为了满足在云平台上构建一个安全防御单元，达到快捷、省钱、高性能的目的。

因此如果一个硬件安全设备本身有针对应用的API，那它也可以实现SDIS。反之即使一个安全防御单元并没有向应用开放API，这个安全防御单元也仍然可以用虚拟化的方式构建（例如hypervisor虚拟机、container容器、或一个进程）。为了进一步证明SDV与SDIS是正交的，罗列出以下4种可能组合：

1）非SDV（硬件安全设备）+非SDIS（不向应用开放API）：信息安全传统架构；

2）非SDV（硬件安全设备）+SDIS（向应用开放API）：安全厂商的硬件安全设备向应用开放编程API；

3） SDV（虚拟化的安全设备）+非SDIS（不向应用开放API）：仅仅把安全厂商的硬软件用虚拟化技术实现；

4）SDV（虚拟化的安全设备）+SDIS（向应用开放API）：安全厂商的安全设备是虚拟化的，同时也对应用开放了编程API；

六、 SDIS和SDV带来的潜在安全威胁及应对

必须严肃正视的一点是，虽然SDIS和SDV带来了很多好处，但同时增加了攻击平面，例如针对安全设备开放API的攻击、针对虚拟化安全设备的Hypervisor层的攻击。因此我们要谨慎设计并把握三个原则：

1）收紧攻击平面。例如大脑系统和安全设备的API互动，设计一个身份验证机制，防止其他节点或恶意应用仿冒成大脑系统给安全设备发指令。

2）入侵容忍技术（Intrusion Tolerance Technology）。例如安全设备API开放最小化，同时针对敏感API的恶意调用行为有检测和报警模块，这样万一大脑系统也被攻击者控制，我们也留有一个应急处理机制。

3）对敏感业务强制人工审核。例如大脑系统经过分析认为某安全设备策略应当调整，接下来由经验丰富的管理员人工确认这个策略调整。这也可以看作是一种半自动化。

事实上绝对意义上的安全也许是不存在的，因此我们要利用上述三个原则想方设法增大攻击成本，最终使得攻击者在权衡攻击成本和窃取信息价值后选择放弃。

综上所述，在传统IT架构发展到云架构的今天，传统信息安全的分散割据化、对应用的封闭化、硬件盒子化已不再适合新一代应用的需求了。信息安全和应用的关系亟待一场变革，从变革的目标看，信息安全与应用的跨界融合是主流方向，安全最终一定是由业务和应用驱动的。而这种安全和应用的跨界融合，催生了信息安全三个维度的发展方向：信息安全自身发展的纵深防御（DiD）、由应用与信息安全二者融合驱动的软件定义信息安全（SDIS）、由虚拟化技术和信息安全二者结合驱动的安全设备虚拟化（SDV）。信息安全在这三个维度演化出来的新技术融合以后，能否形成一套更安全、敏捷、经济的下一代云平台安全体系？这需要我们进一步的实践和探索。

原文链接：https://blog.csdn.net/liangzhao_jay/article/details/35271675