資料庫層級下客戶自控金鑰的透明資料加密 (TDE)

適用於：Azure SQL Database

此文章描述在 Azure SQL 資料庫的資料庫層級使用客戶自控金鑰的透明資料加密 (TDE)。

注意

資料庫層級 TDE CMK 適用於 Azure SQL 資料庫 (所有 SQL Database 版本)。 不適用於 Azure SQL 受控執行個體、SQL Server 內部部署、Azure VM 和 Azure Synapse Analytics (專用 SQL 集區 (先前稱為 SQL DW))。

注意

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

概觀

Azure SQL 為透過透明資料加密 (TDE) 提供待用加密功能給客戶。 使用客戶自控的金鑰 (CMK) 擴充 TDE 可讓待用資料保護，其中 TDE 保護裝置 (加密金鑰) 儲存在加密資料庫加密金鑰的 Azure Key Vault 中。 目前 TDE 與 CMK 設定於邏輯伺服器層級上，讓所有與該伺服器的相關聯加密資料庫繼承。 這項新功能允許將 TDE 保護裝置設定為伺服器內每個資料庫中個別客戶的自控金鑰。 具有有效、無空白 Microsoft.Sql/servers/databases 屬性的任何 encryptionProtector 資源均已設定資料庫層級客戶自控的金鑰。

在此案例中，儲存在客戶擁有和客戶自控的Azure Key Vault (AKV) 中非對稱金鑰可以個別用於伺服器中的每個資料庫，以加密資料庫加密金鑰 (DEK)，稱為 TDE 保護裝置。 您可以選擇為每個資料庫新增金鑰、移除金鑰，以及變更使用者指派的受控識別 (UMI)。 如需身分識別的詳細資訊，請參閱 Azure 中受控識別類型。

下列功能可供使用：

• 使用者指派的受控識別：您可以將單一使用者指派的受控識別指派給資料庫。 此身分識別可用來存取 Azure Key Vault 並管理加密金鑰。
• 加密金鑰管理：您可以在資料庫層級啟用一或多個要新增的加密金鑰，並將其中一個新增的金鑰設定為 TDE 保護裝置。 要新增的加密金鑰會使用已指派給資料庫的使用者指派受控識別來存取 Azure Key Vault。
• 同盟用戶端身分識別：您也可以在不同的 Microsoft Entra 租用戶中啟用來自 Azure Key Vault 的客戶自控金鑰 (CMK)，以便利用 Azure SQL 資料庫上設定的同盟用戶端身分識別，在資料庫層級上將其設定為透明資料加密保護程式。 這可讓您使用儲存在不同的租用戶 Azure Key Vault 中的金鑰來管理 TDE。

注意

資料庫層級不支援系統指派的受控識別。

資料庫層級客戶自控 TDE 的優點

對於更多的服務供應商 (也稱為獨立軟體廠商 (ISV))，請使用 Azure SQL Database 來建置其服務，許多都轉換成彈性集區，以有效率地將計算資源分散到多個資料庫。 藉由讓每個客戶的資料庫在共用彈性集區中，ISV 可以利用集區最佳化資源使用率功能，同時仍確保每個資料庫都有適當的資源。

不過，此方法有一項重大限制。 當多個資料庫裝載在相同的 Azure SQL 邏輯伺服器上時，均會共用伺服器層級 TDE 保護裝置。 ISV 無法提供真正的客戶自控金鑰 (CMK) 功能給客戶。 若無法自控加密金鑰，客戶可能會不想要將敏感性資料委派給 ISV 的服務，特別是合規性法規要求他們維持針對加密金鑰的完整控制權。

使用資料庫層級 TDE CMK，ISV 可以為其客戶提供 CMK 功能並達成安全性隔離，因為每個資料庫的 TDE 保護裝置可能由他們擁有的金鑰保存庫中個別 ISV 客戶擁有。 ISV 客戶所達成的安全性隔離，既包含金鑰和用於存取金鑰的身分識別相關細節。

