使用 F5 NGINX APP Protect 和 F5 NGINX Plus 实现安全防护自动化，从而降低安全漏洞的防范成本

Thelen Blum of F5

F5 NGINX App Protect 高级产品营销经理

Matthieu Dierick of F5

欧洲、中东和非洲地区解决方案架构师

2022-07-07

也许您不知道，虽然企业为了改善安全性，在自动化和人工智能（AI）上面投入了很多资金，但是这样反而会节省很多钱。IBM Security 在《2021 年数据泄露成本报告》中指出，自动化和 AI 技术可以将数据泄露成本平均降低 80%，其中未部署此类技术的企业数据泄露成本高达 671 万美元，而全面实施此类解决方案的企业的相应成本为 290 万美元，两者足足相差 381 万美元。通过优先使用安全自动化和 AI 技术，企业可以更快地识别和阻止漏洞，从而节省成本和时间。

Bar chart showing average cost of a data breach by security automation deployment level — 未部署安全自动化和 AI 技术的企业的数据泄露成本更高
（资料来源：2021 年数据泄露成本报告）

在 CI/CD 流水线中集成安全性固然重要，但是给工具减负也不可小视。您检查流量的次数越少，引发的延迟就越小。业务界有一种说法，技术复杂性是敏捷性的敌人。

F5 NGINX 安全平台具有独特的优势，除了具备优秀的无缝集成能力外，它还可以帮助团队在软件开发生命周期内实现“安全左移”。只要企业将“安全即代码”集成到 CI/CD 流水线中，就相当于启动了安全自动化和 AI 的钥匙，也就离 IBM 所说的重大成本节省不远了。通过将安全性构建到应用和 API 开发的每个阶段，您能够以代码的形式使用配置和安全策略文件，您的 SecOps 团队也可以创建并维护声明式安全策略，以供 DevOps 团队在构建应用时使用。您还可以直接将这些策略“照搬”到新应用中，从而在 CI/CD 流水线中实现自动化安全。

现在我们从流量处理的三个阶段入手，抽丝剥茧地看看 F5 NGINX App Protect 和 F5 NGINX Plus 是如何帮助您实现自动化安全保护的：

阶段 1 —— F5 NGINX App Protect DoS 检测并防范拒绝服务 (DoS) 攻击
阶段 2 —— F5 NGINX App Protect WAF 抵御 OWASP 十大安全风险和恶意 bot 程序
阶段 3 —— F5 NGINX Plus 使用原生功能以及集成的第三方单点登录 (SSO) 解决方案，对应用和 API 客户端进行身份验证和授权

Diagram of three-phase security solution for efficient application traffic management to block illegitimate traffic and automate security, using NGINX App Protect DoS and WAF plus NGINX Plus — 安全“三步走”：通过高效的应用流量管理拦截非法流量，实现自动化安全，进而节省时间和成本

安全“三步走”可从两个方面为您节省成本，尤其是在公有云环境中：

只有合法流量可以抵达应用，因为 NGINX App Protect DoS 可以滤除 DoS 流量，NGINX App Protect WAF 则能够消除多种威胁向量，包括 OWASP 十大安全风险。
NGINX Plus 高效的事件驱动型设计意味着，它能够以较低的 CPU 消耗处理每秒发出的大量请求。再加上是仅处理合法的应用流量，因此所需的计算资源要少得多 —— 这不仅可以节省时间和成本，而且还能在不压垮应用的情况下抵御多个攻击向量。

如果您目前正在使用 F5 BIG-IP Advanced WAF 保护数据中心的应用，那么可以直接添加带 NGINX App Protect Dos 和 WAF 的 NGINX Plus，以作为 Kubernetes 的 Ingress controller（Ingress 控制器），这是一款全面的解决方案，可以扩展和保护您的现代应用，并编排云端的 Kubernetes 应用。借助 F5 的“安全即代码”方法，您可以通过声明式 API 或文件中声明式 JSON 格式的定义，将基础架构和安全策略控制定义为代码，也可以将 BIG-IP XML 文件转换成 JSON 文件。您的策略，也就是 SecOps 团队拥有和维护的标准企业安全控制，可以被存放到代码库中，然后像任何其他代码段一样随用随取并集成到开发流水线中。这种方法有助于 DevOps 和 SecOps 弥合运维鸿沟，同时以更低的成本和更高的安全性更快地将应用推向市场。

F5 将 WAF 策略的构建和基线评估整合到了开发流程中，这是应用开发流水线“安全左移”和应用部署自动化中的一个重要环节。

BIG-IP 和 NGINX 中的可视化工具具有互补性，有助于 SecOps 尽早将自动化流程融合到 DevOps 生命周期中。BIG-IP 允许团队将 XML 文件转换成 NGINX 使用的 JSON 文件，从而保持一致的安全策略。NGINX 支持团队优化已经部署好的应用，同时又带来了先进的现代应用安全自动化技术，能够帮助防范未来的漏洞并抵消潜在攻击的成本。

