场景：您收到了一个数据库备份并被告知将其还原到服务器（该服务器已经托管了其他数据库），但没有提供有关备份包含什么或是否应信任源的有用信息。
问题 1：恢复可能是恶意的备份的潜在影响是什么？
问题 2：您可以做些什么来保护您的服务器/其他数据库中的数据免受还原潜在恶意备份的影响？RESTORE VERIFYONLY似乎是很好的第一步。最终的答案可能是“在无法访问外部世界的沙盒 VM 中恢复数据库”，但让我们假设该选项已取消。在这种情况下还应该做什么？
AskOverflow.Dev
数据库可能包含恶意代码，可能是要更改“sa”登录密码或删除每个数据库的过程。但是，我可以看到导致问题的唯一方法是个人恢复数据库，然后手动执行该数据库中的任何代码。它不会以任何自动方式执行。
没有可以在数据库中应用的设置来让 SQL Server 在将数据库还原到服务器时自动执行数据库中的一些代码。如果是这样，我预计微软会放弃该产品的通用标准认证。这对我来说是一个很大的错误，允许在 DBMS 中使用。
您可以采取一些预防措施。
就像 Shawn 所说的，除非某些看起来 vbalid 的存储过程具有另一个恶意代码的 exec，否则代码不会自行执行。这就是在将其置于多用户模式之前检查每个内部代码的原因。
我到了这里，但我至少能想到一个危险的场景：如果你恢复一个有filetable的数据库，这些文件现在默认在你的网络上（特别是在你的 SQL Server 上）。你可以恢复病毒。
当然，这本身不会做任何事情 - 病毒不会突然变得有感知力 - 但如果您的用户随后尝试访问该文件，他们可能会被感染。（嘿，我说我到达了。）我正在设想一个外部黑客想要将恶意软件带入门的场景，然后他向会计部门的 Bob 发送了一封电子邮件，说：“这是文件：\sqlserver\filetableshare\ myvirus.exe” - 那时它已经通过了您的防火墙而没有被检测到，我们现在需要使用您的内部防病毒和反恶意软件工具。
恢复 verifyonly验证数据库的完整性它不会告诉您备份是否包含恶意代码 RESTORE VERIFYONLY 不会尝试验证备份卷中包含的数据的结构。如果备份来自您工作的公司内部，则极不可能是恶意的，但如果它来自某个第三方，您需要小心，正如肖恩指出的那样。
微软在线文档说
•出于安全目的，我们建议您不要从未知或不受信任的来源附加或恢复数据库。此类数据库可能包含恶意代码，这些代码可能会执行意外的 Transact-SQL 代码或通过修改架构或物理数据库结构而导致错误。在使用来自未知或不受信任来源的数据库之前，请在非生产服务器上的数据库上运行DBCC CHECKDB，并检查数据库中的代码，例如存储过程或其他用户定义的代码。
该问题主要集中在包含恶意软件的备份上，但也有可能从还原操作本身获得不需要的和潜在的恶意行为。
过去我偶然发现，通过尝试恢复损坏的备份文件可能会导致 SQL Server 崩溃，这会导致 SQL Server 尝试读取备份文件的末尾并崩溃。我不确定哪些版本容易受到影响或重现问题所需的确切内容。几年前我遇到这个问题时，我在这里记录了一些有限的细节。
从未知来源恢复未知数据库有什么风险？没有任何。
让未知应用程序使用系统管理员帐户连接到该数据库并开始运行代码有什么风险？很多！如果应用程序帐户仅在数据库中具有权限而没有服务器级别的访问权限，那么它在数据库之外实际上无能为力。这基本上归结为在服务器上设置适当的安全框架。
好的。您要求任何告诉您这样做的人签署一份书面声明，表明他们对后果承担全部责任。如果他们不愿意这样做，您应该在检查备份文件（如果可能）后在沙箱中测试安装，并彻底检查所有表、程序等。如果任何时候有什么奇怪的东西，不要把它放在生产系统。即便如此，你也应该明确（对你的老板和他的上级）你从不信任备份，并且只是在直接命令下这样做。
如果他们不签署这样的声明，请在做任何事情之前通知他们的上级。作为专业人士，您有责任尽可能地保护您的系统，无论某些愚蠢的上级可能命令您做什么。你可能会被解雇，但你可以昂首阔步，知道自己做了正确的事。
除了这里建议的一些影响深远的危险之外，每个人说的危险并不多。如前所述，在数据库备份本身中很难有自动执行的东西。它需要某种外部触发机制。
如果许可是一个问题，请获取旧的笔记本电脑/台式机和数据库软件 (SQLExpress) 的评估版。复制机器上的备份文件，拔掉网络/无线，然后进行恢复。然后开始挖掘。花点时间，因为有很多地方可以隐藏东西，其中大部分已经被此线程中的其他帖子所涵盖。
您的 DBA 正直和生产环境的健康比上级下达的任何命令都更重要。