共用方式為

使用 Azure SQL Database 和 Azure SQL 受控執行個體解決一般安全性需求的腳本

  • 發行項

適用於： Azure SQL 資料庫 Azure SQL 受控執行個體

本文提供解決一般安全性需求的最佳做法。 所有需求並非都適用所有環境，您應該向資料庫和安全性小組諮詢要執行的功能。

注意

Microsoft Entra ID 先前稱為 Azure Active Directory (Azure AD)。

解決常見的安全性需求

本文件提供如何使用 Azure SQL Database 和 Azure SQL 受控執行個體解決新應用程式或現有應用程式的一般安全性需求。 由高層級安全性區域所組成。 若要解決特定威脅，請參閱常見安全性威脅與可能風險降低措施一節。 雖然有些列出來的建議適用於將應用程式從內部部署移轉至 Azure 的過程，但這份文件不會著重在移轉案例。

本指南涵蓋的 Azure SQL Database 部署服務

本指南未涵蓋的部署服務

  • Azure Synapse Analytics
  • Azure SQL VMs (IaaS)
  • SQL Server

適用對象

本指南的目標觀眾是對於如何保護 Azure SQL Database 有疑問的客戶。 對本最佳做法文章感興趣的角色包括但不限於：

  • 安全架構設計人員
  • 安全性管理員
  • 合規性人員
  • 隱私權人員
  • 安全性工程師

如何使用本指南

本文件是為搭配現有的 Azure SQL Database 安全性文件而撰寫。

除非另有說明，建議您遵循每個區段中列出的所有最佳做法來達成個別的目標或需求。 為了符合特定的安全性合規標準或最佳做法，重要的法規合規性控制列在「需求」或「目標」適用的區段中。 下列為本文所提及的安全性標準和法規：

我們計畫繼續更新此處列出的建議和最佳作法。 請使用本文底部的意見反應連結，提供針對此文件的意見或任何需要更正的地方。

驗證

驗證是證明使用者宣告身分的程序。 Azure SQL Database 和 SQL 受控執行個體支援兩種類型的驗證：

  • SQL 驗證
  • Microsoft Entra 驗證

注意

可能並非所有工具和協力廠商應用程式都支援 Microsoft Entra 驗證。

集中管理身分識別

中央身分識別管理提供下列優勢：

  • 不需要在伺服器、資料庫和受控執行個體之間重複登入就可管理群組帳戶和控制使用者權限。
  • 簡化且彈性的權限管理。
  • 大規模管理應用程式。

實作方法

  • 針對集中化身分識別管理使用 Microsoft Entra。

最佳作法

  • 建立 Microsoft Entra 租用戶，建立使用者來代表人類使用者，並建立服務主體來代表應用程式、服務和自動化工具。 服務主體相當於 Windows 和 Linux 中的服務帳戶。

  • 透過群組指派將資源的存取權限指派給 Microsoft Entra 主體：建立 Microsoft Entra 群組、將存取權授與群組，以及將個別成員新增至群組中。 在資料庫中建立對應 Microsoft Entra 群組的自主資料庫使用者。 若要在資料庫內指派權限，請將代表您群組的自主資料庫使用者新增至資料庫角色，或將權限直接授與他們。

    注意

    您也可在 SQL 受控執行個體中建立與 master 資料庫中 Microsoft Entra 主體對應的登入。 請參閱 CREATE LOGIN (Transact-SQL)。

  • 使用 Microsoft Entra 群組可簡化權限管理，且群組擁有者和資源擁有者可以在群組中新增/移除成員。

  • 為每個伺服器或受控執行個體的 Microsoft Entra 系統管理員建立個別群組。

  • 使用 Microsoft Entra ID 稽核活動報告來監視 Microsoft Entra 群組成員資格變更。

  • 針對受控執行個體，需要透過個別步驟建立 Microsoft Entra 管理員。

注意

  • Microsoft Entra 驗證會記錄在 Azure SQL 稽核記錄中，但不會記錄在 Microsoft Entra 登入記錄中。
  • Azure 中授與的 Azure RBAC 權限不適用於 Azure SQL Database 或 SQL 受控執行個體權限。 這類權限必須使用現有的 SQL 權限手動建立/對應。
  • 在用戶端上，Microsoft Entra 驗證需要存取網際網路，或透過使用者定義路由 (UDR) 存取虛擬網路。
  • Microsoft Entra 存取權杖會快取在用戶端上，其存留期則取決於權杖設定。 請參閱 Microsoft Entra ID 中的可設定權杖存留期一文
  • 如需針對 Microsoft Entra 驗證問題進行疑難排解的指引，請參閱下列部落格文章：疑難排解 Microsoft Entra ID。

Microsoft Entra 多重要素驗證

提及於：OSA 實務 #2、ISO 存取控制 (AC)

Microsoft Entra 多重要素驗證可透過要求多種形式的驗證來提供額外的安全性。

實作方法

  • 使用條件式存取在 Microsoft Entra ID 中啟用多重要素驗證，並使用互動式驗證。

  • 替代方法是為整個 Microsoft Entra 租用戶或 Active Directory 網域啟用多重要素驗證。

