SQL Server 2005+对象加密的缺点？

Question

对于随远程部署产品提供的数据库，是否有任何缺陷通过MS SQL Server 2005和2008中的WITH ENCRYPTION子句来加密所有代码对象（特效，函数，视图）？

其优点是阻止了“自定义”领域的变化，以解决一个需求，同时创造更多。我们的目标不是保护知识产权或数据，而是为了防止未经授权的代码更改，如果无法管理更改对象的权利（安全性不在开发人员手中，但是解决其他人造成的问题的责任是）。

采取这种方法会导致哪些新问题？

Answer 1

Microsoft为此创建了此功能。我能看到的唯一缺点是保护很薄弱;它可以通过公开可用的脚本来规避，SQL Profiler可以用来查看解密过程的明文。但它仍应该起到有效的威慑作用。

Answer 2

由于您指定的原因，我们在企业产品中实施了加密，我们已部署到200多个站点，并阻止逆向工程。

在我们的案例中，它比它的价值更麻烦。我们的客户从未真正改变过任何事情，这使我们很难调试该领域的问题。当所有事情都被加密时，Profiler不会给你所需的细节。我们经常需要加载一个未加密的SPROC等版本来调试问题。

此外，它会使您的模式变得更难以与您期望的版本保持一致。大多数差分工具不能区分加密对象。

Answer 3

你走错路了。 WITH ENCRYPTION是SQL 2000时代的一个过时选项。周围的道路是众所周知的，任何人都可以通过minimal google search skills发现。正确的方法是使用code signing。最好的办法是创建一个证书，签署程序，然后删除私钥。这样，没有人，甚至没有人可以在不破坏签名的情况下更改代码。这并不妨碍任何人修改程序，但一旦修改它们就会破坏签名印章，并且篡改很明显。您可以进一步采取措施，确保程序本身无权执行其目的（即无法读取尝试访问的表），但授权来自其签名（用于签名的证书已授予所需的权利）。这样，如果他们篡改代码不仅会破坏密封，还会导致系统停止。解释这些行动的后果通常具有足够的威慑力。

Answer 4

有许多工具可以解密SQL Server中的存储过程。 有一种商业上可用的工具叫做SQL Shield，它改变了加密机制，使得更难揭示和更改源代码。 但是我必须说加密程序使得难以维护：比较，制作差异等。