提要 在SQL Server 2005內(nèi)運(yùn)行.NET框架代碼是一件令人激動(dòng)的事情還是一種威脅？本系列文章將全面探討這類SQLCLR代碼的安全問題，以便開發(fā)人員和DBA都能夠有所借鑒。

一、引言

編寫運(yùn)行于宿主在任何環(huán)境下的CLR中的.NET代碼的主要優(yōu)點(diǎn)之一是代碼存取安全（CAS）。

CAS提供了一種基于代碼的而不是基于用戶的認(rèn)證模式以預(yù)防各種代碼的入侵問題。但是，這種安全模式如何與SQL Server 2005自己的新的增強(qiáng)的安全特征共存呢？默認(rèn)情況下，你的.NET代碼是比較安全的；但是，這兩種安全模式很容易發(fā)生沖突而且容易給你帶來一些問題。在本篇中，我們將簡(jiǎn)短地分析CAS幕后有關(guān)概念和在SQL Server 2005中新引入的一些安全特征；然后，在后面的幾篇中分析如何實(shí)現(xiàn)在利用SQL Server所提供的高級(jí)可編程特征的同時(shí)，使這兩種系統(tǒng)協(xié)同工作。

好消息是，為了實(shí)現(xiàn)SQL Server所提供的安全系統(tǒng)和通用語(yǔ)言運(yùn)行時(shí)刻庫(kù)協(xié)同工作，微軟已經(jīng)提供了一定的工具來實(shí)現(xiàn)代碼控制。但是，也存在許多有趣的問題！

能夠用C#，VB或任何其它.NET語(yǔ)言編寫存儲(chǔ)過程及其它代碼模塊一直被長(zhǎng)期期待，而這正是SQL Server 2005最激動(dòng)人心的特征之一。開發(fā)人員和DBA最終都能夠沖破存在于擴(kuò)展存儲(chǔ)過程的Transact-SQL（T-SQL）和C 中的羈絆，而用一種真正的具有高度生產(chǎn)力的語(yǔ)言編寫數(shù)據(jù)庫(kù)代碼！

同時(shí)，在數(shù)據(jù)庫(kù)服務(wù)器的內(nèi)存空間中運(yùn)行.NET代碼的前景嚇壞了某些人，尤其是一些負(fù)責(zé)保護(hù)數(shù)據(jù)完整性并且確保這些服務(wù)器晝夜運(yùn)行的DBA們。運(yùn)行一些開發(fā)人員的代碼（能夠完全存取.NET框架和Win32 API）的想法導(dǎo)致許多DBA堅(jiān)持認(rèn)為，對(duì)運(yùn)行于服務(wù)器中的這樣的代碼進(jìn)行維護(hù)根本超出他們的能力之外。

通過在會(huì)議上進(jìn)行演講并進(jìn)行大量培訓(xùn)活動(dòng)，以及我向同學(xué)和客戶提問"是否在服務(wù)器上的.NET代碼嚇壞了他們及其原因"。最終得到下面一些典型的備受關(guān)注的問題：

·含糊的安全問題。其中大多數(shù)與當(dāng)前正在出現(xiàn)的攻擊問題相關(guān)；但是，顯然，對(duì)有哪些新內(nèi)容還不理解更為關(guān)注。

·需要學(xué)習(xí)一種全新的技能來評(píng)定是否代碼是安全的。

·在數(shù)據(jù)和代碼之間存在很多的模糊性，特別是對(duì)于使用.NET代碼創(chuàng)建用戶定義的類型這種新的能力。

·還有另一種方式能夠?qū)崿F(xiàn)代碼與服務(wù)器的"混合"，盡管OLE自動(dòng)化（SP_OS*）和命令外殼系統(tǒng)(xp_cmdshell)存儲(chǔ)過程一直可用來讓人們運(yùn)行外部代碼。

事實(shí)上，在SQL Server 2005中的.NET框架代碼，經(jīng)常被稱作是SQLCLR代碼，因?yàn)樗腔?NET通用語(yǔ)言運(yùn)行時(shí)刻庫(kù)（CLR）。其實(shí)，它僅僅是另一種存在和運(yùn)行于SQL Server內(nèi)部的代碼模塊而已。它是新東西，而且很酷，但是也仍只是代碼；但決不是T-SQL（仍然是首選的數(shù)據(jù)存取編碼實(shí)現(xiàn)方式）的插件代替品；而是，SQLCLR代碼為復(fù)雜的數(shù)據(jù)庫(kù)應(yīng)用程序開創(chuàng)了全新的可能性。遲早大多數(shù)的DBA都會(huì)使用它并且將不得不做出最后的決定-是否讓它駐于數(shù)據(jù)庫(kù)中。

