使用 NGINX App Protect WAF 保护您的 API 网关

随着整体式应用转向微服务，应用的开发速度比以往更快。 速度是保持竞争力的必要条件，而 API 则处于这些快速现代化努力的前沿。 但是应用现代化 API 的流行对于应用程序安全具有重大影响。 API 是易受攻击的目标，会将应用逻辑和敏感数据暴露给其他应用程序或第三方。 随着 API 的使用增长，对 API 网关的需求也在增长。

根据 F5 的《 2021 年application战略状况报告》 ，企业正在使用各种方法实现现代化，而 API 在这些现代化努力中名列前茅：

• 58% 的企业正在添加一层 API 来支持现代用户界面
• 51％ 正在添加现代应用组件（例如 Kubernetes）
• 47％ 正在重构（修改应用程序代码本身）
• 40% 的企业正在迁移至公共云（提升和转移），而无需进行现代化

随着组织的发展，他们可以通过采用 API 网关来降低 API 风险。 在 F5 更新的2022 年application战略状况报告中，我们发现 API 网关在边缘或边缘附近的表现最佳。 在这里，API 网关可以在攻击影响整个网络之前阻止攻击，为多个 API 提供统一、一致的保护。 API 网关封装了应用程序的内部结构，简化了客户端与 API 之间的通信。客户端无需调用特定服务，只需连接到 API 网关即可。 这为客户端提供了特定的 API，减少了客户端和 API 之间的往返次数，并简化了客户端代码。

F5 NGINX 客户已成功在分布式环境中部署了 API 网关。 但是，如果您的 API 网关不安全，恶意行为者仍然可以通过。 在 NGINX，我们拥有强大的安全工具，以确保 API 网关后面的应用程序在这个不断变化的环境中保持安全。

更多 API 意味着更多攻击面

API 并不是什么新鲜事。 基于 Web 的 API 可以追溯到 20 世纪 90 年代，甚至在我们今天所知的互联网出现之前就已经存在各种版本的 API，作为小型分布式网络之间的通信。 我们现在看到的——改变游戏规则的——是使用 API 的现代架构。

虽然 API 在加速现代化方面发挥着至关重要的作用，但它们同时也变得越来越容易被利用。 在微服务架构中，单个 API 可以有数百个端点，单个应用可以由许多使用 API 相互连接的微服务组成。 这与过去的单一应用程序不同，过去的单一应用程序只有一个入口点需要保护。 由于每个微服务暴露多组 API 端点，潜在的攻击面增加了十倍。

F5 的 2022 年报告还发现，大多数组织拥有 200 到 1,000 个应用程序，77% 的组织在多个云中运行应用。 在分布式环境中，添加到产品组合的应用程序和 API 越多，可能的攻击面就越大。

OWASP API 安全十大漏洞

其特点是API是开放的，可以暴露敏感数据。 开放式 Webapplication安全项目 (OWASP) 在其OWASP API 安全 Top 10 项目中重点介绍了最普遍的漏洞：

随着开发周期的加快，当今的企业需要敏捷性和速度。 在这个脆弱的、 API 驱动的环境中，安全解决方案必须具有适应性、轻量级，并作为 API自动化部署流程的一部分纳入其中。

使用 F5 NGINX Plus 开始您的 API 安全

备受瞩目的 API 攻击经常成为头条新闻。 2019 年，共享出行公司Uber 的 API 中发现了一个严重的漏洞——一个易受攻击的 API 端点允许不良行为者窃取有价值的数据，包括乘客的身份验证令牌。 值得庆幸的是，我们在造成任何损害之前就发现了这个错误。 2021 年，LinkedIn 就没有那么幸运了——由于 API 漏洞，黑客窃取了超过 7 亿 LinkedIn 用户的数据，然后在暗网上出售。

