如何从 DevOps 无缝地进化到 DevSecOps

本文要点

• 遵守 IaaS 安全性和合规性意味着在安全性和正常运行时间方面，云供应商必须满足某些法律和行业标准 。

• 在正常运行时间和冗余方面，即使是最可靠的数据中心也比不上主要的云平台。是时候采取行动了。

• 首先审计我们的云计算栈，并考虑在何处以及如何集成不同的业务系统。

• 检查我们和云供应商的合同，查看如果受到攻击哪些故障保护是到位的。配置 IAM，给所有用户分配级别访问权限。

• 即使是最周密的计划也会失败。用户会犯错（如：上传私钥、无法使用 VPN 等等）。定期测试集成是确保基础设施安全的关键。

根据定义，DevSecOps 是DevOps的进化。这个不断发展的理念本身还未完全成型，还有很多东西有待定义。对于任何人来说，任何接近完全成型的最佳实践或规则都实现了对自身及对该理念超载。这应该是预料之中的事，因为相对而言 DevSecOps 还是个新生事物。

这就是 DevOps 的本质，总的来说，它总是在改进，永不停滞。

作为一个过程，DevOps 本身并不古老。在很大程度上，它已经被认为是促进 IT 部门中各个团队之间合作的一种手段，否则这些团队可能在很大程度上仍然相互隔绝。

在完全成型的 DevOps 过程中，IT 开发团队直接和运维团队协作。这使得编码和直接软件开发能够与传统基础设施（如：设备管理、网络维护和服务台功能）协同工作。

DevOps 旨在允许让这些方面以自动化和精简的方式相遇、交流，并更容易改进彼此的工作。而其中有一个重要方面却被丢到了一旁，那就是安全。

安全是一个不断发展的问题，不可能突击上一段时间就能解决掉。它是个令人头痛的问题，需要包含在 DevOps 过程中以在组织内部产生长远的影响。

只能在整个项目进行过程中来解决项目的安全问题。

保持 DevOps 心态

DevOps 的核心是一种经营理念，是构建和组织公司 IT 文化的方式。在这一理念背后的一大卖点是，它有助于创建软件、测试它并更快地把它推向市场。尽管这确实是事实，但还不是全部。

如果生产出来的产品质量不高，那么快速地创建和发布软件就没什么意义。在质量控制中忽略 DevOps 的作用将无法理解其真正的重要性和意图。有效的 DevOps 允许开发和运维部门协调一致，并尽可能快地创建高水平和质量受控的软件。

DevOps 一直都在发展，随着它的不断发展，很明显可以看到，这些流程、服务和所需的工具要包含的远远不止软件开发和运维管理。随着大规模数据泄露及其灾难性结果的新闻不断地出现，网络安全迅速成为任何 IT 生态系统的重要组成部分。这种认识导致了 DevSecOps 的产生。

过渡到 DevSecOps，并拥抱它

目标是让安全成为开发工作流的一部分。

如上所述，DevSecOps 是 DevOps 的自然扩展。该过程旨在做两件事情：它可以利用 DevOps 带给 IT 部门开发和运维团队的好处并把它们扩展到安全团队，或者可以把需要完成的安全过程集成到 DevOps 团队中。

在 DevOps，如果生产出来的产品质量不高，那么快速地创建和发布软件就没什么意义。如果生产出来的产品不安全，那又有多大的意义呢？

安全在过程中被忽视了，其实，从逻辑上来说，它应该是重要的组成部分。公司确实不能再忽视这个问题了。

任何组织都可以用以下三种基本方式解读DevSecOps：

1. 作为一系列确保 DevOps 过程的技术协议，如：多因素身份验证或零信任。无休止的验证会让人感到疲惫不堪，但是，不经过检查就不要让任何东西通过，这是阻止来自外部几乎所有威胁为数不多的方法之一。该过程几乎总能从内部诊断到威胁。

2. 作为一系列指示何时及如何对我们在 DevOps 中所执行的一切操作进行安全检查的过程。特定场景比其他场景需要更多的安全检查。识别并指出哪个过程比其他过程需要更多的安全关注，这可以消除大多数安全威胁。

3. 作为合作和共享所有权的理念，我们的开发、运维和安全团队中的成员一起协作，每个人都负责一些通常不在其职权范围内的事情。

