SQL Server2005 SQLCLR代码之CLR安全

核心提示：一、 CLR安全性在第一篇中，我们已经讨论了宿主于和在SQL Server内执行的.NET代码的安全环境-从SQL Server的角度来观察SQLCLR代码模块，SQL Server2005 SQLCLR代码之CLR安全，但是CLR使用其自己的安全模型，一旦SQL Server同意进行所有的许可权检查并且允许代码执行，

一、 CLR安全性

在第一篇中，我们已经讨论了宿主于和在SQL Server内执行的.NET代码的安全环境-从SQL Server的角度来观察SQLCLR代码模块。但是CLR使用其自己的安全模型。一旦SQL Server同意进行所有的许可权检查并且允许代码执行，那么这种模型就会"强制介入"。仅仅因为它能够执行并不意味着它能够做它想做的任何事情。

CLR提供给它运行的.NET代码和它运行的主机许多服务。这些服务包括：

1）类型安全检查-校验代码能够以良好定义的方式来存取内存结构；

2）基于角色的安全-根据由谁运行代码；

3）代码存取安全-在这种情况下，许可权的授予是基于代码特征而不是基于谁在运行代码；

4）应用程序域-它提供在宿主进程中实现安全执行地带。

在数据库中的所有具有相同所有者的程序集都被加载到同一个AppDomain中，不管它们被安装到哪个数据库中。在一个AppDomain中的每一个程序集都能够通过反射找到另外每一个其它程序集。既然它们具有相同的所有者，所以SQL Server不必执行它自己的权限检查，这有助于性能的改进。但是这些措施并不能解决实际存在的代码存取安全问题。

CLR还强制实行宿主保护属性（HPA）-允许一个宿主（在此情况下，是指SQL Server）控制允许SQLCLR代码使用.NET框架的指定部分。其实，在可靠性方面，还有除了安全性外的其它方面的内容。

二、 代码存取安全性

CLR提供的最重要的服务之一是代码存取安全性(CAS)。CAS的基本原则是，为代码赋予特权，而不是针对用户。如果你已习惯于Windows或SQL Server模式的把许可权赋予用户和登录而不是它们正在执行的代码，这听上去似乎有些奇怪。但是，就算SQLCLR代码在一个管理用户的安全上下文下执行，它也可能不具有所有可用的许可权。事实上，在SQL Server内部执行的SQLCLR代码几乎一定不会拥有所有许可权-这称为"完全信任"。