为什么机器学习对于有效的 API 安全必不可少

2020 年 8 月 26 日发布

在过去十年中，对更快的开发周期、高可用性、选择性按需扩展和总体解耦的追求，推动技术驱动型组织走向微服务架构。结果，单片软件中的许多安全函数调用变成了通过非安全网络在微服务之间进行的 API 调用。也就是说，这种转变虽然解决了许多运营和业务挑战，但也带来了一些新的安全挑战。

随着开源软件、容器化和基础设施即代码（IaC）的激增，安全形势更加恶化。现在，加入或修改微服务可能需要 15 分钟，安全团队可能没有及时的机会正确分析微服务的安全性。在部署流程中引入全面的安全评估作为门控阶段几乎总是会遭到 DevOps 团队的不利反应。即使成功有效地控制部署，许多安全问题（尤其是运行时攻击）也无法在部署时识别。

安全已不再一样

虽然开发人员和 DevOps 团队有理由热情接受向微服务的过渡，但安全团队却越来越难以跟上不断增长的 API 数量、不断变化的 API 定义和行为、缺乏 API 文档（尤其是在开源组件中）、多样化的协议和有效负载结构。现在，许多模块之间的内部函数调用已经成为微服务之间的 API 调用，攻击面呈爆炸式增长，安全管理很快变得难以承受。

即使在中等规模的微服务环境中，在部署或更新任何微服务之前定义和维护每个 API 端点的正常和可接受行为列表也是非常具有挑战性的，甚至是不可能的。这还包括维护每个 API 端点的授权策略。新的微服务的增加、弃用的微服务的删除以及流量的季节性是“正常和可接受”的定义不断变化的可预见的原因。还有一些不太可预测的原因，例如间歇性网络中断、DDoS 攻击、上游中断和安全漏洞，这些也可能发挥重要作用。

考虑到适当的安全性需要考虑的所有因素，需要近乎实时地收集、关联、处理和学习大量数据，以做出合理、及时的安全决策。这一要求使得传统的解决方案和控制变得不够充分。值得庆幸的是，过去十年机器学习（ML）的进步和学习模型的成熟为应对这些新的安全挑战提供了一个非常强大的平台。

ML 来救援！

机器学习的强大功能让我们重新思考定义、改进和实施安全控制的方式。它使我们能够应对 API 交互的动态特性，同时仍然提供有效的 API 安全性。我们现在将讨论实现全面有效的基于 ML 的解决方案的三个主要步骤。

1. 让机器学习发现范围...不要喂它

如前所述，API 的动态特性和庞大数量使得开发人员或安全团队无法有意义地定义 API 定义并将其提供给保护 API 端点的系统。使用基于 ML 的模型，可以输入一些离线训练数据，让系统根据 API 端点（HTTP 的情况下为 URL 路径）、调用者、有效负载等自主发现、识别、分类、解释和允许/拒绝 API 调用。例如，使用基于 ML 的 URL 图来完成 API 发现，并且可以使用深度学习进行组件分类。这使得系统能够随着时间的推移构建、发展和学习 API 通信的范围和性质。

一个针对此类范围发现的经过良好校准的系统可以在数小时内取代每次更新部署所需的数天甚至数周的人力。

2. 学习、调整、重复

这是任何基于 ML 的安全解决方案的核心部分。好的解决方案使安全控制能够观察系统的行为，构建行为配置文件，并调整当前模型（使用过去的观察构建）。这是一个连续的过程，干净实施的解决方案使得控制能够以有意义的方式及时应用。例如，如果过去的配置文件显示特定的 API 调用序列是正常流程，则可以在几个小时内了解并在配置文件中添加在流程中实现几个额外调用的更新应用版本。

这就是基于 ML 的解决方案的论点非常容易理解的地方，因为行为分析和校准是尽可能实时的。

3. 探测

前两个步骤使我们能够了解并了解系统中应该被视为“正常和可接受的”行为。最后一步是检测并找出超出该范围的行为模式。例如，如果在了解了数百名用户的正常行为后，系统注意到某个用户突然出现大量登录或数据下载尝试，或者多个用户在短时间内尝试从同一网络地址登录，则这些行为可以很快被标记为异常。可以使用顺序无监督深度学习来进行 API 异常检测。

这里值得注意的是，反馈延迟是整个学习周期中非常关键的部分，以防止恶意行为者调整其行为并“逃避雷达监视”。

图 2 显示了一系列 API 调用，这些调用被分析为正常且被系统接受。

图 3 显示了系统检测和标记的异常 API 调用序列。