API攻击盛行，如何基于业务基线进行防护

企业的上云和数字化转型，将越来越多的业务运行于网络之上。为适应敏捷开发等新型应用架构，API 的使用数量更加普遍并持续增长。企业的应用开发越来越依赖 API 之间的相互调用，同时通过 API 传递的数据量也随之迅速增长。

不可避免地，暴露于网络中的企业应用 API 亦成为恶意攻击者的目标。近年来，与 API 攻击相关的数据泄露事件屡见不鲜，其中不乏企业重要业务数据甚至个人身份数据等敏感信息，给企业带来极大的数据安全威胁。

API 安全不容乐观

虽然我们已经发现并且感知到 API 安全风险，但又不得不面对的是，事实已证明传统的安全技术并不能有效地阻止 API 攻击，企业需要在全新的安全防护方法。

据 Gartner 的一份预测报告，2022 年起 API 已成为网络攻击者利用最频繁的媒介载体之一，而通过攻击 API 可以非授权使用企业的各类应用数据，并且由 API 安全问题引起的数据泄露风险在 2024 年将翻倍。

频出的 API 攻击事件不断向我们证明，API 治理不当导致的攻击、欺诈以及数据泄露风险正在对企业的构成新的安全挑战。同时，在 AI 技术的发展，被滥用的 AI 让攻击手段越来越自动化甚至智能化，API 攻击更快、更准确，API 面临的威胁越来越复杂化。

Akamai 最新发布的《潜伏在阴影之中：攻击趋势揭示了 API 威胁》报告证实，API 在 Web 攻击里面所占的比例越来越高，2023 年在所有的 Web 攻击类型里面针对 API 的攻击占了将近 30%。

Akamai 北亚区技术总监 刘烨

Akamai 北亚区技术总监刘烨表示，这个比例可能还会继续增高，因为越来越多的流量也会变成这种 API 的流量，比如很多原生的 手机 应用跟数据中心之间都会通过 API 做数据传输。

针对于 API 的攻击方法和攻击向量非常多样化，这对于企业来说要保护应用 API 的难度大大增加，因为要考虑的方面非常多，刘烨解释道：API 防御可能会面临更大的挑战。企业要找到业务逻辑可能会出现的漏洞，然后去降低风险，降低企业遭受攻击所造成的损失。

基于业务场景攻防

正如刘烨所述，与传统 Web 应用的防护不同，API 的安全防护要求更为广泛，往往是深入到业务逻辑中，并且涉及到多个环节，对任何环节的监测不足都会影响到整体的安全防护效果。

企业如何着手做 API 防护？刘烨特别建议要重点考虑三个方面的问题。

第一，可视性。企业应该给予 API 足够的可视性。比如对于一些 API 接口的开发过程，开发人员通过这个接口在开发、测试、上线的时候会更容易取得某些数据，但是当开发者离开以后，这些接口是不是仍然存在，其实不一定有完整的审计，也不一定有安全开发合规性流程。这种情况下，当这些 API 推到 互联网 以后就可能不具备足够的可视性。

第二，漏洞风险。企业要了解上线的应用里，易遭受攻击的风险点到底有哪些，会不会出现一些已知的漏洞等等。这就要求企业要遵循最佳实践去开发，最大化减少漏洞的出现，从而减少风险点。

第三，业务逻辑。API 攻击的变化多样不是针对于应用本身的，而是针对业务逻辑的。因为这种针对业务逻辑的攻击，可能获取更具价值的东西。所以在业务逻辑方面，企业需要建立在不同业务场景下产生的基线，然后确定哪些是异常情况。

刘烨继续解释道：所有的业务场景可以分为几个部分，首先是 API 的隐患，如果是注入类型的隐患，它与业务场景关系不大，但与 API 的开发技术相关。当使用标准技术或实施方法，遵循软件开发流程时，我们应确保在这个过程中减少漏洞。

跟业务场景相关隐患的是从技术上看是没有问题的、合乎逻辑的，但是从业务上来看就是有问题的，比如过度收集用户数据可能与业务场景相关。

不同业务场景有很多不同防护重点。例如，在 金融 行业，对信用卡使用和交易安全防护的要求可能与 社交 媒体 完全不同。在社交媒体中，用户信息可能是防护重点，而在金融行业中，账户资金安全可能更为重要。因此，在不同业务场景下，按照业务逻辑，实施有效的保护措施非常重要。

对企业更重要的是根据业务场景建立自己的模型和基线，然后判断是否存在针对特定业务场景的攻击。因此，可以分为两部分：首先是针对传统注入类型攻击的防护，这与 API 开发技术密切相关。通过开发最佳实践，安全产品和服务，可以大大帮助用户解决安全隐患。

对于基于漏洞的渗透，刘烨认为可以通过这六步方法，帮助用户提高 API 安全防护水平，减少潜在漏洞对系统的渗透。

首先，记录 API 中的所有相关日志。例如，Akamai API Security 产品利用大量离线分析和基于 API 访问日志的建模来建立基准。

第二，是要了解所有 API 的端点，这被称为「API 发现」，这一点非常重要。许多 API 的问题可能源于在开发过程中留下的接口，这些接口可能仅供内部调用或用于部门间协作。

第三，是进行风险审计，需要确定哪些记录是敏感的，并建立审计方案来审查这些风险并建立基线。

第四，建立基线后进行行为检测，当用户违反了应用逻辑时，应能识别出该用户。

第五，响应，一旦识别出问题，需要给出防护措施的指导，如限制或中断用户访问。

第六，事后分析，需要调整模型以应对可能的风险和恶意攻击，这有助于优化整体策略。

API 的安全防护已成为企业数据安全的重要关注点，如何确保 API 交互过程中保护数据数据的完整性、机密性和可用性，将会是未来一段时间内企业与专业安全提供商要共同面对的问题。