从“软件定义”到“智能协同”

安全 应用安全 云安全
大数据分析以及人工智能的发展,使得安全智能化成为可能。本文从软件定义着手,结合云安全技术路线的三个阶段,详细阐述了为什么云安全一定要实现智能协同化,这种智能协同是否可行以及如何来实现。

大数据分析以及人工智能的发展,使得安全智能化成为可能。本文从软件定义着手,结合云安全技术路线的三个阶段,详细阐述了为什么云安全一定要实现智能协同化,这种智能协同是否可行以及如何来实现。

云安全,从“软件定义”到“智能协同”,是趋势、是必然,当然也是挑战。

[[217484]]

一、概述

“软件定义”的概念,伴随着软件定义网络的兴起,曾一度被追捧。相继出现了软件定义存储、软件定义体系结构、软件定义数据中心、软件定义云计算等等,甚至出现了软件定义一切。当然这其中也包括了软件定义安全。

那么软件定义为何如此备受青睐呢?笔者认为,软件定义提出了一种对于解决问题近乎完美的想法,它把所有美好的愿景都寄托在了逻辑上集中的控制中心,尤其是随着虚拟化和云计算的不断发展和应用,这种集中控制的需求显得越来越迫切。

图1 软件定义的三个层次

软件定义是一种态度、是一种思想、是一种架构。这种架构思想包含三个层面上的内容:首先就是最下面的资源层,也可以称作基础设施层,或者叫执行层,是需要被控制和操作的对象;其次就是控制层,这是软件定义架构里面的集中控制中心,是下面执行层所执行操作指令的发出者;最后就是上面的应用层,基于具体的业务需求,实现不同的应用,进而通过控制层将相应的控制逻辑下发到执行层,转化为对应的执行操作指令。

软件定义也仅仅是一种架构思想。从整个系统来看,实现了软件定义,也就相当于实现了系统的骨架,真正的思维和灵魂,是上层的应用。这和互联网时代所谓的“应用为王”是相通的。

那么回到云安全,云计算的特性决定了传统的安全解决方案对云安全来讲,是不能完全复制、复用的。在这里,笔者将云安全的技术路线总结为三个阶段:

云安全技术路线

图2 云安全技术路线

1. 安全设备虚拟化

在云安全发展的早期,由于云计算的资源虚拟化、多租户、弹性伸缩等特性,传统的“安全盒子”方案没有办法解决云中的安全问题了。那么简单而有效的办法,就是将“安全盒子”也进行虚拟化,具体体现形式就是由硬件设备变成虚拟机。

这样不同的租户,根据各自不同的安全需求,在其租户网络内进行安全虚拟机的申请、部署、使用。比如某租户需要对其业务系统进行入侵检测、web防护,那么他就可以申请购买一台虚拟化IDS和WAF进行部署。

这种单纯的虚拟化方式,其实和传统数据中心的安全方案并没有太大的差别,只不过是把硬件设备变成了虚拟机。安全设备的管理、配置、运维还是需要用户人工登录到各个设备进行操作。

这样,简单粗暴的虚拟化方式,就形成了第一阶段的云安全解决方案。基本实现了对云环境进行专业安全防护的从0到1过程。

2. 安全资源池化(软件定义)

随着人们对云安全认知的不断深入,大家不再满足于这种简单粗暴的方式。

从云服务提供者角度来看,他会考虑所有租户独占一套安全设备虚拟机时,对于云中的资源利用率来说,性价比是否合适;

从用户的角度来看,1)租户独占方式购买、部署安全设备虚拟机,其安全成本是否合适,据笔者了解,单独的安全设备虚拟机在云里面的价格,也是不低的;2)安全运营成本是否合适,一方面需要像传统安全设备一样,逐个的对每个安全虚拟机进行安全策略的配置,繁琐麻烦;另一方面,安全设备又包括透明模式、代理模式、旁路模式等多种的部署方式。这都需要具有一定安全背景的专业人员才能够完成的。

那么在这个阶段,基于软件定义安全的云安全方案就应运而生了。安全资源不再是租户独占的安全设备虚拟机,而是通过安全资源池化的方式,为租户提供无感知的安全服务。

这样一方面对于云服务提供商来说,池化的方式可以更好的提高其资源利用率;另一方面,对于用户来说,服务化的方式既不需要自己进行复杂的部署,也可以通过安全应用尽可能的降低其安全运营成本。

基于安全资源池的云安全方案

图3 基于安全资源池的云安全方案

3. 安全防护智能化(智能协同)

正如前文对软件定义的描述那样,第二阶段的基于软件定义安全的云安全方案,算是将这种池化的安全系统骨架搭起来了。那么怎样在这个骨架的基础之上,将其变的有血有肉有灵魂,就是安全防护智能化需要考虑的了。

这里的智能化可以包括如何动态灵活的仅将必要的流量进行专业的安全检测;如何通过多个设备的自动化联动,实现复杂的攻击检测;如何针对检测到的异常准确的进行防护处置;以及如何不断提高自身的检测与防护精准度等等。

