Cloudflare 现在可自动发现所有 API 端点，并针对我们所有的 API Gateway 客户学习 API 模式。客户可以使用这些新功能在他们的 API 端点上实施积极的安全模型，即使他们现在对他们现有的 API 知之甚少，甚至一无所知。
确保 API 安全的第一步是了解 API 主机名和端点。我们经常听到客户被迫开始他们的 API 编目和管理工作，说一些类似于“我们通过电子邮件发送电子表格，并要求开发人员列出他们的所有端点”的话。
您能想象这种方法会有什么问题吗？也许您已经亲眼目睹了问题。“发邮件询问”方法会创建一个时间点清单，而这个清单很可能会随着下一次代码发布而变化。它依赖于团队知识，而这些知识可能会随着人员离开组织而消失。最后但依然很重要的一点是，它很容易出现人为错误。
即使您通过群策群力收集到了准确的 API 清单，但要通过执行 API 模式来验证 API 是否按预期使用，还需要更多的集体知识来构建该模式。现在，API Gateway 的全新 API 发现和模式学习功能结合在一起，可针对 Cloudflare 全球网络中的 API 自动保护 API，无需手动执行 API 发现和模式构建。
API Gateway 发现和保护 API
API Gateway 通过名为 API 发现的功能发现 API。以前，API 发现使用特定于客户的会话标识符（HTTP 标头或 Cookie）来识别 API 端点，并向客户显示其分析结果。
用这种方法进行发现虽然可行，但是有三个缺点：
客户必须知道他们使用的是哪个标头或 Cookie，以便划分会话。虽然会话标识符很寻常，但找到合适的令牌却需要时间。
API 发现需要会话标识符，这使我们无法监控和报告完全未经过身份验证的 API。如今，客户仍然希望了解无会话流量，以确保所有 API 端点都有记录，并将滥用降至最低。
在将会话标识符输入仪表板后，客户需要等待长达 24 小时才能完成发现过程。没有人喜欢等待。
虽然这种方法有缺点，但我们知道，从基于会话的产品开始，我们可以迅速为客户提供价值。随着我们的客户越来越多，通过系统的流量也越来越大，我们知道新的标签数据对进一步开发我们的产品非常有用。如果我们能使用现有的 API 元数据和新的标签数据训练机器学习模型，我们就不再需要会话标识符来确定哪些端点用于 API。因此，我们决定构建这种新方法。
我们利用从基于会话标识符的数据学到的知识，构建了一个机器学习模型，以发现流向某个域的所有 API 流量，无论会话标识符是什么。借助我们全新的基于机器学习的 API 发现，Cloudflare 可持续发现通过我们的网络路由的所有 API 流量，而无需任何先决条件的客户输入。本次发布之后，API Gateway 客户将能够比以往更快地开始使用 API 发现，他们将发现以前发现不了的未经过身份验证的 API。
会话标识符对 API Gateway 而言仍然很重要，因为它们构成了我们的容量耗尽滥用预防速率限制和序列分析的基础。请在下面的“工作原理”部分查看有关新方法性能的更多信息。
API 保护从无到有
既然您已经使用 API 发现找到了新的 API，那么该如何保护它们呢？为了抵御攻击，API 开发人员必须清楚地知道他们希望如何使用自己的 API。幸运的是，开发人员可以通过编程生成 API 模式文件，该文件将可接受的输入编码为 API，并将其上传到 API Gateway 的模式验证中。
不过，我们已经说过，很多客户无法像开发人员一样快速找到他们的 API。当他们找到 API 时，要为数以百计的 API 端点中的每个端点构建一个唯一的 OpenAPI 模式极其困难，因为安全团队很少能在日志中看到 HTTP 请求方法和路径以外的内容。
当我们研究 API Gateway 的使用模式时，我们发现客户会发现 API，但几乎从不执行模式。当我们问他们“为什么不执行”时，答案很简单：“即使我知道 API 存在，也要花费大量时间追踪每个 API 的所有者，以让他们提供模式。与其他必须完成的安全项目相比，我很难将这些任务放在更优先的位置”。缺乏时间和专业知识是我们的客户在启用保护功能方面存在的最大鸿沟。
因此，我们决定填补这个鸿沟。我们发现，我们用于发现 API 端点的学习过程也可以在发现端点后应用于端点，以便自动学习模式。使用这种方法，我们现在可以针对发现的每个端点实时生成 OpenAPI 格式的模式**。**我们称这项新功能为模式学习。然后，客户可以将 Cloudflare 生成的模式上传到模式验证中，以执行积极的安全模型。
工作方式
基于机器学习的 API 发现
对于 RESTful API，请求由不同的 HTTP 方法和路径组成。以 Cloudflare API 为例。您会注意到一个共同的趋势，那就是向该 API 提出的请求可能会在向本博客提出的请求中脱颖而出：API 请求都以 /client/v4 开头，然后是服务名称、唯一标识符，有时还有服务功能名称和更多标识符。
怎样才能轻松识别 API 请求？乍一看，这些请求似乎很容易通过类似于“路径以 /client 开头”这样的启发式方法通过编程进行发现，但我们新的发现的核心包含一个机器学习模型，该模型为分类器提供动力，可对 HTTP 事务进行评分。如果 API 路径都是这样结构化的，为什么还要使用机器学习来完成此操作，难道不能使用一些简单的启发式方法吗？
答案可以归结为一个问题：什么实际上构成了 API 请求，它与非 API 请求有什么不同？让我们来看两个例子。
与 Cloudflare API 一样，我们许多客户的 API 也遵循这样的模式，例如在其 API 请求路径前加上“api”标识符和版本，例如：/api/v2/user/7f577081-7003-451e-9abe-eb2e8a0f103d。
因此，在路径中查找“api”或版本已经是一个很好的启发式方法，可以告诉我们这很可能是 API 的一部分，但遗憾的是，这并不总是那么容易。
让我们再看两个例子：/users/7f577081-7003-451e-9abe-eb2e8a0f103d.jpg 和 /users/7f577081-7003-451e-9abe-eb2e8a0f103d，它们只是扩展名不同而已。第一个路径可能只是一个静态资源，如用户的缩略图。仅从路径来看，单单第二个路径并不能提供很多线索。
手工制作这种启发式方法很快就会变得很困难。虽然人类善于发现模式，但考虑到 Cloudflare 每天所见数据的规模，建立启发式方法极具挑战性。因此，我们使用机器学习来自动推导这些启发式方法，这样我们就知道这些方法是可重复的，并能达到一定的准确性。
训练的输入是 HTTP 请求/响应样本的特征，如内容类型或文件扩展名，这些特征是我们通过前面提到的基于会话标识符的发现收集到的。遗憾的是，在这些数据中，并不是所有的数据都是明确的 API。此外，我们还需要代表非 API 流量的样本。因此，我们从会话标识符发现数据开始，对其进行手动整理，并进一步获得非 API 流量样本。我们非常谨慎，尽量避免模型与数据过度拟合。也就是说，我们希望模型能够超越训练数据。
为了训练模型，我们使用了 CatBoost 库，我们对该库已经有了相当的了解，因为它也为我们的机器人管理 ML 模型提供了支持。简化来说，我们可以将生成的模型视为一个流程图，它告诉我们应该依次检查哪些条件，例如：如果路径中包含“api”，那么还要检查是否没有文件扩展名等等。流程图的最后是一个的分数，它告诉我们 HTTP 事务属于 API 的可能性。
有了经过训练的模型，我们就可以输入通过 Cloudflare 网络运行的 HTTP 请求/响应的特征，并计算该 HTTP 事务是否属于 API 的可能性。特征提取和模型评分在 Rust 中并在我们的全球网络上完成，时间只需要几微秒。由于发现的数据来源于我们强大的数据管道，因此实际上没有必要对_每个_事务进行评分。我们可以只对那些我们知道最终会进入我们数据管道的事务进行评分，从而减少服务器的负担，节省 CPU 时间，使特征具有成本效益。
有了数据管道中的分类结果，我们就可以使用一直用于基于会话标识符的发现的 API 发现机制。这个现有系统运行良好，让我们可以高效地重复使用代码。在将我们的结果与基于会话标识符的发现进行比较时，它也为我们提供了帮助，因为这两个系统具有直接可比性。
为使 API 发现的结果发挥效用，发现的首要任务是将我们看到的唯一路径简化为变量。我们以前讨论过这个问题。要推导出我们在全球网络中看到的各种不同标识符模式并非易事，尤其是当网站使用的自定义标识符超出了简单的 GUID 或整数格式时。API 发现借助几种不同的变量分类器和监督式学习，对包含变量的路径进行了恰当的标准化处理。
只有在对路径进行标准化处理后，发现成果才能供用户直接使用。
结果：针对每个客户发现了数百个端点
那么，与基于会话标识符的发现相比，ML 发现是如何依靠标头或 Cookie 来标记 API 流量的呢？
我们希望它能检测到一组非常相似的端点。然而，在我们的数据中，我们知道会有两个缺口。首先，我们有时会发现客户无法使用会话标识符对仅 API 流量进行清晰的剖析。当出现这种情况时，发现就会揭示非 API 流量。其次，由于我们在第一版 API 发现中要求使用会话标识符，因此不属于会话的端点（例如登录端点或未经过身份验证的端点）在概念上是不可发现的。
下图显示了两种发现变体在客户域上检测到的端点数量直方图。
从鸟瞰的角度来看，结果非常相似，这很好地说明了 ML 发现发挥了应有的作用。在这幅图中已经可以看到一些差异，这也在意料之中，因为我们还将发现一些概念上无法用会话标识符发现的端点。事实上，如果我们仔细观察逐个域的比较，就会发现大约有 46% 的域没有变化。下图比较了基于会话的发现和基于 ML 的发现之间的差异（按端点百分比计算）：
在约 15% 的域中，我们看到端点数在 1 到 50 之间增加，而在约 9% 的域中，我们看到类似的减少。在约 28% 的域中，我们发现了超过 50 个额外端点。
这些结果突出表明，ML 发现能够揭示更多以前不为人知的端点，从而扩展 API Gateway 提供的工具集，帮助让您的 API 环境变得井然有序。
通过 API 模式学习实现即时 API 保护
通过 API 发现解决发现问题后，从业者该如何保护新发现的端点呢？我们已经了解了 API 请求的元数据，现在让我们来看看 API 请求的主体。API 的所有 API 端点的所有预期格式的汇编称为 API 模式。API Gateway 的模式验证是抵御 OWASP Top 10 API 攻击的好方法，它能确保请求的正文、路径和查询字符串以预期格式包含该 API 端点的预期信息。但如果您不知道预期格式怎么办？
即使客户不知道特定 API 的模式，使用该 API 的客户端也会被编程为主要发送符合这种未知模式的请求（否则它们将无法成功查询端点）。模式学习利用了这一事实，并会查看对该 API 的成功请求，自动为客户重建输入模式。例如，API 可能希望请求中的 user-ID 参数具有 id12345-a 形式。即使没有明确说明，希望与 API 成功交互的客户也会发送这种格式的 user-ID。
模式学习首先会识别最近向 API 端点发出的所有成功请求，然后根据每个请求的不同输入参数的位置和类型对其进行解析。对所有请求进行解析后，模式学习会查看每个位置的不同输入值，并找出它们的共同特征。在验证所有观察到的请求都有这些共性后，模式学习会创建一个输入模式，以限制输入符合这些共性，并可直接用于模式验证。
为了让输入模式更加准确，模式学习会识别参数何时可以接收不同类型的输入。假设您想编写一个 OpenAPIv3 模式文件，并在少量请求样本中手动观察到一个查询参数是 unix 时间戳。您编写了一个 API 模式，强制要求查询参数必须是一个大于去年 unix 纪元起点的整数。如果您的 API 同时允许该参数采用 ISO 8601 格式，那么当格式不同（但有效）的参数进入 API 时，您的新规则就会产生误报。模式学习会自动为您完成所有这些繁重的工作，并捕捉到人工检查无法捕捉到的内容。
为防止误报，模式学习会对这些值的分布进行统计学检验，只有当分布的边界可信度较高时，才会写入模式。
那么，它的效果如何呢？下面是我们看到的参数类型和值的一些统计数据：
参数学习将略多于一半的参数归类为字符串，其次是整数，几乎占三分之一。其余 17% 的参数由数组、布尔值和数值（浮点）参数组成，而对象参数在路径和查询中出现的频率较低。
路径中的参数数量通常很少，94% 的端点路径中最多只有一个参数。
在查询方面，我们确实看到了更多的参数，有时一个端点会有 50 个不同的参数！
参数学习能够以 99.9% 的置信度估算出大部分观测参数的数值约束。这些约束可以是参数的值、长度或大小的最大值/最小值，也可以是参数必须取值的一组有限的唯一值。
几分钟内保护您的 API
从今天起，所有 API Gateway 客户现在只需点击几下即可发现和保护 API，即使您之前的信息一无所知也可以。在 Cloudflare 仪表板中，点击进入 API Gateway，然后点击发现选项卡，即可观察到已发现的端点。这些端点将立即可用，无需您进行任何操作。然后，将发现中的相关端点添加到端点管理中。模式学习会自动运行添加到端点管理中的所有端点。24 小时后，导出已学习的模式并上传到模式验证。
尚未购买 API Gateway 的 Enterprise 客户可以通过在 Cloudflare 仪表板中启用 API Gateway 试用，或联系帐户经理。
下一步
我们计划通过支持更多格式的更多已学习参数来增强模式学习功能，例如 JSON 和 URL 编码格式的 POST 正文参数，以及标头和 Cookie 模式。将来，当模式学习检测到已识别的 API 模式发生变化时，它还会通知客户，并提供刷新的模式。
我们希望听到您对这些新功能的反馈意见。请将您的反馈意见转达给您的客户团队，以便我们优先考虑正确的改进方面。我们期待您的来信！