利用NIST SP 800-228应对API安全挑战

根据Wallarm 2025年第一季度威胁统计报告，70%的应用攻击针对API。行业不能再将API安全视为次要问题，而应将其作为主要关注点。NIST似乎认同这一观点，发布了NIST SP 800-228的初始公开草案，这是一套保护API的建议。

背景：API、自动化和攻击速度

API不仅仅是应用架构的演进，更是服务构建、消费和保护方式的根本转变。与Web应用不同，API专为编程访问设计。这意味着使它们对自动化至关重要的特性——状态性、结构、机器可读性——也使它们对攻击者具有吸引力。

AJ在我们的讨论中提出了一个重要观点：API降低了进攻性安全工作的技术门槛。你不需要操纵浏览器流量或掌握代理工具来模糊测试API；一个简单的curl命令或Python脚本就足够了。这种易用性使API成为自动化扫描器和更复杂攻击者的高价值目标。

API与AI系统（尤其是GenAI代理）的日益集成只会放大这种风险。这些代理自主与API交互，做出决策并触发工作流。因此，API流量、复杂性和暴露风险呈指数级增长。

NIST SP 800-228带来的价值

NIST并未提供一个整洁的分组最佳实践列表，而是发布了22项推荐控制措施。虽然我们建议您自行查阅，但整体消化可能有些 overwhelming。因此，在网络研讨会期间，AJ和我决定帮大家一个忙：我们将它们分为七个主题组。这些不是官方类别，而是一个有助于理解内容和应用方式的有用视角。

API规范和库存管理

我们从基础开始：你无法保护你不知道存在的东西。我指出，最新的API库存和明确定义的规范是基础。AJ同意，将这种情况比作传统的NAC。她说，如果我们难以跟踪物理设备，那么跟踪快速移动、短暂的API将更加困难。尽管如此，防止影子API成为低 hanging fruit 至关重要。

模式验证和输入处理

一旦你知道存在什么，就需要验证通过它的内容。我谈到了在运行时强制执行请求/响应模式的重要性，AJ分享了一个研究人员利用加密货币交易所的例子——不是通过改变价格，而是通过替换API未正确验证的令牌类型。这完美说明了为什么模式执行在明显输入之外也很重要。

身份验证和授权

我们都同意：虽然身份验证（authN）得益于SSO和OAuth有所改进，但授权（authZ）仍然一团糟。AJ直言不讳：许多API仍然让用户“自称是管理员”，没有真正的检查。我补充说，这类失败往往未被发现；它们不会使系统崩溃或加密文件，而是悄悄泄露数据。这正是NIST呼吁字段和方法级访问控制，而不仅仅是基本端点限制的原因。

敏感数据识别和保护

敏感数据不仅仅是PII。AJ讲述了一个公司意外在线暴露其网络保险单的故事——其中包括勒索软件支付限额。这正是攻击者要求恰好金额赎金所需的所有信息。我强调，检测和分类通过API流动的数据，然后围绕其执行策略，需要超越简单模式或关键词。

访问控制卫生和请求流

在这里，我们专注于强化API行为，特别是在令牌受损或异常使用的情况下。我强调了按需阻止特定密钥或用户的建议，AJ指出，虽然这听起来很简单，但许多组织尚未具备足够快的工具或流程。NIST显然在推动行业走向更成熟、实时的响应能力。

速率限制和滥用预防

API不仅带来可用性风险，还可能影响你的钱包。AJ提到攻击者如何在云环境中通过启动计算资源累积巨额账单，我指出LLM或其他计量API也是如此。NIST建议细粒度速率限制，不仅按端点，还按方法、用户或字段—— wherever滥用可能发生。

日志记录和可观察性

最后，我们讨论了可观察性。AJ提出了一个强有力的观点：拥有日志是一回事，但能够响应才是关键。“你知道哪个令牌被滥用了吗？你能真正关闭它吗？”她问道。我同意——没有操作能力和跨团队协调，日志只是噪音。NIST正确地包括了可见性，但真正的力量在于将可见性与行动联系起来。

Wallarm的定位

Wallarm与NIST SP 800-228保持一致，但提供直接的API安全控制（发现、模式执行），验证API符合性（检测不合规请求），并支持其他安全控制（识别损坏的身份验证、分类敏感数据）。

我们的平台自动发现和清点API，从实时流量生成OpenAPI规范以识别漂移和影子端点，并强制执行模式验证。我们还检测关键风险，如损坏的身份验证、暴露的密钥和BOLA，同时呈现敏感数据以进行策略执行和编辑。此外，Wallarm提供细粒度速率限制，并提供完整的流量上下文以构建完整的攻击叙事。

想了解更多关于NIST SP 800-228以及Wallarm如何帮助您合规的信息？请查看我和AJ的完整网络研讨会。