保护 API 端点使 API 难以保障安全
关于API 安全性（不安全性）的统计数据并不缺乏。 在互联网上进行粗略搜索，你就能找到关于你喜欢的话题的任何观点。 可以说：(a) API 攻击正在增加，并且 (b) 其中一些攻击已经成功。
还普遍注意到，组织很难找到隐藏在其组织中的所有 API。 这不仅仅是因为这些 API 遍布核心、云和边缘。 这是因为除了众所周知的开放 API 规范（OAS）之外，没有真正的“标准”可以依赖来定义 API，更不用说查找 API。
但这并不意味着我们需要它们。 毕竟，我们有 SOAP、WSDL 和 UDDI，虽然人们仍在使用它们并依赖 XML 作为数据格式，但世界上大多数人已经转向 REST、JSON、GraphQL 和 gRPC。
即使我们有标准，也无法改变 API 难以保护的事实。
这是因为 API 这个术语是一个总称。 例如，OpenTelemetry API 只是一种说法，“我们正在向开发人员提供 OpenTelemetry 的功能。” 这并不意味着您有一个可以覆盖“Open Telemetry API”的安全策略。那将是理想的，并且会让事情变得简单得多。 但事实并非如此。 我们拥有涵盖 OpenTelemetry API端点的安全策略。
让我们深入研究一下，好吗？
API 和端点
让我们以 Open AI API 为例，因为现在每个人都对生成式人工智能感到兴奋。
您首先会意识到的是，尽管只有“一个” API，但也有很多端点。 多少？ 每次引入新功能时，该数字都会发生变化。
以下是（非完整列表）：
- https://api.openai.com/v1/chat/completions
- https://api.openai.com/v1/audio/speech
- https://api.openai.com/v1/audio/transcriptions
- https://api.openai.com/v1/audio/translations
- https://api.openai.com/v1/embeddings
- https://api.openai.com/v1/fine_tuning/jobs
- https://api.openai.com/v1/files
多模式生成 AI 将媒体（音频和视频）添加到内容类型列表中，但添加了新的端点来处理处理请求。 附加功能（例如使用工具）也可能扩大端点的数量。 每项进步——每项令我们兴奋的新功能——通常都会为 API 添加另一个端点。
您还会注意到这些端点中的“v1”。 这意味着当 v2 发布时，将需要另一套安全策略来覆盖这些端点，并且其中一些策略将需要根据实际端点的变化而改变。
这也存在于 IT 堆栈中，其中自动化是通过设备 API 实现的。 端点的数量很大程度上取决于您的环境。 您管理的设备越多，需要管理和保护的端点就越多。 哦，别忘了，没有两台设备使用相同的 API。我的意思是，那太疯狂了，不是吗？ 几乎就像两个云提供商同意使用相同的 API。这可能就是为什么“复杂性”仍然是无法实现各种操作任务自动化的最常见原因。 太多的工具和 API 使得自动化变得困难，甚至更加难以确保安全。
但是API 安全必须解决所有这些端点，因为它们是攻击者进入的途径。 每个端点都需要一组不同的参数，这些参数最终以 JSON（或 XML 或 GraphQL 或 <在此处插入格式> 对象）的形式出现在有效负载中。 每个参数可以包含的内容需要有所限制： 它是字母数字吗？ 人物？ 值的范围？ 可以多久？ 哪些字符是不允许的？ 所有这些信息都被转化为一种策略，强制执行内容的样子，从而防止攻击潜行。
仅为 Open AI API 制定策略就需要一些时间。 而且这还只是一个 API。根据我们即将进行的 2024 年研究，大多数组织平均拥有 442.8 个 API，而对于非常大的组织来说，这个数字会急剧上升。 考虑一下这可能意味着多少个端点和端点的版本，你很快就会明白为什么 API 安全如此困难。
以及为什么攻击者能够成功并继续攻击他们。