1.2　DevOps中的安全

“船泊港湾固然安全，但这不是造船的初衷。”

——John A.Shedd

要想在竞争激烈的市场中立于不败之地，组织需要行动迅速，勇于承担风险，还要以合理的成本去运营。这些组织中的安全团队在帮助组织取得成功的同时，还要充当公司资产的安全网。安全团队需要和构建公司产品的工程师及经理紧密协作。当公司接纳DevOps时，安全文化也要改变，同样要接纳DevOps，这一切都要从聚焦于客户开始。

DevOps和它的前身——敏捷宣言（Agile Manifesto，链接1.1）[1]与戴明十四法（Deming’s 14 principles，链接1.2）都有一条共同的特质：聚焦于更快地将更好的产品交付给客户。成功的策略无一例外都是从聚焦于客户开始的（链接1.3）：

“我们不在乎竞争对手，我们以客户为中心。一切从客户需要出发并回馈给客户。”

——Jeff Bezos，Amazon

在DevOps中，产品流水线上的每个人都以客户为中心：

•产品经理度量参与度和留存率。

•开发人员度量工效和易用性。

•运维人员度量上线时间和响应时间。

客户是公司关注的焦点。每个人的目标都要向客户的满意度这个指标看齐。

与此形成鲜明对比的是，许多安全团队却着眼于以安全为中心的目标，比如：

•某种安全标准的合规性。

•安全事件的数量。

•生产系统中未修补的漏洞数量。

公司对外聚焦于客户，而安全团队对内聚焦于自身的环境。一方想提升组织的价值，而另一方想保护现有的价值。二者对于一个健康的生态系统来说，都是不可或缺的，但若是南辕北辙的目标，则会给沟通和效率造成影响。

在积极考核个体团队的目标和绩效并以此来分配奖金的组织里，每一方都很紧张，都只会关注自己的业绩并无视对方。开发人员和运维人员为了达成目标，在交付可能存在风险的产品时会对安全建议视而不见。安全工程师则会阻止项目使用不安全的技术，并且为了避免那些触碰底线的事件发生而推荐一些不切实际的方案。在这种情况下，双方都有理有据，但就是不能理解和接受对方的动机。

作为一个安全工程师，我从未遇到过对安全毫不在意的开发或运维团队，但我遇到过许多因交付与目标脱节而受挫的团队。一方面，安全团队对产品策略缺乏认识，安排武断的安全审计阻挠特性上线，或者要求难以实现的复杂控制，这些都是和敏捷背道而驰的安全系统的征兆。另一方面，忽视安全团队的经验和反馈的产品团队是风险的源头，这些风险最终损害的只能是组织。

DevOps教会我们，行之有效的策略要求运维方和开发方结合得更为紧密，要打破开发人员和运维人员之间的各种沟通壁垒。同样地，保障DevOps必须从安全团队和他们的工程师伙伴之间的紧密协作开始。安全需要作为服务的一项功能提供给客户，同时安全团队和DevOps团队的内部目标必须保持一致。

当安全变成DevOps不可分割的一部分之后，安全工程师可以将安全控制直接内建到产品之中，而不是在事后强加于产品之上。每个人都有着让组织获得成功的共同目标。目标达成一致，沟通得到改善，数据安全得到提升。将安全引入DevOps的核心思想是，让安全团队采用DevOps技术，将他们的注意力从仅仅保护基础设施转移到通过持续改进来保护整个组织的目标上来。

在本书中，我将这种方法称为持续安全。在下一节，你将会了解如何一步步地实现持续安全，从简单和容易实现的安全控制开始，逐步完善安全策略，直到其覆盖整个组织。