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:-
- Access Control (IAM)
- Access Policies
- Network restriction
- key rotation
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
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:portal.azure.com
Azure Virtual Machines deployment service
Azure Resource Manager template deployment service
Azure Disk Encryption volume encryption service
Azure Information Protection
Azure App Service: Web Apps
Azure Data Lake Storage
Azure Machine Learning Service
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
- 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.
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.
Start of with Overview
From there you can begin to drill down into available metrics provided by Azure for Key Vault
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.
Lastly, turning on diagnostic settings allows you to collect the following :-
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!