CISO被敦促：在监管出手前主动化解API风险

据Raidiam报告，被敦大多数企业正通过未设置安全控制的促监API暴露敏感数据，而他们甚至可能尚未意识到这一点。管出

该报告基于对68家跨行业企业的手前详细评估，报告故意排除了如英国开放银行等受监管环境 ，主动因为在这些环境中 ，化解高级安全措施是被敦强制要求的，研究目的促监是了解那些没有监管压力的典型企业如何保护其API，结果并不乐观 。管出

超过80%的云计算手前企业落入了报告所称的“急需行动”类别 ，这些公司通过API处理高价值个人或支付数据 ，主动但使用的化解控制措施薄弱 ，如静态API密钥、被敦长期有效的促监承载令牌或基于共享密钥的基本OAuth
，在全部样本中，管出只有一家企业部署了研究人员认为的现代API安全堆栈
，该堆栈依赖于客户端证书认证、发送方约束令牌和双向TLS(mTLS) 。

数据敏感性与安全态势之间的差距是源码下载研究人员想要揭示的核心问题 ，报告警告称：“尽管大多数企业对API的依赖程度日益增加，但它们在API安全加固方面却落后了 。”

API广泛用于支持移动应用 、云服务和合作伙伴集成，这意味着攻击面已经发生了变化 ，但安全实践往往没有跟上 。如今
 ，API处理从身份声明、持卡人数据到健康和账户信息的所有内容，然而 ，在许多企业中，免费模板它们仍然不在标准安全计划的范围内 。

报告指出，只有27%的企业对其API暴露的敏感数据有可见性 ，不到一半的企业进行API特定的安全测试 ，如模糊测试或动态分析，监控也缺乏，意味着攻击者可能数周内探测或滥用API而未被发现 。

Raidiam提出了加强API安全的路径，其中大部分归结为采用已在受监管领域证明有效的实践。服务器租用例如，金融级API依赖双向TLS来认证客户端和服务器 ，使得攻击者更难冒充合法应用 ，它们还使用证书绑定令牌 
，防止令牌被盗成为有效的访问方式。

这些并非理论上的改进，英国 、欧洲和澳大利亚的开放银行制度强制要求此类控制措施，英国的每家银行都已实施 ，但在没有监管压力的行业 ，采用率仍然很低。源码库

这创造了一个两种速度的环境：一组企业将API视为核心业务基础设施，并设有安全治理，而另一组企业则将其视为另一种开发者工具。Raidiam的企业战略负责人David Oppenheim告诉记者：“尽管报告中的大多数企业在API安全方面落后 ，但那些已经前进的企业 ，如因法规要求而行动的银行或自愿行动的全球卡方案，其规模和成熟度远超落后者。”“这造成了风险态势的鲜明对比 。”

Oppenheim补充说 ，香港云服务器董事会层面的有效监督并不需要技术熟练度。“在这样一个技术复杂的领域中，提出有意义的董事会层面指标可能很困难 ，但仍有有效的方法来指导监督和投资，董事应询问已采用或计划采用哪些公认的标准(如FAPI)，以及企业是否应用了成熟度模型或框架来评估其当前态势并跟踪改进情况。”

他还提到了一个简单的起点 ：“一个简单但有力的KPI可能是仍依赖静态密钥或共享密钥的API集成比例，以及转向加密保护的迁移时间表。随时间推移跟踪减少情况，可以为非技术人员提供安全改进的可视性。”

到目前为止，API安全方面的最大改进要么来自直接监管 ，要么来自行业主导的强制要求 ，但其他方面的压力也在增加。

“再次强调
，企业规模起着关键作用，”Oppenheim说，“大型公司和基础设施提供商已经在自愿前进——不仅在银行业
，还在支付和身份平台上——因为他们将强大的API安全视为规模和信任的必要基础
。”

他补充说
，合规的推动力正在显现 ：“TLS基础要求的变化将影响所有有数字足迹的企业，而像DORA这样的法规正在推动对第三方风险的新期望——特别是对于暴露给外部合作伙伴的API而言 。”

Oppenheim还看到更广泛的架构趋势在推动事情向前发展 。“NIST零信任框架正开始成为许多企业寻求减少其数字环境中隐式信任的蓝图 ，在这种背景下 ，通过PKI或双向TLS实现的强客户端身份是向可防御 、可验证架构转变的一部分
。”

最新评论