NGINX.COM

随着系统从单体架构转向微服务,应用的开发速度也变得比以往任何时候都快。速度是保持竞争力的必要条件。在日新月异的应用现代化进程中,API 是最核心的要素之一。随着 API 在现代应用中的广泛流行,其对应用安全带来日益增长的重要影响。由于 API 将应用逻辑和敏感数据暴露给其他应用或第三方,因此非常容易遭到攻击。随着 API 使用量的增长,对 API 网关的需求也与日俱增。

根据 F5 的《2021 年应用策略现状报告》,企业采用了多种多样的方法推进现代化,其中 API 名列榜首:

  • 58% 的受访者选择添加一层 API 来启用现代接口
  • 51% 的受访者选择添加现代应用组件(例如 Kubernetes)
  • 47% 的受访者选择采用重构的方法(修改应用代码本身)
  • 40% 的受访者正在迁移到公有云(直接迁移上云),而没有进行现代化升级

随着企业的发展,他们可以通过采用 API 网关来降低 API 风险。F5 最新的《2022 年应用策略现状报告》指出,将 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 到 1000 个应用,其中 77% 的受访企业在多云环境中运行应用。企业在分布式环境中引入的应用和 API 越多,潜在的受攻击面就越大。

 

OWASP 十大 API 安全漏洞

一般来说,API 是开放的,可以暴露敏感数据。开放式 Web 应用安全性项目 (OWASP) 指出了十个最常见的 API 安全漏洞

API1. 失效的对象级授权
API2. 失效的用户身份验证
API3. 过度的数据暴露
API4. 缺乏资源和速率限制
API5. 失效的功能级授权
API6. 批量赋值
API7. 安全配置错误
API8. 注入
API9. 资产管理不当
API10. 日志记录和监控不足

 

随着开发周期的加快,敏捷性和速度成为当今企业的当务之急。在当今这个脆弱的、由 API 驱动的环境中,安全解决方案必须具备适应性和轻量级的特点,并且能够成为 API 自动化部署流程的一部分。

 

保护 API 安全,从 F5 NGINX Plus 开始

API 攻击事件登上头条引起轰动的事情已经屡见不鲜。2019 年,共享出行应用公司优步被曝其 API 存在严重漏洞 —— 它的一个 API 端点非常容易遭到攻击,允许攻击者盗取重要数据,包括打车者的身份验证令牌。值得庆幸的是,这个漏洞在还没有造成任何伤害之前就被发现了。而 LinkedIn 领英就没有那么幸运了 —— 2021 年,由于存在一个 API 漏洞,黑客借此窃取了 7 亿多名 LinkedIn 用户的数据,随后又在暗网上兜售这些信息。

通过将 F5 NGINX Plus 部署成 API 网关,您可以紧跟 API 这一快速发展的潮流,在处理 API 路由和交付时获得出色的性能。GigaOm(一家独立技术研究和分析公司)对 NGINX 与其他 API 网关解决方案进行了基准测试和比较。结果表明,NGINX 能够每秒发送 30,000 个请求,并且延迟不到 30ms,比一些超大规模企业的 API 网关低 1000 倍。

NGINX Plus 不仅提供了开箱即用的 OWASP API 漏洞防御机制,而且还带来了额外的安全保护,例如检查格式错误的 cookie、JSON 和 XML,验证允许的文件类型和响应状态码等。它可以确保 HTTP RFC 合规性,并检测用于掩码攻击的规避技术。

