使用 F5 NGINX App Protect 和 F5 NGINX Plus 实现安全自动化，降低漏洞成本

您可能会惊讶地发现，通过自动化和人工智能（AI）改善安全态势所花费的资金最终会为您节省大量的金钱。 IBM 安全团队在其《2021 年数据泄露成本报告》中透露，安全漏洞给没有部署安全自动化和人工智能的组织造成的成本平均比完全部署自动化和人工智能的组织高出 80%——分别为 671 万美元和 290 万美元，相差381 万美元。 通过优先考虑安全自动化和人工智能，组织可以更快地识别和遏制漏洞，从而节省金钱和时间。

但是，当您将安全性集成到 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 Top 10攻击和恶意机器人
• 第 3 阶段- F5 NGINX Plus 使用本机功能以及与第三方单点登录 (SSO) 解决方案的集成对应用程序和 API 客户端进行身份验证并强制执行授权要求

这个由三部分组成的安全解决方案可以通过两种方式为您节省资金，尤其是在公共云环境中：

1. 只有合法流量才能到达您的应用程序，因为 NGINX App Protect DoS 会过滤掉来自 DoS 攻击的流量，然后 NGINX App Protect WAF 会消除OWASP Top 10等多种攻击媒介。
2. NGINX Plus 的高效、事件驱动设计意味着它可以在较低的 CPU 消耗下每秒处理大量请求。 在高效平台上仅处理合法的应用流量需要更少的计算资源，从而节省您的时间和金钱，并确保防御多种攻击媒介，而不会使您的工具不堪重负。

如果您目前正在使用F5 BIG-IP Advanced WAF（API 安全 - 新一代 WAF）来保护在您的数据中心运行的应用程序，那么可以直接将 NGINX Plus 添加为 Kubernetes 的入口控制器，并使用 NGINX App Protect Dos 和 WAF 作为全面的解决方案来扩展和保护您的现代应用并在云中编排 Kubernetes 应用程序。 使用 F5 的安全即代码方法，您可以通过声明性 API 或文件中的声明性 JSON 格式定义将基础设施和安全策略控制定义为代码，也可以将 BIG-IP XML 文件转换为 JSON 文件。 您的策略（SecOps 拥有和维护的标准公司安全控制）可以驻留在代码存储库中，可以从中获取它们并将其集成到您的开发管道中，就像任何其他代码一样。 这种方法有助于 DevOps 和 SecOps 弥合运营差距，以更低的成本和更好的安全性更快地将应用程序推向市场。

F5 将 WAF 策略构建和基准测试纳入开发流程，这是应用开发流程中“安全左移”和自动化应用部署的重要组成部分。

BIG‑IP 和 NGINX 中的可见性工具相互补充，使 SecOps 能够将自动化流程尽早融入到您的 DevOps 生命周期中。 BIG-IP 允许团队将 XML 文件转换为 NGINX 使用的 JSON 文件，以维护一致的安全策略。 NGINX 允许团队对已经安装的应用程序进行微调，同时带来现代应用程序安全自动化，以帮助抵消未来的漏洞和潜在攻击的成本。

第一阶段： NGINX App Protect DoS 防御 DoS 攻击

我们安全流量管理之旅的第一站是清除拒绝服务（DoS）攻击。 从一开始就制止这种滥用行为是必要的第一道防线。

我们之前注意到，攻击者越来越多地从传统的容量攻击转向使用 HTTP 和 HTTPS 请求或 API 调用在第 7 层进行攻击。 为什么？ 他们正在走阻力最小的路径。 基础设施工程师花费了数年时间构建针对第 3 层和第 4 层攻击的有效防御措施，使得这些攻击更容易被阻止并且成功的可能性更小。 第 7 层攻击可以绕过这些传统防御措施。