阶段 1：使用 NGINX App Protect DoS 防御 DoS 攻击

在我们的安全流量管理旅程中，第一站就是消除拒绝服务 (DoS) 攻击。作为第一道安全防线，釜底抽薪十分关键。

我们之前已经注意到，越来越多的攻击者不再使用传统容量耗尽攻击，而是开始利用 HTTP 和 HTTPS 请求或 API 调用发起七层攻击。为什么呢？因为这种方法是阻力最小的。基础架构工程师花费了数年的时间来建立针对三层和四层攻击的有效防御机制，让这些威胁变得更容易拦截、也更难得逞。但是七层攻击可以绕过这些传统防御措施。

并非所有 DoS 攻击都是容量耗尽型攻击。通过 Slow POST 或 Slowloris 等“慢速攻击 (low and slow)”方法消耗服务器资源的攻击很容易隐藏在合法流量中。虽然 gRPC 等开源 HTTP/2 远程程序调用框架提供了现代应用所需的速度和灵活性，但它们的开源性质可能相比专用协议更容易招致 DoS 攻击。

与传统 DoS 防护功能不同，NGINX App Protect DoS 能够利用自动化用户和站点行为分析、主动健康检查技术和无接触配置检测当今的攻击。它是一种低延迟解决方案，能够阻止 HTTP GET flood、HTTP POST flood、Slowloris、Slow read 和 Slow POST 等常见攻击。

为了抵御这些攻击，SecOps 和 DevOps 团队需要将“安全即代码”自动化集成到 CI/CD 工作流程中 —— 这也是其左移文化的一部分。NGINX App Protect DoS 可以帮助实现一点。它不仅能够通过高级 DoS 威胁防御机制保护现代分布式应用和 API，还能使用轻量级软件包、持续的威胁防御响应以及通过 RESTful API 集成的常用的 DevOps 工具促成这一模式，从而协调 SecOps 和 DevOps 不时冲突的工作优先级。

NGINX App Protect DoS 集成了机器学习 (ML) 技术，该技术被 IBM Security 报告指出是显著节省成本的关键所在。它能够分析客户端行为和应用健康状态，以便对正常的流量模式建模，并使用独特的算法创建动态统计模型，以实施高度准确的保护，同时通过部署动态签名来自动规避攻击。它还能够持续评估防御的有效性，并适应不断变化的行为或健康状况。在每个攻击请求都看起来完全合法的情况下，甚至在一个攻击者产生的流量比普通合法用户还要少的情况下，这些功能也能帮助 NGINX App Protect DoS 轻松拦截 DoS 攻击。

Diagram depicting eight types of attacks blocked by NGINX App Protect WAF and DoS — 安全解决方案阶段 1 和阶段 2：使用 NGINX App Protect DoS 和 WAF 高效处理流量，保护应用安全

阶段 2：使用 NGINX App Protect WAF 抵御 OWASP 十大安全风险

虽然 DoS 防护解决方案能够明显阻止恶意流量进入基础架构，但是难免会有漏网之鱼。因此，您需要部署 Web 应用防火墙 (WAF) 来集中消除隐藏在合法流量中的恶意威胁，保证下一阶段的防御成功。

NGINX App Protect WAF 是一款轻量级的高性能解决方案，能够提供全方位的安全保护，包括检查响应、HTTP 协议合规性检测检测规避技术、使用 Data Guard 屏蔽信用卡号和其他个人敏感信息，以及检查不允许的元字符和文件类型、格式错误的 JSON 和 XML、敏感参数等。它还可以防御最新的 OWASP 十大安全风险：

OWASP 十大安全漏洞（比如 A03:2021 注入）网络攻击如此猖狂也完全在意料之中。2021 年 7 月，开源电商网站 WooCommerce 宣布其多个插件存在 SQL 注入风险，当时有多起攻击事件发生。由于很多企业和客户都主攻线上业务，也就不难理解为什么攻击者把矛头瞄准基于 Web 的应用了，这些应用通常很复杂，由微服务组成并且分布在各种环境中，通过多个 API 相互通信，增加了容易遭到攻击的端点的数量。

现代攻击的反应速度很快，适应力也很强，为此我们引入了 AI 技术，这也是 IBM 强调其重要性的原因。与在 NGINX App Protect DoS 中一样，NGINX App Protect WAF 中丰富的机器学习系统允许 Platform Ops、DevOps 和 SecOps 团队轻松共享攻击趋势和数据。NGINX App Protect WAF 还添加了一项新功能 —— Adaptive Violation Rating（自适应违规评级），它能够进一步利用机器学习检测应用的行为变化，并帮助 NGINX App Protect WAF 持续评估每个应用的预测性行为。这项新功能支持原本可能会被拦截的客户端请求，从而降低应用的违规评分，并极大地减少误报，最终以更低的管理成本打造更好的用户体验。

