CLR安全性详解

大家都知道CLR是公共运行库语言，现在给大家分析一下关于CLR安全性，代码存取安全性的原理机制。

一、 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安全性之代码存取安全性

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

下面是一些有关于CAS工作的基本知识。当加载一个程序集以响应一个SQLCLR存储过程、函数或其它代码模块的调用时，由CLR负责搜集证据。它使用该证据来把该程序集指派给一个或多个代码组。每一个被指派的代码组都有一个通过某种运行时刻安全策略（使用会员条件来决定代码被指派到哪里）指派的权限集。一种权限相应于操作被保护的内容的一种权力。总之，代码要求调用者必须拥有某种许可权才可以执行特定的行为。

如果这些对于你来说都是陌生概念，那么你需要首先对开发安全的应用程序的这些极其重要的部分有个透彻了解为好。而且，对于理解SQLCLR代码在执行时所具有的许可权来说，理解CAS是最关键的。

那么，SQL Server是如何把SQL Server和CLR安全环境融合到一起的呢？要理解的第一事情是，这些系统保护着两个资源集合。第一个集合包含SQL Server对象和数据。SQL Server的安全环境保护对它自己的对象的存取，甚至包括对它所宿主的SQLCLR代码的保护。

CLR保护对于其它一切的存取。这"其它一切"是指什么呢？是指在SQL Server实例外部的资源，包括磁盘文件、注册表设置、其它的数据库、网络资源和Web服务。这意味着，对于保护在它的宿主SQL Server实例内的任何内容来说，CAS什么也没有做。

现在，让我们稍作停顿再作进一步考虑。让我们先搞明白，哪种安全系统保护哪些关键内容。当然，我们也可以用另一种方式来描述同样的事情：在SQL Server内授予的许可权保护它的所有的数据和对象以免为任何类型的执行代码所调用，而不管这些代码是用T-SQL或是用SQLCLR编写。CLR的CAS保护对于SQL Server外部所有资源的存取。

这样以来，一个必然的结论就是：对于保护一个SQL Server实例的对象或数据来说，CAS什么也不没有做。