11-1 伺服器層級的安全性

11-2 認證(Credentials)

11-3 資料庫層級的安全性

11-4 伺服器、資料庫及結構層

級的授權

11-5 管理金鑰及憑證

11-6 透明資料加密

(TDE, Transparent Data

Encryption)(SQL 2008)

11-7 稽核安全性

管理安全性

11-1 伺服器層級的安全性

11-1-1 驗證方式

驗證方式：基礎的 SQL Server 的登入安全性原理，偶爾會出現的題型。

自 SQL 2000 以後的版本，SQL Server 有「Windows 驗證」及「SQL Server 驗證」兩種登入的驗證方式。在預設安裝的情況下，SQL Server 只會採

取「Windows 驗證」，與微軟的網域安全性相結合，只接受網域或本機的

Windows 帳號登入，而不接受「SQL Server 驗證」。若需調整 SQL Server 的連線驗證模式，請修改伺服器的選項設定：伺服器上按右鍵→「屬性」→「安

全性」，從其中修改 SQL Server 的驗證模式，並將 SQL Server 服務重新啟

動。

圖 11-1：調整 SQL Server 的連線驗證模式

若 SQL Server 在「Windows 驗證」的模式下，使用者欲以 SQL 帳號登入

SQL Server 時，在 SQL 2005 中，會得到「未使用信任連接」的錯誤訊息。而

在 SQL 2008 時，基於安全性，為了避免有心人士透過錯誤訊息來獲得伺服器

CHAPTER

MCTS: Microsoft SQL Server 2008 專業認證手冊 150

的相關資訊，進而調整攻擊 SQL Server 的方式，因此 SQL 2008 時的錯誤訊息

都已非常精簡。則只會得到「登入失敗」的錯誤訊息，如下圖所示：

圖 11-2：使用 SQL 帳號登入「Windows 驗證」模式的 SQL Server

由於「SQL Server 驗證」的帳號密碼是由 SQL Server 自行儲存管理，而

不像「Windows 驗證」的帳號密碼是由網域控制站(Domain Controller)統一控

管，因此自然無法做到如網域中的群組原則(Group Policy)所具有的帳號、密

碼原則的控管功能。如：每隔 42 天必須更換密碼、連續輸入錯誤 3 次即鎖定

此帳號、使用密碼複雜度……等原則。

自 SQL 2005 後，「SQL Server 驗證」的帳號密碼可以「借」用 Windows作業系統中的群組原則(Group Policy)中的帳號原則及密碼原則的功能。但是先

決條件必須是以 SQL 2005 / 2008 搭配 Windows Server 2003 / 2008 ，才能讓 SQL Server 使用 Windows 作業系統中的帳號原則及密碼原則。請在利用

「CREATE LOGIN…」建立登入帳號時透過指定「WITH CHECK POLICY…」

等參數來指定使用密碼原則或使用 SSMS 的圖形化介面建立登入帳號時(伺服器

→「安全性」→「登入」按右鍵→「新增登入」)，從其中選取啟用密碼原則。

Chapter 11 管理安全性 151

圖 11-3：使用 Windows 作業系統的帳號及密碼原則來建立 SQL 帳號

11-1-2 連結伺服器(Linked Server)

連結伺服器：此部份的內容操作並不難，但卻有許多人不清楚運作原理，

因此微軟甚至將此部份納入實際操作的考題，請讀者注意！

在一般業界、公司中操作、管理數台 SQL Server 應算是稀鬆平常的事。

但是往往有許多人卻無法正確的由一台 SQL Server 連線到另一台 SQL Server 進行分散式查詢資料。

無論要以何種方式連接到第二台遠端伺服器 (可以是 SQL Server、Access、Excel 或其他資料庫伺服器)。首先需要先在第一台 SQL Server 上加

入「連結伺服器」，並輸入註冊第二台遠端伺服器的連結相關資訊(具名位置

或 IP、驅動程式)。可以透過「sp_addlinkedserver」預存程序或 SSMS 的圖形

化介面來完成(伺服器→「伺服器物件」→「連結的伺服器」→「新增連結的

伺服器」)。

圖 11-4：設定「新增連結的伺服器」的相關資訊

MCTS: Microsoft SQL Server 2008 專業認證手冊 152

接著就是最重要的部份，建立 SQL Server 本機登入帳號與遠端伺服器之

