全面講解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什么也不沒有做。
【編輯推薦】
