SQL Server 2005SQL代码安全之权限(4)

或者：

　　· 程序集的使用方式必须是，通过一个具有EXTERNAL ACCESS ASSEMBLY权限的登录而且要使用一个证书或一个非对称密钥。

　　EXTERNAL ACCESS ASSEMBLY权限是另一种新的粒度许可权-允许一名负责人创建这类程序集。默认情况下，系统管理员拥有它并且能够把它赋给其它登录。但是这样做时要慎重，这当然因为可能潜在地允许危险代码安装到服务器中。

　　一个数据库的TRUSTWORTHY属性要求设置管理员权限并且是在数据库中安装非SAFE程序集的前提。基于EXTERNAL ACCESS ASSEMBLY权限，一个DBA能够控制是否存在潜在危险性的程序集能够被安装到任何数据库中，以及谁能够把它们放到那里。这很有希望会使DBA安心而不必再担心他们的服务器会感染.NET代码！

四、 总结

　　表格3包含可用于SQLCLR程序集的三种权限集的总结，以及SQL Server为每种权限集提供的保护类型。

　　· 代码存取安全是在代码内CLR托管的许可权集。

　　· 编程模型限制是指宿主保护属性，以及是否代码能够使用静态技术。

　　· 要求确认指指，当你使用CREATE ASSEMBLY语句安装它时是否SQL Server验证代码存在相对的安全性。

　　· 调用本机代码指示，是否代码能够调用Win32 API或对外部组件作一种平台调用。

　　表格3:权限设置总结。

　　权限集

保护类型 SAFE EXTERNAL_ACCESS UNSAFE

代码存取安全 仅执行 执行和受限存取外部资源 不受限制

编程模型限制(主机保护属性) 是 是 无

要求确认 是 是 否

调用本机代码 否 否 是

　　如你所见，只要你把你的代码限制为SAFE或EXTERNAL_ACCESS，SQL Server就能够提供一种对保护数据安全和服务器稳定性的SQLCLR代码的良好包装。

　　下面是一个考察你对于SQLCLR安全的理解的测试：

　　· 可以使用一个常规的ADO.NET连接串来存取另一种数据库（或者是一个Oracle或者是一个Access数据库）吗？

　　· 假定你现在已经了解访问外部资源，存取一个Oracle数据库的程序集需要具有什么样的SQLCLR权限集级别？

　　在继续阅读之前，请认真地考虑一下这两个问题吧。

　　提示 .NET框架中所包含的唯一的托管数据库提供者是System.Data.SqlClient。

　　注意，这个程序集必须被安装为UNSAFE。为什么呢？因为该代码必须使用System.Data.OleDb对象。因为这些是基于COM的对象（这意味着是非托管代码），所以程序集需要被安装为UNSAFE-因为这是能够存取非托管代码的唯一的级别。

　　你可能认为这是微软的与Oracle交互的方式。其实，答案是，对于访问一个微软Access数据库也是一样的，因为它也是基于OLE DB和相应的非托管代码。

　　我将在此斗胆说一句：UNSAFE代码永远不应该用在一个生产服务器中。除非它是能够被完全观察的代码和经过严格校验以验证它不会危害服务器；否则，你无法用一切办法来足已保证它是安全的。尽管我不排除存在关于UNSAFE代码的合法使用，但是我还是要深思熟虑到底是什么样的代码值得这样一冒险。我通常感到，对于使用扩展的存储过程也存在相同的问题，这一样存在冒险性且必须以复杂的C++代码来编写。

　　至此，我可以说，任何允许UNSAFE代码被安装到一个生产服务器的DBA一般都应该是一个DBA高手而不是一个普通的DBA。而且，我认为，作为一名经常与DBA交流的开发人员，他们中的大多数都是高手！

　　但是，SAFE代码不会比一个T-SQL存储过程带来更大的危险性，而且，当你需要存取外部资源时，EXTERNAL_ACCESS是一种合理的妥协。因此，你可以不必考虑对于未知内容的畏惧，而只需让SAFE代码加入到你的数据库中好了。然后，当它对于数据库、应用程序及用户来说是重要的情况下，再考虑EXTERNAL_ACCESS代码问题。总之，在使得这一类代码安全和可靠方面，微软的确做了一件好事情。