您的 API 网关足够安全吗？

本文转载自 The New Stack。

快问快答：贵企业使用了多少个 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 提供了组成应用的所有商用和开源软件组件的详细清单。如欲了解有关 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 成为您的利器！