破除API安全迷思

我最近与应用安全和DevSecOps领导者Tejpal Garwhal进行了一次对话，旨在破除一些最常见的API安全迷思。从僵尸端点到WAF和网关的局限性，我们探讨了实际情况以及安全团队需要采取的不同做法。以下是关键要点的快速概述，但要了解完整内容，请观看完整的网络研讨会。

迷思1：“我们知道拥有哪些API”

这是我们解决的第一个也是最持久的迷思。大多数团队认为，如果他们部署了API，就必须知道环境中存在什么。但现实却截然不同。

Tejpal指出，API蔓延经常在无人察觉的情况下发生。开发人员在短时间内构建和部署端点，文档滞后，不同团队可能假设其他人在跟踪记录。实际上，没有一个团队能完全掌握API清单。

更糟糕的是，许多人依赖API网关或管理平台作为真相来源，但这些工具只跟踪通过它们路由的内容。它们无法捕获临时部署的端点或遗留代码库中遗忘的旧API。

我们一致认为：没有完整的可见性，保护API就是猜测工作。

Tejpal和我经常听到加密解决了数据暴露问题的说法。只要使用HTTPS，假设就是安全的。然而，正如我们讨论的，传输或静态加密并不能解决谁可以访问数据或如何通过业务逻辑暴露数据的问题。

Tejpal强调开发人员通常默认过度共享。没有严格的设计边界，API倾向于返回完整数据对象而不是最小字段。再加上糟糕的访问控制或包含敏感细节的日志记录，就形成了隐性责任。

在我们讨论的一个例子中，一个组织认为自己是安全的，因为其Web UI有强大的控制。然而，在幕后，底层API仍然允许未经身份验证的访问。这是一个常见的脱节。API不需要可见就能存在漏洞。

我们都看到这个迷思导致问题。它基于对传统工具实际功能的误解。

例如，WAF可以检测基本注入攻击，但通常难以处理GraphQL和gRPC等API协议，或者当请求深度嵌套或批处理时。同样，API网关可以管理身份验证和路由，但它们并非设计用于解析和检查请求逻辑或标记业务滥用。

简而言之，这些工具具有重要功能，但并非为检测我们现在在API流量中常规看到的威胁而构建，如破碎对象级别授权（BOLA）、僵尸端点或代理触发的抓取。最终，仅依赖WAF和网关会产生危险的虚假安全感。

这是我们对话转向运营的地方。检测是必要的，但还不够。仅仅知道攻击并不能降低风险；阻止它才能。没有行动的警报只是噪音。

Tejpal强调许多组织拥有生成令人印象深刻的报告的工具，但缺乏在攻击时刻干预的工作流程或覆盖范围。等到检测被分类时，损害可能已经造成。

我们讨论了实时阻断的必要性，而不仅仅是警报。特别是考虑到自动化机器人和AI代理正在大规模探测API，现代防御者不能只做出反应；他们必须预防。

虽然测试起着重要作用，但它只是更广泛生命周期的一部分。你不能通过扫描来实现安全部署。

我们都同意安全需要左移。组织需要在设计中纳入威胁建模，并在API上线前验证安全合同。但我们也强调了一个经常被忽视的概念：右屏蔽。即使你构建了安全的API，攻击者也不会停止尝试。你需要适应现在情况的运行时保护。

那么，问题来了：API安全实际需要什么？我们已经破除了迷思，现在是揭示真相的时候了。以下是Tejpal和我认为每个组织应该基于的六个基本原则：

让我们印象深刻的一点是，许多API安全策略仍然作为技术练习运作，与业务隔离。但如果API支持支付、库存或客户数据，它就是业务。安全决策必须反映这一事实。

然而，这篇博客只是我们对话的表面。如果任何内容引起共鸣，我鼓励你观看完整对话。我们涵盖了真实世界的违规行为、被忽视风险的演示示例，并逐步介绍了使开发、安全和运营围绕共享威胁模型对齐的现代策略。在此观看网络研讨会。