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交互过程中保护数据数据的完整性、机密性和可用性，将会是未来一段时间内企业与专业安全提供商要共同面对的问题。