作为我国 *** 安全领域的基本国策、基本制度，关于等保2.0的重大意义，业界已经充分的讨论过，本文就不涉及了。而作为工作在 *** 安全之一线的队伍，我们更愿意就等保2.0的具体的技术要求做一些分析。

对于新的技术标准，业界普遍关注到，这个标准增加了对云计算等新业务场景的要求，但是事实上，等保2.0在基础技术要求部分也做了相当大的调整，可以说是在整个安全管理理念上做出了非常深刻的变革。本文只讲两个点，希望能够让大家有所感觉。

这个“天坑”是怎么挖的

1.? 白名单

8.1.2.4?访问控制

a)?应在 *** 边界或区域之间根据访问控制策略设置访问控制规则，默认情况下除允许通信外受控接口拒绝所有通信；

在等保1.0中，关于 *** 安全访问控制部分，只是提出了要设置访问控制设备，并能提供状态检测能力，和部分应用检测能力。但是并没有明确提出是否应用白名单机制进行访问控制，而在等保2.0里面，则是非常明确的提出，访问控制应该使用白名单机制！

这里做个小科普，在访问控制策略的设计中，从大的机制上分成黑名单和白名单两种机制，所谓黑名单，就是默认放开全部通信，除非在策略中明确对该通信进行阻断。而所谓白名单，就是默认阻断全部通信，除非在策略中明确允许该通信。

一般来说，白名单当然是更安全的一种策略设计机制，但是白名单有一个很大的风险，那就是可能会阻断业务。因为你必须明确的指定你要允许哪些通信，而 *** 安全管理者往往不具备对业务的理解，因此无法有效设计出一个很完善的白名单来。相反，安全管理者所理解的是安全问题，或者说威胁挑战，关于该封堵什么他们往往有着丰富的知识，所以黑名单成为了 *** 安全实践中被普遍采用的一种机制。

当然，黑名单也有黑名单的风险，那就是攻击逃逸，或者说策略绕过。由于黑名单普遍依赖于签名信息，而攻击者通过一些技术手段比较容易将自己的特征进行变化进而躲开签名的匹配筛查，而一旦绕开这个签名，在黑名单机制下，攻击就可以畅通无阻了。所以，一直以来，攻击与防御始终在玩猫捉老鼠的游戏，恶意代码快速变种，而签名生产者就要尽快的捕捉到新的变种，然而，攻击的难度远远小于防御，黑名单机制越来越表现出力不从心的迹象。

在这种情况下，一方面业界发展出了一些基于行为的下一代分析 *** ，比如UEBA，EDR一类的技术，但是实话实话说，这些技术到今天为止从实战层面上看还很难被委以重任，相较而言，将黑名单机制切换回白名单机制，成为了更加有效和可执行的一种选择。我想，这也是为什么在等保2.0的技术要求里明确提出访问控制要用白名单机制了。

所以，之一个大坑，就是白名单机制，这要求广大安全管理者必须理解业务，并根据业务去设置白名单策略。作为安全老兵，我们深深知道这对于安全管理者的压力有多大，一个不慎就会阻断业务，然后就是铺天盖地的 *** 质询与事后问责。

2. 东西向

8.1.2.5?入侵防范

b) 应在关键 *** 节点处检测、防止或限制从内部发起的 *** 攻击行为；

在等保1.0的入侵防范部分，要求的是在边界处进行对指定类型的攻击进行防御，虽然并没有强调防内还是防外，但是从上下文的角度分析，当时的规范编写者考虑的是防范外来的攻击，这一点从其部署位置就能看得出来，边界上的防御，在传统的的理解上防的是边界以外的威胁。然而，在等保2.0中，则明确提出要进行对内部威胁的防御，也就是我们业界常说的东西向防御。

为什么说东西向防御也是个坑呢？

首先这是由 *** 结构决定的，一般来说南北向安全都能找到一个叫做网关的地方，我们只要将安全产品部署在网关的位置就能起到一夫当关的作用。然而东西向安全则不同，我们很难找到一个关键路径，让所有的内部流量都会经过这里。为了解决这个问题，业界有两个思路，一个思路叫做“引流”，就是把所有流量都牵引到一个固定的地方去处理，处理后再牵引回来。这个 *** ，业界笑称为“体外透析法”，是属于强行将南北向安全技术用于解决东西向问题的一种做法，其结果就是非常大的内网带宽占用，非常大的 *** 延迟，以及完全处理不过来的流量压力（东西向流量是南北向流量的20倍以上）。另一个思路，是将控制点下沉，比如在每一台接入交换机的位置都部署上安全设备，而这个方案的问题在于其高昂的采购，部署，和维护成本。

其次这也是由 *** 规模决定的，南北向安全不管内部有多大，网关就是一个，基本不受 *** 规模的影响，而东西向安全则和 *** 规模有很大关系，50台服务器的数据中心和500台服务器的数据中心将是完全不同的挑战。

