Azure SQL 透明資料加密使用客戶管理的金鑰

適用於：Azure SQL 資料庫Azure SQL 受控執行個體Azure Synapse Analytics (僅限專用的 SQL 集區)

結合使用 Azure SQL 中的透明資料加密 (TDE)與客戶自控金鑰 (CMK)，可使自帶金鑰 (BYOK) 案例進行靜止資料保護，並讓組織能在金鑰和資料管理中實現職責分離。 使用客戶自控 TDE，客戶將負責完全控制金鑰生命週期管理 (金鑰的建立、上傳、輪替、刪除)、金鑰使用權限及對金鑰作業進行稽核。

在此情境中，透明資料加密（TDE）保護器是客戶管理的金鑰，用來保護資料庫加密金鑰（DEK）。 你可以將 TDE 保護器存放在 Azure Key Vault 或 Azure Key Vault Managed HSM 中，這兩者是設計為高可用性與可擴展性的雲端金鑰管理服務。 這兩項服務都支援由 FIPS 140-2 驗證硬體保護的加密金鑰：Azure Key Vault 支援 FIPS 140-2 第二級，而 Azure Key Vault Managed HSM 則支援 FIPS 140-2 第三級。 這兩個服務也都支援非對稱與對稱金鑰類型，且所支援的演算法與使用方式取決於 TDE 部署模型。 你可以在服務中產生金鑰、匯入，或 安全地從本地的 HSM 轉移金鑰。 直接存取金鑰受到限制，因此授權服務執行密碼學操作時不會暴露金鑰資料。

針對 Azure SQL 資料庫 和 Azure Synapse Analytics，可在伺服器層級上設置 TDE 保護裝置，並由所有與該伺服器建立關聯的加密資料庫繼承。 針對 Azure SQL 受控執行個體，系統會將 TDE 保護裝置設定於執行個體層級，並由該執行個體上的所有加密資料庫繼承。 在本文中，伺服器一詞既指 SQL Database 和 Azure Synapse 中的伺服器，也指 SQL 受控執行個體中的受控執行個體，除非另有說明。

可以在 Azure SQL 資料庫的資料庫層級管理 TDE 保護裝置。 如需詳細資訊，請參閱透明資料加密 (TDE) 資料庫層級的客戶自控金鑰。

注意

本文適用於 Azure SQL 資料庫、Azure SQL 受控執行個體和 Azure Synapse Analytics (原為 SQL DW 的專用 SQL 集區)。 如需 Synapse 工作區內專用 SQL 集區透明資料加密的詳細資訊，請參閱 Azure Synapse Analytics 加密。

注意

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

客戶管理金鑰 （CMK） 和自備金鑰 （BYOK）

在本文中，客戶管理密鑰（CMK）和「攜帶您自己的密鑰」一詞會交替使用，但代表一些差異。

  • 客戶管理金鑰 （CMK） - 客戶會管理金鑰生命週期，包括金鑰建立、輪替和刪除。 密鑰會儲存在 Azure Key Vault 或 Azure 受控 HSM 中，並用於在 Azure SQL、Azure VM 上的 SQL Server 和內部部署 SQL Server 中加密資料庫加密金鑰（DEK）。

  • 攜帶您自己的金鑰 （BYOK） - 客戶安全地將自己的金鑰從內部部署硬體安全性模組 （HSM） 帶入 Azure Key Vault 或 Azure 受控 HSM。 這類匯入的金鑰可做為 Azure Key Vault 中的任何其他金鑰使用，包括作為客戶管理的金鑰來加密 DEK。 如需詳細資訊，請參閱 將受 HSM 保護的金鑰匯入受控 HSM （BYOK）。

由客戶管理的 TDE 的優點

客戶所管理 TDE 可為客戶提供下列優點：

  • 對 TDE 保護器的使用和管理進行完整和細緻的控制。

  • TDE 保護裝置使用方式的透明度。

  • 在組織內金鑰和數據管理中實作職責分離的能力。

  • Azure Key Vault 系統管理員可以撤銷密鑰訪問許可權，讓加密的資料庫無法存取。

  • 在 Azure Key Vault 中集中管理金鑰。

  • 更信任您的終端客戶，因為 Azure Key Vault 的設計目的是讓Microsoft看不到或擷取加密密鑰。

重要

對於使用由服務提供者管理的 TDE 而想轉為客戶自控 TDE 的使用者，在轉換過程中，資料仍然保持加密狀態，不會出現停機情況，也不需要重新加密資料庫檔案。 從服務管理金鑰切換至客戶管理金鑰金鑰時，只需要重新加密 DEK 即可，而這是快速的線上作業。

設定由客戶管理的 TDE（透明資料加密）的權限

此圖表顯示客戶自控 TDE 的設定和功能。

選取您想要使用的 Azure Key Vault 類型。

