Azure Key Vault:- 5 ways to secure

Using Azure Key Vault to store your secrets , encryption keys or even certificate data? Have a read of this blog, I will be discussing 5 ways on how to secure your Key Vault from network restriction to key rotation. As mentioned by Microsoft, access to a key vault is controlled via two types of interfaces/planes as mentioned below:

Access to a key vault is controlled through two interfaces: the management plane and the data plane. The management plane is where you manage Key Vault itself. Operations in this plane include creating and deleting key vaults, retrieving Key Vault properties, and updating access policies. The data plane is where you work with the data stored in a key vault. You can add, delete, and modify keys, secrets, and certificates.

docs.microsoft.com

The five areas that I will be discussing:-

  1. Access Control (IAM)
  2. Access Policies
  3. Network restriction
  4. key rotation
  5. Monitoring

Lets create a Key Vault

$resource_group = "tamopskv"
$keyvault_name = "tamopskvtest"

New-AzureRmKeyVault -VaultName $keyvault_name -ResourceGroupName $resource_group -verbose -location "east us"

1. Access Control (IAM)

What is IAM?

Access Control (IAM) is the access control used to manage and access Resources within Azure, usually defined in a granular way with least-privileged access being used at all times.

Have a thought, does all your account admins need to be Subscription owners? Owners let you manage everything, including access to all resources including accessing and viewing Key Vault secrets!

The recommended IAM role

I would recommend at least using role based access for resources, you can create custom based access roles but the built in role-based access is usually suffice.

The built-in role for Key vaults is Key Vault Contributor, “lets you manage key vaults, but not access to them” . This is the recommended role users should be if they do not require access to the Key Vault secrets/keys. Further details on this role here

2. Access Policies

Now that we have looked at the resource access control side (management plane), lets look at Key Vault Access Policies. (data plane) as mentioned above “The data plane is where you work with the data stored in a key vault”

Ensure you have reviewed your Access Control polices for the subscription, owners & contributors can allow themselves access to the data plane of a Key Vault!

What is a Key Vault Access Policy?

A Key Vault Access Policy is a permission or set of permissions assigned to a subscription user or managed identity that will allow that specific access to potentially read, write or even delete secrets and keys.

Adding a user to a Key Vaults Access Policy

Select required Key Vault and Access Policies

Select Add new

Add Access Policy

Configure from template: A list of predefined management options, have a review of these as one of these may be what you require, Remember:- Least priviledged access!
Select principle: Select User, resource principle or Application managed identity

Thinking a more manual access policy to fine-tune the defined access? Select custom Key, secret and certificate permissions!

Authorized application: “Authorizes this application to perform the specified permissions on the User’s or Group’s behalf.”

Apply the policy

Got users already in the access policy? Review their access!

One last thing, you may have noticed “Click to show advanced access policies” within the Key Vaults access policy

Available options in advanced access policies:-

  • Enable access to Azure Virtual Machines for deployment: Specifies whether Azure Virtual Machines are permitted to retrieve certificates stored as secrets from the key vault.
  • Enable access to Azure Resource Manager for template deployment: Specifies whether Azure Resource Manager is permitted to retrieve secrets from the key vault.

3. Network Restriction

In most circumstances your Key Vault endpoints do not need to be open to the public internet, reviewing and adding network restriction(s) are recommended from a security perspective.

Firewalls and virtual network restrictions are split into three areas

  • Virtual Networks: Azure vNET related restrictions
  • IPv4 Address or CIDR: Public addresses or CIDR
  • Allow trusted Microsoft Services

Lets have a look

Select Firewalls and virtual networks

Virtual Networks

Within this, you can restrict Key Vault endpoints to specific Azure Virtual Networks and even more specifically to subnets on them networks, snippet below is an example of this

Within the snippet I am allowing access to the endpoint from virtual network: tamopsvnet and subnet: default only

This can be applied for multiple Azure Virtual Networks if required.

IPv4 Address or CIDR

Add a list of public IPV4 Addresses or CIDR’s that will require access to the Key Vault end points.

Allow trusted Microsoft Services

See below, the list of Trusted Microsoft services if this option is selected

Trusted Microsoft services include:
Azure Virtual Machines deployment service
Azure Resource Manager template deployment service
Azure Disk Encryption volume encryption service
Azure Backup
Exchange Online
SharePoint Online
Azure Information Protection
Azure App Service: Web Apps
Azure SQL
Azure Storage
Azure Data Lake Storage
Azure Databricks
Azure Machine Learning Service

portal.azure.com

4. Key Rotation

I will only touch on this area, as it can be quite complex and numerous factors need to be considered before a successful key rotation can be in place, factors include:

  • How will the application react to a new key?
  • Expiration dates to be considered
  • Will it be an automatic or manual process?

A thorough blog on key rotation and code examples

For this blog, lets look at an example of creating a new key with expiration date and showing how to create a new version of the key

Lets create

Select Keys

Select Generate/Import


  • Options: Select generated
  • Name: Enter key name
  • Key Type and RSA Key size default for this example
  • Next, look at the activation settings – can have a timestamp for both activation and expiration date. Need a temporary key? A great example!

You will now have created a key which you can view to get the key end point and other various options as below, expiration date can also be changed on the fly along with permitted options

Need a new version of the key? (Key rotation starting…)

Inside Key settings, select New Version


Follow same configuration setup as before, you will end with a current and older version of the key.

5. Monitoring and Logging

Now that you have your Key Vault and configured more securely, monitoring and logging setup will be beneficial as you will want to know who or want is accessing your key vault and when.

Activity Log

Wanting to know what was accessed and when? Have a look at the activity log.

Full audit trail available of Key Vault Operations, within here you can drill down to the json to see what was specifically accessed.

Metrics

Start of with Overview

From there you can begin to drill down into available metrics provided by Azure for Key Vault

Alerting

Want to know when something abnormal happens in your activity log or spike in a metric? Add relevant alerts. Azure provide a great baseline on configuring an defining alerts.

Example below of the available definitions


This is found within Alerts



Select New alert rule

From there, within conditions you can browse from the defaults as shown above.

Diagnostics settings

Lastly, turning on diagnostic settings allows you to collect the following :-

  • AuditEvent
  • AllMetrics

From this, you can create custom dashboards and even further alerting if you send this data to Log Analytics

Select Diagnostic settings

Select Turn On

As per below, select where you want the logs to appear or stream to

This is now the finish, I hope you have enjoyed this blog into securing your Azure KeyVault! Any queries? Give me a shout on Twitter!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: