华为安全首席架构师甘永存

华为安全首席架构师甘永存先生，他给大家带来的题目是《让安全贴近负载》。

大家好，我是来自华为的甘永存，今天我讲的偏技术一点。让安全贴近负载是什么意思呢？传统的负载在数据中心的负载都是比较稳定、静态的，通常不会变。但是随着公有云和混合云，这个负载会变化非常快，而且是弹性的。传统的安全架构可能跟不上这种负载的变化，我们怎么应对呢？所以，大概就是这么一个意思。

这是传统数据中心的架构图，有不同分区的，中间是核心交换机、汇聚、接入，最后可能会挂一些防火墙等等，大概这么一个架构。这个架构本质上来说就是两层，一层是防火墙、IPS、DDos，内部是按网段分离的。这个大家比较熟了，我就不再讲了。

说一个趋势，第一个是2020年的时候云计算的支出将超过自建IT基础设施，90%的企业会采用混合云。所以，我们发现未来整个基础设施云化是一个非常明确的趋势，这也是大家比较清楚的，我只是说一个数字而已。

另外一个问题，数据中心东西向流量占比超过三分之二。传统数据中心的架构是为了适应南北向，三层，核心、汇聚和接入。现在比较典型的数据中心架构都是二层的，这样适合于满足大容量、无阻塞、延时可控的业务。东西向流量占比超过三分之二，对整个数据中心服务质量其实是有要求的。但是传统的安全方案会对这种服务质量有影响，一会我们会看一下。

我们找了一个比较典型的数据中心，看下一些情况的介绍。这个数据中心大概有1200个防火墙，有PA、Jumiper、华为等等，用户策略大概20W，主要是进出数据中心的。网元策略主要是30W，这个策略是经过20—30年积累的过程。现在据说一般人不会动原有的策略，因为他不知道这个业务是什么样子，所以大部分是敢加不敢删。

这种复杂情况他们自己也开发过一个防火墙策略管理系统，但是这个系统没法适应网络变化，原来做的时候能够统一管理。例如实现跨厂商的统一管理是能做到的，但是唯一的问题是比如我某个业务下线了，它根本适应不过来，因为业务和安全是剥离的。我的策略按照这个去配，如果业务下线，业务和策略不绑定，所以这个是跟不上的，只能解决统一管理的问题，但是解决不了网络变化，这个几乎已经是被废弃的状态。这里一共有接近50万，超过70%的策略是服务器之间的互访。当前主要的问题是安全策略管理和应用管理是分离的，我部署了哪些服务器和应用，和安全策略剥离开了，这样一个问题就是刚才说的，根本适应不了不同网络的变化，业务变化已经适应不了。业务的变更、迁移、扩容、下线都跟不上。用户提交策略是要审批，每天要批300个单子，哪组服务器到哪组服务器，审批权限，所以这还是有很大的问题。

它的诉求，第一，全网防火墙统一纳管和可视化。另外一个是对接现有的工单系统，实现策略的自动编排下发。希望实现以应用为中心的策略管理，大部分的策略全是用户访问应用，应用内部的分组互发，比如说我这个业务分三层，web层、APP业务逻辑和数据库，每层大概有哪些服务器，我定义好之后，这个策略自动翻译转发到下面的防火墙或者其他设备去执行。比如说运维人员不用管底层的策略管理，我会把应用和策略绑到一起，最后综合就是聚焦以应用为中心的安全策略管理，同时实现安全策略自动下发和编排，并且跟踪到安全策略全生命周期，这就是一个比较基础的需求。

我们再看看传统的网络控制方案图。这是传统的三层架构，核心、汇聚、接入，每一区有不同的分组，例如web服务器放一个区，APP服务器放一个区，所有的业务流量是通过防火墙做隔离的。这种架构的问题，其实没有任何一个地方定义应用，可能在IT工程师的本子上或者资料里会写，我这个应用分几层，每层大概的服务器有哪些，这个其实不在整个系统中维护。这样的话，应用变了，安全策略变不了，所以这是一个传统的访问控制方案的不足。

另外是负载和安全的分离，本质上来说，我们常用的web服务器和APP服务器，通常会在防火墙来做，安全策略控制是在这儿体现的。但是负载是在这儿，所以这就是一个分离的问题。解决方案是什么呢？安全要跟随负载一块走，负载在哪，安全就在哪。未来安全策略会随着负载的变化而变化。

当前传统的架构只能子网级的安全控制，当然这个业内的思路挺多的，最终实现VM级的隔离，如果你做了更精细化的话，可以做到应用级的隔离。另外一个就是性能低、延时高。所有的内部流量都需要到防火墙转一圈，然后从防火墙再回来。如果是按照我们刚才说的架构的话，正常的就是两跳，第一跳到这儿下来，如果你旁挂一个防火墙的话，再增加，这样的话对整个数据中心的网络服务质量、吞吐是有很大影响的。另外一个是把集中式防火墙拆散，放到下面的集成负载上面，这样才能适应大容量、不阻塞、不延时的架构。