為了讓 Azure 中的邏輯伺服器使用 Azure Key Vault 中儲存的 TDE 保護器來加密 DEK，Key Vault 管理員必須以伺服器獨特的 Microsoft Entra 身份授權存取權限。 伺服器身分識別可以是系統指派的受控識別，或指派給伺服器的使用者指派受控識別。 有兩種存取模型可授與伺服器金鑰保存庫的存取權：

  • Azure 角色型存取控制 (RBAC) - 使用 Azure RBAC 授予使用者、群組或應用程式金鑰保存庫的存取權。 建議使用此方法，因為它兼具彈性和細微性。 伺服器身分識別需要金鑰保存庫 加密服務使用者角色，才能使用金鑰進行加密和解密作業。

  • 保存庫存取原則 - 使用金鑰保存庫存取原則，將金鑰保存庫的存取權授與伺服器。 此方法較簡單直接，但較不具彈性。 伺服器身分識別必須在金鑰保存庫具有下列權限：

    • get - 用於擷取 Azure Key Vault 中金鑰的公用部分和屬性
    • wrapKey - 能夠保護 (加密) DEK
    • unwrapKey - 能夠解除包裝並解密 DEK

在金鑰保存庫 [存取設定] Azure 入口網站 功能表，您可以選取 [Azure 角色型存取控制] 或 [保存庫存取原則]。 如需設定 TDE 之 Azure Key Vault 存取設定的逐步指示，請參閱使用 Azure Key Vault 設定 SQL Server TDE 可延伸金鑰管理。 如需存取模型詳細資訊，請參閱 Azure Key Vault 安全性。

金鑰保存庫系統管理員也可以啟用金鑰保存庫稽核事件的記錄，以便稍後進行稽核。

當伺服器設定為使用來自 Azure Key Vault 的 TDE 保護裝置時，伺服器會將每個已啟用 TDE 的資料庫 DEK 傳送至密鑰保存庫以進行加密。 金鑰保存庫會傳回加密的 DEK，然後將其儲存在使用者資料庫中。

在有需要時，伺服器會將受保護的 DEK 傳送至金鑰保存庫以進行解密。

稽核員可以使用 Azure 監視器來檢閱金鑰庫的稽核事件記錄檔，前提是已啟用記錄功能。

注意

任何權限變更可能需要大約 10 分鐘的時間，才會對金鑰庫生效。 這包括撤銷 AKV 中 TDE 保護裝置的存取權限，而此時間範圍內的使用者可能仍有存取權限。

設定客戶管理 TDE 的要求

  • 必須在 Azure Key Vault 上啟用 軟刪除 和 清除保護 的功能。 這有助於避免意外或惡意將金鑰保存庫或金鑰刪除的情形，這種狀況會導致資料庫進入無法存取的狀態。 在設定現有伺服器或建立伺服器時的 TDE 保護程式，Azure SQL 會驗證所使用的金鑰保存庫是否已啟用軟刪除和清除保護功能。 如果未在金鑰保存庫上啟用虛刪除和清除保護，TDE 保護裝置安裝作業會失敗並發生錯誤。 在此情況下，必須先在金鑰保管庫上啟用軟刪除和清理保護，接著再進行 TDE 保護裝置的設定。

  • 搭配 Azure Key Vault 使用防火牆時，除非您使用 Azure Key Vault 的私人端點，否則您必須啟用 [允許受信任的Microsoft服務略過防火牆] 選項。 如需詳細資訊，請參閱設定 Azure Key Vault 防火牆和虛擬網路。

配置 TDE 保護器的關鍵要求

透明資料加密 使用客戶管理金鑰使用外部金鑰，稱為 TDE 保護器，儲存在 Azure Key Vault 或 Azure Managed HSM 中以保護資料庫加密金鑰（DEK）。

適用以下要求。

支援的金鑰類型與大小

根據 Azure SQL 產品與 TDE 配置，TDE 保護器可由儲存在 Azure Key Vault 或 Azure Key Vault Managed HSM 中的非對稱或對稱金鑰支援。

  • 非對稱金鑰（RSA 或 RSA HSM）

    • 支援於 Azure Key Vault 及 Azure Key Vault Managed HSM
    • 支援的金鑰大小：2,048 位元與 3,072 位元
    • 支援 Azure SQL Database、Azure SQL 受控執行個體 及 Azure Synapse Analytics

  • 對稱鍵（AES）

    • Azure Key Vault Premium（預覽）和 Azure Key Vault 受控 HSM 均支援此功能
    • 支援的金鑰大小：128 位元、192 位元及 256 位元
    • 僅支援 Azure SQL Database，目前處於公開預覽階段

注意