由于 DevOps 的基础是协作，因此这是 DevSecOps 最重要的方面。几乎可以肯定的是，引入其他关注点会遇到来自团队成员的阻力，但是，考虑到带来的长期好处，值得这么做。

这三种看待 DevSecOps 的方法最终会改善不同 IT 团队部门之间的合作。尤其是，从 DevOps 到 DevSecOps 的过渡改善了团队在开发过程中更早地检测到威胁并进行缓解的能力。

采用所有这三种选择可确保竭尽全力，在解决需要解决的安全问题的同时，维持当前开发目标，甚至进一步提高。目标不是把一切都拆掉，而是授权。

实际采用 DevSecOps 理念

DevSecOps 不可能仅仅通过正常的日常 DevOps 过程来实现。我们不能告诉团队成员只需要对安全有更多的关注就能期望得到更好的结果。安全团队成员不能随便就“蹦进”开发过程，期望跟开发人员“称兄道弟”。

那么，DevSecOps 实际上是不是真的有用？DevSecOps 的理念是一回事，而 DevSecOps 的实践是另一回事。本质上，DevOps 的这个新迭代有三个主要元素：

基于微服务的基础设施

剖析整个基础设施可能是个非常烦琐的过程。一旦真正完成，整个过程（开发软件、配置基础设施和运行安全检查）就被分解成微小的部分，每个部分都具有特定功能。这让我们的基础设施变成一台平滑的机器。

在一切都变得超级专业化、细分和明确定义后，就更容易监控过程的每个步骤，并逐步进行必要的升级。

这还允许每个人或那些小团队将流程申明为自己的流程。团队之间不会互相指责，团队合作将达到更高的水平。DevSecOps 对团队的依赖程度与 DevOps 的相同，甚至可能更高。

再说一次，目标不是把一切都拆掉。整个基础设施的剖析都是在纸上完成的。一旦剖析完毕，公司可以找到如何以有效的方式进行专业化和细分，尽可能地减少实践中造成的破坏。

持续反馈

首先，拆掉基础设施需要反馈。每个团队以及可能每个团队成员都应该有对组织的假设剖析有发言权。在一个基于反馈的系统上从零开始是理想的方式。

在 DevSecOps 调优环境中，开发人员接收有关其系统状态的持续反馈。这种不断更新的信息流让我们的团队了解它和安全威胁的关系。借助安全的混入，每个人获得最新的信息，并能够有效地实施必要的安全补丁和更新。

如果没有持续的反馈，新流程会让团队中的个别成员感到畏惧。持续的反馈对于保持 IT 团队的专注及获得灵感是必要的。当任务长时间（有时候要几年时间）以相同的方式完成时，那么持续反馈就是保持高效和熟练的必要条件。

要牢牢记住一个关键细节：反馈不仅源于管理层。反馈应该来自 DevSecOps 过程中的每个团队。如果团队在开发、安全和运维方面确实是隔离的，那么每个团队对其他团队都要负责，并应该每天来回地提供多次反馈。

自动化

人工智能和机器学习都有潜力简化几乎所有事情、减少人为错误并显著加快速度。关键是，它必须恰当地应用于我们的安全检查及其他过程。自动化很好，但是，如果不恰当地实施，就会出现问题。

大多数 DevOps 过程都灌输了大量的自动化。从底层开始的团队应该慢慢来，以避免被压垮及在团队中引起混乱。自动化不仅仅意味着人工智能。在我们的团队中推广使用最高质量的基本软件（如：恶意软件扫描程序、VPN 和双因素身份验证工具）可以帮助你立即加强安全实践。

如果开发人员必须主动开始扫描，那么，他们很可能会放弃扫描工具。双因素身份验证已经增加了一点任务处理时间，在访问任何内容时应该是自动的。一个好的规则是，不要打搅开发人员。

为了不过度考虑基本安全性，并将自动化视为充满高级人工智能的复杂工具，我们不应该忽视这些基础。很多时候，自动化确实包括高级人工智能。但是，简单来说，它接受一项要花时间的任务，并把它变成一个不需要像之前那样花那些时间就能完成的任务。

除了这些基础之外，人工智能和机器学习在网络安全方面提供的帮助尤其宝贵，因为它们不仅自动执行这些基础和基本安全协议，而且，实际上能够学习、进化并适应新出现的威胁。

