相信大家已经了解F5的双模安全架构，通过构建出敏态区域和稳态区域，结合对安全策略，安全设备的灰度发布，进行小范围的试错，将我们对抗的时间成本，误报成本都给消除。

现在已经有很多用户通过构建双模安全架构，充分发挥出WAF精细化策略的能力，既满足了合规，又要满足了对抗。

今天我给大家带来的是双模安全2.0，纵深防御的内容。

大家可以思考一个问题，比如fw，ips，ids，waf，这些解决方案都发挥了多少的功能，策略开了多少？

有这样一个统计，90%的用户对这些安全产品的功能只用了30%以下，安全功能开多了，一上线就误报，应用部门不同意，我们要支持业务的发展，策略降下来，那么如果一旦策略放开，那么还能再开吗，很多时候，可能就这样了，其实很难的。

这也是很多安全策略制定的思路，是业务优先还是安全优先，尽管有的安全设备比如F5就具备自动学习模式的概念，而真正落地的时候往往用户会认为人工进行进行策略定义更可控。那么怎么办，策略无法调整，往往就以一个很粗力度进行配置了，如何解决这个问题呢，其实就是双模安全架构，既然产品平台的能力无法满足需求，就用架构的能力去赋予安全策略以灵捷。

纵深防御，这个名词大家可能最近不少听到。

这个方法其实有的用户已经在用了。是什么样呢，网络部门运维统一的安全策略，应用开发部门在每个应用前端，运维per-app的，基于每个应用定制的精细化策略。

其实我们很早就推行的是基于F5 VE的per-app策略，但是比较难，为什么，因为开发部门运维VE需要有F5的专业知识，学习成本相对高，并且VE相对而言，比较重。

然而用nginx的话，其实更轻量级，F5是大而全的话，nginx就是小而美。 我们先撇开WAF的功能不看，就说是slb软负载的功能， 现在我们发现在现实中，很多用户的应用部门或者开发部门已经自己开始搞软负载了，现在这种场景已经是客观事实的存在了。可能是商业化slb的模式，可能是nginx的形式，但是 anyway，这种双层负载的模式一定是存在的。只不过是后面的软件的负载不在传统用户的网络部门这边维护，很可能在中间件，平台部门，应用部门那边维护，

在这样一个场景下，很多应用部门的诉求就能实现，为什么，因为有自主权，他可以控制软件的slb。他甚至把这些slb的变更整合到他的发版的流程里，今天发一个小版本，直接就在应用部门把这些事情都完成了，并不需要提一个流程工单给网络部门。

那么现状是双层架构已经基本上都存在于用户的数据中心里了，用户网络部门的F5更多的是4层策略，用户应用部门的nginx更多的是7层策略。这时候我们看，如果nginx也有WAF功能不就完美了吗，别着急，nginx其实在很多用户那边已经用了开源的mod security来做waf了，但是美中不足的是，mod security能力不够，性能不好，我们要做精细化防御，需要有足够的子弹，足够的7层安全能力，好消息是F5的nap，nginx app protect模块移植了F5十几年技术沉淀积累的WAF的能力到nginx上。

好，回过来看，这样一种纵深防御的方法，其实可以通过现有用户应用开发部门运维的nginx上附加高级waf能力得以完美实现，这样其实也是非常合理的方法，应用部门最懂应用，如果他们运维精细化的安全策略，就能把策略做的更精细，在结合到devops的流水线里面，devsecops其实就可以实现。