透明資料加密 with symmetric key（AES）目前處於預覽階段。 預覽功能雖然功能有限，但 Microsoft 會以預覽方式提供，讓客戶能搶先體驗並提供回饋。 預覽功能受限於個別補充預覽條款，但不受 SLA 限制。 在某些情況下，會盡最大努力提供支援。 不過，Microsoft 支援服務熱切希望獲得您對預覽功能的意見反應，並在某些情況下盡力提供最佳支援。 預覽功能可能具有有限或受限的功能，而且只能在選取的地理區域使用。

對稱（AES）金鑰的金鑰管理行為

你可以使用存放在 Azure Key Vault Premium（預覽版）或 Azure Key Vault Managed HSM 中的對稱（AES）金鑰作為 TDE 保護器。 要開始使用來自本地硬體安全模組（HSM）的金鑰，請將金鑰匯入任一服務。 初始匯入後，所有持續進行的金鑰生命週期操作皆在 Azure Key Vault Premium（預覽版）或 Azure Key Vault Managed HSM 中進行。 時間點還原、異地災難復原及金鑰重新驗證都取決於該處的金鑰持續可用。 維護匯入金鑰的本地備份，以支援復原與重新驗證情境。 此行為僅適用於對稱（AES）金鑰，不適用於非對稱（RSA）金鑰。

關鍵狀態與有效性要求

  • 若指定金鑰啟用日期，必須設定為過去的日期與時間。
  • 若指定金鑰到期日，必須設定為未來的日期與時間。
  • 金鑰必須處於「已啟用」狀態。

主要進口需求

如果您將現有金鑰匯入 Azure Key Vault，請以以下支援格式之一提供該金鑰：

  • .pfx
  • .byok
  • .backup

若要將受 HSM 保護的金鑰匯入 Azure 受控 HSM，請參閱 將受 HSM 保護的金鑰匯入受控 HSM （BYOK） 。

注意

在 v2.8.0 版之前的 Thales CipherTrust Manager 存在一個問題，導致新匯入到 Azure 金鑰保存庫的金鑰無法用於 Azure SQL Database 或 Azure SQL 受控執行個體 中的客戶管理 TDE (透明資料加密) 情境。 欲了解更多此問題細節，請參閱 CipherTrust Cloud Key Manager 發布說明。 在這種情況下，將密鑰匯入 Azure Key Vault 之後，請等候 24 小時，以開始使用它作為伺服器或受控實例的 TDE 保護裝置。 此問題已在 Thales CipherTrust Manager v2.8.0 中解決。

關於配置客戶管理 TDE 的建議

  • 為確保最佳效能與可靠性，建議使用專用的 Azure Key Vault 來管理 Azure SQL。 不要把這個金鑰庫分享給其他服務。 若金鑰庫因共用使用或過度金鑰操作而負載過重，可能會對資料庫效能產生負面影響，尤其是在加密金鑰存取時。 Azure 金鑰保存庫會強制執行 節流限制。 當超過這些限制時，作業可能會延遲或失敗。 此風險在伺服器故障轉移期間最高，該故障觸發伺服器上每個資料庫的金鑰操作。

    如需節流行為的詳細資訊，請參閱 Azure 金鑰保存庫節流指引。

    若要維持高可用性並避免節流問題，請遵循每個訂用帳戶的下列指導方針：

    • 針對 Azure SQL 資源使用 專用的 Azure 金鑰保存庫 。

    • 將 不超過 500 個一般用途資料庫 與單一 Azure 金鑰保存庫產生關聯。

    • 將 不超過 200 個業務關鍵資料庫 與單一 Azure 金鑰保存庫產生關聯。

    • 可與單一 Azure 金鑰保存庫相關聯的超大規模資料庫數目是由頁面伺服器數目所決定。 每一個頁面伺服器都會連結至邏輯資料檔。 若要尋找頁面伺服器的數目，請執行下列查詢。

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      不要將超過 500 台頁面伺服器與單一 Azure Key Vault 關聯。 隨著資料庫的成長，頁面伺服器的數目會自動增加，因此定期監視資料庫大小非常重要。 如果頁面伺服器數量超過 500 台，請為每個超大規模資料庫使用專用的 Azure Key Vault，且不要與其他 Azure SQL 資源共用該 Key Vault。

    • 監視 和設定 Azure 金鑰保存庫 警示。 如需監視和警示的詳細資訊，請參閱 監視 Azure 金鑰保存庫 和 設定 Azure 金鑰保存庫警示。

  • 為了配合長期密碼韌性規劃，建議使用 AES-256 對稱金鑰作為 TDE 保護器。

    大規模量子運算預計將破解像RSA這類公鑰密碼演算法。 對稱密碼學，包括 AES，在足夠大的金鑰大小下被認為是量子韌性的。

    Microsoft 更廣泛的量子安全策略強調加密敏捷性。 在支援的情況下採用更強的對稱式演算法，並隨著指引和標準的演進，規劃未來的密碼技術轉型。

    重要

    透明資料加密 with symmetric keys（AES）目前僅支援 Azure SQL Database，並處於公開預覽階段。

  • 在金鑰保存庫上設定資源鎖定，藉此控制可刪除這項重要資源的人員，並防止意外或未經授權的刪除發生。 深入了解資源鎖定。

  • 啟用所有加密金鑰的稽核和報告：Azure Key Vault 提供可輕鬆插入其他安全性資訊和事件管理工具的記錄。 例如，Operations Management Suite Log Analytics 即是已整合的服務之一。

  • 使用 Azure 區域中的金鑰保存庫，可將內容復寫至配對區域，以取得最大可用性。 如需詳細資訊，請參閱 使用 Azure Key Vault 和 Azure Key Vault 可用性和備援的最佳作法。

