推薦：通過JDBC連接DB2數(shù)據(jù)庫技巧
關(guān)于DB2數(shù)據(jù)庫的JDBC連接文章有很多，比較出名的有諸如“JDBC數(shù)據(jù)庫連接大全”和“JSP的DB2連接數(shù)據(jù)庫”，雖然都是很詳細(xì)的資料，也都說解決了前人沒有解決的問題，但還是

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

一、引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·SQL Server 2005的新的安全特征

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

二、安全宿主SQLCLR代碼

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

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

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

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

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

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

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

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

sp_configure 'clr enabled'，1
GO
RECONFIGURE
GO

當(dāng)然，你還可以使用新的與SQL Server 2005一起安裝的Surface Area配置工具來實現(xià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配置工具來啟動SQLCLR。

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

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

圖2.安全層：SQLCLR代碼并非運行于一個安全真空中。

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

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

三、SQL Server級的安全性

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

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

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

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

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

分享：精彩的表數(shù)據(jù)排序分組
今天，當(dāng)你需要對一個沒有排序ID的表進(jìn)行排序，并且想給每一行數(shù)據(jù)都給一個序號。這相當(dāng)于很多人問到的，如何在一個視圖中為每一行增加一個自動增長的“ID”號。你可以這樣寫：