服务威胁工程：从站点可靠性工程中获取一页

每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。

SRE 是一种现代方法，用于管理运行复杂、动态软件部署所固有的风险——停机、减速等风险。

云原生计算远远超出了基于 Kubernetes 的基础架构，以汇总许多现代最佳实践方法来大规模构建、运行和利用软件资产。然后，云原生方法将这些实践从云扩展到整个 IT 环境。

此最佳实践列表中包含属于站点可靠性工程 (SRE) 类别的最佳实践。SRE 实践的核心是一种现代方法来管理运行复杂、动态软件部署所固有的风险——停机、减速等风险。

遵循云原生方法，我们应该将这些实践扩展到所有软件环境风险，包括 络安全风险。

那么，将 SRE 原则从其传统的对可靠性的关注之外应用于整个 络安全风险会是什么样子呢？

错误预算：云原生 SRE 的关键

要将 SRE 和 络安全联系在一起，我们需要一些背景知识，从服务水平目标开始。

站点、系统或服务（统称为“服务”）的服务水平目标(SLO) 是组织想要针对给定用户旅程测量的任何可靠性维度的精确数字目标。

例如，SLO 可以量化服务的可用性、在用户界面上提供给用户的信息的延迟或新鲜度，或其他对业务很重要的关键性能指标。

基于此 SLO，运维团队及其利益相关者可以基于事实判断是增加服务的可靠性（从而降低其成本）还是降低其可靠性和成本以提高提供服务的应用程序的开发速度。

而不是以完美为目标——100% 的 SLO 没有反映任何问题——真正的问题是你应该以完美的可靠性为目标还有多远。我们称这个量为误差预算。

错误预算表示在给定时间窗口中由小于 100% 的 SLO 目标导致的允许错误数。换句话说，这个预算代表了在用户对服务不满意之前，特定服务可以累积的错误总数。

最重要的是，运营商的目标绝不应该是完全消除可靠性问题，因为这种方法既成本太高，又耗时太长，从而影响组织快速部署软件和大规模运行动态软件的能力（两者是核心云原生实践）。

相反，运营商应该在成本、速度和可靠性之间保持最佳平衡。错误预算量化了这种平衡。

将 SRE 带入 络安全

SRE 最基本的推动力是可观察性。运营商必须拥有关于其权限范围内的系统和服务行为的足够准确的实时数据，以执行量化 SLO 所需的计算以及这些服务与维护它们的距离。

络安全工程师需要针对他们必须管理和缓解的威胁具有相同的可观察性。我们称这种特殊类型的可观察性基于风险的警 (RBA)。

RBA 取决于风险评分。每个观察到的可能与 络安全工程师相关的事件都必须计算其风险评分。

任何事件的风险评分是风险影响（威胁相关危害的影响有多严重）、风险信心（工程师对事件是威胁的积极指标的信心）和风险的乘积量化受威胁用户或系统的关键程度的修饰符。

然后，RBA 通过利用组织选择的安全框架（例如 MITRE ATT&CK）来量化每个事件的风险评分。

RBA 为 络安全工程师提供他们做出明智的威胁缓解决策所需的原始数据，就像以可靠性为中心的可观察性为 SRE 提供缓解可靠性问题所需的数据一样。

介绍威胁预算

一旦我们有了可量化的实时威胁度量——威胁遥测，就可以为 络安全工程师创建一个类似于 SRE 的模型。

我们可以设定威胁级别目标(TLO)，这将是 络安全团队面临的任何特定威胁的精确数字目标。

同样，我们可以创建威胁预算的概念，该概念将反映在给定时间窗口内未缓解的威胁数量，该数量是由低于 100% 的 TLO 导致的。

换句话说，威胁预算表示在相应的妥协对服务用户产生不利影响之前，特定服务可以随时间累积的未缓解威胁的总数。

这里的基本见解是威胁预算永远不应该是 100%，因为完全消除威胁会太昂贵并且会减慢软件工作量，就像 100% 错误预算一样。

因此，一些低于 100% 的威胁预算将反映成本、时间和妥协风险之间的最佳妥协。

我们可以将这种方法称为 TLO 和威胁预算服务威胁工程， 类似于站点可靠性工程。

服务威胁工程的意思是，基于 RBA， 络安全工程师现在拥有一种可量化的方法来实现最佳威胁缓解，该方法考虑了所有相关参数，而不是依赖于个人专业知识、部落知识和对 络安全有效性的不合理期望。

尽管 RBA 使用了风险一词，但我还是使用了威胁一词来区分服务威胁工程和 SRE。毕竟，SRE 也是关于量化和管理风险的——除了 SRE，风险与可靠性相关，而不是与威胁相关。

因此，服务威胁工程不仅仅类似于 SRE。相反，它们都是管理两种不同但相关的风险的方法的例子。

络安全妥协肯定会导致可靠性问题（勒索软件和拒绝服务是两个熟悉的例子）。但这个故事还有更多。

运营和安全团队的关系一直很紧张，他们在具有不同优先级的相同系统上工作。然而，将威胁管理提升到与 SRE 相同的水平可能有助于这两个团队在管理风险的方法上保持一致。

因此，服务威胁工程针对的是继续困扰 DevSecOps 工作的组织挑战——这是许多组织应该欢迎的战略优势。