DevOps工具已经存在一段时间了。也已经有专门为 DevSecOps 创建的工具，但是受到了一些批评。一些人把 DevSecOps 工具称为多此一举的DevOps。应该鼓励大家要有耐心，以培育 DevSecOps 社区，因为随着时间的推移会出现一些新的工具。

在安全编码方面培训开发人员

DevSecOps 的起源并不具体，但是，其起源大约可以追溯到简单的一句话：安全即代码。问题是，安全即代码不是大多数开发人员首先学习的东西。

在安全编码方面重新培训整个开发团队不仅仅是再培训方面的挑战，而且价格高昂。有时间和钱来完成这种培训是非常罕见的。确保从 DevOps 平稳地过渡到 DevSecOps 是必要的。

主要问题是，开发人员不了解或不认为他们的代码有问题。安全即代码通常不是开发团队担心的首要问题。要使 DevSecOps 过程站稳脚跟，这一点亟需改变。

避免过渡到 DevOps 或 DevSecOps 的困难

尽管有效的 DevSecOps 在质量控制、增强合作及效率方面的优势巨大，但是，DevSecOps 与其他任何东西一样，跟人有关。

即使是在最好的团队中，有时候人和人之间也有摩擦。给团队成员介绍一种组织他们合作的新方法（跟他们习惯的工作方式有显著的不同），那么会在以下方面产生问题：

• 学习如何适应开发人员的工作方式，不要进行大规模的重组。DevSecOps 的实施可以减少代码中的错误，但是，可能会遭受来自实际实施这些代码人员的阻力。这被视为不信任开发团队，并会招致不满。

通过沟通和妥协解决这类问题。像托管服务的选择这样简单的事可以巧妙地解决。开发人员可能希望使用“开发者云（developer cloud）”托管服务，即一个对开发人员友好的产品生态系统的服务，如：Salesforce 所有的Heroku或广受欢迎的 DigitalOcean 云托管。

确保开发人员希望使用的每个服务都是安全的，这给安全团队带来了很多工作。这可能导致安全专家选择经过验证的真实服务。对特定的以开发人员为中心的服务进行安全审核，然后再使用所述服务是一种妥协的方法。

• IT 部门不同团队之间的信任问题导致合作不理想。与适应开发人员类似，组织的每个部分都有其他团队的意见。偏见会导致安全团队的成员不信任开发人员或开发人员不信任处理基础设施进程的人员。

对于 DevOps 来说，这些都不是新鲜事，并且和其他团队的合并会产生更多的问题。这就需要来自不同学科的团队成员并肩合作了。把来自不同团队的成员整合到新的交叉团队中，可以形成社区。

• 过度依赖人工智能和自动化使人类不再尽职。随着 DevSecOps 获得成功，自动化软件也在迅猛发展。不管听哪个 DevOps 领域中专家的演讲，我们都会听到对自动化过度依赖的警告。总有一天，整个过程可能都由机器完成。就目前来讲，人类仍然是 DevSecOps 进程的运动机制。

必须缓慢而谨慎地完成自动化。如果一台自动化机器出问题，那么，整个系统会受到影响。从基础开始做，然后从那里开始。

这些是可以克服的难题。部门间信任的缺乏和糟糕的合作正是 DevSecOps 要克服的问题。只要有足够的时间和坚持，就会自然而然产生需要的信任。实施新流程的一个经过验证的真正策略是，让团队以渐进阶段的方式轻松地进入 DevSecOps，避免超负荷工作。

检查与供应商的关系

借助 DevOps 的安全部分，更容易实施预防措施。这是预先检查和持续保持警惕之间的不同，要不就等着出现混乱局面失控，直到那时才来尝试解决问题，但通常为时已晚。

在当今互相交织的互联网上，大量的安全风险来自第三方合作伙伴，他们提供服务并和我们的组织共享数据及资源。我们的公司和网络的强大程度取决于最脆弱的链接部分。最近有个例子，跟托管服务有关，是谷歌云断电了，引起了大规模的断网。像油管、Gmail、Snapchat 和 Shopify 等等公司都受到了严重的影响。

