Edit

Share via

Cross-tenant customer-managed keys with transparent data encryption

Applies to: Azure SQL Database

Azure SQL Database 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 or Azure Managed HSM 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 or managed HSMs 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.

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 Database to extend Azure SQL Database TDE with CMK capabilities to their respective customers. With cross-tenant CMK support enabled, ISV customers can own the key vault or managed HSM 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 Database and key vault or managed HSM in another Microsoft Entra tenant is enabled with the Microsoft Entra feature, workload identity federation.

ISVs that deploy Azure SQL Database services can create a multitenant 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 Database) to their key vault or managed HSM 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 Database resource, the Azure SQL Database resource in the ISV's tenant can access the customer's key vault or managed HSM.

For more information, see:

Set up cross-tenant CMK

The following diagram represents the steps for a scenario that utilizes an Azure SQL Database logical server that uses TDE to encrypt the data at rest using a cross-tenant CMK with a user-assigned managed identity.

Diagram of setting up cross-tenant transparent data encryption with customer-managed keys.

Overview of the setup

On the ISV tenant

  1. Create a user-assigned managed identity

  2. Create a multitenant application

    1. Configure the user-assigned managed identity as a federated credential on the application

On the client tenant

  1. Install the multitenant application

  2. Create or use existing key vault or managed HSM and grant key permissions to the multitenant application

    1. Create a new or use an existing key

    2. Retrieve the key from Azure Key Vault or Azure Managed HSM and record the Key Identifier

On the ISV tenant

  1. Assign the user-assigned managed identity created as the Primary identity in the Azure SQL resource Identity menu in the Azure portal

  2. Assign the Federated client identity in the same Identity menu, and use the application name

  3. 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

Next step

Create Azure SQL Database logical server configured with user-assigned managed identity and cross-tenant CMK for TDE

Related content