SQL Server 安全總體架構簡介

安全是資料庫管理與開發人員需要密切注意之課題，維護系統安全可視為一系列的措施與步驟，一般也稱為防禦縱深。 SQL Server 2005版後，大幅強化了縱深中的各個項目，我們在此整理一個初略的大綱，讓你對相關的安全技術有個概念後， 再選擇要加強系統中的哪一環。

首先，分門別類地列出相關技術：

再依據這些技術出現的SQL Server版本，或是不同版本強化了哪些內容製作成表2：

微軟從2003年起，為了洗刷先前使用者對其安全不佳的印象，且為了打進企業核心，開始大幅強化安全， 喊出「secure by Design, secure by Default, and secure in Deployment」的安全3D口號。 因此，其後的Windows 2003和SQL Server 2005都以安全為前提設計、設定與部署。 最明顯的差異就是Windows 2000和SQL 2000安裝完畢後，所有的功能都是開放的。 但有些系統因為IIS漏洞而被攻破，管理人員卻渾然不覺，在哪個年代大部分IT人員可能完全不了解網站為啥。 但Windows 2003預設為儘量關閉服務，需要管理人員自主開啟，因而需要記載在企業的組態管理中， 自然較有警覺。

SQL Server 2005亦是相同，安裝完SQL Server 2005後，所有對外的存取介面如Email、xp_cmdshell… 等都先關閉，待資料庫管理師要用時才開啟。並從此版開始提供憑證、簽章、驗證、 資料頁以Checksum檢查正確性…等。

以下針對上述列表中，各安全項目擇要說明。

部署

首先，基礎不安全，就不安全。如果安裝SQL Server的伺服器環境不夠安全， 即使SQL Server本身是安全的，但駭客的手可以摸到實體機器，難保不被破壞或入侵， 應嚴格限制對實體伺服器和硬體元件的存取。例如，將資料庫伺服器硬體和網路裝置放 在上鎖與限制存取的機房內，透過跳板與監控室才能取得高權限帳號，執行管理作業。 此外，備份媒體應儲存在安全的異地位置，同樣需要限制存取與加密內容。

由於SQL Server是執行在Windows/Linux作業系統的應用程式，且資料庫的實體檔案是 放在Windows/Linux上，若作業系統不安全，一切也都是假的。因此，檔案系統是否安全， 並嚴格地管理帳戶與授權、防病毒與木馬…等，都需要考慮。

強化安裝過程對服務帳號、使用者登入/授權的安全要求

SQL Server 2008版後，強化了安裝精靈對服務帳號、System Admin伺服器角色成員的要求， 讓安裝者注意到，且可選擇適當的Windows帳號來執行各項服務。

搭配防火牆與網路安全設定

防火牆有助於保護電腦資源，或部分的惡意攻擊。一般會將SQL Server安裝在防火牆之內， 並儘量不用預設的設定，避免駭客掃描已知的檔案路徑、網路埠號、最高權限帳號…等。 透過「SQL Server 組態管理員」工具程式更改SQL Server資料庫引擎所聽的埠(Port)號碼， 這需要搭配前端程式修改連線字串(我們較建議此種做法)，或是透過UDP 1434詢問 SQL Server Browser 服務，SQL Server所支援的埠號碼為何。

最小接觸面與介面區組態原則

就管理人員而言，越小的防護面越好，一般SQL Server 對外存取只啟用應用程式需要的功能， 藉此保護伺服器。尤其像sp_OA*或xp_cmdshell等功能強悍的系統延伸預存程序， 當應用程式有SQL Injection風險時，就容易讓駭客透過這些系統預存程序存取各項系統資源。 而除了透過「原則(Policy)管理」所控管的「介面區組態Facet」檢核與關閉前述功能外， 還要注意的是：使用Agent Services也要小心，它的PowerShell、CmdExec和ActiveX Script 等類型之作業步驟也具備影響系統相同的能力。

認證

談安全的基本要先確認使用者的身分，然後依身分授權。SQL Server認證使用者身分的方式有好幾種， 分別是依靠：