在本文中，我將探討人們對(duì)于SQLCLR代碼最關(guān)心的一個(gè)問題之一：其安全性如何？實(shí)際上，我將故意模糊兩種重要概念-安全性和可靠性。安全性意味著保持?jǐn)?shù)據(jù)的安全，而可靠性意味著保持SQL Server的安全；可靠性經(jīng)常被與安全性相混淆。因此，盡管我主要討論安全問題，但是我還要涉及到一定的可靠性問題。

我將假定，你熟悉在SQL Server 2005編寫.NET代碼的優(yōu)點(diǎn)和基本知識(shí)。概括來說，包括下面這些內(nèi)容：

·程序集，作為打包、發(fā)布和版本管理的單元

·.NET代碼存取安全基礎(chǔ)

·SQL Server 2005的新的安全特征

換句話說，本文并不是一篇有關(guān)于SQLCLR代碼的入門性文章。

二、安全宿主SQLCLR代碼

隨著SQLCLR代碼的引入，SQL Server 2005現(xiàn)在支持兩種完全不同的運(yùn)行時(shí)刻環(huán)境：好的舊的可靠的T-SQL和新的正在發(fā)展中的SQLCLR。在過去的幾年中，T-SQL隨著SQL Server版本的不斷升級(jí)而不斷發(fā)展，并且與存儲(chǔ)在一個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)和對(duì)象緊密集成到一起，也與SQL Server中的安全系統(tǒng)良好地集成。相比之下，SQLCLR代碼，在內(nèi)部使用了一種由CLR所提供的完全不同的安全系統(tǒng)，這是一種"溫暖的"、安全的環(huán)境。在此環(huán)境下，代碼的運(yùn)行不是基于運(yùn)行它的用戶的安全資格而是基于代碼本身的安全資格。同時(shí)，SQLCLR代碼必須在數(shù)據(jù)庫(kù)和服務(wù)器的安全范圍內(nèi)執(zhí)行；然而，這兩種安全系統(tǒng)是根本不同的。如今，微軟的SQL Sever開發(fā)小組已經(jīng)研究出一種方法使得這二者共存并能夠協(xié)同工作。

能夠在另外一個(gè)應(yīng)用程序中可靠地安全地宿主CLR是.NET框架2.0的一種新特征。這種宿主環(huán)境及其SQL Server實(shí)現(xiàn)，正是使得這兩種安全系統(tǒng)和平共處的"秘密"所在，因?yàn)樗拗鳎ㄔ诖耸荢QL Server）能夠很大程度地控制運(yùn)行的代碼。這意味著，從一種安全角度來看，托管SQLCLR代碼不被允許存取沒有授權(quán)給它的數(shù)據(jù)庫(kù)對(duì)象。該代碼必須運(yùn)行于用戶會(huì)話的SQL Server安全上下文中，而且需要使用相關(guān)的與T-SQL代碼相同的許可權(quán)來激活它。

注意底線是，在一個(gè)數(shù)據(jù)庫(kù)中，SQLCLR代碼不能做比在相同的安全上下文中等價(jià)的T-SQL代碼模塊更多的事情。

當(dāng)設(shè)計(jì)怎樣宿主CLR時(shí)，微軟具有三個(gè)主要的設(shè)計(jì)目標(biāo)：

·CLR及運(yùn)行于其中的代碼不能妥協(xié)于SQL Server的安全性和穩(wěn)定性。

·SQLCLR代碼必須遵循SQL Server認(rèn)證和授權(quán)規(guī)則。這在一定程度上意味著，它要運(yùn)行于用戶會(huì)話的安全上下文中。

·系統(tǒng)管理員必須能夠控制對(duì)操作系統(tǒng)資源的存取。這意味著，必須存在一種安全的方式來從SQL Server進(jìn)程中存取機(jī)器資源。

這些目標(biāo)的最明顯的表現(xiàn)之一是，默認(rèn)情況下，CLR集成是關(guān)閉的。如果你想在一個(gè)數(shù)據(jù)庫(kù)中運(yùn)行.NET代碼，那么一個(gè)系統(tǒng)管理員必須把它打開。打開它的T-SQL代碼需要使用sp_configure：

sp_configure 'clr enabled'，1
GO
RECONFIGURE
GO

當(dāng)然，你還可以使用新的與SQL Server 2005一起安裝的Surface Area配置工具來實(shí)現(xiàn)這一點(diǎn)，如圖１所示。從Windows開始菜單下，選擇"Microsoft SQL Server 2005→Configuration Tools→SQL Server Surface Area Configuration"，再選擇"Surface Area Configuration for Features"，然后從列表下選擇"CLR Integration"。

圖1.Surface Area配置工具-該圖展示了怎樣使用Surface Area配置工具來啟動(dòng)SQLCLR。