最佳作法

最小化使用者密碼型驗證的使用

提及於：OSA 實務 #4、ISO 存取控制 (AC)

以密碼為基礎的驗證方法是較弱的驗證形式。 認證可能遭到入侵或因錯誤送出。

實作方法

  • 使用 Microsoft Entra 的整合式驗證消除密碼的使用。

最佳作法

  • 透過 Windows 認證來使用單一登入驗證。 將 內部部署的 Active Directory 網域與 Microsoft Entra ID 同盟，並使用整合式 Windows 驗證 (適用具有 Microsoft Entra ID 的已加入網域的機器)。

最小化應用程式密碼型驗證的使用

提及於：OSA 實務 #4、ISO 存取控制 (AC)

實作方法

  • 啟用 Azure 受控識別。 您也可以使用整合式或憑證型的驗證。

最佳作法

保護密碼和祕密

針對無法避免密碼時的案例，請確保它們受到保護。

實作方法

  • 使用 Azure Key Vault 儲存密碼和祕密。 在適用的情況下，盡可能使用適用於有 Microsoft Entra 使用者的 Azure SQL 資料庫多重要素驗證。

最佳作法

  • 如果無法避免密碼或祕密，請在 Azure Key Vault 中儲存使用者密碼和應用程式祕密，並透過 Key Vault 存取原則來管理存取權。

  • 不同的應用程式開發架構，也可以提供專屬架構的機制來保護應用程式中的祕密。 例如：ASP.NET 核心應用程式。

為舊版應用程式啟用 SQL 驗證

SQL 驗證是指使用者透過使用者名稱和密碼連線到 Azure SQL Database 或SQL 受控執行個體時的驗證。 必須在每個伺服器或受控執行個體中建立登入，並在每個資料庫中建立一個使用者。

實作方法

  • 使用 SQL 驗證。

最佳作法

存取管理

存取管理 (又稱授權) 是一個程序，控制及管理授權使用者針對 Azure SQL Database 或 SQL 受控執行個體的存取和權限。

執行最低權限原則

提及於：FedRamp 控制 AC-06、NIST：AC-6、OSA 實務 #3

最低使用權限的原則會指出使用者不應擁有的權限大於完成其工作所需的權限。 如需詳細資訊，請參閱恰到好處的系統管理一文。

實作方法

只能指派必要的權限以完成必要的工作：

  • 位於 SQL 資料庫中：

  • 位於 Azure Resource Manager 中：

最佳作法

下列最佳作法是選擇性的，但可讓您的安全性策略能更有效地管理和有更好的支援能力：

  • 可能的話，請從可能最低的權限集合開始，如果有真正的需求 (和理由) 請一併開始新增權限 – 相對於相反的方法：逐步移除權限。

  • 避免指派權限給個別使用者。 改為一致使用角色 (資料庫或伺服器的角色)。 角色可大幅協助您報告和進行權限的疑難排解。 (Azure RBAC 只能透過角色支援指派權限。)

  • 使用需要的正確權限建立和使用自訂角色。 實務中使用的一般角色：

    • 安全性部署
    • 系統管理員
    • 開發人員
    • 支援人員
    • 稽核員
    • 自動化的流程
    • 終端使用者

  • 只有當角色權限完全符合使用者所需的權限時，才使用內建角色。 您可以指派使用者至多個角色。

  • 請記住資料庫引擎中的權限可套用至下列範圍內 (範圍愈小，授與權限的影響愈小)：

    • Azure 中的伺服器 (master 資料庫的特殊角色)
    • 資料庫
    • 結構描述
      • 最佳做法是利用架構授與資料庫內的權限。
    • 物件 (資料表、檢視、程序等)

    注意

    不建議在物件層級套用權限，因為此層級會在整體執行過程中增加多餘的複雜度。 如果您決定使用物件層級的權限，就因清楚記載這些權限。 這同樣適用於資料行層級權限，因為相同的原因更不建議這麼做。 也請注意，資料表層級的否決根據預設不會覆寫資料行層級「授與」。 這會需要啟用通用條件合規性的伺服器設定。

  • 利用弱點評估 (VA) 執行定期檢查，以測試太多的權限。

實行職責區分

提及於：FedRamp：AC-04、NIST：AC-5、ISO：A.6.1.2、PCI 6.4.2、SOC：CM-3、SDL-3

職責區分 (又稱職責隔離) 描述將指派給不同使用者的敏感性工作分割成多個工作的需求。 職責區分有助於防止資料缺口。