• AAD/AD/Windows作業系統：由身分驗證服務確認使用者身分，告知SQL Server來者何人。
• SQL Server自己儲存帳密，自行驗證：不管是伺服器登入，將帳密存在Master系統資料庫， 還是「有密碼的SQL使用者」，將帳密存在一般的使用者資料庫，都由SQL Server自行保管帳密。
• 依憑證認證：一般運用在程式溝通時，利用憑證與簽章設定程式身分。

微軟建議儘可能使用搭配網域與Kerberos的Windows驗證與登入帳號登入SQL Server， 這是因為Windows在保護帳戶資訊的功能較SQL Server為佳，其使用Kerberos安全性通訊協定採三方驗證， 本身就強化安全外，使用者應用程式可能以明碼的方式到處存放SQL Server帳/密資訊。 當然，若應用程式不是直接以自身的服務帳號登入SQL Server，要轉換成特定的系統帳號登入 SQL Server，也有可能會簡單地存放帳/密，則依然不安全。

授權

階層式角色存取安全架構

SQL Server 提供之「角色為基礎的安全」在整體設計架構上，可以大分為三類物件：

• 主體(Principals)：如登入帳號(login)/伺服器角色與資料庫的使用者(user)/資料庫角色、應用程式角色等。
• 安全性實體(Securable)：可被賦予存取權限的物件，如資料庫、資料表、預存程序…等。
• 權限(Permission)：對於安全性實體可執行的動作，如CREATE、SELECT、EXECUTE…等。

因為資料庫的使用者來來去去，可能因為公司員工新進、升遷、離職…等因素，而需要改變存取權限。 企業中的工作角色變異較小，因此，最好設定擁有不同權限的角色，將使用者賦予成該角色， 自然獲得正確的權限。當使用者身分轉變時，僅需要改變該使用者的角色即可。而授權就是設定 某個主體對某個安全性實體有某種權限，例如：使用者甲(主體)可以SELECT(權限)資料表A(安全性實體)。

SQL Server 的授權結構具備階層性，主要分為：伺服器、資料庫、結構描述(Schema)、 物件(如資料表、檢視、預存程序…等)，階層間的授權並具有繼承性，例如，授權某個資料庫使用者 可以查詢某個結構描述，則該使用者預設可以查詢該結構下的物件。前述三者：主體、安全性實體、 權限各自皆有階層繼承關係。

一般而言，基於安全的最小權限原則，會避免賦予高權限給不需要的主體，讓主體儘可能地僅擁有 完成工作所需的權限。此外，尤其要限制擁有最高權限的主體之數量，例如：不要讓SysAdmin角色 內有多餘的帳號，且避免加入Windows群組，導致DBA無法掌控那些Windows帳號可以最高權限登入。

在極其講究安全的環境，在受監控的時空下，才可使用最高權限登入。例如：在有特定錄影的房間 與機器上，才可以最高權限登入。且這類帳號的密碼定期變更，使用時需要申請，使用期限到即封閉。

透過DCL陳述式授權

SQL Server 2005版後，建置與維護大部份的功能都有標準的DDL、DCL語法，讓使用者不需要強記 特殊的設定做法。而所有的權限多以DCL來設定，且提供精細獨立的權限，這也稱為 「All Permissions Grantable」或「Granular Permissions」。

程式碼存取安全

SQL Server 2005版後，允許透過.NET Assembly提供各種資料庫物件，如預存程序、使用者自訂 函數…等5種。但由於.NET有強大的能力，必須要防護在資料庫伺服器執行的.NET程式碼不會傷害 SQL Server本身，乃至於作業系統與網路。

SQL Server要求.NET程式碼需要簽章，再透過用以簽章的憑證建立使用者，賦予該使用者權力以 限制程式功能，讓程式因本身的身分受到限制，與執行者的身分無關。若程式有不良意圖， 不管誰叫用該.NET物件，就算是管理者，因為程式身分無權，該程式再有能力也無法偷偷執行。

強化檢視系統資訊的授權

SQL Server 2005版後，使用者不可以直接存取系統資料表，必須要透過系統檢視表(View)、 系統預存程序或系統函數來檢視中繼資料(Metadata)。而不同權限的使用者檢視中繼資料時， 看到的結果亦不相同。

