原文作者：Andrew Stiefel- F5 产物营销司理
原文链接：您的 API 网关足够安全吗？
转载来源：NGINX 中文官网
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
快问快答：贵企业使用了多少个 API？即所有用于内部产物、外部服务以致 Amazon S3 对象存储或 Kubernetes 等底子设施管理的 API。
如果您不知道答案，也不必尴尬，由于并非只有您不知道。在大量观察中，首席信息官和首席信息安全官认可，他们没有全部 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 流量。
实际上，API 网关的功能可由反向代理或负载均衡器执行，而且正越来越多地由 Ingress controller（Ingress 控制器）来执行。我们之以是知道这一点，是由于许多 NGINX 开源版用户对其 NGINX 实例进行专门设置以管理 API 流量。
这需要进行大量定制，因此许多 DevOps 团队会选择部署已设置好的 API 网关（比方 NGINX Plus）来处理一些最紧张的 API 管理用例也就屡见不鲜了。
API 网关通过充当访问 API 的外部应用的中心控制点和访问点来改进安全防护。它们不仅可以执行身份验证和授权计谋，并实施速率限制及其他安全防护措施，以防范恶意攻击和未经授权的访问，而且还能够对传输中数据进行加密，并提供可见性和监控功能，从而帮助识别和防止安全漏洞。API 网关还可对流量进行优先级分别，执行服务级别协议 (SLA) 或有关 API 使用的业务决议，并节省网络和盘算资源。
一旦完成安装并全面部署后，API 网关每每具有粘性，很难再更换。因此，必须确保第一次就选择合适的 API 网关。此事关系巨大——并非所有 API 网关都能提供类似水平的安全性、耽误、可观测性及灵活性。
一些 API 网关依靠于底层开源技术，这些技术可能会导致安全漏洞或可靠性问题。而另一些 API 网关则可能需要执行繁琐的集成步骤，并会造成不可预见的流量耽误。所有这些都可能影响 API 网关的安全性，因此需要在选择时慎重思量。
了解API网关底层机制很紧张
市场上的大多数 API 网关办理方案均基于开源软件的修改版本而构建。常用的有 NGINX、HAProxy、Envoy 和 Traefik。然而，许多 API 网关办理方案都是闭源办理方案（它们会在专有代码中封装开源组件）。也就是说，这些专有办理方案仍然完全依靠于开源组件的底层安全防护。
这可能会带来巨大安全漏洞。当被用于专有 API 网关办理方案的开源项目被爆出漏洞后，API 网关厂商可能需要数月的时间才能推出安全补丁，由于对反向代理层进行任何更改均需执行回归测试并实施其他质量保证措施，以确保修复代码不会影响稳定性或性能。攻击者深知这一点，因此每每会对准这些产物中袒露在外且未打补丁的开源层。
结论是什么呢？您需要了解您的 API 网关采用了哪些技术。如果您需要为 API 部署高度安全的办理方案，那么对第三方模块和底子组件（开源或专有）的依靠可能会产生巨大的风险。
使用软件物料清单考核安全依靠
创建软件物料清单 (SBOM) 是评估潜在漏洞的最常用方法之一。简而言之，SBOM 提供了组成应用的所有商用和开源软件组件的详细清单。
在全面了解软件堆栈后，您便可评估所有项目是否符合安全和合规标准。您每每会发现，许多工具都有嵌入式依靠。一些项目得到了积极维护，并依照标准化服务级别协议发布了已知 CVE（通用漏洞和袒露）的补丁。
但许多巨大开源项目并非商业实体，因此它们可能不会发布有关漏洞披露或保证补丁时间的服务级别协议，致使您更容易受到 CVE 的影响。这会偶然间造成您的服务不符合规定的标准。因此，您需要验证 SBOM 中的每个组件是否符合标准。
与其他安全防护控制的轻松集成至关紧张
虽然 API 网关是 API 安全防护的紧张组成部分，但也只是此中的一个要素。大多数运行 API 网关的企业还需在其网关的前面部署 Web 应用防火墙 (WAF) 来拦截攻击（OWASP 十大 API 安全防护风险等）。如果底子设施为分布式，则需部署多个 WAF。在大型企业中，API 网关需要与全局防火墙相集成，以监管所有进出流量。
即使是有助于应对 API 发现和威胁分析等挑战的新型 API 安全防护办理方案，也离不开与强大 API 网关的精密集成。这些工具每每依靠 API 网关来了解 API 流量，并通常与 API 网关协同应对新兴威胁。
无论是哪一种情况，API 网关和安全防护工具之间的精密集成对于维护有效的安全防护而言至关紧张。最便捷的方法是使用单个监控办理方案同时跟踪防火墙和网关流量。
这种集成可能具有挑战性，尤其是当企业在多云或混淆情况中运行时。集成挑战还可能意味着，若更改网关设置，则需更新 WAF 或全局防火墙，这会增加团队的工作量，或者最糟糕的情况是，拖慢应用开辟团队的工作速度，由于他们必须等待其防火墙或网关设置请求得到处理。
计谋细粒度可能因情况差别而有很大差别
从理论上讲，无论在何种情况下运行，API 网关均可执行同一计谋。然而，如果您必须在差别的情况中通过差别的组件组合来构建 API 网关，那么实际情况将迥然差别。
比方，API 管明白决方案可能将一种底层开源技术用于其 API 网关的本地安装或托管安装，而将另一种办理方案用于云服务。计谋细粒度和由此带来的所有安全上风也可能明显受限于底层底子反向代理自己或两种实现之间功能的差别等。
因此，进行广泛的概念验证至关紧张 (POC)。只有这样，才能确保 API 网关办理方案可为不停增长的 API 群提供所需的计谋细粒度和控制范例。
计谋细粒度和控制不足可能会导致安全防护功能的敏捷性降低，这每每会使 API 网关沦为钝器，而非管理 API 情况中快速变化的攻击面所需的利器。
速度对应用开辟团队很紧张
对于应用团队和 API 所有者而言，API 网关在执行计谋的同时安全传输流量的速度至关紧张。痴钝的 API 会迫使依靠进程等待，进而进一步影响应用的整体性能，造成用户体验不佳。
不得不面对痴钝 API 的团队很有可能绕过安全体系或部署自己的 API，以提高性能并更好地控制用户体验和依靠项。这些影子 API，如果未对 API 进行适当的锁定、测试和监控，便会产生巨大的安全风险。
API 网关自己以快为要。但同样紧张的是，需要密切关注 WAF 和 API 网关组合产生的耽误影响。抱负情况下，这两者精密集成，可降低对数据包速度的影响。这也是近似生产的概念验证对于做出正确决议至关紧张的另一个缘故起因。
结论：API 网关的安全系数可能会有所差别 — 审慎选择
API 是技术底子设施和组合式松散耦合应用的将来。随着越来越多的企业转向云情况、微服务及其他解耦和分布式盘算范式，API 的遍及速度可能会加速。
即使您反潮流地向单体应用的方向发展，您的应用仍需管理 API，以便与全球其他实体进行通信，包罗合作伙伴、客户、存储层、Stripe 等支付服务提供商、CDN 等关键云服务。
购买 API 网关一事需要严肃对待，慎重思量。当然，最紧张的思量因素就是安全。
本文列出了四项标准：可靠的底层技术、与安全防护工具的轻松集成、跨情况的计谋细粒度及低耽误，但这只是在将 API 网关投入生产情况之前所需考量的诸多因素中的几项。
请深图远虑，审慎选择，愿 API 成为您的利器！
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