實作方法

  • 識別所需的職責區分層級。 範例：

    • 開發/測試環境與實際執行環境之間
    • 安全性敏感的工作與資料庫管理員 (DBA) 管理層級工作與開發人員工作。
      • 範例：稽核程式、建立角色層級安全性 (RLS) 的安全性原則、使用 DDL 權限執行 SQL Database 物件。

  • 找出可存取系統的全方位使用者 (和自動化流程)。

  • 根據所需的使用者群組建立角色，並指派權限給角色。

    • 針對 Azure 入口網站內或透過 PowerShell 自動化的管理層級工作，請使用 Azure 角色。 請尋找符合需求的內建角色，或使用可用權限建立 Azure 自訂角色
    • 在受控執行個體中針對全伺服器的工作 (建立新的登入、資料庫) 建立伺服器角色。
    • 建立資料庫層級工作的資料庫角色。

  • 針對特定的敏感性工作，請考慮建立由憑證簽署的特殊預存程式代替使用者執行工作。 數位簽署預存程式其中一項重要優點是，如果程式變更完後會立即移除授與先前版本程式的權限。

  • 使用 Azure Key Vault 中客戶管理的金鑰實行透明資料加密 (TDE)，以區分資料擁有者和安全性擁有者之間的職責。

  • 若要確保 DBA 看不到被視為高度機密的資料，且仍可執行 DBA 的工作，您可以搭配角色隔離使用 Always Encrypted。

  • 在使用 Always Encrypted 不可行的情況下，或至少需要太大的成本和努力，甚至可能會導致系統幾近無法使用時，就可以妥協並使用補償控制項來進行移轉，例如：

最佳作法

  • 請確定開發/測試和生產環境是利用不同的帳戶。 不同的帳戶能協助符合測試和生產系統的分隔。

  • 避免指派權限給個別使用者。 改為一致使用角色 (資料庫或伺服器的角色)。 擁有角色可大幅協助您報告和進行權限的疑難排解。

  • 當權限完全符合必要權限時，請使用內建角色 - 如果多個內建角色的擁有權限聯集結果為 100% 相符，您也可以同時指派多個角色。

  • 當內建角色授與太多許權限或權限不足時，請建立並使用使用者定義的角色。

  • 角色指派也可暫時完成，又稱動態職責區分 (DSD)，可能在 T-SQL 中的 SQL Agent 作業步驟內完成，或針對 Azure 角色使用 Azure PIM。

  • 請確定 DBA 無法存取加密金鑰或金鑰存放區，而且可存取金鑰的安全性系統管理員無法再次存取資料庫。 使用可延伸的金鑰管理 (EKM) 可讓您更輕鬆地完成此區分。 Azure Key Vault 可用來執行 EKM。

  • 務必確定安全性相關動作有稽核記錄。

  • 您可以擷取 Azure 內建角色的定義，以查看已使用的權限，並根據這些權限透過 PowerShell 的摘錄和累計來建立自訂角色。

  • 因為 db_owner 資料庫角色的任何成員都可以變更透明資料加密 (TDE) 等安全性設定，或變更 SLO，所以應謹慎授與此成員資格。 不過，許多工作都需要 db_owner 權限。 變更任何資料庫設定的工作，例如變更 DB 選項等。 稽核在任何解決方案中都扮演著重要的角色。

  • 您無法限制 db_owner 的權限進而防止系統管理帳戶查看使用者資料。 如果資料庫內涵高度敏感的資料，Always Encrypted 可以用來安全地防止 db_owners 或任何其他 DBA 進行查看。

注意

達成職責區分 (SoD) 對安全性相關或疑難排解工作是一項挑戰。 其他像是開發和一般使用者角色等區域比較容易區分。 大部分與合規性有關的控制項都可讓您使用替代的控制功能，例如在其他方案不可行時進行稽核。

想要深入了解 SoD 的讀者，我們建議下列資源：

執行一般程式碼檢閱

提及於：PCI：6.3.2、SOC：SDL-3

職責區分不限於資料庫中的資料，但包含應用程式程式碼。 惡意程式碼有可能規避安全性控制措施。 部署自訂程式碼至生產環境前，請務必先複習即將部署的內容。

實作方法

  • 使用 Azure Data Studio 等支援原始檔控制的資料庫工具。

  • 執行隔離的程式碼部署程序。

  • 在認可主要分支前，必有有人 (程式碼本身的作者除外) 檢查程式碼是否有可能提高權限風險，以及修改惡意資料以防止詐騙和惡意存取。 可以使用原始檔控制機制來完成此操作。

最佳作法

  • 標準化：這有助於實行任何程式碼更新遵循的標準程式。

  • 「弱點評估」包含的規則會檢查過多的權限、使用舊的加密演算法，以及資料庫結構內的其他安全性問題。

  • 在QA 或測試環境中使用「進階威脅防護」，掃描易受 SQL-插入的程式碼，以進行進一步的檢查。

  • 可注意的內容範例：

    • 在自動化的 SQL-程式碼更新部署中建立使用者或變更安全性設定。
    • 根據提供的參數而定，預存程式，會以不符合規範的方式更新儲存格中的貨幣值。

  • 請確定進行評論的人員是原始碼作者以外的人員，且對評論程式碼和撰寫安全程式碼有一定的認識。

  • 請務必了解所有程式碼-變更的來源。 程式碼可以在 T-SQL 指令碼中。 該程式碼可以是要以「視圖」、「函式」、「觸發程式」和「預存程式」形式來執行或部署的特定命令。 該程式碼可以是 SQL Agent 作業定義的一部分 (步驟)。 也可以在 SSIS 封裝、Azure Data Factory 和其他服務中執行。

資料保護