注意

為了在設定客戶管理的 TDE 方面有更大的彈性，現在可以將一個區域中的 Azure SQL Database 和 Azure SQL 受控實例連結至任何其他區域中的 Azure Key Vault。 伺服器和金鑰保存庫不需要共置於相同的區域。

關於設定 TDE 保護器的建議

  • 將 TDE 保護裝置的金鑰複本置於安全位置，或將其提供給委付服務。

  • 如果密鑰是在金鑰保存庫中產生，請先建立金鑰備份，然後再第一次在 Azure Key Vault 中使用金鑰。 備份只能還原至 Azure Key Vault。 深入了解 Backup-AzKeyVaultKey 命令。 Azure 受控 HSM 支援建立 HSM 整個內容的完整備份，包括所有密鑰、版本、屬性、標籤和角色指派。 如需詳細資訊，請參閱 完整備份和還原和選擇性密鑰還原。

  • 對金鑰進行任何變更 (例如金鑰屬性、標籤、ACL) 時，即建立新的備份。

  • 在輪換金鑰時，將舊版本的金鑰保留在金鑰庫或受管理的 HSM 中，這樣你才能還原較舊的資料庫備份。 當資料庫的 TDE 保護器更換時，舊的資料庫 備份不會更新 以使用最新的 TDE 保護器。 在還原時，每個備份都必須使用在建立時加密的 TDE 保護裝置。 要旋轉金鑰，請依照文章《 旋轉透明資料加密（TDE）保護器》中的指示操作。

  • 即使在切換至服務管理的密鑰之後，在 Azure Key Vault 或 Azure 受控 HSM 中保留所有先前使用的金鑰。 它可確保使用儲存在 Azure Key Vault 或 Azure 受控 HSM 中的 TDE 保護裝置來還原資料庫備份。 使用 Azure Key Vault 或 Azure 受控 HSM 建立的 TDE 保護裝置必須維持，直到使用服務管理的密鑰建立所有剩餘的預存備份為止。 使用 Backup-AzKeyVaultKey 建立這些金鑰的可復原備份複本。

  • 若要在安全性事件期間移除可能遭到入侵的金鑰，而不會有資料遺失的風險，請遵循使用 PowerShell 移除透明資料加密 （TDE） 保護程式一文中的步驟。 刪除或停用被入侵的金鑰前，務必更換新的 TDE 保護器，並確認所有資料庫都在使用新金鑰。 刪除或停用金鑰且未先輪換，會使所有加密資料庫無法存取，且不會使先前備份並還原到其他保險庫的金鑰副本失效。

小提示

使用具版本和無版本的 Azure 金鑰保存庫密鑰進行 TDE

當你設定 TDE 保護器時，你可以用特定的金鑰版本或無版本的金鑰識別碼來參考 Azure Key Vault 金鑰。

在這兩種情況下，Azure SQL Database 都會解析並使用最新啟用的 Azure Key Vault 或 Azure Key Vault Managed HSM 中的金鑰版本。 使用無版本金鑰識別碼以避免在 TDE 保護器配置中嵌入特定金鑰版本。

目前僅支援 Azure SQL 資料庫的無版本金鑰識別碼。

範例：

  • 包含特定版本的金鑰識別碼

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • 無版本金鑰識別碼

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

TDE 保護裝置旋轉

旋轉 TDE 保護器可以替換用於保護資料庫加密金鑰（DEK）的金鑰。 金鑰輪替是一項線上作業，完成應只需幾秒。 此作業只會解密和重新加密資料庫加密金鑰，而不是整個資料庫。

你可以透過切換設定，使用存放在 Azure Key Vault 或 Azure Key Vault Managed HSM 中的新金鑰來輪換 TDE 保護器。 根據 Azure SQL 的提供內容及支援的設定，這可能包括：

  • 切換至同一金鑰的新版本
  • 切換到不同按鍵
  • 在支援的金鑰類型間切換，例如非對稱（RSA）與對稱（AES）金鑰

注意

透明資料加密 with symmetric keys（AES）目前僅支援 Azure SQL Database，並處於公開預覽階段。

TDE 保護裝置輪替可以手動執行，或使用自動輪替功能執行。