模擬不同身分

在授權給一般使用者帳號時，可能會遇到某個使用者在執行某項功能時，需要使用到特定的物件 存取權限，但該使用者在一般情形下，並無權直接存取該物件。因此，要經由某種管道，臨時 提高存取權限，而使用者並未永久擁有權限。此種設計在撰寫服務程式時常常發生，服務程式 可能以本身帳號存取，或是模擬當下呼叫的使用者，也可能是模擬特定使用者來存取特定資源。

在SQL Server 2000以前，可以透過應用程式角色(Application Role)搭配預存程序等伺服器物件 來完成，藉由sp_setapprole系統預存程序，輸入特定的帳號/密碼將Execution Context換成 應用程式角色，以取得原來使用者所不具有的權限。

SQL Server 2005版本後，可以更直觀且彈性地透過模擬身分的機制來完成。在定義預存程序或 使用者自訂函數時，使用WITH EXECUTE AS語法；指定該預存程序或函數執行時，不以呼叫者的 身分執行，而是模擬(impersonate)成另外一個帳號。

在執行批次語法時，也可以使用如下的語法：

關於授權的討論除了上述各點外，還要注意資料庫是否啟用「guest」使用者的存取權。 如果不需要，請移除「guest」使用者的存取權。且要小心賦予執行個體與資料庫的「Public」 角色權限，因為執行個體所有的登入和資料庫內所有使用者都各自屬於該層的「Public」角色。

資料列層級安全

SQL Server 2016版後提供了資料列層級的RLS(Row Level Security)，簡單地說就是用來 限制使用者可以存取哪些資料列。RLS透過使用者自定函數規範用戶執行SELECT、DELETE以及 UPDATE語法時，可用到的記錄。

監控與稽核

監控務求儘早發現儘早補救，而稽核則要保證每個人對其所作所為不可否認。 雖然SQL Server提供了諸多的監控與稽核機制，卻多未與通知結合，且缺乏對分散式多個系統 的監控與稽核資料的統籌搜集、報表、分析、歸檔…等配套措施。換句話說，僅是蒐集存放 「人、事、時、地、物」的資料，如何有效運用還需巧思規劃。

稽核

SQL Server 2008後新增稽核(Audit)物件，可蒐集要監視的伺服器或資料庫層級動作和動作群組。 稽核位於SQL Server執行個體層級，各執行個體可設多個稽核。定義稽核時，會針對結果的輸出 指定位置，如檔案、Windows的安全或應用程式記錄。預設狀態為「停用」，不會稽核任何動作。 啟用後，稽核接收到的資料會存放到目的地。

定義了伺服器執行個體的「稽核」後，尚需定義「伺服器稽核規格(Server Audit Specification)」 和「資料庫稽核規格(Database Audit Specification)」。建議可針對每個「稽核」建立一個 「伺服器稽核規格」，這兩者都是定義在SQL Server執行個體層級。定義稽核規格時， 可選擇預先定義好的「稽核動作群組」，這些動作是資料庫引擎不可部分完成的事件。 動作發生時會傳送相關資訊給稽核，以記錄在儲存位置中。

同樣地，每個「稽核」可針對不同的資料庫建立一個「資料庫稽核規格」，需將資料庫等級的 稽核動作群組或稽核事件加入至資料庫稽核規格。「稽核事件(Audit Event)」也是不可部分完成的 動作。同樣有預先定義的「稽核動作群組」事件群組。動作發生時傳送相關資訊給「稽核」， 以記錄在儲存位置中。

SQL Server 2019版後，稽核可以搭配資料分類(classify)，方便辨識存取個資留下的稽核紀錄。

透過Temporal/總帳資料表可追蹤資料變化

上述的稽核資料可以看到使用者下的增、刪、修、查語法，但無法知道實際的資料內容。 搭配SQL Server 2016版提供的Temporal資料表功能，可以針對執行語法的當下資料比對稽核取得 的T-SQL語法，以了解使用者處理的資料內容。SQL Server 2022版後基於Temporal資料表和 區塊鍊技術提供了總帳資料表，以確認整個紀錄變動的歷程未經竄改。

