随着单体架构向微服务架构转型，应用开发速度比以往更快。要保持竞争力，速度至关重要，而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端点，潜在攻击面已扩大至原来的10倍。
F5的2022年报告还发现，大多数组织拥有200至1,000个应用，77%的组织在多个云中运行应用。跨分布式环境添加到应用组合中的应用和API越多，潜在攻击面就越大。
OWASP API安全十大漏洞
API通常具有开放性，可能会暴露敏感数据。开放式Web应用程序安全项目（OWASP）在其OWASP API安全十大风险项目中重点介绍了最常见的漏洞：
API1. 对象级授权失效
API2. 用户身份验证失效
API3. 过度数据暴露
API4. 资源不足和速率限制缺失
API5. 功能级授权失效
API6. 批量赋值
API7. 安全配置错误
API8. 注入
API9. 资产管理不当
API10. 日志记录和监控不足
随着开发周期不断加快，当今企业需要更加敏捷、高效。在这个由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 ms，比超大规模云服务提供商的API网关低1,000倍。
NGINX Plus不仅可提供开箱即用的OWASP API漏洞防护，还可检查格式错误的Cookie、JSON和XML，并验证允许的文件类型和响应状态码。它可确保符合HTTP RFC规范，并检测用于掩盖攻击的规避技术。
NGINX Plus可快速路由API请求，同时对API客户端进行身份验证和授权，以保护API，并通过流量限速防止基于API的服务过载。这些工具还可保护API免受OWASP API安全十大风险的影响：
- 身份验证和授权机制：确保只有具备适当访问权限的客户端才能使用您的API。其中一种机制是JSON Web Token（JWT）中的声明。这有助于应对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合规要求，负载必须在开放的公共网络中进行端到端加密。将NGINX App Protect WAF部署在负载均衡器或CDN之后的API网关上，可使负载在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版本而变化。基于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时，还需要同步更新该文件中的配置和代码。自动化仍是关键。全面采用安全左移或“安全优先”理念后，开发人员可以轻松地从代码仓库中获取相关代码，从而保持敏捷性、提高开发速度并缩短产品上市时间。
为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流量减少一次转发。减少层间转发次数有助于降低延迟和复杂性，并减少故障点。相比之下，典型的API管理解决方案并未集成WAF（必须单独部署WAF；完成设置后，API流量必须分别经过WAF和API网关）。NGINX的紧密集成可在不影响安全性的前提下实现高性能。
结论
NGINX通过NGINX Plus和NGINX App Protect WAF提供强大的API安全防护。凭借NGINX轻量级的可扩展性和F5 Advanced WAF引擎的稳健性，您可以放心迈入API驱动的世界，确保现代应用安全无虞。
秉承NGINX的核心价值观，NGINX App Protect WAF是一款现代应用软件安全解决方案，不受平台限制，可与常用DevOps工具链无缝集成，从而减少阻碍并加快安全部署。借助声明式配置功能，安全防护可作为CI/CD流水线和整个软件开发生命周期（SDLC）的一部分实现自动化。这不仅有助于加快发布速度，还能帮助组织构建可靠且受保护的API，同时弥合DevOps与SecOps团队之间的差距，推动文化向DevSecOps转变。
准备亲自试用NGINX App Protect WAF？立即开始30天免费试用，或联系我们，讨论您的用例。
关于作者
相关博客文章
NGINX Plus R26 正式发布
NGINX Plus R26通过缓存JSON Web密钥集加快JWT验证，并强化TLS握手，从而提升安全性。NGINX JavaScript的新功能包括增强对异步函数的支持，以及实现WebCrypto API。
使用NGINX App Protect DoS保护gRPC应用，抵御严重的DoS攻击
gRPC具备开发人员设计和部署现代应用所需的速度与灵活性，但其开放性也使其极易受到第7层DoS攻击。NGINX App Protect DoS可保护gRPC应用免受此类破坏性攻击。
Ingress Controller 选型指南（第 2 部分）：风险与面向未来的规划
了解选择错误的Ingress控制器可能带来的风险，以及如何从关键方面着手，让您的选择更好地适应未来需求。
NGINX Plus R19 正式发布
NGINX Plus R19扩展了监控功能，不仅提供更多指标，还新增了指标分析方式；增加试运行模式，用于测试限速效果；增强键值存储，以支持IP地址范围；并使限速更加动态。
NGINX现已正式加入F5
NGINX现已正式成为F5的一部分。Gus Robertson现任F5 NGINX业务部门负责人。他阐述了两家公司在人才、文化和愿景方面融合的价值，以及双方将如何携手增强NGINX的开源产品和商业产品。