通过部署F5 NGINX Plus作为您的 API 网关，您可以在处理 API 路由和交付时以高性能进入这个快速的 API 环境。 独立技术研究和分析公司 GigaOm对 NGINX 与其他 API 网关解决方案进行了基准测试。 基准测试结果显示，NGINX 每秒能够处理 30,000 个请求，延迟不到 30 毫秒，比超大规模服务器的 API 网关延迟低 1000 倍。

NGINX Plus 不仅提供针对 OWASP API 漏洞的开箱即用保护，其额外的安全保护还包括检查格式错误的 cookie、JSON 和 XML，并验证允许的文件类型和响应状态代码。 它确保遵守 HTTP RFC 并检测用于掩盖攻击的逃避技术。

NGINX Plus 快速路由 API 请求，同时对 API 客户端进行身份验证和授权以保护您的 API，并限制流量速率以确保基于 API 的服务免于过载。 这些工具还可以保护您的 API 免受 OWASP API 安全十大漏洞的侵害：

• 身份验证和授权机制——确保只有具有正确访问权限的客户端才能使用您的 API。 其中一种机制是 JSON Web Tokens (JWT) 中的声明。 这解决了 OWASP API 安全 Top 10 中的多个漏洞： 对象级授权损坏（API1）、用户身份验证损坏（API2）、功能级授权损坏（API5）以及日志记录和监控不足（API10）。
• 速率限制策略——通过设置 API 网关在规定时间段内从每个 API 客户端接受的请求数量，保护您的 API 免于超负荷并减轻 DDoS 攻击。 使用 NGINX Plus，速率限制可以特定于源（例如，基于 JWT 声明的值），因此有效用户不会受到影响。 这有助于解决缺乏资源和速率限制（API4）漏洞。

使用 F5 NGINX App Protect WAF 强化您的 API

使用F5 NGINX App Protect WAF保护您的 API 网关可提供额外的 API 安全性并减轻注入（API8）等 OWASP 攻击。 与提供 OWASP API 保护最低限度的其他 API 网关和管理提供商不同，NGINX App Protect WAF 提供针对远程代码执行 (RCE)、跨站点脚本 (XSS) 和其他攻击媒介等漏洞的额外保护。 NGINX App Protect WAF 还为日志记录和监控不足(API10) 提供了必要的攻击可见性。 这些记录的攻击详细信息可以发送到安全信息和事件管理 (SIEM) 系统或其他客户数据湖进行进一步分析。

如果您使用 NGINX Plus 作为 API 网关和负载均衡器（用于路由需要公开到互联网的 API 以及供外部开发人员和合作伙伴使用），那么它是部署 NGINX App Protect WAF 进行保护的最佳位置。 通过减少 API 流量的跳数，可以以最少的复杂性和最低的延迟添加保护。

根据某些行业处理敏感数据（个人身份信息 [PII]）的 PCI 合规性要求，必须在开放的公共网络上对有效负载进行端到端加密。 在 API 网关处（负载均衡器或 CDN 后面）安装 NGINX App Protect WAF 意味着有效负载在 API 网关处解密之前保持完全加密。 因此，您的 API 可以在满足处理敏感数据的要求的同时保持受到保护。

使用 F5 NGINX App Protect WAF 实现多层保护

您可能有一个负载均衡器，并且您可能在该负载均衡器上有一个 WAF – 例如 F5 Advanced WAF（API 安全 - 新一代 WAF） 。 在这些背后，您已经部署了一个 API 网关。 那么，如果您的负载均衡器上已经有 WAF，为什么还需要在 API 网关上安装 WAF？

从边缘的负载均衡器-WAF 组合转移到环境内部的 API 网关-WAF 组合的一个主要好处是可以对安全性进行更严格、更精细控制。 可以将安全责任移交给 API 团队，以使策略更加针对 API。

通过这种两层方法，您可以确保即使在最快的 API 开发和发布周期中，您的 API 也能受到保护。

使用 OpenAPI 模式验证增加积极安全性

