Today I Learned Cloud

Is Azure key vault secure?

Most developers need a secure place to store application secrets, service passwords, encryption keys, TLS/SSL certificates and other secure information outside of the application source code. There are many options available. Microsoft Azure Key Vault is one of them.

Is Azure key vault secure? Microsoft Azure Key Vault is designed in a way that prevents Microsoft from ever seeing the raw keys or secrets. The private data is processed with FIPS 140-2 level 2 validated HSMs. Multiple permission points must be passed to retrieve any secret information. Any access can be logged for review.

But knowing this, what type of secret information can be stored within Microsoft Azure Key Vault? How is the secret information extracted by authorized users or applications from Key Vault?

Azure Key Vault Access Restrictions

There are several security based mechanisms which are put in place to prevent just anyone from accessing the secret information contained within an Azure Key Vault account in the Microsoft data centers. The actual process of getting the secret information out of Key Vault can seem quite involved when first looking at it, but is quite trivial for a well written application or library.

The first step in accessing this secret information is to first have the user, or client application, authorize themselves with Azure Active Directory. This request must specify the Azure Key Vault account to which the requests are going to be targeted at. The goal of this initial step is for the callee to get an OAuth token with enough permissions so that it can be used to make requests against the Azure Key Vault API. If the user, or client application, can’t successfully retrieve this token, they will be unable to retrieve any secret information from the Azure Key Vault account.

The next step is for the client to make a request to the Azure Key Vault service, however this request must go through the firewall configured on the Azure Key Vault account. If the Key Vault service detects that the request is coming from an unauthorized location or address, it will be denied. If the request is from a firewall approved location, the Azure Key Vault service will then check the OAuth token received and validate it with the Azure Active Directory service. Only once validated with the Key Vault service will the Key Vault service then proceed in checking further permission on the request.

If validation has passed up to this point, the Azure Key Vault service will now check the access policy linked to the identity making the request. It will confirm that the identity is allowed to access the secret, key, or certificate that is requested in the API call, and it will also confirm that the type of request is permitted. For example if a read request was sent to the Key Vault service but the calling identity does not have read permission on the given secure object, access will be denied.

Only after going through all these hoops, and passing all of the security requirements involved will the Azure Key Vault service then send back the requested secret information to the calling user or application. Again this may sound like a time consuming process, but for most systems or applications it is a trivial process to go through.

Azure Key Vault - Secrets, Keys, and Certificates

There are several types of private information that can be stored within Azure Key Vault. This includes secrets which are usually considered to be passwords or auth tokens that an application may be required to know when running in normal operation. However a developer shouldn’t store the raw password or token in the application source code, or even in a config file with the application. Using something like Azure Key Vault to request the password or auth token when required is the preferred way to go.

Another type of secret information that can be stored within Azure Key Vault are encryption keys. These keys are not something that you would normally want to have publicly exposed, because once they are, anyone with the key can use it to decrypt anything that was encrypted with that same encryption key. Storing your encryption keys in something like Azure Key Vault would be an ideal place to put it. Only when an application needs to encrypt or decrypt some data to do its job should the encryption key be read from KeyVault, and only by an authorized user or application.

The final type of secure data that most developers will come into contact with at a certain point is SSL or TLS certificates. These are mainly used to secure website traffic so that computers or devices in the path of a source machine and target website can’t understand the data that is passing between the two locations. This is heavily used for financial transactions that happen online.

Azure Key Vault can securely store and maintain these secure certificates within its service. Once there, an authorized service or application can load the certificate information on startup to provide secure connections between itself and other endpoints on the web. When a certificate expires, the secure data for the certificate can be rotated out with a newly generated certificate. After this is updated, the application or service can load the new certificate and continue operating as normal.

Key Vault Properties

Several other features that are supported by Azure Key Vault help make things more secure as well. These include things like versioning of secrets. This allows for updating the value of a secret stored inside Azure Key Vault without losing the old secret data. There can be many versions of the same secret stored within Key Vault.

Taking the versioning a step further, the secret data can be disabled from being accessible to even authorized users. So if a secret is updated with a new value, creating a new version, an authorized Key Vault user can disable the previous version inside Key Vault. This means that the old secret value is no longer retrievable as a secret from the vault, and only the newer enabled secret may be retrieved.

Another feature available to secrets stored within Azure Key Vault is the ability to configure an expiration date on the secrets. Once an expiration date is set the secret information will be valid until that date and time. After the expiry has passed, the secret information will no longer be retrievable from the Key Vault service unless the secret item is updated by an authorized user.

A great feature that is not directly part of Azure Key Vault, but more of a companion to it, would be the Azure Logging capability that can be attached to the Key Vault service. Azure Logging can be enabled so that any access to the Key Vault, read or write, will be detected and tracked for future review. This is especially useful during audits, or for leaving a security trail that can be analyzed to determine who might have gotten access to which service and when.

The logging can even be enhanced a bit further with Azure Alerts. This can be setup so that based on custom configured rules, an alert can be triggered to notify the proper individuals of certain conditions that have happened on the Azure Key Vault based on the data that was logged. This can help identify security issues very early on, and potentially save time and money tracking things down later.

Azure Key Vault also offers very granular access control permissions to the different types of secret data. For example looking at the Secrets component of Azure Key Vault, there are the following permissions: get, list, set, delete, recover, backup, restore, and a privileged permission of purge. All of these can be enabled, or disabled, for a specific user or application within Azure Active Directory. This can be done via the Azure Portal, the Azure Command Line Interface, or with Power Shell modules designed to work with Microsoft Azure.

Based on all of the above information and details, I think it is safe to say that there is a lot going for Microsoft Azure Key Vault to claim that it is a secure service provided by Microsoft.