Ensure Success by Learning Azure Key Vault Best Practices

Published:13 September 2022 - 12 min. read

Azure Cloud Labs: these FREE, on‑demand Azure Cloud Labs will get you into a real‑world environment and account, walking you through step‑by‑step how to best protect, secure, and recover Azure data.

Protecting your data in the cloud can be worrisome when you don’t use any service to keep your secrets safe. The good news is that Azure Key Vaults provide a mechanism for securely storing and accessing secrets. Not sure how the Key Vaults work? No worries! This tutorial has got you covered with Azure Key Vault best practices.

With Key Vaults, you can ensure that only authorized people and resources can access and interact with your secrets. And in this tutorial, you’ll learn to protect your Key Vaults from attacks or unwanted exposures.

Stay tuned so you can keep your secrets, well, a secret (pun intended)!

Prerequisites

This tutorial will be a hands-on demonstration. If you’d like to follow along, be sure you have the following:

  • An Azure AD group where you can assign access policy – This tutorial uses an AD group called Key Vault – Key, secret, and Certificate Manager.

Creating a Key Vault to Use for Azure Key Vault Best Practices

When creating Azure Key Vaults, a best practice is having a separate key vault per application and environment. Separating Key Vaults this way provides the following advantages versus larger, shared key vaults:

  • A security boundary between secrets that have different purposes.
  • Decreases the “blast radius” in the unfortunate case of a security event, such as a malicious attacker.
  • Prevents misconfigured code from accessing secrets meant for another environment.

To create a new Azure Key Vault, follow these steps:

1. Launch your favorite web browser and navigate to the Azure Portal.

2. In the Azure Portal, search for key vaults in the search bar, and choose Key vaults under Services in the search result, as shown below.

Accessing Key Vaults services
Accessing Key Vaults services

3. On the Key vaults page, click on Create to initiate creating a Key Vault.

Creating a new Key Vault
Creating a new Key Vault

4. Now, configure the new Key Vault’s basic settings with the following:

  • Choose an existing resource group or create a new one where this Key Vault will be stored.
  • Specify a unique name for the new Key Vault. Keep in mind that Key Vault names must be globally unique across Azure.
  • Click on Review + Create (bottom-left) to review and validate the settings.
Configuring a resource group and name for the new Key Vault
Configuring a resource group and name for the new Key Vault

5. Verify the validation has passed, and click on Review + Create again (bottom-left) to finalize creating the new Key Vault.

Once created, your browser redirects to the deployment overview page (step six).

Reviewing settings and creating the new Key Vault
Reviewing settings and creating the new Key Vault

6. Lastly, verify that the deployment was completed successfully, and click on Go to Resource to view the new Key Vault.

Waiting for the deployment to complete
Waiting for the deployment to complete

Controlling Access to the Key Vault

Creating siloed Key Vaults is just the first step in protecting sensitive and business-critical keys and secrets. Controlling who and what can access a Key Vault helps ensure that secrets don’t end up in the wrong hands, maliciously or otherwise.

When setting up access to a Key Vault, an important distinction is the differences between Control Plane and Data Plane permissions.

PermissionDescription
Control PlaneLets you manage resources in the Azure subscription, including creating and deleting resources, retrieving the properties of a resource, and configuring role assignments to the resource.
Data PlaneHandles actions that take place within a given resource, such as creating or deleting secrets within a Key Vault.

Read on to see different ways you can control access to your Key Vaults.

Vault Access Policy

With an access policy, you can specify actions that a principal (user, group, service principal, or managed identity) can perform, like for keys, secrets, and certificates. Vault Access Policy enables data plane access to the secrets stored in Azure Key Vaults.

1. From the newly created Key Vault’s page, click on Access policies (left panel) to access the settings for Vault Access Policy.

Navigating to Access Policies
Navigating to Access Policies

2. On the Access Policies page, keep the default option (Vault Access Policy) selected for the permission model and click on Add Access Policy to create a new policy.

Adding an Access Policy
Adding an Access Policy

3. Choose permissions for the access policy depending on your needs.

