如何保护我的存储过程代码

引言

每个开发人员都非常关注如何最好地保护她的/他的 SQL 代码对象，比如视图/存储过程。因此，我们将尝试加密。加密是一种好的方法，但并非完全站得住脚。在本文中，我想向您展示一些保护 SQL Server 代码对象的最佳实践。

除非绝对必要，否则不要加密

当您将基于 SQL Server 的应用程序分发给客户和其他第三方时，您可能想加密存储过程、函数和类似对象的源代码。显然，这可以保护您的代码免受窥探，并阻止他人未经您的许可更改您的代码。

也就是说，除非您真正担心机密或专有信息被盗，否则我建议不要加密您的 SQL Server 对象。对我来说，加密 SQL Server 对象通常弊大于利。加密 SQL Server 对象源代码有许多缺点。让我们讨论其中的几个。

第一，加密对象无法被脚本化，即使是通过企业管理器。也就是说，一旦过程或函数被加密，您就无法从 SQL Server 检索其源代码。在早期版本的 SQL Server 中解码加密源代码的众所周知但未公开的方法不再有效，并且 Microsoft 不支持其他可能发现的方法。更糟糕的是，如果您尝试使用默认选项通过企业管理器对加密对象进行脚本化，您的新脚本将包含一个对象的DROP语句，但没有CREATE语句。相反，您将看到的只是一个有用的注释，通知您不支持对加密对象进行脚本化（而显然，删除它们是可以的）。如果您运行此脚本，您的对象将丢失。它将被删除，但不会被重新创建。

第二，加密对象无法作为 SQL Server 复制的一部分发布。如果您的客户设置复制操作以保持多个服务器同步，那么如果您的代码被加密，他们将遇到问题。

第三，您无法检查加密源代码的版本信息（例如，由源代码管理系统插入的版本信息）。由于客户可以加载可能重新安装旧版本代码覆盖较新版本的备份，因此能够检查客户服务器上的代码的版本信息非常方便。如果您的代码被加密，您将无法轻易做到这一点。如果它没有被加密，并且您已经在源代码中包含了版本信息，那么您应该能够轻松确定客户正在使用的对象的确切版本。

我如何保护我的存储过程代码？

当将应用程序部署到客户端服务器或共享 SQL Server 时，通常会担心其他人可能会窥探您的业务逻辑。由于存储过程中的代码通常是专有的，因此我们可能希望保护我们的 T-SQL 工作是可以理解的。在 SQL Server 中有一个简单的方法可以做到这一点，而不是

CREATE PROCEDURE dbo.Example 
AS 
BEGIN
     SELECT 'SQL statements'
END

GO

您可以使用WITH ENCRYPTION选项

CREATE PROCEDURE dbo.Example 
WITH ENCRYPTION 
AS 
BEGIN 
     SELECT 'SQL statements' 
END

现在，在您这样做之前，请确保将存储过程的逻辑保存在安全的地方，因为一旦您保存了它，您将无法轻松访问该过程的代码。

现在您会注意到，当您尝试在企业管理器的 GUI 中打开该过程时，您将收到以下错误

Microsoft SQL-DMO 
Error 20585: [SQL-DMO] 
/****** 
    Encrypted object is not transferable, 
    and script can not be generated. 
******/

当您尝试使用sp_helptext查看代码时...

EXEC sp_helptext 'Example' 

...您将得到以下错误

The object comments have been encrypted. 

不幸的是，至少有两种方法可以击败这种机制。一种是在执行存储过程时运行 SQL Profiler；这通常可以揭示过程本身的文本，具体取决于存储过程的功能（例如，它是否有 GO 批处理、动态 SQL 等）。如果他们错过了初始安装，用户可以删除存储过程或删除数据库，启动 Profiler 跟踪，并要求您重新创建它们（在这种情况下，他们将捕获CREATE PROCEDURE语句）。您可以通过将sp_password嵌入到代码中作为注释来防止 Profiler 向窥探者显示文本

CREATE PROCEDURE dbo.Example 
WITH ENCRYPTION 
AS 
BEGIN 
     SELECT 'SQL statements' 
    -- comment: sp_password 
END 

参考文献

有关此主题的更多信息，请访问此链接。

结论 

我希望本文对您有所帮助。 祝您愉快！

历史  

• 2009 年 7 月 30 日：初始帖子