Share via

Azure Key Vault : Overview

  • Article

Introduction

Security is one of the biggest concerns for any organization, and with the advent of Cloud Computing and Hybrid Infrastructure; Security is probably the biggest concern. A breach is security and compliance can impact organizations reputation, business and it can also invoke legal issues.

One of the major aspects of security is managing credentials. Every organization needs to manage a few hundreds or thousands of credentials, which include Passwords, Encryption keys, Connection Strings, Digital Certificates, etc.

In many organizations, this sensitive information is not managed properly. Some of the examples are:

  • Passwords are not stored in a central repository and are often hard-coded within program.
  • Database connection strings are hard-coded within the program.
  • When an employee leaves the organization who knows many critical passwords and secrets, it is difficult to change those as they are not centrally managed.
  • In the case of any security incident, response time becomes higher as there is no central place to monitor and troubleshoot.
  • The auto-renew policy is not configured for digital certificates, which often leads to outages related to an expired certificate. This also spoils organizations reputation and brand value.

The goal is to store all credentials in a secure repository, from where we can manage those through a single console.

Management tasks include:

  • Securely store all credential in a central repository.
  • Configure access to the safe repository.
  • Keep credentials out of the code.
  • Auto rotation of credentials after a certain interval.
  • Auto-renewal of digital certificates before they expire.
  • Deny access to all credential when an employee moves out of the organization or role changes.
  • Backing up credential and storing the backup in a secure location.
  • Manage resiliency of the credentials keeping any possible disaster in mind.
  • Monitor the repository on a regular basis.

Azure Key Vault is a managed service offered by Microsoft, where the organization can securely store all the credentials in a safe repository and perform above-mentioned management tasks.

Please note that Microsoft does not see or extract the keys and secret which are stored within a key vault.

Azure Key Vault Objects

1) Secrets :

Using Azure Key Vault, we can securely store secrets like passwords, connection strings, API keys etc. Secrets are octet sequences, with a maximum size of 25 KB each.

Inside Key Vault, Secrets are stored in an encrypted format.

Example of Secret: 1) Password for PFX files 2) Storage Account Access Keys.

The main reason behind storing secrets in Key Vault is to decouple them from the application. A typical example is web.config file, where we often store database connection strings. Now we can securely store these strings in Key Vault and the application/config files can access it from Key vault as and when required. In short, we call it “Keep your secrets out of your codes”.

2) Keys :

Key management is one of the weakest links in any encryption. Often, we choose weak encryption algorithms which are easy to decrypt.

Using the Azure Key Vault, we can store encryption keys in a secured manner, and restrict the access. Those keys are used to encrypt data, or they are used to encrypt another key (typically, Symmetric Key).

Azure Key Vault can store Cryptographic Keys (used for encryption) and also Azure Storage Account Keys. When Azure Storage Accounts keys are stored within Key Vault, the Key Vault will internally sync with Storage Account and will auto-rotate the keys.

  • Azure Key Vault can encrypt Symmetric Keys as well as Asymmetric Keys.
  • When the key in Key Vault is asymmetric, key encryption is used. When the key in Key Vault is symmetric, key wrapping is used.
  • Cryptographic keys in Key Vault are represented as JSON Web Key [JWK] objects.
  • Key Vault supports RSA and Elliptic Curve keys.

RSA Key sizes: Key Vault supports RSA keys of sizes 2048, 3072 and 4096

EC Key types: P-256, P-384, P-521, and P-256K (SECP256K1)

3) Certificates :

Azure key vault can generate an X.509 certificate and can also manage lifecycle management. When Azure Key vault creates a certificate, it stores the certificate private key as keys and stores the password as Secret.

Please note that Key Vault does not act as a Certificate Authority (CA). It does not issue a certificate, and it does not resell certificates from Public CAs. Key Vault automates the Certificate lifecycle management, including enrollment and renewal of Certificates from Public CAs.

I have added a separate section in this article, which covers the details of certificate management through Key Vault.

For more insight on keys, secrets, and certificates, please click this link.