間連接時的對應帳號及密碼。可以透過「sp_addlinkedsrvlogin」預存程序或 SSMS 的圖形化介面來完成(伺服器→「伺服器物件」→「連結的伺服器」→

「新增連結的伺服器」→「安全性」)。

圖 11-5：設定「連結的伺服器」的連結安全性

圖形上方的清單部份，可以在此處設定個別帳戶在透過此連結連接遠端伺

服器時，欲使用的指定相對應帳號及密碼(如上方所示)，此動作稱之為「對應

(Mapping)」。當勾選「模擬」時，則將會無法指定後方的「對應帳號密

碼」，因為此表示使用網域信任及帳號模擬的方式連接遠端伺服器，SQL Server 執行個體將會使用目前使用者的帳號「模擬」給遠端伺服器用以登入，

此動作稱之為「委派(Delegate)」。

下方的四個選項則是表示，若有任何透過此連結連接遠端伺服器，卻未出

現在上方清單列表中的登入帳號，將會以下方的選項做相對應的處理。

Chapter 11 管理安全性 153

選 項 描 述

不建立 若有未出現在上方清單中的使用者帳號，則一律不准透

過此連結，連到遠端伺服器。

不使用安全性內容建立

若有未出現在上方清單中的使用者帳號，則一律以不帶

帳號密碼的不需驗證的方式來連接遠端伺服器，如：

Excel、Access。但能否連接成功，仍要由遠端伺服器是

否需要驗證來決定。

使用登入的目前安全性

內容建立 若有未出現在上方清單中的使用者帳號，則一律以目前

使用者的登入帳號「模擬」給遠端伺服器。

使用此安全性內容建立若有未出現在上方清單中的使用者帳號，則一律以下方

所指定的帳號密碼來連接登入遠端伺服器。

 

以下例子，是以一個 SQL 帳號「 John 」登入一台在電腦名稱為

「WIN2K8」上的 SQL Server 預設執行個體，並連接至同台電腦上的另一台名

為「SQL1」的具名個體。

 --在[WIN2K8\SQL1]個體上建立 Kitty 的 SQL 帳號 CREATE LOGIN Kitty WITH PASSWORD='AaBb123' GO --建立 Test 資料庫 CREATE DATABASE Test GO USE Test GO --建立 Kitty 的對應使用者

CREATE USER Kitty GO --在[WIN2K8\SQL1]個體的 Test 資料庫中建立人事表 CREATE TABLE 人事表 ( 員工編號 INT, 姓名 NCHAR(10), 薪資 MONEY )

GO INSERT INTO 人事表 VALUES(1,'王小明',30000) INSERT INTO 人事表 VALUES(2,'李小英',28000) INSERT INTO 人事表 VALUES(3,'林大雄',26000) INSERT INTO 人事表 VALUES(4,'廖小美',32000) GO

MCTS: Microsoft SQL Server 2008 專業認證手冊 154

--建立一預存程序來取得相關資料及資訊 CREATE PROC usp 人事表

AS SELECT @@SERVERNAME AS 伺服器名稱, SUSER_SNAME() AS 登入者名稱, USER_NAME() AS 使用者名稱, * FROM 人事表

GO --授權讓 Kitty 可以執行此預存程序

GRANT EXECUTE ON usp 人事表 TO Kitty

圖 11-6：在[WIN2K8\SQL1]個體上做帳號、資料庫、資料表的相關處理

Chapter 11 管理安全性 155

圖 11-7： 在預設個體上建立「連結伺服器」，指定「John」

帳號對應遠端伺服器上的「Kitty」帳號做連接登入

MCTS: Microsoft SQL Server 2008 專業認證手冊 156

圖 11-8：以「John」在預設個體上執行遠端呼叫查詢

此外，「連結的伺服器」中的「伺服器選項」設定，也是在進階考試及操

作實務上值得注意的部份。比如：是否在透過此連接做連線時使用遠端定序 (若定序不同，則會查不到資料)？是否開啟 RPC(才能執行遠端預存程序)？可

以透過「sp_serveroption」預存程序或 SSMS 的圖形化介面來完成(伺服器→

「伺服器物件」→「連結的伺服器」→「新增連結的伺服器」→「伺服器選

項」)，若需詳細的相關的選項說明，讀者可自行查閱 SQL 線上叢書。在此處

