问题1：还原很可能是恶意的备份有哪些潜在影响？
问题2：如何保护您的服务器/其他数据库中的数据免受还原的影响？潜在的恶意备份？
RESTORE VERIFYONLY似乎是不错的第一步。最终的答案可能是“将数据库还原到无法访问外部环境的沙箱VM中”，但让我们假设该选项不在桌面上。在这种情况下还应该做什么？#1 楼
数据库可能包含恶意代码，可能是一个过程，该过程将更改“ sa”登录名的密码或删除每个数据库。但是，我看到导致问题的唯一方法是个人还原数据库，然后手动执行该数据库中的任何代码。它不会以任何自动化方式执行。没有任何设置可以应用到数据库中，以使SQL Server在将数据库还原到服务器时自动执行数据库中的一些代码。如果可以的话，我希望微软会放弃该产品的通用标准认证。允许我使用DBMS的那是个很大的错误。
评论
如果在还原过程中重新启用Service Broker（使用WITH ENABLE_BROKER等），则代码可以“自动”运行。显然，如果考虑到安全性，恢复器将不希望使用这些选项中的任何一个，但是它可能被埋在用户可能看不到的第三方供应商应用程序中。
–乔恩·西格尔（Jon Seigel）
14年7月16日在14:36
通过Service Broker可以执行哪种代码？我从不使用或设置它。
–user507
2014年7月16日14:52
激活存储过程。 technet.microsoft.com/zh-CN/library/…
–乔恩·西格尔（Jon Seigel）
14年7月16日在14:59
也许还进行RESTORE HEADERONLY，以查看数据库是否启用了包含。如果是这样，并且在服务器上启用了遏制，则用户无需您授予服务器访问权限就可以访问它。当然，这适用于SQL 2012或更高版本。如果未在服务器上启用包容性，并且备份中的数据库已启用包容，则还原将失败，因此主要仅是在服务器上启用包容性时才需要考虑的问题。
– Robert L Davis
14年7月16日在19:31
@JonSeigel我不认为那些会自动触发。某些东西必须通过将消息发送到服务来将其放入队列中，因此该数据库内必须进行某种交互才能插入记录或触发过程或其他操作。代理队列不只是在没有任何交互的情况下继续触发其激活过程，而是监视消息以显示在队列中。
– JNK
14年7月16日在19:57
#2 楼
您可以采取一些预防措施。请确保只有一个系统管理员可以访问已还原的数据库。
还原完成后，将数据库置于单用户模式。
检查此数据库中所有存储过程和函数中的代码以及触发器。
执行dbcc checkdb以确保没有完整性问题。
检查曾经有权访问数据库的用户并删除所有用户。
开始允许访问，但仅限于您检查的特定对象。
就像肖恩所说的那样，除非某些似乎vbalid的存储过程具有另一个恶意代码的exec，否则代码不会自行执行。这就是在将其置于多用户模式之前检查其中每个代码的原因。
#3 楼
我正在到达这里，但我至少可以想到一种危险的情况：如果还原具有文件表的数据库，则这些文件现在默认情况下位于网络上（尤其是在SQL Server上）。您可以还原病毒。它本身不会做任何事情-病毒不会突然变得有意识-但是，如果您的用户随后尝试访问该文件，则可能已被感染。 （嘿，我说我要到达。）我正在构想一种情况，外部黑客想要在门上安装恶意软件，然后他向电子邮件发送一封电子邮件给Bob，说：“这是文件：\ sqlserver \ filetableshare \ myvirus.exe”-到那时，它已被防火墙检测到，没有被发现，现在我们可以使用内部的防病毒和防恶意软件工具。
评论
您也可以将其表示为“数据库包含必须阅读和应用的有关我们人员的操作说明”。如果他们遵循恶意的方法，他们将向莫斯科发射火箭。这将是普通的varchar ina表...同上，如果您还原二进制文件并邀请员工运行而无需验证原点，那么它就来了。
–雷木斯·鲁萨努（Remus Rusanu）
14年7月16日在22:30
@RemusRusanu在莫斯科发射火箭，哈哈哈，太好了！
–布伦特·奥扎（Brent Ozar）
2014年7月17日在3:45
喜欢社会工程学的观点。具有.bak文件的目标电子邮件可能很诱人，具体取决于目标。
– Max Vernon♦
2014年7月27日在2:28
#4 楼
还原存储似乎是一个不错的第一步。最终的答案可能是“将数据库还原到无法访问外部环境的沙箱VM中”，但让我们假设该选项不在桌面上。在这种情况下还应该做些什么？
Restore verifyonly验证数据库的完整性，它不会告诉您备份是否包含恶意代码RESTORE VERIFYONLY不会尝试验证数据库的结构。备份卷中包含的数据。极不可能的是，如果备份来自您工作所在的公司内部可能是恶意的，但如果备份来自某个第三方，则需要如Shawn所指出的那样小心。
Microsoft Online文档说，
•出于安全性考虑，我们建议您不要从未知或不受信任的源附加或还原数据库。此类数据库可能包含恶意代码，这些恶意代码可能会执行意外的Transact-SQL代码或通过修改架构或物理数据库结构而导致错误。在使用来自未知或不受信任来源的数据库之前，请在非生产服务器上的数据库上运行DBCC CHECKDB，并检查数据库中的代码，例如存储过程或其他用户定义的代码。
#5 楼
问题主要集中在包含恶意软件的备份上，但是还可能从还原操作本身中获得有害的和潜在的恶意行为。我过去偶然发现，SQL Server可能崩溃通过尝试还原损坏的备份文件导致SQL Server尝试读取备份文件末尾而崩溃。我不确定哪个版本容易受到感染，或者确切地说是重现该问题所需的版本。几年前遇到此问题时，我在这里记录了一些有限的详细信息。
评论
好点子。我并不一定要专注于“包含恶意软件的有效备份”，通过无效备份使SQL Server崩溃也是“可能出什么问题？”的完全相关答案。
–西蒙·里格斯（Simon Righarts）
2014年7月17日下午6:15
#6 楼
从未知来源还原未知数据库有什么风险？没有。让未知应用程序使用sysadmin帐户连接到该数据库并开始运行代码有什么风险？很多！如果应用程序帐户仅具有数据库内的权限，而没有服务器级别的访问权限，则它在数据库之外实际上无能为力。基本上，这归因于首先要在服务器上设置适当的安全框架。
#7 楼
您已获得数据库备份，并被告知将其还原到服务器（该服务器已托管其他数据库），但未获得有关备份内容或是否应信任源的有用信息。
很好。您要求任何告诉您执行此操作的人都签署一份书面声明，以使他们对后果承担全部责任。如果他们不愿意这样做，则应在检查备份文件后（如有可能）在沙盒中测试安装，并彻底检查所有表，过程等。如果有任何气味，请不要放在任何地方生产系统。即使这样，您也应该（向您的老板和上司）清楚地表明，您从未信任过备份，并且仅在直接命令下才这样做。
如果他们不签署此类声明，请发出警报做任何事情之前，他们的上司。作为专业人员，无论某些机智的上级可能命令您执行什么操作，您都有责任尽可能多地保护系统。您可能会被解雇，但可以昂首阔步，知道自己做对了。
#8 楼
除了这里建议的一些深远的危险外，每个人所说的没有很多危险。如前所述，很难在数据库备份本身中包含自动执行的内容。它需要某种外部触发机制。如果存在许可问题，请获取旧的笔记本电脑/台式机和数据库软件（SQLExpress）的评估版。将备份文件复制到计算机上，拔下网络/无线网络，然后进行还原。然后开始挖掘。花费所有时间，因为有很多地方可以隐藏东西，其中大部分已经被该线程中的其他帖子覆盖了。
您的DBA完整性和生产环境的舒适性更加出色比上级下达的任何命令都重要。
评论
即使假设还原是仅数据的（没有存储过程或类似的过程），也可能发生许多恶意行为。假设备份是针对包含用户表及其相应权限级别的Web应用程序的，则恶意备份可以将访问权限授予不应该拥有该用户表的用户，并且知道这些用户可以做什么。非常奇怪的是，没有人提到CLR程序或功能的潜在风险。 （默认情况下不再禁用）