随着应用程序编程接口 (API) 的使用与日俱增，实现和维护有效安全性的挑战从未像现在这样大。 

由于缺乏管理 API 的单一标准，这意味着团队不能仅依靠工具来解决安全问题，因此这一挑战变得更加严峻。没有任何一种产品可以解决 API 环境的每种语言、框架或上下文的所有问题。

为此，企业玩混搭。现代组织专注于使用工具来应对具有挑战性的网络威胁——以至于陷入阻碍进展的狭隘视野。

一份 2022 年的报告显示，大型企业安全团队平均监督 76 种安全工具，那太多了。

对自动化和工具的关注会产生一种错误的安全感，并且无法解决根本原因，因为大多数数据泄露都是由人为错误引起的。

研究发现，开发人员还严重依赖预先存在的代码，例如，近一半的开发人员使用具有固有缺陷的库或框架，因为它们没有经过持续测试或评估。

同时，开发人员假设因为代码存在于库中，所以它是安全的。但情况并非总是如此。

实现最佳实践

是时候按下重置按钮了。我们需要停止不断寻找最新的闪亮对象，而开始更多地关注我们的员工。是的，安全工具已经取得了令人瞩目的进步，并且起到了关键作用。

然而，软件开发团队仍然需要提高他们的安全能力以有效地部署这些解决方案。由此产生的培训和政策实施应侧重于以下最佳实践：

1.分配所有权：

就其本质而言，API 被过度许可以允许应用程序之间进行未经检查的通信。坦率地说，他们“说得太多了”——导致过度分享的状态，从而引发妥协。这就是“TMI 技术”。

TMI 技术持续存在是因为我们很少分配 API 的所有权（无论是分配给开发人员还是分配给他们的应用程序安全团队）。因此，很少对哪个 API 共享什么进行细致的监控。

为了纠正这个问题，管理人员应该将 API 所有权分配给开发团队，并帮助他们认识到广泛开放（和未记录）API 实施的风险。当涵盖了此类责任并建立了上下文行为基线时，关闭这些麻烦的“对话”就容易得多。

2. 像对待人一样对待 API：

为了扩展我们的第一个最佳实践，我们可以通过对 API 应用零信任、最小特权和基于角色的授权来立即改进访问控制，就像我们对人所做的那样。

如果需要 API 来执行特定功能，那么我们将其权限限制为仅用于该功能。同样，我们应该进一步适当地限制 API 花在访问上的时间以及访问的容量。

3. 融入“测试先行”的心态：

开发人员需要了解假设的缺陷——但最好不是困难的方法。因此，开发团队应定期测试 API 以验证它们不可利用（同时仍按预期运行）。

从长远来看，尽早并经常进行测试有助于减少错误、节省时间和额外成本。此外，安全团队将对此表示赞赏。

4. 进行定期模拟：

当出现不同的 API 情况时，模拟可以更好地让开发团队做出反应。它们似乎正是开发人员提高安全编码技能所需要的。

研究发现，每 10 个开发人员中就有超过 9 个承认需要安全框架方面的培训。

近三分之一 (30%) 的受访者表示，他们会从以工作相关的真实案例为特色的实用安全培训课程中受益；几乎同样多的人表示他们将从动手互动中受益——例如他们尝试编写安全代码的练习课。

5. 改变绩效评估指标：

安全发展不能仓促行事。因此，鉴于明显的后果，是时候停止在团队成员评估过程中过分强调功能交付的原始速度了。

否则，性能审查阶段会给开发人员提供一种不正当的动机，如果不牺牲质量，就牺牲安全性）。相反，组织应该奖励那些能够在合理的时间范围内创建高质量、安全代码的人。

网络犯罪分子构成的威胁将在未来数月乃至数年内继续演变和加剧。

通过采用更加以人为本的 API 安全方法，组织可以确保他们最有能力抵御这些威胁并继续发展和繁荣。