SQL Server 安全性最佳做法
適用於：
SQL Server Azure SQL 資料庫 Azure SQL 受控執行個體
本文提供建立 SQL Server 安全性的最佳做法和指導方針相關資訊。 如需完整檢閱 SQL Server 安全性功能，請參閱保護 SQL Server。
如需特定產品的安全性最佳做法，請參閱 Azure SQL Database 和 SQL 受控執行個體以及Azure VM 上的 SQL Server。
概觀
分層安全性方法利用以不同安全性範圍為目標的多種安全性功能，提供深度防禦解決方案。 在 SQL Server 2016 中提供並在後續版本中改善的安全性功能，可協助抵禦安全性威脅，並提供妥善保護的資料庫應用程式。
Azure 符合多種業界規範及標準，可讓您使用在虛擬機器中執行的 SQL Server，建置相容的解決方案。 如需 Azure 的法規相符性資訊，請參閱 Azure 信任中心。
資料行層級保護
組織通常需要保護資料行層級的資料，因為客戶、員工、營業秘密、產品資料、醫療保健、財務和其他敏感性資料通常會儲存在 SQL Server 資料庫中。 敏感性資料行通常包括識別/社會安全號碼、行動電話號碼、名字、姓氏、金融帳戶識別，以及可能被視為個人資料的任何其他資料。
本節所述的方法和功能會以最少的額外負荷提高資料行層級的保護程度，而不需要對應用程式程式碼進行大量變更。
使用 Always Encrypted 來加密待用資料和透過網路傳送的資料。 加密資料只能由應用程式用戶端層級的用戶端程式庫解密。 請盡可能優先使用隨機化加密，確定性加密次之。 使用記憶體保護區的 Always Encrypted 可在隨機化加密案例中提升比較運算的效能，例如 BETWEEN、IN、LIKE、DISTINCT、Joins 等。
當 Always Encrypted 不是可用的選項時，請使用動態資料遮罩 (DDM)，模糊化資料行層級的資料。 動態資料遮罩 (DDM) 與 Always Encrypted 不相容。 盡可能優先使用 Always Encrypted，動態資料遮罩次之。
您也可以將資料行層級的 GRANT 權限授與資料表、檢視或資料表值函式。 請考慮以下事項：- 只能授與資料行的 SELECT、REFERENCES 及 UPDATE 權限。
- 資料表層級的 DENY 不會優先於資料行層級的 GRANT。
資料列層級保護
資料列層級安全性 (RLS) 可讓您利用使用者執行內容來控制資料庫資料表中資料列的存取。 RLS 可確保使用者只能看到與其相關的記錄。 這可為應用程式提供「記錄層級」安全性，而不需要對應用程式進行重大變更。
商務邏輯封裝在資料表值函式中，而該函式是由切換開啟和關閉 RLS 功能的安全性原則所控制。 安全性原則還控制了 FILTER 和 BLOCK 述詞，這兩個述詞則繫結到執行 RLS 的資料表。 使用資料列層級安全性 (RLS) 來限制傳回給發出呼叫的使用者的記錄。 若使用者透過中介層應用程式連接資料庫且該應用程式的使用者共用相同的 SQL Server 使用者帳戶，則請使用 SESSION_CONTEXT (T-SQL) 。 若要獲得最佳效能和管理性，請遵循資料列層級安全性最佳做法。
提示
使用資料列層級安全性 (RLS) 搭配 Always Encrypted 或動態資料遮罩 (DDM)，將組織的安全性狀態最大化。
檔案加密
透明資料加密 (TDE) 可提供資料庫檔案待用加密，以保護檔案層級的資料。 透明資料加密 (TDE) 可確保若無正確的憑證解密資料庫檔案，則無法附加和讀取資料庫檔案、備份檔案和 tempdb 檔案。 若沒有透明資料加密 (TDE)，攻擊者就可以取得實體媒體 (磁碟機或備份磁帶)，並還原或附加資料庫以讀取內容。 支援透明資料加密 (TDE) 搭配 SQL Server 中的所有其他安全性功能一起使用。 透明資料加密 (TDE) 提供資料和記錄檔的即時 I/O 加密和解密。 TDE 加密所使用的資料庫加密金鑰 (DEK) 儲存在使用者資料庫中。 也可以使用憑證來保護資料庫加密金鑰，該憑證是由 master 資料庫的資料庫主要金鑰所保護。
使用 TDE 來保護待用資料、備份和 tempdb。
稽核與報告
若要稽核 SQL Server，請在伺服器或資料庫層級建立稽核原則。 伺服器原則會套用至伺服器上所有現有和新建立的資料庫。 為了簡單起見，請啟用伺服器層級稽核並允許資料庫層級稽核繼承所有資料庫的伺服器層級屬性。
稽核含有敏感性資料且已套用安全性措施的資料表和資料行。 如果資料表或資料行重要到需要安全性功能的保護，則應視為重要到需要稽核。 匯入和定期檢閱含有敏感性資訊的資料表尤為重要，但因某種應用程式或結構限制，資料表無法套用需要的安全性措施。
身分識別和驗證
SQL Server 支援兩種驗證模式：Windows 驗證模式和「SQL Server 和 Windows 驗證模式」(混合模式)。
登入與資料庫使用者是分開的。 首先，請將登入或 Windows 群組分別對應到資料庫使用者或角色。 接下來，請將權限授與使用者、伺服器角色和/或資料庫角色，以存取資料庫物件。
SQL Server 支援下列類型的登入：
- 本機 Windows 使用者帳戶或 Active Directory 網域帳戶 - SQL Server 依賴 Windows 來驗證 Windows 使用者帳戶。
- Windows 群組 - 授與存取權給 Windows 群組，即會將存取權授與該群組成員的所有 Windows 使用者登入。 從群組中移除使用者，即會移除該群組成員的使用者權限。 群組成員資格是慣用的策略。
- SQL Server 登入 - SQL Server 會將使用者名稱和密碼雜湊儲存在
master資料庫中。 - 自主資料庫使用者會驗證資料庫層級的 SQL Server 連線。 自主資料庫是與其他資料庫和裝載資料庫的 SQL Server 執行個體 (以及
master資料庫) 分開的不同資料庫。 SQL Server 支援 Windows 和 SQL Server 驗證的自主資料庫使用者。
下列建議和最佳做法可協助保護您的身分識別和驗證方法：
使用最低權限角色型安全性策略來改善安全性管理。
- 將 Active Directory 使用者放在 AD 群組中是標準做法，AD 群組應該存在於 SQL Server 角色中，且應將應用程式所需的最低權限授與 SQL Server 角色。
在 Azure 中，您可以透過角色型存取 (RBAC) 控制項來使用最低權限安全性
請盡可能選擇 Active Directory 而不是 SQL Server 驗證，尤其是選擇 Active Directory 而不是儲存應用程式或資料庫層級的安全性。
- 如果使用者離開公司，很容易就能停用帳戶。
- 當使用者變更角色或離開組織時，也可以從群組中輕鬆移除使用者。 群組安全性被視為最佳做法。
對於具有電腦層級存取權的帳戶，請使用多重要素驗證，包括使用 RDP 登入電腦的帳戶在內。 這有助於防止認證遭竊或外洩，因為單一要素密碼型驗證是較弱的驗證形式，因為認證有遭到洩漏或錯誤授與他人的風險。
需要無法輕易猜到且未用於任何其他帳戶或用途的強式複雜密碼。 請定期更新密碼並強制執行 Active Directory 原則。
群組受控服務帳戶 (gMSA) 可讓您執行自動密碼管理、簡化的服務主體名稱 (SPN) 管理，以及將管理委派給其他管理員。
- 使用 gMSA，Windows 作業系統可管理帳戶的密碼，而不用依賴管理員來管理密碼。
- gMSA 會自動更新帳戶密碼，而不用重新啟動服務。
- gMSA 可減少管理層面的負擔並改善職責區分。
縮減授與 DBA AD 帳戶的權限；請考慮限制虛擬機器存取權、登入作業系統的能力、修改錯誤和稽核記錄的能力，以及安裝應用程式和/或功能的能力等職責區分。
請考慮從 sysadmin 角色中移除 DBA 帳戶，並將 CONTROL SERVER 授與 DBA 帳戶，而不是讓它們設為 sysadmin 角色的成員。 系統管理員角色可以不遵照
DENY，而 CONTROL SERVER 會。
資料譜系和資料完整性
保留一段時間內的資料變更的歷程記錄，有助於處理意外發生的資料變更。 對於應用程式變更稽核也很有用，而且在不良執行者進行未經授權的資料變更時，還可以用來復原資料元素。
- 使用時態表來保留一段時間內的記錄版本，並查看記錄生命週期的資料，以提供應用程式資料的歷程檢視。
- 時態表可用來提供任何時間點的最新資料表版本。
安全性評量工具和評估
以下設定和評量工具可解決介面區的安全性問題、識別資料安全性風險，並提供執行個體層級 SQL Server 環境安全性的最佳做法評量。
- 介面區設定 - 您應只啟用環境所需的功能，以便將惡意使用者所能攻擊的功能數降到最低。
- SQL Server 弱點評量 (SSMS) - SQL 弱點評量是 SSMS v17.4+ 提供的一項工具，可協助探索、追蹤和補救潛在的資料庫弱點。 弱點評量是可以提升資料庫安全性的重要工具，而且是在每個資料庫的資料庫層級執行。
- SQL 資料探索和分類 (SSMS) - DBA 通常可管理伺服器和資料庫，而且並不了解該資料庫所含資料的敏感性。 資料探索和分類的新增功能可以探索、分類、標示和報告資料的敏感性程度。 從 SSMS 17.5 開始支援資料探索和分類。
常見的 SQL 威脅
這有助於了危及 SQL Server 的一些常見威脅：
- SQL 插入式攻擊 - SQL 插入式攻擊類型會將惡意程式碼插入要傳遞至 SQL Server 執行個體以供執行的字串。
- 插入攻擊程序的運作方式是終止文字字串並附加新命令。 因為插入的命令在執行之前可能附加有更多字串，所以攻擊者會使用註解標記
--終止插入的字串。 - SQL Server 會執行所收到的任何有效語法查詢。
- 插入攻擊程序的運作方式是終止文字字串並附加新命令。 因為插入的命令在執行之前可能附加有更多字串，所以攻擊者會使用註解標記
- 請注意旁路攻擊、惡意程式碼和其他威脅。
SQL 插入風險
若要將 SQL 插入的風險降到最低，請考慮下列事項：
- 檢閱建構 SQL 陳述式的 SQL 程序是否有插入弱點。
- 以參數化方式建構動態產生的 SQL 陳述式。
- 開發人員和安全管理員應檢閱所有呼叫
EXECUTE、EXEC或sp_executesql的程式碼。 - 不允許下列輸入字元：
;：查詢分隔符號'：字元資料字串分隔符號--：單行註解分隔符號。/* ... */：註解分隔符號。xp_：目錄擴充預存程序，例如xp_cmdshell。- 不建議在任何 SQL Server 環境中使用
xp_cmdshell。 由於xp_cmdshell可能會產生安全問題，因此請改用 SQLCLR 或尋找其他替代方案。
- 不建議在任何 SQL Server 環境中使用
- 一律驗證使用者輸入並清除錯誤輸出，避免洩漏並曝露給攻擊者知道。
旁路攻擊風險
若要將旁路攻擊的風險降到最低，請考慮下列事項：
- 確定已套用最新的應用程式和作業系統修補程式。
- 針對混合式工作負載，請確定任何硬體內部部署均已套用最新韌體修補程式。
- 在 Azure 中，對於高度敏感的應用程式和工作負載，您可以使用隔離的虛擬機器、專用主機或利用機密計算虛擬機器 (例如 DC 系列和使用第三代 AMD EPYC 處理器的虛擬機器)，新增防止旁路攻擊的其他保護措施。
基礎結構威脅
請考慮下列常見的基礎結構威脅：
- 暴力密碼破解存取 - 攻擊者嘗試在不同的帳戶使用多個密碼進行驗證，直到找到正確的密碼為止。
- 密碼破解/密碼噴灑 - 攻擊者會針對所有已知的使用者帳戶嘗試一個經過謹慎編製的密碼 (一個密碼用於許多帳戶)。 如果初次密碼噴灑失敗，他們會利用另一個謹慎編製的密碼再試一次，通常會等待一定的時間量再進行另一次嘗試，以避免被系統偵測到。
- 勒索軟體攻擊是鎖定目標的攻擊類型，攻擊者會使用惡意程式碼來加密資料和檔案，讓使用者無法存取重要內容。 然後攻擊者就會嘗試向受害者勒索金錢 (通常以加密貨幣支付)，用以交換解密金鑰。 大部分勒索軟體感染是因為電子郵件含有嘗試安裝勒索軟體的附件，或網站裝載了惡意探索套件，這些套件會嘗試利用網頁瀏覽器和其他軟體弱點來安裝勒索軟體。
密碼風險
既然您不希望攻擊者輕鬆猜到帳戶名稱或密碼，下列步驟可協助您降低密碼被發現的風險：
- 建立不是名為 Administrator的唯一本機系統管理員帳戶。
- 為您的所有帳戶使用複雜的強式密碼。 如需如何建立強式密碼的詳細資訊，請參閱 建立強式密碼一文。
- 根據預設，Azure 會在 SQL Server 虛擬機器安裝期間選取 Windows 驗證。 因此，系統會停用 SA 登入，並由安裝程式指派密碼。 我們建議不要使用或啟用 SA 登入。 如果您必須具有 SQL 登入，請使用下列其中一個策略：
使用具有 sysadmin 成員資格的唯一名稱建立 SQL 帳戶。 在佈建期間啟用 SQL 驗證，即可從入口網站執行此作業。
提示
如果您未在佈建期間啟用 SQL 驗證，您必須將驗證模式手動變更為 SQL Server 和 Windows 驗證模式。 如需詳細資訊，請參閱變更伺服器驗證模式。
如果您必須使用 SA 登入，請在佈建後啟用此登入，然後指派新的強式密碼。
勒索軟體風險
請考慮下列事項，將勒索軟體的風險降至最低：
- 防範勒索軟體的最佳策略是特別注意 RDP 和 SSH 弱點。 此外，請考量下列建議事項：
- 利用防火牆和鎖定連接埠
- 確保已套用最新的作業系統和應用程式安全性更新
- 使用群組受控服務帳戶 (gMSA)
- 限制虛擬機器的存取
- 需要 Just-In-Time (JIT) 存取和 Azure Bastion
- 避免在本機電腦上安裝 sysinternals 和 SSMS 等工具，以改善介面區安全性
- 避免安裝 Windows 功能、角色和啟用不需要的服務
- 此外，應該排程定期完整備份，備份應與常用的系統管理員帳戶分開保護，這樣就不會刪除資料庫的複本。