How to secure Azure Key Vault?

Over the last couple of years, I have helped different enterprises to build secure and scalable Azure solutions that are consumable by internal DevOps teams. At the moment, I mainly focus on the concept of Azure Landing Zones, which uses Policy-driven Governance to enforce compliance out of the box. As a result, DevOps teams can consume Azure services in a variety of ways (e.g. Azure Portal or Terraform) as long as their configuration is aligned with the security standards of your enterprise.

Within this blogpost, I want to share my experience with securing Azure Key Vault. As such, I discuss the Azure service, its most relevant security features, and the Azure Policy Definitions you can use to enforce these security features.

Introduction to Azure Key Vault

Azure Key Vault is an Azure service that helps you to securely store and access secrets. A secret is anything that you want to control access to, like a password, cryptographic key, or certificate. Currently, it supports vaults and managed Hardware Security Module (HSM) pools. Vaults can be used to store software and HSM-backed keys, secrets, and certificates whereas HSM pools only support HSM-backed keys. With the introduction out of the way, it is time to look at the security features of this Azure service.

Security Features of Azure Key Vault

Since Azure Key Vault enables you to store and access secrets, you want this Azure service to be protected properly. Therefore, I will discuss its most relevant security features, that are inline with the Azure security baseline for Key Vault. On top of that, I will provide various Azure Policy examples that you can use to monitor or enforce these security features.

Be aware, the security features, and my recommendations on their usage, does not take your security standards and risk appetite into account. Therefore, your implementation might be very different from mine but still suffice the security needs of your company.

Network Security

Azure Key Vault is a Platform as a Service (PaaS) resource that essentially lives in Azure Public. Consequently, you can interact with it over the internet. In terms of networking, there are three options:

1. Allow public access from all networks
2. Allow public access from specific virtual networks and IP addresses
3. Disable public access

When you select option 1, there are no restrictions to interact with Azure Key Vault from a networking perspective. You can select this option by clicking on the ‘Networking’ tab as is visualized in Figure 1. Nevertheless, if you want to control access on the networking level, you need to select either option 2 or 3.

Figure 1: Allow public access from all networks

Option 2 essentially creates a PaaS firewall in front of the Azure service that allows you to whitelist certain traffic. This traffic filtering can be applied on IP addresses or Virtual Networks. When using IP-based filtering, you can denote the IP addresses or IP address ranges from which traffic to the Azure Key Vault is allowed. When using the latter option, you need to create a Service Endpoint that is linked to a Virtual Network and whitelist traffic from that Virtual Network in the PaaS firewall. On top of that, you can use the ‘Allow trusted Microsoft services to bypass this firewall’ setting to let trusted Microsoft services bypass the firewall. Since Access Policies can only be configured for identities bound to your own Tenant, the residual risk of enabling this setting is minimal whereas it can provide great benefits since you do not have to whitelist trusted Microsoft services that have no default IP addresses or IP address ranges. Again, option 2 can be selected by clicking on the ‘Networking’ tab as is visualized in Figure 2.

Figure 2: Allow public access from specific virtual networks and IP addresses

The third option simply disables public access to the Azure service in its entirety. When selecting this option, you should create a Private Endpoint to connect to the Azure Key Vault on a networking level. Figure 3 displays this option in more detail.

Figure 3: Disable public access

Be aware, Private Endpoints are only a feasible solution for traffic that originates from Azure Private or On-premises. When traffic originates from for instance Azure Public, Private Endpoints cannot be used since the Domain Name System (DNS) records cannot be resolved properly. Therefore, I recommend using option 2, but implement Private Endpoints for workloads that can use it. Be aware, when implementing Private Endpoints, you might want to limit cross-tenant connections in order to minimize your data exfiltration risks. In Figure 4, the different options, and their respective traffic flows, are visualized in more detail.

Figure 4: Selecting a networking option for Azure Key Vault

Identity Management

Azure Key Vault has a control plane and a data plane. The control plane of this Azure service can be used to for instance configure the Diagnostic Settings or the Networking topology whereas the data plane comprises the passwords, cryptographic keys, or certificates stored within the Azure Key Vault.

Access to the control plane is arranged via Role-based Access Control (RBAC). For instance, the Key Vault Contributor role allows you to manage this Azure service but does not allow you to manage secrets, keys, or certificates. As you can see in Figure 5, you can create Role Definitions and Role Assignments by clicking on the ‘Access control (IAM)’ tab and subsequently hitting the ‘Add’ button.

