Transparent data encryption (TDE) in Azure SQL Database and Managed Instance helps protect against the threat of malicious offline activity by encrypting data at rest. Azure SQL TDE with Customer-Managed Key (CMK) enables Bring Your Own Key (BYOK) scenario for data protection at rest, and allows customer to have full control of the key lifecycle management. TDE is one of the most widely used security features in Azure SQL and customers are increasingly adopting BYOK to meet compliance and regulatory requirements.
We are announcing a number of key improvements to the TDE BYOK feature which will provide customers with greater flexibility in configuring their database servers with CMK, as well as hardening overall security configuration of the databases.
User-Assigned Managed Identity support for TDE BYOK in Azure SQL Database and Managed Instance
Managed identities in Azure Active Directory (Azure AD) provide Azure services with an automatically managed identity in Azure AD which can be used to authenticate to any service that supports Azure AD authentication, without any credentials in the code. Managed Identities can be of two types:
- System-assigned
- User-assigned
System-assigned managed identities are created for a specific Azure resource and are tied to the lifetime of that Azure resource. User-assigned managed identities, on the other hand, are standalone Azure resources with an independent lifecycle and can be associated with multiple Azure resources. Enabling system-assigned managed identity for Azure SQL logical servers and Managed Instances is already supported today, and once enabled, the same server identity must be provided access to the key vault prior to configuring TDE BYOK on the server.
Assigning a user-assigned managed identity to the Azure SQL logical server and Managed Instance, and using the same for key vault access for TDE BYOK, is now supported and available in public preview.
Benefits of using User-Assigned Managed Identity for TDE BYOK
Leveraging a user-assigned managed identity assigned to the server for TDE BYOK has distinct benefits:
- Pre-authorize key vault access for Azure SQL logical servers or managed instances prior to server creation. This can be done by creating a user assigned managed identity, and granting it access to required key vault(s). Then while creating the server, assigning the user-assigned managed identity to the server enables it to directly access key vault for key encryption/decryption
- Create an Azure SQL logical server or Managed Instance with TDE BYOK enabled by specifying the user-assigned managed identity, key vault and key details at creation time. This is especially useful for customers looking to have their databases encrypted with their own key right from the time database is created, instead of first creating the database with service-managed key and then switching to CMK
- Enables the same user-assigned managed identity to be assigned to multiple servers, eliminating the need to individually turn on system-assigned managed identity for each Azure SQL logical server or managed instance, and providing each server’s system-assigned managed identity access to key vault
Quick steps to create a SQL logical server with user-assigned managed identity and TDE BYOK
- Create a user-assigned managed identity
- Provide the user-assigned managed identity with Get, wrapKey, unwrapKey permissions on the key vault containing the customer’s encryption key
- During server creation workflow, select the user-assigned managed identity, set it as the primary identity on the server, and select the key vault and key
Screenshots of this experience on the Azure Portal are below:
- After providing the above information, submit the server creation workflow. SQL logical server now gets created with TDE enabled with customer-managed key.
For a detailed tutorial with Portal, CLI, PowerShell and ARM template experiences, please refer this link - Create server configured with user-assigned managed identity and customer-managed TDE - Azure SQL Database & Azure Synapse Analytics | Microsoft Docs
Limitations in the public preview
- User-assigned managed identity cannot be used for TDE BYOK when the key vault is behind a VNet. Please continue to use system-assigned managed identity in this case.
- For other known issues, refer our documentation - https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-identity#limitations-and-known-issues
Learn More
- TDE BYOK in Azure SQL - https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview
- Managed Identities for TDE BYOK in Azure SQL - Customer-managed transparent data encryption using user-assigned managed identity - Azure SQL Database | Microsoft Docs
- Managed identity types for Azure resources - Managed identities for Azure resources | Microsoft Docs
Additional feature enhancements for TDE BYOK for Azure SQL DB and MI
Updated built-in Azure Policy to enforce TDE BYOK for Azure SQL Database and Managed Instance
We are releasing an updated version of the built-in Azure Policy to enforce the creation of an Azure SQL Database server or Managed Instance with TDE BYOK enabled during provisioning. Customers can use this policy to meet organizational compliance objectives that require databases to be always created by encrypting with a customer-managed key.
Policy Name – “SQL server should use customer-managed keys to encrypt data at rest”
The policy can be applied to the whole Azure subscription, or just to a resource group. The policy supports “Deny”, “Audit” and “Disabled” effects. With this policy in place with the “Deny” effect, any attempts to create a logical server or managed instance will fail if a customer-managed key hasn’t been selected during provisioning.
For more information on this updated built-in policy, see Azure Policy for customer-managed TDE.
For more information on Azure Policy, see What is Azure Policy? and Azure Policy definition structure.
Support for Azure Key Vault configured with RBAC permissions model
Azure Key Vault supports both the vault access policy model as well as Azure RBAC model, for providing required permissions to a Azure AD managed identity (or other security principal).
For TDE BYOK in Azure SQL Database and Managed Instance, in addition to support for the vault access policy model, support for RBAC permission model is now available.
Depending on the permission model of the key vault (vault access policy or Azure RBAC) that the server needs to access, the server’s managed identity (either system-assigned or user-assigned) can be granted required permissions on the key vault as below:
- For a key vault using the vault access policy model – Create a new access policy on the key vault to grant Get, wrapKey, unwrapKey permissions to the server’s managed identity (either system-assigned or user-assigned)
- For a key vault using the RBAC permission model – Create a new RBAC role assignment on the key vault to assign the role Key Vault Crypto Service Encryption User to the server’s managed identity (either system-assigned or user-assigned)
Support for both AKV permission models enables further flexibility in how customers choose to provision access to their database servers on the key vaults.
This feature enhancement is in public preview.
Ability to link server and key vault located in different Azure regions
For TDE BYOK configuration, Azure SQL Database servers and Managed Instances in one Azure region can now be linked to key vault in any other Azure region. The server and key vault no longer need to be co-located in the same region.
With this, customers can have the flexibility to locate their Azure SQL server and key vaults in the region of their choosing.
Another benefit of this is in geo-replication and failover group scenarios, in which case, the primary and secondary servers can be connected to the same key vault, eliminating the need to maintain separate key vault for each server and the need to keep the key material used as TDE Protector in sync across both key vaults.
We hope the above enhancements to TDE BYOK will provide Azure SQL customers more flexibility and ease-of-use in managing their customer-managed keys.
Posted at https://sl.advdat.com/3sdnlD6