接下来,本文就将详细的介绍,进入智能协同时代,如何利用大数据以及人工智能的方式,设计实现更加完善的云安全解决方案。

二、智能协同

2017年“智能”这个词简直是太火了,以至于谁家的产品和方案不贴个“智能”的标签,根本不好意思拿出来讲。但是笔者认为智能化是有前提的,是需要积累的,就像我们想要造一艘能拉货过河的船,万吨油轮肯定是好的,但是如果连普通货船都造不好呢,谁又敢相信他的大油轮呢?

道理一样,今天我们谈智能协同的云安全,也一定是顺势而为,水到渠成的。

1. 什么是智能协同

所谓智能,根据维基百科的解释,可以将其总结为“让机器能够像人一样,可以观察周围的环境,进行感知、学习、分析,并且做出相应的行动以实现某种目标”。那么智能协同的安全防护,笔者将其定义为“安全防护系统能够进行威胁感知,并且调动所有可用的安全资源,主动的进行威胁检测防御,同时不断提升自己的威胁感知能力”。

Gartner在2016年提出了“自适应安全”(Adaptive Security)的防护模型,模型中包括了预测(Predictive)、防御(Preventive)、检测(Detective)和响应(Retrospective)这一持续处理的安全防护过程。自适应安全架构,是实现智能协同安全防护的一种典型架构设计方式。通过对四个阶段的划分,形成一个持续的闭环防御体系。

自适应安全模型

图4 自适应安全模型

在整个模型中,持续的监控和分析成为了其核心所在:

  • 预测能力强调安全系统需要具备持续对业务系统进行监控分析的能力,据此形成相应的安全基线,主动对业务系统进行风险评估以及威胁预测。
  • 防御能力指一系列安全防御产品和服务,提升威胁攻击门槛,防止事件发生。
  • 检测能力用于发现那些进入防御网络的攻击,对事件进行确认和处理,降低威胁造成的损失。
  • 响应能力需要能够对系统脆弱性提出修复意见,对威胁事件进行调查取证,同时更新预测手段,避免再次遭受类似的安全威胁。

2. 为什么一定要智能协同

那么为什么说云安全技术路线的第三个阶段一定是智能协同呢,我们从以下两个方面来看:

首先从云计算系统的角度来看,假如一个拥有50台计算节点的小型私有云,平均每台主机间的东西向流量为3G左右,双向的话大约就是5G—6G,那么如果要对所有的流量进行专业安全检测,就需要足够安全资源能够处理300G的流量。同时在这种情况下,云数据中心会额外增加一倍的东西向流量用于安全检测。这无论是对于计算资源,还是网络带宽资源,都是一笔不小的投入。

而这double出来进行检测的流量,其中异常的部分可能不及5%。因此,我们一定要让安全防护系统用一种“聪明”的方式来进行应对,而不是粗犷的“眉毛胡子一把抓”。这就是说,云安全一定要是智能的。

另外,从攻防的角度来看,攻击者的攻击手段千变万化。尤其是像APT这种高级持续性的威胁,攻击者在发动攻击之前会对攻击对象的业务流程和目标系统进行精确的信息收集,这种行为往往经过长期的经营与策划,并具备高度的隐蔽性。一旦发现可乘之机,便会对攻击对象发起大规模的攻击。

面对这种威胁,单一设备基于规则的安全防护和检测,在处理起来可能会有些力不从心。需要漏洞检测、入侵检测、未知威胁检测等多种手段,共同来应对。这就是说,云安全一定要是协同作战的。

3. 可行性分析

理想很丰满,现实情况是什么样的呢?下面我们对智能协同进行可行性分析。

可行性分析

图5 可行性分析

(1) 全局网络视图

作为云管理平台,网络监控以及流量可视化是基础也是必要的功能。这里的流量既包括南北向机房入口的流量、也包括整个Spine-Leaf层跨宿主机流量、同时还包括宿主机内虚拟化层的网络流量。这些流量信息都是可以进行采集、监控和分析的,只不过从上到下难度会逐渐的增加。

通过云管理平台的网络监控,一方面可以获取到flow层的信息,这层的流信息相对来讲还比较轻量,获取难度也比较小,比如通过SDN或者netflow等方式;另一方面可以获取到packet层的信息,通过端口镜像、专用采集器等方式,拿到完整的数据包,这个层面的监控相对来说难度会稍大一些,因为可能会涉及到一些租户的隐私。

这样把收集到的flow和packet连同租户以及租户网络信息放在一起,就形成了全局的网络视图。有了这个全局网络视图,就很容易对其中各个租户的相关流量信息进行分析和监控。

全局网络监控

图6 全局网络监控

(2) 流量画像

