API发现：如何计算API？

当我们讨论应用程序接口（API）时，往往容易忘记这个话题并不像看上去那样定义明确、理解严格。与任何涉及复杂系统的话题一样，当你提出简单的问题时，问题就会开始出现。忒修斯之船就是一个很好的例子。当一个东西改变了部件，它什么时候会变得明显不同？换了 50%的零件，它还是同一艘船吗？ 75% 呢？

这似乎是一个奇怪的提法，但在 2024 奥斯汀 API 峰会上，Graylog 工程副总裁罗布-迪金森（Rob Dickinson）提出了一个具有重大现实意义的同类哲学问题。 API 究竟是什么，我们如何计算它？答案比你想象的要复杂得多。

下面，我们将从 Dickinson 的回答中了解如何计算 API。我们还将考虑为什么这是一个重要的区别，因为这关系到可发现性，也关系到编制 API 清单，以便大规模管理安全和风险。

为什么 API 发现很重要？

在深入探讨这个话题之前，我们应该问一问为什么它如此重要。 API 发现是对服务中的 API 进行检测和分类的过程。这种发现开始成为我们了解攻击面和在攻击面内所作决策的相对风险的基础。

如果不了解服务由哪些 API 组成，就很难可靠地了解受到威胁的表面区域。这种认识上的差距会进一步导致难以解决可能存在的问题，或在发生重大威胁或攻击成功时难以制定恢复计划。

缺乏对这种类型的了解也意味着我们缺乏量化风险的基本指标，无论是静态威胁还是不断变化的威胁。没有跟踪的指标，就不可能有安全，因为没有 “目标 “来表明成功的安全态势。

在这次演讲中，迪金森表示目标很简单：能够说 “我们目前有 X个API，其中Y个是新的，Z个需要立即关注”。但主要的哲学问题就在这里–API 到底是什么？

什么是应用程序接口？

在应用程序接口领域，能够定义什么是应用程序接口绝对是至关重要的。只是有一个问题–这个定义可能因人而异，更不用说组织与组织之间了。

迪金森指出，这个问题之所以不像初看起来那么简单，是有一些原因的。首先，API 的最佳实践并没有得到很好的理解，对许多人来说，端点数量、服务性质、甚至每个服务的内部或外部性质的变化都可能会改变手头 API 的基本数量。理想情况下，我们正在寻找的指标应该是普遍适用的，因此我们的计算方式也应该是相对通用和可移植的。

与网站或电子邮件相比，应用程序接口也很 “黑暗”。对于大多数人来说，网站是什么一目了然，而应用程序接口则更难连接和使用，甚至开始使用一个简单的应用程序接口都需要大量的知识。再加上应用程序接口固有的快速变化和支撑其技术的不同文化，导致应用程序接口的定义有些松散，即使对专家来说也是如此，而对普通人来说几乎完全不透明。

应用程序接口发现示例

让我们以实际代码为例看看这个问题。下面是在一个系统中提出的三个假设请求。

REQUEST A



POST coinbroker.io/user



{

"first_name":" Rob",

"last_name":" Dickinson",

"email":" rob@resurface.io"

}

REQUEST B



GET coinbroker.io/quote



{

“Account_token”:”4b86cd3f-ccaf-445b-b099”,

"Amount_usd":" 6",

"coin_type":" BTC"

}

REQUEST C



POST coinbroker.io/order



