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 customer-managed Azure Key Vault as the TDE Protector on the server. This way, all encrypted databases associated with the server inherit the same level of protection. Note that TDE with CMK is currently set at the server level.
The new feature allows setting the TDE protector 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 customer-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. - Federated client identity
You can enable a customer-managed key (CMK) from Azure Key Vault in a different Azure Active Directory (Azure AD) tenant to use as the TDE protector at the database-level, 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.
The diagram below shows the functionality described above. The Azure SQL Server is set up with default service-managed key (SMK). The database DBSMK, by default 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 assigned to the database DBCMK1, resides in AKV 1 and is protected by UMI 1, while the Key 2 assigned to the database DBCMK2 resides in AKV 2, 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 PowerShell, Azure CLI, and Rest API. See here for more details.
For more details on how to configure geo replication and backup restore for database level CMK, see here.
The following functionalities are not supported in preview:
- The Azure portal for database level CMK
- Auto-rotation for database level CMK
For questions related to database-level CMK, please contact sqltdefeedback@microsoft.com.
Learn More
- Transparent data encryption (TDE) with database level customer-managed keys - Azure SQL Database | Microsoft Learn
- Identity and key management for TDE with database level customer-managed keys - Azure SQL Database | Microsoft Learn
- Configure geo replication and backup restore for transparent data encryption (TDE) with database level customer-managed keys - Azure SQL Database | Microsoft Learn
- Cross-tenant customer-managed keys with transparent data encryption - Azure SQL Database & Azure Synapse Analytics | Microsoft Learn