关键字：数据库
一、 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代码几乎一定不会拥有所有许可权-这称为"完全信任"。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/