「資料保護」是一組用來保護重要資訊免於受到加密或混淆危害的功能。

注意

Microsoft 證明 Azure SQL Database 和 SQL 受控執行個體符合 FIPS 140-2 層級 1 的規範。 確認符合 FIPS 140-2 層級 1 可接受的演算法和 FIPS 140-2 Level 1 已驗證的實例，包括與所需的金鑰長度、金鑰管理、金鑰產生和金鑰儲存區一致，之後才會執行證明。 此證明旨在讓客戶在處理資料或傳送系統或應用程式時，可以回應使用 FIPS 140-2 層級 1 驗證實例的需求或要求。 我們會定義上述陳述中「FIPS 140-2 層級 1 相容」和「FIPS 140-2 層級1合規性」等字詞，向美國和加拿大政府使用不同詞彙「FIPS 140-2 層級 1 已驗證」展示其預期適用性。

加密傳輸中的資料

提及於：OSA 實務 #6、ISO 控制系列：加密

於資料在您的用戶端與伺服器之間移動期間，保護您的資料。 請參閱網路安全性。

加密待用資料

提及於：OSA 實務 #6、ISO 控制系列：加密

待用加密是將資料保存在資料庫、記錄和備份檔案時的進行加密保護。

實作方法

  • 透明資料加密 (TDE) 搭配服務管理金鑰，在任何 2017 年之後於 Azure SQL 資料庫和 SQL 受控執行個體中建立的資料庫中均預設為啟用。
  • 在受控執行個體中，如果資料庫是利用內部部署伺服器從還原作業建立，則會接受原始資料庫的 TDE 設定。 如果原始資料庫沒有 TDE，建議您針對受控執行個體手動啟動 TDE。

最佳作法

  • 請勿將需要代用加密的資料儲存在 master 資料庫中。 master 資料庫無法以 TDE 加密。

  • 如果您需要對 TDE 保護增加透明度和細微控制，請在 Azure Key Vault 中使用客戶管理的金鑰。 Azure Key Vault 允許隨時撤銷權限，使資料庫無法存取。 您可以使用 Azure Key Vault，集中管理 TDE 保護裝置以及其他金鑰，或透過您自己的排程來循環 TDE 保護裝置。

  • 如果您在 Azure Key Vault 中使用客戶管理的金鑰，請遵循使用 Azure Key Vault 設定 TDE 的指導方針，以及如何使用 Azure Key Vault 設定地區災害復原等文。

注意

視為客戶內容的某些項目 (例如資料表名稱、物件名稱與索引名稱) 可能會在記錄檔中傳輸，以便由 Microsoft 支援及進行疑難排解。

保護使用中的敏感性資料免於高級權限、未經授權的使用者的危害

使用中的資料為執行 SQL 查詢期間，儲存在資料庫系統記憶體中的資料。 如果您的資料庫存有敏搞性資料，您的組織可能需要確保高級權限的使用者無法在您的資料庫中查看敏感性資料。 高級權限使用者，例如您組織中的 Microsoft 操作員或 DBA，應該要能夠管理資料庫，但無法從 SQL 流程的記憶體或藉由查詢資料庫來查看進而洩漏敏感性資料。

決定哪些是敏感性資料的政策，以及敏感性資料是否必須加密在記憶體中，並讓系統管理員無法在純文字中存取，根據貴組織而定，且是您需要遵守的合規性法規。 請參閱相關的要求：識別並標記敏感性資料。

實作方法

  • 使用 Always Encrypted 來確保敏感性資料不會在 Azure SQL Database 或 SQL 受控執行個體中以純文字形式公開，即使在記憶體/使用中也一樣。 Always Encrypted 會保護資料庫管理員 (DBA) 和雲端管理員的資料 (或假冒高級權限但未經授權使用者的惡意人員)，讓您更充分掌控可以存取資料的人員。

