記得早在DOS的時代，就已經結合資料庫的相關應用軟體設計，當時由於正處於區域網路技術的醞釀階段，因此多半的應用系統都是採用單機資料庫的架構模式，平日的管理維護上也相對簡易許多，資安問題上，由於處在單機執行的環境中，規劃上往往只要對於實體的安全性進行管制即可，例如主機的隔離措施做好，病毒的防禦上過濾來往的磁片，至於資料備份就更加容易，只要定期做即可。DOS單機運作的時代，資料庫的維護與效能執行上似乎不會有太大的問題，對於資訊化所帶來的IT產值也相對有限。
看看十幾年後的今天，各項網路技術的蓬勃發展以及結合前端各類應用系統的整合方案（例如：ERP、CRM、SCM等等），幫助企業快速處理許多複雜的資料、自動化商業流程、決策系統支援，這一些應用系統的背後有一個負責大量資料處理的核心系統，就是所謂的關連式資料庫（RDBMS），要負責處理後端資料庫交易運算不會只是單一的應用系統，因此在各項效能管理、維護以及安全的設計上必須相當嚴謹，一旦與現有的網路環境搭上線，資料庫安全問題便會隨之蜂擁而上，這包含了資料外洩、資料庫損毀、中毒問題以及效能不彰等等問題。
如何有效解決以上所有可能的資安問題呢？從根本面來看必須拆解成三個部份，資料庫伺服器的安全建置、災害預防規劃以及前端應用程式的安全設計，如圖1所示，此為資料庫常見的幾項安全威脅，從遠端的登入存取、前端應用程式的連線存取到後端資料庫的安全問題，必須解決的問題包括帳戶密碼與權限的安全管理、內外防火牆的存取原則管制、傳輸通道的安全以及應用系統的安全設計。
資料庫伺服器的安全建置
在此以Microsoft SQL Server 2000為例，初步的安全性建置與後續的DBA管理維護上，務必符合下列幾項安全性要求：
* 永遠維持安裝最新的修正程式：除了作業系統本身的補強更新之外，所有與SQL Server本身修正程式有關的更新下載皆務必完成，截至目前為止Microsoft已發行了SQL Server 2000 Service Pack 4可供下載。不過在此建議凡是內部SQL Server伺服器的更新，最好能夠採用內部派送，也就是在企業網路中建置一部負責定時與Windows Update主機同步的系統，例如Windows Server Update Service（WSUS）或是System Management Server，甚至於是其它協力廠商的更新整合系統，如此一來對於SQL Server本身的更新安全更上一層樓，不過務必在進行正式安裝更新程式之前，與前端應用系統的廠商確認更新後的相容性是否會有問題，根據筆者的實務經驗，曾有完成修正更新之後，應用程式卻無法正常運作的案例。
* 結合MBSA弱點掃瞄的使用：MBSA（Microsoft Baseline Security Analyzer）是Microsoft所發行的免費弱點掃瞄程式，目前最新的版本為MBSA 2.0，如圖2所示，透過它可以讓管理人員結合Windows Update網站或企業內部的WSUS主機，來同時掃瞄多部作業系統以及包含MSDE與SQL Server系列產品的安全性問題，當然也會告知您目前安全性需要，及相關設定的方法。以下就讓我們了解一下，結合MBSA能偵測SQL Server的項目。
下載網址：http://www.microsoft.com/technet/security/tools/mbsahome.mspx。
* 大多的登入者是屬於Sysadmin伺服器角色的成員。
* 除了Sysadmin角色之外，有其它的角色也能夠建立與執行CmdExec相關的外部命令作業。
* 採用空白或太過簡易的碼設定。
* 薄弱的驗證模式選擇。
* 過多的資料庫存取權限給予Administrators群組成員。
* 對於存放資料庫資料檔案的資料夾，配置不當的存取控制清單（ACLs，Access Control Lists）。
* 有關預設sa的密碼資訊暴露在安裝記錄檔中。
* 將SQL Server安裝在網域控制站上面（不建議的安裝）。
* 對於Everyone群組的權限配置，例如提供修改某一些系統登錄值（registry keys）的修改權限。
* 對於SQL Server服務帳戶的不當權限配置。
* 缺少特定的Service Pack與安全性的修正更新。
* 採用Windows整合驗證模式：在SQL Server 2000的安裝中，系統會讓我們選擇需要採用的連線驗證模式，包含預設的唯一Windows驗證，以及混合式驗證（Mixed mode）兩種模式，在此建議採用唯一Windows驗證模式，可以提升使用者登入驗證時的安全性，此種驗證機制除了強化了驗證通訊協定，密碼複雜度要求與帳戶的使用期限設定，像是權限的委派設定部份也同樣只能夠使用在Windows驗證模式的環境中。如果您已經在安裝的過程中選擇了混合式驗證，如圖3所示，在安裝之後一樣可以經由SQL Server Enterprise Manager管理介面中，點選指定伺服器的屬性內容，然後在「安全性」的頁籤中進行驗證模式的變更即可。
* 資料庫伺服器的隔離防護：此部份包含了實體層與邏輯層的隔離規劃，前者建議您將重要的資料庫伺服器，安置在一般使用者無法接觸，甚至只有特定的IT管理人士可進入的區域中，而後者則是透過內外防火牆的防護，只讓特定前端應用程式與使用者進行連線登入存取，尤其架設在企業網路入口防火牆存取原則的控管上，務必不要開放可存取後端資料庫的相關通訊埠，以SQL Server為例便是TCP 1433與UDP 1434的通訊埠連線。
* 使用符合複雜度要求的密碼設定：一般IT人員在安裝SQL Server 2000的過程中，可能會習慣性地將預設的sa帳戶密碼設定為空白，或者是不符合安全性密碼原則的簡易密碼設定，事實上無論是你打算採用Windows唯一驗證或是混合驗證模式，都應當讓每一組的登入者密碼設定符合複雜度要求，並且讓密碼定期變更時間週期，如此才能夠做好資料庫安全防護的第一道防線。在即將發行的SQL Server 2005的登入帳戶安全管理中，已經整合了Windows本機的安全性原則，讓管理者新增登入使用者密碼的同時，直接參考密碼安全性原則的設定值來完成。
* 限制SQL Server服務的權限層級：在SQL Server 2000中有兩個主要的Windows服務常駐，分別為「SQL Server」以及「SQL Server Agent」，而這一些服務的啟動設定中都需要有一組相對應的Windows帳戶，為了避免有心人士在成功入侵作業系統之後，透過這一些使用的帳戶來延伸攻擊或存取其它的企業網路資源，因此在這兩個服務所使用的啟動帳戶設定中，請不要指定為本機系統（Local System）、本機管理員（Local administrator）、網域管理帳戶（Domain administrator）。另外，如果資料庫平日運作的過程中不會使用到SQL Server Agent服務，那麼建議可以將它關閉。
* 加強檔案目錄安全性保護：關於SQL Server安裝時所指定的資料檔存放位置，最理想便是指定儲存在NTFS格式化分割區中，唯有在這一個儲存分割區中，才能夠進一步設定該資料夾存取權限的配置（ACLs），以及加密檔案系統（EFS，Encrypting File System）的使用，前者可防止未經授權的使用透過網路或本機的連線登入來存取這一些檔案，而後者則是可以預防一旦檔案被未經授權的憑證用戶複製到其它地方，也無法開啟檔案檢視其資料檔內容。必須注意的是，一旦資料檔擁有人（例如Administrator）採用了EFS加密之後，如果這一些檔案打算變更存取權限的擁有人時，則必須先將它們以Administrator完成解密之後，接著再經由新的擁有人來進行加密設定，以避免萬一原EFS加密擁有人帳戶刪除之後，而導致資料檔無法存取的事件發生。關於EFS進一步的使用也可以結合CA憑證伺服器的使用，進行多位使用者的授權存取管理。
* 保護或刪除安裝記錄檔案：在SQL Server安裝或更新的過程中，可能會有一些記錄檔儲存著未加密的驗證資訊，以及一些敏感的組態設定資訊在裡頭，而這一些檔案可以由SQL Server指定或預設的安裝路徑中找到，在SQL Server 2000中包含了儲存sa或Windows帳戶密碼的Sqlstp.log，以及儲存存取控制清單的Setup.iss，而在叢集服務的環境中則有Remsetup.ini記錄檔，為了避免這些檔案資訊的內容危害到SQL Server本身，建議可以採取以下措施來解決此問題。
* 安裝SQL Server可以先選擇使用本機系統帳戶來啟動服務，之後再到服務設定中去更改即可。
* 完成安裝之後再去進行一次sa與Administrator帳戶密碼的變更。
* 可以到微軟的網站上去下載Killpwd.exe檔案，協助清除安裝檔案的密碼資訊。
* 稽核SQL Server連線：相信許多IT人員都知道Windows作業系統的稽核設定功能，事實上在SQL Server 2000中同樣也擁有此功能的設定選項，如圖3所示您只要在開啟SQL Server Enterprise Manager的管理介面之後，點選伺服器內容屬性中的「安全性」頁籤即可進行設定，在預設的狀態下該設定值為「無」，也就是說後續的記錄檔內容中是看不到任何有關的稽核資訊。在此建議您請將此頁籤中設定為「失敗」，有任何的使用者嘗試進行連線登入時，可以清楚透過記錄檔內容得知這一些失敗的連線記錄，進而著手失敗相關地防範措施。
如圖4所示若想要追蹤使用者對於SQL Server的連線存取狀況，必須藉由SQL Server 2000所提供的Profiler輔助工具來完成，在典型的案例中我們可以針對使用者登入的失敗事件，以及對於資料庫物件進行DROP與TRUNCATE時進行記錄，並讓這些記錄保存在指定的資料庫資料表中，以供管理者後續查詢使用。
* 防範重要資料庫物件與資料的誤刪：針對一些重要的資料紀錄，為了避免遭到使用者的誤刪可以透過觸發（Trigger）的設計來加以防範，可是在SQL Server 2000中並無法對於資料庫物件（例如資料表、預存程序）的誤刪行為，透過觸發的設計來加以防範，不過在即將發行的SQL Server 2005中已經可以支援DDL的觸發機制來解決此問題。
* 其它注意事項：在預設的SQL Server 2000安裝中，系統會自動安裝兩個範例資料庫分別為Northwind與Pubs，由於只是用來供教學使用，因此建議您將它手動移除，此外對於在生產線使用的資料庫，除了對於一般使用者的權限配置之外，對於自訂的預存程序執行權限務必給特定的管理人員使用，最後也請讓系統內建CmdExec外部命令列工具與函數，只開放給系統管理可執行它，這一點非常的重要！想要確認此功能是否已設定，請在管理工具中點選「SQL Server代理程式」的內容，接著在「作業的系統」的頁籤中便可以看到「只有擁有系統管理員權限的使用者可以執行CmdExec及ActiveScripting作業步驟」選項是否已核取。
資料庫災害預防規劃
在SQL Server 2000中對於平日資料庫的維護方法，最快的方法就是使用「資料庫維護計畫」精靈來完成，透過它每一個選用性的頁面設定可以完成資料庫最佳化重整、資料庫完整性檢查與修復、資料庫排程備份設定、資料庫維護計畫報告產生、傳送交易記錄檔至另一部SQL Server 2000主機（企業版專屬功能）。
至於資料庫的備份方式與排程設計，可依照資料庫資料異動的頻率與其重要性來進行規劃，一般性的資料庫可以一天設定兩次完整備份在中午與半夜，而對於像是ERP方面的資料庫，則可以採用備份排程較為密集的「交易記錄檔備份」。接下來我們要針對所有重要的資料庫設定交易記錄檔備份排程，以便於管理者可以隨時還原任一交易記錄檔備份的時間點，例如以每一個小時作為每一次交易記錄檔的備份間隔時間，不過在此必須特別注意有關交易記錄檔的備份排程設定，必須相依在第一次「完整備份」的時間點，以及最後一次「差異備份」的時間點為一個備份週期。
在預設的狀態下所有使用者的資料庫是無法進行交易記錄檔備份，這是因為在資料庫復原模型的設定中為「簡易」，我們必須先將該資料庫改設定為「完整」。請在選取指定的資料庫項目後，按下滑鼠右鍵點選「內容」然後切換到「選項」頁籤中，最後將模型下拉欄位的選項改為「完整」即可。完成了復原模型的「完整」設定之後，接下來我們開始設定整個交易記錄檔備份的排程計畫。首先請點選要備份的資料庫項目後，按下滑鼠右鍵點選「所有工作」\「備份資料庫」，接著在「一般」的頁籤中確認目前備份類型選取在「完整備份」，然後在目的地的方框中點選「新增」按鈕繼續設定備份檔案的存放路徑。完成完整備份的目的地設定之後，接下來請先確認覆寫的類型中已選擇「附加至儲存媒體」項目，最後請設定勾選「排程」選項然後點選「..」按鈕來設定排程時間，請設定整個備份週期的第一個時間點，完成後點選「確定」按鈕即可。
注意！建議您將備份檔案的路徑指向非系統開機磁碟機代號，以防止在作業系統發生損毀時，可以在重新安裝作業系統時不會影響到資料庫備份檔案。
緊接著我們必須繼續完成這一個備份週期的排程設定。請同樣再針對相同的資料庫項目，按下滑鼠右鍵點選「所有工作」\「備份資料庫」，從這一次備份的時間點到最後第二次的備份時間點都必須指定為「交易記錄檔」備份方式，因此您必須重複此設定直到最後第二次的時間點（例如設定相隔一小時一次），最後也請留意覆寫的方式必須為「附加至儲存媒體」，並且是指定覆寫相同的目的地檔案。在最後一次的時間點，請新增一個「資料庫-差異備份」，並且同樣在覆寫的設定中選擇「附加至儲存媒體」
如果在前面的SQL Mail與操作員設定中您有成功完成設定，那麼您便可以在完成排程備份設定後，經由展開「SQL Server代理程式」\「作業」項目後來開啟每一個排程作業的內容，然後切換到「告知訊息」的頁籤中勾選「電子郵件操作員」，在選取適當的操作員之後可以指定訊息通知的時機，例如「當作業失敗時」，每當任一時間點的備份作業失敗時，此操作員便會收到Email通知。
除了資料庫平日的維護與備份計畫的執行之外，高可用性整合部份可考慮建置多部的叢集服務（Cluster Service）主機，做到資料庫伺服器相互備援的目的地，此種方式是針對整個資料庫伺服器進行自動容錯備援的機制，必須有一部共同存取的儲存設備（例如：DAS），在硬體花費的成本上會高出許多。
第二種方式則是可以結合其它協力廠商的HA產品來完成，雖然在硬體的成本上可以大幅降低許多，相對地在軟體授權的花費上卻相當可觀，自動容錯移轉的回復時間也比傳統的叢集服務來得長，並且在管理維護上也複雜許多。
最後一種方式，則是可以考慮採用SQL Server 2000的企業版交易紀錄檔傳送功能（如圖5所示），來自動完成資料庫遠端備份的機制，它主要是用來針對指定的資料庫，複製交易紀錄檔的來源，以及目的地交易紀錄檔功能，並且透過一部擔任監控的Monitor Server，來負責收集與檢視它們之間的運作情形，當然也可以由Primary Server同時擔任Monitor Server，只是一但Primary Server發生停止運作時，Monitor Server也將無法繼續監控，而且它們彼此間的角色互換是無法自動完成的，必須經由管理人員透過預存程序sp_change_secondary_role的執行才可達成。
關於企業版交易紀錄檔傳送功能的備援機制，在SQL Server 2005中已可由全新設計的資料庫鏡射（Database Mirroring）技術所取代，因為它改善了沒有自動角色切換的機制，並且讓前端的應用程式搭配ADO 2.0的容錯移轉連線特色，來自動判斷目前可連線的資料庫所在的伺服器，因此管理人員不需要手動去變更DNS的紀錄設定或IP位址與電腦名稱的修改，更重的要的是這項自動容錯的移轉時間遠遠比傳統的叢集服務的容錯時間還要更短，相信此項備援容錯機制的解決方案可以作為IT導入規劃時的評估。
前端應用程式安全設計
在前端的應用系統的設計中，最令人擔憂的部份就是與後端資料庫連線驗證的設定內容外洩，以下說明幾點可能的安全性缺失與解決方法：
* 若採用SQL Server驗證方式，在連接字串的內容中便需要指定驗證的帳戶與密碼的資訊，因此建議改用Windows驗證方式。
* 連接字串直接嵌入在程式碼中。一般來說有關應用系統與後端資料庫的連線登入設定字串，皆會儲存在專屬的組態設定檔之中，例如Web.config。
* 使用了一般未加密的連接字串。如果能夠對於連接字串的資訊內容進行雜湊加密處理，可以大幅提昇此部份的安全性。
* 用戶端到前端的應用系統通訊使用了明碼通訊方式。一般來說應用系統的預設通道模式都會採用明碼來傳送，如果再加上使用SQL Server驗證的話，則傳送中的帳戶密碼資訊將會輕易遭受到竊聽，如果是在網際網路上的Web應用程式，就可能遭到有心人士竊聽到Response與Request往來資料內容。有鑑於此，請選擇以Windows的驗證方式來連接資料庫，並且建置SSL加密通道的安全模式在用戶端到前端應用程式之間，至於前端應用程式到資料庫伺服器之間，則可以使用IPSec的通道模式來完成。
* 開放無限大的權限給前端應用系統的登入。筆者曾經看過許多的應用系統在設計上常常忽略掉此部份的安全性問題，如此一來萬一發生了該使用者帳戶被入侵或是被惡意程式碼的破解，那麼資料庫伺服器此刻要殺要剮便由駭客全權作主了。因此對於資料庫系統開放給前端應用系統的專屬帳戶權限，請務必量身訂作，盡可能縮減到最小的適用權限最佳。
結 論
資料庫伺服器的整體安全設計可以說是企業e化安全規劃中最複雜的一塊，不同資料庫系統廠商針對自家的產品，所推出的的安全架構設計建議也不盡相同，因此難以一文道盡每一個細節的安全設計技巧，不過若您仔細發掘，大體上不外乎是帳戶權限的管理、稽核管理、隔離管制、備援備份的設計以及前端應用系統的安全規劃等等。以微軟的SQL Server產品來說，如今在Technet的網站上已經有許多的相關安全性資源可供參考，建議您不妨連結到SQL Server的安全中心，進一步學習更多的安全規劃技巧，為企業的商務應用環境打造真正高安全度的後端資料庫管理平台。
參考網址http://www.microsoft.com/technet/security/prodtech/sQLserver.mspx。
作者現任高傑信公司技術顧問、Microsoft MVP&特約資深講師，專精於企業資訊安全部署規劃以及Windows Server System整合技術。