In this post, I will tell you about a service in Azure called Key Vault, which you can think of as secret storage/handling-as-a-service.
It’s probably fair to say that a concern that most prospective and current cloud customers have is secrecy. Some things must not be known outside of an organization. Sometimes secrets must not be known by more than a few people. Some secrets must be kept in the cloud:
Microsoft introduced Azure Key Vault to handle these kinds of secrets. When it launched, it seemed like a service that I would have little to do with. But more and more, Microsoft is finding more ways to use Key Vault, making the service one of the things that are hard to avoid in Azure.
Any secrets that you generate or store in Key Vault are kept in the same physical data centers as the applications that have stored and are using the secrets. That provides you with performance. But much like with many systems in Azure, the vaults are replicated within the region and also to the documented paired region. This is a twinned region, at least 150 miles away, and normally in a similar regulatory zone such as in the EU or in the USA. In the event of a region failover (I haven’t witnessed one yet), it can take a few minutes for the key vault to come online in the paired region and the secrets will be in read-only mode. A fail-back can occur and then the vault returns to read and write mode.
In the USA, Federal Information Processing Standards (FIPS) is considered an important measuring stick for security. Microsoft has two levels of certification based on how you store a secret in Key Vault. The support levels available depend on the tier (price/features) of key vault that you deploy.
A Standard tier key vault only supports software keys. These are processed inside of cryptographic modules with FIPS 140-2 Level 1 validation or higher. A Premium tier key vault also offers hardware keys. In this case, a hardware security module (HSM) validated to FIPS 140-2 Level 2 or higher will handle the secrets for you.
A key vault has its own permission system for the contents, independent of what is done at the resource or resource group level. When you create a key vault, you will define a default administrator, who has a set of key permissions, secret permissions, and certificate permissions. This means that only a subset of Azure administrators/developers/operators can manage or even see the secrets that are stored in the vault.
Let’s say that you wish to build an online application that requires a set of encryption keys for handling data transfers securely. Typically, those secrets are stored with the application, leaving them vulnerable to theft and misuse by a hacker. If you use Key Vault, the keys are stored in key vault, not with the application. The application is provided with a URI to access the keys and use them, effectively allowing the developer to treat the code as being somewhat untrusted. This is the same sort of approach that the same developers use for credit card payments, using an API to offload payments to a more trusted handler.
After I started to look at Key Vault, I realized that I should have been using this service for years and I have to start telling my customers about it. For example, without doing any PaaS or development, I can store secrets (text) very easily in a key vault and make them available to me at any time:
Examples might be:
These are simple secrets that are easily created in the Azure Portal and will improve how most admins are keeping these secrets today (a spreadsheet or Word document).