WAF 在数据路径中处于什么位置？

基于代理的 Web应用防火墙 (WAF) 是应用保护的一个组成部分。 除了符合 PCI-DSS 的要求之外，WAF 还能出色地防御 OWASP Top 10。 它们也是解决零日漏洞的首选解决方案，要么通过快速发布签名更新，要么在某些情况下，在部署长期解决方案时使用编程功能来虚拟修补应用。

问题是，你把这种保护放在哪里？

当然还有其他选择。 数据路径包含多个可部署 WAF 的插入点。 但这并不意味着每个插入点都是好主意。 有些方法效率较低，有些方法会引入不可接受的故障点，还有一些方法会引入架构债务，随着时间的推移会产生高额的利息惩罚。

理想情况下，您将在负载均衡层后面部署 WAF。 这可以优化利用率、性能和可靠性，同时为所有应用程序提供必要的保护 - 特别是对于那些暴露在互联网上的应用程序。

利用率

制定负载均衡决策所涉及的资源需求（CPU 等）很少。 这通常是为什么 LB 能够同时支持数百万用户，而 WAF 需要更多利用率的原因——因为它们正在检查整个有效负载并根据签名和策略对其进行评估，以确定请求是否有效和安全。

现代数据中心模型大量借鉴了云及其基于使用情况的成本结构。 利用率成为运营成本的一个关键因素。 更高的利用率会导致额外的资源需求，从而消耗预算。 因此，优化利用率是限制数据中心和公共云环境成本的合理策略。

可靠性

水平扩展 WAF 是一种常见的做法。 也就是说，您使用 LB 来扩展 WAF。 这个架构决策与利用率直接相关。 尽管许多 WAF 扩展性很好，但它们仍然可能被闪电流量或攻击所压垮。 如果 WAF 位于 LB 前面，则您要么需要另一个LB 层来单独扩展它，要么可能会影响性能和可用性。

表现

性能是应用经济中关注的一个关键问题。 由于在数据路径中传输数据时有如此多的变量和系统与数据交互，因此很难确定到底是哪个变量和系统的性能受到了影响，更不用说在不影响其他变量的情况下调整每个变量和系统了。 正如之前多次提到的那样，随着系统负载的增加，性能会下降。 这是未优化利用率的意外后果之一，也是经验丰富的网络架构师在网络设备上使用 60% 利用率阈值的一个关键原因。

在 LB 层后面部署 WAF 消除了对上游指定 WAF 负载均衡层的需求，从而从等式中删除了整个网络层。 虽然节省的处理时间似乎并不多，但管理连接和扩展 WAF 服务以及再次选择目标应用实例/服务器所花费的宝贵微秒却至关重要。 通过在 LB 层后面部署 WAF 来消除这一层，可以节省宝贵的微秒，今天的用户不仅会注意到，而且会感激。

可见性

可视性是数据路径中安全解决方案的一项关键要求。 如果缺乏检查整个流程（包括有效载荷）的能力，WAF 的大部分安全功能都会变得毫无意义。 毕竟，大多数恶意代码都是在有效负载中发现的，而不是在协议标头中。 将 WAF 放置在 LB 层后面，可以在流量传递到 WAF 进行检查之前对 SSL/TLS 进行解密。 这是一种更理想的架构，因为无论如何，负载均衡器很可能需要了解安全流量，以确定如何正确路由请求。

综上所述，WAF 几乎可以安装在您想要的任何数据路径上。 它是一种基于 L7 代理的安全服务，作为网络路径中的中介部署。 如果你愿意的话，它表面上可以位于网络的边缘。 但如果您想同时优化架构的性能、可靠性和利用率，那么最好的选择是将 WAF 放置在负载均衡层后面，更靠近它所保护的应用。

使用正确的工具，全面的 WAF 覆盖可以显著降低您的风险以及运营成本。 通过 F5 的点播网络研讨会了解有关保护您的应用免受 OWASP Top 10 和其他威胁的更多信息，并探索部署 F5 WAF 功能的多种方式，包括该公司基于云的Silverline WAF托管服务。

F5 安全架构师Brian McHenry和首席威胁研究推广员David Holmes对本文做出了贡献。 2019 年 8 月进行了微小编辑。