安全性——“DevOpS”中的 S

阿姆斯特丹DevOps Days 的第一天， Schuberg Philis 安全官 Frank Breedijk 在演讲中介绍了安全性和DevOps 之间的摩擦，以及如何协作以避免这些问题。演讲中，他举出的例子包括自动化安全测试及其环境、缩小安全审计范围使其仅针对相关系统组件，或是让安全性补丁在产品变更队列中能够享有更高顺位。

Frank 强调了安全性与以下两项因素之间的矛盾：开发方面在安全性上缺乏投入（他们更注重功能的交付），而且还缺乏来自运营方面的支持——运营方面认为安全性是其常规工作之上的不必要负担。最后，由于 DevOps 看起来缺乏职责分离，而且令产品变更频率上升，安全方面的人员往往将其视作一种风险。Frank 认为真正的 DevOps 文化应该倡导协作——不仅仅是开发和运营之间的协作，还要提倡他们与安全方面的协作（因此，他开玩笑道，DevOpS 中的 S 应该与其他首字母缩写中的 S 具有相同涵义，例如 Http/HttpS, Imap/ImapS）。

要增加各方之间的协作，可以阐明安全性要求，并增加系统变更的透明度，从而减少对安全威胁的恐惧。例如，针对 PCI、DSS 和 SOX 审计的一种常见误解，是认为需要审计整个系统，而实际上只有部分组件需要经过审批。另一方面，产品变更的交付频率一般会因为采用 DevOps 而显著增加。回滚将不再是可行的选择，而随着发布高优先级安全性修订能力的增加（在产品变更队列中插队），前向修正（fixing forward）将得以实现。

Frank 认为，对安全性来说，高交付频率并非注定成为问题。当对所有人可见的时候，较小的变更会更容易进行安全性分析和测试；再加上交付窗口数量的增加，将允许更快地修复产品中的安全性问题。最后，专注于基础架构配置管理，以管理诸如动态产品环境等内容，也将有助于基础架构安全性测试。例如，自动检查用于配置新机器的 OS 镜像，以及所有需要的安全性补丁。综上，安全环境和测试的自动化将变得更容易，而后便能够轻松地整合到交付流程中。

对于功能导向敏捷开发团队和产品拥有者的心态，Frank 也指出了将安全性要求纳入其中所面临的困难。为了满足这些要求所需的工作，需要在开发迭代中进行规划，而诸如通过修复安全性缺陷以减少技术债务的工作，应该与功能交付得到同等奖励。

最后，Frank 表示真正的 DevOps 文化应该拥抱安全团队，并调整激励措施，从而让为了交付功能性变更而工作的人们也能够看到安全性和运营方面的要求。安全团队不应该被看做交付变更的瓶颈，而是一种“免疫系统”——侦测威胁并提供解决它们所需要的洞见和工具。

与大会其他内容一样，这一演讲通过流媒体进行了直播，其讲稿也已经发布在网上。

查看英文原文： S is for Security