并非所有的 DoS 攻击都是容量限制性的。 通过 Slow POST或 Slowloris 等“低速”方法消耗服务器资源的攻击很容易隐藏在合法流量中。 虽然gRPC等开源 HTTP/2 远程过程调用框架提供了现代应用程序所需的速度和灵活性，但它们特有的开放性质使它们比专有协议更容易受到 DoS 攻击。

与传统的 DoS 保护不同， NGINX App Protect DoS通过利用自动用户和站点行为分析、主动健康检查和非接触配置来检测当今的攻击。 它是一种低延迟解决方案，可阻止常见攻击，包括 HTTP GET洪水、HTTP POST洪水、Slowloris、Slow read 和 Slow POST 。

为了打击这些攻击，SecOps 和 DevOps 团队需要将“安全即代码”自动化集成到他们的 CI/CD 工作流程中——这是左移思维的一部分。 NGINX App Protect DoS 可以实现这一点。 它通过高级保护来保护现代分布式应用程序和 API 免受 DoS 威胁，并通过使用轻量级软件包、持续威胁缓解反馈循环以及通过 RESTful API 与熟悉的 DevOps 工具集成来促进此模型，帮助协调 SecOps 和 DevOps 有时发生冲突的优先级。

NGINX App Protect DoS 集成了机器学习 (ML) 技术， IBM Security 报告强调该技术是大幅节省成本的关键。 它分析客户端行为和应用健康状况以模拟正常的流量模式，使用独特的算法创建提供最准确保护的动态统计模型，并部署动态签名以自动缓解攻击。 它还持续衡量缓解效果并适应不断变化的行为或健康状况。 这些功能使 NGINX App Protect DoS 能够阻止 DoS 攻击，其中每个攻击请求看起来都完全合法，并且单个攻击者甚至可能产生的流量比一般合法用户还少。

第 2 阶段： NGINX App Protect WAF 可防御 OWASP 十大漏洞

虽然 DoS 保护可以有效阻止恶意流量进入您的基础设施，但攻击仍然可以通过。 这就是为什么您需要一个 Web应用防火墙 (WAF) 来实现成功防御的下一阶段，它的重点是伪装成合法的不良行为者的流量。

NGINX App Protect WAF轻量且性能卓越，可提供全面的安全保护，包括检查响应、强制执行 HTTP 协议合规性、检测逃避技术、使用 Data Guard 屏蔽信用卡号和其他敏感个人信息，以及检查不允许的元字符和文件类型、格式错误的 JSON 和 XML 以及敏感参数。 它还可以防御更新的OWASP Top 10 ：

访问控制失效
加密失败
注射
不安全的设计
安全配置错误
易受攻击和过时的组件
识别和认证失败
软件和数据完整性故障
安全日志记录和监控失败
服务器端请求伪造

针对OWASP Top 10漏洞（例如A03:2021 注入）的网络攻击仍然很流行，这并不奇怪。 2021 年 7 月，开源电商网站WooCommerce 宣布其多款插件存在SQL 注入漏洞，当时正发生多起攻击事件。 由于企业和客户主要在线运营，因此攻击者将重点放在基于 Web 的应用程序上是有道理的，这些应用程序通常很复杂，由微服务组成，并且跨越分布式环境，其中许多 API 相互通信，增加了易受攻击的端点数量。

现代攻击也快速转变和适应。 这就是 AI 的作用所在，也是 IBM 强调其重要性的原因。 与 NGINX App Protect DoS 一样，NGINX App Protect WAF 中丰富的 ML 系统使平台操作、DevOps 和 SecOps 团队可以轻松共享攻击趋势和数据。 一项新功能——自适应违规评级功能——将通过检测应用程序行为何时发生变化来进一步利用机器学习。 凭借这一 ML 功能，NGINX App Protect WAF 不断评估每个应用的预测行为。 基于这些学习，它可以启用原本会被阻止的客户端请求，降低应用程序的违规评级分数，并显著减少误报，从而以更低的管理成本提供更好的用户体验。

