构建下一个威胁模型时您大概应当纳入的内容

我们在 DisruptOps 正着手构建威胁模型，因此我决定重新梳理一遍各种不同的方法。很快有一点引起了我的注意：我所见过的威胁建模文档或工具，几乎没有一个涵盖 CI/CD 流水线。

这。是。个。问题。 请将您的流水线纳入威胁模型。

过去几年间，除了各类咨询工作之外，我还亲自执行了数十次云安全评估。我始终把开发/部署流水线纳入评估范围，而它们往往正是我发现较大安全问题的地方。如果有人只需在某处修改一个模板，或者窃取已存储的密钥，就能改动基础架构的核心部分，那么您那个超级安全的云环境不过是一座纸牌屋。

大多数威胁模型都以数据流图或架构图为起点，您可以据此逐步梳理应用程序并对威胁建模（我本人偏好 STRIDE，它源自微软）。这涵盖了应用程序功能，却未涵盖流水线。

在对流水线套用您*当下选用的*威胁模型时，请把开发人员/管理员视为用户；如果流水线本身存有凭据，也请把它视为用户（考虑它与您环境的连接方式）。

例如，有人能否伪造一次调用 Jenkins 的 API 请求，从而触发生产应用程序的变更？（按照 Jenkins 常见的配置方式，很可能可以。）作业变更与代码变更的抵赖问题呢？流水线中的权限提升呢？

流水线通常经不起严格的安全审视，因此我们将在后续有关安全基础的文章中讨论这一话题。您大概不会感到意外：我倾向于建议对流水线部署及任何相连的基础架构都设置护栏，以降低风险。例如，您的 CI 服务器绝不应对公网暴露，也不应具备被暴露的可能。您可以使用相互加强的护栏，确保它位于没有 Internet 网关的网段中，并且确保您的安全组不允许公共访问（更好的做法是，同时确保 CI 服务器始终位于弹性负载均衡器之后）。

应用程序的攻击面仅限于其自身组件的时代早已结束。在云中，我们的大多数应用程序都由流水线提供支撑，而由于流水线拥有深层访问权限并存有凭据，它极有可能成为最脆弱的软肋。