F5 NGINX：API蔓延问题出现的六大迹象

作者：Andrew Stiefel，NGINX 产品营销经理

据行业分析机构451 Group指出，目前企业拥有的 API 的平均数量超过15,000个。显然，这一数字远高于平台运营团队可以用电子表格跟踪的API 的平均数量。即使将API跟踪的责任分配给各个业务部门，考虑到API数量的惊人的增长速度，这仍然是一项艰巨的任务。

2021年，F5工程师和技术专家Rajesh Narayanan为这个问题创造了一个新词：API蔓延（API sprawl）。“API蔓延”一词的含义正如其名——即世界各地的企业中的API数量的加速增长，而这也给API的管理和防护带来了巨大挑战。这一问题有多严重？据Narayan估计，到2030年，全球部署和运行的API将超过10亿个。

现代应用在开发方式方面的变化加速了API的蔓延。微服务的兴起、用于系统内部通信的API的不断增加，以及多云和混合云架构的快速增加，都使得我们需要更多地使用API在应用之间进行通信。例如，作为容器编排的事实标准的Kubernetes就是使用API来实现所有的内部通信的。新的基础架构类型（如serverless架构）也意味着API可以在几乎所有环境中运行。同时还有更多种类的API技术需要管理——REST、GraphQL和gRPC都已被广泛使用，而更多的API查询协议也将很快出现。

更糟糕的是，网络罪犯绝对会乐于见到API蔓延。他们越来越多地将API作为他们精确攻击的目标，原因是API通常没有得到仔细的管理，而且默认配置的访问权限相对开放。

为了消除这种问题，必须以程序化、规模化的解决方案来应对API管理、发现和防护方面的挑战。不过在您能够有效应对API蔓延之前，您需要先了解该问题在您的组织机构中的严重程度。以下六个明显迹象表明您遇到了API蔓延问题。

1. 没有最近更新的API清单

API蔓延的典型症状是不知道在所有环境中都运行着哪些API，这通常是由于松散的API管理策略导致的——在这种策略下，团队无需注册仅在内部使用的API（即所谓的“影子API”）。

您的首要任务是准确盘点现有的API。但由于API的添加和弃用通常极为频繁，想要“准确盘点”就需要不断地进行统计。合理的解决方案是通过编程式的方式进行盘点并持续进行API发现，类似于网络扫描和资产发现。

从理论上讲，结构化的API审批流程也有所助益。但在现实中，对于API创建和版本管理等任务，不断“左移”的企业会想要缩减繁重的审批流程。对于这些企业来说，将API清单盘点作为CI/CD的一部分来构建流程通常是一种很好的方法，尤其是当API用于微服务和其他更现代的应用架构时。

2. 不知道每个API分别在何处运行

在现代基础架构环境中，仅仅知道API的存在还远远不够——还需要知道每个API的位置。端点可能会在不同基础架构形式的容器间互为镜像——横跨多个云平台、在混合云中，或者在像是 serverless 这样的多种服务中。

安全团队需要掌握API的位置信息，从而正确配置策略和防护措施并运行API安全测试。如果您需要在多个环境中运行API，这也会影响您对于API网关和其他API流量管理方式的选择。理想情况下，您会希望有一个适用全局的API网关解决方案，以便能够在不同环境中实现具有一致性的API流量管理和防护。

3. 无法轻松地识别API的所有者或负责人
如果您不知道API由谁负责，当API出现问题时，就不知道该找谁处理。通常情况下，当构建API的人或团队调岗或者离职时，那些对于平稳运营来说不可或缺的API就会成为“孤儿”。有时，API所有权的转移非常明确——但更常见的情况是，这个过程会被跳过或通过非正式手续完成。

为每个API分配所有权是清单盘点过程的一部分，它至关重要，因为这样可以确立问责制，帮助责任人合理地管理和防护他们负责的API。

4. 多个API在执行着类似或重复任务

当多个团队有相似但不完全相同的需求，通常会发生任务重合的情况，而且有人会说：“我们会通过构建自己的API来满足我们的需求，这样，我们就可以掌控自己的命运！”但是，拥有多个类似API会增加不必要的技术债务。因此，衡量有多少应用或服务需要使用API，并将其作为关键性能指标 (KPI) 之一非常重要。跟踪这些指标有助于最大程度地提高每个API的可重用性。整合API的另一种方法是转换到像是GraphQL一类的更灵活的形式。

5. 文档滞后超过2个版本

文档对于经验传递、新员工入职培训和组织弹性至关重要。可惜的是，编写和维护文档通常是工程师最痛恨的事情。过时的API文档通常表明API正在蔓延——因为这说明团队创建和更新API的速度太快，所以没时间更新文档——或者他们可以看似合理地这么解释他们不更新文档的行为。在最坏的情况下，过时的文档标示着其中提到的API是无人维护的孤儿。

庆幸的是，API往往有清晰定义的结构，使其易于理解。良好的API管理解决方案通常包含一个工具，用于帮助开发人员根据API规范自动生成文档。最常见的例子之一是OpenAPI规范。它使用标准格式来描述API，这样，人类和计算机就可以在无需访问源代码或其他文档的前提下发现和理解API的功能。

6. 项目由于API安全防护而延误

有好消息？安全团队会在发布前检查所有API。坏消息呢？由于API负责人在开发过程中没有遵循API安全最佳实践，或者没有进行充分的测试，因此未通过检查，代码被送回返工。还有更好的消息？制定一套一致的通用规则和最佳实践来帮助开发人员实现绝大部分的要求，并不是那么难的事情——基本方法包括了实施速率限制、加密外部流量，以及要求对密钥再生进行重新授权等。大多数企业还可以使用高级Web应用防火墙 (WAF) 或其他工具对API网关实施额外的保护，以抵御OWASP 列出的10种最常见API攻击。

更先进的组织机构拥有成熟的SecDevOps能力，可以为每个API进行威胁建模，而且还可能能够根据可以访问的数据或服务类型为不同的API指定不同的安全等级。

结论：避免蔓延是一场永无止境的斗争
以上六个迹象只是API蔓延现象的一部分预警。我们要明确一点——API蔓延是开发人员自主性和微服务DIY思维的自然产物。借助现代开发工具和像GitHub Copilot这样的代码自动化能力，构建新的API正变得越来越轻松可行。

应对API蔓延的工作没有止境。部署API管理解决方案和API网关可以发挥强大的助推作用——如果开发人员不针对API使用APIM（API Management，即API管理）解决方案，网关可能会关闭他们的API——这一要求很苛刻，但对安全防护来说很必要。

幸运的是，应对蔓延所采取的措施大多与常见的API管理方法一致。随着时间的推移，这些措施可以消除技术债务，并避免在开发过程后期或发布后通过补充的安全措施修复API，最终让开发速度得到提高。

如果说API是企业的生命线，则API蔓延是对企业健康状况的最大威胁之一。谨慎且主动的API蔓延控制措施会带来巨大的回报，并且最终会提高开发人员的满意程度。