第四部分：安全的首要位置软件团队通常会对严重的错误、蹩脚的设计和糟糕系统性能做出及时的响应。因为这些问题既明显又尖锐。而作为“硬币另一面”,他们对于那些所谓的“技术债”，则只是通过一些预防性工作予以滞后解决，或甚至挤压下来直到将来失控，并造成更大的问题。因此，经验丰富的DevOps团队通常应当把安全问题视为“头等公民”，放在急需解决的首要位置，而不能将它们放积压到To-Do（待办）列表中，甚至永远不去解决。既然一个团队能够重视应用中的漏洞以及安全性，那么他们自然会在开发和发布过程中采取各种恰当的安全措施。我们下面来详细研究一下这些安全实践。 密码的安全管理· 与生产系统有关的所有密码信息（密码、私钥、或攻击者可以利用的任何敏感信息）都应存储在安全且高可用的库中，并且只有被授权访问它们的系统，能在恰当的时间段所访问到。
· 不允许库管访问到具体的密码值/信息。
· 确保密码根据既定的时间表自动变更，进而控制其有效时间。
良好的安全习惯下面是以“安全为中心”的团队时常践行的一些安全要点：· 最小权限的原则可以适用到任何地方。机器也好、人员也罢，只能访问他们适合访问的资源。一旦有不恰当的访问发生，应立即撤销其对应的权限。
· 漏洞扫描会自动运行在所有相关的第三方特征库之上。如果有最新的更新，则应立即升级各个漏洞库。
· 无论是否检测到相关的漏洞，都应保持第三方特征库为最新。因为某些修补程序可能仅适用于特征库的最新版本，因此升级与更新将有助于避免出现重大的兼容性问题。
· 针对潜在攻击因素，应定期对应用程序（及其CI/CD环境）进行渗透测试。这些测试有时甚至可以作为CD管道的一部分，被自动化工具来完成。当然也可以通过定期的人为干预，如白帽子黑客，来增强效果。
· 将应用与信息安全方面的培训，放到所有新入职的开发人员的培训计划中，并让他们得到持续教育。
· 为产品代码的变更开发工作流程，其中包含：攻击向量因素和安全策略违规等信息准确检查与披露。例如，某个团队使用着GitHub PR(PullRequest)，那么提交者和审阅者都应使用同一个PR模板来进行编写。
全员致力于安全速度在一些公司里，安全团队常背负着“挡路人”的名声。而实际情况却是：在整个开发周期中，安全团队往往过迟地获悉新的系统与计划。而无论开发进程是多么的流畅与快速，安全团队始终有责任确保整体业务，不会因为新技术的部署而面临风险。安全审批是需要时间的，特别是有大量项目并发进行的时候，当然，各种不满的情绪很容易滋生。在一些“失常”的组织中，开发人员甚至会秘密地部署那些未经批准的应用，以颠覆安全团队的权威，从而使事态更为恶化。因此，高绩效的组织应当从上述问题中认识根源，即：安全团队被放置在了开发流程的错误位置。将安全放到左边经验丰富的团队往往在开发新应用的早期阶段就直接考虑到安全问题，让安全团队去检查他们的架构和技术选择，并努力在流程中“将安全放到左边”（详见上一篇）。如此，在大量代码被编写之前，安全团队就能提早发现各种严重的问题，并能尽早解决之。同时，此举也会减少开发人员和安全人员之间的争论，塑造出和谐的团队关系。乍看来，“将安全放到左边”在短时间内会是一项吃力不讨好的选择。但是如果从整个开发的生命周期来看，早期的安全评估势必会避免主要架构在后期出现漏洞时的返工成本。实际上，早期的安全审查不但能降低开发项目的风险，还能为后续的发布周期降低成本。第五部分：自动化对于DevOps团队来说，他们已经能够实现QA、打补丁、部署、升级、回滚和灾难恢复的自动执行，并达到了前面提过的“不犯错式快速推进”的效果。而对于高绩效的DevOps团队来说，他们还应当将安全性纳入现有的自动化规划之中，在不增加不当风险的前提下，实现快速的发布功能。 人类只做其最擅长的事经验丰富的DevOps团队不仅能够最大限度地发挥系统自动化，还会持续寻找那些将人类重复执行的任务转化为自动化的机会。而安全性恰好就属于这种自动化转化的范畴。当然，在安全开发中也存在着一些仅适合人类完成方面。例如：在新的应用程序被推出之前，以及在管理现有的应用程序时，安全团队都是审查和判断授予各项权限的最佳选择。尽管有许多高效的自动化工具可用于渗透测试，但是人类总能找到去攻击软件或系统的更好、更新的方法。增加自动化，降低人数在大多数高绩效的DevOps团队中，一旦他们将持续集成（CI）的管道设置为以自动化的方式将应用程序推送到下个阶段、或是生产环境，那么操作人员就不必再参与应用程序的后期升级了。同样，只要应用程序的安全政策没有发生变更，且不需要增加新的权限，那就不需要让安全人员作为审批的一个环节，也不可能造成瓶颈，甚至影响到应用的推进或上线。他们既然已经人工批准了某个应用的注册，那么只要该应用程序在运行时不需要更多的权限去访问资源，升级应该被完全自动化。当然，在不影响安全性的情况下，实现自动升级就需要在CI管道中设置更多的任务，包括：扫描第三方软件库和运行中的CVE（Common Vulnerabilities and Exposures），检查应用程序的代码是否存在着安全漏洞，以及是否进行渗透测试等。这些自动化的配置虽然可能会需要一定的时间，但当它们被相互累计起来时，其成本、风险以及整体所花费的时间，都会比人工进行要节省得多。自动化安全随着数据中心自愈能力和灾难恢复（DR）技术的发展，自动化安全沿着如下的发展路径，逐步缓解了运营中可能出现的各种复杂故障：· 维护一个需要手动启用的备用站点。
· 对于手动站点的切换流程进行定期的演习与测试。
· 完全自动化地切换到另一站点。
· 多个站点或区域同时运行，在出现故障时，能自动在系统中同步所有的差异。
· 通过运用混沌工程（chaos engineering）原理故意造成基础设施故障，进行测试。
自动化防范入侵自动化不但能协助高效的安全团队做出及时的故障响应，还能防范各种入侵行为的发生。众所周知，攻击者入侵系统是需要时间的。如果某个关键数据库的帐户密码需要每90天手动更改一次的话，那么他们将有几个月的时间去试图破解它。但是，如果该数据库的密码每天都自动更改（轮询的方式），或更为频繁的话，那么他们破解密码的能力将大幅降低。自动化响应入侵另一个防范入侵的关键因素是：定期自动化重构基础设施。即：通过虚拟机技术、和自动化进程，可以定期将服务器快速地恢复到已知的良好状态，而不产生任何的宕机时间。在许多组织内，各种自动化响应流程在检测到入侵发生时，就启动了自动恢复的进程，所有密码被轮询一次，而所有相关的“可调用”组件（如虚拟机、容器等）也被重新创建到过去已知的良好状态。上面我们提到过，应当对灾难恢复方案进行持续演习那样，如果自动化流程也能够持续测试与执行的话，那么其相应的风险也会大幅降低。第六部分：技术采用技术发展得如此迅速，以至于安全人员常被开发人员贴上“过时策略的执行者”和“拒绝采用现代化工具”的标签。如今，DevOps使用到了各种SaaS产品，支持CI、CD、配置管理以及各种编排的各种开源解决方案。安全团队要想适应该环境，并流畅地开展工作，就必须拥抱这些新的系统与技术。 安全理念的变迁劣等的安全团队会负面地看待新的技术。对他们而言，现代化的工具代表了不断增加的威胁因素、潜在的漏洞和受攻击的可能性。而优等的安全团队则持有乐观的态度，即：如果能安全地采用新的工具，组织的业务不但能够运行得更快，而且组织也会更为安全。传统的IT安全理念建立在静态的本地数据中心和已知资产明细的基础上。在系统边界处，外围防火墙作为主要的防御措施，抵御着各类攻击。而内部安全系统则专注于管理组织里的人员与机器。LDAP、Kerberos和ActiveDirectory是主流的管理身份与角色的工具。新添置的机器和新雇用的员工需要被手动配置到系统之中。如今，现代化的组织则使用微服务、容器、编排器（orchestrators）和无服务器技术来管理动态的基础架构。显然这些与传统的安全理念并不相称。新的安全理念不再专注于“守住”生产环境中的资产，而是要更好地且“安全地支持企业的快速推进”。新技术提高了安全性新的安全保护措施，有助于各种安全流程跟上IT系统的发展节奏，并能防止影子IT的威胁。例如，BeyondCorp是Google的一个安全模型，它能够将各种内部应用转换为典型的部署模型。Google并没有将那些敏感的应用放置在VPN后面，而是将它们部署到了公网之上。对于这些应用的访问，完全取决于访问者的身份，而并非他们所处的网络。这就颠覆了传统的IT策略，并为Google和使用它的其他组织提供了巨大的速度与灵活性。Conjur同样在其产品中也用到了：将身份识别应用于所有的动态计算资产与用户的安全理念。其他一些以开发人员为中心的技术，也从根本上减少了开发者所需要访问的敏感资产数量。它们有助于更好地实现职责分离。例如，像Pivotal Cloud Foundry之类的PaaS系统，和像Kubernetes这样的部署编排器，能为开发人员提供完全隔离的、且独立于系统操作的清晰视图。无服务器技术同样能够大幅提高系统的安全性。由于使用虚拟机或容器的开发人员，能够“近距离地”接触到操作系统，这给资产和敏感数据带来了风险。然而，在无服务器或“功能即服务（FaaS）”的模型中，这些资产是完全无法被访问到的。因此，对于大多数安全团队来说，与其去监控并保护开发人员可能访问到的资产，不如直接不让他们所“知晓”。旧思维与新思想传统的IT安全模型着眼于：确定哪些资产需要被控制，然后构建出结构来“守住”它们。因此，所有工作流程都基于这种集中式的管控模型。而新的方法则假设：手头已经没有一套完整的系统资产对应图表了，应当使用的简单而有效的准则。即：每个实体都必须具有身份，必须通过策略清楚地传达权限的更改，明确职责的分离，通过自动化的实现提高业务的推进速度。借助这一全新的理念，现代化的DevOps团队将能够在不牺牲安全性的情况下，保持高速的交付能力。而且这种新的理念、方法和模型势必会被所有的组织所接受。【原标题】DevOps Security at Scale (作者: Brian Kelly)原文链接：https://www.conjur.org/blog/2018/03/06/security-as-first-class-citizen.html