下圖摘要說明上述新功能。 此圖提供兩個不同的 Microsoft Entra 租用戶。 Best Services 租用戶，其中包含具有兩個資料庫的 Azure SQL 邏輯伺服器，使用 UMI 1 的 DB 1 和 DB 2，以及 Azure Key Vault 1，並搭配 Key 1 存取資料庫 DB 1。 UMI 1 和 Key 1 代表伺服器層級設定。 根據預設，此伺服器上建立的所有資料庫都會使用 CMK 繼承 TDE 的這項設定。 Contoso 租用戶代表用戶端租用戶，包含 Azure Key Vault 2 使用 Key 2 存取跨租用戶的資料庫 DB 2作為針對此資料庫使用 Key 2 和 UMI 2 設定資料庫層級 CMK 的跨租用戶支援。

如需跨租用戶身分識別組態的詳細資訊，請參閱伺服器層級文件跨租用戶客戶自控金鑰與透明資料加密。

支援金鑰管理案例

在下一節中，假設一部伺服器包含三個資料庫 (例如 Database1、Database2 和 Database3)。

現有案例

Key1 設定為邏輯伺服器層級的客戶自控金鑰。 此伺服器下的所有資料庫都會繼承相同的金鑰。

• 伺服器 – Key1 設定為 CMK
• Database1 – Key1 用為 CMK
• Database2 – Key1 用為 CMK
• Database3 – Key1 用為 CMK

新的支援案例：使用客戶自控金鑰設定的邏輯伺服器

Key1 設定為邏輯伺服器層級的客戶自控金鑰。 您可以在資料庫層級設定不同的客戶自控金鑰 (Key2)。

• 伺服器 – Key1 設定為 CMK
• Database1 – Key2 用為 CMK
• Database2 – Key1 用為 CMK
• Database3 – Key1 用為 CMK

注意

如果邏輯伺服器已設定 TDE 的客戶自控金鑰，則此邏輯伺服器中個別資料庫無法選擇使用服務管理金鑰來進行透明資料加密。

新的支援案例：使用服務管理金鑰設定的邏輯伺服器

邏輯伺服器會針對 TDE 使用服務管理金鑰 (SMK) 進行設定。 您可以在資料庫層級設定不同的客戶自控金鑰 (Key2)。

• 伺服器 - 服務管理的金鑰設定為 TDE 保護裝置
• Database1 – Key2 設定為 CMK
• Database2 – 服務管理的金鑰設定為 TDE 保護裝置
• Database3 – 服務管理的金鑰設定為 TDE 保護裝置

還原至伺服器層級加密

使用 TDE 的資料庫層級客戶自控金鑰設定 Database1，而邏輯伺服器則是使用服務管理的金鑰進行設定。 Database1 可以還原，以使用邏輯伺服器層級服務管理的金鑰。

注意

如果邏輯伺服器針對 TDE 使用 CMK 進行設定，則以資料庫層級 CMK 設定的資料庫無法還原為伺服器層級加密。

雖然只有在使用的 TDE 是使用服務管理的金鑰設定邏輯伺服器時，才支援還原作業，但只要伺服器具有有效身分識別來源資料庫所使用的所有金鑰，就可以將設定資料庫層級 CMK 的資料庫還原到使用 CMK 的伺服器。

金鑰保存庫和受控識別需求

設定 Azure Key Vault (AKV) 金鑰和受控識別的相同需求，包括授與套用至伺服器層級客戶自控金鑰 (CMK) 功能的身分識別金鑰設定和權限也適用於資料庫層級 CMK。 如需詳細資訊，請參閱 使用 CMK 的透明資料加密 (TDE) 與 使用 CMK 的受控識別。

金鑰管理

