適用於：
Azure SQL 資料庫Azure SQL 受控執行個體Azure Synapse Analytics (僅限專用的 SQL 集區)
搭配使用 Azure SQL 中的透明資料加密 (TDE) 與客戶自控金鑰 (CMK)，可讓攜帶您自己的金鑰 (BYOK) 案例進行待用資料保護，並可讓組織區分對金鑰和資料的管理實作職責。 使用客戶自控 TDE，客戶將負責完全控制金鑰生命週期管理 (金鑰的建立、上傳、輪替、刪除)、金鑰使用權限及對金鑰作業進行稽核。
在此案例中，透明數據加密 （TDE） 保護裝置是客戶管理的非對稱密鑰，用來保護資料庫加密密鑰 （DEK） — 會儲存在 Azure Key Vault或 Azure Key Vault 受控 HSM 中。 這些是專為高可用性和延展性而設計的安全雲端式密鑰管理服務。 Azure Key Vault 支援 RSA 金鑰，而且可由 FIPS 140-2 層級 2 驗證的 HSM 支援。 對於需要更高保證的客戶，Azure Key Vault 受控 HSM 提供 FIPS 140-2 層級 3 驗證的硬體。 金鑰可以在服務中產生、匯入或 安全地從內部部署 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（透明資料加密）的權限
選取您想要使用的 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 保護裝置只能是非對稱金鑰、RSA 或 RSA HSM 金鑰。 支援的金鑰長度為 2,048 位和 3,072 位。
金鑰啟用日期 (若已設定) 必須是過去的日期和時間。 到期日 (若已設定) 必須是未來的日期和時間。
金鑰必須處於「已啟用」狀態。
如果您要將現有的金鑰匯入金鑰保存庫，請確定它以其中一種支援的檔案格式提供：
.pfx、.byok或.backup。 若要將受 HSM 保護的金鑰匯入 Azure 受控 HSM，請參閱 將受 HSM 保護的金鑰匯入受控 HSM （BYOK） 。
注意
在 v2.8.0 版之前的 Thales CipherTrust Manager 存在一個問題，導致新匯入到 Azure 金鑰保存庫的金鑰無法用於 Azure SQL Database 或 Azure SQL Managed Instance 中的客戶管理 TDE (透明資料加密) 情境。 您可以在這裡找到更多有關此問題的詳細資料。 在這種情況下，將密鑰匯入 Azure Key Vault 之後，請等候 24 小時，以開始使用它作為伺服器或受控實例的 TDE 保護裝置。 此問題已在 Thales CipherTrust Manager v2.8.0 中解決。
設定客戶自控 TDE 時的建議
為了確保最佳效能和可靠性，強烈建議使用適用於 Azure SQL 的 專用 Azure 金鑰保存庫 。 此金鑰保存庫不應該與其他服務共用。 如果金鑰保存庫負載過重，因為共用使用量或過多的金鑰作業，可能會對資料庫效能造成負面影響，尤其是在加密金鑰存取期間。 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 金鑰保存庫產生關聯。 隨著資料庫的成長，頁面伺服器的數目會自動增加，因此定期監視資料庫大小非常重要。 如果頁面伺服器數目超過 500，請針對每個未與其他 Azure SQL 資源共用的超大規模資料庫使用專用的 Azure 金鑰保存庫。
監視 和設定 Azure 金鑰保存庫 警示。 如需監視和警示的詳細資訊，請參閱 監視 Azure 金鑰保存庫 和 設定 Azure 金鑰保存庫警示。
在金鑰保存庫上設定資源鎖定，藉此控制可刪除這項重要資源的人員，並防止意外或未經授權的刪除發生。 深入了解資源鎖定。
啟用所有加密金鑰的稽核和報告：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 保護裝置輪替
輪替伺服器的 TDE 保護裝置，即表示切換至可保護伺服器上資料庫的新非對稱式金鑰。 金鑰輪替是一項線上作業，完成應只需幾秒。 此作業只會解密和重新加密資料庫加密金鑰，而不是整個資料庫。
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 保護裝置存取權撤銷
如果某人擁有密鑰保存庫的足夠訪問許可權，或受控 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 上啟用多重區域複寫。
Geo-DR 和客戶管理 TDE
在兩種情境中，即主動性地理複寫和故障轉移群組的情境下，所涉及的主伺服器和次伺服器可以連結到位於任何區域的 Azure Key Vault 或 Azure 受控 HSM。 伺服器和金鑰保存庫或受控 HSM 不必共置在同一個區域中。 為了簡單起見，主要和輔助伺服器可以連線到相同的金鑰保存庫或受控 HSM（可在任何區域）。 如果兩部伺服器都使用個別的密鑰保存庫或受控 HSM，這有助於避免密鑰數據可能不同步的情況。
Azure Key Vault 和 Azure 受控 HSM 有多層備援，以確保在服務或區域失敗時，密鑰和密鑰保存庫仍可供使用。 備援機制由非配對區域及配對區域提供支援。 如需詳細資訊，請參閱 Azure Key Vault 可用性與備援。
根據客戶的需求，有數個選項可用來儲存 TDE 保護裝置金鑰：
使用 Azure 金鑰保存庫的原生配對區域容錯能力或非配對區域容錯能力。
使用客戶的 HSM，並在多個區域的個別 Azure 金鑰保存庫中載入金鑰。
使用 Azure 受控 HSM 和跨區域複寫選項。
- 此選項可讓客戶選取複製金鑰的所需區域。
下圖顯示 Azure Key Vault 與 Azure SQL 設置在使用故障轉移群組的異地複寫中，跨故障轉移的配對區域（主要區域和次要區域）組態：
適用於 Geo-DR 的 Azure Key Vault 備註
Azure SQL 中的主要和次要伺服器都會存取主要區域中的 Azure Key Vault。
Azure Key Vault 故障轉移是由 Azure Key Vault 服務起始，而不是由客戶起始。
如果 Azure 金鑰保存庫容錯移轉至次要區域，Azure SQL 中的伺服器仍可存取相同的 Azure 金鑰保存庫。 雖然在內部，Azure Key Vault 的連線被重新導向至次要區域中的 Azure Key Vault。
只有當主要複本中的 Azure Key Vault 可用時，才能進行新的密鑰創建、匯入和密鑰輪替。
故障轉移發生之後，除非可再次存取配對區域主要區域中的 Azure Key Vault，否則不允許密鑰輪替。
客戶無法手動連線到次要區域。
當主要區域中的 Azure Key Vault 無法使用時，Azure Key Vault 處於只讀狀態
客戶無法選擇或檢查 Azure Key Vault 目前所在的區域。
針對非配對區域，所有 Azure SQL 伺服器都會存取第一個區域中的 Azure Key Vault（如圖所示），而 Azure Key Vault 會使用區域冗餘存儲，跨同一區域的獨立可用性區域內複寫數據。
如需詳細資訊，請參閱 Azure Key Vault 可用性和備援、Azure 區域配對和未配對的區域，以及 Azure Key Vault 服務等級協定。
適用於 Geo-DR 的 Azure SQL 備註
使用 Azure SQL 受控執行個體和 Azure SQL 資料庫的區域備援選項來增加復原能力。 如需詳細資訊，請參閱 什麼是 Azure 可用性區域？。
使用 Azure SQL 受控執行個體和 Azure SQL 資料庫的容錯移轉群組，將災害復原至次要區域。 如需詳細資訊，請參閱 故障轉移群組概觀 & 最佳做法。
當資料庫是作用中異地復寫或故障轉移群組的一部分且 無法存取時，SQL 控制平面會中斷連結，並將資料庫轉換成獨立資料庫。 修正密鑰限之後，主資料庫通常可以重新上線。 次要資料庫無法重新上線，因為 Azure SQL 在設計上不會針對次要資料庫進行完整備份。 建議卸除輔助資料庫，然後重新建立連結。
如果 Azure SQL 中使用私人端點，設定可能需要更複雜的 DNS 區域（例如，無法在相同 DNS 區域中建立兩個私人端點至相同的資源）。
請確定應用程式使用重試邏輯。
客戶在某些情況下可能會選擇 Azure 受控 HSM 解決方案而不是 Azure Key Vault：
手動連接二級儲存庫的需求。
即使發生故障，仍需對保管庫進行讀取存取。
彈性地選擇要複製其密鑰資料的區域
- 需要啟用跨區域複寫，這會在第二個區域中建立第二個 Azure 受控 HSM 集區。
使用 Azure 受控 HSM 可讓客戶在原始複本遺失或無法使用時，為 HSM 建立確切的複本。
針對安全性或法規需求使用 Azure 受控 HSM。
選擇備份整個保管庫或備份個別金鑰。
如需詳細資訊，請參閱 啟用 Azure 受控 HSM 的多重區域復寫 及 受控 HSM 的災害復原。
客戶自控 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 的舊版內建政策已被棄用。 使用已取代原則的現有原則指派不會受到影響，並繼續像以前一樣運作。