跳转到主要内容

API 安全已纳入联邦审查范围:CIO 们的警钟已然敲响

Stas Neyman

寫於

Stas Neyman

June 13, 2025

Stas Neyman

寫於

Stas Neyman

Stas Neyman is a senior marketing leader specializing in cybersecurity. As Director of Product Marketing at Akamai, he oversees the $1.5B Application and API Security portfolio, shaping positioning, messaging, and growth strategy across App & API Protector (WAAP), API Security, Firewall for AI, and bot management solutions. Before Akamai, Stas built the Product Marketing function at Noname Security (acquired by Akamai) and led Product Marketing for CyberArk’s Workforce Identity portfolio. Earlier in his career, Stas drove product marketing and go-to-market initiatives at Amazon Web Services (AWS) and HP, helping launch and grow multiple high-impact security and enterprise mobility offerings.

API 相关事件已不再被当作孤立的技术问题来看待。它们会被当作不合规事件,同时引发监管层面的后果。
API 相关事件已不再被当作孤立的技术问题来看待。它们会被当作不合规事件,同时引发监管层面的后果。

联邦政府近期对一系列 API 数据泄露事件的调查,无疑是对众多科技和电信企业敲响了警钟。多起案例显示,攻击者正是利用防御薄弱的 API 端点,堂而皇之地窃取敏感客户数据,这不仅暴露出企业安全防护的致命弱点,更直接触发了监管部门的严厉审查。

鉴于 API 在数字基础架构中呈爆炸式增长,联邦监管机构正不断加码,要求企业务必加大对经由这些接口传输数据的保护力度。

对于技术领域的 CIO 和 CISO 而言,这些安全事件敦促他们必须迅速评估当前 API 安全防护实践,他们不仅要评估有没有足够的风险抵御能力,还要评估合规性能否符合逐渐发展的监管框架,例如支付卡行业数据安全标准(PCI DSS 4.0 版)、通用数据保护条例 (GDPR)、健康保险流通与责任法案》(HIPAA) 和数字运营弹性法案》(DORA)。

企业主动将 API 风险纳入监管合规范畴来考量,有助于减轻联邦审查力度加大带来的影响。

API 安全故障实际案例

在某次事件中,一家全球域名和主机提供商遭受了攻击。攻击者利用该提供商 API 架构中的漏洞,提取了客户的帐户信息。后续调查表明,该提供商的身份验证控制机制存在过失,对 API 也缺乏针对性的监控手段。

类似的,某大型电信公司也因为未做好 API 端点防护,导致敏感用户数据遭到泄露。事故原因包括:输入验证不充分、访问权限限制不恰当,而这次疏忽引发了联邦监管机构的关注。

在上述两个案例中,两家公司都投资搭建了传统的防御体系,却没有同等重视 API,而 API 正是现代数字化服务的核心。

监管机构为什么越来越关注 API

美国联邦通信委员会 (FCC)、美国联邦贸易委员会 (FTC) 等联邦监管机构和欧洲监管机构越来越重视 API 安全防护,将其视作客户数据保护的关键因素。

监管机构越来越重视,反映出许多公司都面临着相同的风险暴露问题,包括:

  • API 清单不完善
  • 监测能力不足
  • 运行阶段的控制措施不足
  • 测试实践不足

API 清单不完善

几乎所有的合规框架都有一个基本要求:要对已有的资产及其处理的数据类型有清晰认识。由于 API 的开发与更新不断,且往往由不同团队或第三方负责,因此大多数企业都缺少一份完整、实时的 API 清单。

企业必须要知道部署在环境中的 API 和每个 API 的用途,更重要的是,要识别出完全在其监测范围或流程之外运行的 API。

监测能力不足

即使识别出 API,也往往无法明确哪些数据会经过 API 传输,或是这些 API 是否有正确的安全防护机制。许多企业既无法决定 API 的归属权,也无法确定流量是否通过 Web 应用程序防火墙 (WAF) 或 API 网关等经过批准的管控渠道进行传输。

我们的 2024 年 API 安全影响研究表明,在拥有完整 API 清单的 IT 安全专业人员中,只有 27% 的人真正知道哪些 API 会返回敏感数据,这一比例明显低于 2023 年的 40%。

此外,企业不同人员之间也经常存在信息不一致的问题:尽管 43% 的受访 CIO 认为他们知道哪些 API 会返回敏感数据,但只有 17% 的 CISO 同意这一观点。这些监测不足可能引发严重的不合规问题,比如信用卡信息、个人身份信息或医疗相关记录等敏感数据发生泄露。

运行阶段的控制措施不足

合规并不仅仅要求知道资产情况。合规还要求确保实时检测并解决滥用问题。安全团队需要有能力判断,是否有人恶意利用 API 提取客户数据,或者想要获取更高权限。

例如,企业通常无法检测隐蔽的业务逻辑滥用,或防范类似 OWASP 十大 API 安全风险中的失效的对象级授权威胁。这些攻击模式出现得越来越频繁,往往还能规避传统的边界防护工具。

测试实践不足

许多企业仅仅依赖功能测试,而忽视了安全测试的重要性。合规框架越来越强调要从源头开始重视安全,因此,要在部署 API 之前测试漏洞,这一点至关重要。