輪替資料庫的 TDE 保護裝置，即表示切換至可保護資料庫的新非對稱式金鑰。 金鑰輪替是一項線上作業，完成應只需幾秒。 此作業只會解密和重新加密資料庫加密金鑰，而不是整個資料庫。 將有效的使用者指派受控識別指派給資料庫之後，輪替資料庫層級的金鑰是涉及更新資料庫加密保護裝置屬性的資料庫 CRUD 作業。 Set-AzSqlDatabase 和屬性 -EncryptionProtector 可用來輪替金鑰。 若要建立以資料庫層級 CMK 設定新的資料庫，New-AzSqlDatabase 可以搭配 -EncryptionProtector、-AssignIdentity 和 -UserAssignedIdentityId 參數使用。

您可以新增新的金鑰，並使用類似的要求從資料庫中移除現有的金鑰，再修改資料庫資源的金鑰屬性。 Set-AzSqlDatabase、參數 -KeyList 和 -KeysToRemove 可用於這些作業。 若要擷取加密保護裝置、身分識別和金鑰設定，可以使用 Get-AzSqlDatabase。 根據預設，Azure Resource Manager 資源 Microsoft.Sql/servers/databases 只會顯示資料庫上設定的 TDE 保護裝置和受控識別。 若要展開金鑰的完整清單，則需要其他參數如 -ExpandKeyList。 此外，-KeysFilter "current" 時間點的值 (例如 2023-01-01) 可用來擷取目前金鑰和過去在特定時間點使用的金鑰。

自動金鑰輪替

自動金鑰輪替可以在資料庫層級使用，也可搭配 Azure Key Vault 金鑰使用。 偵測到新版本的金鑰時，就會觸發輪替，而且會在 24 小時內自動輪替。 如需如何使用 Azure 入口網站或 Azure CLI 設定自動金鑰輪替的資訊，請參閱資料庫層級的自動金鑰輪替。

金鑰管理的權限

根據金鑰保存庫的權限模型 (存取原則或 Azure RBAC)，您可以藉由在金鑰保存庫上建立存取原則來授與金鑰保存庫存取權，或新建 Azure RBAC 角色指派。

存取原則權限模型

為了讓資料庫使用儲存在 AKV 中的 TDE 保護裝置來進行 DEK 加密，則金鑰保存庫系統管理員必須使用其唯一的 Microsoft Entra 身分識別來將下列存取權授與資料庫使用者指派的受控識別：

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

Azure RBAC 權限模型

為了讓資料庫使用儲存在 AKV 中的 TDE 保護裝置來進行 DEK 加密，您必須使用其唯一的 Microsoft Entra 身分識別，為資料庫使用者指派的受控識別新增具有角色金鑰保存庫密碼編譯服務加密使用者的全新 Azure RBAC 角色指派。

跨租用戶客戶自控金鑰

具有透明資料加密的跨租用戶客戶自控金鑰描述如何設定伺服器層級 CMK 的同盟用戶端識別碼。 針對資料庫層級 CMK 必須完成類似的設定，而且同盟用戶端識別碼必須新增為 Set-AzSqlDatabase 或 New-AzSqlDatabase API 要求的一部分。

注意

如果多租用戶應用程式尚未新增到具有必要權限 (Get、Wrap Key、Unwrap Key) 的金鑰保存庫存取原則中，在 Azure 入口網站中使用應用程式進行識別身分同盟，將會顯示錯誤。 在設定同盟用戶端身分識別之前，請確定已正確設定權限。

如果使用 Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert 設定邏輯伺服器使用服務管理金鑰，則設定資料庫層級 CMK 的資料庫可以還原為伺服器層級加密。

如果無法存取的 TDE 保護裝置，如使用 CMK 的透明資料加密 (TDE) 中所述，一旦更正金鑰存取，即可使用 Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation 來存取資料庫。

注意

TDE 的身分識別和金鑰管理與資料庫層級客戶自控的金鑰會詳細說明資料庫層級 CMK 的身分識別和金鑰管理作業，以及 Powershell、Azure CLI 和 REST API 範例。

其他考量