筆者所示範的例子，必須開啟 RPC 才能順利執行。

Chapter 11 管理安全性 157

圖 11-9：「連結的伺服器」的「伺服器選項」設定

11-2 認證(Credentials)

自 SQL Server 2005 開始提供了讓 SQL Server 能夠連接至 SQL Server 以外的 Windows 領域的機制。由於離開了 SQL Server 之後，就是 Windows 網域的管理範圍，SQL Server 也必須擁有合適的網域帳戶才能在網域環境中執行

各項工作，因此便設計了「認證」的功能。其實「認證」只是指定當 SQL Server 欲前往非 SQL Server 領域(即 Windows 網域)時，所能夠使用的適當網

域帳戶。

圖 11-10：認證的設定

MCTS: Microsoft SQL Server 2008 專業認證手冊 158

11-3 資料庫層級的安全性

11-3-1 資料庫使用者及角色

SQL Server 資料庫中的基本使用對象為「使用者(User)」，而「使用者」

可對應 SQL 驗證登入帳號、Windows 驗證網域的單一帳號或群組。其中以利

用網域群組的方式處理「登入帳號」及「使用者帳號」是較為方便的，可直接

讓同屬於網域群組的多位使用者有相同的資料庫使用權限，也較容易做到權限

的管理與指派。可利用「CREATE USER…WITH LOGIN=…」或 SSMS 圖形

化介面來完成建立或修改使用者帳號。當未指定對應何帳號時，則預設將會建

立與「登入帳號」相同名稱的「使用者帳號」。

值得注意的是，當資料庫發生還原或移動至非當初的原 SQL Server 執行

個體時，則在新的 SQL Server 執行個體上必須要有相對應的登入才能正確運

作。由於每個登入帳戶在 SQL Server 個體上被建立時，皆會有各自獨一無二

的 SID 識別碼，而 SQL Server 在運作服務時也是皆以此 SID 為辨識區隔的依

據。但一旦將資料庫換到新的 SQL Server 個體時，縱使已在新的 SQL Server 個體上建立了相同名稱的「登入帳號」，資料庫中當初所建立的「使用者帳

號」依然會發生對應不到「登入帳號」的問題，主要就是因為當初資料庫中的

「使用者帳號」所記錄應對應的 SID ，並非新的 SQL Server 個體上的同名「登

入帳號」的 SID。因此必須修改資料庫中「使用者帳號」以重新對應新的伺服

器上的「登入帳號」的 SID。此動作並不困難，但卻是許多人容易忽略或不瞭

解的地方。

--在資料庫中修改 Kitty 的使用者帳號重新對應名為 Kitty 的登入帳號 ALTER User Kitty WITH LOGIN = Kitty GO

資料庫角色(Database Role)，是另一項 SQL Server 可以讓管理人員容易控

管或配置權限的功能。管理人員只要將使用者帳號加入內建的資料庫角色，就

可以利用內建的 10 個資料庫角色來快速配置特定的權限給使用者。而若某些

使用者需要同時具備多項內建資料庫角色的功能，管理人員也可以建立自訂的

資料庫角色，再將此資料庫角色加入至多個內建的資料庫角色中，即讓此自訂

資料庫角色同時具備多個內建資料庫角色的能力後，管理人員只需將欲擁有多

項權限的使用者加入此自訂的資料庫角色中即可。

Chapter 11 管理安全性 159

當然，不一定要將自訂資料庫角色加入至許多內建的資料庫角色中，我們

也可以利用自訂資料庫角色的方法來方便管控已加入此角色的眾多使用者。當

管理人員對此資料庫角色授予權限時，即等同對加入此角色中的多個使用者同

時授予相同的權限。

11-4 伺服器、資料庫及結構層級的授權

SQL Server 以往只能透過伺服器內建的 8 種角色及資料庫的內建 10 種角

色來賦予使用者擁有不同的權限。但是往往會遇到內建角色所具備的權限無法

滿足實際現況的權限分派(不是過多、就是過少)，並且還要透過 SQL Server 的內建預存程序(sp_addsrvrolemember、sp_addrolemember)來完成角色指派。

自 SQL 2005 後，SQL Server 將所有權限逐一細分，並且皆統一使用 ISO 規定的 SQL 語法，利用 GRANT、DENY 及 REVOKE 來完成各種權限的賦

予。