The Add access policy blade manages three kinds of permissions, Key Permissions, Secret Permissions, and Certificate Permissions.

Selecting permissions for the new Access Policy
Selecting permissions for the new Access Policy

Optionally, select a template from the Configure from template dropdown field, automatically assigning the appropriate permissions across the three categories.

This tutorial uses the Key, Secret, & Certificate Management template.

Configuring Access Policy permissions from a template
Configuring Access Policy permissions from a template

After selecting a template, three dropdown fields automatically populate, as shown below.

Selecting a permission template
Selecting a permission template

4. Now, assign a principal, which can be a user account, Azure Active Directory group, application, or service, to this new access policy with the following:

  • Click the None Selected hyperlink on the Add access policy blade, which opens the Principal blade (rightmost).
  • Search for the AD group or user (key vault) to assign to this policy in the Principal blade’s search bar.

Using Azure AD groups is recommended to prevent the need to update all Key Vaults a user has access to. This behavior occurs whenever their role changes or they move on.

  • Choose your target group or user (as the principal), and click Select.
Selecting a principal for the new access policy
Selecting a principal for the new access policy

Optionally, click on None selected shown below to assign an application that will be authorized to run the tasks specified by the permissions on the user’s or group’s behalf.

Authorizing an application to perform permissions (optional)
Authorizing an application to perform permissions (optional)

5. Click on Add once you’ve specified all permissions and selected a principal.

The new policy appears under the Current Access Policies list (step six).

Adding the new access policy
Adding the new access policy

6. Finally, modify the permissions under Current Access Policies if desired, and click the Save button to save the changes.

Saving the access policy changes
Saving the access policy changes

Azure Role-Based Access Control (RBAC)

RBAC for Key Vaults is an alternative to the Vault Access Policy model. This access control is built on the Azure Resource Manager, which lets you configure access across resources in Azure.

This feature allows permissions to secrets, keys, and certificates to be managed using Role Assignments under Access Control (IAM). In this example, you’ll update an existing Key Vault to use Azure Role-Based Access Control.

1. Navigate to the Access Policies page again as you did in steps one to two of the “Vault Access Policy” section. But this time, choose Azure Role-Based Access Control for the Permission model and click Save to save the changes.

You’ll see that the Current Access Policies section is replaced by an information message that says access policies are now being managed under the Access Control (IAM) blade.

There will be a WARNING that says changing the permission model may impact any existing permissions. So, proceed with caution if this is not a new Key Vault.

Switching to Azure Role-Based Access Control
Switching to Azure Role-Based Access Control

2. Once saved, click on Access control (IAM) on the left panel to access the page where you can manage IAM access.

Navigating to Access control (IAM)
Navigating to Access control (IAM)

3. Click on the Role Assignments tab to view the current role assignments, as shown below.

Accessing the list of role assignment
Accessing the list of role assignment

4. Now, click Add → Add role assignment to configure a new role assignment for this Key Vault.

Adding a new role assignment
Adding a new role assignment

5. On the Add role assignment page, search for key vault, select Key Vault Reader from the result list and click Next.

Choosing Key Vault Reader gives the member(s) assigned to this role assignment access to see the Key Vault at the Control Plane level.

Searching for the Key Vault Reader role
Searching for the Key Vault Reader role

4. Add members to this role assignment with the following:

  • Select User, group, or service principal under Assign Access to.
  • Click Select members, and the Select Members blade (rightmost) opens.
  • Search for the group or user to assign to this policy in the Select Members blade.
  • Select your target group or user, and click Select.
Selecting an AD group to assign this role assignment to
Selecting an AD group to assign this role assignment to

7. Once all correct members have been added, click Review + Assign twice to create the new role assignment.

Reviewing and assigning the new role assignment
Reviewing and assigning the new role assignment

8. Lastly, navigate the Access control (IAM) page, and click on the Role assignments tab.

The new role assignment is now listed under Key Vault Reader, as shown below.

Verify the newly created role assignment
Verify the newly created role assignment

Secret Role Assignments

Unlike Vault Access Policies, you can assign role assignments to specific secrets with the Azure Role-Based Access Control for Key Vaults.

