Edit

Share via

Secure your Azure Key Vault

Azure Key Vault protects cryptographic keys, certificates (and the private keys associated with the certificates), and secrets (such as connection strings and passwords) in the cloud. When storing sensitive and business-critical data, however, you must take steps to maximize the security of your vaults and the data stored in them.

The security recommendations in this article implement Zero Trust principles: "Verify explicitly", "Use least privilege access", and "Assume breach". For comprehensive Zero Trust guidance, see the Zero Trust Guidance Center.

This article provides security recommendations to help protect your Azure Key Vault deployment.

Service-specific security

Azure Key Vault has unique security considerations related to vault architecture and appropriate use of the service for storing cryptographic materials.

Key vault architecture

  • Use one Key Vault per application, region, and environment: Create separate Key Vaults for development, preproduction, and production environments to reduce the impact of breaches.

    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.

  • Use one Key Vault per tenant in multitenant solutions: For multitenant SaaS solutions, use a separate Key Vault for each tenant to maintain data isolation. This is the recommended approach for secure isolation of customer data and workloads. See Multitenancy and Azure Key Vault.

Object Storage in Key Vault

  • Do not use Key Vault as a data storage to store customer configurations or service configurations: Services should use Azure Storage with encryption at rest or Azure configuration manager. Storage is more performant for such scenarios.

  • Do not store certificates (customer or service owned) as secrets: Service-owned certificates should be stored as Key Vault certificates and configured for autorotation. For more information, see Azure key vault: Certificates and Understanding autorotation in Azure Key Vault.

    • Customer content (excluding secrets and certificates) should not be stored in Key Vault: Key Vault is not a data store and not built to scale like a data store. Instead use a proper data store like Cosmos DB or Azure Storage. Customers have the option of BYOK (Bring Your Own Key) for encryption at rest. This key can be stored in Azure Key Vault to encrypt the data in Azure Storage.

Network Security

Reducing network exposure is critical to protecting Azure Key Vault from unauthorized access. Configure network restrictions based on your organization's requirements and use case.

These network security features are listed from most restricted to least restricted capabilities. Pick the configuration that best suits your organization's use case.

  • Disable public network access and use Private Endpoints only: Deploy Azure Private Link to establish a private access point from a virtual network to Azure Key Vault and prevent exposure to the public internet. For implementation steps, see Integrate Key Vault with Azure Private Link.

  • Enable Key Vault Firewall: Limit access to public static IP addresses or your virtual networks. For full details, see Key Vault network security: firewall settings.

    • Some customer scenarios require trusted Microsoft services to bypass the firewall, in such cases the vault might need to be configured to allow Trusted Microsoft Services.

  • Use Network Security Perimeter: Define a logical network isolation boundary for PaaS resources (for example, Azure Key Vault, Azure Storage and SQL Database) that are deployed outside your organization's virtual network perimeter and/or public static IP addresses. For full details, see Network security: Network Security Perimeter)

    • "publicNetworkAccess": "SecuredByPerimeter" overrides "Allow trusted Microsoft services to bypass the firewall", meaning that some scenarios that require that trust will not work.

TLS and HTTPS

Azure Key Vault supports TLS 1.2 and 1.3 protocol versions to ensure secure communication between clients and the service.

  • Enforce TLS version control: The Key Vault front end (data plane) is a multi-tenant server where key vaults from different customers can share the same public IP address. To achieve isolation, each HTTP request is authenticated and authorized independently. The HTTPS protocol allows clients to participate in TLS negotiation, and clients can enforce the TLS version to ensure the entire connection uses the corresponding level of protection. See Key Vault logging for sample Kusto queries to monitor TLS versions used by clients.

Identity and access management

Azure Key Vault uses Microsoft Entra ID for authentication. Access is controlled through two interfaces: the control plane (for managing Key Vault itself) and the data plane (for working with keys, secrets, and certificates). For details on the access model and endpoints, see Azure RBAC for Key Vault data plane operations.

  • Enable managed identities: Use Azure managed identities for all app and service connections to Azure Key Vault to eliminate hard-coded credentials. Managed identities help secure authentication while removing the need for explicit credentials. For authentication methods and scenarios, see Azure Key Vault authentication.

  • Use role-based access control: Use Azure Role-Based Access Control (RBAC) to manage access to the Azure Key Vault. For more information, see Azure RBAC for Key Vault data plane operations.

    Important

    RBAC permission model allows vault-level role assignments for persistent access and eligible (JIT) assignments for privileged operations. Object-scope assignments only support read operations; administrative operations like network access control, monitoring, and object management require vault-level permissions. For secure isolation across application teams, use one Key Vault per application.

  • Assign just-in-time (JIT) privileged roles: Use Azure Privileged Identity Management (PIM) to assign eligible JIT Azure RBAC roles for administrators and operators of Key Vault. See Privileged Identity Management (PIM) overview for details.

  • Enable Microsoft Entra Conditional Access Policies: Key Vault supports Microsoft Entra Conditional Access policies to apply access controls based on conditions such as user location or device. For more information, see Conditional Access overview.

  • Apply the principle of least privilege: Limit the number of users with administrative roles and ensure users are granted only the minimum permissions required for their role. See Enhance security with the principle of least privilege

Data Protection

Protecting data stored in Azure Key Vault requires enabling soft delete, purge protection, and implementing automated rotation of cryptographic materials.

Compliance and governance

Regular compliance audits and governance policies ensure your Key Vault deployment adheres to security standards and organizational requirements.

Logging and Threat Detection

Comprehensive logging and monitoring enable detection of suspicious activities and compliance with audit requirements.

Backup and Recovery

Regular backups ensure business continuity and protect against data loss from accidental or malicious deletion.

  • Enable native backup for Azure Key Vault: Configure and use the Azure Key Vault native backup feature to back up secrets, keys, and certificates, ensuring recoverability. See Azure Key Vault backup.

  • Ensure backups for secrets that can't be recreated: Back up Key Vault objects (like encryption keys) that can't be recreated from other sources. See Azure Key Vault backup.

  • Test backup and recovery procedures: To verify the effectiveness of backup processes, regularly test the restoration of Key Vault secrets, keys, and certificates. See Azure Key Vault backup.

For security best practices specific to keys, secrets, and certificates, see:

Next steps

  • Last updated on