↑ Back to top

Key Vault Authentication

As Key Vault stores all the credentials, it is very critical that authentication and authorization are tightly controlled. A Caller (User or Application) must authenticate to the key vault, and after successful authentication, the vault checks the access policy or RBAC to grant/deny the access as per the policy.

Microsoft recommends using Managed Identities for Azure Resources for Key Vault authentication. This is the most secure and recommended method for Key Vault authentication. In this method, an Azure Resource is registered to Azure AD and gets an Identity. That identity is used to grant access to the secrets within key vault. For an application which is running within an Azure VM, the VM itself is registered with Azure AD and gets an Identity.

I have published an article related to Managed Identities for Azure Resources, which you can refer for further reading.

For more insight into Key Authentication, please read this article.

Key Vault Authorization

As mentioned before, Key Vault has two planes, Management Plane and Data Plane. For Authorization, Management Plane uses RBAC and Data Plane uses Access Policies.

1. Management Plane (For Key Vault): Using the Management Plane, we can control the access of the Key Vault itself using Azure Resource Manager RBAC. The operations include creating the vault, deleting the vault, setting access policies, etc.

Azure has a built-in RBAC Role Key Vault Contributor, which have access to the management plane. Therefore, any user who is assigned this built-in role, can manage the entire Key Vault, including deletion of vault.

It is also very important to note that if a user has contributor permissionson Key Vault, the user can grant himself/herself access to data plane and access keys & secrets within the key vault. For Example, a user who is assigned Key Vault Contributor role or contributor role, has the privilege to modify access policies in dthe ata plane.

2. Data Plane (For Keys & Secrets): This area is for the Keys and Secrets management which are stored within the vault. This is not managed through RBAC, but key vault Access Policies. 

Access Policies for Keys Access Policies For Secrets
Decrypt, Encrypt, UnwrapKey, WrapKey, Verify, Sign, Get, List, Update, Create, Import, Delete, Backup, Restore Get, List, Set, Delete

For more insight on Authorization, please read this article.

VNET Service Endpoint and Key Vault

In the previous section, we have discussed how we can secure the Key Vault using Authentication and Authorization. On the top of that. Azure VNET endpoint offers an additional layer of security to restrict access to the Key Vault.

When we enable this feature, only users from a particular Azure VNET can access the Key Vault. Any access request outside that VNET would be denied by the Key Vault. We can restrict the access further, by allowing only specific IPv4 ranges within that VNET to access the Key Vault.

There is an exception for this rule. If a user has opted-in to allow trusted Microsoft services, connections from those services are allowed through the firewall, even if it is coming from a different VNET or IP range. However, this is not a security risk , as those users still need to go through an uthentication and authorization process which we have mentioned before.

For more information, please refer this article.

Key Encryption Key

We can encrypt a data using Azure Key Vault, and store the encryption key within the vault. These types of keys are known as Content Encryption Keys (CEKs) or Data Encryption Keys (DEKs).

Alternatively, we can also encrypt another encryption key and store it within Key Vault. In this case. The second key is called as Key Encryption Keys (KEKs).

Here is how the DEKs and KEKs are used together:

  1. We encrypt data/content using Data Encryption Key (DEK). This is typically a symmetric key.
  2. We encrypt the DEK using a Key Encryption Key (KEK), using Asymmetric Encryption. This KEK can be generated by Key Vault or can be imported to Key Vault.
  3. As KEK is Asynchronous, it uses a Private-Public Key Pair. The private portion of the key is always kept within the key vault HSM at rest.
  4. The Public Key of KEK can be cached by the client system.
  5. While decrypting the DEK, a request is made to Key Vault.
  6. Once the caller is authenticated and verified by a key vault, it uses KEK to decrypt the DEK.
  7. For software backed keys, the encryption and decryption happen in an Azure Service VM.
  8. For HSM backed keys, the encryption and decryption happen within HSM.
  9. Once DEK is retrieved, it is used to decrypt the actual content.

Typically, Data / Content encryption keys are Symmetric.