最佳作法

  • Always Encrypted 無法替代加密待用資料 (TDE) 或傳輸中的資料 (SSL/TLS)。 Always Encrypted 不應用於非敏感性資料，將效能和功能的影響降至最低。 建議搭配 TDE 和傳輸層安全性 (TLS) 使用 Always Encrypted，全面保護待用、傳輸中和使用中的資料。

  • 在生產環境資料庫部署 Always Encrypted 之前，請先評估對已識別敏感性資料行進行加密的影響。 一般而言，Always Encrypted 會減少加密資料行的查詢功能，且有其他限制，這些限制列在 Always Encrypted 功能詳細資料中。 因此，您可能需要重新架構應用程式來重新實作該功能、沒有支援的查詢、用戶端或/及重構您的資料庫結構描述，包括預存程式、函式、檢視和觸發程序的定義。 如果現有的應用程式未遵守 Always Encrypted 的限制和侷限，則可能無法配合加密的資料行作業。 雖然 Microsoft 工具、產品和服務的生態系統，越來越支援 Always Encrypted，但是有一些功能無法配合加密的資料行作業。 根據工作負載的特性而定，加密資料行可能也會影響查詢表現。

  • 如果您使用 Always Encrypted 來保護資料免於惡意 DBA 的攻擊，請使用角色隔離來管理 Always Encrypted 金鑰。 有了角色隔離，安全性系統管理員會建立實體金鑰。 DBA 會建立資料行主要金鑰和資料行加密金鑰中繼資料物件，描述資料庫中的實體索引鍵。 在這個過程中，安全性系統管理員不需要存取資料庫，且 DBA 不需要以純文字格式存取實體金鑰。

  • 將您的資料行主要金鑰儲存在 Azure Key Vault 中以方便管理。 請避免使用會讓金鑰管理困難的 Windows 憑證存放區 (和一般的分散式金鑰存放區解決方案，而不是集中式金鑰管理解決方案)。

  • 請仔細考慮利用多個金鑰 (資料行主要金鑰或資料行加密金鑰) 的取捨。 維持小的金鑰數目以降低金鑰管理成本。 在穩定狀態環境中 (而不是金鑰輪替的過程中)，每個資料庫都有一個資料行主要金鑰和一個資料行加密金鑰。 如果您有不同的使用者群組使用不同的金鑰並存取不同的資料，您可能需要額外的金鑰。

  • 依據您的合規性要求輪替資料行主要金鑰。 如果您也需要輪替資料行加密金鑰，請考慮使用線上加密將應用程式停機時間降到最低。

  • 如果需支援資料計算 (相等)，請使用確定性加密。 否則請使用隨機化加密。 避免針對低熵資料集或使用公開已知發佈資料集使用確定性加密。

  • 如果您擔心協力廠商在不同意的情況下存取您的資料，請確定能以純文字方式存取金鑰和資料的所有應用程式和工具都在 Microsoft Azure Cloud 外執行。 如果沒有金鑰的存取權，除非繞過加密，否則協力廠商將無法解密資料。

  • Always Encrypted 不會輕易支援暫時授與金鑰存取權 (以及受保護的資料)。 例如，如果您需要與 DBA 共用金鑰，允許 DBA 對敏感性和加密資料進行一些清理作業。 能可靠撤銷 DBA 資料存取權的唯一方法，就是輪替保護資料的資料行加密金鑰和資料行主要金鑰，而這是一項昂貴的作業。

  • 若要存取加密資料行中的純文字值，使用者必須能夠存取保護資料行的資料行主要金鑰 (CMK)，這能在保存 CMK 的金鑰存放區中設定。 使用者也需要 VIEW ANY COLUMN MASTER KEY DEFINITION 和 VIEW ANY COLUMN ENCRYPTION KEY DEFINITION 的資料庫權限。

透過加密控制應用程式使用者存取敏感性資料

加密可用來確保只有可以存取加密金鑰的特定應用程式使用者可以查看或更新資料。

實作方法

  • 使用資料格層級加密 (CLE)。 如需詳細資料，請參閱加密資料行一文。
  • 使用 Always Encrypted，但請留意其侷限。 侷限如下所示。

最佳做法：

使用 CLE 時：

  • 透過 SQL 權限和角色控制存取金鑰。

  • 使用 AES (推薦 AES 256) 資料加密。 演算法，例如 RC4、DES 和 TripleDES等，已被取代且不應使用，因為有已知弱點。

  • 使用非對稱金鑰/憑證 (非密碼) 來保護對稱金鑰，以避免使用3DES。

  • 透過匯出/匯入 (bacpac 檔案) 使用資料隔層級加密來移轉資料庫時，請特別小心。

請記住，Always Encrypted 主要是設計用來保護使用中敏感性密資料免於 Azure SQL Database 高級權限使用者危害 (雲端操作員、DBA) - 請參閱保護使用中的敏感性資料免於高級權限、未經授權使用者的危害。 使用 Always Encrypted 來保護應用程式使用者的資料時，請注意下列挑戰：

  • 根據預設，支援 Always Encrypted 的所有 Microsoft 用戶端驅動程式都會維護全域 (每個應用程式都有一個) 快取資料行加密金鑰。 一旦用戶端驅動程式藉由聯繫保存資料行主要金鑰的金鑰存放區，取得純文字資料行加密金鑰，就會快取純文字資料行加密金鑰。 這會讓隔離多使用者應用程式的使用者資料更加困難。 如果您的應用程式在與金鑰存放區互動 (例如 Azure Key Vault) 時假冒終端使用者，在使用者的資料行加密金鑰以查詢填入快取之後，則需要由另一位使用者觸發相同金鑰的後續查詢將會使用快取的金鑰。 驅動程式不會呼叫金鑰存放區，而且不會檢查第二位使用者是否有存取資料行加密金鑰的權限。 因此，即使使用者無法存取金鑰，使用者也可以看到加密的資料。 若要在多使用者應用程式中隔離多個使用者，您可以停用資料行加密金鑰快取。 停用快取會導致額外的效能負荷，因為驅動程式必須針對每個資料加密或解密作業與金鑰存放區聯繫。

保護資料不被未經授權的應用程式使用者查看，同時保留資料格式

另一個防止未經授權的使用者查看資料的方法為，模糊或遮罩資料，同時保留資料類型和格式，以確保使用者應用程式能繼續處理及顯示資料。

實作方法

注意