When using Vault Access Policies, if a user or principal is given access to view or change secrets, that user will have that same access across all secrets in the Key Vault. This option may be acceptable in certain situations. But there may be a need to set some security boundaries between secrets in a vault.

To configure role assignments for a particular secret, assuming the Azure Role-Based Access Control is enabled on the Key Vault:

1. Navigate to Secrets (left panel), and click on an existing secret to open the secret’s Overview page.

Navigating to an existing secret
Navigating to an existing secret

2. Next, click on Access Control (IAM) on the left panel → Add → Add role assignment to create a new role assignment to apply to the secret selected.

Adding a role assignment to a secret
Adding a role assignment to a secret

3. Ultimately, follow steps five to eight of the “Azure Role-Based Access Control” section. But this time, search for and select Key Vault Secrets Officer role to assign.

The Key Vault Reader role assignment in the Azure Role-Based Access Control section gave the principal read access to secret contents (like metadata) in this Key Vault. But not sensitive values.

Once selected, choose the same AD group to assign the role assignment, and click Review + Assign to validate the settings.

Once the Key Vault Secrets Officer role assignment is created, the users can see the sensitive value of this secret only. The only way they can see other secret values is if a role assignment is created for those specific secrets, creating security boundaries between the key vault’s secrets.

Networking Best Practice

You’ve seen different ways to manage Azure Key Vaults. But there’s another best practice you must know, restricting access to only specified virtual networks or IP addresses.

1. Enable the Azure firewall on a Key Vault:

  • Navigate to the desired Key Vault and click on Networking (left panel) under the Settings section.
  • Click on the Firewalls and virtual networks tab, and select the Selected networks option since you’ll restrict access to specific IP addresses.

Once selected, more options become available, as shown below.

Navigating to the Networking settings
Navigating to the Networking settings

2. Decide whether to add an existing virtual network or create a new one. But for this tutorial, click on Add new virtual network to initiate creating a virtual network.

Adding a new virtual network
Adding a new virtual network

3. Configure the new virtual network on the Create virtual network blade (rightmost) with the following:

  • Specify a descriptive name for the new virtual network (i.e., vnet-01).
  • Address space and Subscription fields will have default values and can be left as-is.
  • Choose a Resource Group where the virtual network will be created or create a new one.
  • Leave the rest of the fields with their default values, and click Create to create and deploy the new virtual network.
Creating the new virtual network
Creating the new virtual network

4. Confirm that the new virtual network is in the list under the Virtual networks section, as shown below.

Confirming the new virtual network
Confirming the new virtual network

5. Next, under Firewall, IP addresses can be added from the public Internet or an on-premises network:

  • For this demo, enter 13.71.199.112/30 (public Azure IP range). The IP address or CIDR field accepts an IP Address or CIDR block.
  • Click the Save button to save the changes.

Verify that vnet-1 is listed under Virtual Networks and the Azure IP CIDR block is listed under Firewall. Now, only traffic that originates from the default subnet in vnet-1 or the public range can communicate with this Key Vault.

Saving the firewall and virtual network changes
Saving the firewall and virtual network changes

Enabling Recovery Options

In the unfortunate scenario that a Key Vault or Key Vault object resource is inadvertently or maliciously deleted, enabling recovery options on the key vault is the best practice. Key Vaults offer both soft-delete and purge protection options to allow objects to be quickly recovered.

Navigate to Properties under the Settings section (left panel) to access the properties of the Key Vault.

Below, you can see that Soft-delete is enabled by default (upon Key Vault creation). When soft-delete is enabled, deleted resources are retained for some time. 90 days is the default retention period, but you can set the value anywhere between 7 and 90 days.

Note that you can only change the retention period during Key Vault creation. Once created, the retention period cannot be modified anymore.

Navigating to the recovery options of an existing Key Vault
Navigating to the recovery options of an existing Key Vault

For new Key Vaults, Soft-delete, Purge protection, and retention period can be configured under the Recovery options section.

Navigating the recovery options when creating a new Key Vault
Navigating the recovery options when creating a new Key Vault

