透过镜子:安全性和 SRE

现在是时候对系统安全性采取更积极主动的方法了。以下是混沌工程如何发挥关键作用。
432 位读者喜欢这篇文章。
Through the looking glass: Security and the SRE

Opensource.com

“我们不能再在无状态世界中设计依赖状态的安全。”——Rinehart

“我们形成假设,但我们从不检验它。”——Bergstrom

在过去的几年中,DevOps、混沌工程和站点可靠性工程 (SRE) 在全球工程界发生了基础性的转变。安全工程学科逐渐通过 DevSecOps、坚固的 DevOps 和其他名称变体进入 DevOps。本文的目的是分享我们在旅程中收集的见解,并挑战社区以不同的方式思考安全系统的设计方式,本文重点关注将混沌工程和 SRE 应用于网络安全领域。

以不同的方式思考信息安全的需求至关重要,因为分布式计算有可能对安全性产生破坏性影响。许多组织今天使用的方法、能力和工具缺乏在现代工程生态系统中保持同步所需的安全特性和客观衡量标准。除非从一开始就将控制和监控构建到应用程序的所有层中,否则应用程序将不可避免地无法保持安全。

就像建筑物周围的栅栏一样,基本的安全控制仅起到威慑作用:正如栅栏很容易被突破一样,凭据和访问权限也很容易获得。一旦入侵者确定了如何获得访问权限,他们就有可能自由地控制整栋建筑物。为了防止这种情况,现代建筑配备了安全门、限乘电梯和内置摄像头系统。最安全的楼层还包括特殊的大堂甚至武装警卫。系统安全的设计应采用类似的方法:限制对 API 路径的访问、允许轻松阻止请求、白名单授权操作和参与者,以及加密所有流量和存储。就像未经授权的访客试图进入建筑物一样,不属于系统的请求应被标记并阻止。

分布式系统和安全中的反馈循环

即使现代软件变得越来越分布式、快速迭代且主要无状态,但当今的安全方法仍然主要是预防性的,侧重于时间状态并依赖于时间状态。它缺乏使现代产品交付取得成功的快速迭代反馈循环。产品环境的变化与用于保持其安全的机制之间应存在相同的反馈循环。安全措施应具有迭代性和敏捷性,足以像它们运行所在的软件生态系统一样频繁地改变其行为。

安全控制通常是在考虑到特定状态(即 Day 0 的生产发布)的情况下设计的。与此同时,围绕这些控制的系统生态系统每天都在快速变化。微服务、机器和其他组件正在启动和关闭;组件更改每天通过持续交付多次发生,外部 API 也在按照自己的交付计划不断变化等等。安全工具和方法必须足够灵活,以适应环境中不断的变化和迭代。如果没有安全反馈循环,系统最终将陷入安全故障,就像没有开发反馈循环的系统会陷入不可靠的运行就绪状态一样。

一种新的工具方法:不仅仅是测试,还要实验

现代分布式系统中不断变化的无状态变量使得几乎不可能了解系统在任何给定时刻是如何工作的。解决此问题的一种方法是通过强大的系统化工具和监控。您可以将安全工具分为两个主要类别:测试和实验。测试是对先前已知结果的验证或评估——或者,用通俗的话说:我们在寻找之前就知道我们在寻找什么。实验旨在获得以前未知的新见解和信息。

站点可靠性工程和混沌工程

“如果你没有尝试过,就假设它是坏的。” ——未知

“任何计划都无法在与敌人第一次接触后幸存下来。”
——赫尔穆特·冯·毛奇

SRE 的两个主要职责是量化对其维护的系统的信心,并提高对系统执行预期能力的额外信心。信心可以通过过去的表现来衡量,并通过了解未来的可靠性来预测。彻底的测试有助于预测未来结果,并提供足够的细节以使其具有实用性和实用价值。系统被测试和实验覆盖得越完整,不确定性和潜在的系统不可靠性就越少。通过足够的测试,您可以在系统可靠性降至可接受水平以下之前进行更多更改。

这些相同的测试和工具方法也适用于安全实验。谷歌的 SRE 的核心原则之一是“实践,实践,再实践。” 重要的是不仅要通过持续和严格的测试来增加系统内的反馈循环,还要确保团队在需要时在操作上做好准备并身经百战。

将安全故障事件注入系统有助于确保对我们已知由人为因素引起的漏洞的弹性。类似于聘请安全顾问闯入高层建筑,我们不断测试我们快速识别和补救隐藏故障的能力。我们努力镜像我们生产安全控制平面中可能发生的或历史上发生过的安全故障模式,并寻找在受控情况下模拟这些模式的方法。SRE、产品团队和安全团队应实施安全控制并编写其服务的代码,以承受潜在的故障并在必要时优雅地降级,而不会影响业务。SRE 的一句常用格言是手动执行一次,第二次自动化它。SRE 的主要功能是致力于自动化以改进系统。通过继续运行安全实验,我们可以主动评估和改进生态系统中的此类漏洞,使其在成为危机情况之前得到解决。

安全 + 混沌工程 = 安全实验

将混沌工程应用于网络安全,历史上一直侧重于人为因素和系统故障如何直接影响系统安全。我们发现安全故障最常见的方式是安全事件被触发时。到那时,通常为时已晚,并且已经造成了损害。我们必须采取更积极主动的方法。将这两个学科结合起来导致了安全实验,我们希望这将成为围绕组织如何构建、运营、工具化和保护其系统发展学习文化的基础。

承认和预测我们在设计安全系统的方式中存在的失败,已经在根本上挑战,甚至瓦解了我们自认为了解的关于系统如何工作的知识。当我们探索这个新领域时,我们将继续分享我们的发现。

如果您有兴趣了解更多关于我们研究的信息或想参与其中,请联系 Aaron RinehartPatrick Bergstrom


[请参阅我们的相关报道,安全混沌工程:网络安全的新范例。]

User profile image.
DevSecOps, Security+Chaos Engineering=ChaoSlingr, Entrepreneur, RuggedSoftware, Innovation Catalyst @UnitedHealthGrp 🤠

1 条评论

感谢 Aaron Rinehart 的精彩文章。我喜欢它)

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。

下载 IT 文化变革的开放组织指南

用于交付无与伦比的业务价值的开放原则和实践。

© . All rights reserved.