Edit

Use Azure Key Vault in a multitenant solution

Azure Key Vault manages secure data, including secrets, encryption keys, and certificates. This article describes Key Vault features that benefit multitenant solutions. It also provides links to guidance that can help you plan how to use Key Vault.

Isolation models

When you work with a multitenant system that uses Key Vault, determine the level of isolation that you need. Your isolation model depends on the following factors:

  • How many tenants you have

  • Whether you share your application tier between multiple tenants, deploy single-tenant application instances, or deploy separate deployment stamps for each tenant

  • Whether your tenants must manage their own encryption keys

  • Whether your tenants have compliance requirements that require you to store their secrets separately from other tenants' secrets

The following table summarizes the differences between the main tenancy models for Key Vault.

Consideration Vault for each tenant, in the provider's subscription Vault for each tenant, in the tenant's subscription Shared vault
Data isolation High Very high Low
Performance isolation Medium. High throughput might be limited, even with many vaults. High Low
Deployment complexity Low-medium, depending on the number of tenants High. The tenant must correctly grant access to the provider. Low
Operational complexity High Low for the provider, higher for the tenant Lowest
Example scenario Individual application instances for each tenant Customer-managed encryption keys Large multitenant solution that has a shared application tier

Vault for each tenant, in the provider's subscription

Consider deploying a vault for each tenant within your (the service provider's) Azure subscription. This approach provides strong data isolation between each tenant's data. But you must deploy and manage an increasing number of vaults as the number of tenants increases.

Azure doesn't limit the number of vaults that you can deploy within a single subscription. But consider other limits:

Vault for each tenant, in the tenant's subscription

In some scenarios, your tenants can create vaults in their own Azure subscriptions and grant your application access to work with secrets, certificates, or keys. Use this approach when you allow customer-managed keys for encryption within your solution.

To access the data in your tenant's vault, the tenant must provide your application with access to their vault. This process requires that your application authenticates through their Microsoft Entra ID instance. You can publish a multitenant Microsoft Entra ID application.

Your tenants must perform a one-time consent process that includes the following steps:

  1. Register the multitenant Microsoft Entra application in their Microsoft Entra tenant.

  2. Grant your multitenant Microsoft Entra application the appropriate level of access to their vault.

  3. Provide you with the full resource ID of the vault that they create.

After this setup, your application code can use a service principal associated with the multitenant Microsoft Entra ID application in your Microsoft Entra ID to access each tenant's vault.

Or you can ask each tenant to create a service principal for your service to use and provide you with its credentials. But this approach requires you to securely store and manage credentials for each tenant, which introduces a security liability.

If your tenants configure network access controls on their vaults, make sure that you can access the vaults. Design your application to handle situations where a tenant changes their network access controls and blocks your access to their vaults.

Shared vaults

You can store multiple tenants' secrets within a shared vault in your subscription. This approach reduces the number of vaults that you manage, but it provides less data isolation and performance isolation than separate vaults.

Deployment stamps and regions

You can also deploy multiple shared vaults. For example, a solution that follows the Deployment Stamps pattern likely deploys a shared vault within each stamp. Similarly, if you deploy a multi-region solution, you should deploy vaults into each region for the following reasons:

  • To avoid cross-region traffic latency when you work with data in your vault
  • To support data residency requirements
  • To enable the use of regional vaults within other services that require same-region deployments

Request throughput

When you work with a shared vault, consider the number of operations that you perform against the vault. Operations include reading secrets and performing encryption or decryption operations. Key Vault imposes limits on the number of requests made against a single vault and across all vaults within an Azure subscription. Follow the throttling guidance, and apply other recommended practices. Securely cache secrets that you retrieve, and use envelope encryption to avoid sending all encryption operations to Key Vault. These best practices help you run high-scale solutions against a single vault.

Network connectivity

Private endpoint limits can also affect a shared vault. Key Vault limits the number of private endpoints for each vault, which can constrain how many tenant networks can connect to the same vault through separate private endpoints. Consider these connection requirements when you decide whether to share a vault or deploy separate vaults. For more information, see Key Vault private endpoint guidance.

Access control

When an application identity can access multiple tenants' secrets, a compromise of that identity can expose all of those secrets. Prefer separate vaults along with isolated applications when you need to enforce a security boundary between tenants. For more information, see Key Vault security guidance.

A naming convention, like a tenant ID prefix, helps your application locate tenant-specific secrets, keys, and certificates in a shared vault. But naming conventions don't enforce access control. Authorize each request against the tenant's context before you access the corresponding object, and restrict the application's permissions to the objects that it needs.

Azure role-based access control (Azure RBAC) supports role assignments on individual secrets, keys, and certificates. When each tenant has a separate application identity, you can use these assignments to limit each identity to its tenant's objects. A single identity that accesses multiple tenants' objects doesn't get this separation, so your application must take responsibility for authorizing each request. Object-level role assignments also don't provide separate network controls or performance isolation. Key Vault guidance recommends that you use them only for limited scenarios. For more information, see Best practices for individual role assignments.

Features of Key Vault that support multitenancy

Tags

Key Vault supports tagging secrets, certificates, and keys by adding custom metadata. You can use a tag to track the tenant ID for each tenant-specific secret. But Key Vault doesn't support querying by tags, so this feature works best for management purposes rather than within application logic.

For more information, see the following resources:

Azure Policy support

If you deploy a large number of vaults, ensure that they follow a consistent standard for network access configuration, logging, and access control. Consider using Azure Policy to verify that the vaults are configured according to your requirements.

For more information, see the following resources:

Azure Key Vault Managed HSM and Azure Cloud HSM

When Key Vault operation limits aren't enough for your cryptographic workload, consider Managed HSM. Each Managed HSM instance is dedicated to a single customer and provides reserved capacity, but it costs more than Key Vault. Managed HSM stores only keys, so you still need another store for secrets and certificates. Plan for the limits on the number of instances that you can deploy in each region.

Azure Cloud HSM suits a different scenario. Choose it when an application that runs on virtual machines needs direct HSM access through interfaces such as PKCS#11. Cloud HSM is an infrastructure as a service (IaaS) offering, and it doesn't integrate with Azure platform as a service (PaaS) or software as a service (SaaS) services. For customer-managed keys in Azure services, use Managed HSM instead.

For more information, see the following resources:

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal author:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

  • Last updated on