Best practices for using Azure Key Vault (2024)

Azure Key Vault safeguards encryption keys and secrets like certificates, connection strings, and passwords. This article helps you optimize your use of key vaults.

Use separate key vaults

Our recommendation is to use a vault per application per environment (development, preproduction, and production), per region. Granular isolation helps you not share secrets across applications, environments and regions, and it also reduce the threat if there is a breach.

Why we recommend separate key vaults

Key vaults define security boundaries for stored secrets. Grouping secrets into the same vault increases the blast radius of a security event because attacks might be able to access secrets across concerns. To mitigate access across concerns, consider what secrets a specific application should have access to, and then separate your key vaults based on this delineation. Separating key vaults by application is the most common boundary. Security boundaries, however, can be more granular for large applications, for example, per group of related services.

Control access to your vault

Encryption keys and secrets like certificates, connection strings, and passwords are sensitive and business critical. You need to secure access to your key vaults by allowing only authorized applications and users. Azure Key Vault security features provides an overview of the Key Vault access model. It explains authentication and authorization. It also describes how to secure access to your key vaults.

Recommendations for controlling access to your vault are as follows:

• Lock down access to your subscription, resource group, and key vaults using role-based access control (RBAC) permission model for data plane.
  • Assign RBAC roles at Key Vault scope for applications, services, and workloads requiring persistent access to Key Vault
  • Assign just-in-time eligible RBAC roles for operators, administrators, and other user accounts requiring privileged access to Key Vault using Privileged Identity Management (PIM)
    • Require at least one approver
    • Enforce multi-factor authentication
• Restrict network access with Private Link, firewall and virtual networks

Turn on data protection for your vault

Turn on purge protection to guard against malicious or accidental deletion of the secrets and key vault even after soft-delete is turned on.

For more information, see Azure Key Vault soft-delete overview.

Turn on logging

Turn on logging for your vault. Also, set up alerts.

Backup

Purge protection prevents malicious and accidental deletion of vault objects for up to 90 days. In scenarios, when purge protection is not a possible option, we recommend backup vault objects, which can't be recreated from other sources like encryption keys generated within the vault.

For more information about backup, see Azure Key Vault backup and restore.

Multitenant solutions and Key Vault

A multitenant solution is built on an architecture where components are used to serve multiple customers or tenants. Multitenant solutions are often used to support software as a service (SaaS) solutions. If you're building a multitenant solution that includes Key Vault, it is recommended to use one Key Vault per customer to provide isolation for customers data and workloads, review Multitenancy and Azure Key Vault.

Frequently Asked Questions:

Can I use Key Vault role-based access control (RBAC) permission model object-scope assignments to provide isolation for application teams within Key Vault?

No. RBAC permission model allows to assign access to individual objects in Key Vault to user or application, but only for read. Any administrative operations like network access control, monitoring, and objects management require vault level permissions. Having one Key Vault per application provides secure isolation for operators across application teams.

Next steps

Learn more about key management best practices:

• Best practices for secrets management in Key Vault
• Best practices for Azure Managed HSM