由於各種權限非常多，管理人員可以透過「SELECT * FROM fn_builtin_ permissions(NULL)」來查詢 SQL Server 中所有的權限種類。

若需查詢有關伺服器層級權限的賦予狀況，可透過「SELECT * FROM sys.server_permissions」來得知；若需查詢有關資料庫層級權限的賦予狀況，

可透過「SELECT * FROM sys.database_permissions」或 sp_helprotect 預存程

序來得知相關資訊。

至於若欲查詢有關伺服器的主體，則可透過「SELECT * FROM sys.server _principals」或 sp_helplogins 預存程序來得知；至於若欲查詢有關伺服器的主

體，則可透過「SELECT * FROM sys.database_principals」或 sp_helpuser 預存

程序來得知相關資訊。

--賦予 Mickey 控制伺服器的能力(等同 sysadmin) GRANT CONTROL SERVER TO Mickey GO --賦予 Mickey 備份 Test 資料庫資料檔的能力 --但禁止 Mickey 備份 Test 資料庫的交易記錄檔 --(不同於 db_backupoperator 兩種能力皆擁有) USE Test GO

MCTS: Microsoft SQL Server 2008 專業認證手冊 160

GRANT BACKUP DATABASE TO Mickey DENY BACKUP LOG TO Mickey GO --賦予 Mickey 讀取整個資料庫的能力(等同 db_datareader) GRANT SELECT TO Mickey GO --賦予 Kitty 控制整個資料庫的能力(等同 db_owner) GRANT CONTROL TO Kitty GO

11-5 管理金鑰及憑證

自 SQL 2005 後， SQL Server 加入了完整的安全架構，包含憑證

(Certificate)、非對稱式金鑰(Asymmetric Key)及對稱式金鑰(Symmetric Key)。SQL Server 的安全架構大致如下圖：

圖 11-11：SQL Server 的安全架構

在 SQL Server 中，基於安全性，主要是以憑證或非對稱式金鑰為加密的

優先選擇，因為憑證或非對稱式金鑰皆以較為安全的非對稱式加密演算為基

礎。當然，我們也可以使用憑證或非對稱式金鑰來演算再產生出對稱式金鑰，

而利用對稱式金鑰加密大量的資料，因為對稱式金鑰是使用相同的演算法來加

密及解密，因此是比較有效率而且節省資源的。

Chapter 11 管理安全性 161

當然，本書著重在 SQL Server 認證考試指導為撰寫方向，若讀者想更詳

細了解各種憑證、金鑰的加密原理及 SQL Server 如何加密資料的使用語法

(SQL Server 具有四種加密資料的方法：憑證加密、對稱式金鑰加密、非對稱

式金鑰加密及片語加密)，請自行參閱線上叢書及其他 SQL Server 2008 或加密

安全……等相關書籍。

在 Windows 網域及 SQL Server 中，憑證是較被信任及安全的，憑證具備

以下特性：

屬非對稱式加密結構，較為安全。

具有固定目標主題的公開金鑰。

具有與目標主題有關的如姓名或電子郵件的可辨識資訊。

具有驗證期限。

由發行單位做數位簽章及辨識。

可透過匯入 / 匯出，以達到可攜性及備存性的目的。

沒有任何一種加密方式能夠全部適用於各種情況，那到底該什麼時候，該

使用何種加密方式？可注意下列幾點為考量因素：

愈強、愈堅固的加密通常會比較弱的加密法，消耗較多的 CPU 資源。

位元數愈多的金鑰能夠比位元數較少的金鑰產生較強固的加密。

當使用同樣長度的金鑰，非對稱式加密會比對稱式加密強固；但相對

的，非對稱式加密會比對稱式加密的速度慢。

較長較複雜的密碼會比較短的密碼強固。

當要加密大量資料時，應該使用對稱式金鑰來加密大量資料，再使用非

對稱式金鑰來加密此對稱式金鑰。

加密後的資料不能再被壓縮，但壓縮後的資料是可以再加密的。

加密方式 使用時機

憑證(Certificate) 憑證可用來加密連線通訊。在資料庫鏡像中可用來簽署封

包及其他物件，或用來加密資料及連線過程。

(非)對稱式金鑰 (Asymmetric Key /

非對稱式金鑰通常用來加密對稱式金鑰，或也可針對少量

的資料或資料庫物件用以加密。非對稱式金鑰可以維持私

MCTS: Microsoft SQL Server 2008 專業認證手冊 162

加密方式 使用時機

Symmetric Key) 密金鑰及公開金鑰的一致對應關係性。非對稱式金鑰可以

