共用方式為

搭配使用 Azure SQL 透明資料加密與客戶自控金鑰

  • 發行項

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

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

在本案例中，用來加密資料庫加密金鑰 (DEK) 的金鑰 (稱為 TDE 保護裝置) 是客戶所管理非對稱金鑰，其儲存在客戶擁有及客戶管理的雲端式外部金鑰管理系統 Azure Key Vault (AKV) 中。 Key Vault 是可調整且安全的高度可用儲存體，其適用於 RSA 密碼編譯金鑰，並可選擇由 FIPS 140-2 層級 2 驗證的硬體安全性模組 (HSM) 加以支援。 其不允許直接存取儲存的金鑰，但會使用授權實體的金鑰來提供加密和解密服務。 金鑰可以由金鑰保存庫產生、匯入或從內部部署 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 加密。
  • 若要為 Azure SQL 客戶提供兩層的待用資料加密，請使用 AES-256 加密演算法) 的基礎結構加密 (推出平台管理的金鑰。這會提供另一層待用加密，以及使用客戶自控金鑰 (已提供) 進行的 TDE。 針對 Azure SQL 資料庫和 Azure SQL 受控執行個體，在開啟基礎結構加密時，所有資料庫 (包括 master 資料庫和其他系統資料庫) 都會加密。 目前，客戶必須要求存取這項功能。 如果您對這項功能有興趣，請聯絡 AzureSQLDoubleEncryptionAtRest@service.microsoft.com。

注意

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

客戶所管理 TDE 的優點

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

  • 對 TDE 保護裝置使用方式和管理的完整精細控制；

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

  • 可在組織內對金鑰和資料的管理實作職責區分；

  • Key Vault 系統管理員能撤銷金鑰的存取權，以防止對加密資料庫的存取；

  • 在 AKV 中集中管理金鑰；

  • 可更加受到終端客戶信任，因為 AKV 設計為 Microsoft 無法看到也無法解壓縮加密金鑰；

重要

對於正在使用服務管理 TDE，而想要開始使用客戶所管理 TDE 的人員，資料會在切換的過程中保持加密，既不會有停機時間，資料庫檔案也不會重新加密。 從服務管理金鑰切換至客戶管理金鑰金鑰時，只需要重新加密 DEK 即可，而這是快速的線上作業。

客戶所管理 TDE 的運作方式

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

為了讓 Azure 邏輯伺服器使用儲存於 AKV 的 TDE 保護裝置加密 DEK，金鑰保存庫系統管理員必須使用其唯一的 Microsoft Entra 身分識別授予伺服器存取權。 有兩種存取模型可授與伺服器金鑰保存庫的存取權：

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

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

    • get - 用於在金鑰保存庫中擷取金鑰的公開部分和屬性
    • wrapKey - 能夠保護 (加密) DEK
    • unwrapKey - 能夠取消保護 (解密) DEK

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

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

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

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

如果有啟用記錄，則稽核員即可使用 Azure 監視器來檢閱金鑰保存庫稽核事件記錄檔。

注意

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

設定客戶自控 TDE 的需求

設定 AKV 的需求

啟用 AKV 的虛刪除和清除保護

重要

在新的或現有的伺服器或受控執行個體上設定客戶自控 TDE 時，必須在金鑰保存庫上啟用虛刪除和清除保護。

虛刪除和清除保護是 Azure Key Vault 的重要功能，可讓您復原已刪除的保存庫和已刪除的金鑰保存庫物件，藉以降低使用者不小心或惡意刪除金鑰或金鑰保存庫的風險。

  • 虛刪除的資源將會保留 90 天，除非客戶復原或清除這些資源。 復原和清除動作本身的權限已在金鑰保存庫的存取原則中建立關聯。 新的金鑰保存庫預設會開啟虛刪除功能，也可以使用 Azure 入口網站、PowerShell 或 Azure CLI 來啟用。

  • 您可以使用 Azure CLI 或 PowerShell 來開啟清除保護。 啟用清除保護時，必須等到保留期間過後，才能清除處於已刪除狀態的保存庫或物件。 預設保留期間為 90 天，但可透過 Azure 入口網站設定為 7 到 90 天。

  • 在內有加密金鑰 (做為伺服器或受控執行個體的 TDE 保護裝置) 的金鑰保存庫上，Azure SQL 會要求啟用虛刪除和清除保護。 這有助於避免意外或惡意將金鑰保存庫或金鑰刪除的情形，這種狀況會導致資料庫進入無法存取的狀態。

  • 在現有的伺服器或在伺服器建立期間設定 TDE 保護裝置時，Azure SQL 會驗證所使用的金鑰保存庫是否已開啟虛刪除和清除保護。 如果未在金鑰保存庫上啟用虛刪除和清除保護，TDE 保護裝置安裝作業會失敗並發生錯誤。 在此情況下，必須先在金鑰保存庫上啟用虛刪除和清除保護，然後才能執行 TDE 保護裝置的設定。

設定 TDE 保護裝置的需求

  • TDE 保護裝置只能是非對稱金鑰、RSA 或 RSA HSM 金鑰。 支援的金鑰長度為 2048 位元和 3,072 位元。

  • 金鑰啟用日期 (若已設定) 必須是過去的日期和時間。 到期日 (若已設定) 必須是未來的日期和時間。

  • 金鑰必須處於「已啟用」狀態。

  • 如果您要將現有金鑰匯入金鑰保存庫，請務必提供支援的檔案格式 (.pfx、.byok 或 .backup)。

注意

Azure SQL 和 Azure VM 上的 SQL Server 支援使用儲存在受控 HSM 中的 RSA 金鑰作為 TDE 保護裝置。 Azure Key Vault 受控 HSM 是一種完全受控、高可用性、單一租用戶且符合標準的雲端服務，可讓您使用 FIPS 140-2 層級 3 驗證過的 HSM 來保護雲端應用程式的密碼編譯金鑰。 透過使用 Azure Key Vault 設定 SQL Server TDE 可延伸金鑰管理一文，瞭解更多關於受控 HSM 和 SQL Server 所需的設定或 RBAC 權限。

v2.8.0 以前的 Thales CipherTrust Manager 版本發生問題，導致無法在客戶自控 TDE 的情況下，將剛匯入 Azure Key Vault 的金鑰與 Azure SQL 資料庫或 Azure SQL 受控執行個體搭配使用。 您可以在這裡找到更多有關此問題的詳細資料。 針對這類案例，請在將金鑰匯入金鑰保存庫之後等候 24 小時，再開始使用該金鑰作為伺服器或受控執行個體的 TDE 保護裝置。 此問題已在 Thales CipherTrust Manager v2.8.0 中獲得解決。

設定客戶自控 TDE 時的建議

設定 AKV 時的建議

  • 在單一訂用帳戶中，最多可將 500 個一般用途資料庫或 200 個業務關鍵資料庫與金鑰保存庫建立關聯，以確保在伺服器存取金鑰保存庫中的 TDE 保護裝置時具有高可用性。 這些數字是以經驗為基礎，且記載於金鑰保存庫服務限制中。 目的是要避免伺服器容錯移轉後發生問題，因為其會因該伺服器上有多少資料庫，而觸發多少金鑰作業。

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

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

  • 將每部伺服器與位於不同區域並持有相同金鑰內容的兩個金鑰保存庫連結在一起，以確保加密資料庫的高可用性。 將其中一個金鑰保存庫的金鑰標示為 TDE 保護裝置。 如果中斷情況影響到第一個區域中的金鑰保存庫，系統會自動切換到第二個區域之中有相同金鑰內容的金鑰保存庫。

注意

為了讓您在設定客戶自控 TDE 時有更大的彈性，在一個區域中的 Azure SQL 資料庫和 Azure SQL 受控執行個體現在可以連結到其他任何區域中的金鑰保存庫。 伺服器和金鑰保存庫不需要共置於相同的區域中。

設定 TDE 保護裝置時的建議

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

  • 如果金鑰在金鑰保存庫中產生，請在第一次使用 AKV 中的金鑰前，先建立金鑰備份。 備份只能還原至 Azure Key Vault。 深入了解 Backup-AzKeyVaultKey 命令。

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

  • 在輪替金鑰時將舊版保留在金鑰保存庫中，以便在還原較舊的資料庫備份時使用。 資料庫的 TDE 保護裝置有所變更時，資料庫的舊備份不會更新為使用最新 TDE 保護裝置。 在還原時，每個備份都必須使用在建立時加密的 TDE 保護裝置。 您可以依照使用 PowerShell 輪替透明資料加密保護裝置中的指示，來執行金鑰輪替。

  • 即使切換到服務管理的金鑰之後，也要將所有先前使用的金鑰保留在 AKV 中。 這可確保能夠使用儲存在 AKV 中的 TDE 保護裝置來還原資料庫備份。 在使用服務管理金鑰建立所有剩餘的已儲存備份之前，必須妥善維護以 Azure Key Vault 建立的 TDE 保護裝置。 使用 Backup-AzKeyVaultKey 建立這些金鑰的可復原備份複本。

  • 若要在安全性事件發生時移除可能遭破壞的金鑰，且不致產生資料遺失風險，請遵循移除可能遭破壞的金鑰中步驟來操作。

TDE 保護裝置輪替

輪替伺服器的 TDE 保護裝置，即表示切換至可保護伺服器上資料庫的新非對稱式金鑰。 金鑰輪替是一項線上作業，完成應只需幾秒。 此作業只會解密和重新加密資料庫加密金鑰，而不是整個資料庫。

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

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

使用 Azure Key Vault 中的自動金鑰輪替時，此功能可以在 Azure SQL 資料庫和 Azure SQL 受控執行個體的 TDE 保護裝置上進行端對端零接觸輪替。

注意

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

設定 TDE 保護裝置自動輪替時的異地複寫考量

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

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

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

  • 針對現有的異地複寫設定，在主要伺服器上啟用自動金鑰輪替之前，請將要在主要伺服器上作為 TDE 保護裝置使用的加密金鑰新增至次要伺服器。 次要伺服器需要存取的金鑰位於主要伺服器使用的同一個金鑰保存庫中 (而不是具有相同金鑰資料的另一個金鑰)。 或者，在啟用自動金鑰之前，請確定次要伺服器的受控識別 (使用者指派或系統指派) 具有主要伺服器金鑰保存庫的必要權限，而且系統會嘗試將金鑰新增至次要伺服器。

  • 系統支援將客戶自動金鑰 (CMK) 用於 TDE 的異地複寫案例。 如果您要在 Azure 入口網站中設定 TDE，則必須在所有伺服器上設定使用自動金鑰輪替的 TDE。 深入了解如何在 TDE 的異地複寫設定中設定自動金鑰輪替，請參閱異地複寫設定的自動金鑰輪替。

無法存取的 TDE 保護裝置

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

注意

如果因為間歇網路中斷而無法存取資料庫，則不需要採取任何動作資料庫會自動重新上線。

還原金鑰的存取權之後，讓資料庫重新上線需要額外的時間和步驟，這可能會因無法存取金鑰的經過時間，以及資料庫的資料大小而有所不同：

注意

  • 如果在 30 分鐘內還原金鑰存取，則資料庫會下一個小時內自動修復。
  • 如果在超過 30 分鐘後還原金鑰存取，則無法自動修復資料庫。 復原資料庫需要在 Azure 入口網站上執行額外的步驟，並且視資料庫大小而定，可能需要大量時間。
  • 資料庫重新上線後，先前設定的伺服器層級設定可能包含容錯移轉群組設定、標籤和資料庫層級設定，例如彈性集區設定、讀取縮放、自動暫停、時間點還原歷程記錄、長期保留原則等，將會遺失。 因此，建議客戶實作通知系統，以在 30 分鐘內識別加密金鑰存取的遺失。 一旦 30 分鐘的時間範圍過期，建議您驗證復原資料庫上的所有伺服器和資料庫層級設定。

以下說明在入口網站上將無法存取的資料庫重新上線所需的額外步驟。

TDE BYOK 無法存取的資料庫。

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

這種情況可能會因具有足夠權限可存取金鑰保存庫的人員，透過執行以下項目，不小心停用了伺服器存取金鑰的權限：

  • 從伺服器撤銷金鑰保存庫的 get、wrapKey、unwrapKey 權限

  • 刪除金鑰

  • 刪除金鑰保存庫

  • 變更金鑰保存庫的防火牆規則

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

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

封鎖 SQL 受控執行個體和 Key Vault 之間的連線

在 SQL 受控執行個體，嘗試在 Azure Key Vault 存取 TDE 保護裝置時發生網路錯誤，可能不會造成資料庫將其狀態變更為無法存取，但之後會呈現該執行個體離線。 此情況主要是發生在金鑰保存庫資源存在，但無法從受控執行個體連線到其端點時。 可以連線到金鑰保存庫端點但連線遭到拒絕、遺失權限等的所有情節，都會導致資料庫將其狀態變更為無法存取。

無法與 Key Vault 建立網路連線的常見原因如下：

  • Key Vault 是透過私人端點公開，且與受控執行個體子網路相關聯的網路安全性群組 (NSG) 輸出規則不允許 AKV 服務的私人 IP 位址。
  • 不正確的 DNS 解析，例如金鑰保存庫 FQDN 未解析或解析為不正確的 IP 位址時。

測試連線：從 SQL 受控執行個體到裝載 TDE 保護裝置的 Key Vault 連線。

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

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

  • 檢查已解析的 IP 位址，確認是有效位址。 遺漏值表示發生 DNS 解析問題。
    • 確認受控執行個體上的網路安全性群組具有輸出規則，其中涵蓋連接埠 443 上已解析的 IP 位址，特別是在解析的位址屬於金鑰保存庫的私人端點時。
    • 檢查路由表、虛擬裝置及其設定等其他網路設定。

監視客戶自控 TDE

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

  • Azure 資源健康狀態。 無法存取且已失去 TDE 保護裝置存取權的資料庫，會在首次連線至該資料庫遭拒後顯示為「無法存取」。
  • 活動記錄當無法存取客戶管理金鑰保存庫中的 TDE 保護裝置時，系統會將這些項目新增至活動記錄中。 建立這些事件的警示，可讓您儘快恢復存取。
  • 動作群組可定義為根據偏好來傳送通知和警示，例如電子郵件/簡訊/推播/語音、邏輯應用程式、Webhook、ITSM 或自動化 Runbook。

使用客戶管理 TDE 進行資料庫備份和還原

使用 Key Vault 中的金鑰以 TDE 加密資料庫後，新產生的任何備份也會使用相同 TDE 保護裝置進行加密。 TDE 保護裝置有所變更時，資料庫的舊備份不會更新為使用最新 TDE 保護裝置。

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

重要

在任何時候，伺服器都不能設定超過一個 TDE 保護裝置。 這是在 Azure 入口網站窗格中，標記為「將金鑰設為預設 TDE 保護裝置」的金鑰。 不過，您可將多個額外的金鑰連結到伺服器，而不需要將其標記為 TDE 保護裝置。 這些金鑰不會用來保護 DEK，但如果備份檔案是以具有對應指紋的金鑰進行加密，則可在從備份還原期間使用。

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

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

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

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

客戶管理 TDE 的高可用性

透過 AKV 提供多層備援，使用客戶管理的金鑰的 TDE 可以利用 AKV 可用性和復原能力，並完全依賴 AKV 備援解決方案。

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

AKV 提供下列可用性和復原元件，這些元件會在不需使用者介入的情況下自動提供：

注意

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

Geo-DR 和客戶管理 TDE

在作用中異地複寫和容錯移轉群組案例中，可將相關的主要和次要伺服器連結到任何區域中的相同金鑰保存庫或個別的金鑰保存庫。 如果個別的金鑰保存庫連結到主要和次要伺服器，客戶須負責將金鑰保存庫中的金鑰內容保持一致，以便讓異地次要金鑰保存庫保持同步，且如果主要金鑰保存庫因為區域中斷而無法存取並觸發了容錯移轉，即可從其本機金鑰保存庫使用相同的金鑰。 最多可設定四個次要金鑰保存庫，且不支援鏈結 (次要的次要)。

為了避免因為金鑰內容不完整而在異地複寫期間發生問題，請務必在設定客戶管理 TDE 時遵循下列規則 (如果主要和次要伺服器使用個別的金鑰保存庫)：

  • 所有相關的金鑰保存庫都必須具有相同屬性，並對個別的伺服器具有相同存取權限。

  • 所有相關的金鑰保存庫都必須包含相同金鑰內容。 這不僅適用於目前的 TDE 保護裝置，也適用於可能用於備份檔案之所有先前的 TDE 保護裝置。

  • TDE 保護裝置的初始設定和輪替必須先在次要金鑰保存庫上完成，然後才在主要金鑰保存庫上進行。

此圖表顯示容錯移轉群組和異地災害復原。

若要測試容錯移轉，請遵循作用中異地複寫概觀中的步驟。 應定期測試容錯移轉，藉以驗證 SQL Database 持續保有對兩個金鑰保存庫的存取權限。

現在，同一個區域中的 Azure SQL 資料庫伺服器和 SQL 受控執行個體可以連結至任何其他區域中的金鑰保存庫。 伺服器和金鑰保存庫不需要共置於相同的區域。 如此一來，為了簡單起見，主要和次要伺服器可連線至任何區域中的相同金鑰保存庫。 這有助於在兩個伺服器使用個別的金鑰保存庫時，避免金鑰產製原料出現不同步的情況。 Azure Key Vault 設有多層備援，以確保您的金鑰和金鑰保存庫在服務或區域失敗時仍可供使用。 Azure 金鑰保存庫的可用性與備援

客戶自控 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 邏輯伺服器或受控執行個體。 此失敗的詳細資料會記錄在資源群組的活動記錄中。

重要

客戶自控 TDE 的舊版內建原則 (包含 AuditIfNotExist 效果) 已遭取代。 即使現有原則指派所使用的原則已遭取代，現有原則也不會受影響，且會繼續正常運作。

相關內容