{

“Account_token”:”4b86cd3f-ccaf-445b-b099”,

“Quote_token”:”552cd9da-2ff4-4dfe-b2eb”,

这里显示了多少个应用程序接口？很多人会回答 “三个”，这些人可能是对的。但是，答案 “1 “和 “2 “也可能是正确的。每个请求都是自己的 API 吗？每个请求都有自己的端点，但它们共享类似的数据，那么是否由路径决定？

服务的其他部分呢？这是一个微服务集合吗？在这种情况下，是每个微服务都有自己的应用程序接口，还是整个服务构成一个单一的应用程序接口？

这就是迪金森试图展示的根本问题。这些逻辑都没有明确、完美的答案，但它们从根本上都是正确的–那么，我们究竟该如何计算 API 呢？

计算应用程序接口的合理方法

解决这个问题的方法有很多，其中很多都很合理。我们可以计算完全合格的域名（FQDN），这样就能知道特定应用程序接口的数量。但路由呢？好吧，也许我们可以把 FQDN 和路由结合起来，得到别的东西。

但内部 API 和外部 API 之间的区别又是什么呢？已废弃的 API 仍可作为选项使用，但其功能存在于不同的核心 API 中，又该如何处理？这些问题带来的问题比解决方案更多。答案可能很简单：通过规范来计算。在这种方法中，规范决定了应用程序接口的数量，而定义则不那么重要。

新问题：变化的状态

这种方法虽然有效，但也带来了一个新问题。我们如何按生命周期状态计算 API？流氓或未托管的应用程序接口仍然是应用程序接口，即使它们未在规范中指定，也应该计算在内。 Dickinson 的解决方案是从类别的角度来考虑这些问题：

盗贼或不受管理的应用程序接口是新事物，需要审查；
积极维护受监测和支持的应用程序接口
已废弃的 API 或僵尸 API 已死亡，但仍与整体计数相关。

这就引入了一个更符合实际情况的计数。现在，我们有了一个与其生命周期中的状态相关的数字，而不仅仅是一个纯粹的数字，这样我们就可以逐步建立一个可以长期跟踪的 API 清单。这样，再加上通过自省进行的自我描述，就能让应用程序接口规范确定其定义并浮现出可用数据。

风险如何？

为了提高数据的可用性，我们还应该分配风险。了解这些现有的应用程序接口类别很有帮助，但了解具体的风险度量标准则是我们首次讨论的这一流程的巨大优势。

有了规范，我们就需要开始研究哪些指标可能有用。用户活动、特定上下文、网络流量，甚至 API 最近的更改都应被跟踪，这样我们就能根据上下文确定 API 最近的更改，从而确定 API 的攻击面。

现在，我们谈论的不仅仅是规范，还包括开发人员的意图和实际使用。威胁既有内部的也有外部的，意图与实际使用同样重要，因此运行时监控和日志记录对这一过程至关重要。

虽然目前还没有标准的风险度量，但跟踪这些数据可以开始描绘出一幅图画，用于在内部分配这些分数，并具有一定的有效性。 Rob 特别指出，Graylog 将这一过程视为基于请求和响应数据的计算，并指出响应往往是数据泄漏和不希望发生的行为发生的地方。

发现应用程序接口的阶段

由此，我们最终可以建立一个 API 发现模型，满足我们的所有需求：

步行：创建 API 清单。使用 API 规范来定义 API 集合，并确定哪些在内部被视为 API。记录和跟踪这些 API，并指定运行时跟踪，以便在内部生成数据，用于安全态势评估。

运行：跟踪 API 清单的变化。通过对这些 API 进行分类，添加更多的上下文。通过对生命周期和最终用户目的的考虑，跟踪它们随着时间的推移而发生的变化，从而丰富数据并为 API 收集提供实质性的背景信息。

火箭飞船：跟踪 API 库存风险指标的变化。最后，随着 API 的发展和在现实世界中的使用，跟踪风险指标的变化。这样就可以计算相对风险，并采用基于度量的安全态势方法，这种方法是以现实为依据的，而不是凭空想象的。

结论：

对许多人来说，这似乎是显而易见的–尤其是对于 API 规范的倡导者来说–但对其他人来说，这却是一个启示。明确定义并不重要，重要的是共享定义的模式，这对了解您的安全态势至关重要。安全是基于度量的：您需要对您的安全态势的成功和安全程度进行一定的度量，而这种方法能够为最广泛的业务、应用程序接口设计和范例提供度量。

本文翻译源自：https://nordicapis.com/api-discovery-how-do-you-count-apis/