從具有強式名稱的檔案中匯入，但是不能被匯出。非對稱

式金鑰也沒有逾期的機制，並且也無法加密連線通訊。

11-6 透明資料加密(TDE, Transparent Data Encryption)(SQL 2008)

透明資料加密：此功能為 SQL 2008 的新功能，一定會考。

一般而言，我們有各種方式預防資料庫中的資料外洩，如：落實嚴格的帳

號控管、防堵資料隱碼(SQL Injection)攻擊、將 SQL Server 放在強大的防火牆

後、更換通訊埠 1433……等做法，但其中一種會出人意料之外的外洩方式，

就是實體資料檔(*.mdf、*.ndf、*.ldf)或備份檔的遺失或盜用。

由於備份檔即是資料庫的資料備份，一旦被有心人士取得，即可拿到另外

一台 SQL Server 上將其還原，就可以看到資料庫的資料；當然，有些管理人

員會在操作備份時，指定「備份 / 還原密碼」，其實這依然不是很安全的，因

為只要有心人士取得備份檔後，只要不透過正常 SQL Server 的還原方式，就

可不用指定還原密碼，而直接利用一些較低階、可閱讀位元組碼的軟體直接讀

取備份檔中的位元碼，依然可以看到備份檔中的蛛絲馬跡的資訊。

至於若實體資料檔(*.mdf、*.ndf、*.ldf)直接被有心人士取得的話，就更

危險了！因為有心人士可以另外自行安裝新的 SQL Server 個體，他的帳號一

定為系統管理員(sysadmin)，便可自行附加所取得的實體資料檔，資料庫中的

機密資料便因此而外洩！

在 SQL 2005 時，SQL Server 與 .NET Framework 結合後，即可使用各種

加密演算法來加密資料表中的資料，著實強化了資料的安全性，但終究必須一

張一張資料表，一欄一欄的執行加密處理，較為耗時費工。

因此 SQL 2008 提出了「透明資料加密」的功能，可以直接針對整個資料

庫的檔案層級加密，可防止當資料庫檔案被還原或移動附加到別台 SQL Server 個體後而曝露資料。原來的 SQL Server 執行個體在正常存取時，使用者是不

會感受到「加密」的操作動作，是由 SQL Server 在背後自動進行加 / 解密動

Chapter 11 管理安全性 163

作，使用者不需做任何語法的改變，完全依照平常的存取操作，因此才稱為

「透明」。

在使用「透明資料加密」的功能，可考慮以下幾點：

仍然會耗費一定的資源來執行加 / 解密資料的動作，可考慮不要使用在存

取負擔較重或資料庫中的資料機密性不高的資料庫。

若只有某些欄位或某些表的資料較為機密，可考慮使用 SQL Server 中的

各種加密演算函數來加密資料即可。

若資料庫有使用 SQL 2008 的 FILESTREAM 功能，儲存在 SQL Server 之外的 FILESTREAM 檔案並不會加密。

一定要備份用來處理「透明資料加密」功能的憑證，一旦遺失，就再也

無法開啟資料庫。

用於加密資料庫加密金鑰的憑證或非對稱金鑰必須位於 master 系統資料

庫中。

資料庫加密僅允許用於使用者資料庫，而非系統資料庫。

資料庫加密金鑰無法從資料庫中匯出。只有系統、擁有伺服器偵錯權限

的使用者，及可存取加密 / 解密資料庫加密金鑰之憑證的使用者可以進行

匯出。

使用「透明資料加密」，主要步驟如下：

1. 建立「資料庫主要金鑰」(DMK, DATABASE MASTER KEY)。

2. 透過「資料庫主要金鑰」來建立或取得匯入憑證。

3. 建立資料庫加密金鑰，並使用憑證予以保護。

4. 設定資料庫使用「透明資料加密」。

--切換至 master 資料庫 USE master GO --建立資料庫主要金鑰(DMK, Database Master Key) CREATE MASTER KEY ENCRYPTION BY PASSWORD='AaBb123' GO --使用 DMK 建立憑證 CREATE CERTIFICATE 伺服器憑證 WITH SUBJECT='伺服器使用憑證' GO