• 如果已在伺服器層級啟用具有 CMK 的 TDE，設定特定資料庫的 CMK 會覆寫伺服器層級 CMK 設定 (系統會以資料庫層級 TDE 保護裝置重新加密資料庫的 DEK)。
• 任何邏輯伺服器層級金鑰變更或輪替不會影響資料庫層級 CMK 設定，而且資料庫會繼續使用自己的 CMK 設定。
• 再 Transact-SQL (T-SQL) 中部支援資料庫層級 CMK。
• 邏輯伺服器使用者指派的受控識別 (UMI) 可用於資料庫層級。 不過，建議針對資料庫層級 CMK 使用指定的 UMI。
• 伺服器層級跨租用戶 CMK 設定不會影響使用資料庫層級 CMK 設定的個別資料庫，而且會繼續使用自己的單一租用戶或跨租用戶設定。
• 資料庫層級只能設定單一使用者指派的受控識別。

注意

如果重新命名資料庫，則必須重新指定資料庫上的受控識別。

將現有資料庫移轉至資料庫層級 CMK

新的資料庫可以在建立期間使用資料庫層級 CMK 進行設定，而使用服務管理金鑰所設定伺服器中現有資料庫可以使用使用資料庫層級客戶自控金鑰的 TDE 身分識別和金鑰管理理中所述的作業，移轉至資料庫層級 CMK。 若要移轉使用伺服器層級 CMK 或異地複寫所設定的資料庫需要其他步驟，如下列各節所述。

使用伺服器層級 CMK 設定的資料庫，而不需異地複寫

1. 使用 sys.dm_db_log_info (Transact-SQL) - SQL Server 針對您的資料庫，並尋找作用中虛擬記錄檔 (VLF)。
2. 針對所有作用中的 VLF，記錄 sys.dm_db_log_info 結果的 vlf_encryptor_thumbprint。
3. 使用 sys.dm_database_encryption_keys (Transact-SQL) - SQL Server 檢視，讓資料庫檢查 encryptor_thumbprint。 記錄 encryptor_thumbprint。
4. 使用 Get-AzSqlServerKeyVaultKey Cmdlet 來取得邏輯伺服器上設定的所有伺服器層級金鑰。 從結果中挑選與上述結果具有相同指紋的指紋的項目。
5. 對您要移轉的資料庫進行更新資料庫 API 呼叫，以及身分識別和加密保護裝置。 使用 Set-AzSqlDatabase 使用 -UserAssignedIdentityId、-AssignIdentity、-KeyList、-EncryptionProtector (如有需要則 -FederatedClientId) 參數，傳遞上述金鑰作為資料庫層級金鑰。

重要

更新資料庫要求中使用的身分識別必須能夠存取作為輸入傳遞的所有金鑰。

設定具有異地複寫的伺服器層級 CMK 的資料庫

1. 依照上一節中所述的步驟 (1) 至 (4) 擷取移轉所需的金鑰清單。
2. 使用 Set-AzSqlDatabase 和 -KeyList 參數，對您要移轉的主要和次要資料庫更新資料庫 API 呼叫，以及身分識別和上述金鑰作為資料庫層級金鑰。 尚未設定加密保護裝置。
3. 您想要作為資料庫上主要保護裝置的資料庫層級金鑰，必須先加入次要資料庫。 使用 Set-AzSqlDatabase 搭配 -KeyList，在次要資料庫上新增此金鑰。
4. 將加密保護裝置金鑰新增至次要資料庫之後，請使用 Set-AzSqlDatabase ，並使用 -EncryptionProtector 參數將其設定為主資料庫上的加密保護裝置。
5. 將金鑰設定為次要資料庫上的加密保護裝置，如 (4) 中所述，以完成移轉。

重要

若要移轉使用伺服器層級服務管理金鑰和異地複寫所設定的資料庫，請遵循本節中的步驟 (3)、(4) 和 (5)。

異地複寫和高可用性

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

