TDE with database-level CMK now generally available for Azure SQL Database

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Azure SQL Database provides Transparent Data Encryption (TDE) to safeguard against offline threats by encrypting the data at rest. By using a Customer-Managed Key (CMK), TDE can further enhance data protection by enabling the use of a key stored in a customer owned and managed Azure Key Vault as the TDE Protector on the server. When TDE with CMK is set at the server level, all encrypted databases associated with the server inherit the same level of protection.

With the introduction of database level CMK, the TDE protector can be set at the individual database level, protected by a different key that is managed by the customer.

Database level CMK overview

In this scenario, a key that is stored in a customer owned and managed Azure Key Vault (AKV) can be used for each database within a server to encrypt the database encryption key (DEK), called the TDE protector. The feature provides the ability to add keys, remove keys, and change the user-assigned managed identity (UMI) for each database. For more information on identity management, see Managed identity types in Azure.

The following functionality is available for database level CMK:

User-assigned managed identity:
You can assign a single user-assigned managed identity to the database. This identity can be used to access the Azure Key Vault and manage encryption keys.
Encryption key management:
You can add one or more encryption keys to the database level and set one of the added keys as the primary TDE protector. The user assigned identity that is assigned to the database will be used to access the encryption key that is stored in the Azure key Vault.
Automatic key rotation
You can setup an automatic key rotation for an individual database with database level CMK that rotates a key following the Azure Key Vault rotation policy.
Federated client identity
You can enable a customer-managed key (CMK) to use as the TDE protector at the database-level from Azure Key Vault in a different tenant of Microsoft Entra ID (formerly Azure Active Directory) than the tenant used by the server, by utilizing the federated client identity set on the database. This allows you to manage TDE with keys stored in a different key vault tenant than the tenant of the server that you are protecting.

The diagram below shows the functionality described above. The logical server in Azure SQL is set up with default service-managed key (SMK). By default, the database service-managed key (DBSMK) inherits the server SMK setting for TDE during its creation. The other two databases are set up with database level CMKs. The TDE CMK protector Key 1 that is assigned to the database DBCMK1, resides in AKV 1, and is protected by UMI 1. Key 2 is assigned to the database DBCMK2, resides in AKV 2, and is protected by UMI 2.

Note: The Azure Key Vault does not have to reside in the same tenant as the Azure SQL resource and can be set up in a different tenant. For additional information on database level CMK and supported scenarios, see here.

The database level CMK can be set up and managed using different surface areas, such as Azure portal, PowerShell, Azure CLI, and Rest API. Additionally, the database-level CMK can be automatically rotated. See here for more details.

For more details on how to configure geo replication, and backup or restore scenarios for database level CMK, see here.

For the demo video see below.

For questions related to database-level CMK, please contact sqltdefeedback@microsoft.com.

Learn More

Leave a Reply Cancel reply