安全的DevOps –看起来很简单

DevOps安全故事看似简单。 它基于一些基本，直接的想法和实践：

较小的发行版更安全

这些想法之一是，与大爆炸的更改相比， 较小的，增量的和更频繁的发行版更安全并且所引起的问题更少。 说得通。

较小的版本包含较少的代码更改。 更少的代码意味着更少的复杂性和更少的错误。 风险也较小，因为较小的发行版更易于理解，易于计划，易于测试，易于查看，并且在出现问题时也易于回滚。

通过留意代码的高风险区域的更改，更容易捕获安全风险：处理敏感数据或安全功能或其他重要管道的代码，新API，错误处理。 例如 ， 在Etsy上 ，他们在评论，笔测试或其他方面识别此代码，对其进行哈希处理，并在更改时自动通知安全团队，以确保更改是安全的。

更频繁地更改代码还可能使坏人更难理解您的工作并在系统中发现漏洞-在更改系统时间和坏人之间利用临时的“ 蜜月效应 ”找出如何利用其中的弱点。

而且更改频率越来越高，迫使您简化和自动化应用程序部署，使其可重复，可靠，更简单，更快，更易于审核。 这有利于变更控制：您可以更加信任自己安全而一致地进行部署的能力，可以跟踪进行了哪些更改，进行了哪些更改以及何时进行了更改。

如果发现问题，您可以快速部署应用程序补丁。

“ ...能够快速部署是我们的第一安全功能”

Web应用程序安全性的有效方法 ，Zane Lackey

通过基础架构即代码实现标准化的运营环境

DevOps将“ 基础架构视为代码 ”：基础架构配置以与应用程序代码相同的方式编写和管理的代码定义，并使用自动化工具（如Puppet或Chef）进行部署，而无需手动进行。 这意味着您始终知道如何设置基础结构以及设置是否一致（不再需要Configuration Drift ）。 您可以证明进行了哪些更改，由谁进行更改以及何时进行更改。

如果发现问题，则可以快速部署基础结构更改和补丁程序 。

您可以使用敏捷开发人员所依赖的相同类型的自动化单元测试和集成测试套件来预先测试配置更改，包括安全性测试。

而且，您可以轻松地设置与生产相匹配（或更接近匹配）的测试环境，这意味着您可以对所有测试进行更彻底，更准确的工作。

自动化连续安全测试

DevOps建立在敏捷开发实践的基础上，例如持续集成中的自动化单元/集成测试，以在持续交付 /持续部署中包括更高级别的自动化系统测试 。

您可以使用Gauntlt之类的工具来进行自动化的安全测试，以“对您的代码卑鄙”，以受控方式在系统上运行固定的攻击。

向Devops注入安全性的其他方法包括：

1. 通过自助式静态分析为开发人员提供有关安全问题的即时反馈：在每次签入时或在编写代码时直接在其IDE中运行“静态分析”扫描。
2. 帮助开发人员编写自动化的安全性单元测试和集成测试，并将其添加到持续测试管道中。
3. 作为构建或持续集成的一部分，使用OWASP的Dependency Check之类的工具自动检查开放源代码和其他第三方软件依赖项，以突出显示具有已知漏洞的依赖项。

使用自动测试的快速反馈循环意味着您可以更早地发现并解决更多安全问题。

操作检查和反馈

DevOps将反馈循环的思想扩展到了从开发到生产的整个测试过程中的开发人员，从而允许（并鼓励开发人员查看生产指标 ，并使开发人员，操作人员和安全人员全部监视系统中的异常情况，以发现性能问题和可靠性问题，并安全问题。

在生产中的部署中（以及在启动/重新启动之前）添加自动的断言和运行状况检查 ，以确保满足关键的操作依赖性，包括安全检查 ：确保配置正确，应关闭的端口已关闭，应打开的端口已打开，权限正确，SSL设置正确...

甚至杀死不符合要求的系统进程（或者有时只是为了确保它们正确地进行故障转移， 就像在Netflix那样 ）。

人们互相交谈，共同解决问题

最后，DevOps是关于人们在一起交谈并共同解决问题的。 不仅仅是开发人员与企业/客户交谈。 开发人员与操作人员交谈，操作人员与开发人员交谈以及每个人都与安全性交谈。 共享想法，工具和实践。 尽早将操作和安全性引入循环。 开发人员，操作人员和安全人员在计划，事件响应以及在根本原因分析会议和其他评论中的共同学习中共同努力。 跨筒仓建立团队。 建立信任。

使SecDevOps工作

这些人正在做的事情，他们走的路很令人兴奋。 它为开发人员和安全性以及操作人员合作提供了一种新的，更有效的方式。

但是有一些警告。

安全的DevOps 需要强大的工程学科和技能 。 DevOps工程技术仍然供不应求。 信息安全（尤其是appsec）技能也是如此 。 精通DevOps和Appsec的人只是这些人才的一小部分。

在配置管理和监视之外，工具是有限的–您可能不得不编写大量自己需要的内容（这很快导致技能问题）。

为了将其应用于受监管的环境，强制执行职责分离以及监管机构将敏捷视为“ A Word”（因此，您可以想象他们对开发人员在持续不断地推动生产变更的想法），还需要做更多的工作部署，即使他们正在使用自动化工具也是如此）。 少数人正在Google针对DevOps的讨论小组中为受监管行业的经理和审计师探讨这些问题，但到目前为止，提出问题的人多于提供答案的人。

使开发人员，操作人员和安全人员一起协作并跨开发，操作人员和安全人员进行协作可能会彻底改变组织的结构和文化。

安全的DevOps实践和想法本身不足以使系统安全。 您仍然需要所有的基础知识。 即使他们逐步发行软件并运行大量自动化测试，开发人员仍然需要了解软件安全性和设计安全性并遵循良好的软件工程实践。 无论他们是否使用“基础架构即代码”，Ops仍必须设计和设计数据中心，网络以及基础架构的其余部分，以确保安全可靠，并以安全负责的方式运行事物。 安全仍然需要对每个人进行培训并跟进他们的工作，进行扫描并进行笔测试和审计，以确保所有这些操作都正确完成。

安全DevOps并不像看起来那么简单。 它需要纪律严明的安全开发和安全的操作基础，良好的工具和罕见的技能以及高度的组织敏捷性和信任与协作的文化。 这就是为什么今天只有少数组织这样做的原因。 对于大多数组织来说，这不是一个短期的答案。 但这确实为运维和安全性提供了一种方法，以跟上敏捷开发的高速发展 ，并使其自身变得更加敏捷，并有望变得更加有效。

翻译自: https://www.javacodegeeks.com/2014/04/secure-devops-seems-simple.html