而云计算，则更加让这个大坑显得深不见底。首先，当代数据中心规模都极其巨大，一些云数据中心，体量甚至数以10万计，再加上容器技术带来的节点数激增，使得云内的东西向安全已经成为了一个禁区。另一方面，由于云计算普遍采用了虚拟化技术，这意味着只有虚拟化安全产品才可能在云内得以部署，然而虚拟化的安全产品（主要是防火墙）?普遍对云基础架构有着很强的依赖关系，比如国内发布的几款虚拟化东西向防火墙基本上都只支持少数几个指定的虚拟化架构，这使得云用户（尤其是自己开发云系统的私有云用户）很难找到能用的安全产品。而另一方面，虚拟化防火墙毕竟还是防火墙，并没有彻底解决我们前面提到的那个关于关键路径的问题，为了解决对东西向流量进行全覆盖，目前的东西向防火墙普遍要求很高的部署密度（每台宿主机一个），而与此同时，东西向墙的开销却并不低（2核2g是基础配置），这无疑使得在云内东西部署向安全产品变的难上加难。

3. 当东西向遇到白名单

白名单是个大坑，东西向也是个大坑，而当东西向遇到白名单，这个坑就是一个史诗级别的天坑了。

如果只在边界处做白名单，其实还好说，因为一个数据中心对外提供的服务一般来说都是属于已知的，比较规范的，和有限的服务，基本上还是比较容易摸清楚的。但是一旦把场景切换到了内部，你就会发现数不胜数的私有协议和应用，没有人了解他们的 *** 特性，也没有人准确的知道究竟有多少这样的私有化应用在内部。据说曾经有大型央企的安全部门尝试进行内部业务梳理，将近半年过去了，连冰山一角都还没摸清楚，不得不放弃了这个尝试。

同样的，如果说东西向安全只采用黑名单机制，也还好说，因为你不必要去理解内部的业务究竟是什么，你只需要将已知的威胁添加进黑名单就可以了，这样既做了内部防御，又不会破坏业务，但是如果做白名单，则场景就又回到了刚才我们描述的那个场景中。总之，还是那句话，当东西向遇到白名单，恭喜你喜提了一个天坑。

这个“天坑”要怎么填？

1. 方案描述

这个坑要怎样填？这里我们给一个蔷薇灵动的解决思路，不一定是唯一的方案，但是确实是经过验证，从理论到实践都走得通的一个方案。

蔷薇灵动在业界以微隔离技术著称，而微隔离技术本身就是一种防范内部威胁的有效技术。围绕这个技术，蔷薇灵动提出了一个四步走的 *** 论，供大家参考：

A. 学习

白名单问题的核心难点在于了解有哪些业务是你所允许的，如前所述，这个问题在东西向是非常难搞清楚的一个问题。解决之道就在于你需要一个能够自己学习的可视化平台！

如图所示，我们通过在每个工作节点上部署流量收集器，再通过一个复杂的计算引擎，就可以绘制出一个完整的内部业务拓扑图。这张图的核心价值在于回答了哪些节点之间有关系，以及这个关系具体是什么样的！

这样一张业务拓扑图是我们创建东西向白名单策略的依据。

B. 梳理

蔷薇灵动提供了一整套的交互式策略设计 *** ，通过点击图中的线和点，管理员可以非常方便的设计出内网安全策略，因为这个策略是基于真实的业务拓扑设计出来的，因此可以保证策略的有效性和完整性。

C. 验证

为了避免策略破坏业务，蔷薇灵动将策略分为测试状态和防护状态。在测试状态中，策略并没有真实的部署在节点上，而是通过模拟的形式进行策略计算，并将可能的结果展现出来。我们推荐用户在完成策略梳理后，至少进行两个星期的策略验证，以确保策略不会破坏业务。

D. 监测

一旦完成了策略验证，就可以将策略转为防护状态，在防护过程中，蔷薇灵动将会持续记录东西向访问，以作为必要时的溯源工具，同时对一切 *** 访问阻断进行记录，以用于对内部威胁进行分析

2. 方案优势

A.? 最强业务学习工具

蔷薇的东西向业务拓扑图是目前业界更好的东西向流量分析工具，即使你只使用这一个功能，也足以把你的东西向安全之旅缩短个90%的时间。

B. 交互式策略创建，与自适应策略管理

蔷薇的策略管理语言独树一帜，创建过程完全是交互式的，而且是面向业务标签（而非具体ip）来设计策略，这样一来将策略总数下降了90%的同时，还具备自适应策略调整能力（改天单聊这个事）。

C. 基础架构无关

由于蔷薇的产品采用了主机安全软件的形式，因此可以工作在物理机，虚拟机，公有云，私有云，混合云乃至容器环境下，是的用户可以建立起一个多业务架构下的统一安全管理平台，并且不会对未来的基础架构调整造成限制。

D. 极低的开销

这套方案，是目前已知的开销更低的一套方案，从部署上看，一键安装。几百个节点两天搞定。从运行上看，系统开销不超过0.2%，远超业界其他方案。从方案结构上看，方案在流量的正常路径上进行安全处理，不涉及任何的引流和重定向，对业务完全无影响。

E. 还有好多优势，一时想不起来，想起来再说。

以上就是对于等保2.0所挖下的这个东西向加白名单的天坑做的技术分析和解决方案描述，希望对大家有所帮助。