Once the content is encrypted using DEKs, it can be encrypted using KEKs, which is Asynchronous type of encryption.

Also, most of the time DEKs are stored as Secrets, where-as KEK is always stored as Keys within Key Vault. For example, Azure Disk Encryption keys like Bitlocker & DM-crypt are stored inside Secrets within the Key Vault.

Types of Keys

There are two different types of Keys available:

1) Software Protected: Software Protected keys are stored inside an HSM at rest. However, the cryptographic operations are being performed by software running within an Azure Service side VM.

2) HSM Protected: The key vault keys are generated and protected by HSM, which is a hardware device. The HSM protected keys never leave the HSM Protection boundary. The keys are stored within HSM at rest, and the cryptographic operations happen within HSM.

It is important to note that for both the cases, the keys are stored within HSM at rest. In the case of software keys, the cryptographic operations are performed at the software level (not within HSM). But HSM protected keys never leave HSM boundary and all cryptographic operations are performed within HSM.

A recommended approach is to use HSM Protected Keys for Production, and Software keys for Dev-test.

A Key Vault Key can be created by the PowerShell command Add-AzureKeyVaultKey.

The -Destination switch defines whether it would be a software key or HSM backed key.

-Destination software: Software Key
-Destination HSM: HSM protected key

↑ Back to top

Hardware Security Module (HSM)

In order to understand Key Vault, we need to understand HSM.

**HSM is a tamper proof hardware device which is specifically designed to securely store cryptographic keys. **

• Keys can be generated within HSM, or they can also be securely imported to HSM. 

• The keys which are generated or imported to HSM never come out of HSM boundary, and it is not possible to extract / decrypt those keys using any tool or program. Although those keys cannot be decrypted, but those keys can be used to encrypt and decrypt other keys and secrets which are stored within Key Vault.

• Keys which are stored within HSM comply with FIPS 140-2 Level 2 security standard, which is a US Government Computer Security Standard.

• Microsoft uses Thales hardware security modules. 

Azure Dedicated HSM

Some organizations have more stringent security requirement, and need to comply with FIPS 140-2 Level 3 Security Standard. For such organizations, Azure dedicated HSM is the solution.

For dedicated HSM, Microsoft uses the SafeNet Luna Network HSM 7 (Model A790) appliance from Gemalto.

Benefits of dedicated HSM Service:

  • While Azure Key Vault HSM complies with FIPS 140-2 Level 2 security standard, dedicated HSM complies with FIPS 140-2 Level 3.
  • Dedicated HSM offers single tenancy, which means the HSM will not be used by any other organization.
  • Dedicated HSM offers full administrative control.
  • The Gemalto device which Microsoft is using for dedicated HSM is a high performance, low latency device.

It is important to note that dedicated HSM is not the best solution for all types of scenarios. As Microsoft has mentioned, Azure Dedicated HSM is not a good fit for the following type of scenario:

Microsoft cloud services that support encryption with customer-managed keys , such as Azure Information Protection, Azure Disk Encryption, Azure Data Lake Store, Azure Storage, Azure SQL Database, and Customer Key for Office 365.

So before finalizing the deployment of dedicated HSM, please evaluate the scenario carefully and ensure that dedicated HSM is the right solution.

However, dedicated HSM is the only solution to meet FIPS 140-2 Level 3 security standard.

For more information on dedicated HSM, please refer to this page.

Azure Key Vault Tier

Azure Key Vault offers two tiers:

Standard: Standard SKU supports only Software Protected Keys, and does not support HSM Protected Keys.

Premium: Premium SKU supports both software and HSM protected keys. If you want to use HSM Protected keys, you need to choose Premium SKU.

A full comparison of these two SKUs is available here.

Security World

As mentioned above, the Azure Key Vault uses a pool of HSMs. But the contents of those HSMs never leave their Geographic boundaries.

All HSMs within a geographic region replicate to each other and share the same cryptographic boundary. As Microsoft uses Thales HSM devices, this boundary is called Thales Security World or simply Security World.

