保护API端点让API难以保障安全

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

关于API安全性（或不安全性）的统计数据并不少见。只需在互联网上简单搜索，就能找到关于这一话题的各种观点。简而言之：（a）API攻击日益增多；（b）其中一些攻击确实得逞了。

另一个常见问题是，组织甚至难以找出内部隐藏的所有API。这不仅是因为这些API分散在核心、云和边缘环境中，还因为除了广为人知的开放API规范（OAS）之外，并没有真正可依赖的“标准”来定义API，更不用说发现API了。

但这并不意味着我们需要这些标准。毕竟，我们曾经有SOAP、WSDL和UDDI。虽然现在仍有人使用它们，并依赖XML作为数据格式，但大多数人已经转向REST、JSON、GraphQL和gRPC。

即使有了标准，也改变不了API难以保护这一事实。

这是因为API是一个宽泛的概念。例如，OpenTelemetry API只是表示“我们正在向开发者开放OpenTelemetry的功能”。并不存在一项可以涵盖整个OpenTelemetry API的安全策略。如果有，当然很理想，也会让事情简单得多。但现实并非如此。现有的安全策略涵盖的是OpenTelemetry API的端点。

下面我们来深入探讨一下。

API和端点

我们以Open AI API为例，因为生成式AI目前备受关注。

首先会发现，虽然只有“一个”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将音频和视频等媒体纳入内容类型，同时也会增加用于处理请求的新端点。使用Tools等附加功能也可能进一步增加端点数量。每一次进步，也就是每一项令人期待的新功能，通常都会为API增加一个端点。

您还会注意到这些端点中的“v1”。这意味着，当v2发布时，需要另一套安全策略来覆盖这些端点，其中一些策略还需要根据实际端点的具体变化进行调整。

这种情况在IT技术栈中同样存在，其中的自动化通过设备API实现。端点数量主要取决于具体环境。纳管的设备越多，需要管理和保护的端点就越多。别忘了，没有两种设备会使用相同的API。要是真能这样，那可太不可思议了，不是吗？这就像两家云提供商同意使用相同的API一样。因此，在各种运营任务中，“复杂性”可能仍是人们最常提及的不进行自动化的原因。工具和API过多，不仅让自动化难以实现，也让安全防护更加困难。

但是，API安全，必须覆盖所有这些端点，因为攻击者正是通过这些端点入侵。每个端点需要的参数集各不相同，这些参数最终会以JSON（或XML、GraphQL或<insert format here>对象）的形式进入有效负载。必须限制每个参数可包含的内容：是否可以包含字母和数字？是否可以包含字符？是否只能取某个值范围？长度上限是多少？哪些字符不允许使用？所有这些信息都会转化为策略，用于强制规定内容的格式，从而防止攻击乘虚而入。

仅为Open AI API构建策略就需要一些时间，而这还只是一个API。根据我们即将发布的2024年研究，大多数组织平均拥有442.8个API，而超大型组织的这一数字会大幅增加。想想这可能意味着多少个端点以及多少个端点版本，就不难理解为什么API安全如此棘手。

这也解释了为什么攻击者屡屡得手，并持续将其作为攻击目标。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章