若要為已使用資料庫層級 CMK 設定的資料庫建立作用中異地複寫，必須使用有效的使用者指派受控識別和主資料庫所使用的目前金鑰清單來建立次要複本。 您可以使用必要的篩選和查詢參數，或使用 PowerShell 和 Azure CLI，從主要資料庫擷取目前金鑰的清單。 設定這類資料庫的異地複本所需步驟如下：

1. 使用 Get-AzSqlDatabase 命令以及 -ExpandKeyList 和 -KeysFilter "current" 參數，預先填入主要資料庫所使用的金鑰清單。 如果您想要擷取所有金鑰，請排除 -KeysFilter。
2. 請選取使用者指派的受控識別 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)。
3. 使用 New-AzSqlDatabaseSecondary 建立新的資料庫作為次要複本，並提供從來源資料庫取得的金鑰預先填入清單，以及上述身分識別 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)，在 API 呼叫使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector (如有需要則 -FederatedClientId) 參數。
4. 使用 New-AzSqlDatabaseCopy 建立具有上一個步驟中相同參數的資料庫複本。

重要

以資料庫層級 CMK 設定的資料庫必須具有複本 (或備份) 以資料庫層級 CMK 進行設定。 複本無法使用伺服器層級加密設定。

若要在容錯移轉群組中使用以資料庫層級 CMK 設定的資料庫，您必須在次要伺服器上使用與主要複本同名建立次要複本的上述步驟。 設定此次要複本之後，就可以將資料庫新增至容錯移轉群組。

使用資料庫層級 CMK 設定的資料庫不支援在新增至容錯移轉群組時自動建立次要複本。

如需詳細資訊，請使用資料庫層級客戶自控的金鑰來設定透明資料加密的異地複寫和備份還原，說明如何使用 REST API、PowerShell 和 Azure CLI 設定異地複寫和容錯移轉群組。

注意

所有使用 CMK 透明資料加密 (TDE) 中標示關於伺服器層級 CMK 的異地複寫和高可用性的所有最佳作法，同樣適用於資料庫層級 CMK。

在資料庫層級使用 TDE 搭配客戶自控的金鑰來備份和還原資料庫

使用 Azure Key Vault 中的金鑰以 TDE 加密資料庫後，新產生的任何備份也會使用相同 TDE 保護裝置進行加密。 TDE 保護裝置有所變更時，資料庫的舊備份不會更新為使用最新 TDE 保護裝置。 若要從 Azure Key Vault 還原在資料庫層級以 TDE 保護裝置加密的備份，請確定向目標資料庫提供關鍵資料。 我們建議您將所有舊版的 TDE 保護裝置保存在金鑰保存庫中，以便在還原資料庫備份時使用。

重要

資料庫只能設定一個 TDE 保護裝置。 不過，您可在還原期間將多個額外的金鑰傳遞至資料庫，而不需要將其標記為 TDE 保護裝置。 這些金鑰不會用來保護 DEK，但如果備份檔案是以具有對應指紋的金鑰進行加密，則可在從備份還原期間使用。

還原時間點

針對使用資料庫層級客戶自控金鑰所設定資料庫的時間點還原，需要下列步驟：

1. 使用 Get-AzSqlDatabase 命令以及 -ExpandKeyList 和 -KeysFilter "2023-01-01" 參數，預先填入主要資料庫所使用的金鑰清單。 2023-01-01 是您想要還原資料庫時間點的範例。 如果您想要擷取所有金鑰，請排除 -KeysFilter。
2. 請選取使用者指派的受控識別 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)。
3. 使用 Restore-AzSqlDatabase 搭配 -FromPointInTimeBackup 參數，從上述步驟以及上述身分識別取得的金鑰預先填入清單 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)，在 API 呼叫中使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector (如有需要則 -FederatedClientId) 參數。

注意

還原不含 -EncryptionProtector 屬性且具有所有有效金鑰的資料庫將會重設成使用伺服器層級加密。 這對於將資料庫層級客戶自控的金鑰設定還原為伺服器層級客戶自控的金鑰組態很有用。