DDL/DML觸發程序

觸發程序是在動作發生後，所執行的一段自定程式碼。DML觸發程序是在INSERT、UPDATE 及DELETE 陳述式上操作，一般建於資料表或檢視，修改資料後，協助保持資料的完整性。DDL觸發程序是在 執行CREATE、ALTER、DROP和其他DDL陳述式，及類似DDL作業的預存程序後啟動。一般執行管理工作， 用於個別資料庫或整個伺服器。

可藉由DDL/DML 觸發程序，記錄這些事件的發生。因為觸發程序是包在相關陳述式所開啟的交易內， 它可及時遏止事件的進行(Rollback)，但也對效能的影響較大，須小心使用。

監控

一直以來，SQL Server可以透過SQL Trace即時監控SQL Server當下所發生的各種事件， 例如，登入、交易、執行語法、各種錯誤…等，搭配SQL Server Profiler工具程式在前端檢視。 SQL Server 2008版後導入「擴充事件」功能，具有可高度擴充及設定的基礎結構， 讓使用者收集所需的資訊，且消耗較少系統資源，並搭配Management Studio提供的圖形化使用者 介面或Transact-SQL完成設定，或以Management Studio監控SQL Server當下觸發的各種事件。

私密性

具有機密性的資料，在整個資料生命週期中，應隨時保持加密，僅在特定時空可以解密。 因此，存放與取用的過程中，SQL Server要能一直保持資料加密的狀態。但這往往破壞效能、 高可用性、資料整合…等架構與應用，因此，有許多選項與環節可以依需求設計與使用。

網路存取

SQL Server預設透過TDS(Tabular Data Stream)通訊協定溝通，其內容是明碼。若怕網路偷窺， 可以透過Windows平台的IPSec或網路設備加密，也可以直接透過「SQL Server 組態管理員」工具 程式啟動SQL Server預設支援的TLS/SSL加密，或是由用戶端要求TLS/SSL加密。 SQL Server 2022後支援TLS 1.3版協定。

金鑰管理階層結構與可延伸金鑰管理(Extensible Key Management EKM)

若要加/解密資料，需要先考慮如何管理金鑰，若金鑰保護不周，或是保存不善，可能導致資料 依然外洩，或是系統損毀後，資料無法還原/解開²。

SQL Server預設的做法是：執行個體利用Windows的DPAPI服務來加密本身的主鑰匙， 而後利用執行個體主鑰匙加密各資料庫的主鑰匙。各資料庫的主鑰匙可以用來加密資料庫內 多個憑證或是非對稱鑰匙對。而透過憑證和非對稱鑰匙對再繼續加密對稱鑰匙， 以此提供完整的鑰匙管理階層架構。

現今，某些硬體廠商提供「硬體安全性模組(Hardware Security Modules，HSM)」產品， 來處理企業金鑰管理。HSM裝置會將加密金鑰儲存在硬體或軟體模組，這是較安全的解決方案。 因為加密金鑰不會與加密資料存放在一起。且可以僅授權DBA管理資料庫，但無權存取HSM， 使用者有權使用HSM的鑰匙加/解密資料，但無權管理資料庫。且在跨SQL Server執行個體使用 相同鑰匙加解密資料時，可以存取共通的HSM。

SQL Server 2008後的可延伸金鑰管理(Extensible Key Management EKM)讓EKM/HSM協力廠商 在SQL Server中註冊其模組。註冊之後，SQL Server使用者就可以使用儲存在EKM模組上的加密 金鑰，讓SQL Server 存取這些模組支援的進階加密功能(例如，大量加/解密)和金鑰管理函數 (例如，金鑰過期和金鑰循環)。

資料內容加密

管理憑證和加密鑰匙，可在資料內容加/解密、Service Broker Services…等地方使用憑證或鑰匙， 提供各種加/解密和簽章等機制的T-SQL語法和函數。

透明資料加密