NGINX App Protect WAF 还提供机器人保护。 如今，近50% 的互联网流量来自机器人。 通过预先消除已知的恶意流量，NGINX App Protect WAF 可以使用其 Bot Signature 数据库快速阻止机器人流量。

在 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 。

由于其特有的开放性，API 很容易受到攻击。 Gartner Research 在其年度报告中预测，API 将成为 2022 年最常见的攻击媒介，导致企业 Web 应用程序发生无数数据泄露。 当我们进入 2022 年并观察到 API 攻击面在各个组织中持续增长时，这一预测是正确的。

API认证事件： 2020 年application保护报告 F5 实验室强调了 API 事件的三个常见原因：

1. API 端点无需身份验证
2. API 身份验证失效
3. API 授权失效

API 端点无需身份验证

当您实施 API 流量的身份验证时，成功证明其身份的客户端会从受信任的身份提供商处收到令牌。 然后，客户端会在每次 HTTP 请求中出示访问令牌。 在请求传递给应用之前，NGINX Plus 通过验证令牌并提取令牌中编码的身份和其他数据（例如，组成员身份）来确保客户端的身份验证和授权。 假设令牌被验证并且客户端被授权访问资源，则请求被传递给应用服务器。 有几种方法可以完成此验证，但 OpenID Connect（基于 OAuth 2.0 协议构建）是一种启用 API 请求第三方身份验证的流行方法。

然而，市面上很多API在认证层面是没有保护的。 2021 年，互动健身平台Peloton 被曝出存在 API 漏洞。一名安全研究人员发现，攻击者可以对 Peloton 的 API 发出未经身份验证的请求，轻松获取未经身份验证的用户数据。 尽管 Peloton 在发生任何重大漏洞之前就修复了代码，但这一事故凸显了单一的安全方法没有考虑到 API 结构固有的多样性以及随之而来的防御灵活性需求。

API 身份验证失效

API 旨在将计算机连接到计算机，因此许多 DevOps 团队认为人类不会与 API 端点进行通信。 F5 实验室报告中的一个例子是，一名研究人员将多个 API 请求串联起来，在一款移动应用上“赚取”了数十万美元的积分。该应用不断生成旨在防止滥用的令牌，但没有设置有效期，因此可以反复使用它们。

如果您没有正确验证 API 身份验证令牌，攻击者可以利用 API 漏洞。 如果这种漏洞是由恶意行为者而不是研究人员发现的，则可能会危及整个企业。

API 授权失效

API 身份验证不成功自然会导致 API 授权中断。 F5 实验室的报告还描述了一个事件，操作系统中的一个错误允许对 API 发出恶意 HTTP 请求，从而使不法分子能够轻松访问授权令牌。 一旦攻击者获得了此授权令牌，他们就拥有了管理员权限。

NGINX 提供了多种保护 API 和验证 API 客户端的方法。 有关更多信息，请参阅基于 IP 地址的访问控制列表(ACL)、数字证书身份验证和HTTP 基本身份验证的文档。 此外，NGINX Plus 本身支持用于 API 身份验证的 JSON Web Tokens (JWT) 验证。 在我们的博客上使用 JWT 和 NGINX Plus 对 API 客户端进行身份验证了解更多信息。

立即开始

安全自动化使其成为每个人的责任。 通过优先考虑安全自动化，您的组织可以构建更可靠的应用程序、降低风险、降低运营成本并加快发布速度。 这意味着您的微服务、应用程序和 API 将获得可扩展且足够快的敏捷安全性，以跟上当今的竞争步伐。

这种三阶段安全结构还提供了最佳流程，因为您不希望因为 DoS 攻击而导致 WAF 检查流量陷入停滞，或者浪费宝贵的资源尝试对恶意行为者进行身份验证和授权。 通过及早消除容易识别的攻击，您可以节省时间和金钱，并提高应用程序的性能。

准备好亲自尝试 NGINX Plus 和 NGINX App Protect 了吗？ 立即开始30 天免费试用或联系我们讨论您的用例。