当前传统的架构只能子网级的安全控制，当然这个业内的思路挺多的，最终实现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.负载上线，我策略自动下发过去，负载一下线，策略自动消失，安全随着应用变化而变化，无论是应用的上线下线、还是扩容都可以跟得上。如果现实没有负载的话，那就意味着这个策略只存在在数据库里，而不会在网络中存在。而且我也会提醒用户说这个策略没有在网络生效，用户其实就知道这个策略是可以删掉的。