因此，正確理解開關(guān)CLR集成特征的含義是十分重要的；然而，它唯一影響的是，是否允許在存儲(chǔ)過程、觸發(fā)器、用戶定義類型及用戶定義函數(shù)中運(yùn)行SQLCLR代碼。如果它被禁用，那么，在該服務(wù)器實(shí)例中不會(huì)執(zhí)行SQLCLR代碼；如果它被啟動(dòng)，那么，任何CLR代碼都可以執(zhí)行（當(dāng)然，假定用戶擁有正確的執(zhí)行權(quán)限）。如果它被禁用，它不會(huì)阻止你把SQLCLR程序集安裝到數(shù)據(jù)庫(kù)中。你可以安裝所有你想使用的程序集（當(dāng)然，假定你擁有這樣做的屬性許可權(quán)），但是它們?cè)谌魏苇h(huán)境下都不會(huì)運(yùn)行，直到你支持CLR集成為止。

當(dāng)SQLCLR代碼執(zhí)行時(shí)，它是在一個(gè)嚴(yán)格的安全環(huán)境中-這是一個(gè)既能保護(hù)操作系統(tǒng)資源又能保護(hù)SQL Server中的數(shù)據(jù)和對(duì)象的層。

圖2.安全層：SQLCLR代碼并非運(yùn)行于一個(gè)安全真空中。

圖2顯示了這些安全層。操作系統(tǒng)強(qiáng)制性使用它自己的控制-使用熟悉的用戶和組模式以同意存取具有存取控制列表（ACL）的資源。在Windows中運(yùn)行的每一個(gè)應(yīng)用程序都需要運(yùn)行于一個(gè)登錄安全的上下文-它具有適當(dāng)?shù)脑S可權(quán)來進(jìn)行資源存取。即使SQL Server也必須在這一框架內(nèi)運(yùn)作。

通過使用它自己的登錄機(jī)制或者映射到操作系統(tǒng)的登錄機(jī)制，SQL Server控制它自己的環(huán)境的安全性。在它的環(huán)境內(nèi)，基于由對(duì)象的所有者或管理員所賦予的許可權(quán)，它授予或禁止存取數(shù)據(jù)和對(duì)象。T-SQL也在這種權(quán)限模式下操作。SQLCLR代碼在相同的安全環(huán)境下以T-SQL代碼形式執(zhí)行，而且在由CLR所提供的它自己的安全環(huán)境下執(zhí)行。CLR實(shí)現(xiàn)代碼存取安全（CAS）以授予它自己的許可權(quán)來運(yùn)行代碼。在后面部分，在討論其它一些有關(guān)于SQL Server主機(jī)環(huán)境的安全細(xì)節(jié)問題之后，我們將更為深入地分析一下CAS。

三、SQL Server級(jí)的安全性

與早期的SQL Server版本相比，SQL Server 2005實(shí)現(xiàn)一種更具有粒度性的許可權(quán)模式。這種粒度延伸到SQLCLR代碼內(nèi)-對(duì)于該代碼來說，需要使用三種主要的許可權(quán)來安裝和運(yùn)行該代碼。

·需要使用CREATE ASSEMBLY權(quán)限來運(yùn)行CREATE ASSEMBLY語(yǔ)句（這個(gè)語(yǔ)句把一個(gè)SQLCLR程序集安裝到一個(gè)數(shù)據(jù)庫(kù)中）。

·為了運(yùn)行代碼，一名非系統(tǒng)管理員必須具有在一個(gè)代碼模塊上的EXECUTE權(quán)限；而一個(gè)sysadmin能夠運(yùn)行任何代碼。

·代碼的所有者必須具有REFERENCES權(quán)限以參考其它對(duì)象，例如使用外鍵和使用模式綁定創(chuàng)建視圖（運(yùn)行位于同一個(gè).NET程序集中的代碼不需要這種權(quán)限）。

除了這些許可權(quán)外，引起SQLCLR代碼執(zhí)行的用戶在登錄時(shí)必須對(duì)代碼參考的數(shù)據(jù)庫(kù)表?yè)碛型ǔ５腟ELECT，INSERT，DELETE，或UPDATE許可權(quán)。無法實(shí)現(xiàn)這樣的目標(biāo)：根據(jù)代碼對(duì)數(shù)據(jù)庫(kù)表中的數(shù)據(jù)所實(shí)行的操作，使得宿主于SQL Server 2005內(nèi)的SQLCLR能夠避開這些許可權(quán)需要。而且，該權(quán)限檢查還"鉤入"（hook into）SQL Server 2005中的新的執(zhí)行上下文特征，以便當(dāng)定義一個(gè)SQLCLR存儲(chǔ)過程或函數(shù)時(shí)，你可以使用EXECUTE AS語(yǔ)句指定代碼的執(zhí)行上下文。