新闻动态
随心所欲——软件定义安全的架构与实践
发布时间：
2019-06-24 14:16
来源：
作者：
访问量：
微隔离的核心能力或者核心价值是什么呢？目前大家普遍理解的是东西向流量分析，点到点访问控制。这个理解不能说错，但还不本质。事实上微隔离又叫软件定义隔离，它最核心的诉求是实现随心所欲的隔离能力。或者换言之，是可以让用户在任何时候，对任何工作负载（不管在哪里，不管有多少，不管是虚拟机物理机还是容器），进行任何方式的访问控制能力。
软件定义安全，最初是数据中心发展变化的产物，但同时又是自适应安全架构的一个必然要求。
随着数据中心的整个技术体系都倾向于软件定义模式，使得安全技术也不得不跟上这个脚步。这里先说下啥叫软件定义。一般解释软件定义都会从正面对其做出说明，这种解释方法大家自行百度即可，我倒是更愿意从反面给个定义。所谓软件定义是相对硬件定义而言的，过去计算能力是严格与硬件绑定在一起的，比如说，这个机架属于研发部门，那个机架属于测试部门，另外三个机架是生产部门的，上面每一台服务器每一个交换机都承载着特定的数据与业务，从其上架之日起基本没什么变化。但软件定义不是这样，最典型的软件定义就是服务器虚拟化，软件定义把计算能力从物理设备上解耦了出来，从而可以以服务的形式向用户交付，用户不需要了解这个能力的物理位置在哪里，事实上也没啥固定位置，一会儿在这一会儿在那。再比如软件定义网络（SDN），过去交换功能是由每一台交换机自己决策的，交换机彼此之间通过协议协商构建起一个交换网络，但具体的交换决策仍然由一台硬件设备来独立作出。但是在SDN模式下，这个决策就不是每台交换机自己来决定了，而是由一个统一的控制器从全局视角进行统一的定义和管理。
既然整个IT架构都由软件定义了，那么安全也当然应该由软件来定义。由硬件来定义的能力都是相对稳定的，毕竟我们没看见过哪个机架上的机器没事自己到处溜达。所以安全当然也可以由处于特定位置的物理设备来承载。而当计算资源在软件定义模式下变得不再稳定时，安全当然也必须跟着一起动起来。也就是用户可以随需的在某个不确定的位置获取计算资源的时候，我们也必须有可以把安全能力投放到那里去，无论那个资源在哪里。这就是软件定义安全。
我们说软件定义安全大概分三个层次，每个层次可以实现不同的能力。
第一个层次，是指能够在任何位置按需交付安全服务的能力。如前所述，这个能力是软件定义安全的初心。过去的安全能力承载于物理设备之上，而物理设备是有固定位置的，所以安全能力的交付范围也就是固定的。而软件定义安全就是要把安全能力从物理设备中解脱出来，使得安全不再是一个固定的设备，而是一种按需交付的服务。这里需要指出，不仅仅是在公有云上如此，在私有云也是这样。私有云的安全管理者所面临的最大挑战就是如何在庞大且复杂多变的虚拟化环境中将安全按需交付到指定的业务。
第二个层次，是指对安全进行策略化管理并根据计算环境实时交付的能力。或者换言之，是把安全与IT基础架构相分离的能力。并非所有的软件定义安全都能够实现这一能力，比如一些虚拟防火墙，资源池等产品，其策略的编写仍然是面向基础架构的，其利用的参数，仍然是例如IP,VLAN,MAC等基础架构参数。而根据软件定义安全的精神，我们应该尽量使安全与基础架构无关。安全的策略应该面向更高级的逻辑对象，比如身份，ID，角色等等，利用这种策略，甚至可以做到安全的预装载，也就是在研发过程中就编写好安全策略，而当业务交付时，安全能力和业务一起交付，也就是现在流行的DevSecOps原则。这样一来，安全与安全作用对象相脱耦，安全管理者可以聚焦于安全策略本身，基础架构不再需要被考虑。软件定义安全的基本方向就是把服务能力与硬件相脱耦，只要你的策略还是与具体的基础架构参数相关，那么就还不是软件定义的工作方式。软件定义要做到，把特定的服务交付给业务对象，无论他在哪里。
第三个层次，是指能够对安全决策进行实时干预的能力，一般来说到这个时候才是完整的软件定义安全。这里我们再说一下安全资源池。通过与SDN联动，资源池可以做到把安全能力按需交付到指定业务。但是此时的安全决策仍然是由虚拟化的安全设备独立完成的，这个只能算软件定义安全的初级阶段，如果安全决策可以由更上层的决策引擎比如SIEM，威胁情报等进行驱动，就可以实现决策的运行时干预。也就是说，过去的安全能力，是预设定的，一旦上线后就按照配置好的规则来进行防御。但是根据自适应安全的架构，我们需要引入更多的实时的context信息来进行决策，这些context包括但不限于，设备类型，行为基线，业务发生的时间，来自其他安全设备的IOC等等。甚至于这个决策也不是在单台设备上做出的，而是在更高级别的安全运营中心中通过大数据的分析来形成的，这个时候，安全设备只需要开放自己的控制能力的API供管理中心进行调用即可，此时一个经典的自适应安全架构才得以实现。
总结一下，软件定义安全的三个层次，首先是安全交付位置可按需选择，然后是安全策略可以抽象描述，最后是安全决策可以参考环境信息，甚至完全将决策点与控制点分离从而最终实现一个完全的软件定义的，自适应的安全体系结构。
事实上，根据上面提出的软件定义安全的三层次理论，我们也可以给出一个软件定义安全的技术架构模型，不仅仅安全产品可以基于这个模型来做，整个云计算系统的安全管理架构也可以参考这个模型，而且可以分层来做，从低到高，逐渐优化。
第一层：安全服务层
在这一层，要负责向上层提供一个可以随需调用的安全能力。
这里我们要讨论一下，究竟该如何实现这样一种能力呢？目前看，就两大类技术。一类是资源池技术，一类是主机技术。
先说资源池。资源池是一种山不转水转的思维方式，他在一个集中的位置创建安全服务，以引流的方式将需要处理的业务引到这里来进行处理，从而实现将安全能力进行按需交付的要求。我们要强调的是，资源池本身只能完成安全能力的虚拟化创建过程，但他不能解决如何将创建出的安全能力向特定业务交付的问题，要解决这个问题需要SDN技术的配合。而难点也就在这里，SDN也罢，NFV也罢，都需要特定的网络基础架构予以支持，一旦基础架构不能配合（比如交换机不支持SDN功能，openstack的SDN模块不能开放），那么就会失去将安全服务交付进行交付的能力。
另一种技术就是基于主机的技术，这种技术的安全能力就在工作负载上，也就是说安全服务能力默认在整个云计算环境中已经部署完成了，不再需要考虑如何进行能力交付的问题，而只需要考虑如何利用这些能力进行策略设计。显然，在云计算时代，基于主机的安全能力更有优势。如果大家关注国外的安全技术进展，就会发现绝大多数的云安全创新都是利用主机技术完成的。
在端点技术与资源池技术中间，还有一种方案，就是所谓的无代理方案。事实上，”无代理”只是一个市场用语，他强调的是在虚拟机上没有代理，而相应的，他需要在每台宿主机上创建一个独立的虚拟机，这相当于在宿主机上装了一个代理，然后通过引流的方式将同一宿主机上其他虚拟机的流量牵引过来进行处理。而且即使这样，绝大多数的产品实现也都要求在虚拟机上安装一些代理，或者利用已经存在的云管理软件自己的代理（所有云计算环境的虚机镜像里都有云管理所必须的代理软件），只不过这个安装过程是通过云管理系统本身来完成的（或者预装的），对用户不可见。
第一层：安全服务层
第二层：策略计算与运维层
事实上，目前绝大多数的私有云用户的安全架构都聚焦在第一层上。但是真正令软件定义安全可以被使用的是第二层，我们称之为策略计算与运维层。
在前面的分析中，我们指出，有必要使安全策略与基础架构脱耦，因为这是软件定义安全的内在要求，也是适应不断高速变化的云计算环境的必然要求。
但是从抽象的高层次安全策略到具体的可以被底层安全服务所理解的安全配置命令之间一定要有个策略计算引擎来进行翻译，这样才可以把高层次抽象策略，根据目前的业务实际部署情况进行具体的安全配置。而且这个过程不是一次性的，而是一个实时执行，不断更新的过程，因为底层计算资源总在发生变化，而上层的安全策略要求是不变的，这就需要中间的策略计算层要不断的进行策略重算和策略更新。
举个例子，我们要求每一台新部署的web服务器前面都需要waf这种安全服务能力，这就是一条顶层的抽象安全管理策略。但是问题是我们不知道什么时候新增web服务器，也不知道增加多少，也不知道增加到了哪里。这就要求中间的策略计算引擎，可以一方面了解到底层的计算资源情况，和安全服务能力的API，另一方面能够根据上层策略对这些底层资源进行安排调度。
可以认为，一个私有云的安全管理水平，核心就取决于是否有这一层的存在，如果没有，就意味着，在这个云里所有的安全能力都必须以底层参数进行人为的手工配置，而这将是一个非常痛苦和充满错误的过程。
第二层：策略计算与运维层
第三层：策略定义与运营层
在完成了前两层的建设后，我们就可以考虑开始策略定义与安全运营了，也就是说真正的软件定义在此时才有可能发生。
我们说软件定义，是要真正有一个地方去做定义，甚至说是去做编程的地方，我们在这个地方以全局视角，以一定的格式化语言来编写安全管理原则，然后再由下面的策略分析与计算引擎调度更底层的安全能力予以执行。
具体的软件定义安全的驱动源有两个，一个是根据组织的安全管理原则（比如等级保护的相关规定）以及具体业务系统的架构情况，由安全管理员为每一个业务编写安全管理策略。另一个驱动安全架构运转的驱动因素来自于系统的安全运营管理中心。这个地方汇集了来自整个网络的实时监控数据以及威胁情报，威胁特征签名等来自外部的信息，在对这些信息进行汇总和分析的基础上形成了对系统安全架构进行适应性调整的参考信息。安全管理者根据这些参考信息对安全基础架构进行编程，以形成具体的调整部署。这里要指出的是，自适应安全架构不一定是自动化安全架构，目前的技术水平在误报率上还很难达到完全自动化执行的要求，有经验的安全管理专家仍然是自适应安全不可或缺的一环，自适应安全目前看更多的还是一种安全运营方式，而非具体技术架构。但是不可否认，自动化一定是自适应安全的发展方向，即使是现在，针对一些确定性的context变化，一些先进的软件自适应架构已经可以自动化的做出策略的调整，这大大提升了安全运维的工作效率。
第三层：策略定义与运营层
完整的软件定义安全架构：
（又到了大家最期待的广告时间了）
蔷薇灵动的蜂巢自适应微隔离安全管理平台是一个比较典型的软件定义安全产品，也基本遵循了前文提出的软件定义安全的体系结构，应该说是国内目前最具代表性的新一代软件定义安全产品的标杆范例。。。那个。。。之一（尊重广告法）。
微隔离的核心能力或者核心价值是什么呢？目前大家普遍理解的是东西向流量分析，点到点访问控制。这个理解不能说错，但还不本质。事实上微隔离又叫软件定义隔离，它最核心的诉求是实现随心所欲的隔离能力。或者换言之，是可以让用户在任何时候，对任何工作负载（不管在哪里，不管有多少，不管是虚拟机物理机还是容器），进行任何方式的访问控制能力。
第一层：安全服务层
要实现隔离，就一定要有策略控制点，也就是说要有一个具体的位置去对网络流量进行阻断或放行的访问控制动作。那么微隔离技术的控制点在哪里呢？我们前文提到过，主流的软件定义安全产品的三种基础安全能力投递方式，就微隔离而言，资源池加SDN的方式基本不可取，具体分析可以参考我们另一篇文章：
真正可行的，只有主机防火墙方式，和虚拟防火墙方式（无代理方式）。蔷薇灵动的微隔离采用的是主机防火墙方式。相较于虚拟防火墙方式而言，主机防火墙方式最大的好处就是他的策略控制点直接就在每一个工作负载内部，不需要通过引流的方式把业务流量牵引到虚拟防火墙处进行处理。也就是说微隔离的“能力”已经预先存在于工作负载上了，软件定义安全的架构不再需要考虑能力的投递问题，而只需要考虑如何调用这些已经就位的安全能力来执行具体的隔离策略就可以了。
当然这些能力不可以被直接调用，因为在一个私有云里，可能同时存在几千甚至几万个工作负载，没有人可以直接对所有这些工作负载进行管理。我们提供了一个统一的API调用接口，通过这个接口对所有的工作负载上的控制点进行管理。也就是说在我们的架构里，用户不必要，也不可能对每一个工作负载进行直接管理，他用通过一个统一的策略管理位置来对实现策略的编写与下发。而工作负载只是控制点而已，它本身不具备策略管理能力。
第一层：安全服务层
第三层：策略定义与运营层
我们跳过第二层，先说第三层。
蔷薇灵动有一套独特的基于业务标签的策略管理语言，如下图：
我们可以看到，在蔷薇灵动的策略管理语言里，没有ip，mac，vlan等网络层参数，取而代之的是更加有意义的业务标签，比如web，db，app等等。以这样的方式来设计安全策略，我们做到了让管理者真正关注于业务与安全本身，而不必要考虑如何在具体的网络环境中去进行设备配置。比如说，管理者可以设定web可以访问db的数据库服务。他不必再去关注web服务器有多少，他们的地址是什么，db服务器又有多少，地址又是什么，他甚至也不必了解数据库服务的具体端口是什么。在这里，安全管理者被彻底的从底层的命令配置工作中解放了出来，这些具体的命令都由我们的策略计算引擎来自动生成和配置，这不仅能大大提升工作效率，而且可以避免人工配置中可能出现的一些错误。
而除了允许用户配置根据业务进行策略配置，蔷薇灵动还开放了全部的策略配置API，利用这些API，云管理平台以及安全运营中心都可以直接调用我们的隔离能力对业务进行实时安全管理，我们可以成为自适应安全管理架构中的策略控制基础。我们应该了解，一个自适应的安全架构，很重要的是能够有控制点对业务进行干预。当前的自适应安全产品，更多的都是在关注侦测能力，却很少有产品能够做出具体的安全控制，而正因为这样，我们的微隔离能力才成为自适应安全架构中不可缺少的组成部分。
第三层：策略管理层
第二层：策略计算与运维层
这里才是真正见证奇迹的地方，也是蔷薇灵动蜂巢自适应微隔离安全管理平台的核心能力所在。具体的组件就是我们的QCC自适应策略计算引擎。这个引擎，一方面和所有工作负载上的agent通信，了解到他们的身份信息与地址信息。比如说某个工作负载，他的身份是web，他的地址是1.1.1.1，另一个工作负载他的身份是db，他的地址是1.1.1.2。 另一方面他读取上层的策略配置，比如说“web可以访问db的数据库服务”，并且数据库端口为3306。 然后综合这些信息，他就可以计算出一条具体的配置策略（1.1.1.1 可以访问1.1.1.2 的 3306端口）并将这条策略通过API调用配置到业务角色为“db”的那个工作负载上。
是不是觉得很简单呢，那么假设我们通过镜像复制，把一台web变成100台，并随机分配100个地址，把一台db也变成了100台，也分配了100个随机的地址。这个时候你需要配置多少条策略呢？答案很简单，一万条！我们再假设，本地的网络带宽资源有限，发现会影响到web的接入质量，需要把其中的80台web部署到临时租用的公有云上，那么这个时候，意味着有80个地址发生了变化，那么你需要调整多少条安全策略呢？你不一定知道了，答案是16000条！你需要删除8000条原来的策略，新增8000条新的策略。而在我们的平台上，这一切的工作都是由策略自适应计算引擎QCC来完成的，网络管理者完全不需要做任何工作，自始至终他只知道一条策略——“web可以访问db”！所谓量变引起质变，当云计算达到一定规模之后，没有一个这样的策略计算与运维引擎，您的软件定义安全是不可能真正得到执行的。
第二层：策略计算与运维层
蔷薇灵动自适应微隔离完整架构
随着云计算的普遍采用，如何设计云计算体系的安全管理架构，成为安全管理者的重要挑战，再次，我们给管理者们提几条建议。
首先，尽量部署那些本身就具有完整软件定义安全交付能力的产品（比如蔷薇灵动的微隔离），一个没有内在的软件定义基因的产品，要在云环境下进行部署和使用是极其困难的，这绝不只是对过去安全能力在云环境中的一个简单的迁移过程，而是需要革命性的产品架构的重构。
其次，对于资源池类产品，不能只关注他能支持哪些安全能力，一定要关注这个资源池能不能和你的云计算环境相结合，你是否有办法把业务流量有效的牵引出来。以及这个牵引过程是否会对网络的吞吐和延迟造成影响。
再次，您应该让安全策略关注业务而不是具体的网络架构，你不会想去手工编写基于IP的网络安全策略的，这个工作量实在是太大了，而且很容易出错。如果你发现某些产品只能接受基于IP的策略编写方式，那么您一定要意识到这里可能蕴藏着巨大的项目交付风险。
最后，您一定要考虑运维的问题，毕竟云计算是如此的复杂和多变，如果您部署的安全产品不具备自适应运维能力，那么也许您可以自己去打造一个策略执行与运维引擎。通过这个引擎再去调用这些安全能力。正如我们前面指出的那样，一个好的策略管理与运维引擎无论对于一个产品还是对于一个云系统的整体安全架构而言，都是能够直接决定项目成败的关键。
微隔离,软件定义安全
上一页
上一页
