Cross-tenant customer-managed keys with transparent data encryption
Applies to: Azure SQL Database Azure Synapse Analytics (dedicated SQL pools only)
Azure SQL now offers support for cross-tenant customer-managed keys (CMK) with transparent data encryption (TDE). Cross-tenant CMK expands on the Bring Your Own Key (BYOK) scenario for utilizing TDE without the need to have the logical server in Azure in the same Microsoft Entra tenant as the Azure Key Vault that stores the customer-managed key used to protect the server.
You can configure TDE with CMK for Azure SQL Database for keys stored in key vaults that are configured in different Microsoft Entra tenants. Microsoft Entra ID (formerly Azure Active Directory) introduces a feature called workload identity federation, and it allows Azure resources from one Microsoft Entra tenant the capability to access resources in another Microsoft Entra tenant.
For documentation on transparent data encryption for dedicated SQL pools inside Synapse workspaces, see Azure Synapse Analytics encryption.
Note
Microsoft Entra ID was previously known as Azure Active Directory (Azure AD).
Common use scenario
Cross-tenant CMK capabilities allow service providers or independent software vendors (ISV) building services on top of Azure SQL to extend Azure SQL's TDE with CMK capabilities to their respective customers. With cross-tenant CMK support enabled, ISV customers can own the key vault and encryption keys in their own subscription and Microsoft Entra tenant. The customer has full control over key management operations, while accessing Azure SQL resources in the ISV tenant.
Cross-tenant interactions
Cross-tenant interaction between Azure SQL and a key vault in another Microsoft Entra tenant is enabled with the Microsoft Entra feature, workload identity federation.
ISVs that deploy Azure SQL services can create a multi-tenant application in Microsoft Entra ID, and then configure a federated identity credential for this application using a user-assigned managed identity. With the appropriate application name and application ID, a client or ISV customer can install the ISV created application in their own tenant. The customer then grants the service principal associated with the application permissions (needed for Azure SQL) to their key vault in their tenant, and shares their key location with the ISV. Once the ISV assigns the managed identity and federated client identity to the Azure SQL resource, the Azure SQL resource in the ISV's tenant can access the customer's key vault.
For more information, see:
- Configure cross-tenant customer-managed keys for a new storage account
- Configure cross-tenant customer-managed keys for an existing storage account
Setting up cross-tenant CMK
The following diagram represents the steps for a scenario that utilizes an Azure SQL logical server that uses TDE to encrypt the data at rest using a cross-tenant CMK with a user-assigned managed identity.
Overview of the setup
On the ISV tenant
Create a user-assigned managed identity
Create a multi-tenant application
- Configure the user-assigned managed identity as a federated credential on the application
On the client tenant
Create or use existing key vault and grant key permissions to the multi-tenant application
Create a new or use an existing key
Retrieve the key from Key Vault and record the Key Identifier
On the ISV tenant
Assign the user-assigned managed identity created as the Primary identity in the Azure SQL resource Identity menu in the Azure portal
Assign the Federated client identity in the same Identity menu, and use the application name
In the Transparent data encryption menu of the Azure SQL resource, assign a Key identifier using the customer's Key Identifier obtained from the client tenant.
Remarks
- The cross-tenant CMK with TDE feature is only supported for user-assigned managed identities. You cannot use a system-assigned managed identity for cross-tenant CMK with TDE.
- Setting up cross-tenant CMK with TDE is supported at the server level and the database level for Azure SQL Database. For more information, see Transparent data encryption (TDE) with customer-managed keys at the database level.
Next steps
See also
- Create Azure SQL database configured with user-assigned managed identity and customer-managed TDE
- Configure cross-tenant customer-managed keys for a new storage account
- Configure cross-tenant customer-managed keys for an existing storage account
- Transparent data encryption (TDE) with customer-managed keys at the database level
- Configure geo replication and backup restore for transparent data encryption with database level customer-managed keys
- Identity and key management for TDE with database level customer-managed keys