NGINX App Protect WAF 还可以抵御恶意 bot 程序。如今，近 50% 的互联网流量来自 bot。通过提前消除已知的恶意流量，NGINX App Protect WAF 可以使用 Bot Signature（bot 签名）数据库快速拦截 bot 流量。

在 CI/CD 流水线的早期阶段引入 WAF 作为安全层有助于降低安全风险。NGINX App Protect WAF 对 CI/CD 十分友好，因此您可以在应用开发流程的早期集成并自动化实施“安全即代码”。这种“先发制人”的安全意识和有效的团队合作还可以帮您消除交付风险等瓶颈。贯穿多个阶段的 DoS 和 WAF 保护功能创建了许多检查点，能够让安全团队获取有关应用使用情况的洞察，并让应用团队了解它们是如何被维护的。

阶段 3：NGINX Plus 对应用和 API 客户端进行身份验证和授权

即使 NGINX App Protect Dos 和 NGINX App Protect WAF 剔除了恶意流量，您仍然需要验证客户端是否合法以及是否有权访问它们请求的资源。这时候就需要 NGINX Plus 派上用场了，它能够处理身份验证和授权，然后将请求路由到合适的服务器。通过将 NGINX Plus 部署为 API 网关，您可以为多个 API 提供一个一致的入口点并简化堆栈。

身份验证和授权也可以通过单点登录 (SSO) 变得自动化，从而使 DevOps 团队保持所需的敏捷性。NGINX Plus 支持 OpenID Connect (OIDC), 一个建立在 OAuth 2.0 协议之上的身份层。在 NGINX 文档中，我们解释了如何使用 OIDC 为 NGINX Plus 代理的应用启用 SSO。

Authentication and authorization using NGINX Plus and OAuth 2.0/OIDC IdP-compliant examples for SSO — 安全解决方案阶段 3：使用 NGINX Plus 实施的身份验证和授权以及符合 OAuth 2.0/OIDC IdP 的 SSO 示例

API 具有与生俱来的开放性，因而很容易遭到攻击。Gartner Research 曾在年度报告中预测指出，2022 年 API 将成为最常见的攻击载体，可能会引发大量的企业 Web 应用数据泄露事件。随着时间的推进，各个企业的 API 攻击面持续增长，我们的观察似乎印证了这一推测。

F5 Labs 的《API 身份验证事件：2020 年应用保护报告》揭示了 API 事件的三个常见原因：

API 端点没有身份验证
失效的 API 身份验证
失效的 API 授权

API 端点没有身份验证

当您对 API 流量实施身份验证时，成功证明其身份的客户端会从受信任的身份提供商那里获得令牌，然后客户端再为每个 HTTP 请求提供访问令牌。在将请求传递给应用之前，NGINX Plus 会验证令牌并提取在令牌中编码的身份和其他数据（例如组成员资格），以确保对客户端进行身份验证和授权。令牌得到验证并且客户端获得访问资源的授权后，请求就会被传递到应用服务器。验证方法有很多种，其中使用 OpenID Connect（基于 OAUTH 2.0 协议构建）是一种流行的做法，它可以对 API 请求进行第三方身份验证。

但是，市场上的许多 API 都在身份验证层不受保护。2021 年，互动健身平台 Peloton 被曝存在 API 漏洞。一位安全研究人员发现，客户端可以向 Peloton 的 API 发出未经身份验证的请求，从而在没有进行身份验证的情况下轻松检索用户数据。尽管 Peloton 及时止损修复了代码，但这一事件突出表明，单一的安全方法没有考虑 API 结构固有的多样性，敏捷的 API 保护成为当务之急。

失效的 API 身份验证

API 是为了连接计算机而生，因此许多 DevOps 团队都以为人类不会与 API 端点通信。F5 Labs 报告中有这样一个例子：一名研究人员将几个 API 请求链接在一起，在一款移动应用上“赚取”了价值数十万美元的积分。该应用会持续生成令牌来防止滥用，却没有设置有效期，于是导致它们一遍又一遍地被利用。

如果不对 API 身份验证令牌进行恰当的验证，攻击者就会趁虚而入。幸好该漏洞是被研究人员发现的，如果被攻击者钻了空子，企业可能会面临灭顶之灾。

失效的 API 授权

不言而喻，失败的 API 身份验证会导致失效的 API 授权。F5 Labs 报告还描述了一起事件：涉事的操作系统有一个 bug 允许对 API 发出恶意 HTTP 请求，让攻击者轻轻松松就能拿到授权令牌。一旦攻击者获得了此授权令牌，他们就拥有了管理员权限。

NGINX 提供了多种方法来保护 API 和验证 API 客户端身份。有关更多信息，请参阅基于 IP 地址的访问控制列表 (ACL)、数字证书身份验证和 HTTP 基础身份验证的相关文档。此外，NGINX Plus 本身就支持验证用于 API 身份验证的 JSON Web Token (JWT)，详情请参见我们的博文《借助 JWT 和 NGINX Plus 验证 API 客户端身份》。