动态防御作为一个重要的应用安全手段，在当前的安全对抗环境中被越来越多的客户所倚重。但是随着日益变化的数据中心基础架构和业务上云的大趋势，如何能将动态防御设备灵活、可靠的部署到现有的客户环境当中，存在着不少的挑战，本文将从不同的维度来进行探讨。
1.在传统数据中心的部署
由于动态防御本身的对抗和拦截属性，动态防御设备底层都是一个反向代理的存在，在逻辑上都是串接的，因此导致在接入现有的“糖葫芦”的安全架构中，会引起客户对业务可靠性和运维方面的担忧。
1.1与负载均衡设备配合部署（WAF工作在透明模式下）
如果客户已经部署了WAF设备，并且WAF设备工作在透明模式下，动态防御设备的部署需要跟负载均衡设备进行配合部署。其部署的逻辑结构图如下：
部署说明：
客户端请求被负载均衡设备先转发到动态防御设备上，动态防御设备处理完毕之后再转发到负载均衡设备上。（由于绝大部分的动态防御设备都不具备专业的负载均衡的能力，同时后台业务服务器都是多台分布式架构）因此负载均衡设备上需要针对每一个业务增加一个新的VS，该VS负责将动态防御转发回来的流量负载均衡到服务器上。
- 高可用：通过跟负载均衡设备进行联动，通过前端的负载均衡设备来进行高可用的设计。单个动态防御设备故障时，前端负载均衡设备通过对动态防御的健康检查，发现该故障的设备，并自动停止向该动态防御设备转发流量，如果全部动态防御设备都故障时，前端负载均衡设备可以通过监控检查，发现故障的动态防御设备，同时通过负载均衡算法的设置将流量直接转发到后台服务器上，实现业务的高可用性。
- 扩展性：可以通过前端负载均衡设备实现横向的增加多个设备的方式来实现横向扩容。
- 灵活性：可以通过前端负载均衡设备来转发流量，将需要防护的业务流量转发到动态防御设备上，而不是全部的流量都转发到动态防御设备上。
挑战：后台服务器需要读取客户的源IP信息。
- 方法1：通过HTTP的XFF头来传递源IP，应用需要做稍许改造支持从XFF读取源IP。
- 方法2：动态防御设备将源IP透传到服务器上。（需要服务器网关或者回包流量指向动态防御设备）
1.2与负载均衡设备配合部署（WAF工作在反代模式下）
方式一： 动态防御跟WAF 1比1部署，负载均衡对一组设备做负载
数据流：
1.负载均衡将流量负载到动态防御动态防御设备上。
2.动态防御动态防御设备通过1对1的对应关系将流量转发到后台的WAF设备上。
3.WAF设备再把流量转回到负载均衡设备的另外一个VS上。
4.通过该VS，负载均衡把防护后的流量转发给真实服务器。
优点：
1.数据流比较清晰，方便排错。
缺点：
1.部署的动态防御数量需要跟WAF保持一致，不能灵活扩展。
2.当某个动态防御或者WAF出现故障时，整体防护能力会下降。
3.负载均衡上的消耗有所增加。
4.延迟略微增加。
其他：
1.动态防御可以配置基于HTTP的内容健康检查（并且时间参数与前端负载均衡保持一致），这样WAF出现故障，前端负载均衡可以快速的进行判断和切换，无需再等待动态防御的健康检查判断。同理，如果动态防御出现故障，前端负载均衡一样可以快速发现故障，缩短业务失效的时间。
方式二：通过负载均衡对动态防御以及WAF分别做负载
数据流：
1.负载均衡将流量负载到动态防御设备上。
2.动态防御设备处理完之后将流量转发到前端负载均衡器的WAF的VS上。
3.负载均衡器再把流量负载均衡到WAF设备上。
4.WAF设备处理完之后再把流量转发到前端负载均衡设备的业务VS上。
5.负载均衡设备通过业务VS再把流量负载到后台服务器上。
优点：
1.充分利用了负载均衡设备，通过负载均衡设备使得动态防御和WAF的横向扩展性最好，业务的可用性最高。
2.动态防御和WAF的配置相对简单，安全运维比较简单。
缺点：
1.前端负载均衡上额外消耗比较大，配置复杂度会增加。
2.业务的延迟增加。
方式三： 负载均衡对动态防御做负载，动态防御对WAF 做负载
数据流：
1.负载均衡将流量负载到动态防御动态防御设备上。
2.动态防御动态防御设备通过负载均衡的方法将流量转发到后台的WAF设备上。
3.WAF设备再把流量转回到负载均衡设备的另外一个VS上。
4.通过该VS，负载均衡把防护后的流量转发给真实服务器。
优点：
1.数据流比较清晰，方便排错。
2.动态防御和WAF都比灵活，可以横向扩展，容错性比起1：1的部署更好。
缺点：
1.负载均衡上的性能消耗有所增加。
2.延迟略微增加。
其他：
1.动态防御可以配置基于HTTP的内容健康检查（并且时间参数与前端负载均衡保持一致），这样WAF出现故障，前端负载均衡可以快速的进行判断和切换，无需再等待动态防御的健康检查判断。同理，如果动态防御出现故障，前端负载均衡一样可以快速发现故障，缩短业务失效的时间。
方式四： 通过流量编排设备对动态防御设备和WAF设备进行流量编排
数据流：
- 流量编排设备将流量根据策略转发到不同的安全设备资源池中，例如先经过动态防御设备，再经过WAF设备。
- 安全设备的回应包需要回给流量编排设备，流量编排设备再向后台服务器转发。
优点：
- 串接的糖葫芦架构得到优化，安全设备真正的实现旁路接入了，并且支持多种安全设备的旁路接入。
- 安全资源池化之后，横向扩展很简便。
- 设备故障之后，可以快速的被屏蔽，实现业务高可用。
缺点：
1.安全流量编排设备的性能要求比较高。
2.需要对现有的网络进行改造，对现有网络结构的变动影响比较大。
如果现有的安全边界架构比较复杂的情况下，通过流量编排设备来进行动态防御设备的接入是一个比较合适的方案，同时流量编排设备也可以方便的支持未来其他安全设备的快速、旁路接入。目前已有部分客户开始使用流量编排设备来对安全架构进行优化。
2.云环境下的部署
为了适配数据中心虚拟化和私有云环境下的部署，动态防御厂商和都推出了虚机版的动态防御解决方案，可以部署在不同的虚拟化的环境下，以代理的方式进行工作。虚机版的动态防御的部署与动态防御设备的传统的反向代理设备的部署并没有本质的区别，只不过实现的方式由原来的硬件设备变成了虚机。
在云的环境中，本来就存在着基于反代模式的应用负载均衡设备和一些web的反向代理（nginx或apache），因此再加入基于反向代理的动态防御设备或者其他基于反代的安全设备（比如WAF），势必会导致架构的臃肿以及OPEX的极大增加。同时随着互联网业务类型的复杂化，基于虚机的传统的反向代理的部署模式也面临诸多挑战。
因此，在云环境下部署云动态防御的总的原则是：
- 尽量简化架构，利用好云环境中原有的反代设备（ALB）。
- 跟云环境中原有的反代设备（ALB）尽量的松耦合。（为啥？还是部门墙的原因，因为ALB是基础架构设备，动态防御是安全设备，两者的定位完全不同。尽量少给其他部门添麻烦，除非是有统一的规划，否则会落不了地。）
- 同时保持足够的安全防护能力和扩展能力及可靠性。
2.1 将动态防御模块集成到ALB上
此种方式下，由于ALB和动态防御都是基于反向代理架构，甚至都是基于nginx的二次开发，所以可以直接在ALB上通过加载动态防御模块的方式进行集成。像国内目前比较热的长X的动态防御就具备该种部署模式，并且也在国内某股份制银行有过部署，该部署模式因为是跟nginx模块紧耦合的，因此对nginx的版本也有要求，在不同的nginx的版本上需要做一定的适配。
该方式虽然简化了架构，但是却和原则的第2条尽量松耦合冲突，会导致设备管理方面的矛盾。
如果是针对单一业务的ALB，如果性能要求不高且该业务的流量不大时，集成之后动态防御带来的性能消耗是可以由ALB本身的计算资源所支撑。如果业务流量太大时，也会导致水平扩展会比较麻烦，因为ALB本身就是业务的唯一入口，水平增加动态防御就是要增加ALB。
另外，如果未来有增加新的反代架构的安全设备时，该方式的同样可以集成模块，但是带来的性能扩展问题以及管理问题会更复杂。
2.2 nginx异步流量复制
利用nginx本身自带的nginx_mirror_module模块，将请求复制一份，异步转发到动态防御设备上，由动态防御设备进行识别。Nginx1.13.4开始引入了nginx_mirror_module模块，这个模块的作用是把指定的流量转发到目标服务器，但需要注意的是，这个模块会丢弃目标响应，效果和交换机网络流量镜像一样。因为默认该模块不在nginx编译参数中，所以要使用这个模块的话，需要重新编译Nginx并且版本要大于1.13.4。但这个模块有个致命的缺点，复制的镜像请求和原始请求是相关联的，若镜像请求没有处理完成，原始请求就会被阻塞。
在openresty上也有类似的功能，openresty ngx.location.capture。同样，该模块也是忽略子请求的相应。所以，不会打断业务流程，类似的还有ngx.location.capture_multi模块。
F5的负载均衡设备上也有类似的功能，通过HSL（high speed log ）和 irules实现对请求的重构和镜像功能。
该方式由于采用的是旁路流量复制的架构，因此对正常业务几乎没有干扰，并且动态防御可以快速的进行水平扩展。跟nginx的耦合度也很低，只需要简单的指令即可在nginx上进行流量复制。
该方式简化了架构，在管理行、扩展性和耦合度上都可以满足需求，但是异步复制流量的方式，只能起到监控和报警的作用，无法进行拦截。
2.3 nginx阻塞式流量复制
通过在nginx上加载一个阻塞式流量模块，该模块主要实现以下几个功能，用于跟动态防御设备对接。
- 收到请求后，根据配置指令对请求进行处理，匹配的请求用json的方法将请求的头域和body内容转发到另外的安全设备（动态防御）上。不匹配的请求直接进入nginx进行处理。
- 可以通过负载均衡的方法来横向扩展对端安全设备（动态防御）的数量。
- 一旦对端设备(动态防御)出现故障，则可以通过健康检查机制，快速绕开故障设备，直接通过原生nginx流程访问后台业务系统。
该模式引入了一个第三方模块，最大程度的实现了云环境下部署动态防御的三大原则。对业务影响小，旁路部署，快速扩展，管理分离（只需在nginx上配置简单的指令即可），具备完整的报警和阻断能力。
3.总结
由于时间仓促，本文仅提出了几种方式供大家探讨，具体的技术细节本文并没有一一细说，后续可以再针对某种方式做专题探讨。部分资料来自网络，对原作者表示感谢！也欢迎大家随时跟我沟通和探讨。
关于作者：安锐信息，创始人，刘勇。
从网络到ADC到安全，从SI到外企厂商到创业公司，一直在跟安全行业在发生关系。作为一个安全圈的后到者，跨界的经历可以从更多的维度理解客户所需要的安全，希望跟其他安全同行多碰撞。