端到端 API 安全性：从开发到停用
Akamai 在 2024 年 6 月收购了 Noname Security。本博文最初发表于 2022 年 10 月 5 日，现已归档。
妥善保护应用程序编程接口 (API) 的流程绝不止于安全性的范畴。它还涉及到对安全保护成果有推动作用的 IT 运营和架构问题。为确保取得成功，必须将 API 安全性视为涵盖整个软件生命周期的端到端流程。此流程始于开发，延续到运行时和服务终止。
质疑某些原有假设
API 安全性迫使我们质疑某些原有假设。例如，我们以往或许会假设，将代码部署到生产环境就是软件开发工作的终点。但这已经不再契合实际。当今的软件开发不止于编写代码的基本流程。
开发已成为一种持续的流程，持续集成与持续部署 (CI/CD) 的概念充分体现了这一点。与此同时，DevOps 成了软件问世的途径，它融合了既往的软件开发 (Dev) 与 IT 运营 (Ops) 将软件部署到产品之中的连续步骤。
如今，只要有代码片段部署到生产环境中，DevOps 团队就要忙于筹备部署应用程序的又一次迭代，而下一次部署有可能就安排在一个小时之后。在 DevOps 的世界里，开发 (Dev) 似乎就是运营 (Ops)。此流程的运营方面无法再与开发方面清晰区分。因此，应用程序安全性必须覆盖开发与运营工作中相互关联的阶段。
此外，现代软件不仅涉及到代码，还涉及到各种组件（例如微服务、API、代码库等）之间的一组连接。保障 API 安全意味着了解这些连接的运作方式、所在位置，及其有可能如何将漏洞暴露给攻击者。这种要求也超越了常规安全实践，包含各种运营任务，例如创建 API 清单和监控 API 流量。
API 安全性必须覆盖并超越整个 SDLC
API 安全性必须贯穿整个软件开发生命周期 (SDLC)，在应用程序生命周期的开发阶段、运行时及之后积极开展。从开发阶段起，开发人员可指示应用程序通过 API 调用来调用 API 功能，或是创建 API，将应用程序的功能和数据公开给其他软件应用程序。两种 API 操作模式都会造成风险。
发生 API 安全风险的原因多种多样，但很多都与影响用户身份验证和授权的 API 配置问题相关。配置不当的 API 可能会允许未知用户访问敏感数据。此外，配置错误还可能导致用户获取超出允许范围的数据。其他配置问题可能会允许攻击者通过调用导致 API 不堪重负，并执行拒绝服务 (DoS) 攻击。
开发阶段
API 安全测试可在开发阶段缓解此类 API 风险。测试需要专门针对 API，因为通用应用程序测试无法发现 API 配置不当等问题。而专用 API 安全测试套件需要识别 API 漏洞，并在部署软件之前促进漏洞修复。
API 安全测试要想发挥作用，必须安排在开发流程的早期阶段，这就是所谓的“左移”方法。测试套件还必须与 CI/CD 管道集成。否则，安全修复流程会过于繁琐，导致 DevOps 团队成员难以应对。
运行时阶段
在运行时，API 安全性就意味着实时阻止威胁。这需要对 API 进行安全监控。API 安全性解决方案必须随时监控 API 流量，并在发现异常行为或攻击特征时向管理员发出警报。此外，解决方案还可以采取额外措施，在检测到威胁时自动阻止 API。
清点 API 的必要性
API 运行时安全性相对直观易懂。但只有在 API 安全性解决方案了解所有 API 的位置时，它才能发挥作用。为了确保安全性，API 必须接受 API 态势管理，其中涉及到 API 发现流程。如果安全性解决方案不知道 API 的存在，保护 API 就无从谈起，正因如此，必须进行 API 清点。API 发现同样必不可少，因为 API 网关和 Web 应用程序防火墙 (WAF) 不能自动清点环境中的所有 API——虽然人们可能会误以为它们具备这种功能。
恶意、僵尸和影子 API：意外“惊喜”！
通过 API 发现过程，IT 管理员不可避免地会意外发现，其环境中包含许多“恶意”、“僵尸”和“影子”API。
- 恶意 API 是随着时间的推移，不知何故被人所遗忘的 API。它可能是从未关停的旧版 API，也可能是商用套装软件应用程序公开的一个 API，但无人知晓。
- 僵尸 API 是未被检测到并且正常工作的 API。
- 影子 API 是指由某人自行创建、未告知 IT 部门的 API。
全部三种未被发现的 API 都会造成风险。由于它们处于隐藏状态，无法对其应用安全策略。若未对其进行安全配置（它们几乎总是配置不当或者不具备相应的补丁程序），它们就会成为攻击者实施不当访问的途径。
确定如何处理先前未知的 API 相当困难。如果要继续运行这些 API，必须保证它们符合配置、身份验证等方面的策略。在发现 API 时立即将其关停或许是最好的选择，但这样做有可能造成问题。
例如，如果某个 API 的早期版本已被替代，但旧版本仍在使用，那么关停可能会造成应用程序崩溃。如果某人决定将 API 下线，可能会因此惹上麻烦。为此，有必要找到一种工具集，为管理员提供做出正确决定所需的信息。
利用适当的工具
要在端到端基础上执行 API 安全性，适当的工具必不可少。有效的端到端 API 安全解决方案必须能处理 API 安全测试、API 运行时安全性，以及 API 安全态势管理和清点。我们需要认真审视现有工具，因为大多数 WAF 和 API 网关并未涵盖开发、测试、运行时监控和清点。
理想情况下，API 安全性解决方案还应该在不影响网络或 API 性能的前提下运行。例如， Akamai API 安全性解决方案通过监控网络流量副本来发挥作用。它们可在此类复制的网络流量中发现 API 调用，并在此过程中识别未知的 API 和安全威胁。
API 安全性必须涵盖 API 生命周期的所有阶段——从开发、运行时一直到停用。安全性部分源自于在技术上与安全性无关的流程，如 API 清点。未知 API 会带来风险，因此确定这些 API 能加强其应用程序的安全性。这是一种端到端的主张。API 安全性措施越完善，整个环境就越安全。