T-Mobile 泄密事件迄今吸取的教训

T-Mobile 最近披露的数据泄露事件凸显了应用安全领域蓬勃发展的“狂野西部”——API 所面临的挑战。 某个个人（或团体）通过使用（或滥用）API 收集了超过 3000 万客户的个人数据，在被发现之前，每天窃取信息长达一个多月。

在撰写本文时，对于此案中 API 被滥用的原因和方式（例如，功能滥用、对象级授权破坏、过度数据暴露）以及最终如何实现泄露的具体细节还知之甚少。 仅检查数字，平均每天通过此 API 删除 902,000 名客户的数据，而不会触发任何速率限制阈值、时间序列行为异常等。 或者可能确实存在此类攻击，但威胁级别尚未达到适当的程度，无法由运营团队快速识别并采取缓解措施——它具有低速和缓慢攻击的特点。

此类违规行为让我们有机会思考 API 有多么普遍、它们对于当今的组织有多么重要，以及它们在任何应用乃至整个组织的安全性（或不安全性）中所能发挥的独特作用。 F5 实验室在对近年来的违规行为进行分析时注意到，在大多数与 API 相关的事件场景中，违规方法在技术上非常简单，并且影响面向公众的、安全性较差的 API 端点。

当谈到 API 时，安全性说起来容易做起来难（至少做不好）。 如今，大多数组织正在监控越来越多的应用和端点，并由此生成大量应用安全事件数据，因此，掌握一切似乎是一项不可能完成的任务。

然而，这次攻击凸显了 API 安全性的三个核心要素，组织都可以从中吸取教训，优先考虑提供以下技术和服务：

API 可见性和发现。 在这种情况下，尚不清楚这个特定的 API 是否已知或正在被积极监控。 积极的安全性，依赖于具有模式执行功能的安全开发和完善的 API，是至关重要的，但只是等式的一半。 大多数组织可能无法掌握其环境中运行的每个 API，因此能够不断学习和映射应用所有通信路径中尚未记录的 API 至关重要。 发现技术允许组织映射其整个 API 环境，暴露未知/影子 API、要阻止/删除的废弃或僵尸 API，以及任何应考虑进行治理的未知“好”API，提供更全面的监督。

了解 API 的存在并具有访问控制功能是 API 安全难题的两个关键部分。 在我们的2022 年application战略状况报告中，68% 的受访者将身份验证和授权列为 API 安全中最有价值的组成部分，其次是行为分析和异常检测，用于监控 API、识别和警告异常行为和潜在滥用，因为不良行为者可以通过多种方式轻松绕过身份验证和授权。 在这种情况下，API 和客户端之间传递的数据一定存在异常。 在生产过程中，能够跟踪 API 行为随时间的变化通常包括 API 请求分析和时间序列异常检测，以构建基线行为属性，用于识别请求率、错误、延迟、吞吐量等方面的异常。 有了此功能，当出现意外峰值或下降、存在独特的流量模式或检测到异常 API 请求时，警报元素对于提出问题至关重要。

完善现代 API 安全堆栈需要内联应用和 API 安全实施引擎，很可能包括具有多层应用安全功能的 WAF，例如具有速率限制、IP 信誉、允许/拒绝列表功能的细粒度 L7 策略实施，以及具有进一步调查和处理恶意端点、用户和其他活动的能力的 L7 DoS。 这使得运营团队能够在检测到异常时快速轻松地识别可疑的 API 滥用，并制定策略来阻止这种滥用，从而随着 API 和应用程序端点的发展和行为变化更好地保护它们。

随着时间的推移，我们了解到这次特定违规行为期间究竟发生了什么，肯定会有更多信息被披露，但至关重要的是，组织要利用这三个要素来评估和更好地制定计划，以保护他们的应用程序和 API 端点免受此类滥用。