SQL Server中CLR安全性詳解

　一、 CLR安全性

　　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內部執行，那麼，位置證據基本上是不相關的。這樣以來，只剩下了身份證據，例如是否該程式集擁有一個強名字或者是經過一家特定公司進行數字簽名的。

　　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許可權集相交的結果就是程式集許可權集。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-623746/，如需轉載，請註明出處，否則將追究法律責任。