Figure 5: Creating a Role Definition and Assignment for control plane access

On the other hand, access to the data plane is managed via so-called Access Policies which is very similar to RBAC as it enables you to assign custom or built-in Role Definitions to certain identities, via Role Assignments. As visualized in Figure 6, you can create an Access Policy by clicking on the ‘Access policies’ tab and then hitting the ‘Create’ button.

Figure 6: Creating an Access Policy for data plane access

One of the big benefits of Azure Key Vault is that Azure Active Directory (AAD) is used as the default identity and access management service. In other words, Role Definitions can only be assigned to identities that are part of your AAD tenant. These identities can encompass Users, Groups, Service Principals or Managed Identities. As a result, identity management for Azure Key Vault provides a great degree of control and granularity, by enabling you to only assign the right permissions to the right people on the right level.

Data Protection

In terms of data protection, there are two main topics to address. First, you need to protect data in transit from attacks like traffic capture. In order to do so, you need to use encryption so that attackers cannot easily read or modify data when it moves between the Azure Key Vault and the client. By default, this Azure service supports data encryption in transit with TLS v1.2. Nevertheless, the client that connects to Azure Key Vault should also use TLS v1.2 or greater. Hence, the responsibility to enforce encryption for data in transit also lies with the customer, not only with Microsoft.

Even though Azure Key Vault is not your typical storage service, it still manages passwords, cryptographic keys, and certificates. Therefore, the encryption of data at rest is another important topic you need to address. Luckily, this Azure service supports encryption of data at rest out of the box, using Microsoft-managed keys. For some other Azure services like Storage Account, you can configure Customer-managed keys instead. However, since this option is not available for Azure Key Vault, data at rest encryption is completely managed by Microsoft and thus the responsibility of the Cloud Service Provider (CSP).

Besides these encryption topics, you also need to manage the objects that are stored in your Azure Key Vault. For instance, passwords, cryptographic keys, and certificates should have an expiration date to make sure that they are rotated, thereby reducing the risk of compromise. Next to that, some organizations have the requirement that certificates can only be signed with certain key types (e.g. RSA). Hence, data protection also encompasses the way in which you, as a customer, manage Azure Key Vault objects. Luckily, Microsoft has created various built-in Policy Definitions that can get you started in this area.

Monitoring and Threat Detection

From a monitoring perspective, there different actions you can take. First, you have the Activity logs which contain logging information regarding actions such as the creation, modification or deletion of the Azure Key Vault. These logs are collected on a Subscription level and can be streamed to a Log Analytics Workspace, Storage Account, Event Hub and Partner Solution. In order to enable this, click on the ‘Activity log’ tab and after that on the ‘Diagnostic settings’ button, as is visualized in Figure 7.

Figure 7: Enabling the Diagnostic settings for the Activity logs

Besides the Activity logs, Azure Key Vault also generates logs and metrics on the behavior of the service itself. For example, the ‘AllMetrics’ setting provides information on the performance metrics of that particular Azure Key Vault. Again, the Diagnostic settings enables you to stream these logs and metrics to a Log Analytics Workspace, Storage Account, Event Hub and Partner Solution. However, this action does not increase the security posture of your Azure service. It is what you do with the information that matters. Therefore, you should connect with your security department to create monitoring use cases that will actually increase your security posture. As Figure 8 displays, hit the ‘Diagnostic settings’ tab and then click on the ‘Add diagnostic setting’ button to configure the Diagnostic setting for Azure Key Vault.

Figure 8: Enabling the Diagnostic settings for the resource-specific logs and metrics

If you have little experience with developing monitoring capabilities in-house, Azure Key Vault also offers the possibility to enable Microsoft Defender for Cloud. This tool continuously monitors your Azure Key Vault to identify security vulnerabilities and recommends actions to mitigate these in order to reduce the attack surface and increase your security posture. Be aware, Microsoft Defender for Cloud needs to be enabled on the Subscription level, not on the Azure service itself. You can check the security posture of your Azure Key Vault when selecting ‘Security’ tab and checking the ‘Recommendations’ list.

Figure 9: Checking the security posture of your Azure Key Vault

Backup and Recovery

Out of the box, Azure Key Vault provides a lot of features to help you maintain availability and prevent data loss. However, it is up to the customer to determine the need of backing up secrets as this process can introduce operational challenges like maintaining multiple sets of logs, permissions, and backups when secrets expire or rotate.

