CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章如何在整个DevOps中建立分层安全？由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

将我们的DevSecOps方法分成多层，可以在对强大安全性的需求与快速移动并经常部署的需求之间找到适当的平衡.

DevOps运动改变了我们集成和发布的方式。它使我们从缓慢的发行周期(有时是每年的发行周期)过渡到每天(有时甚至是每小时)发行。我们能够编写代码并几乎立即看到生产中的变化。DevOps是突破壁垒并支持对市场变化、客户需求快速响应的令人惊叹的第一步，但是仍然需要打破一堵重要的壁垒，我们需要折中的一个重要群体：安全运营(SecOps).

为了在生产变更持续集成和部署(CI/CD)中包括这个至关重要的小组，我们将DevOps重新定义为DevSecOps。我们在这项工作中面临的挑战与在将开发和运营整合在一起时所面临的挑战相同：开发人员希望快速行动并经常进行更改，而运营则需要稳定和不频繁的更改。安全团队倾向于支持稳定性和不频繁的更改，因为更改可能意味着重复安全测试并再次对环境进行认证.

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

安全分层 。

在深入探讨这个问题之前，我们应该谈谈一种关键的安全实践：分层安全或深度防御。分层安全是一种应用多种安全措施的实践，每一层都与前一层和下一层重叠，以创建一个安全控制网络，这些网络可以一起工作以保护技术系统.

在分层安全方法中，公司通过使用诸如WAN网关防火墙和静态数据加密之类的访问控制来减轻对技术系统的入侵。控件列表很广泛，但要点是，没有任何控件可以充分保护技术系统。同样的方法适用于对我们的应用程序执行安全性分析.

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

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

内联扫描 。

尽管某些安全工具和扫描器确实需要很长的时间才能运行，但仍有一些更快的工具可以在开发生命周期的早期使用，以形成我们的第一层DevSecOps。这就是左移背后的想法：将流程从开发生命周期的末尾(或右侧)移到开始或中间，即再向左移.

第一层应包括需要几秒钟(或几分钟)运行的工具和扫描程序。一些常见的示例是代码lint，单元测试，SonarQube之类的静态代码分析器，OWASP Dependency Checker等第三方依赖项漏洞检查，以及集成测试的子集.

您可能会问：“整理代码和运行单元测试如何适合DevSecOps?” 软件中的错误可以为正在寻找的对手提供完美的解决方案。例如，OWASP在过去的两个关键Web应用程序安全报告(2013年和2017年) 中将代码注入列为第一漏洞。单元测试和静态代码分析可以帮助捕获我们的一些错误，并可能有助于防止代码中的安全漏洞.

由于这些工具扫描只需要很少的时间，因此最好将它们推到开发生命周期中的最左侧。当开发人员将代码推送到我们的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管道中，而是作为异步的，并向开发人员提供持续的反馈。开发人员如何接收和响应该反馈需要进行讨论和达成共识。开发人员将在收到任何反馈后立即对其进行处理，并在较长的周转时间内解决.

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

结论 。

正如我们不能通过使用一两个工具或安全性原则来确保技术系统的安全性一样，我们应用程序的安全性也不能仅取决于一两个工具或扫描仪的类型。它采用分层的方法来应用不同的工具和扫描程序，以合理地确保我们的应用程序及其运行的基础结构的安全性.

关于我们泽阳，DevOps领域实践者。专注于企业级DevOps运维开发技术实践分享，主要以新Linux运维技术、DevOps技术课程为主。丰富的一线实战经验，课程追求实用性获得多数学员认可。课程内容均来源于企业应用，在这里既学习技术又能获取热门技能，欢迎您的到来!(微信ID: devopsvip) 。

原文地址：https://mp.weixin.qq.com/s/VCSmOgdB-8mejCaEqV0LQA 。

最后此篇关于如何在整个DevOps中建立分层安全？的文章就讲到这里了,如果你想了解更多关于如何在整个DevOps中建立分层安全？的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。