在整个 DevOps 中分层安全

DevOps 运动改变了我们集成和发布工作的方式。它使我们从缓慢的、有时是每年的发布周期转变为每天（甚至在某些情况下是每小时）的发布。我们有能力编写代码，并几乎立即在生产环境中看到我们的更改。虽然这可以给我们和我们的客户带来温暖和舒适的感觉，但也可能为恶意攻击者提供可乘之机。

DevOps 是打破壁垒并支持对市场变化和客户需求做出快速响应的了不起的第一步，但我们仍然需要打破一道重要的壁垒，我们需要将一个重要的群体纳入其中：安全运营 (SecOps)。

为了将这个关键群体纳入持续集成和部署 (CI/CD) 的生产变更中，我们正在将 DevOps 重新构想为 DevSecOps。我们在这项工作中面临的挑战与我们在将开发和运营结合在一起时面临的挑战相同：开发人员希望快速行动并经常更改，而运营部门则希望稳定和不频繁的更改。安全团队倾向于支持稳定和不频繁的更改，因为更改可能意味着重复安全测试并重新认证环境。

当我们以 DevOps 的速度前进时，我们如何期望这些团队每天或每周都重新做他们的工作呢？

分层安全

在深入探讨这个问题之前，我们应该谈谈一个关键的安全实践：分层安全或纵深防御。分层安全是指应用多种安全措施的做法，每一层都与前一层和后一层重叠，以创建安全控制网络，共同保护技术系统。

在分层安全方法中，公司通过采用访问控制（如 WAN 网关防火墙、本地门禁卡入口和静态数据加密）来努力减轻对其技术系统的入侵。控制列表很长，但重点是，没有一个单一的控制可以充分保护技术系统。同样的方法也适用于对我们的应用程序执行安全分析。

联系贵公司的应用程序安全团队，询问他们使用哪些扫描和工具来确保您编写的应用程序是安全的。他们很可能不会回复一个工具，因为没有一个工具可以完成所有工作。相反，他们可能会为您提供他们使用或期望开发团队使用的工具列表或工具类型。

这使我们回到了之前的问题：我们如何在进行所有这些扫描和使用所有这些工具的同时，期望保持持续部署周期？这是一项艰巨的任务；其中一些扫描和工具需要花费数小时、数天或更长时间。

内联扫描

虽然有些安全工具和扫描器确实需要很长时间才能运行，但有些更快的工具我们可以而且应该在我们的开发生命周期的早期阶段使用，以形成我们的 DevSecOps 的第一层。这就是左移背后的理念：将流程从我们的开发生命周期的末尾（或右侧）移动到开头或中间，即更靠左的位置。

第一层应包括需要几秒钟（或几分钟）才能运行的工具和扫描器。一些常见的例子包括代码检查器、单元测试、静态代码分析器（如 SonarQube）、第三方依赖项漏洞检查（如 OWASP Dependency Checker）以及可能的集成测试子集。

您可能会问：“检查代码和运行单元测试如何融入 DevSecOps？” 软件中的错误可能会为对手寻找的完美入口提供机会。例如，在其过去的两次关键 Web 应用程序安全报告（2013 年和 2017 年）中，OWASP 将代码注入列为头号漏洞。检查器、单元测试和静态代码分析可以帮助捕获我们的一些错误，并可能帮助防止代码中的安全漏洞。请记住，一切都与分层有关，而这仅仅是第一层。

由于这些工具和扫描花费的时间很少，因此最好将它们尽可能地向左推移到开发生命周期中。当开发人员将代码推送到我们的 Git 存储库并打开拉取请求时，这些工具和扫描器会运行以确保代码在合并之前通过。除了确保我们的主干分支保持可构建状态之外，在开发生命周期的早期阶段拥有这些工具还可以尽早且频繁地向开发人员提供反馈。

预部署扫描

DevSecOps 的第二层包括与我们的部署管道内联运行的工具，完成时间可能为几分钟到一小时。这可能包括更深入的第三方漏洞扫描、Docker 镜像扫描和恶意软件扫描。

这一层的关键是扫描器和工具在构建工件生成之后，并在它们存储到 Artifactory 或 Amazon Elastic Container Registry 等任何位置之前运行。更重要的是，此层中的任何故障都应立即停止当前部署，并向开发团队提供反馈。

另一个关键是这一层以及所有未来层中的并行化。开发人员希望他们的更改尽快部署，而串行运行多个扫描（每个扫描可能长达一小时）将不必要地减慢部署周期。通过并行运行这些工具，部署速度的降低等于运行时间最长的扫描。

部署后扫描

DevSecOps 的下一层包括我们可以在并将代码部署到预生产环境后使用的工具和扫描器。这些工具可能包括性能和集成测试以及应用程序扫描器（如 OWASP Zap）。我们应努力使这一层快速运行，最好在一小时或更短时间内完成，以便向开发人员提供快速反馈，并限制对我们的 CD 流程的影响。

为了确保我们不会错误地将易受攻击的代码部署到生产环境，这一层应作为 CD 管道的一部分运行，目标是在任何扫描器发现漏洞或以其他方式失败时删除工件、销毁环境或回滚环境。

根据行业、安全和法规要求，我们可以在此层成功完成后自动部署到生产环境。管道中应该已经有足够的自动化扫描和测试来合理地证明应用程序的安全性和坚固性。

持续扫描

我们讨论的大多数扫描器和工具都已嵌入到 CI/CD 管道中。我们的目标是在平衡这些工具对我们的 CI/CD 管道时间线的影响的同时，为应用程序的安全性提供合理的保证。

DevSecOps 的最后一层是持续扫描或持续安全 (CS)。正如持续集成、测试和部署是 DevOps 的同义词一样，持续安全是 DevSecOps 的同义词和基石。这一层包括 Nessus、Qualys、IBM App Scan 以及其他基础设施、应用程序和网络扫描工具等工具。

CS 没有嵌入到 CI/CD 管道中，而是作为异步的、持续的过程围绕着它，并向开发人员提供持续的反馈。开发人员如何接收和响应这些反馈需要讨论和商定。一种可能性是将调查结果作为工单提交给开发团队，并进行严重性分类。开发人员会在收到 Sev1 工单后立即处理，并在较长的周转时间内处理 Sev2 和 Sev3 工单。

这些工具和扫描器如何启动以及运行频率是利益相关者应商定的 CS 的另一个方面。具有 API 的工具可以通过 CI/CD 管道在部署完成后启动。其他工具可能需要根据需要或基于某些时间节奏来完成。无论如何完成，重要的是这些工具和扫描器不仅仅运行一次，甚至不仅仅每年运行一两次。相反，这些工具和扫描器应尽可能频繁地运行，并尽可能频繁地运行，这对应用程序来说是有意义的。