为了便于理解，我们来看看对Shopify的影响。因为整个Shopify网络集中在一个主机（谷歌云）上，并且很显然没有好的后备计划，这次停电使 175 个国家或地区的 80 万家商店销售停滞的时间长达 7 小时。最可怕的是，对于那些受托保护网站的人来说，这次停电可能是一次黑客攻击，谷歌服务器被迫下线，而恶意软件在联盟商店的客户数据中漫游，挖掘其能找到的任何内容。

出现这样的事故使我们主要关注托管供应商的正常运行时间/停机时间，将其视为关键网络安全指标。我们需要知道供应商的电话号码。根据https://hostingcanada.org/ \l web-hosting-reviews">最近对网站托管运行时间的调查表明，小型公司无法接受任何低于 99.9%的运行时间，更不用提像 Shopify 这样上万中小企业所依赖的大企业了。

前面提到的例子说明了供应商关系中固有的危险，这只是机会世界中的一个孤例。想一想我们网站所依赖或允许访问的每个供应商。其中任何一个都可能成为严重的安全问题。我们是否做好了准备？

理解 DevSecOps 规则

要在组织中使用 DevSecOps 时达到最高水平的生产效率，可以尝试采用以下方式：

• 从一开始就为每个人集成最佳网络安全实践，如定期更新软件和硬件、渗透测试和对员工进行 VPN 最佳实践（虚拟私有网络）的强制性培训，他们在任何时间连接互联网都要通过 VPN。

• 优先考虑安全性。不要让人为错误或疏忽毁掉我们。DevSecOps 存在的原因是经常发生人为错误。目标是把错误的数量控制在限定范围内，并在错误发生后，把协议设置好以捕捉错误。

• 监控所有的软件并持续检查代码，以便我们修补安全漏洞，并力争比黑客领先一步。这包括定期实施代码依赖性检查，如：OWASP依赖性检查。

• 把任务分解成可以管理的小任务块。每个任务越小越简单，整个过程就越可能正确地完成。

• 设置一键式合规性报告，以便我们有一份清楚记录软件开发流程中每一个步骤的日志。

• 鼓励 IT 部门不同团队成员保持联系并讨论他们所担心的事。极力地确保每天由团队来引导话题，就像强制要求流程中不同团队之间召开会议一样。

与新社区一起成长

DevSecOps 成为主流是该进程每个支持者所设想的。一个新兴社区正处于组织创新的最前沿。

【DevSecOps 的每个支持者都希望，该流程能够成为主流。一个新兴的社区正将自己置身于组织创新的最前沿】

DevSecOps日（DevSecOps Day）是一个为期 1 到 2 天的全球系列会议，有助于教育、发展和探索开发安全即代码的概念。随着这个运动的发展，社区也增强了学习和改进的能力。InfoQ参加了一场伦敦会议，发现它对组织大有裨益。

随着这一运动的发展，会涌现出更多的组织，他们为企业家、小企业和大企业带来更多的活动和学习机会。

是时候演进了

如今的现实是，网络安全威胁无处不在。任何打算在网上生存和发展的组织都需要为此做好准备。这种准备工作的主要部分是站在 DevOps 思想的最前线，那就是 DevSecOps。

这种理念的转变确保组织有恰当的协议来有效地评估、预防、抵抗或抵御威胁。适当的 DevSecOps 实施可能是我们今年要做的最重要的事。

作者介绍：

Sam Bocetta 曾是安全分析师，作为网络工程师为美国海军服务多年。目前，他处于半退休状态，为公众提供有关安全和隐私技术的教育。Sam 的很多工作涉及渗透测试弹道系统。他分析我们的网络寻找入口点，然后根据自己的发现出具安全漏洞评估。此外，他帮助计划、管理和执行复杂的“道德”黑客行为，以识别漏洞并减少美国海军使用的企业网络 （包括在陆地上和海上使用的）的风险状况。

他的大部分工作集中于识别、预防应用程序和网络威胁、减少攻击矢量区域，消除漏洞和一般性报告。他能够发现弱点并制定新的策略，以加强我们的网络来抵御一系列网络威胁。Sam 与架构师和开发人员密切合作，确定对跨应用程序识别的漏洞的缓解控制，执行安全评估以模拟各种威胁的策略、技术和过程。请通过Linkedin账号联系他。

原文链接：

How to Seamlessly Evolve DevOps into DevSecOps