Always Encrypted 無法配合「動態資料遮罩」作業。 您無法加密及遮罩相同的資料行，這表示您需要設定保護使用中資料的優先順序，與透過「動態資料遮罩」為您的應用程式使用者遮罩資料。

最佳作法

注意

「動態資料遮罩」不能用來保護高級權限使用者的資料。 遮罩原則不適用於 db_owner 等具有系統管理存取權的使用者。

  • 不允許應用程式使用者執行臨機查詢 (因為無法繞過「動態資料遮罩」)。

  • 使用適當的存取控制原則 (透過 SQL 權限、角色、RLS)，以限制使用者在遮罩的資料行中進行更新的權限。 在資料行建立遮罩並不會防止該資料行更新。 在查詢遮罩資料行時會收到遮罩資料的使用者，還是可在具有寫入權限時更新資料。

  • 「動態資料遮罩」不會保留遮罩值的統計屬性。 這可能會影響查詢結果 (例如，包含篩選述詞的查詢或遮罩資料的聯結)。

網路安全性

網路安全性指的是存取控制和最佳做法，以保護傳輸至 Azure SQL Database 的資料。

設定我的用戶端可以安全地連接到 SQL Database/SQL 受控執行個體

如何防止具有已知弱點 (例如，使用舊版的 TLS 通訊協定和加密套件) 的用戶端電腦和應用程式 連接至 Azure SQL Database 和 SQL 受控執行個體的最佳做法。

實作方法

  • 確保連線至 Azure SQL Database 和 SQL 受控執行個體的用戶端電腦使用最新的傳輸層安全性 (TLS) 版本。

最佳作法

  • 使用最基本的 TLS 版本設定，在 Azure 上的邏輯伺服器或 SQL 受控執行個體層級強制執行最基本的 TLS 版本。 建議您在測試應用程式確實支援後，將最基本的 TLS 版本設定為 1.2。 TLS 1.2 包含針對舊版中發現的弱點修正。

  • 設定您所有的應用程式和工具在啟用加密時連接到 SQL Database

    • Encrypt = On、TrustServerCertificate = Off (或與非 Microsoft 驅動程式相等)。

  • 如果您的應用程式使用不支援 TLS 的驅動程式，或支援較舊版的 TLS，盡可能更換驅動程式。 如果無法更換，請仔細評估安全性風險。

最小化攻擊面

將可能受惡意使用者攻擊的功能數量降至最低。 實作 Azure SQL Database 的網路存取控制。

提及於：OSA 實務 #5

實作方法

在 SQL Database 中：

  • 將伺服器層級的 [允許存取 Azure] 服務設為 [關閉]
  • 使用 VNet 服務端點以及 VNet 防火牆規則。
  • 使用私人連結。

在 SQL 受控執行個體中：

最佳作法

  • 藉由在連結私人端點連接 (例如，使用私人資料路徑) 來限制存取 Azure SQL Database 和 SQL 受控執行個體：

    • 受控執行個體可以在虛擬網路內隔離，以防止外部存取。 位於相同區域中同等或同儕節點互連虛擬網路的應用程式和工具可直接存取。 不同區域中的應用程式和工具，可以使用虛擬網路對虛擬網路連線，或 ExpressRoute 線路對等互連來建立連接。 客戶應該使用網路安全性群組 (NSG)，限制只有需要存取受控執行個體的資源才能存取埠 1433。
    • 針對 SQL Database，請使用可在為虛擬網路內的伺服器提供專用私人 IP 的私人連結功能。 您也可以使用虛擬網路服務端點搭配虛擬網路防火牆規則來限制對伺服器的存取。
    • 行動使用者應使用點對站 VPN 連線來透過資料路徑進行連接。
    • 連線至其內部部署網路的使用者，應該使用站對站 VPN 連線或 ExpressRoute 來透過資料路徑進行連接。

  • 您可以藉由連接到公用端點 (例如，使用公用資料路徑) 來存取 Azure SQL Database 和 SQL 受控執行個體。 應該考慮下列最佳做法：

    • 針對 SQL Database 中的伺服器，請使用 IP 防火牆規則來限制只能存取授權的 IP 位址。
    • 針對 SQL 受控執行個體，請使用網路安全性群組 (NSG)，將埠 3342 的存取限制為僅限所需的資源。 如需詳細資訊，請參閱配合公用端點安全使用受控實例。

    注意

    預設不會啟用 SQL 受控執行個體公用端點，且必須明確啟用。 如果公司政策不允許使用公用端點，請使用 Azure 原則，以防止在一開始就啟用公用端點。

  • 設定 Azure 網路元件：

設定 SQL Database/SQL 受控執行個體安全連線至 Power BI

最佳作法

設定 SQL Database/SQL 受控執行個體安全連線至應用程式服務

最佳作法

設定 SQL Database/SQL 受控執行個體安全連線的 Azure 虛擬機器主機