由于存在这些潜在的安全漏洞,监管机构开始将 API 安全失效事件视为直接违反数据保护法规,还往往会因此发起进一步的执法行动、处罚或强制性整改措施。在我们的调研中,一些受访的美国 IT 和安全团队领导者(CIO、CISO 和 CTO)表示,从过去 12 个月经历的 API 安全事件来计算,他们在安全方面投入的平均预估成本达到了 943,162 美元。

将 API 安全纳入合规框架

如今,企业需向外界证明:不仅具有扎实的安全防护能力,还能覆盖整个 API 生态系统做好合规准备。下面介绍如何让 API 安全防护满足几项常见重要法规的要求。

  • PCI DSS v4.0:该标准规定,需识别和记录所有与支付相关的 API,采用强身份验证机制保障这些 API 的安全,持续监控,并且限制对持卡人数据的访问权限

  • GDPR:该条例强制规定,需要做到数据最小化、访问控制与数据泄露通知,而这些工作,都与保障处理个人数据的 API 安全息息相关

  • HIPAA:该法案强制规定,对于通过 API 访问的受保护健康信息,必须采用加密、基于角色的访问控制和审计记录等方式来保障安全

  • DORA:该法案规定,要覆盖所有数字渠道(包括 API)开展运营弹性测试与事件检测,且必须监控异常情况与故障场景

不受保护或未记录的 API 可能会引发不合规后果:无论是持卡人数据、健康记录泄露,还是在受监管渠道中未能检测到异常。

面向 CIO 的要点:行动项目

负责数字基础架构和风险计划的 CIO 必须采取审慎的结构化方法来保护 API 安全。首要事项:必须建立全面的 API 环境监测机制。若无法在云、本地和混合环境中建立实时资产清单,有效保障 API 使用安全或对 API 使用进行审计则几乎无从谈起。

其次,必须“从设计上考量安全”。包括实施强身份验证措施、验证所有输入数据,以及在企业内的每一个 API 中应用最小访问权限原则。监测能力同等重要。实时监测 API 流量,能让团队在早期检测到异常情况,赶在风险升级之前及时应对,这也是许多监管框架的一项重要要求。

安全措施还应直接对应合规要求。保持 API 控制措施与 PCI DSS、GDPR、HIPAA 和 DORA 等监管框架要求的清晰对应,能让企业展示合规进展与合规文档证据,从容应对审计。

最后,必须持续开展恢复能力测试。应将 API 纳入企业的安全测试策略与运营弹性规划中,而不是出现安全事件后才考虑。尤其是对于欧盟境内受 DORA 约束的企业而言,具备模拟攻击、评估故障场景和保障业务连续性的能力,正逐渐成为一项基本要求。

Akamai API Security 如何帮您保持合规

Akamai API Security 为企业提供全生命周期的 API 安全防护方法,帮助企业轻松满足合规要求并降低风险。多方面支持企业满足关键合规要求:

  • 全面的 API 发现与清单制定:持续发现并分类所有 API(包括影子 API 和僵尸 API),保持对 API 环境的监测能力,并满足 PCI DSS、GDPR 等合规框架的文档记录要求

  • 风险与安全态势评估:将评估发现与主流合规框架(如 PCI DSS、ISO 27001、GDPR、HIPAA)的要求相比较,识别出可能导致不合规的配置错误或漏洞

  • 行为威胁检测:检测出传统工具经常遗漏的行为异常、业务逻辑滥用和不当数据泄露问题,支持企业满足 DORA 规定的运营弹性目标

  • 借助合规仪表板集中展示合规性:提供合规 API 与不合规 API 的集中化视图,追踪安全态势随时间的变化趋势,并简化审计准备工作

  • 与安全生态系统无缝集成:集成了安全信息与事件管理 (SIEM) 系统、工单系统和工作流程工具,助力生成合规证据,简化事件响应流程

结论

API 相关事件已不再被当作孤立的技术问题来看待。它们会被当作不合规事件,同时引发监管层面的后果。随着联邦政府审查力度的加大,技术领域的首席信息官 (CIO) 不仅必须确保实施 API 安全保护措施,还要确保落实到位且具备可审计性。在企业的安全与合规体系中,若将 API 视为安全计划中不可或缺的一部分,不仅能降低风险,更能使企业具备前瞻性抗风险能力,从容应对未来新兴法规的要求并抵御不断涌现的威胁。

了解更多

请访问网络安全合规性页面,了解四个关键的安全领域,这些领域可以显著提升您满足监管机构要求的能力。您还可以了解到 Akamai 如何帮助企业遵守相关规定,以及我们的客户如何增强其合规方法与事件响应策略的案例。



Stas Neyman

寫於

Stas Neyman

June 13, 2025

Stas Neyman

寫於

Stas Neyman

Stas Neyman is a senior marketing leader specializing in cybersecurity. As Director of Product Marketing at Akamai, he oversees the $1.5B Application and API Security portfolio, shaping positioning, messaging, and growth strategy across App & API Protector (WAAP), API Security, Firewall for AI, and bot management solutions. Before Akamai, Stas built the Product Marketing function at Noname Security (acquired by Akamai) and led Product Marketing for CyberArk’s Workforce Identity portfolio. Earlier in his career, Stas drove product marketing and go-to-market initiatives at Amazon Web Services (AWS) and HP, helping launch and grow multiple high-impact security and enterprise mobility offerings.