SQL Server 2008版後的「透明資料加密(TDE)」讓你無需修改應用程式，就可以完成資料加密的目的， 其所保護的單位是使用者資料庫，與前述保護資料欄位內容不同。也就是在資料庫層級， 利用「資料庫加密金鑰(Database Encryption Key，DEK)」，對目標資料庫的資料檔與交易記錄檔， 以及tempdb系統資料庫，進行即時的磁碟I/O加/解密。其運作方式為將記憶體的資料分頁(Page)寫入 磁碟前先加密。完成加密後，仍會計算總和檢查碼(checksum)保護分頁。

分頁載入記憶體之前，會先檢查總和檢查碼，偵測分頁是否受損，總合檢查碼無誤，便解密分頁資料。 換句話說，在記憶體內的分頁都是明碼。而資料庫備份就是抄寫資料庫檔案和交易記錄，所以若資料庫 有加密，備份就有加密，無須特別處理。

雖然透明資料加密會增加CPU使用量，但因為載入記憶體的資料都已經解密，對於效能的衝擊很低， 也不會增加資料庫的使用空間。但須提醒一點的是：某個使用者資料庫啟動TDE後，導致該執行個體上 的tempdb系統資料庫也被加密。雖微軟強調TDE影響效能不大，畢竟記憶體內是解密的。 但若硬碟I/O很多，不停地增刪修記錄，尤其是tempdb多是增刪暫存資料，這可能會對於相同 SQL Server執行個體所有的資料庫造成效能上的影響，因為存取其他未啟動TDE的使用者資料庫時， 仍有可能要用到tempdb系統資料庫。

備份加密

SQL Server 2014版後可以針對備份檔使用憑證的金鑰加密，其機制與上述透明資料加密相同， 但僅針對備份檔而不影響線上系統，這可提高存放異地備援的安全性，尤其是選擇備份到雲端等 其他供應商提供的儲存位置。

一律加密

透過.NET 4.6版之後的SQLClient函式庫加上SQL Server 2016後的版本，可運用程式先加密資料後 再存入SQL Server，而加密主金鑰則保存在客戶信任的環境之中，並允許應用程式存取。 只需要資料庫管理師定義資料行的加密方式，程式設計師在撰寫應用程式時，資料的加解密過程 完全透明，現有的應用程式不需要撰寫額外的程式碼，再加微幅調整就可以使用這項功能。

對資料行的加密要小心嚴重傷害效能，除了每筆紀錄個別加/解密外，可能導致SQL Server最佳化引擎、 平行運算失效。若不是在開發時期就測試對效能的影響，並設計特別的資料結構與處理邏輯， 系統上線後才打算補做資料行加密，務必三思。

動態資料遮罩

SQL Server 2016版後內建此功能，當使用者查詢敏感性資料時，若其權限不足以看到完整資料， SQL Server會以事先定義好的遮罩模糊資料後回傳，例如：查詢人名「胡百敬」，SQL Server 傳回「胡O敬」或「胡XX」。省去自行撰寫程式或使用協力廠商的工具來達到相同效果， 保護機密資料不外洩。

SQL Server 2022後讓檢視原始資料的權力細到欄位，不同角色的使用者得以檢視不同資料行遮罩組合。

輔助系統的安全

SQL Server除了本身資料庫引擎需有強固的安全機制外，在資料生命週期中，其實是不斷地在 進行搬移與整合的工作。因此，SQL Server提供了「連結伺服器」與「特定分散式查詢 (Ad Hoc Distributed Queries)」、PolyBase…等鏈結外部系統的功能。善用這些功能， 讓我們可以方便地在系統間搬移資料，但也可以因而成為竊取與竄改資料的跳板。

此外，SQL Server資料庫引擎需要Agent Services輔助日常的維運，因此，Agent Services 往往需要有大權限與SQL Server資料庫引擎溝通，且有足夠的權限存取作業系統乃至於網路資源。 SQL Inject攻擊常做的就是加一些名稱看起來正常，但意圖不軌的Agent Services工作，因此， 我們需要了解Agent Services獲得授權的方式。

SQL Server 2005後，可以.NET撰寫SQL Server內部的物件，如預存程序、函數…等，這開啟了 延伸SQL Server資料庫引擎功能的方便之門，而不若以往需用C/C++來完成。但功能越強也等同 破壞力越強，因此，需要了解.NET執行環境本身的安全機制，讓資料庫內的.NET程式不能成為木馬。

