一、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什麼也不沒有做。
現在，我們將更為詳細地討論關於CAS的問題。但是，請記住，現在我們所討論的許可權問題並不是在SQL Server內部的那種，而是在外部-在操作系統中的許可權。例如，比方說SQLCLR代碼不得不打開一個磁盤文件來記錄一些日志數據，或進行連接以從另一個數據庫讀取數據。CAS許可權限制代碼能夠存取該磁盤文件的方式以及到其它數據庫的連接方式。
為了運行某種方法，無論何時CLR裝載一個程序集，它都要收集關於該程序集的與在該機器上定義的策略相匹配的證據以便授予其相應的許可權。典型地，對於.NET程序集的證據通常包括位置（原始）數據（程序集從這裡運行）和身份數據。但是，既然一個SQLCLR程序集從SQL Server內部運行，那麼，位置證據基本上是不相關的。這樣以來，只剩下了身份證據，例如是否該程序集擁有一個強名字或者是經過一家特定公司進行數字簽名的。
圖3.來自四種策略級別的CAS許可權的交集
