为什么数据库修补最佳实践不起作用？以及如何修复它？

补丁非常非常重要–；修补是防止技术解决方案变得像大块瑞士奶酪一样，在关键解决方案中一个接一个地出现无休止的安全漏洞的原因

但任何花了大量时间维护系统的人都会知道，修补往往说起来容易做起来难。

是的，在某些情况下，您只需运行命令行即可安装该修补程序，仅此而已。然而，这种情况越来越罕见；鉴于技术环境的复杂性，您更有可能面临一个复杂的过程来实现修补最佳实践

在本文中，我们将概述为什么数据库修补很重要（是的，数据库也容易受到攻击！），解释修补数据库的问题是什么，并指出一种新的解决方案，可以减轻修补数据库的痛苦

小心！你的数据库服务也很脆弱

我们知道数据库服务至关重要–；数据库以无数方式支撑着IT运营，在后台工作。然而，数据库并不是技术堆栈中最有趣的部分，这也是数据库修补被忽视的原因之一。在Imperva最近的一项调查中，该公司发现近50%的内部数据库易受已知漏洞攻击

然而，网络罪犯并没有忽视数据库。就像技术堆栈中的任何其他元素一样，数据库也充满了漏洞。仅仅一个数据库服务就有上千个相关漏洞。

考虑几个例子。2016年9月，报告了CVE-2016-6662，该漏洞允许攻击者将恶意MySQL配置设置注入受害者的数据库服务。它也影响了MySQL克隆–；包括被迫在这里公布详细缓解措施的MariaDB

另一个例子：2020年，发现了一个数据库漏洞，攻击者可以在该漏洞中发起权限提升攻击，因为某些版本的MariaDB在安装阶段是如何处理“setuid”的

在我们的两个例子中，补丁–；或者升级到更新版本的数据库服务–；将关闭漏洞。但问题就在这里：补丁并没有像应该的那样始终如一地发生，而且不仅仅是因为技术团队懒惰–；或者是因为数据库服务被遗忘了只需开始补丁管理，对不对？

不完全是。数据库修补被忽视还有第二个原因；修补数据库可能非常困难，指令相互冲突且模棱两可。当数据库实现相当复杂时，这个问题尤其普遍

以MySQL集群为例。开源数据库MySQL有一篇官方文章概述了用户需要如何修补MySQL集群–；但是指令非常复杂，当有其他MySQL集群策略时，它只考虑MySQL集群的一个特定设置InnoDB

上述MySQL说明还遗漏了修补的几个重要方面。它没有涵盖修补过程可能会如何影响其他应用程序–；或者它可能会如何影响技术解决方案中的其他系统。当然，它不能提供这样的建议，因为每个环境都是不同的，作者不知道你的环境是什么样子

这就是补丁最佳实践和数据库最佳实践的一个主要问题：几乎不可能解释无限的实际变化–；从数据库配置的差异到技术知识的不同层次

修补最佳实践正好适合目的

最终结果可能是，实施已发布的补丁最佳实践是一项非常模糊和不确定的工作。系统管理员可以轻松确定修补出错的风险和影响，这比数据库遭受网络攻击的风险要重要得多。因此，虽然理论上很容易“继续修补”，但现实情况却大不相同。

即使团队具备成功修补数据库的技术知识和实践确定性，但仍然存在一个现实，即数据库服务必须脱机一段时间才能执行修补

如果没有高可用性，停机是最具破坏性的副作用，因为技术服务会离线，扰乱工作

高可用性配置可以确保没有停机，但即使是这些配置也可能会出现服务降级，因为群集中的一些服务器处于脱机状态，无法支持需求或提供足够的保护，而一些节点正在停机进行维护

复杂的修补程序也会消耗大量时间，这会占用其他重要任务的资源–；在某些情况下，资源可能根本无法确保一致的补丁

最后，为了修补和管理复杂的迁移过程而使数据库离线总是有出错的风险。数据损坏可能会在迁移过程中蔓延，或者一些服务器在修补后可能无法恢复正常运行。这些风险不容忽视–；并且是当前需要重新启动的数据库修补实践所固有的实时数据库修补作为替代方案。

直到最近，修补技术服务几乎总是需要重新启动，但实时修补正变得越来越普遍。通过实时补丁，补丁工具可以对补丁代码执行就地交换：在进行补丁时，被补丁的服务保持运行，无需重新启动

这正是TuxCare的新解决方案DatabaseCare的角色。多亏了DatabaseCare，您可以随时执行全面修补，因为DatabaseCare会在数据库积极运行和服务数据时修补数据库

这是如何工作的？这在实践中很简单。您的服务器连接到内部部署的DatabaseCare ePortal，修补程序安全地存储在那里。一旦记录了新的漏洞，代理就会与ePortal通信，然后ePortal会从DatabaseCare中提取更新。然后，代理会在安全模式下暂时冻结数据库服务，并在内存中透明地应用补丁。这种“冻结”非常快，甚至不会中断与数据库服务的网络连接或运行查询。

结果是：您的数据库会自动更新最新的安全补丁，无需停机，中断和风险最小；而且你的技术团队没有持续的努力DatabaseCare对您有什么好处

让我们更清楚地了解实时补丁的好处；与目前的修补最佳实践相比

我们已经指出了数据库修补的复杂性，尤其是对于高可用性、分布式数据库。DatabaseCare用一个单一、一次性、简单的步骤–；这也很容易自动化

它消除了修补数据库时的模糊性。你遵循正确的指示了吗？即使你做得很完美，它也会起作用吗？所有这些问题现在都没有了–；修补会自动在后台进行。是的，修补数据库所涉及的风险现在已经大大降低，这减少了修补的犹豫

同时，自动修补也意味着，你不需要尝试在一长串消耗IT的任务中加入修补。而且，当补丁不争夺资源时，它会更频繁地发生。组织内的其他业务部门将了解到，修补操作不再需要长时间的维护窗口

我们都知道定期修补意味着什么：更严格的安全性。减少补丁发布日期和应用补丁时间之间的时间间隔，就减少了攻击者利用漏洞的机会窗口，最佳实践很重要–；但DatabaseCare解锁了一致的安全性

修补数据库服务并不是什么新鲜事–；最佳实践指导已经存在了一段时间。但修补现有最佳实践存在实际困难，这些实际困难为网络攻击者留下了一扇窗户

DatabaseCare填补了这一空白–；它不会中断您的运营，不会带来失败的风险，您也不需要资源来让它工作。反过来，你的安全感会变得更加稳固。安装DatabaseCare也很简单。要了解更多信息，只需查看TuxCare网站上的DatabaseCare页面。