Now, choose the Enable purge protection option, which enables purge protection for the Key Vault, and click Save. Note that once enabled, purge protection can’t be disabled again.

Enabling purge protection lets you avoid losing important data. A mandatory retention period is applied to the deleted Key Vault and Key Vault objects. As a result, a Key Vault or one of its objects (even when deleted) cannot be fully purged until the retention period has expired.

Enabling purge protection
Enabling purge protection

Enabling Platform Logging

Once an Azure Key Vault is created, you need a way to track how and when a Key Vault is accessed. Logging should be enabled to help with this task. Enabling platform logging provides visibility into the operations performed within the Key Vault and can be accessed for troubleshooting purposes.

To enable platform logging on a Key Vault:

1. Click on Diagnostic settings under Monitoring to access the Diagnostic settings page.

Navigating to Diagnostic settings
Navigating to Diagnostic settings

2. Next, click the Add diagnostic setting link to configure logging for the Key Vault.

Adding a diagnostic setting
Adding a diagnostic setting

3. Configure the diagnostic settings as follows:

  • Specify a unique Diagnostic setting name (i.e., KeyVault_Logging).
  • Tick the allLogs box to select all available categories. Logging can then be configured for different categories based on the resource type.

Below are the available options for the destination where these logs will be sent to and stored:

  • Send to Log Analytics workspace – Logs can be stored in an existing Log Analytics Workspace where they can be consolidated, correlated, and queried.
  • Archive to a storage account – Logs can be stored as blob storage in an existing storage account.
  • Stream to an event hub – Integrates logs with third-party Security Information and Event Management (SIEM) tools like Splunk and QRadar.
  • Send to partner solution – Logs can be sent to a partner solution in the Azure Marketplace.

But for simplicity in this tutorial, tick the Archive to a storage account box. In the Storage account dropdown, specify an existing storage account where these logs should be stored, and click Save.

Configuring logs to be archived to a storage account
Configuring logs to be archived to a storage account

4. Lastly, navigate to Containers under the Data storage section (left panel) to see the container called insights-logs-auditevent, where the logs are stored, as shown below.

Navigating to the container where logs will be archived
Navigating to the container where logs will be archived

Backing Up Key Vaults

The recovery options available for Azure Key Vaults helps prevent the loss of sensitive and important data. But backing up business-critical secrets, keys, and certificates when updated or changed is the best practice to avoid possible data loss.

There are some considerations to take when backing up Key Vault objects. Azure does not currently provide a way to back up entire Key Vaults through the portal or command line. So secrets need to be backed up individually if desired.

To back up an existing secret:

1. Navigate to Secrets under the Settings section in the Key Vault dashboard, and click on the secret to be backed up.

2. Next, click on Download Backup to begin the process of downloading a backup of the selected secret.

Downloading a backup of the secret
Downloading a backup of the secret

3. Finally, click Download on the pop-up message to download a backup of the secret.

The pop-up message below explains the secret will be encrypted and can only be restored to another Key Vault in the same subscription.

Note that the secret must be restored in the same Azure Geography. Why? A secret can only be restored in the same country where that secret was backed up.

Confirming the secret backup download
Confirming the secret backup download

The secret will be downloaded as an encrypted block with an extension of .secretbackup, which can only be decrypted inside Azure.

Verifying downloaded backup file
Verifying downloaded backup file

Learn more about backing up and restoring to an Azure Key Vault.

Conclusion

This tutorial’s goal was to demonstrate the Azure Key Vault best practices available in Azure. You learned the importance of separating Key Vaults based on their purpose, the different ways you can configure access policies for Key Vaults, and networking and firewall considerations.

By enabling purge protection, you’ve also protected Key Vaults and resources from accidental or malicious deletion. At the same time, you learned to back up Key Vault secrets.

But the best practices you’ve learned in this tutorial only scratch the surface regarding maintaining safe and secure Key Vaults in your environment. Everyone’s needs are different, so why not dive deeper into all these concepts? Make the right decisions based on your own needs.

Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.

Explore ATA Guidebooks

Looks like you're offline!