安全的悲剧消逝于 DevOps 的熔炉

安全早已不同于往昔。或许它一直如此，只是因为我年轻时的理想主义逐渐消磨，才显得有所不同。

安全工作一分为二。一条路径上，我们努力保障组织的安全：阻止恶意行为者，保护数据与资产，使用户免受威胁，甚至免受自身失误的影响。另一条路径则是合规：确保组织满足监管、合同及其他标准。在这两条路径上，我们都在管理风险——泄露与停机的风险，或是监管罚款的风险。

安全的悲剧是公地悲剧的映照。引自维基百科：

大多数安全合规要求的设计初衷是降低安全风险，至少在纸面上如此。但随着时间推移，我们看到一项又一项标准、一部又一部法规，将风险与合规相互剥离。合规标准的本质决定了组织难以按照自身风险量身定制安全措施。我并不是说情况总是如此，但在很大程度上确实如此，尤其是在组织规模不断扩大时。没有任何证据表明，对已启用 MFA 或其他当前常用条件限制的用户，每 90 天强制重置一次密码能够提升安全性。发明密码复杂度要求的那个人确实为此感到后悔，并表示这些要求并不奏效。对于要求对云服务商中的所有存储卷启用非默认加密，既无证据支持，也无可靠的科学依据。

安全是一种共享且有限的资源。我们的预算有限，安全专业人员数量有限，非安全岗位员工在牺牲自身其他目标的前提下能投入安全工作的时间也有限。越是向合规倾斜，可用于安全的份额就越少。合规与安全的契合度越低，真正降低安全风险的举措就越少。

这就是安全的悲剧。我们把风险与合规剥离开来，使不合规本身成为风险。真实的重大风险与合规脱节越深，合规制度就越僵化，可用于防御的安全资源就越少，其他团队对安全工作的支持也越少。

我与Chris Farris的一次交谈中就出现了一个很好的例子。大意如下：

开发人员其实很在意安全，让他们恼火的是合规。帮助他们把应用做得更安全，他们就会支持你。而要求他们在周末停机 4 小时、只为满足某位合规教条主义者的要求而重建带加密的数据库，那只会激怒他们。

我并不是说所有合规要求都是愚蠢的规定，但确有一些合规规定很愚蠢，而将脱离风险的良好规定错误套用，则更是愚蠢。

DevOps 成为安全未来的熔炉，因为在云与 DevOps 的世界里，各个应用团队要对整个技术栈负责，其中包括大部分安全工作。新的服务器、网络和防火墙，只需一次 git commit 和若干 API 调用即可创建。这也让这些团队承担起管理自身安全与合规的更大责任。我们依然拥有集中化的安全职能和共享的安全资源，但在最前沿，我们无疑更加依赖 DevOps 团队。我们无法为云构建一个庞大的 DMZ。内部网络与外部网络之间的界线，已不可能再被划入千篇一律的区域。许多基于云原生服务构建的应用甚至不再拥有网络，而是依赖由应用团队通过基础设施即代码推送的、以 JSON 编写的 IAM 规则和资源策略。

因此，我近期不少以云和 DevOps 为重点的合规项目，更多是先把安全做好，然后再想办法写出一份报告，让它看起来符合合规条文的字面要求——尽管实际上并不符合，即便实际做法更安全。

有两种可能的解决方案。

第一种是修订安全标准，使其更契合云与 DevOps，并减少愚蠢或不适用的规定。这方面的工作已在推进，但我逐渐认为，这需要一代人的转变，而我们没有时间等待。我们不应放弃，但也不必等待。

另一种是借助自动化，尽可能把安全与合规的负担从个人身上卸下，同时仍给予他们快速构建的自由与掌控权。我并不是建议缩小整体的安全投入，而是主张利用自动化及其他技术，减少个人在低价值事务上耗费的精力。

这关乎有限资源的时间与重心。说到底，哪一项更有价值……一次出色的渗透测试，还是一次合规审计？现在再看看您在渗透测试上的花费，以及您为一次审计所支付的费用。