最佳作法

  • 在 Azure 虛擬機器的 NSG 上使用允許和拒絕規則的組合控制可從 VM 存取的區域。

  • 確定您的 VM 已根據 Azure 中 IaaS 工作負載的安全性最佳做法一文進行設定。

  • 確定所有 VM 都與特定的虛擬網路和子網有關聯。

  • 請根據有關強制通道的指引，評估您是否需要預設路由 0.0.0.0/網際網路。

    • 如果有需要 − 例如，前端子網 − 則保留預設路由。
    • 如果沒有需要 − 例如，中介層或後端子網 − 則啟用強制通道，如此一來就不會有流量透過網際網路抵達內部部署 (又稱跨單位)。

  • 如果您使用對等互連或連接至內部部署，請執行選用的預設路由。

  • 如果您需要將虛擬網路的所有流量傳送到網路虛擬裝置以進行封包檢查，請執行使用者定義的路由。

  • 使用虛擬網路服務端點透過 Azure 骨幹網路 的 Azure 儲存體等安全地存取 PaaS 服務。

防止分散式阻斷服務 (DDoS) 攻擊

分散式阻斷服務 (DDoS) 攻擊，惡意使用者會嘗試將大量網路流量傳送到 Azure SQL Database，目標是讓 Azure 基礎結構不堪負荷，使其拒絕有效的登入和工作負載。

提及於：OSA 實務 #9

實作方法

DDoS 保護已在 Azure 平台中自動啟用。 這包括一律開啟的流量監視，以及即時降低公用端點上的網路層級攻擊的風險。

最佳作法

  • 遵循最小化攻擊面中所述的作法，協助將 DDoS 攻擊威脅降至最低。

  • 「先進威脅防護」暴力密碼破解 SQL 認證警示有助於偵測暴力密碼破解攻擊。 在某些情況下，警示甚至可以區分滲透測試的工作負載。

  • 針對連接到 SQL Database 的 Azure VM 主機應用程式：

    • 請遵循建議，透過適用於雲端的 Microsoft Defender 中的網際網路面向端點來限制存取。
    • 使用虛擬機器擴展集在 Azure VM 上執行應用程式的多個執行個體。
    • 從網際網路停用 RDP 和 SSH 來以防止暴力密碼破解攻擊。

監視、記錄和稽核

本節參考的功能，可協助您偵測異常活動，指出不尋常的存取或惡意探索資料庫且可能有害的嘗試。 也會描述設定資料庫稽核以追蹤和捕捉資料庫事件的最佳做法。

保護資料庫免於遭受攻擊

進階威脅防護可讓您在發生異常活動時提供安全性警訊，讓客戶偵測並回應潛在威脅。

實作方法

  • 使用 SQL 的進階威脅防護偵測儲存體帳戶中異常以及可能有害的存取或攻擊意圖，包括：
    • SQL 插入式攻擊。
    • 竊取認證/洩漏。
    • 濫用權限。
    • 資料外流。

最佳作法

  • 針對特定伺服器或受控執行個體設定 SQL 的 Microsoft Defender。 您也可以啟用適用於雲端的 Microsoft Defender，針對訂用帳戶中的所有伺服器和受控執行個體設定 SQL 的 Microsoft Defender。

  • 如需完整的調查體驗，建議您啟用 SQL Database 稽核。 您可以透過稽核追蹤資料庫事件，並將事件寫入 Azure 儲存體帳戶或 Azure Log Analytics 工作區中的稽核記錄檔。

稽核重大安全性事件

追蹤資料庫事件可協助您了解資料庫活動。 您可以深入了解有可能指出業務疑慮或可疑安全性違規的不一致和異常。 也會啟用並促進遵守合規性標準。

實作方法

  • 啟用 SQL Database 的稽核或受控執行個體的稽核，來追蹤資料庫事件，並寫入您 Azure 儲存體帳戶、Log Analytics 工作區 (預覽) 或事件中樞 (預覽) 的稽核記錄檔中。

  • 您可將稽核記錄寫入 Azure 儲存體帳戶、Log Analytics 工作區 (以供 Azure 監視器記錄取用) 或事件中樞 (以供使用事件中樞取用)。 您可以設定這些選項的任何組合，並將稽核記錄寫入至每個組合。

最佳作法

注意

啟用 Log Analytics 的稽核將會根據內嵌費率產生費用。 請留意使用此選項的相關成本，或請考慮將稽核記錄儲存在 Azure 儲存體帳戶中。

其他資源

保護稽核記錄

限制存取儲存體帳戶，以支援職責區分並將 DBA 與稽者分開。

實作方法

  • 儲存稽核記錄檔至 Azure 儲存體時，請確定儲存體帳戶的存取權受限於最基本的安全性原則。 控制能存取儲存體帳戶的人員。
  • 如需詳細資訊，請參閱授權存取 Azure 儲存體。

最佳作法

安全性管理

本節描述管理資料庫安全性狀態不同的層面和最佳做法。 包括可確保您的資料庫設定為符合安全性標準的最佳做法，以便探索及分類和追蹤資料庫中潛在敏感性資料的存取權。

確定已將資料庫設定為符合安全性最佳做法

藉由探索及修補潛在的資料庫弱點，主動改善您的資料庫安全性。

實作方法

  • 啟用 SQL 弱點評量 (VA) 來掃描您的資料庫是否有安全性問題，並在定期資料庫中自動執行。

