从未知来源恢复备份的安全隐患？

Question

场景：您收到了一个数据库备份，并被告知将其还原到服务器（该服务器已经托管了其他数据库），但没有提供有关备份包含的内容或源是否应受信任的有用信息。

问题 1：恢复很可能是恶意的备份有什么潜在影响？

问题 2：您可以采取哪些措施来保护您的服务器/其他数据库中的数据免受恢复潜在恶意备份的影响？RESTORE VERIFYONLY似乎是一个很好的第一步。最终的答案可能是“在无法访问外部世界的沙箱 VM 中恢复数据库”，但让我们假设该选项不在表中。在这种情况下还应该做什么？

Answer 1

数据库可能包含恶意代码，可能是更改“sa”登录密码或删除每个数据库的过程。但是，我可以看到导致问题的唯一方法是让个人恢复数据库，然后手动执行该数据库中的任何代码。它不会以任何自动方式执行。

没有可以在数据库中应用的设置，让 SQL Server 在将数据库还原到服务器时自动执行数据库中的一些代码。如果是这样，我预计微软会取消该产品的通用标准认证。这对我来说是 DBMS 中允许的一个很大的错误。

Answer 2

您可以采取一些预防措施。

1. 确保只有一位系统管理员可以访问恢复的数据库。
2. 还原完成后将数据库置于单用户模式。
3. 检查此数据库中所有存储过程和函数以及触发器中的代码。
4. 执行 dbcc checkdb 以确保没有完整性问题。
5. 检查曾经有权访问数据库的用户并删除所有用户。
6. 开始允许访问，仅限于您检查的特定对象。

就像 Shawn 所说的那样，除非某个似乎 vbalid 的存储过程具有另一个恶意代码的 exec，否则代码不会自行执行。这就是在将其置于多用户模式之前检查每个内部代码的原因。

Answer 3

我到了这里，但我可以想到至少一种危险的情况：如果您还原具有filetable的数据库，那么这些文件现在默认位于您的网络上（特别是在您的 SQL Server 上）。你可以恢复病毒。

当然，这本身不会做任何事情 - 病毒不会突然变得有知觉 - 但是如果您的用户随后尝试访问该文件，他们可能会被感染。（嘿，我说我已经到达了。）我正在设想一个场景，一个外部黑客想要将恶意软件弄进门，然后他向会计部的 Bob 发送一封电子邮件，说：“这是文件：\sqlserver\filetableshare\ myvirus.exe” - 那时它已经在没有检测到的情况下通过了您的防火墙，现在我们可以使用您的内部防病毒和反恶意软件工具。

Answer 4

RESTORE VERIFYONLY 似乎是一个很好的第一步。最终的答案可能是“在无法访问外部世界的沙箱 VM 中恢复数据库”，但让我们假设该选项不在表中。在这种情况下还应该做什么？

Restore verifyonly验证数据库的完整性它不会告诉您备份是否包含恶意代码 RESTORE VERIFYONLY 不会尝试验证备份卷中包含的数据的结构。非常不可能的是，如果备份来自您工作的公司内部，则可能是恶意的，但如果它来自某个第三方，您需要像 Shawn 所指出的那样小心。

微软在线文档说

•出于安全考虑，我们建议您不要从未知或不受信任的来源附加或恢复数据库。此类数据库可能包含恶意代码，这些代码可能会执行意外的 Transact-SQL 代码或通过修改架构或物理数据库结构导致错误。在使用来自未知或不可信来源的数据库之前，请在非生产服务器上的数据库上运行DBCC CHECKDB，并检查数据库中的代码，例如存储过程或其他用户定义的代码。

Answer 5

该问题主要集中在包含恶意软件的备份上，但也有可能从还原操作本身获得不需要的和潜在的恶意行为。

过去我偶然发现，通过尝试恢复损坏的备份文件可能导致 SQL Server 崩溃，这导致 SQL Server 尝试读取备份文件的末尾并崩溃。我不确定哪些版本容易受到影响，也不确定重现问题需要什么。几年前我遇到这个问题时，我在这里记录了一些有限的细节。

Answer 6

从未知来源恢复未知数据库有什么风险？没有任何。

让未知应用程序使用 sysadmin 帐户连接到该数据库并开始运行代码有什么风险？很多！如果应用程序帐户只有在数据库内的权限而没有服务器级别的访问权限，那么它在数据库之外真的无能为力。这基本上归结为开始在服务器上设置适当的安全框架。