訓練
認證
Microsoft Certified: Azure Database Administrator Associate - Certifications
使用 Microsoft PaaS 關聯式資料庫供應項目管理用於雲端、內部部署和混合關聯式資料庫的 SQL Server 資料庫基礎結構。
適用於: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) 資料庫層級的客戶自控金鑰。
注意
master
資料庫和其他系統資料庫) 都會加密。 目前,客戶必須要求存取這項功能。 如果您對這項功能感興趣,請連絡 AzureSQLDoubleEncryptionAtRest@service.microsoft.com。注意
Microsoft Entra ID 先前稱為 Azure Active Directory (Azure AD)。
注意
在本文中,客戶管理密鑰(CMK)和「攜帶您自己的密鑰」一詞會交替使用,但代表一些差異。
客戶所管理 TDE 可為客戶提供下列優點:
對 TDE 保護裝置使用方式和管理的完整精細控制;
TDE 保護裝置使用方式的透明度;
可在組織內對金鑰和資料的管理實作職責區分;
Key Vault 系統管理員能撤銷金鑰的存取權,以防止對加密資料庫的存取;
在 AKV 中集中管理金鑰;
可更加受到終端客戶信任,因為 AKV 設計為 Microsoft 無法看到也無法解壓縮加密金鑰;
重要
對於使用由服務提供者管理的 TDE 而想轉為客戶自控 TDE 的使用者,在轉換過程中,資料仍然保持加密狀態,不會出現停機情況,也不需要重新加密資料庫檔案。 從服務管理金鑰切換至客戶管理金鑰金鑰時,只需要重新加密 DEK 即可,而這是快速的線上作業。
為了讓 Azure 邏輯伺服器使用儲存於 AKV 的 TDE 保護裝置加密 DEK,金鑰保存庫系統管理員必須使用其唯一的 Microsoft Entra 身分識別授予伺服器存取權。 有兩種存取模型可授與伺服器金鑰保存庫的存取權:
Azure 角色型存取控制 (RBAC) - 使用 Azure RBAC 授予使用者、群組或應用程式金鑰保存庫的存取權。 建議使用此方法,因為它兼具彈性和細微性。 伺服器身分識別需要金鑰保存庫加密服務加密使用者角色,才能使用金鑰進行加密和解密作業。
保存庫存取原則 - 使用金鑰保存庫存取原則,將金鑰保存庫的存取權授與伺服器。 此方法較簡單直接,但較不具彈性。 伺服器身分識別必須在金鑰保存庫具有下列權限:
在金鑰保存庫 [存取設定] 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 保護裝置的存取權限,而此時間範圍內的使用者可能仍有存取權限。
使用其 Microsoft Entra 身分識別,將金鑰保存庫的存取權授與伺服器或受控執行個體 (get、wrapKey、unwrapKey)。 伺服器身分識別可以是系統指派的受控識別,或指派給伺服器的使用者指派受控識別。 使用 Azure 入口網站時,會在建立伺服器時自動建立 Microsoft Entra 身分識別。 使用 PowerShell 或 Azure CLI 時,則必須明確建立 Microsoft Entra 身分識別且應加以驗證。 關於使用 PowerShell 時的詳細逐步指示,請參閱使用 BYOK 設定 TDE 和使用 SQL 受控執行個體的 BYOK 設定 TDE。
搭配 AKV 使用防火牆時,除非您使用 AKV 的私人端點,否則您必須啟用 [允許受信任的 Microsoft 服務 略過防火牆] 選項。 如需詳細資訊,請參閱設定 Azure Key Vault 防火牆和虛擬網路。
重要
在新的或現有的伺服器或受控執行個體上設定客戶自控 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 保護裝置只能是非對稱金鑰、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 中獲得解決。
在單一訂用帳戶中,最多可將 500 個一般用途資料庫或 200 個業務關鍵資料庫與金鑰保存庫建立關聯,以確保在伺服器存取金鑰保存庫中的 TDE 保護裝置時具有高可用性。 這些數字是以經驗為基礎,且記載於金鑰保存庫服務限制中。 目的是要避免伺服器容錯移轉後發生問題,因為其會因該伺服器上有多少資料庫,而觸發多少金鑰作業。
在金鑰保存庫上設定資源鎖定,藉此控制可刪除這項重要資源的人員,並防止意外或未經授權的刪除發生。 深入了解資源鎖定。
啟用所有加密金鑰的稽核和報告功能:Key Vault 提供可輕易在其他安全性資訊和事件管理工具中插入的記錄。 例如,Operations Management Suite Log Analytics 即是已整合的服務之一。
使用 Azure 區域中的金鑰保存庫,可將內容復寫至配對區域,以取得最大可用性。 如需詳細資訊,請參閱 使用 Azure Key Vault 和 Azure Key Vault 可用性和備援的最佳作法。
注意
為了讓您在設定客戶自控 TDE 時有更大的彈性,在一個區域中的 Azure SQL 資料庫和 Azure SQL 受控執行個體現在可以連結到其他任何區域中的金鑰保存庫。 伺服器和金鑰保存庫不需要共置於相同的區域。
將 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 保護裝置將會在 24 小時內自動輪替至最新的金鑰版本。
使用 Azure Key Vault 中的自動金鑰輪替時,此功能可以在 Azure SQL 資料庫和 Azure SQL 受控執行個體的 TDE 保護裝置上進行端對端零接觸輪替。
注意
使用手動或自動金鑰輪替設定具有 CMK 的 TDE 時,一律會使用支援的最新版本金鑰。 安裝程式不允許使用舊版或較低版本的金鑰。 一律使用最新版本金鑰符合 Azure SQL 安全性原則,該原則不允許可能遭入侵的舊版金鑰。 資料庫備份或還原可能需要舊版金鑰,特別是長期保留備份必須保留舊版金鑰。 針對異地複寫設定,來源伺服器所需的所有金鑰都需要存在於目標伺服器上。
若要避免在建立或異地複寫期間發生問題,在主要或次要伺服器上啟用 TDE 保護裝置的自動輪替時,請務必在設定異地複寫時遵循下列規則:
主要和次要伺服器都必須具有主要伺服器金鑰保存庫 (含有主要伺服器 TDE 保護裝置金鑰的金鑰保存庫) 的 Get、wrapKey 和 unwrapKey 權限。
對於啟用自動金鑰輪替的伺服器,在起始異地複寫之前,將作為主要伺服器上 TDE 保護裝置使用的加密金鑰新增至次要伺服器。 次要伺服器需要存取的金鑰位於主要伺服器使用的同一個金鑰保存庫中 (而不是具有相同金鑰資料的另一個金鑰)。 或者,在起始異地複寫之前,請確定次要伺服器的受控識別 (使用者指派或系統指派) 具有主要伺服器金鑰保存庫的必要權限,而且系統會嘗試將金鑰新增至次要伺服器。
針對現有的異地複寫設定,在主要伺服器上啟用自動金鑰輪替之前,請將要在主要伺服器上作為 TDE 保護裝置使用的加密金鑰新增至次要伺服器。 次要伺服器需要存取的金鑰位於主要伺服器使用的同一個金鑰保存庫中 (而不是具有相同金鑰資料的另一個金鑰)。 或者,在啟用自動金鑰之前,請確定次要伺服器的受控識別 (使用者指派或系統指派) 具有主要伺服器金鑰保存庫的必要權限,而且系統會嘗試將金鑰新增至次要伺服器。
系統支援將客戶自動金鑰 (CMK) 用於 TDE 的異地複寫案例。 如果您要在 Azure 入口網站中設定 TDE,則必須在所有伺服器上設定使用自動金鑰輪替的 TDE。 深入了解如何在 TDE 的異地複寫設定中設定自動金鑰輪替,請參閱異地複寫設定的自動金鑰輪替。
當 TDE 設定為使用客戶自控金鑰時,資料庫需要持續存取 TDE 保護裝置才能保持線上狀態。 如果伺服器無法存取 AKV 中的客戶管理 TDE 保護裝置,則資料庫會在 10 分鐘內開始拒絕所有連線並顯示對應的錯誤訊息,並將其狀態變更為無法存取。 在處於無法存取狀態的資料庫上,唯一允許的動作是將其刪除。
注意
如果資料庫因為間歇性網路中斷而無法存取,則不需要採取任何動作,而且資料庫會自動恢復上線。 若要在嘗試存取 Azure Key Vault 中的 TDE 保護裝置時降低網路錯誤或中斷的影響,在服務嘗試將資料庫移至無法存取的狀態之前,已引進 24 小時的緩衝區。 如果在達到無法存取的狀態之前發生故障轉移,資料庫就會因為遺失加密快取而變成無法使用。
還原金鑰的存取權之後,讓資料庫重新上線需要額外的時間和步驟,這可能會因無法存取金鑰的經過時間,以及資料庫的資料大小而有所不同:
注意
以下說明在入口網站上將無法存取的資料庫重新上線所需的額外步驟。
這種情況可能會因具有足夠權限可存取金鑰保存庫的人員,透過執行以下項目,不小心停用了伺服器存取金鑰的權限:
從伺服器撤銷金鑰保存庫的 get、wrapKey、unwrapKey 權限
刪除金鑰
刪除金鑰保存庫
變更金鑰保存庫的防火牆規則
刪除 Microsoft Entra ID 中伺服器的受控識別
深入了解導致資料庫變得無法存取的常見原因。
SQL 受控實例與密鑰保存庫之間的網路連線封鎖大部分發生在密鑰保存庫資源存在,但無法從受控實例連線到其端點時發生。 可以連線到金鑰保存庫端點但連線遭到拒絕、遺失權限等的所有情節,都會導致資料庫將其狀態變更為無法存取。
無法與 Key Vault 建立網路連線的常見原因如下:
測試連線:從 SQL 受控執行個體到裝載 TDE 保護裝置的 Key Vault 連線。
如果測試傳回 TcpTestSucceeded: False,請檢閱網路設定:
若要監視資料庫狀態及啟用 TDE 保護裝置存取的遺失警示,請設定 Azure 的下列功能:
使用 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 也一樣需要。
透過 AKV 提供多層備援,使用客戶管理的金鑰的 TDE 可以利用 AKV 可用性和復原能力,並完全依賴 AKV 備援解決方案。
AKV 的多個備援層可確保密鑰存取,即使個別服務元件失敗或 Azure 區域或可用性區域已關閉也一樣。 如需詳細資訊,請參閱 Azure Key Vault 可用性與備援。
AKV 提供下列可用性和復原元件,這些元件會在不需使用者介入的情況下自動提供:
注意
針對所有配對區域,AKV 金鑰會複寫到這兩個區域,而且在這兩個區域中都有硬體安全性模組 (HSM),可在這些密鑰上運作。 如需詳細資訊,請參閱 數據復寫。 這適用於標準和進階 Azure 金鑰保存庫 服務層級,以及軟體或硬體密鑰。
在 主動式異地複寫 和 故障轉移群組 情境中,相關的主要伺服器和輔助伺服器都可以連結至位於任何區域的 Azure Key Vault。 伺服器和金鑰保存庫不需要共置在同一個區域中。 如此一來,為了簡單起見,主要和次要伺服器可連線至任何區域中的相同金鑰保存庫。 這有助於在兩個伺服器使用個別的金鑰保存庫時,避免金鑰產製原料出現不同步的情況。
Azure Key Vault 有多層備援,以確保在服務或區域失敗時,密鑰和密鑰保存庫仍可供使用。 非配對區域以及配對區域均支援備援。 如需詳細資訊,請參閱 Azure Key Vault 可用性與備援。
根據客戶的需求,有數個選項可用來儲存 TDE 保護裝置金鑰:
利用 Azure Key Vault 和原生配對區域高可用性或非配對區域高可用性。
在跨多個區域的不同 AKV 中,利用客戶 HSM 並在 Azure Key Vault 中載入密鑰。
利用受控 HSM 和跨區域複寫選項。
以下圖表顯示 Azure SQL 配置中使用故障轉移群組進行異地複寫的 AKV 跨故障轉移配對區域的組態(主要和次要):
Azure SQL 中的主要和輔助伺服器都會存取主要區域中的 AKV。
AKV 故障轉移是由 AKV 服務起始,而不是由客戶起始。
如果是 AKV 故障轉移至次要區域,Azure SQL 中的伺服器仍然可以存取相同的 AKV。 雖然在內部,AKV 聯機會重新導向至次要區域中的 AKV。
只有在主要複本中的 AKV 可用時,才能建立新的金鑰、匯入和密鑰輪替。
故障轉移發生之後,除非配對區域中主要區域的 AKV 能再次被存取,否則不允許進行密鑰輪替。
客戶無法手動連線到次要區域。
當主要區域的 AKV 無法使用時,AKV 會變成唯讀狀態。
客戶無法選擇或檢查 AKV 目前所在的區域。
針對非配對的區域,Azure SQL 伺服器都會存取第一個區域中的 AKV(如圖所示),而 AKV 會使用區域冗餘儲存,跨相同區域的獨立可用性區域複製區域內的資料。
如需詳細資訊,請參閱 Azure Key Vault 可用性和備援、Azure 區域配對和未配對的區域,以及 Azure Key Vault 服務等級協定。
使用 Azure SQL MI 和 Azure SQL DB 的區域備援選項來增加復原能力。 如需詳細資訊,請參閱 什麼是 Azure 可用性區域?。
使用 Azure SQL MI 和 Azure SQL DB 的故障轉移群組,將災害復原至次要區域。 如需詳細資訊,請參閱 故障轉移群組概觀 & 最佳做法。
如果 Azure SQL 中使用私人端點,設定可能需要更複雜的 DNS 區域(例如,無法在相同 DNS 區域中建立兩個私人端點至相同的資源)。
確定應用程式會利用重試邏輯。
當客戶可能想要選擇受控硬體安全模組(HSM)解決方案而不是 AKV 時,會有幾種情境:
手動連接二級儲存庫的需求。
即使發生故障,仍需對保管庫進行讀取存取。
彈性地選擇要複製其密鑰資料的區域
使用受控 HSM 可讓客戶在原始複本遺失或無法使用時,為 HSM 建立確切的複本。
針對安全性或法規需求使用受控 HSM。
選擇備份整個保管庫或備份個別金鑰。
如需詳細資訊,請參閱 啟用 Azure 受控 HSM 的多重區域復寫 及 受控 HSM 的災害復原。
在 Azure SQL 資料庫伺服器或 Azure SQL 受控執行個體的建立或更新期間,Azure 原則可以用來強制執行客戶自控 TDE。 這項原則就位後,若並未以客戶自控金鑰來設定原則,則任何建立 Azure 邏輯伺服器或受控執行個體的嘗試都會失敗。 此 Azure 原則可套用到整個 Azure 訂閱,或只在資源群組內套用。
如需 Azure 原則的詳細資訊,請參閱 什麼是 Azure 原則 和 Azure 原則定義結構。
在 Azure 原則中,客戶自控 TDE 支援下列兩個內建原則:
前往 Azure 入口網站並搜尋原則服務,即可管理客戶自控 TDE 原則。 在 [定義] 下,搜尋客戶自控金鑰。
這些原則有三種效果:
如果客戶自控 TDE 的 Azure 原則設為 [拒絕],將無法建立 Azure SQL 邏輯伺服器或受控執行個體。 此失敗的詳細資料會記錄在資源群組的活動記錄中。
重要
客戶自控 TDE 的舊版內建原則 (包含 AuditIfNotExist
效果) 已遭取代。 現有使用已被廢除原則的政策指派不會受到影響,並將繼續如以往一樣運作。
訓練
認證
Microsoft Certified: Azure Database Administrator Associate - Certifications
使用 Microsoft PaaS 關聯式資料庫供應項目管理用於雲端、內部部署和混合關聯式資料庫的 SQL Server 資料庫基礎結構。
文件
透明資料加密 - Azure SQL Database & Azure SQL Managed Instance & Azure Synapse Analytics
Azure SQL Database、Azure SQL 受控執行個體和 Azure Synapse Analytics 的透明資料加密概觀。 本文件說明其優點和設定選項,其中包括服務管理的透明資料加密和「攜帶您自己的金鑰」。
資料庫層級客戶自控金鑰的透明資料加密 (TDE) - Azure SQL Database
透過 Azure Key Vault 針對 Azure SQL Database 在資料庫層級細微性下,支援透明資料加密 (TDE) 的客戶自控金鑰 (CMK) 概觀。
了解如何使用 PowerShell 和 Azure CLI,針對 Azure 中 Azure SQL Database、Azure SQL 受控執行個體和 Azure Synapse Analytics 所使用的伺服器來輪替透明資料加密 (TDE) 保護裝置。