NGINX Plus 能够快速路由 API 请求,同时对 API 客户端进行身份验证和授权以保证 API 安全,并对流量实施速率限制,以防止基于 API 的服务过载。以下工具也可以保护您的 API 免遭 OWASP 十大 API 安全漏洞攻击:

  • 身份验证和授权机制 —— 确保只有那些具有正确访问权限的客户端才能使用您的 API。JSON Web Token (JWT) 中的“声明(Claims)”机制就是一个典型的例子。身份验证和授权可以防御 OWASP 十大 API 安全风险中的多个漏洞,包括失效的对象级授权 (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 威胁。其他 API 网关和管理解决方案提供商仅针对 OWASP 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 呢?

将边缘侧的“负载均衡器- WAF 组合”转变成环境内的“ API 网关- WAF 组合”有一个重要的好处,那就是能够实现更严格、更细粒度的安全控制。这种方法允许将安全责任移交给 API 团队,使得安全策略更具有 API 针对性。

借助这种双层保护,即使在最快速的 API 开发和发布周期中,您的 API 也能保持安全。

 

通过 OpenAPI 模式验证主动安全防御

针对 API 的保护的一个关键领域就是验证是否符合 Swagger 的 OpenAPI 规范。每个 API 都具有独一无二的 OpenAPI 模式,并且该模式因 API 版本而异。如果采用基于 OpenAPI 规范模式的保护,那么我们根本等不及 IT 团队更新其维护的集中式 WAF 上的安全控制,因为这一更新需要得到批准并进行严谨的测试,以免对其他 API 和应用带来意想不到的影响。

NGINX App Protect WAF 可以验证 OpenAPI 规范,核证请求是否符合 API 支持的内容(方法、端点、参数等)。出于以上原因,我们认为让 NGINX App Protect WAF 在负载均衡器集中式 WAF 后面的 API 网关提供主动安全防御是明智之举。

 

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

CI/CD 流水线是为了速度而生,其初衷与安全性无关。API 的发布频率也比以往的应用高得多,因此 API 驱动的 DevOps 环境正在呈现出“左移”的趋势。通过“左移”或者在应用开发生命周期的早期实施应用安全控制,DevOps 正在朝着“安全即代码”的 DevSecOps 文化演进。

无论是在 API 网关、负载均衡器上还是在这两个位置均安装 WAF,WAF 配置都需要以自动化的方式部署,以跟上 API 版本的变更速度。当企业拥抱“左移”文化并将“安全即代码”整合到 CI/CD 流水线中时,安全性就可以被构建到应用和 API 开发的每个阶段中,而不是事后再补救。

以代码的形式使用安全策略和配置有很多好处:

  • 您可以轻松从源代码存储库中拉取代码。
  • 您的 SecOps 团队可以创建并维护声明式安全策略,以确保保护业务所需的控制措施都已到位。
  • 声明式策略可以重复编码到新的应用和 API 中。
  • 安全性成为 CI/CD 流水线中的一个自动化组成部分。

在采用自动化 API 模式时,只要您更新 API,就要更新该文件中的配置和代码。再次重申一下,自动化是关键。一旦完全采用了“左移”或“安全为先”的理念,开发人员就可以轻松地从仓库中获取代码,从而保持敏捷性、提高开发速度并缩短上线时间。

 

为您的 API 提供高性能保护

无论您将 WAF 部署在何处来保护 API,高性能和低延迟都是让 API 能够迅速响应客户、丰富用户体验的必要条件。NGINX App Protect WAF 的轻量级架构能够实现这种高性能和低延迟,并且在云端的计算需求极低。

GigaOm 的《高性能应用安全测试报告》展示了 NGINX App Protect WAF、AWS WAF、Azure WAF 以及 ModSecurity 开源 WAF 的性能测试结果。GigaOm 发现,NGINX App Protect WAF 的延迟比 ModSecurity OSS WAF on NGINX 低 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 和稳健、强大的 F5 Advanced WAF 引擎,您可以自信从容地迈入 API 驱动的世界,并且不必担忧您的现代应用的安全性。

作为一款现代应用软件安全解决方案,NGINX App Protect WAF 坚持秉承 NGINX 的核心价值,不受平台限制,能够无缝集成常见的 DevOps 工具链,从而消除摩擦并加快安全部署。凭借声明式配置功能,安全性可以成为 CI/CD 流水线以及整个软件开发生命周期 (SDLC) 中的一个自动化组成部分。这不仅有助于加快发布速度,而且还可以帮助企业建立可靠和受保护的 API,同时弥合 DevOps 和 SecOps 团队之间的差距,并推动向 DevSecOps 文化转变。

想要亲身体验 NGINX App Protect WAF 吗?立即下载 30 天免费试用版,或联系我们讨论您的用例

Hero image
免费 O'Reilly 电子书:
《NGINX 完全指南》

更新于 2022 年,一本书了解关于 NGINX 的一切

关于作者

Thelen Blum

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

关于作者

Daphne Won

F5 NGINX 应用安全产品管理总监

关于 F5 NGINX

F5, Inc. 是备受欢迎的开源软件 NGINX 背后的商业公司。我们为现代应用的开发和交付提供一整套技术。我们的联合解决方案弥合了 NetOps 和 DevOps 之间的横沟,提供从代码到用户的多云应用服务。访问 nginx-cn.net 了解更多相关信息。