已卸除的資料庫還原

針對使用資料庫層級客戶自控金鑰所設定資料庫的卸除資料庫還原，需要下列步驟：

1. 使用 Get-AzSqlDeletedDatabaseBackup 和 -ExpandKeyList 參數，預先填入主要資料庫所使用的金鑰清單。 建議您傳遞源資料庫使用的所有金鑰，但或者您也可以嘗試使用刪除時間所提供的金鑰作為 -KeysFilter。
2. 請選取使用者指派的受控識別 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)。
3. 使用 Restore-AzSqlDatabase 搭配 -FromDeletedDatabaseBackup 參數，從上述步驟以及上述身分識別取得的金鑰預先填入清單 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)，在 API 呼叫中使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector (如有需要則 -FederatedClientId) 參數。

異地還原

針對使用資料庫層級客戶自控金鑰所設定的資料庫異地還原，需要下列步驟：

• 使用 Get-AzSqlDatabaseGeoBackup 和 -ExpandKeyList，預先填入主要資料庫所使用的金鑰清單。
• 請選取使用者指派的受控識別 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)。
• 使用 Restore-AzSqlDatabase 搭配 -FromGeoBackup 參數，從上述步驟以及上述身分識別取得的金鑰預先填入清單 (如果設定跨租用戶存取，也請設定同盟用戶端識別碼)，在 API 呼叫中使用 -KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector (如有需要則 -FederatedClientId) 參數。

重要

建議保留資料庫使用的所有金鑰來還原資料庫， 也建議您將這些金鑰全部傳遞至還原目標。

注意

長期備份保留 (LTR) 備份不會提供備份所使用的金鑰清單。 若要還原 LTR 備份，來源資料庫使用的所有金鑰都必須傳遞至 LTR 還原目標。

若要深入了解使用 Powershell、Azure CLI 和 REST API 搭配資料庫層級 CMK 的 SQL Database 備份復原，請參閱使用資料庫層級客戶自控的金鑰設定透明資料加密的異地複寫和備份還原。

限制

當資料庫虛擬記錄檔使用與資料庫目前主要保護裝置不同的舊金鑰加密時，資料庫層級客戶自控的金鑰功能不支援金鑰輪替。 在此情況下擲回的錯誤為：

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse：當使用中交易保留使用舊金鑰加密的記錄時，會封鎖資料庫層級 TDE 保護裝置的金鑰輪替。

若要進一步了解此案例，讓我們考慮下列時程表：

• 時間 t0 = 建立資料庫而不加密
• 時間 t1 = 此資料庫受到 Thumbprint A 保護，這是資料庫層級客戶自控的金鑰。
• 時間 t2 = 此資料庫保護裝置會輪替為新資料庫層級客戶自控金鑰，Thumbprint B。
• 時間 t3 = 要求保護裝置變更 Thumbprint C。
• 如果使用中的 VLF 使用 Thumbprint A，則不允許輪替。
• 如果使用中的 VLF 未使用 Thumbprint A，則允許輪替。

您可以使用使用 sys.dm_db_log_info (Transact-SQL) - SQL Server 檢視針對您的資料庫，並尋找作用中虛擬記錄檔。 您應該會看到使用第一個金鑰加密的作用中 VLF (例如 Thumbprint A)。 一旦資料插入產生足夠的記錄，這個舊的 VLF 就會排清，而且您應該可執行另一個金鑰輪替。

如果您認為某個項目保留記錄的時間超過預期，請參閱下列文件以進一步進行疑難排解：

• sys.dm_db_log_stats (Transact-SQL) 針對 log_truncation_holdup_reason 的值。
• 針對寫滿交易記錄錯誤 9002 進行疑難排解。

下一步

請查看下列有關各種資料庫層級 CMK 作業的文件：

• 使用資料庫層級客戶自控金鑰的 TDE 身分識別和金鑰管理

• 使用資料庫層級客戶自控的金鑰設定透明資料加密的異地複寫和備份還原