据笔者了解,无论是公有云还是私有云,用户在虚拟云主机上,主要包含两种类型的业务:一种是自身的业务系统,比如门户网站、办公系统、信息系统之类的;另外一种就是集群计算系统,主要用于后端的数据运算。而无论是哪种业务,它们都有一个共同的特点,就是云主机之间的东西向流量一定存在某种固定的特征,比如某个主机开放哪些端口、这些主机和端口的访问客户端是哪些主机、他们通常会在什么时间段进行什么样的流量交互、流量大小又有什么样的特征等等。

我们可以将这种特征称之为流量画像,或者行为基线。那么如果某一时刻,实时流量和画像描述的特征不符,那么这种“另类”的流量就很有可能是存在安全威胁的。

(3) 攻击链

下面再从攻击链的角度看一下。攻击链是根据攻击者对目标系统入侵的不同进展程度进行阶段划分,将各个阶段串联形成完整的攻击过程的模型。对于攻击链中的每一阶段,都可以通过流量监控/检测提取出来的特征属性,间接判断出威胁攻击的进展。比如在侦查探测阶段,可以通过发现异常的端口访问,或者在工具分发阶段发现异常大小数据包等,更早的发现并预防威胁的发生。

由于攻击者攻击手段的隐蔽性,以及攻击链模型中各阶段的界定有一定的模糊性,单个阶段难以评估目标遭受入侵的严重程度,因此可以对各阶段之间进行关联分析。同时与流量画像进行对比分析,发现可疑流量。

攻击链模型

图7 攻击链模型

(4) 安全资源池化

池化的安全资源是安全防护基础性保障,能够根据检测防护需求,快速动态的进行资源的生成、配置、使用,同时还可以灵活的实现多种安全手段的有效联动。这部分作为先决条件,前文已经进行了详细的介绍,这里就不再赘述了。

云计算系统有着全局的网络视图,能够对其中的网络信息进行监控和分析,结合其应用特点,进而可以生成相应的流量画像。一旦发现网络流量特征与画像不符,便可以通过池化的安全资源进行深度精准的检测。

三、实践方案

下面的架构图展示了一种智能协同的云安全设计方案。

右半边是云计算管理平台,通过流量采集,将所有的流量信息进行“可视化”,这里的流量既可以flow级的,也可以是packet级的,流量采集的手段当然也可能是netflow、SDN或者其它方式,不同的云服务提供商,可能会有不同的实现方式。

方案架构图

图8 方案架构图

左半边为安全资源池,通过安全控制平台对其中的各种安全能力进行统一管理。最上层实现为智能协同的安全应用,AI应用根据云平台中的流量监控信息智能的生成防护方案和策略,编排模块据此调用对应的安全资源进行防护响应。方案流程可参考下图。

方案流程图

图9 方案流程图

在服务上线前(确保无威胁存在),AI应用从云计算管理平台获取租户所有的监控流量信息,形成相应的流量画像,作为其流量行为基线。系统上线后,实时获取流量监控信息,对于符合流量行为基线的流,则认为是正常的。

对于与画像不符合的流,则通过编排应用,生成相应的安全审计流程,针对这部分流进行更深入的安全审计,审计结果可转化到实时的防护规则。

安全资源池的防护结果,可以反馈到AI应用,AI应用根据这个结果不断的调整其判断的准确性。当然,考虑到误报,这个过程必然会需要一定的人工参与。AI应用应尽可能地从流程、视图和算法层面降低人力投入成本。

上述方案仅仅是对于云安全智能协同化的一个简单设计,算是抛砖引玉。真正实现这种智能协同化,还是有很长一段路要走的。

四、总结

本文从软件定义着手,结合云安全技术路线的三个阶段,详细阐述了为什么云安全一定要实现智能协同化,这种智能协同是否可行以及如何来实现。

云安全,从“软件定义”到“智能协同”,是趋势、是必然,当然也是挑战。

【本文是51CTO专栏作者“绿盟科技博客”的原创稿件,转载请通过51CTO联系原作者获取授权】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2014-12-05 10:51:57

软件定义存储闪存云应用

2023-02-20 10:15:00

云协同边缘

2010-12-22 12:00:48

软件保护软件授权

2015-09-17 13:09:48

预装软件毒瘤国产手机

2013-01-04 10:35:34

网络交换机路由器

2011-12-30 15:37:13

软件加密软件授权软件保护

2020-05-26 21:04:01

物联网能源技术

2015-10-10 09:37:12

软件定义技术软件定义

2010-05-18 20:04:05

物联网智能计算

2023-09-19 09:28:47

AI视觉

2019-05-26 23:26:19

智能监狱物联网IOT

2019-09-03 22:02:29

智能制造AWS

2017-06-07 10:54:09

2009-03-14 09:31:50

企业软件移植智能手机

2011-11-28 10:10:24

手机手机设计

2015-05-28 15:12:14

普元BFVSOA

2018-03-07 07:26:27

2018-05-24 16:57:17

微软人工智能Azure

2015-10-28 17:19:20

点赞
收藏

51CTO技术栈公众号