Most organizations have secrets, such as private keys and passwords that need to be protected. Many organizations (rightly) are very sensitive to where the secrets are stored, and how they are used. On premises, it’s possible to simply store the keys on a USB drive in a safe, for example, but for larger organizations this isn’t possible, and necessitates the use of a Hardware Security Module, or HSM.
HSMs are an enterprise product, so they adhere to the ‘Call for Pricing’ model. Conveniently, Azure makes available a HSM-as-a-service at an eminently reasonable price.
This is an image of a Thales HSM, which is similar to the device that Microsoft uses in their datacenters.
There are two models for Azure Key Vault – a software HSM, and a true hardware HSM. The software HSM is billed as ‘Standard’. The documentation for Azure Key Vault is currently unclear what kind of architecture this model follows. The hardware HSM is billed as ‘Premium’ and is hosted within customized Thales HSMs. If using a HSM is a requirement, be sure to select the correct SKU, and set the Destination parameter correctly when working with Key Vault.
Understanding what a HSM does is critical before diving into the documentation. Essentially, it is a device that generates and holds private keys. The intent of the device is to make it extremely difficult for an unauthorized agent to access the contents without obvious damage or an audit trail.[footnote]This StackExchange question goes into a bit of detail about what that would look like – physical access, acid, and scanning electron microscopes may be involved.[/footnote] An API allows authorized users (or security principals – i.e. service accounts and applications) to request cryptographic operations be performed on data included with the request. It’s a bit of a black-box, “magic” process from the developer point of view. Data goes in, and encrypted data comes out. The key is never exposed in plaintext to the application, to the users, or to the administrators, yet it can easily be used. HSMs are also used payment card processing devices – the pinpad at the grocery store – to encrypt your PIN as you complete a transaction (assuming you’re not in the USA). The root certificates for Certificate Authorities (should) be stored in an HSM, and used to sign certificates.
Azure Key Vault is a core component of a number of Microsoft’s services – the most obvious is the capability to BYOK for Azure Rights Management Service. You can use a Thales HSM on-premises to generate the key, wrap it up for secure transport over the Internet [footnote]Keys are wrapped on-premises using a Key Encrypting Key – essentially a public key that is verifiably created in the Key Vault infrastructure that is used to encrypt your key such that it can only be decrypted in the Azure Key Vault service[/footnote], and upload it to the Azure Key Vault. One of the fundamental principles of the Key Vault Service is that Microsoft is unable to recover, read, or export the keys. The automated process that Thales and Microsoft worked together to develop ensures that the key upload process is verifiably secure, that the keys are always opaque to Microsoft, and that the keys remain in the HSM security world.
Key Vaults can store both keys and secrets. The difference is subtle – a key would be a private key for a certificate, whereas a secret is a string you’d like to protect, such as a password or an access key for a Storage Account. Thus, Key Vaults are important for continuous deployment – in scenarios where developers should not or cannot have access to production administrative credentials or certificates, but do have access to deploy to production, it is possible to create ARM templates that reference Key Vaults for secrets. This reduces the burden on IT Administrators to manage frequent deployments to production, as they can hand off many of the tasks to the development team. The user (or service account) performing the deployment must have special permission to perform the ‘deploy’ action on the Key Vault.
As a developer of a SaaS application, there are times when customers store privileged information. Customer information must be kept isolated, both from the reference point of the customer as well as the SaaS developer. With Key Vault, it is possible to allow the customer to Bring their Own Key (BYOK), in such a way that the service provider does not have the liability of handling the keys. When the application needs to perform a cryptographic operation with the keys, it actually delegates the task to the HSM – the HSM will look up the keys, use them internally, and return the result. The secret never leaves the HSM.
This post only scratches the surface of how Key Vaults work and is totally free of configuration details. Most organizations can benefit from using the Key Vault service, but before you get started using it in production, I HIGHLY recommend reading and understanding as much documentation as possible on the subject. The official Azure documentation is available here, but a lot of the information I found helpful was found on the Azure Key Vault Blog. A great overview of HSM as it pertains to the Microsoft Azure environment is available from Thales. The Azure Key Vault team is pretty quick to respond to questions if you email them at AzureKeyVault at microsoft.com, and there’s a Yammer community (mostly focussed around Azure Information Protection and Azure RMS) at yammer.com/askIPTeam. If you’re storing keys or secrets in your applications, I strongly recommend investigating whether Key Vault can be useful to you. Implementation is critical to the security of your data, so ensure you read all the documentation, and ask for clarification where appropriate!