你的API网关有多安全？

你的组织使用了多少API？我们谈论的是内部产品、外部服务，甚至是基础设施管理，如亚马逊的S3对象存储或Kubernetes。很多人不知道答案。在一次又一次的调查中，首席信息官和首席信息官承认他们并没有一份准确的API目录。然而，在继续采用以API为中心的技术范式（如云原生计算和微服务）的推动下，进一步使用API是不可避免的。

根据Gartner软件工程研究主管Mark O'Neill在2022年分享的统计数据：

——98%的组织使用或计划使用内部API，高于2019年的88%。

——94%的组织使用或计划使用第三方提供的公共API，高于2019年的52%。

——90%的组织使用或计划使用合作伙伴提供的私人API，高于2019年的68%。

——80%的组织提供或计划提供公开的API，高于2019年的46%。

API网关仍是关键基础设施组件

为了应对这种快速增长及其带来的管理和安全挑战，首席信息官、平台运维团队和云架构师正转向API网关来集中管理API流量。API网关帮助发现、管理、观察和保护网络上的API流量。

事实上，API网关是一种可以由反向代理或负载均衡器执行的功能，并且越来越多地由入口控制器执行。我们知道这是事实，因为许多NGINX开源用户专门配置他们的NGINX实例来管理API流量。

然而，这需要大量的定制，因此许多DevOps团队选择部署一个API网关并不奇怪，该网关已经配置为处理一些最重要的API管理用例，如NGINX Plus。

API网关通过充当访问API的外部应用程序的中心控制点和访问点来提高安全性。它们可以强制执行身份验证和授权策略，并实施速率限制和其他安全措施，以防止恶意攻击和未经授权的访问。

此外，API网关可以加密传输中的数据，并提供可见性和监控功能，以帮助识别和防止安全漏洞。API网关还可以对流量进行优先级排序，强制执行服务级别协议（SLA）或围绕API使用的业务决策，并节约网络和计算资源。

一旦安装并完全部署，API网关往往很难移除。因此，确保第一次选择正确的API网关至关重要。这风险很大。因为并非所有API网关都提供相同级别的安全性、延迟、可观察性和灵活性。

有些依赖于底层的开源技术，这些技术可能会导致安全漏洞或可靠性问题。其他可能需要繁琐的集成步骤，并产生无法预见的流量延迟。所有这些都会影响API网关的安全性，需要在选择过程中加以考虑。

更多需要考虑的因素

市场上大多数API网关解决方案都是基于开源软件的修改版本构建的。NGINX、HAProxy、Envoy和Traefik都是常用的。然而，许多API网关解决方案都是闭源代码（它们使用封装在专有代码中的开源代码）。尽管如此，此类专有解决方案仍然完全依赖于开源组件的底层安全性。

这可能会造成严重的安全漏洞。当在专有API网关解决方案下的开源项目中宣布漏洞时，网关供应商可能需要几个月才能推出安全补丁，因为对反向代理层的任何更改都需要回归测试和其他质量保证措施，以确保修复不会影响稳定性或性能。攻击者知道这一点，通常会将这些产品中暴露的和未修补的开源层作为攻击目标。

底线是什么？你需要知道哪些技术是API网关的一部分。如果需要高度安全的API解决方案、模块和基础组件（无论是开源还是专有）依赖第三方可能会产生不可接受的风险。

使用软件物料清单审核安全依赖关系

创建软件物料清单（SBOM）是评估潜在漏洞的最常见方法之一。简单地说，SBOM是构成应用程序的所有软件组件（商业和开源）的详细清单。

一旦你对软件堆栈有了完整的了解，就可以评估所有项目是否符合安全和合规标准。你经常会发现，许多工具都在其中嵌入了依赖关系。一些项目正在积极维护，并根据标准化服务级别协议发布已知CVE（常见漏洞和风险）的补丁。

