领先于最新 API 威胁的三种方法
采用以 API 为中心的安全方法，保护以 API 为中心的世界
API 连接的安全隐患
二十多年前，杰夫·贝佐斯 (Jeff Bezos) 宣布，要求所有 Amazon 团队必须“通过服务接口公开其数据和功能”，无一例外。这份备忘录（现在称为“API 强制令”）实质上表明，应用编程接口 (API) 并非可有可无，并且这引发了世界各地的开发人员通过 API 连接一切的竞赛。然而，许多企业的 API 安全措施已经落后于快速的 API 部署速度。
根据最近发布的《2024 年 API 安全和管理报告》，API 相关流量目前占所有动态互联网流量的大多数（约 57%）。但企业普遍面临各种挑战，包括：
隐形且未受保护的攻击面：IT 团队和安全团队无法抵御他们看不到的威胁，而且企业拥有的“影子 API”（即：不受 IT 团队或安全团队管理的 API）会导致数据泄露、横向移动和其他网络风险。
过于宽松的授权：如果原本拥有只读权限的 API 被赋予“写入”权限后落入了不法分子之手，将导致系统容易遭受攻击并可能造成数据丢失。而近 60% 的企业授予至少一半 API 拥有“写入”权限。
企业可能很容易忽视和错误分类 API 相关错误的原因：并非所有 API 错误都是由攻击引起，也不是所有针对 API 的攻击都可以用相同的方式予以缓解。遗漏或误判的错误或漏洞，可能会导致不愉快的最终用户体验，甚至更糟糕的情况下，会遭受网络攻击。
据估计，人们目前使用的公共和私有 API 数量达到 2 亿个，并且这个数字还在继续增长。为了安全地利用这些（以及未来）API 的强大功能，企业需要采取一种专门构建的 API 管理方法，其中包含以下三个注意事项。
1) 宜利用专门构建的机器学习服务，提高 API 可见性和安全管理效率。
假设 Acme 医院提供了深受患者和供应商喜欢的数字计划：从无缝的移动远程医疗到 AI 辅助记录处理，应有尽有。某天，Acme 的一位开发人员启用了计费系统 API 的“写入”访问权限，但没有提供适当的文档。几个月后，供应商遭到黑客攻击，然后攻击者通过横向移动，能够利用 Acme 的公共 API 来泄露医院的患者记录。
如果 Acme 要是能够自动执行以下操作，他们便可以更快速地检测并缓解此次攻击：
发现所有公共 API 端点（包括未经身份验证的 API）以及相关流量
检测 API 模式，即：定义有效 API 请求/响应规范的元数据
检测针对 API 的攻击变体
开启：利用机器学习模型的 API 安全解决方案，无需 IT、安全团队和开发人员之间进行手动的“时间点”通信。
例如，机器学习提供支持的 API 发现和 API 模式检测可以为像 Acme 这样的机构提供更完整的 API 清单：这些 API 是什么？它们会访问哪些数据和系统？何时何地进行？谁被授予了“只读”权限，谁被授予了“写入”权限？
此类数据是阻止影子 API 扩散的关键。在开发新的客户功能过程中（通常首先作为面向互联网的 API 公开），API 文档和安全最佳实践通常由各个开发人员自行决定。很多时候，没有足够的时间或资源来让安全团队介入。
这就是出现安全挑战的原因：企业无法保护他们看不见的东西。事实上，Cloudflare 机器学习模型发现的 API 端点比组织自行报告的 多 31%，这表明将近三分之一的 API 本质上是影子 API。
影子 API（通常是在频繁更改代码的过程中良性引入）本质上并不是恶意 API。但是，考虑到 86% 的开发人员不将应用安全视为首要任务，影子 API 便成为了头号威胁。如果这些 API 被利用，则可能导致数据泄露、未修补的漏洞、数据违规，以及其他风险。机器学习有助于将这些影子 API 暴露出来。
2) 忌完全依赖于 Web 应用安全工具来实现 API 安全和管理。
Web 应用与 API 本质上完全不同。拼车应用对用户来说“可见”，但允许该应用访问 Google Maps 数据的 API 却“不可见”。鉴于这些（以及其他）差异，企业需要专门设计的 API 安全方法来保护 API，而不只是采用 Web 应用安全方法。
例如，传统的 Web 应用防火墙 (WAF) 根据黑名单来过滤和监测 Web 应用与互联网之间的 HTTP 流量。WAF 会查找已知的攻击迹象，然后采取措施加以阻止。同时所有其他流量均被允许。这就是“消极”安全模型，对 Web 应用安全可能很有效，可以更轻松地识别和阻止恶意 Web 流量。
但保护 API 免遭滥用的 API 安全方法需要“积极”安全模型。不是只寻找“已知的恶意”流量，而是寻找“已知的良性”请求并且只允许这些流量通行：阻止所有其他流量。 （详细了解这些请求的定义，即：API 调用，请查看此处）。
为什么？
请看具体示例：一家澳大利亚电信供应商经历了一次数据泄露，导致近 1000 万客户数据被泄露。黑客通过一个未经身份验证的 API 访问了某客户数据库。虽然此次攻击的完整细节尚未对外公开，但值得注意的是，“积极”API 安全模型只允许符合公司 API 规范的 API 流量通行。
换句话说，转为采用“积极”API 安全模型，仅允许来自经过身份验证的用户、经过身份验证的公司网络的流量，以及采取授权操作。（企业还可以组合使用多种安全模型，例如将 WAF 的“消极”安全模型与 API 网关的“积极”安全模型叠加。）
总之：需要采用一种全面的 API 方法来抵御各种 API 威胁，其中包括以下 6 大 API 威胁：
来源：《2024 年 API 安全和管理报告》
如上图所示，HTTP 异常占已缓解 API 威胁的大多数 (60.7%)。HTTP 异常，例如缺少用户代理（为最终用户检索互联网内容的软件）以及其他异常，是恶意请求的常见信号。
通过应用“积极”安全方法（如前所述），企业可以识别 HTTP 异常和其他威胁，并且只允许每个 API 的“干净”流量访问其 API 服务器。
3) 宜统一管理应用开发、性能和安全。
IT 团队、安全团队和应用开发人员应该共担责任，一起保护由数千个 API 提供支持的资产组成的巨大攻击面。但这些团队的优先事项往往相互冲突：
73% 的开发人员表示，其工作或安全团队要求使用的工具“妨碍了他们的工作效率和创新能力”。
87% 的 CIO 认为，软件工程师和开发人员“会在安全策略与控制措施方面做出妥协，以便更快速地将新产品和服务推向市场”。
只有一半的 CISO 认为，开发人员对开发和工作流程工具的安全风险“非常熟悉”。
因此，企业可能需要权衡加快创新与提高安全性，导致其 API 容易遭受攻击。报告显示，近 60% 的企业授予对其至少一半的 API 进行“写入”访问，但谁最终“负责”确保“写入”访问权限不会授予给错误的用户呢？
对于持续通过 API 提供新服务的企业，Cloudflare 全球连通云可以作为应用部署与 API 纵深防御之间的连接纽带。
全球连通云是一个统一的云原生服务平台，可以简化跨 IT 环境的“任意对任意”安全连接。反过来，这有助于组织重获控制并监测其不断扩展的数字化域（包括 API 流量）。
采用 Cloudflare 全球连通云，企业可以使用单一控制平面来处理下列以及更多工作：
自动化 API 发现和可见性，为所有利益相关方提供清晰的 API 资产清单
从一开始就内置现代化的 API 身份验证和授权流程
管理 API 端点，以监测多种指标，例如延迟、错误和错误率，以及 API 驱动域的响应大小
逐步提高 API 安全模型的成熟度
API 技术并不是什么新概念，但对于许多 AppSec 团队和 AppDev 团队来说，全面解决 API 安全问题并非易事。虽说“万事开头难”，但可以分阶段解决 API 安全：
第 1 阶段 - 可见性：首先，识别企业内部使用的所有 API。包括：使用 API 发现工具，审核技术文档和协议，与开发人员交流，以及监测 Web 流量。
第 2 阶段 - 常规 Web 攻击防护：Web 应用与 API 经常协同工作（例如，电商网站使用 API 处理付款）。使用并集成直接设计用于保护 Web 应用（以及一定程度上，其背后的 API）的工具，抵御 DoS 和 DDoS 攻击、凭据填充、零日漏洞和其他威胁。
第 3 阶段 - 整合高级 API 安全：Cloudflare Web 应用和 API 保护 (WAAP) 产品组合由 Cloudflare 全球连通云提供支持，可为面向公众的 API 提供全面的安全保护和性能，同时不影响生产力。借助 API 发现、集成 API 管理和分析，以及分层防御，Cloudflare 解决方案让 IT 团队和安全团队能够获得对其 API 的可见性和控制。
Cloudflare 就影响当今技术决策者的最新趋势和主题发布了系列文章，本文为其一。
进一步探索这个话题。
查看《2024 年 API 安全和管理报告》，了解最常见的 API 漏洞、行业预测以及保护 API 安全的深入建议。
关键要点
阅读本文后，您将能够了解：
三个常见的 API 相关挑战
专门构建的 API 管理方法注意事项
如何逐步提高 API 安全模型的成熟度