最佳作法

  • 起出請在您的資料庫上執行 VA，然後藉由修補相對於安全性最佳做法的失敗檢查來進行反覆運算。 設定可接受的設定基準，直到掃描結果為乾淨，或通過所有檢查為止。

  • 設定定期執行的掃描，一周執行一次，並設定讓相關人員可接收摘要電子郵件。

  • 檢閱每週掃描出來的 VA 摘要。 若找到的任何弱點，請評估先前掃描結果的資料漂移，並判斷是否應該解決檢查。 檢查設定中的變更是否有的合法原因。

  • 解決檢查結果並更新相關的基準。 建立解決動作的票證項目，追蹤這些項目，直到它們解決為止。

其他資源

識別並標記敏感性資料

探索可能包含敏感性資料的資料行。 敏感性資料的標準主要取決於客戶、合規性法規等，且必須由負責該資料的使用者進行評估。 分類資料行來使用基於進階敏感性的稽核和保護案例。

實作方法

  • 使用 SQL 資料探索與分類讓您探索、分類、標記及保護資料庫中的敏感性資料。
    • 在 SQL 資料探索和分類儀表板中，檢視自動探索所建立的分類建議。 接受相關分類，讓您的敏感性資料可以持續用分類標籤標記。
    • 針對非自動化機制探索到的任何其他敏感性資料欄位進行手動新增分類。
  • 如需詳細資訊，請參閱 SQL 資料探索與分類。

最佳作法

  • 定期監視分類儀表板，精準評量資料庫的分類狀態。 可以匯出或列印資料庫分類狀態的報表來進行分享以因應合規性和稽核。

  • 持續監視 SQL 弱點評定中推薦的敏感性資料狀態。 追蹤機密資料探索規則，識別推薦資料行中的任何資料漂移以進行分類。

  • 以特別針對您組織量身需求打造的方式來利用分類。 在適用於雲端的 Microsoft Defender 內的 SQL 資訊保護原則中，自訂您的「資訊保護」原則 (敏感度標籤、資訊類型、探索邏輯)。

追蹤敏感性資料的存取

監視存取敏感性資料的人員，並在稽核記錄中擷取敏感性資料的查詢。

實作方法

最佳作法

圖像化安全性和合規性狀態

使用統一的基礎結構安全性管理系統，強化資料中心的安全性狀態 (包括 SQL Database 中的資料庫)。 檢視有關資料庫安全性和合規性狀態的建議清單。

實作方法

常見的安全性威脅和潛在的風險降低措施

本節可協助您找到安全性措施防止特定的攻擊媒介。 您必須遵循上述一個或多個安全性指導方針，以達成大部分的風險降低措施。

安全性威脅：資料外流

資料外流是指在電腦或伺服器未經授權複製、傳輸或抓取資料。 查看維基百科上資料外流的定義。

透過公用端點連線到伺服器可能造成資料外流的風險，因為它需要客戶對對公用 IP 開啟其防火牆。

案例 1：：Azure VM 上的應用程式連線到 Azure SQL Database 中的資料庫。 惡意執行者取得 VM 的存取權，並加以入侵。 在此案例中，資料外流表示外部的個體可用惡意 VM 的連接到資料庫、複製個人資料，然後將其儲存在 blob 儲存體或不同訂用帳戶中不同的 SQL Database。

案例 2：：惡意的 DBA。 這種情況通常由受管控產業的敏感安全性客戶引發。 在此案例中，高級權限的使用者可能會將資料從 Azure SQL Database 複製到不受資料擁有者控制的另一個訂用帳戶。

可能的風險降低措施

現在 Azure SQL Database 和 SQL 受控執行個體提供下列技術來緩和資料外流的威脅：

  • 在 Azure 虛擬機器的 NSG 上使用允許和拒絕規則組合控制 VM 可存取的區域。
  • 如果是在 SQL Database 中使用伺服器，請設定下列選項：
    • 允許 Azure 服務設定為 [關閉]。
    • 藉由設定 VNet 防火牆規則，只允許來自包含 Azure VM 的子網路流量。
    • 使用私人連結
  • 針對 SQL 受控執行個體，預設使用私人 IP 存取來解決惡意 VM 第一個資料外流的問題。 在子網路上開啟子網路委派功能，來在 SQL 受控執行個體子網路上自動設定最嚴格的原則。
  • SQL 受控執行個體公開會更加顯露惡意 DBA 的問題，因為它有更大的介面區，且客戶可以看到網路需求。 最好的風險降低措施，就是套用本安全性指南中的所有作法，從一開始就防止惡意 DBA 案例 (不只用於資料外流)。 Always Encrypted 是一種保護敏感性資料的方法，將資料加密，並讓 DBA 無法存取金鑰。

商務持續性和可用性的安全性層面

多數的安全性標準都可因應作業持續性的資料可用性，藉由執行備援和容錯移轉功能來避免單一失敗點。 保留資料和備份的紀錄檔是針對嚴重損壞狀況的常見作法。 下一節將提供 Azure 內建功能的概要說明。 也提供其他選項來設定以符合特定需求：

下一步