必须针对 API 进行保护的一个关键领域是 Swagger 的OpenAPI 规范的验证。 OpenAPI 模式对于每个 API 都是唯一的，并且随着每个 API 版本而变化。 基于 API 的 OpenAPI 模式的保护不能等待 IT 团队更新其维护的集中式 WAF 上的安全控制，这需要批准和仔细测试，以避免对其他 API 和应用程序产生意外影响。

NGINX App Protect WAF 可以验证 OpenAPI 模式，验证请求是否符合 API 支持的内容（方法、端点、参数等）。 这就是为什么最好让 NGINX App Protect WAF 在负载均衡器的集中式 WAF 后面的 API 网关上提供积极的安全性。

“安全即代码”与 API 部署保持同步

CI/CD 管道是为了速度而构建的，而不是为了安全。 API 的发布频率也比过去的应用程序更高。 这就是我们看到 API 驱动领域向左转移的原因。 通过左移或在应用程序开发生命周期的早期应用安全控制，DevOps 朝着将安全视为代码的DevSecOps文化迈进。

无论您将 WAF 定位在 API 网关、负载均衡器还是两者处，都需要以自动化方式部署 WAF 配置以跟上 API 版本的变化。 当组织采用左移文化并将“安全即代码”集成到 CI/CD 管道中时，安全性可以融入到应用和 API 开发的每个阶段，而不是事后才想到。

将安全策略和配置作为代码使用有很多好处：

• 可以轻松地从源代码存储库中提取代码。
• 您的 SecOps 团队可以创建并维护声明性安全策略，以确保保护业务所需的控制到位。
• 声明性策略可以重复编码到新的应用程序和 API 中。
• 安全性已自动化并纳入 CI/CD 管道。

当自动化 API 模式时，每次更新 API 时，您还需要更新该文件中的配置和代码。 再次强调，自动化是关键。 一旦完全采用左移或“安全第一”的理念，开发人员就可以轻松地从 repo 中获取该代码——保持敏捷性、提高速度并加快产品上市时间。

为您的 API 提供高性能保护

无论您将 WAF 放在哪里来保护您的 API，高性能和低延迟都是使您的 API 能够快速响应客户以获得更丰富用户体验的要求。 NGINX App Protect WAF 的轻量级架构在云端以极低的计算需求提供了这种高性能和低延迟。

在其高性能应用安全测试报告中，GigaOm 报告了 NGINX App Protect WAF、AWS WAF、Azure WAF 和 ModSecurity 开源 WAF 的性能测试结果。 GigaOm 发现，对于需要高性能的应用而言，NGINX App Protect WAF 的延迟比 NGINX 上的 ModSecurity OSS WAF 低 4.7 倍，比 AWS WAF 低 128 倍。

NGINX 是唯一将 WAF 嵌入 NGINX API 网关的供应商，从而减少了 API 流量的跳数。 层间跳数越少，延迟、复杂性和故障点就越少。 这与不与 WAF 集成的典型 API 管理解决方案形成鲜明对比（您必须单独部署 WAF，并且一旦设置完成，API 流量必须分别穿越 WAF 和 API 网关）。 NGINX 的紧密集成意味着高性能，同时又不损害安全性。

结论

在 NGINX，我们通过 NGINX Plus 和 NGINX App Protect WAF 提供强大的 API 安全性。 借助 NGINX 的轻量级可扩展性和 F5Advanced WAF（API 安全 - 新一代 WAF）引擎的稳健性，您可以进入 API 驱动的世界，并确信您的现代应用程序是安全的。

秉承 NGINX 的核心价值，NGINX App Protect WAF 是一种现代应用软件安全解决方案，它与平台无关，并与常见的 DevOps 工具链无缝集成，以消除摩擦并加速安全部署。 借助声明性配置功能，安全性可以作为 CI/CD 管道和整个软件开发生命周期 (SDLC) 的一部分实现自动化。 这不仅有助于加快发布速度，而且还可以帮助组织构建可靠且受保护的 API，同时弥合 DevOps 和 SecOps 团队之间的差距并实现向 DevSecOps 的文化转变。

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