解决可用性与安全性，IT 中的持续冲突

冲突的业务需求是一个常见问题——您可以在组织的每个角落找到它，包括在信息技术领域。解决这些冲突是必须的，但这并不总是那么容易——尽管有时有一种新的解决方案会有所帮助。

在 IT 管理中，安全团队和运营团队之间一直存在斗争。是的，两个团队最终都希望拥有更难被破坏的安全系统。然而，安全性可能以牺牲可用性为代价——反之亦然。在本文中，我们将研究可用性与安全性冲突，以及有助于解决该冲突的解决方案。

运营团队专注于可用性……安全团队锁定

运营团队将始终将稳定性和可用性作为重中之重。是的，运维团队也会将安全作为优先事项，但仅限于涉及稳定性或可用性，而不是绝对目标。

它实现了“五个九”的正常运行时间目标，该目标设定了一个令人难以置信的高要求——系统正在运行并且可以在 99.999% 的时间内为请求提供服务。这是一个值得称道的目标，让利益相关者感到高兴。高可用性等工具通过提供系统或服务级别冗余来提供帮助，但安全目标可能会很快阻碍实现“五个九”。

对于安全团队来说，最终目标是尽可能锁定系统，将攻击面和整体风险级别降至最低。在实践中，安全团队可以要求系统必须立即关闭以进行修补，而不是从现在起两周后，降低可用性以便立即进行修补——不管对用户造成什么后果。

很容易看出，这种方法会给运维团队带来巨大的头痛。更糟糕的是，高可用性确实帮助运营团队实现了他们的可用性和稳定性目标，它实际上会让安全团队变得更糟，他们现在必须处理成倍增长的服务器或服务，所有这些都需要保护和监控。

遵循哪种最佳实践？

它在操作和安全之间造成了冲突，这意味着这两个小组在最佳实践和流程等主题上很快就会出现分歧。在考虑修补时，基于维护窗口的修补策略将减少中断并提高可用性，因为修补工作和相关的停机时间之间存在数周的延迟。

但是有一个问题：维护窗口的修补速度不足以正确防御新出现的威胁，因为这些威胁通常在披露后的几分钟内（甚至在披露之前，例如 Log4j）就被积极利用。

这个问题发生在所有类型的工作负载中，无论您是使用最新的 DevOps、DevSecOps 还是任何一种运维方法都没有关系。最终，您要么以牺牲可用性或性能为代价更快地为安全操作打补丁，要么以更慢的速度打补丁并承担不可接受的安全风险。

它很快变得非常复杂

决定修补的速度只是开始。有时，修补并不简单。例如，您可能正在处理编程语言级别的漏洞——这反过来会影响使用该语言编写的应用程序，例如CVE-2022-31626，一个 PHP 漏洞。

发生这种情况时，还有另一组参与可用性与安全性冲突：需要分两步处理语言级漏洞的开发人员。首先，通过更新有问题的语言版本，这是容易的部分。

但是更新语言版本带来的不仅仅是安全性改进；它还带来了其他根本性的变化。这就是为什么开发人员需要进行第二步：补偿重写应用程序代码带来的语言级别的变化。

这也意味着在某些情况下需要重新测试甚至重新认证。就像希望避免与重启相关的停机时间的运维团队一样，开发人员确实希望尽可能长时间地避免大量的代码编辑，因为这意味着主要的工作，是的，可以确保更严格的安全性——但否则会使开发人员无所适从.

过程崩溃

您可以轻松了解为什么当前的补丁管理流程会导致团队之间出现多层次的冲突。自上而下的政策可以在一定程度上解决问题，但这通常意味着没有人对结果感到真正满意。

更糟糕的是，这些策略通常会使系统长时间不打补丁而危及安全。每周或每月修补系统，认为风险是可以接受的，在当前的威胁级别上，迟早会导致清醒的现实检查。

有一种方法可以显着减轻甚至解决立即修补（和中断）和延迟修补（和安全漏洞）之间的冲突。答案在于无中断和无摩擦的修补，在每个级别或至少与实际一样多的级别。

无摩擦修补可以解决冲突

实时修补是您的安全团队应该注意的无摩擦修补工具。多亏了实时修补，您的修补速度比常规维护窗口所希望的要快得多，并且永远不需要重新启动服务来应用更新。快速安全的修补，几乎没有停机时间。一种解决可用性和安全性冲突的简单有效的方法。

在TuxCare，我们为关键的 Linux 系统组件提供全面的实时补丁，以及针对多种编程语言和编程语言版本的补丁，这些补丁专注于安全问题，并且不会引入任何语言级别的更改，否则会强制代码重构 - 您的代码将继续运行 -是，只有安全。即使您的业务依赖于不受支持的应用程序，您也不必担心漏洞会通过编程语言缺陷渗入您的系统——您也不需要更新应用程序代码。

因此，总而言之，在可用性与安全性冲突中，实时修补是一种可以显着减少运营和安全团队之间紧张关系的工具。