大概是一个什么样的方案呢？应用驱动的安全策略管理，我们大概把它分成几层，按照红线分，最上面一层是CIO角度，只看到应用就足够了。IT层面它会指导这个应用由哪些逻辑的分组组成，逻辑分组之间的互访关系是怎样的，同时有哪些服务器负载承担，这个应该是IT能看到的维度。从安全的角度就是互访，例如web到APP的互访，这个都是从逻辑定义的角度来说，自上而下的编排，从应用到应用互访的定义，到最终往下安全策略的分级。

最终再好的安全策略都有一个执行层面的东西，所以就变成整个安全策略的执行，大概分两个，第一，混合云。如果是同构的，以华为为例，我们有私有云、和数据中心，通过私有云安全组、传统数据DCN的接入交换机，在这几个层面完全可以离你的负载最近的位置上实现访问控制。负载在的时候，我这个访问控制策略自然加在上面。负载消失了，这个策略就会只存在在数据库里，而不会在网络中有什么效果。对于以后的混合云组网和负载Docker化，一它做不了访问控制，所以没办法，只能把访问控制策略再往上移，移到跟VM一个级别。对于现在已有的防火墙和策略，怎么调优？就是安全策略自动化，要求下面接入交换机的，我不管你是公有云还是私有云，还是物理的数据中心，要进行流量信息的导入，我根据这些流量信息做应用分组识别、用户互访定义，策略的一致性校验。

安全策略编排，通常定义应用分组，这些分组都是在IT层面中看到的，包含web的分组、应用逻辑的分组和DB的分组，每个资产对应的名字和IP地址都有统一的管理。在这块接下来会有一个安全策略的清单，比较传统的是这么做的，而且这个策略通常在防火墙实现。

但是这里有几个问题，第一，应用下线，策略依然存在，维护海量策略的情况下，如何保证策略和安全的一致性。这是一个问题。第二个问题是，应用的扩容，举个例子，我web里增加了一个主机，那就要求对应修改我的防火墙策略。怎么样能够快速高效满足应用的变化？这是传统的不能够跟得上的。第三是基础设施的云化，利用负载的快速变化，安全策略怎样高效地满足应用变化，这上面主要是传统的安全策略的定义及面临的一些挑战。

无论单体的公有云、私有云、混合云，我们接下来都会采用一个安全策略编排的方式，第一，你要定义业务，就是我有哪些业务。业务上有哪些负载，对应的负载的安全策略是怎样的，举个例子，我们以刚才APP为例，可能APP上有两个APP的负载，分别是APP01和APP02，刚才的定义其实是web是能够访问APP的，同时它俩又能访问DB，这就变成了一个入站策略和出站策略。比如说我会在通过安全组，或者通过在接入交换机，把这个策略下发到这儿来，只有白名单策略才是OK的。

最后一个，如果我这个应用变化了，增加了APP03，我只要把APP03打一个标签，不管它在公有云还是私有云，还是数据中心，只要这个资产或者负载一上线，把这个策略直接配置到数据中心。这是整个安全策略编排思路。

下面是安排策略自动化，大概分成几层，同样跟刚才介绍的负载是一样的，这层是web的负载，中间是应用逻辑的负载，最后是DB的负载。分组，第一无论是底层的网络，安全策略会自动化把这个分组出来，比如说哪个是web分组，哪个是APP分组，哪个是DB分组。分组之后会把互访关系定义出来，整个应用分组的互访关系自动化生成。接下来把它转换成底层的安全策略，就变成了负载对应的出站入站，到来源到目的的一个访问过程策略，这跟安全策略编排是一样的，从这儿开始往下都是一样的。

下面一个就是要把安全策略执行绑定到策略上，刚才我们说的应用分组一样，我加一个服务器，它一上线我的交换机就知道这个应用上线了，我就会安策略自动化，或者新的负载就会查询安全策略。这也一样，到这儿去查询策略。查询策略之后可以下发给安全组，也可以下发给VM.负载上线，我策略自动下发过去，负载一下线，策略自动消失，安全随着应用变化而变化，无论是应用的上线下线、还是扩容都可以跟得上。如果现实没有负载的话，那就意味着这个策略只存在在数据库里，而不会在网络中存在。而且我也会提醒用户说这个策略没有在网络生效，用户其实就知道这个策略是可以删掉的。

对比一下，传统的安全访问控制和安全信息负载的方式，第一，聚焦业务方面，传统的是业务和安全是分离的，完全由IT人员和安全工程师手工转译。从弹性的角度，传统的安全防护没法适应业务的变化，需要人工干预。控制粒度，传统只能做到子网级，新的负载方式是主机级微隔离。

我们把这个类比大数据的思路，数据量太大的时候，传统来说都是把数据搬到计算列表上去计算，但是数据量太大的时候没法搬就换了一个思路，把计算贴近数据，其实这个思路跟那个思路是一样的。负载足够大的时候，而且快速变化的情况下，对不起，我只能把安全挪到负载，跟着负载一块跑，这样才能适应业务的快速变化。

我今天的演讲就到这里，谢谢大家！