On top of this scenario, you also need to take into account the possibility of a malicious user acquiring the right permissions on your Azure Key Vault. In this case, your Azure Key Vault, and all the secrets within, can be removed very easily. In order to prevent this, Azure has build two recovery features. First, Soft-delete allows you to recover a deleted Azure Key Vault and deleted objects (e.g. keys, secrets and certificates) up to a period of 90 days. The recovery period is set to 90 days by default but can be changed accordingly. Upon the creation of an Azure Key Vault, this feature is enabled by default and cannot be disabled afterwards. To check but also change its configuration, click on the ‘Overview’ tab and then select the ‘Soft-delete’ button as is visualized in Figure 10.

Figure 10: Checking the Soft-delete state of your Azure Key Vault

Whereas Soft-delete is designed to prevent the accidental deletion of your Azure Key Vault, and the keys, secrets, and certificates within, Purge protection is designed to prevent the deletion of these components by a malicious insider. Essentially, you can think of this as a recycle bin with a time-based lock. Until the retention period elapses, you cannot permanently delete or purge an Azure Key Vault, even though you have the permissions to do so. Be aware, once purge protection is enabled, it cannot be disabled or overridden by anyone including Microsoft. As a result, you must either recover a deleted Azure Key Vault or wait for the retention period to elapse before reusing its name. For that reason, it is recommended to enable Purge protection in a production environment but disable it in a pre-production environment. Again, to check or change its configuration, select the ‘Overview’ tab and subsequently click on the ‘Purge protection’ button as is visualized in Figure 10.

Azure Policy

In the ‘Security Features of Azure Key Vault’ section, I have described various security features that you can leverage to make your Azure Key Vault more secure. The usage of many of these features can be either monitored or enforced, using Policy Definitions, Policy Sets and Policy Assignments. Below, I have defined a couple of Policy Definitions, whether these are custom or built-in, and the security feature to which they are linked. In terms of the built-in Policy Definitions, I have only included the ones I deemed relevant. You can find the complete list at ‘Azure Policy built-in definitions for Key Vault’.

1. Key Vault - Firewall Settings DENY [Custom]| Network Security
2. Key Vault - Firewall Settings AUDIT [Custom]| Network Security
3. Private endpoint should be configured for Key Vault [Built-in]| Network Security
4. Key Vault - SKU Setting DENY [Custom] | Data Protection
5. Key Vault - SKU Setting AUDIT [Custom] | Data Protection
6. Certificates should be issued by the specified integrated certificate authority [Built-in] | Data Protection
7. Certificates should be issued by the specified non-integrated certificate authority [Built-in] | Data Protection
8. Certificates should have the specified lifetime action triggers [Built-in] | Data Protection
9. Certificates should use allowed key types [Built-in] | Data Protection
10. Certificates using elliptic curve cryptography should have allowed curve names [Built-in] | Data Protection
11. Certificates using RSA cryptography should have the specified minimum key size [Built-in] | Data Protection
12. Key Vault keys should have an expiration date [Built-in] | Data Protection
13. Key Vault secrets should have an expiration date [Built-in] | Data Protection
14. Keys should be backed by a hardware security module (HSM) [Built-in] | Data Protection
15. Keys should be the specified cryptographic type RSA or EC [Built-in] | Data Protection
16. Keys should have more than the specified number of days before expiration [Built-in] | Data Protection
17. Keys should have the specified maximum validity period [Built-in] | Data Protection
18. Keys should not be active for longer than the specified number of days [Built-in] | Data Protection
19. Keys using RSA cryptography should have a specified minimum key size [Built-in] | Data Protection
20. Secrets should have content type set [Built-in] | Data Protection
21. Secrets should have more than the specified number of days before expiration [Built-in] | Data Protection
22. Secrets should have the specified maximum validity period [Built-in] | Data Protection
23. Secrets should not be active for longer than the specified number of days [Built-in] | Data Protection
24. Key Vault - Diagnostic Settings DINE [Custom] | Monitoring and Threat Detection
25. Key Vault - Diagnostic Settings AINE [Custom] | Monitoring and Threat Detection
26. Key vaults should have soft delete enabled [Built-in] | Backup and Recovery
27. Key vaults should have purge protection enabled [Built-in] | Backup and Recovery

I hope you enjoyed this blog post on ‘How to secure Azure Key Vault?’. In the future, I will be writing new blog posts, covering other Azure services. So, if you have any questions or comments, feel free to reach out!