SQL Server維繫安全的工具

維繫整個資訊系統安全的工具與平台在市場上非常多，且有多種分類與用途，在此不談， 僅針對SQL Server自己提供的工具程式，就安全面向的應用說明。因為大部分的工具程式與機制 都是廣用的，並非單純只用在安全維護。

「原則(Policy)」檢測

「以原則為基礎的管理」用於管理一個以上SQL Server執行個體，內建了許多判讀伺服器設計與 運行的邏輯，其中部分與安全有關。

SQL Server 2008後，隨附了許多微軟預先定義的最佳做法之原則，「匯入」這些原則後， 可以檢視「類別目錄」屬於「Microsoft 最佳做法：安全性」和「Microsoft 預設為[關閉]： 介面區組態」之原則，觀察SQL Server與安全相關的議題，並著手定義自己所需的安全規範， 在多台SQL Server執行個體施行原則，並監控原則的執行與分析結果。

伺服器追蹤(SQL Trace)與SQL Profiler/擴充事件(Extended Event)與SQL Server Management Studio

伺服器追蹤和擴充事件的實作方式不同，但功能相同，都是廣用性地記錄SQL Server執行當下作業時， 所觸發的各種事件。如果SQL Server發生的事件是列在追蹤定義內之事件類別，就會被SQL追蹤蒐集。 你可設定篩選這些事件，決定是否放入目的地的中。

Extended Event的目的地就更多樣化了，因為它是取代SQL Trace的機制，所以除包含SQL Trace的 所有功能外，且更有效率，記錄與累積事件的方式也可以選擇，不僅僅是每個事件的細節， 也可以彙總發生次數的數量，讓管理者有更多彈性的選擇。

事件通知(Event Notification)

事件通知會將這些事件的資訊傳送給SQL Server Service Broker，以回應各種Transact-SQL 資料定義語言(DDL)陳述式和SQL追蹤事件。事件通知以非同步方式在交易範圍以外執行，因此， 與「DDL 觸發程序」不同的是，事件通知可在資料庫應用程式中使用，但不影響當下進行的交易。

事件通知可用來執行下列工作：

• 記錄和檢閱發生在資料庫的變更或活動。
• 以非同步而不是同步的方式執行動作來回應事件。
• 事件通知可提供程式設計替代方案給 DDL 觸發程序和 SQL 追蹤。

與SQL追蹤不同的是，事件通知可在SQL Server執行個體內執行商業邏輯，以回應SQL追蹤事件。

其他

安全上有其他需要注意的事項，例如，資料完整性與被惡意破壞後的復原：

驗證資料分頁的正確性

資料庫的「Page Verify」屬性在2005版改用「總和檢查碼(Checksum)」而不建議再用2000版的 「TornPageDetection」。兩者都是確認資料分頁有沒有壞，但Checksum是計算整頁的雜湊值， TornPageDetection只取幾個特定位置的bit加總，不夠精準。當分頁從記憶體寫入硬碟時， 就會計算Checksum或TornPageDetection值，一併寫在該頁。從硬碟讀出時，會先計算這個值， 與寫入時所計算的值比較，若不相同，則認定該分頁損毀，這可防止硬體意外，也保護惡意 竄改資料庫檔案資料。

復原

當系統遭到破壞後，例如：資料表內存有大量遭SQL Injection加入的Script、隱藏了不好的 預存程序，或是資料被竄改、物件被刪除，乃至於被惡意撐爆的資料庫檔案/交易記錄、系統損毀…等， 如何即時快速地回復到正常狀態，這等同考驗你對系統高可獲得性的規劃。

¹ 參考線上說明：https://msdn.microsoft.com/zh-tw/library/ms143504(v=sql.120).aspx#MSA。 SQL Server 2016以後開始支援群組受管理的帳戶，並應用於叢集。

² 可以類比金鑰管理成家門鑰匙，若是放把鑰匙在門邊，或是搞丟鑰匙， 都是極糟糕的事🙁。