但许多主要的开源项目都不是商业实体，因此它们可能不会发布关于漏洞披露或保证修补时间的SLA，从而使你更容易受到CVE的攻击。反过来，这可能会无意中使你的服务不符合要求的标准。出于这些原因，你需要验证SBOM中的每个组件是否都符合要求。

易于与其他安全控制集成至关重要

虽然API网关是API安全的关键部分，但它们只是一个元素。大多数运行API网关的组织还需要在其网关前面安装一个web应用程序防火墙（WAF）来阻止攻击（OWASP API Security Top 10等）。如果他们的基础设施是分布式的，需要一个以上的WAF。在大型企业中，API网关需要与全局防火墙集成，该防火墙对所有进出的流量进行管理。

即使是帮助应对API发现和威胁分析等挑战的较新API安全解决方案，也依赖于与API网关的强大集成。这些工具通常依赖于API网关来查看API流量，并且通常与API网关一起处理任何新出现的威胁。

在所有情况下，API网关和安全工具之间的紧密集成对于维护有效的安全至关重要。如果你可以使用单一的监控解决方案来跟踪防火墙和网关流量，这是最方便的。

这可能是一个具有挑战性的集成，特别是当组织在多云或混合环境中运行时。集成挑战还可能意味着网关配置的更改需要更新WAF或全局防火墙，从而增加团队工作负载，或者（最坏的情况下）减慢应用程序开发团队的速度，因为他们必须等待防火墙或网关配置请求同步。

策略粒度在不同环境中可能有很大差异

理论上，API网关无论在什么环境中运行都可以执行相同的策略。如果必须在不同环境中使用不同的组件组合来构建API网关，那么实际情况就大不相同。

例如，API管理解决方案可能使用一种底层开源技术来实现其API网关的内部或托管安装，另一种用于云服务。策略粒度和所有由此产生的安全好处也可能受到底层基础反向代理本身的严重限制，或者两种实现之间的功能不匹配。

出于这些原因，运行一个广泛的概念验证（POC）以密切模拟实时生产流量至关重要。这是确保API网关解决方案能够为不断增长的API星座提供所需的策略粒度和控制类型的唯一方法。

策略粒度和控制不足可能会导致安全能力不够灵活，通常会将API网关简化为一种生硬的工具，而不是管理API环境中快速变化的攻击面所需的精细手术刀。

速度对应用程序开发团队至关重要

API网关在执行策略的同时安全传递流量的速度对应用程序团队和API所有者至关重要。缓慢的API会迫使依赖进程等待，从而产生糟糕的用户体验，从而以复杂的方式影响应用程序的整体性能。

被迫处理慢API的团队更有可能绕过安全系统或自行开发以提高性能并更好地控制用户体验和依赖关系。这相当于影子IT的API，如果API没有被正确锁定、测试和监控，就会产生相当大的安全风险。

仅API网关必须很快。但同样重要的是，要看看WAF和API网关的组合所产生的延迟命中。理想情况下，这两者紧密结合，减少了减慢数据包速度的需要。这也是近生产POC对于做出正确决策至关重要的另一个原因。

结论：API网关安全有所不同，请明智选择

API是技术基础设施和可组合、松散耦合应用程序的未来。随着越来越多的组织转向云、微服务和其他解耦和分布式计算范式，它们的快速扩散可能会加速。

即使你逆潮流而动，朝着单体的方向发展，你的应用程序仍需要管理API以与其他地方进行通信，包括合作伙伴、客户、存储层、Stripe等支付提供商、CDN等关键云服务等。

API网关是一项需要仔细考虑的重要购买。当然，最重要的考虑是安全。

我们在这篇文章中提出的四个标准——可靠的底层技术、易于与安全工具集成、跨环境的策略粒度和低延迟——只是API网关在投入生产之前需要检查的众多条件中的几个。

明智地选择，深入思考，让API力量与你同在！

原文链接：

https://thenewstack.io/how-secure-is-your-api-gateway/