Two HSMs in different geographic regions will never replicate to each other.

Example: East US and West US shares the same Security World, as they are part of the same geographic region.

For more information, you can refer to this link.

Object Management and Versioning

Key vaults support object versioning feature.

Inside Key Vault, every object version (Keys, Secrets, certificates etc.) get a unique identifier and URL.

When a new object is created, it gets a unique version identifier and is treated as the current version. If a new instance of this object is created, the new version becomes the current version. The old version will still be there in the key vault, with a unique version identifier and URL.

By default, when an object is addressed without any version ID, it will go to the current version which is the latest version. If we need to access any version other than the current version, then we have to mention the version specific identifier.

Please refer to this article for more insight on object identifier and versioning.

↑ Back to top

Backup, Restore and Soft Delete

As we discussed in the last section, Key Vault offers built-in resiliency by replicating vault contents within Security World.

In case of any regional outage, Key Vaults in other regions (within security world) will take over but offer only read-only operations.

In case we want to take a backup of the vault and its contents that can be done using Azure PowerShell or Azure CLI. However, the PowerShell or CLI commands only backup individual item, there is no single command to backup all keys and secrets within a Key Vault. If we want to achieve that, we need to prepare PowerShell script.

Backup and Restoration between Key Vaults work when both these conditions are true:

  • Both the Key Vaults are part of the same geo-location.
  • Both the Key Vaults are part of the same Azure subscription.

Basically, Key Vault allows exporting Keys, Secrets, Certificates and Storage Account Keys in a secured manner. The keys and secrets are not visible during the export as they are protected.

You can refer to this blog for more insight.

In addition to High Availability and Backup, Azure Key Vault also offers a feature called Soft Delete.

Imagine a scenario where someone (intentionally or accidentally) deletes an important Key, or in the worst case, an entire Key Vault! Also, assume that backup is not available for that vault.

Keeping such a scenario in mind, Microsoft offers Soft Delete feature. When Soft Delete feature is enabled for the vault, any deleted Key/Secret or an entire vault can be recovered within 90 days of deletion.

  • When a new Key Vault is created, Soft Delete is enabled by default. If you want to create a Key Vault without Soft Delete, you have to use Azure PowerShell or Azure CLI.
  • By default, the deleted keys or vaults are permanently deleted after 90 days and can no longer be recovered.
  • During that 90 days period, we can recover it or purge (delete) it permanently.
  • Using soft delete, keys and secrets can be recovered within the same vault. You cannot recover keys and secrets to a different key vault using the soft delete feature. For that, you need to use backup and restore method mentioned above.

For more insight of soft delete feature, please refer to this blog. You can also refer to this Microsoft document.

Key Vault Resiliency

Azure Key Vault is a Highly Available Service, which can also sustain a regional failure. Key Vault contents are securely replicated to other Key Vault within the same Geography. 

In case of a Key Vault failure or a regional outage, another Key Vault will take over automatically and will work in read only mode. During that outage, you cannot make any change in the key vault contents, as the secondary Key Vault will operate in read only mode. Once the issue is resolved, Primary Key Vault will automatically take over. No user intervention is required in this entire operation.

For more insight, you can refer this article.

Key Vault and Azure Backup

Azure Backup supports backing up those Azure VMs, where OS and data disks are encrypted with Azure Disk Encryption (ADE). Sometimes a Key Encryption Key (KEK) is being used in conjunction with encryption secrets, which adds an additional layer of security. 

Azure backup supports backing up encrypted VMs, both with or without KEKs. However, to do so, Azure Backup needs to have access to the Key Vault to read encryption keys and secrets.

If no KEK is being used, access to key vault Secrets is enough. However, if KEK is used in conjunction with ADE, then Azure backup needs to access both Secrets and Keys. Please follow this article for the required steps to configure the permission.

Please note that backing up encrypted VMs using Azure Backup has got some limitations.

Please refer this article for more details.

Key Rotation

Without a centralized Key Management System, it is very difficult to rotate keys and secrets as these are scattered and are hardcoded into many codes.

