SQL Server 安全性最佳做法

適用於：SQL ServerAzure SQL DatabaseAzure 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 系結至 RLS 數據表的 和 BLOCK 述詞。 使用資料列層級安全性 (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 角色的成員。 當 CONTROL SERVER 執行時，系統管理員角色並不尊重DENY。

資料譜系和資料完整性

保留一段時間內的資料變更的歷程記錄，有助於處理意外發生的資料變更。 當不良動作專案導入未獲授權的數據變更時，它也適用於應用程式變更稽核，而且可以復原數據元素。

• 使用 時態表 來保留一段時間的記錄版本，並查看記錄的存留期數據，以提供應用程式數據的歷程記錄檢視。
• 時態表可用來提供任何時間點的最新資料表版本。

安全性評量工具和評估

下列組態和評估工具可解決介面區安全性、識別數據安全性機會，並提供實例層級 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 。 請改用 SQLCLR，或尋找其他因風險而可能造成的 xp_cmdshell 替代方案。
• 一律驗證使用者輸入並清除錯誤輸出，避免洩漏並曝露給攻擊者知道。

旁路攻擊風險

若要將旁路攻擊的風險降到最低，請考慮下列事項：

• 確定已套用最新的應用程式和作業系統修補程式。
• 針對混合式工作負載，請確定任何硬體內部部署均已套用最新韌體修補程式。
• 在 Azure 中，針對高度敏感的應用程式和工作負載，您可以使用隔離的虛擬機、專用主機，或使用使用 DC 系列和 虛擬機器 等使用第三代 AMD EPYC 處理器的機密計算虛擬機，來新增對側通道攻擊的額外保護。

基礎結構威脅

請考慮下列常見的基礎結構威脅：

• 暴力密碼破解存取 - 攻擊者嘗試在不同的帳戶使用多個密碼進行驗證，直到找到正確的密碼為止。
• 密碼破解/密碼噴灑 - 攻擊者會針對所有已知的使用者帳戶嘗試一個經過謹慎編製的密碼 (一個密碼用於許多帳戶)。 如果初次密碼噴灑失敗，他們會利用另一個謹慎編製的密碼再試一次，通常會等待一定的時間量再進行另一次嘗試，以避免被系統偵測到。
• 勒索軟體攻擊是鎖定目標的攻擊類型，攻擊者會使用惡意程式碼來加密資料和檔案，讓使用者無法存取重要內容。 然後攻擊者就會嘗試向受害者勒索金錢 (通常以加密貨幣支付)，用以交換解密金鑰。 大部分勒索軟體感染是因為電子郵件含有嘗試安裝勒索軟體的附件，或網站裝載了惡意探索套件，這些套件會嘗試利用網頁瀏覽器和其他軟體弱點來安裝勒索軟體。

密碼風險

既然您不希望攻擊者輕鬆猜到帳戶名稱或密碼，下列步驟可協助您降低密碼被發現的風險：

• 建立未命名為 管理員 istrator 的唯一本機系統管理員帳戶。
• 為您的所有帳戶使用複雜的強式密碼。 如需如何建立強式密碼的詳細資訊，請參閱 建立強式密碼一文。
• 根據預設，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 功能、角色和啟用服務
  • 此外，應該排程定期完整備份，備份應與常用的系統管理員帳戶分開保護，這樣就不會刪除資料庫的複本。

相關內容

• 保護 SQL Server 的安全
• Azure SQL 資料庫 和 SQL 受管理執行個體
• Azure VM 上的 SQL Server