數據安全是企業級應用極爲重要的保證，數據庫安全更是數據安全中的重中之重。Win2003是微軟第一個“缺省安全”產品，缺省情況下整個服務器是被鎖定的，必須手動去激活一些你想要使用的服務。與Win2003一樣，SQL Server 2005也是微軟提供的第一個“缺省安全”的數據庫系統，缺省安裝情況下，安裝程序爲每個安裝選項選擇恰當的配置，使得一個新的SQL Server 2005安裝結束時，默認處於一個安全的狀態。雖然從總體安全模型上比較，SQL Server 2000與SQL Server 2005的安全機制是類似的，都是基於認證，授權與審覈（SQL Server安全機制請參見文章：[url]http://alligator.blog.51cto.com/36993/111389[/url]）。但SQL Server 2005在訪問控制，身份驗證，加密以及權限粒度控制等多方面，都比SQL Server 2000有了長足的進步！本文就SQL Server 2005默認的安全配置選項，身份驗證以及授權增強（Schema）等方面做相應的闡述，其它安全性增強，請參考SQL聯機從書或MS網站。
一：安全配置增強
2002年1月，微軟公司提出了“可信賴計算”計劃，旨在提高安全性、私密性、可靠性和業務完整性。SQL Server 2005中引入一些安全改進和新的安全特性，以適應“可信賴計算”。在缺省安裝情況下，SQL Server 2005默認將只會啓用少數核心功能和服務，並且每個安裝選項都選擇恰當的配置，使得SQL Server 2005安裝完成後，擁有一個最小的“***表面”。在SQL Server 2005中默認被禁用的服務和組件包括：.NET框架、Service Broker網絡連接組件、分析服務的HTTP連接組件。其他一些服務，例如SQL Server代理、全文檢索、新的數據轉換（DTS）服務，被設置爲手動啓動。
同時SQL Server 2005提供了“外圍應用配置器”工具，以更好的方便系統管理員對SQL Server進行安全的表面配置。我們通過實際的界面來認識和了解相關的設置和功能。
1：打開外圍應用配置器工具。選擇“所有程序”->"Microsoft SQL Server 2005"->"配置工具"->"SQL Server外圍應用配置器“
2002年1月，微軟公司提出了“可信賴計算”計劃，旨在提高安全性、私密性、可靠性和業務完整性。SQL Server 2005中引入一些安全改進和新的安全特性，以適應“可信賴計算”。在缺省安裝情況下，SQL Server 2005默認將只會啓用少數核心功能和服務，並且每個安裝選項都選擇恰當的配置，使得SQL Server 2005安裝完成後，擁有一個最小的“***表面”。在SQL Server 2005中默認被禁用的服務和組件包括：.NET框架、Service Broker網絡連接組件、分析服務的HTTP連接組件。其他一些服務，例如SQL Server代理、全文檢索、新的數據轉換（DTS）服務，被設置爲手動啓動。
同時SQL Server 2005提供了“外圍應用配置器”工具，以更好的方便系統管理員對SQL Server進行安全的表面配置。我們通過實際的界面來認識和了解相關的設置和功能。
1：打開外圍應用配置器工具。選擇“所有程序”->"Microsoft SQL Server 2005"->"配置工具"->"SQL Server外圍應用配置器“
2：在打開的SQL Server外圍應用配置器界面中，可以看到“外圍應用配置器”工具將安全配置分爲兩種類型，分別是：基於功能的表面安全配置和基於服務和連接的表面安全配置。
其中：“功能的外圍應用置器”應於啓用或禁用數據庫引擎、Analysis Services 和 Reporting Services 的功能。“服務和連接的外圍應用配置器”應於啓用或禁用 Windows 服務和遠程連接。
3：選擇具體的應用配置器，在應用配置器配置界面中，我們可以看到默認情況下，SQL Server 2005只開啓了必須的服務和功能。同時我們可以在配置界面根據自己實際的需求，開啓或關閉具體的服務和功能，查看和修改現有的安全配置選項，這裏就不過多說明。
二：身份驗證增強
SQL Server 2005在身份驗證方面的增強主要有以下幾個方面：
1：基於win2003操作系統上的帳號安全性策略。
在SQL Server 2000中，基於SQL登錄的帳號是直接在SQL Server 2000中設置，無法使用安全策略,比如密碼強度，過期時間等等。SQL Server 2005中改變了這種現狀，在Windows Server 2003或以後的操作系統版本中,SQL Server 2005可以實現
強制登錄帳戶密碼符合本地操作系統的密碼策略，SQL Server用戶和應用程序角色都可以使用帳號安全性策略，包括密碼策略和帳戶鎖定策略。
SQL Server 2005在身份驗證方面的增強主要有以下幾個方面：
1：基於win2003操作系統上的帳號安全性策略。
在SQL Server 2000中，基於SQL登錄的帳號是直接在SQL Server 2000中設置，無法使用安全策略,比如密碼強度，過期時間等等。SQL Server 2005中改變了這種現狀，在Windows Server 2003或以後的操作系統版本中,SQL Server 2005可以實現
強制登錄帳戶密碼符合本地操作系統的密碼策略，SQL Server用戶和應用程序角色都可以使用帳號安全性策略，包括密碼策略和帳戶鎖定策略。
2：基於其它操作系統上的標準SQL登錄增強
在SQL Server 2000中，基於標準SQL登錄的帳號在連接驗證時，默認是使用明文方式在網絡上傳輸驗證憑證，存在驗證憑證在網絡上被捕獲的可能性，帶來安全隱患。爲避免這種安全隱患，MS建議在SQL Server 2000中使用SSL加密通道進行身份驗證。
SQL Server 2005默認對這種現狀進行增強，對於標準的SQL登錄,驗證通道自動使用SQL Server服務器生成的證書進行加密，整個過程是透明的，不需要用戶預先配置SSL證書。但這種增強僅適合於客戶機與服務器都是SQL Server 2005，對於非SQL Server 2005客戶機連接時，驗證方式與SQL Server 2000類似。
在SQL Server 2000中，基於標準SQL登錄的帳號在連接驗證時，默認是使用明文方式在網絡上傳輸驗證憑證，存在驗證憑證在網絡上被捕獲的可能性，帶來安全隱患。爲避免這種安全隱患，MS建議在SQL Server 2000中使用SSL加密通道進行身份驗證。
SQL Server 2005默認對這種現狀進行增強，對於標準的SQL登錄,驗證通道自動使用SQL Server服務器生成的證書進行加密，整個過程是透明的，不需要用戶預先配置SSL證書。但這種增強僅適合於客戶機與服務器都是SQL Server 2005，對於非SQL Server 2005客戶機連接時，驗證方式與SQL Server 2000類似。
3：基於端點的訪問控制
不論是SQL Server 2000還是SQL Server 2005,都支持多種協議通信，默認提供的通信協議有如下四種：Shared Memory、Named Pipes、Tcp/IP、VIA,在SQL Server中對於實際的通信過程中，並不是直接配置通信協議，，MS對通信協議進行了進一步的封裝，SQL Server 2000中，封裝成Net Library，並支持配置參數配置,實現協議通信。SQL Server 2005中封裝成SNI協議層,但SNI並不支持用戶直接配置，而是通過“TDS 端點”對象進行通信。
不論是SQL Server 2000還是SQL Server 2005,都支持多種協議通信，默認提供的通信協議有如下四種：Shared Memory、Named Pipes、Tcp/IP、VIA,在SQL Server中對於實際的通信過程中，並不是直接配置通信協議，，MS對通信協議進行了進一步的封裝，SQL Server 2000中，封裝成Net Library，並支持配置參數配置,實現協議通信。SQL Server 2005中封裝成SNI協議層,但SNI並不支持用戶直接配置，而是通過“TDS 端點”對象進行通信。
TDS 端點是表示 SQL Server 與客戶端之間通信點的SQL Server對象。SQL Server自動爲SQL Server支持的四個協議分別創建一個端點。 我們可以這樣來理解TDS端點：TDS端點實際是與通信協議相關，在實際的SQL Server 2005環境中中啓用了什麼樣的通信協議，就有什麼樣的端點。
SQL Server 2005中，端點對象的具體位置如下：
在SQL Server 2000中，一旦啓用了哪種通信協議，那麼所有的登錄名都可以通過該協議去連接SQL Server服務器,SQL Server 2005增強了基於端點的訪問控制，針對具體的通信協議，可以授權不同的登錄帳戶是否可以連接。
具體的配置方法如下：
1：選擇具體的登錄名，右鍵屬性，打開用戶登錄屬性配置界面
具體的配置方法如下：
1：選擇具體的登錄名，右鍵屬性，打開用戶登錄屬性配置界面
2：在用戶登錄屬性配置界面，選中"安全對象"，添加具體的安全對象.
3: 在添加對象彈出框選擇“添加特定類型對象”
4：在對象類型彈出框選擇“端點”
5：選擇端點後，會列出當前所有的通信協議端點，並可以針對具體的端點授權該登錄用戶是否可以訪問。
5：選擇端點後，會列出當前所有的通信協議端點，並可以針對具體的端點授權該登錄用戶是否可以訪問。
三：授權增強-理解架構
在SQL Server 2000中，授權級別基於三級模型，分別是服務器級別、數據庫級別以及對象級別。在SQL Server 2005中，權限控制粒度細化，新增了架構級別的權限分配,實現了用戶與架構的分離。模型細化成四級：分別是服務器級別，數據庫級別、架構級別和對象級別。
在SQL Server 2000中，授權級別基於三級模型，分別是服務器級別、數據庫級別以及對象級別。在SQL Server 2005中，權限控制粒度細化，新增了架構級別的權限分配,實現了用戶與架構的分離。模型細化成四級：分別是服務器級別，數據庫級別、架構級別和對象級別。
要正確理解架構這個概念，需要對比一下SQL Server 2000中所有權概念。
對於SQL Server 2000來說，所有權與創建用戶是隱式綁定在一起的,一個對象的所有者就是對象創建者。
比如說User1創建了一個表tb_User1,那麼這個表的所有者就是user1。
唯一的例外是dbo這個所有者，所有屬於sysadmin角色中的用戶創建的安全對象默認都是屬於同一個所有者：dbo。
對於SQL Server 2000來說，所有權與創建用戶是隱式綁定在一起的,一個對象的所有者就是對象創建者。
比如說User1創建了一個表tb_User1,那麼這個表的所有者就是user1。
唯一的例外是dbo這個所有者，所有屬於sysadmin角色中的用戶創建的安全對象默認都是屬於同一個所有者：dbo。
對於SQL Server 2000來說，完整的訪問方式是：
服務器名.數據庫名.所有者名.表名 (servername.databsename.owner.tablename).
如果是在同一個服務器和同一個數據庫中，可以省略成：owner.tablename。
那麼對於剛所說的表tb_user1,完整的訪問方式應該是user1.tb_user1。
用戶與所有者隱式綁定的方式會帶來一些問題，考慮如下場景：
在一個實際應用程序中，大量使用到形如user1.tb_user1這樣的訪問對象方式。
某一天需要刪除user1這個用戶，但此時無法刪除，系統會提示該用戶擁有tb_user1這個表對象。可能的解決辦法是將tb_user1表對象的所有者轉移到其它用戶後，再進行用戶刪除。但此時用戶刪除後，所有形如user1.tb_user1的訪問對象方式就無法使用，必須手動去修改相應的訪問代碼。
服務器名.數據庫名.所有者名.表名 (servername.databsename.owner.tablename).
如果是在同一個服務器和同一個數據庫中，可以省略成：owner.tablename。
那麼對於剛所說的表tb_user1,完整的訪問方式應該是user1.tb_user1。
用戶與所有者隱式綁定的方式會帶來一些問題，考慮如下場景：
在一個實際應用程序中，大量使用到形如user1.tb_user1這樣的訪問對象方式。
某一天需要刪除user1這個用戶，但此時無法刪除，系統會提示該用戶擁有tb_user1這個表對象。可能的解決辦法是將tb_user1表對象的所有者轉移到其它用戶後，再進行用戶刪除。但此時用戶刪除後，所有形如user1.tb_user1的訪問對象方式就無法使用，必須手動去修改相應的訪問代碼。
爲解決這種問題，在SQL Server 2005中，新增了架構對象，架構不隱式等效於數據庫用戶,而是將用戶與架構的分離。MS對架構的解釋是架構是數據庫對象組織的名稱空間，我們可以將架構理解成是存放安全對象的容器。SQL Server 2005中的所有安全對象都必須指定存放的具體架構。任何用戶都必須指定存放其所擁有對象的架構，如果不指定，默認存放的架構是dbo。同時架構本身也是安全對象，可以針對架構進行授權。
在SQL Server 2005中，對於安全對象的完整的訪問方式是:
服務器名.數據庫名.架構名.對象名。
在SQL Server 2005中，對於安全對象的完整的訪問方式是:
服務器名.數據庫名.架構名.對象名。
下面以一個實際的演示來更好的說明架構的概念。
1：在Manager Studio中新建一個基於SQL登錄的登錄名：DBUser
2：新建一個數據庫SchemaDemo
3：SchemaDemo數據庫中新建用戶DBUser,並選擇對應的登錄名是剛纔創建的DBUser,並取消強制密碼策略，其它設置不變。
4：在SchemaDemo數據庫中授權DBUser用戶擁有創建表權限。
方法是右擊數據庫Schema的屬性選擇權限，添加了DBUser用戶，並給該用戶賦予Create Table的權限
1：在Manager Studio中新建一個基於SQL登錄的登錄名：DBUser
2：新建一個數據庫SchemaDemo
3：SchemaDemo數據庫中新建用戶DBUser,並選擇對應的登錄名是剛纔創建的DBUser,並取消強制密碼策略，其它設置不變。
4：在SchemaDemo數據庫中授權DBUser用戶擁有創建表權限。
方法是右擊數據庫Schema的屬性選擇權限，添加了DBUser用戶，並給該用戶賦予Create Table的權限
5：授權完成後，查看一下DBUser用戶的基本屬性：
默認架構是dbo,沒有擁有的架構，也不屬於任何數據庫角色。
默認架構是dbo,沒有擁有的架構，也不屬於任何數據庫角色。
6：用戶創建完成後，以DBUser登錄到SQL Server Manager Studio，在SchemaDemo數據庫創建新表。
在彈出的對話框中忽略權限警告信息，按“確定”進入實際的建表，保存爲
在彈出的對話框中忽略權限警告信息，按“確定”進入實際的建表，保存爲
tb_User
7：在實際的保存過程中，我們會看到該表是無法保存，提示權限不夠。
8：出現這種情況的原因是在創建DBUser用戶時，沒有指定該用戶的默認架構。那麼默認DBUser存放對象的架構是dbo,但實際上我們並沒有授予DBUser用戶在dbo架構存放對象的權限。解決的方法是授予DBUser向dbo架構存放對象的權限或者新建架構，並授予DBUser存放對象的權限。我們採用第2種方式繼續演示。
9：新建架構db_SchemaDemo,架構所有者選擇DBUser用戶。
10：修改DBUser屬性，指定DBUser默認架構爲db_SchemaDemo。
11：再次以DBUser帳戶登錄，重複第6步操作，此時新建表tb_User成功,這時該表的名稱是：db_SchemaDemo.tb_User，也就是架構名.表名的格式。
9：新建架構db_SchemaDemo,架構所有者選擇DBUser用戶。
10：修改DBUser屬性，指定DBUser默認架構爲db_SchemaDemo。
11：再次以DBUser帳戶登錄，重複第6步操作，此時新建表tb_User成功,這時該表的名稱是：db_SchemaDemo.tb_User，也就是架構名.表名的格式。
12：至此，新建安全對象與架構的關係已經演示完畢，此時tb_user表的訪問格式是db_SchemaDemo.tb_User。有興趣的朋友可以試着將該架構的所有者轉移給其它用戶後，刪除用戶DBUser不會刪除表tb_User,同時tb_User的訪問方式仍然是db_Schema.tb_User。所以說，在SQL Server 2005中實現了架構與用戶的分離。
四：SQL Server 2005安全性其它方面的增強
本文所闡述的安全性的增強只是整個SQL Server 2005安全性增強的一小部分，實際上在元數據保護，數據加密，審覈，以及權限控制粒度等許多方面，SQL Server 2005都做了大量的改進。限於文章篇幅，本文不做太多闡述，請參考SQL聯機從書或MS網站等相關資料。
本文所闡述的安全性的增強只是整個SQL Server 2005安全性增強的一小部分，實際上在元數據保護，數據加密，審覈，以及權限控制粒度等許多方面，SQL Server 2005都做了大量的改進。限於文章篇幅，本文不做太多闡述，請參考SQL聯機從書或MS網站等相關資料。