Azure Key Vault – Making the cloud safer
Welcome!
Today we're announcing the public preview of Microsoft Azure Key Vault, a cloud-hosted HSM-backed service for managing cryptographic keys and other secrets used in your cloud applications. You will be able to use it for all your important workloads both on premises and cloud hosted. In this blog we dive a bit deeper into what we think will drive you to endorse the Azure Key Vault design principles. This blog site will focus on the more technical and more hands-on aspects of Key Vault. The shorter announcements will be posted here.
Here is the Azure page: https://azure.microsoft.com/services/key-vault
We value your input so please take a moment to follow us , join our advisory board , send us private feedback , and/or visit our forum
The Azure Key vault is a cryptographic key management service based on FIPS-validated Hardware security modules (HSMs). This service is a public Azure service that will, over time, be the trust root for important Microsoft first party services, for third party services seeking to offer higher assurances, and for your own custom line of business (LOB) Azure-hosted applications. Today’s announcement offers a preview of the Azure Key Vault service, a SQL Server Connector, and an upgrade to Cloudlink SecureVM.
With these you can:
1. Safeguard cryptographic keys and sensitive settings such as passwords used in your custom applications.
2. Enable safer, more secure encryption of SQL Server databases in Azure VMs.
3. Protect your Azure virtual machines using CloudLink SecureVM, using master keys in your own Key Vault.
Please don’t let the ‘preview’ label dissuade you from seriously reviewing the service. The Key Vault is really the public incarnation of our 18mth old Azure RMS bring-your-own-key (BYOK) offering which is in worldwide production and underpins Microsoft Office 365. This new Azure Key Vault offering is about sharing this wonderful capability and user model with other applications. Many Azure and Office 365 services will migrate, over time, to use the Azure Key Vault service.
The service enables several important user roles, to perform common cryptographic tasks, all while introducing only a handful of simple concepts. Let’s take a moment to explore each of them...
There are several important actors in a secure application environment. In the earlier phases of application development or deployment they are all performed by the same person but production systems generally do (should!) isolate them. 
Security Operations – These are typically IT staff from the ‘office of the CSO’ in larger companies. They are responsible for the proper safekeeping of secrets despite how hard this has been in the past. For example, in organizations using Azure Rights Management these people are responsible for the security of the master RSA key. They also (should) manage the SSL certificates for websites. Where applicable, they are liable for any passwords and sensitive data collected from users. You get the idea.
Developers and IT Pro – You know these people well. Here we want to emphasize that they are not (meant to be) part of the Security Operations team. The ‘meant to be’ parenthetical reminds us of just how hard it has been to exclude them from having access to sensitive tidbits thus far.
Auditors – Similar to Security Operations, this is a role isolated from Developers and general IT staff. In regulated businesses, this role is even isolated from the Security Operations team.
There are 3 commonly used cryptographic building blocks in a complete solution.
The most critical enables the storage of a ‘root protection key’ with very high security assurance. Generally this infrastructure is an HSM and is designed so the customer’s asymmetric key (private portion) can never be seen or shared.
A second valuable building block is a Secret. Secrets are small data packets that customers want protected. Good examples would be the password for a protected Azure VM and a SQL connection string. These secrets are protected by one of the aforementioned HSM-backed keys. Secrets are an important Key Vault construct because most applications have them and persist them in less than ideal ways.
Finally, a third important building block is one that is capable of bulk data protection. The data is large (unlike secrets) and so it certainly does not reside in a Key Vault. Bulk protection uses a symmetric key for protection of the raw data. This symmetric key then requires safe storage, most often protected by an asymmetric key. One example is Azure RMS which protects bulk data (Office files, PDFs, etc) using symmetric keys. RMS creates a symmetric bulk data encryption key (per file) protected by a per-customer, HSM-backed key. The protected symmetric data encryption key is stored in the encrypted file. This model permits the protection of millions of files, each with a different symmetric key, but all rooted in a HSM-backed master key. RMS thus uses the top and bottom building blocks outlined here. Another example is the SQL Server Connector that permits SQL data encryption to benefit from Azure Key Vault. Here again, the pattern is similar – we want to encrypt a lot of data but feel assured that the protection of the key used for bulk encryption is well guarded. A third example is protecting Azure VMs. We’ll cover the SQL and protected Azure VM offerings in more details in blogs 3 and 4 of this series (next week).
In picture form:
In terms of concepts, we have the following:
Vaults – Organizations will have several key vaults. Each key vault is a collection of cryptographic keys and cryptographically protected data (we call them “Secrets”) managed by one or more responsible individuals within your organization. These key vaults represent the logical groups of keys and secrets for your organization; those that you want to manage together. They are like folders in the file system.
Keys – Keys are the central actor in the Azure Key Vault service. A given key in a key vault is a cryptographic asset destined for a particular use such as the master asymmetric key of Microsoft Azure RMS, or the asymmetric keys used for SQL Server TDE (Transparent Data Encryption), CLE (Column Level Encryption) and Encrypted backup.
Your keys must stay 'out of sight' from the applications that are using them. One user adds keys to a key vault. Applications must use your keys by calling cryptography methods on the Key Vault service. The Key Vault service performs the requested operation within its hardened boundary. The keys are not seen by the application.
Keys can be HSM-protected or Software-protected. The Key Vault service performs all cryptographic operations on HSM-protected keys inside Hardware Security Modules. The service uses Thales nShield HSMs validated to FIPS 140-2 Level 2. Cryptographic operations on software-protected keys in contrast are done in software. Software-protected keys benefit from HSM-protection when stored. In general, they offer most of the same assurances as HSM-protected keys except the FIPS 140-2 Level 2 assurance. E.g. your key is still isolated from the application in a container that you manage, it is stored encrypted with HSMs, and you can monitor usage via Key Vault logs (coming soon). This said, we suggest you carefully review your specific (maybe even regulatory) needs before using software-protected keys over native HSM-protected keys. For production use, we recommend using HSM-protected keys and use software-protected keys in only test/pilot scenarios.
Keys can be single instanced (only one key exists) or be versioned. In the versioned case, the Key is an object with a primary (active) key and a collection of one or more secondary (archived) keys created when keys are rolled (renewed).
Key Vault supports asymmetric keys (RSA 2048). Your applications may use these for encryption or digital signatures.
Secrets – Secrets are small, less than 25 kilobytes, data blobs protected by a key that is automatically generated as part of creating a Key Vault. Secrets exist to dramatically simplify the process of persisting sensitive settings that almost every application has... storage account keys, SQL connection strings, data encryption keys, etc.
Usage Logs – While not offered publicly during the preview, they will be shortly. All key use and management operations result in log entries. The Key Vault administrators configure logging; each Vault is given access to your owned Azure storage. This results in all aspects of log access and retention being within your full control.
Applications – Applications are modified to use the key vault for the purpose of segregating sensitive key matter from their code paths, storage and operating environments. Applications makes use of key vaults, secrets and keys via simple web service calls.
Let’s now pull these actors, concepts, and components together. The elegance of the Azure Key Vault service is best described using a ‘day in the life’ story. Nearly everyone’s business will have line of business (LOB) applications; several of which involve sensitive data and requirement to encrypt it. We’ll review one such application going through several phases of its ‘life’.
In particular:
1.Contoso learns that their LOB application is not as secure as they once thought.
2.The ‘Office of the CSO’ requests the application be modified to use the Azure key vault
3.Contoso outsources development of the application to several small app design shops
4.Contoso IT validates the updated application
5.Contoso prepares for the production deployment and the corresponding security audits
Contoso learns that their LOB application is not as secure as they once thought. Their application meticulously encrypts all sensitive employee data but does so using a master key that is built into the application. A security audit reveals several problems:
1. The application installer ‘injects’ the key or a password into the installed application. That key or password is available ‘in the clear’ to all those involved in the deployment process. It has marginal protection once integrated into the setup package. While there are many ways to do this, none of them are highly desirable.
2. When the application crashes the resultant crash dumps are given to the vendor that wrote the application. This vendor, who never had access to the key matter, is now very likely in possession of that key given the application loaded the key into memory to encrypt the sensitive LOB data. Worse still, the crash dump being too big to email, was likely shared to the developer via a cloud drive. We know this happens every day.
3. Many IT staff have access to the servers running this LOB application. Some are vendors. A malicious engineer or malware could easily extract the key from this application via several means.
The ‘Office of the CSO’ requests that the application be modified to use the Azure Key Vault. The design of the key vault is a key (pun intended) reason for using it. For the first time both on premises and cloud hosted applications can make use of a service that offers to segregate key matter, control, management and auditing from the application context.
Contoso outsources development of their LOB applications to several small app design shops. The developers are trusted vendors. One for Windows and others for the mobile clients. The elegant developer model for the key vault makes for a simple update. First, the key configuration software is ripped out of app setup. This application will never again see the key used to protect data. Next the application is taught to rely on keys and secrets from the Key Vault web service to perform cryptographic operations. They make use of a simple web service API to do so.
At this point the developer will need to make some important decisions. They will need to consider the trade-off of having the highest security pattern, one where all crypto happens in the Vault boundary. Or, go for reduced operational and latency costs often required for effective bulk data protection, where the Key Vault only provides protection of the ‘secret’ used for bulk data protection (most certainly an AES symmetric key). The choice is theirs to make. Similar choices (trade-offs) exist today with HSMs.
To test the environment, each of the software vendors (PC, mobile) can setup their own Key Vaults and make use of less expensive ‘software-backed keys’ for testing. They can do so knowing that this 'one box' test environment uses the EXACT SAME programming paradigm as a worldwide, HSM-backed production deployment. This is a new found scalability and quite a big deal for developers.
The software vendors can also test key versioning by using the key rollover features of the Key Vault. When a key is rolled, the application needs a notification that the version has changed. It can then use any of the archived keys for decryption but only the newest key for encryption. This results is a very clean, progressive migration to the new keys. Their tests validate rolling a key. They then can validate their continued ability to unprotect all content, regardless of which version of the key was used to protect it. They can finally validate that all new data is always protected with the latest version of the key. Confident in their simple modifications, the applications are given to IT for validation.
Contoso IT validates the updated application. Contoso IT configures a new key vault, generates a software-protected key, and verifies the app. They take the time to verify application behavior when keys are rolled, disabled, or deleted, to ensure that the application behaves well across all facets of the key lifecycle. They test several instances of the same application (for scale out) using the same key vault, and in multiple Azure regions (redundancy). Confident with their work, this application is now ready for on premises and/or Azure data center use. Key vaults take only minutes to set up, making it easy for Contoso IT to do this validation exhaustively.
Contoso prepares for the production deployment and the corresponding security audits. TheContoso IT team can now deploy the LOB application worldwide. They deploy the application on-premises or in Azure. Within Azure they can do so in each geography, with the application being offered in 2 or 3 regions for increased availability. Following central IT’s lead, the CSO IT team will create key vaults in each of the same geographies. These key vaults are provisioned with HSM-backed keys. These keys can be the same across geographies or be different depending on needs (regulations, risk management, different operating LLCs, etc). The HSMs within a given geography all share the same ‘security world’: US, EU, Asia Pacific, South America, China and Australia. With the key vaults created and the keys provisioned, the CSO IT team authorizes the LOB application in each region to access their assigned keys using the key identifier (KID). It looks like this:
https://ContosoTestVault.vault.azure.net/keys/ContosoPayrollKey
That’s it! At this point Contoso has a world wide deployment of their far more secure LOB application. They have complete key isolation and all use of the key is audited by (and only by) the designated auditors. Their keys stay within a FIPS 140-2 Level 2 boundary (HSMs). Their organization is in control of those use logs. Key rollover is a built-in concept so the CSO IT leaders can roll keys as they please without ill effect on the product.
Our next blog post will have Sumedh take the above ‘day in the life’ flow and show you how the Key Vault is created, configured, and otherwise managed. Following that, we’ll have a detailed blog posts on the integration of SQL Server and Cloud Link SecureVM using our new Azure Key Vault. After that, well, you'll need to follow us to find out more.
Until then, thanks for your support!
Dan (twitter) on behalf of the Azure Key Vault Team
Please take a moment to send us feedback , join our advisory board , and/or visit our forum
To ‘kick the tires’ yourself on an Azure Key Vault, please refer to these resources: https://go.microsoft.com/fwlink/?linkid=512409
[
Updated 2016/11/18 - Fixed typos, small edits for clarity. ambapat@MSFT]