With Azure Key Vault, Key rotation is much simple as all the keys are managed centrally and are not hardcoded into programs. We only need to regenerate and update the key in one place (Key Vault), and applications will automatically get the updated key. That way, we can easily prevent misuse of a leaked key and comply with the organizations security standard.

There are multiple ways we can automate the key generation and rotation after a specific interval of time. The most preferred way is to use some automation script (Ex: PowerShell) through Azure Automation.

To allow Azure Automation to set secret values in your key vault, you must get the client ID for the connection named AzureRunAsConnection, which was created when you established your Azure Automation instance.

For more details, please refer to this document.

Key Vault Logging

As Key Vault is a critical part where all the Secrets, Keys and Certificates are stored, it is important to monitor the Vault on a regular basis to understand who is accessing Key Vault and for what purposes.

Key Vault logging is not enabled by default, and we have to enable it manually. When we enable logging, it will ask in which storage account logs will be stored. Once we specify the storage name, it will automatically create a container named insights-logs-auditevent . We can store logs of multiple key vaults inside this container.

The logs are stored in JSON format, in UTC time zone. You can use Azure Log Analytics to interpret the logs.

For more information on Key Vault Logging, please refer to this link.

To know how to use Log Analytics with Key Vault, please refer to this link.

Managing Certificates with Key Vault

As mentioned earlier in this article, we can manage Digital Certificates using Key Vault. One of the biggest advantage of managing certificates through Key Vault is the Private Key of the certificate is never exposed outside the Key Vault Security World.

You can create the certificate using a key vault by generating a Certificate Signing request (CSR). At the time of CSR generation, the Private Key would be stored within Key Vault, and Public Key would be attached to CSR and submitted to the CA. Upon receiving the certificate from the CA, you have to import it to the Key Vault. During Import, the Public Key (attached with the certificate) would be matched against the Private Key (stored within Key Vault) to complete the Key Pair.

You can also import existing Certificate to Key Vault using a PFX or PEM File. The PFX / PEM file contains the Private Key as well as Public Key, so you should immediately delete the PFX / PEM file once it is imported to the Key Vault.

Azure Key Vault does not act as a Certificate Authority (CA). However, to make the Certificate Management experience better, Microsoft has partnered Azure Key Vault with some leading CAs like DigiCert and GlobalCert. You can request OV or EV SSL Certificates to these partnered CAs dthrough Azure Key Vault.

But that does not mean you cannot manage certificates issued by other CAs through the Key Vault. Even if the CA is not partnered with Azure Key Vault, that would not prevent you to manage the certificate by Key Vault.

You can refer this article, where this topic has been discussed more elaborately. 

Apart from Certificates issued by CAs, you can also create Self-Sign Certificate using Key Vault. In the case, the certificate is signed by its own Key and not any CAs Key.

Azure Key Vault supports Certificate Policy, which defines all the rules associated with the lifecycle of a certificate including Certificate type, key length, pre-expiry alerts and renewal policy. For a new certificate, you have to define a certificate policy. If you are importing an existing certificate to key vault, the default policy is associated with it. If a certificate has multiple versions available within the key vault, there is only one single Certificate Policy associated with all versions of that Certificate.

Key vault also supports auto renewal of the certificate, depending on the certificate policy associated with it. If the action type is emailContacts, it will just notify the contact person about the upcoming expiry. If the action type defined is autoRenew, the key vault will try to renew the certificate.

A Key Vault Certificate can be retrieved as a Secret. However, whether Private Key would be part of the retrieved secret or not, depends on the Certificate Policy. If the policy says that the Private key is exportable, then it would be part of the retrieved secret. If the policy defines the private key as non-exportable, then the Private Key can never be exported and it would not be part of the retrieved secret.

You can get more information in this link.

Pricing

Azure Key Vault comes into two flavors, Standard and Premium.

Premium Edition supports HSM Protected Keys and advanced key type, which Standard Edition does not support.

For a full comparison and pricing details, please refer this link.

References

 

↑ Back to top