設定伺服器的 TDE 保護裝置時，可以啟用 TDE 保護裝置的自動輪替。 自動旋轉預設為停用。 啟用時，伺服器會持續檢查金鑰保存庫或受控 HSM 中，是否有用作 TDE 保護裝置的任何新版本金鑰。 如果偵測到金鑰的新版本，伺服器或資料庫上的 TDE 保護裝置會在 24 小時內自動輪換至最新的金鑰版本。

搭配 Azure Key Vault 中的自動化金鑰輪替 或 Azure 受控 HSM 中的自動輪替使用時，此功能會啟用 Azure SQL Database 和 Azure SQL 受控實例上 TDE 保護功能的端對端零觸控輪替。

注意

使用手動或自動輪換金鑰來設定 CMK 的 TDE 一律會使用支援的最新版本金鑰。 安裝程式不允許使用舊版或較低版本的金鑰。 一律使用最新版本金鑰符合 Azure SQL 安全性原則，該原則不允許可能遭入侵的舊版金鑰。 資料庫備份或還原可能需要舊版金鑰，特別是長期保留備份必須保留舊版金鑰。 針對異地複寫設定，來源伺服器所需的所有金鑰都需要存在於目標伺服器上。

設定 TDE 加密保護器自動輪替時的地理複寫考量

若要避免在建立或異地複寫期間發生問題，在主要或次要伺服器上啟用 TDE 保護裝置的自動輪替時，請務必在設定異地複寫時遵循下列規則：

  • 主要和次要伺服器都必須具有主要伺服器金鑰保存庫 (含有主要伺服器 TDE 保護裝置金鑰的金鑰保存庫) 的 Get、wrapKey 和 unwrapKey 權限。

  • 對於啟用自動金鑰輪替的伺服器，在起始異地複寫之前，將作為主要伺服器上 TDE 保護裝置使用的加密金鑰新增至次要伺服器。 輔助伺服器需要存取在相同的金鑰保存庫或用於主伺服器的受控 HSM 中的金鑰（而不是使用具有相同金鑰材料的其他金鑰）。 或者，在起始異地複寫之前，請確定次要 伺服器的受控識別 （使用者指派或系統指派） 在主要伺服器的金鑰保存庫或受控 HSM 上具有必要的許可權，而且系統會嘗試將金鑰新增至次要伺服器。

  • 針對現有的異地複寫設定，在主要伺服器上啟用自動金鑰輪替之前，請先將主要伺服器上用作 TDE 保護程式的加密金鑰新增至次要伺服器。 輔助伺服器需要存取在相同的金鑰保存庫或用於主伺服器的受控 HSM 中的金鑰（而不是使用具有相同金鑰材料的其他金鑰）。 或者，在啟用自動金鑰之前，請確定次要 伺服器的受控識別 （使用者指派或系統指派） 具有主要伺服器金鑰保存庫的必要許可權，而且系統會嘗試將金鑰新增至次要伺服器。

  • 支援使用客戶管理金鑰（CMK）進行 TDE 的地理複製場景。 如果您要在 Azure 入口網站中設定 TDE，則必須在所有伺服器上設定使用自動金鑰輪替的 TDE。 深入了解如何在 TDE 的異地複寫設定中設定自動金鑰輪替，請參閱異地複寫設定的自動金鑰輪替。

無法存取的 TDE 保護裝置

當 TDE 設定為使用客戶自控金鑰時，資料庫需要持續存取 TDE 保護裝置才能保持線上狀態。 如果伺服器失去 Azure Key Vault 或 Azure 受控 HSM 中客戶管理的 TDE 保護裝置的存取權，則資料庫最多 10 分鐘會開始拒絕所有具有對應錯誤訊息的連線，並將其狀態變更為 無法存取。 在處於無法存取狀態的資料庫上，唯一允許的動作是將其刪除。

無法存取的狀態

如果資料庫因間歇性網路中斷 （例如 5XX 錯誤） 而無法存取，則不需要採取任何動作，因為資料庫會自動重新上線。 為了減少在 Azure 金鑰保存庫或 Azure 受控 HSM 中存取 TDE 保護程式時網路錯誤或中斷的影響，在服務嘗試將資料庫移至無法存取狀態之前，會引進 24 小時緩衝區。 如果在達到無法存取的狀態之前發生故障轉移，資料庫就會因為遺失加密快取而變成無法使用。

如果伺服器因為任何 Azure 金鑰保存庫 錯誤 （例如 4XX 錯誤） 而失去對 Azure 金鑰保存庫或 Azure 受控 HSM 中客戶管理 TDE 保護裝置的存取權，則資料庫會在 30 分鐘後移至無法存取狀態。

在 Azure Key Vault 或 Azure 受控 HSM 錯誤之後恢復資料庫存取

還原金鑰的存取權之後，讓資料庫重新上線需要額外的時間和步驟，這可能會根據金鑰無法使用的持續時間和資料庫內資料的大小而有所不同。

