CLR提供給它運行的.NET代碼和它運行的主機許多服務。這些服務包括：

　　(1)類型安全檢查-校驗代碼能夠以良好定義的方式來存取內存結構;

　　(2)基于角色的安全-根據由誰運行代碼;

　　(3)代碼存取安全-在這種情況下，許可權的授予是基于代碼特征而不是基于誰在運行代碼;

　　(4)應用程序域-它提供在宿主進程中實現安全執行地帶。

　 　在數據庫中的所有具有相同所有者的程序集都被加載到同一個AppDomain中，不管它們被安裝到哪個數據庫中。在一個AppDomain中的每一個程 序集都能夠通過反射找到另外每一個其它程序集。既然它們具有相同的所有者，所以SQL Server不必執行它自己的權限檢查，這有助于性能的改進。但是這些措施并不能解決實際存在的代碼存取安全問題。

　　CLR還強制實行宿主保護屬性(HPA)-允許一個宿主(在此情況下，是指SQL Server)控制允許SQLCLR代碼使用.NET框架的指定部分。其實，在可靠性方面，還有除了安全性外的其它方面的內容。

　　2.代碼存取安全性

　 　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什么也不沒有做。

　　現在，我們 將更為詳細地討論關于CAS的問題。但是，請記住，現在我們所討論的許可權問題并不是在SQL Server內部的那種，而是在外部-在操作系統中的許可權。例如，比方說SQLCLR代碼不得不打開一個磁盤文件來記錄一些日志數據，或進行連接以從另 一個數據庫讀取數據。CAS許可權限制代碼能夠存取該磁盤文件的方式以及到其它數據庫的連接方式。

　　為了運行某種方法，無論何時CLR裝 載一個程序集，它都要收集關于該程序集的與在該機器上定義的策略相匹配的證據以便授予其相應的許可權。典型地，對于.NET程序集的證據通常包括位置(原 始)數據(程序集從這里運行)和身份數據。但是，既然一個SQLCLR程序集從SQL Server內部運行，那么，位置證據基本上是不相關的。這樣以來，只剩下了身份證據，例如是否該程序集擁有一個強名字或者是經過一家特定公司進行數字簽 名的。

　　CLR收集該證據，然后與四種策略級別(企業，機器，用戶和AppDomain)加以比較。(SQL Server文檔經常調用AppDomain級別"Host Policy"，但這是一回事。在.NET框架中，AppDomain是更為典型的術語，我經常使用它)。由CLR授予給一個程序集的實際的許可權集是在 每一個級別上授予的許可權的交集。

　　這四種級別中的每一種都有其自己的許可權集合。為了決定授予給一個程序集的許可權集，CLR使用這些許可權的交集-也即是，各種許可權集的公共集合，并且把這個交集授予給該程序集。

　　你可以使用.NET框架2.0配置工具來分析前三種策略級別：企業，機器和用戶。當你展開TreeView控件的運行時刻安全策略部分時顯示策略級別。

　 　在此，一個用戶或系統管理員能夠修改顯示的級別的默認策略，這樣以來，一個程序集在其加載時就擁有更多或更少的許可權。這可能是個比較復雜的主題，但是 對于SQLCLR代碼來說，事實上，所有的安裝在本地機器上的.NET代碼，這三種策略級別默認地都把"完全信任"指派給一個程序集。"完全信任"僅僅意 味著，代碼自動地擁有每一種可能的權限。更精確地說，它意味著，CLR并不進行任何權限檢查。

　　如果程序集默認地擁有檢查"短路"的許可權，那么為什么我建議你讀取所有關于CAS的內容呢?

　 　理由是，CLR共使用四種策略級來指派許可權，但是只有其中三種能夠使用的工具來進行配置。第四種是AppDomain級別，該級別是當你把一個程序集 安裝到一個數據庫時創建的。該策略級別由SQL Server控制作為CLR宿主。而且，SQL Server極少會授予一個程序集完全許可權信任，因為這對于安全性和可靠性都可能意味著極度的冒險。

　　默認情況下在SQLCLR代碼所 發生的實際情況(記住，一個用戶或系統管理員都能夠修改企業、機器和用戶級上的策略設置)。因為企業、機器和用戶策略級別都授予完全信任權限，他們具有相 同的結果權限集-所有的許可權。該權限集與AppDomain權限集相交的結果就是程序集許可權集。

關鍵字：SQL Server、安全性、數據庫