SQL Server 安全組態設定指南 (GCB & CIS)


  1. 資安實踐
    1. 系統管理員帳戶應強制執行密碼逾期
    2. 執行強制執行密碼原則
    3. 關於 SA Login 的那些事情兒
    4. 服務帳號的權限限制
    5. 移除 Guest Connect Permissions
    6. 檢查孤立使用者
    7. 自主資料庫安全措施
    8. MSDB 共用角色
    9. Instance Facet 設定
    10. spconfiguration
      1. 關閉跨資料庫擁有全鏈結功能
      2. 停用 CLR
      3. 停止掃描啟動程序
    11. 停用對資料庫的 Trustworthy
    12. SQL Server Logs 最大數目調整為 12 以上
    13. 備份 Master Key
    14. TLS 加密協定採安全設定 (停止 TLS 1.2 之下的協定)
  2. 建議項目
    1. 驗證模式採用 Windows 驗證模式
    2. SQL Server Default Port 使用非 1433 Port
    3. 停用遠端存取功能
    4. 隱藏執行個體
    5. 成功和失敗的登入都加入稽核
  3. 參考資料
  4. 相關連結

SQL Server DBA 的資安設定指南,邁向熟練的資料庫管理師之路,筆記 SQL Server 如何遵循 GCB 以及 CIS 提供的安全組態設定與最佳安全實務設定,來減少資料庫受到的攻擊點以及提升資安防禦 🏓

SQL Server Logo

資安實踐

系統管理員帳戶應強制執行密碼逾期

對於 SQL Login 而言較難執行,但改採 Windows 驗證的帳戶方式配合使用定期修改,可以 😁

執行強制執行密碼原則

對所有的 SQL Login 都應符合密碼原則,避免複雜度過低的密碼被破解登入。

對於 Legacy System 使用的 Legacy Login & Password 要調整有難度,但身為 DBA 總是得力挽狂瀾,耐心向開發人員溝通,以資安提升為目標,該改的密碼,絕對不是改天再改 😕

關於 SA Login 的那些事情兒

因為 SA 人盡皆知權限很大,直接停用 SA 或者變更 SA 名稱,避免被猜密碼。

改名 SA 不如直接把它停了,也好讓稽核人員知道你停掉 SA 了。關於 SA 建議直接停用並且另創具備 sysadmin 的帳號取代,如果使用 Windows 驗證帳戶更棒 😎

服務帳號的權限限制

SQL Server 使用的服務帳號 (SQL Server, Full-Text Service) 不能為 Windows Administrators 群組

移除 Guest Connect Permissions

除 master, msdb, tempdb 資料庫外,未避免不當的授權,應主動移除 Guest 的連線權限杜絕潛在的問題:

REVOKE GRANT FROM GUEST

如何確認?

SELECT USER_NAME(grantee_principal_id) as Principal,* 
FROM sys.database_permissions
WHERE USER_NAME(grantee_principal_id) = 'guest'

檢查孤立使用者

確認不存在孤立使用者,修復它或者移除它。

USE userDatabase;
EXEC sp_change_users_login 'report';

SQL Server Restore With Orphaned User Missing User (孤兒 / 孤立使用者)

自主資料庫安全措施

自主資料庫僅允許使用 Windows 驗證使用者且應停用自主資料庫自動關閉功能,但對於 DBA 而言直接 Deny 使用自主資料庫比較快 😋

MSDB 共用角色

msdb 共用角色不能具有 SQL Server Agent Proxy 存取權限

Instance Facet 設定

項目 最佳設定
AdHocRemoteQueriesEnabled False
RemoveDacEnabled False
OleAutomationEnabled False
XPCmdShellEnabled False
DefaultTraceEnabled True

XPCmdShellEnabled 一定要關,如果沒有任何理由要讓 SQL 去執行 Windows Command,留著這個萬一被 Injection 或其他資料庫類型的攻擊,會導致影響的範圍不僅是資料庫本身,更可能波及作業系統、區域網路甚至整個網域環境 😫 太可怕,關!關!關!

另外 DatabaseMailEnabled 被建議設定為 False,但 DBA 不建議這樣的設定,會讓 DatabaseMail 無法作用,如此一來 Agent 排程就無法透過 Operator 使用電子郵件通報錯誤了,關於啟用 DatabaseMailEnabled 的潛在風險,DBA 願意扛著 😡

項目 最佳設定
DatabaseMailEnabled False

spconfiguration

關閉跨資料庫擁有全鏈結功能

EXECUTE sp_configure 'cross db ownership chaining', 0;
RECONFIGURE;

停用 CLR

EXECUTE sp_configure 'clr enabled', 0;
RECONFIGURE;

停止掃描啟動程序

EXECUTE sp_configure 'scan for startup procs', 0;
RECONFIGURE;

停用對資料庫的 Trustworthy

除 msdb 外,都做這個調整,但具體的效益仍待商榷。

ALTER DATABASE databaseName SET TRUSTWORTHY OFF

因為要對很多資料庫做同樣的設定,可以自己來組裝 Script:

SELECT 'ALTER DATABASE' + name + 'SET TRUSTWORTH OFF' FROM sys.databases

SQL Server Logs 最大數目調整為 12 以上

筆記相連到天邊,調整方式直接參考⭐SQL Server 如何移除 ErrorLog

備份 Master Key

備份是一定要的。

一把服務主金鑰 (Service Maskter Key) 🔑
多把資料庫主金鑰 (Database Maskter Key) 🔑🔑🔑

TLS 加密協定採安全設定 (停止 TLS 1.2 之下的協定)

IIS CRYPTO 直接開下去,Best Practices 再關掉 TLS 1.1,重開機後,謝謝指教 😎

建議項目

驗證模式採用 Windows 驗證模式

這個真心難,除非是單一用途的 Instance 否則為服務多元的應用系統使用資料庫需求,混合模式的使用是必要的。

SQL Server Default Port 使用非 1433 Port

換了 Port 同樣是受到 NMAP 掃 Port 的潛在攻擊,同時內網的資料庫應用情境還是保持慣用的 TCP 1433 吧,對外的資料庫在考慮這項調整。

停用遠端存取功能

使遠端無法執行本機的預存程序;本機無法執行遠端的預存程序

目前還不清楚具體的影響範圍,先捏著不做這個調整。

隱藏執行個體

目前還不清楚具體的影響範圍,先捏著不做這個調整。

成功和失敗的登入都加入稽核

這個…資料量會不會太大?反而使失敗的事件不容易被觀察到。

EXECUTE sp_configure 'remote access', 0;
RECONFIGURE;

參考資料

政府組態基準(GCB)下載 | NCCST

相關連結

SQL Server 閃電般快速查詢指南⚡

SQL Server 周邊工具彙整筆記

SQL Server 學習資源筆記