一、 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代码几乎一定不会拥有所有许可权-这称为"完全信任"。 下面是一些有关于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什么也不没有做。
·瑞星病毒监测报告（2005.12.12-2005.12·使用VS2005打造简单分页浏览器·快下载：微软免费提供VB2005电子书·三分钟学会打字，神奇数字五笔2005.1·安装指南：SQL Server 2005安装及界面·体验另类的微软MCE2005·教你用WPS2005演示制作播放按钮·VS.NET2005 Beta2初体验·SQL 2005的SSIS与Oracle的迁移性能·Norton SystemWorks 2005体验
现在，我们将更为详细地讨论关于CAS的问题。但是，请记住，现在我们所讨论的许可权问题并不是在SQL Server内部的那种，而是在外部-在操作系统中的许可权。例如，比方说SQLCLR代码不得不打开一个磁盘文件来记录一些日志数据，或进行连接以从另一个数据库读取数据。CAS许可权限制代码能够存取该磁盘文件的方式以及到其它数据库的连接方式。 为了运行某种方法，无论何时CLR装载一个程序集，它都要收集关于该程序集的与在该机器上定义的策略相匹配的证据以便授予其相应的许可权。典型地，对于.NET程序集的证据通常包括位置（原始）数据（程序集从这里运行）和身份数据。但是，既然一个SQLCLR程序集从SQL Server内部运行，那么，位置证据基本上是不相关的。这样以来，只剩下了身份证据，例如是否该程序集拥有一个强名字或者是经过一家特定公司进行数字签名的。
图3.来自四种策略级别的CAS许可权的交集 CLR收集该证据，然后与四种策略级别（企业，机器，用户和AppDomain）加以比较。(SQL Server文档经常调用AppDomain级别"Host Policy"，但这是一回事。在.NET框架中，AppDomain是更为典型的术语，我经常使用它)。由CLR授予给一个程序集的实际的许可权集是在每一个级别上授予的许可权的交集。 图3展示了这一工作机理。这四种级别中的每一种都有其自己的许可权集合。为了决定授予给一个程序集的许可权集，CLR使用这些许可权的交集-也即是，各种许可权集的公共集合，并且把这个交集授予给该程序集。 你可以使用.NET框架2.0配置工具来分析前三种策略级别：企业，机器和用户。图4展示了这个工具，当你展开TreeView控件的运行时刻安全策略部分时显示策略级别。
图4.该图显示了.NET框架2.0配置工具的策略级别。 在此，一个用户或系统管理员能够修改显示的级别的默认策略，这样以来，一个程序集在其加载时就拥有更多或更少的许可权。这可能是个比较复杂的主题，但是对于SQLCLR代码来说，事实上，所有的安装在本地机器上的.NET代码，这三种策略级别默认地都把"完全信任"指派给一个程序集。"完全信任"仅仅意味着，代码自动地拥有每一种可能的权限。更精确地说，它意味着，CLR并不进行任何权限检查。 如果程序集默认地拥有检查"短路"的许可权，那么为什么我建议你读取所有关于CAS的内容呢？
图5.这里是SQLCLR代码中的实际的CAS权限集。 理由是，CLR共使用四种策略级来指派许可权，但是只有其中三种能够使用如图４所示的工具来进行配置。第四种是AppDomain级别，该级别是当你把一个程序集安装到一个数据库时创建的。该策略级别由SQL Server控制作为CLR宿主。而且，SQL Server极少会授予一个程序集完全许可权信任，因为这对于安全性和可靠性都可能意味着极度的冒险。 图5显示出默认情况下在SQLCLR代码所发生的实际情况（记住，一个用户或系统管理员都能够修改企业、机器和用户级上的策略设置，此时，情况与图3所示相同)。因为企业、机器和用户策略级别都授予完全信任权限，他们具有相同的结果权限集-所有的许可权。该权限集与AppDomain权限集相交的结果就是程序集许可权集。