如果金鑰存取在 30 分鐘內還原，則資料庫會在後續一小時內自動修復。 不過，如果金鑰存取在超過 30 分鐘後還原，則無法自動修復資料庫。 在這種情況下，還原資料庫牽涉到透過 Azure 入口網站進行額外的程式，視資料庫的大小而定，可能很耗時。

資料庫重新上線之後，先前設定的伺服器層級設定，包括容錯移轉群組設定、標籤，以及資料庫層級設定，例如彈性集區設定、讀取調整、自動暫停、時間點還原歷程記錄、長期保留原則等，都會遺失。 因此，建議客戶建立通知系統，以在發生加密密鑰存取權限遺失後30分鐘內進行偵測。 在 30 分鐘的時間範圍過期之後，建議您驗證已復原資料庫上的所有伺服器和資料庫層級設定。

以下是入口網站上使無法存取的資料庫重新上線所需的額外步驟的檢視。

TDE BYOK 無法存取資料庫的螢幕擷取畫面。

意外 TDE 保護裝置存取權撤銷

如果某人擁有密鑰保存庫的足夠訪問許可權，或受控 HSM 不小心停用對密鑰的伺服器存取，可能會發生下列情況：

  • 撤銷伺服器的金鑰保存庫或受控 HSM 的 get、wrapKey、unwrapKey 許可權

  • 刪除金鑰

  • 刪除金鑰保存庫或受控 HSM

  • 變更金鑰保存庫或受管理 HSM 防火牆規則

  • 刪除 Microsoft Entra ID 中伺服器的受控身分識別

深入了解導致資料庫變得無法存取的常見原因。

SQL 受控實例與 Azure Key Vault 或 Azure 受控 HSM 之間的封鎖連線

SQL 受控實例與密鑰保存庫或受控 HSM 之間的網路連線區塊大多發生在金鑰保存庫或受控 HSM 資源存在，但無法從受控實例聯機到其端點時發生。 所有可以連線到金鑰保存庫或受控 HSM 端點，但連線遭到拒絕、遺失許可權等的案例，都會導致資料庫將其狀態變更為 [無法存取]。

Azure Key Vault 或 Azure 受控 HSM 的網路連線不足最常見的原因是：

  • Azure Key Vault 或 Azure 受控 HSM 會透過私人端點公開，而且在與受控實例子網相關聯的網路安全組 （NSG） 輸出規則中，不允許 Azure Key Vault 或 Azure 受控 HSM 服務的私人 IP 位址。

  • 錯誤的 DNS 解析，例如密鑰保存庫或受控 HSM 的全域唯一名稱（FQDN）無法解析，或解析為無效的 IP 地址。

