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: http://azure.microsoft.com/services/key-vault

We value your input so please take a moment to follow usjoin 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 add 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.

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.

Key Vault supports asymmetric keys (RSA 2048). Your applications may use these for encryption or digital signatures.

Secrets – Secrets are small, less than 10 kilobytes, data blobs protected to 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 (VHDs). 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 need only notice 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. The Contoso IT team can now deploy the LOB application worldwide. They can do in 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 Key Vault administrators. 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: http://go.microsoft.com/fwlink/?linkid=512409

Comments (20)

  1. Anonymous says:

    @Prashant — Nothing to announce at this time but I’ll say that you’re not the first to ask 🙂

  2. Anonymous says:

    Andy,
    You can store anything under 10KB as a ‘secret’ in the Key Vault. It could be a password for instance. The application must be explicitly coded to write and retrieve these secrets.

    Nitramafve,
    The security goal here is to ensure that only the application (and the VM it is running in) can see the secrets — not even the people who deploy the application or develop the application. In contrast, many applications today deploy secrets as part of their
    application package (say in their config files) and this exposes the secrets to the operations staff that deploys the application, and perhaps the developers also.

    Let’s say in your company,
    – Person A deploys SQL Servers.
    – Person B deploys an application that uses that SQL Server.
    – Person C is the CSO.

    With key vault, these people will coordinate as follows:
    1. Person C deploys a ‘service certificate’ in Azure. See
    http://msdn.microsoft.com/en-us/library/azure/gg981929.aspx.
    2. Person B configures his application with the name/thumbprint of that certificate.

    3. Azure automatically injects into the VM that hosts B’s application. B’s application now uses this certificate as the credential to get a token from Azure AD, to be used in step 5 below.
    4. Person A deploys the SQL server. Person A creates a key vault, adds the SQL connection string to it as a secret, and authorizes B’s application (but not B) to read that secret.
    5. B’s application reads the SQL connection string and talks successfully to the SQL server.

    In this flow, person B does not have direct access to the secret.

    B’s application (and VM) does have access to the secrets that it needs (the certificate to get a token, the token to read the connection string, the connection string to talk to the SQL server). Due to the nature of the application, there is no way around this.

    To close, if B’s application were dealing with cryptographic keys, not generic secrets, then further isolation is possible. When B’s application calls the key vault to operate with a key, the key vault service doesn’t return the key. It does the operation on
    the application’s behalf, so even the application cannot see the key.

  3. Anonymous says:

    @Johan Persson – Azure Key Vault uses Azure AD for authentication, so in that sense it’s already integrated.

  4. Anonymous says:

    Aron – that is correct.

  5. Anonymous says:

    2014年後半の振り返り中ですが、取り急ぎ。

    Azure Virtual Machines G-Series が 米国西部リージョンで一般提供開始
    Azure Virtual Machines

  6. Johan Persson says:

    Will it integrate with Azure AD?

  7. Anonymous says:

    El equipo de Azure no para ni en las vacaciones de Navidad de este año, nada más volver

  8. Prashant Gharpure says:

    Any plans to provide TDE support in Azure SQL DB using the Key Vault?

  9. Anonymous says:

    Welcome!
    In our introductory blog post we covered the overall Key Vault model. Today we’re going

  10. Anonymous says:

    Welcome!
    In our introductory blog post we covered the overall Key Vault model. Today we’re going

  11. Nitramafve says:

    If the app is running in Azure, the credentials for authenticating towards Azure AD must still be stored on the machine which needs access to a secret. For example the apps client id and a corresponding certificate may be stored. Otherwise key vault cant
    be accessed. Except for the auditing benefits, I fall to see how this service adds security compared to storing the secret on the machine. An attacker with access to the machine can retrieve the data in both cases. I don’t see how it helps to store the secret
    data in a very secure place if I still need to store the access credentials for that place in the relatively insecure location. What am I missing?

  12. Andy Ball says:

    Cool. Can this be used to store standard passwords for things like Windows Service Accounts / SQL Logins ? ie like Cyberark.

    cheers
    Andy

  13. Anonymous says:

    Welcome!
    In our first blog Azure Key Vault – Making the cloud safer , we introduced you to the Azure

  14. Fernando Rubio (PFE) says:

    Hi

    The idea of HSMs (both on premise and on cloud) is that the cryptographic operation is performed inside the HSM, if somebody hacks the windows box they would be able to make crypto operations but won´t be able to get a copy of the crypto materials (the private
    key) and go to another machine to make crypto operations with it. Therefore, mostly you are right, mainly is the auditing what you get but also the ability to delete a key from the vault…

    HH

  15. Aron says:

    "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."

    It seems to me that the design pattern choice goes beyond just the developer making a decision on their own as this section implies. A decision such as this should either be guided by an organization's existing security policies and standards or by a group
    of individuals from Development, Security and Operations that can evaulate the risks associated with both approaches to make an informed decision that will balance out both the security needs of the organization and the performance of an application.

  16. Anonymous says:

    В дайджесте новостей облачной платформы Microsoft Azure собраны основные анонсы и контент для разработчиков

  17. Richard Moulds says:

    Picking up on the point made by Nitramafve, which was essentially, if a malicious application has the ability to use hardware protected keys (for example by stealing weakly protected access credentials), how is this any better than the malicious application
    actually having the keys (by stealing the keys rather than just the credentials). For me the crucial distinction is that the latter scenario enables an off-line attack and yet the former is only subject to potential on-line attacks. If the malicious application
    has direct sight of keys it can export those keys and enable their use outside of any detection or auditing mechanisms. On the other hand, if those keys are locked inside an HSM (that we assume can not be physically stolen or tampered with) they can not be
    exported and can only be used in situ. Any attempt to misuse the keys must be performed in the full glare of the surrounding IDS, audit and behavior monitoring systems. That means the attacker of HSM protected keys must tread carefully and will eventually
    get spotted – not perfect, but much better than an attacker running off with the keys and using them without restriction or observation.

  18. Anonymous says:

    This post comes from Devendra Tiwari, a senior security program manager in the Azure Security engineering

  19. Anonymous says:

    NOTE: This post was updated on June 2 2015 to incorporate recent changes in Azure cmdlets.

    Welcome

  20. Anonymous says:

    This is the August 2015 monthly edition of Luper’s Learnings. We’re now a full month into