剖析SQL Server2005 SQLCLR代码安全性

核心提示： 图2.安全层：SQLCLR代码并非运行于一个安全真空中，图2显示了这些安全层，剖析SQL Server2005 SQLCLR代码安全性(5)，操作系统强制性使用它自己的控制-使用熟悉的用户和组模式以同意存取具有存取控制列表（ACL）的资源，在Windows中运行的每一个应用程序都需要运行于

图2.安全层：SQLCLR代码并非运行于一个安全真空中。

图2显示了这些安全层。操作系统强制性使用它自己的控制-使用熟悉的用户和组模式以同意存取具有存取控制列表（ACL）的资源。在Windows中运行的每一个应用程序都需要运行于一个登录安全的上下文-它具有适当的许可权来进行资源存取。即使SQL Server也必须在这一框架内运作。

通过使用它自己的登录机制或者映射到操作系统的登录机制，SQL Server控制它自己的环境的安全性。在它的环境内，基于由对象的所有者或管理员所赋予的许可权，它授予或禁止存取数据和对象。T-SQL也在这种权限模式下操作。SQLCLR代码在相同的安全环境下以T-SQL代码形式执行，而且在由CLR所提供的它自己的安全环境下执行。CLR实现代码存取安全（CAS）以授予它自己的许可权来运行代码。在后面部分，在讨论其它一些有关于SQL Server主机环境的安全细节问题之后，我们将更为深入地分析一下CAS。

三、 SQL Server级的安全性

与早期的SQL Server版本相比，SQL Server 2005实现一种更具有粒度性的许可权模式。这种粒度延伸到SQLCLR代码内-对于该代码来说，需要使用三种主要的许可权来安装和运行该代码。

· 需要使用CREATE ASSEMBLY权限来运行CREATE ASSEMBLY语句（这个语句把一个SQLCLR程序集安装到一个数据库中）。

· 为了运行代码，一名非系统管理员必须具有在一个代码模块上的EXECUTE权限；而一个sysadmin能够运行任何代码。

· 代码的所有者必须具有REFERENCES权限以参考其它对象，例如使用外键和使用模式绑定创建视图（运行位于同一个.NET程序集中的代码不需要这种权限）。

除了这些许可权外，引起SQLCLR代码执行的用户在登录时必须对代码参考的数据库表拥有通常的SELECT，INSERT，DELETE，或UPDATE许可权。无法实现这样的目标：根据代码对数据库表中的数据所实行的操作，使得宿主于SQL Server 2005内的SQLCLR能够避开这些许可权需要。而且，该权限检查还"钩入"（hook into）SQL Server 2005中的新的执行上下文特征，以便当定义一个SQLCLR存储过程或函数时，你可以使用EXECUTE AS语句指定代码的执行上下文。