測試從 SQL 受控實例到裝載 TDE 保護裝置的 Azure Key Vault 或 Azure 受控 HSM 的連線能力。

  • 端點是您的保管庫 FQDN，例如 <vault_name>.vault.azure.net (沒有 https://)。
  • 要測試的連接埠為 443。
  • RemoteAddress 的結果應該存在，而且是正確的 IP 位址
  • TCP 測試的結果應該是 TcpTestSucceeded: True。

如果測試傳回 TcpTestSucceeded: False，請檢閱網路設定：

  • 檢查已解析的 IP 位址，確認是有效位址。 遺漏值表示發生 DNS 解析問題。

    • 確認受控實例上的網路安全組具有涵蓋埠 443 上已解析 IP 位址的 輸出 規則，特別是當解析的位址屬於密鑰保存庫或受控 HSM 私人端點時。

    • 檢查路由表、虛擬裝置及其設定等其他網路設定。

監控客戶管理的 TDE

若要監視資料庫狀態及啟用 TDE 保護裝置存取的遺失警示，請設定 Azure 的下列功能：

  • Azure 資源健康狀態。 在第一次拒絕連線到資料庫之後，因失去 TDE 保護程式的存取權而導致無法存取的資料庫會顯示為「無法使用」。

  • 活動記錄當無法存取客戶管理金鑰保存庫中的 TDE 保護裝置時，系統會將這些項目新增至活動記錄中。 建立這些事件的警示，可讓您儘快恢復存取。

  • 動作群組可定義為根據偏好來傳送通知和警示，例如電子郵件/簡訊/推播/語音、邏輯應用程式、Webhook、ITSM 或自動化 Runbook。

使用客戶管理的 TDE 的資料庫 backup 和 restore

使用來自 Azure Key Vault 或 Azure 受控 HSM 的金鑰以 TDE 加密資料庫之後，任何新產生的備份也會使用相同的 TDE 保護裝置加密。 TDE 保護裝置有所變更時，資料庫的舊備份不會更新為使用最新 TDE 保護裝置。

若要從 Azure Key Vault 或 Azure 受控 HSM 還原使用 TDE 保護裝置加密的備份，請確定目標伺服器可以使用密鑰數據。 因此，建議您將所有舊版 TDE 保護裝置保留在金鑰保存庫或受控 HSM 中，以便還原資料庫備份。

重要

伺服器隨時不能設定一個以上的 TDE 保護裝置。 在 Azure 入口網站窗格中，標示為 將金鑰設定為預設 TDE 保護裝置 的金鑰，便是 TDE 保護裝置。 不過，多個密鑰可以連結至伺服器，而不將它們標示為 TDE 保護裝置。 這些金鑰不會用於保護 DEK，但如果備份檔案是以具有對應雜湊碼的密鑰加密，則可以在從備份還原時使用。

如果還原備份時可能需要的金鑰不再可供目標伺服器使用，則會傳回下列錯誤訊息：「目標伺服器 <Servername> 無法存取在 <Timestamp #1> 與 <Timestamp #2> 之間建立的所有 AKV URI。 請先還原所有的 AKV URI，再重試作業。」

若要避免此情形，請針對目標伺服器執行 Get-AzSqlServerKeyVaultKey Cmdlet，或針對目標受控執行個體執行 Get-AzSqlInstanceKeyVaultKey，以傳回可用的金鑰清單，並找出遺失的金鑰。 為確保所有備份均可還原，請確定還原的目標伺服器有權存取所有所需金鑰。 這些金鑰不必標記為 TDE 保護裝置。

若要深入瞭解 SQL Database 的備份復原，請參閱 從 Azure SQL Database 中的備份還原資料庫。 若要深入了解 Azure Synapse Analytics 中專用 SQL 集區的備份復原，請參閱復原專用的 SQL 集區。 如需使用 SQL 受控執行個體的 SQL Server 原生備份/還原，請參閱 快速入門：使用 SSMS 將資料庫還原至 Azure SQL 受控執行個體。

記錄檔的另一項考量：備份的記錄檔仍會以原始 TDE 保護裝置加密，即使其已輪替且資料庫目前使用新的 TDE 保護裝置，仍是如此。 還原時，必須要有這兩個金鑰才能還原資料庫。 如果記錄檔使用儲存在 Azure 金鑰保存庫或 Azure 受控 HSM 中的 TDE 保護裝置，則在還原時需要此金鑰，即使資料庫已變更為同時使用服務受控 TDE。

客戶管理 TDE 的高可用性

透過 Azure Key Vault 或 Azure 受控 HSM 提供多層備援，使用客戶受控密鑰的 TDE 可以利用 Azure Key Vault 或 Azure 受控 HSM 可用性和復原能力，並完全依賴 Azure Key Vault 或 Azure 受控 HSM 備援解決方案。

即使個別服務元件失敗或 Azure 區域或可用性區域已關閉，Azure Key Vault 多個備援層仍可確保密鑰存取。 如需詳細資訊，請參閱 Azure Key Vault 可用性與備援。

Azure Key Vault 提供下列可用性和復原元件，這些元件會自動提供，而不需要使用者介入：

注意

針對所有配對區域，Azure Key Vault 金鑰會複寫到這兩個區域，而且這兩個區域中都有硬體安全性模組 （HSM）可在這些密鑰上運作。 如需詳細資訊，請參閱 數據復寫。 這適用於標準和進階 Azure 金鑰保存庫 服務層級，以及軟體或硬體密鑰。

Azure 受控 HSM 多重區域複寫可讓您將 Azure 受控 HSM 集區從一個 Azure 區域（稱為主要區域）延伸至另一個 Azure 區域（稱為擴充區域）。 設定好之後，這兩個區域都處於作用中狀態，能夠處理要求，而且透過自動化複寫，共用相同的密鑰資料、角色和許可權。 如需詳細資訊，請參閱 在 Azure 受控 HSM 上啟用多重區域複寫。

利用客戶管理的 TDE 進行地理災害復原

主動式地理複製 與 故障轉移群組 支援客戶管理的 TDE。 主伺服器和次要伺服器可在任何支援區域使用 Azure Key Vault 或 Azure Managed HSM。 伺服器和金鑰儲存不一定要在同一區域。

要成功進行故障轉移，兩台伺服器都必須能存取所有包含所需金鑰的 Azure Key Vault 或 Azure Managed HSM。

設置方面的考量

當您在 Azure 入口網站中設定主動式地理複製或故障轉移群組時，需考慮以下事項：

  • TDE 保護器位置：主伺服器與次要伺服器可以使用相同的 Azure Key Vault 或 Azure Managed HSM。 使用相同的金鑰庫可以降低金鑰材料不同步的風險。如果你在多個區域使用獨立的金鑰庫，必須保持所需的金鑰資料同步。 關於金鑰存儲韌性，請參閱 Azure Key Vault 的可用性與冗餘，以及 Managed HSM 中的多區域複製。

  • 區域冗餘：在可用的情況下，Azure SQL Database 或 Azure SQL 受控執行個體 的區域冗餘能在區域內提供額外的韌性。 如需詳細資訊，請參閱 什麼是 Azure 可用性區域？。

  • 金鑰權限：主伺服器與次要伺服器必須對每個包含必要 TDE 保護器的 Azure Key Vault 或 Azure Managed HSM 擁有所需權限。

  • 金鑰可用性： 確保所需金鑰同時存在於主伺服器與次要伺服器。 伺服器不必使用相同的 TDE 保護器，但每台伺服器必須擁有相同的金鑰材料。 你可以透過 Azure 入口網站、PowerShell、Azure CLI 或 Azure SQL REST API 來為伺服器新增金鑰。 如果在故障轉移時所需的金鑰無法取得，資料庫可能會無法存取。

  • 私有端點：如果你在 Azure SQL 中使用私有端點，設定可能需要更複雜的 DNS 區域（例如，它無法在同一 DNS 區域內建立兩個私有端點，指向同一資源）。

  • 應用程式連接性： 應用程式應使用重試邏輯來處理故障轉移期間的暫時性故障。

關於配置 Azure SQL 地理災難復原資源的資訊，請參閱主動地理複製或故障轉移群組的概述與最佳實務。

重要

當你建立地理複製連結或故障轉移群組時，Azure SQL 會驗證兩台伺服器都能存取所有必要的客戶管理金鑰。 如果任一伺服器無法取得所需的金鑰，建立操作就會失敗。 例如，若主伺服器與次要伺服器分別使用金鑰 A 與金鑰 B，則在建立地理複製連結或故障轉移群組前，先將兩個金鑰加入兩台伺服器。

下圖展示了 Azure SQL 地理複製，搭配故障轉移群組，以及 Azure Key Vault 跨區域故障轉移，採用配對區域配置：

圖表，顯示配對區域的 Azure Key Vault 跨區域故障轉移支援。

Azure Key Vault 在故障轉移期間的行為

  • Azure Key Vault 是啟動故障轉移的，不是你。
  • 當主要區域中的金鑰庫無法使用時，金鑰庫會處於唯讀狀態。
  • 只有在主區域的金鑰庫還在時，才能建立、匯入和更換金鑰。 故障轉移後，金鑰輪替會維持封鎖狀態，直到主要區域再次可連線。
  • 你無法選擇或檢查鑰匙庫目前所在的區域，也無法手動連接次要區域。

從無法存取的 TDE 保護裝置復原

如果處於活躍地理複製關係或故障轉移群組的資料庫無法存取，Azure SQL 控制平面會斷開連結，並將資料庫轉換成獨立資料庫。

在你恢復金鑰權限後，通常可以讓主要資料庫重新上線。 你無法讓次級資料庫重新上線，因為 Azure SQL 不會完整備份次級資料庫。 先丟掉次要資料庫，然後重新建立地理複製連結或故障轉移群組。

客戶自控 TDE 的 Azure 原則

在 Azure SQL 資料庫伺服器或 Azure SQL 受控執行個體的建立或更新期間，Azure 原則可以用來強制執行客戶自控 TDE。 使用此原則後，如果未設定客戶自控金鑰，則在 Azure 或受控執行個體中建立或更新 邏輯伺服器 的任何嘗試都會失敗。 此 Azure 原則可套用到整個 Azure 訂閱，或只在資源群組內套用。

如需 Azure 原則的詳細資訊，請參閱 什麼是 Azure 原則 和 Azure 原則定義結構。

在 Azure 原則中，支援客戶管理的 TDE 的兩個內建原則如下：

  • SQL 伺服器應使用由客戶管理的金鑰來加密靜態資料
  • 受控執行個體應使用客戶自控金鑰來加密待用資料

前往 Azure 入口網站並搜尋原則服務，即可管理客戶自控 TDE 原則。 在 [定義] 下，搜尋客戶自控金鑰。

這些原則有三種效果：

  • 稽核 - 預設設定，而且只會擷取 Azure 原則 活動記錄中的稽核報告

  • 拒絕：阻止在未配置客戶自控金鑰的情況下建立或更新邏輯伺服器或受控執行個體

  • 已停用 - 停用原則，且不會限制使用者在未啟用客戶管理 TDE 的情況下建立或更新邏輯伺服器或受控執行個體

如果客戶管理 TDE 的 Azure 原則設定為 [ 拒絕]，則 Azure SQL 邏輯伺服器或受控執行個體建立會失敗。 此失敗的詳細資料會記錄在資源群組的 「活動記錄 檔」中。

重要

包含影響AuditIfNotExists 的客戶管理 TDE 的舊版內建政策已被棄用。 使用已取代原則的現有原則指派不會受到影響，並繼續像以前一樣運作。

相關內容

  • Last updated on