A primer on protecting keys and secrets in Microsoft Azure

Supporting data confidentiality, including encryption keys and certificates, is a critical task. In cloud-hosted workloads, the requirements are even more complex as different actors need to mediate access to sensitive material. According to the Ponemon Institute’s 2015 Cost of Failed Trust Report, “Security professionals believe that, over the next two years, the risk facing every Global 5000 from attacks on keys and certificates is at least $53M.” The report also notes that “54 percent of organizations admit to not knowing where all keys and certificates are located, which means they do not understand how they are being used or what should be trusted.”

Security best practices dictate that we not store secrets in plain text or at easily accessible locations. One common failure mode we have observed time after time includes storing secrets in source code, local, easy to access files or environment variables. These methods are convenient and solve the problem quickly. Unfortunately, because they offer little means for authentication, access control, or revocation, mistakes leading to inadvertent exposure causes severe problems for many organizations that can be difficult to recover from.

Azure Key Vault

The Microsoft Azure cloud platform provides a secure secrets management service, Azure Key Vault, to store sensitive information. It is a multi-tenant service for developers to store and use sensitive data for their application in Azure.

The Azure Key Vault service can store three types of items: secrets, keys, and certificates.

• Secrets are any sequence of bytes under 10 KB like connection strings, account keys, or the passwords for PFX (private key files). An authorized application can retrieve a secret for use in its operation.
• Keys involve cryptographic material imported into Key Vault, or generated when a service requests the Key Vault to do so. An authorized cloud service can request the Key Vault perform one or more cryptographic operations with a key on its behalf.
• An Azure Key Vault certificate is simply a managed X.509 certificate. What’s different is Azure Key Vault offers life cycle management capabilities. Like Azure Keys, a service can request Azure Key Vault to create a certificate. When Azure Key Vault creates the certificate, it creates a related private key and password. The password is stored as an Azure Secret while the private key is stored as an Azure Key. Expired certificates can roll over with notifications before these operations happen.

These primitives offer fascinating models to manage performance and assurance requirements for cloud workloads. For example, an application can choose to store its connection strings as a secret in order to limit access to its datastores to only itself and other authorized parties.

When added, security assurance is important for the cloud application. An application can store cryptographic material as a key.

Key Vault supports two types of keys:

• RSA: Cryptographic operations using RSA Key Vault keys execute in software. A key encrypting key stored in a hardware security module (HSM) protects the actual keying material when at rest.
• HSM: Cryptographic operations using HSM Key Vault Keys and never leave the HSM protection boundary (i.e., all cryptographic operations on HSM-protected keys take place inside HSMs).

While this process would appear arduous at first, it provides a safer alternative to hard-coding credentials or parameters needed for the application to authenticate itself to the Key Vault. In addition, this provides the application author the ability to revoke access to the application without necessarily changing keys or certificates.

With many projects, compliance requirements dictate special handling for keys and secrets. In some cases, only a security or DevOps administrator has access to the key. Engineering teams may not be permitted to manage these keys, especially in production workloads. In these scenarios, the administrators have the responsibility of managing the life cycle of this sensitive material including creating, importing, revoking, and deleting the keys and secrets. Monitoring key usage is also a mandatory requirement in these environments. Engineering teams only have access to sensitive material via their identifiers (URIs) provided by the administrator. This way, the applications don't own responsibility to the keys/secrets. Additionally, the key management remains external to the application.

Another feature of Key Vault is having different versions of a particular key/secret. When authorized personnel wants the value of a secret/key to be updated, the older version of the secret/key is archived, in the likely event that a workload will need to decrypt data encrypted with an older version of the secret/key.

Finally, Key Vault offers logging features. Here, logging provides the ability to monitor when and who accessed a key, secret, or certificate from the Key Vault. Key Vault saves access logs into an Azure storage account. Manage this storage account by using standard access control methods.

Bottom line

Azure Key Vault is an effective solution for managing secrets in cloud environments. In addition to its usefulness for storing secrets, it can also act as a store for sensitive keys and certificates. Above this, it offers the capability to manage certificate life cycles from certificate creation through expiration to rollover.

As icing to the cake, it offloads sensitive cryptographic operations to Azure and provides facilities for logging and auditing key usage. For teams looking to migrate their applications to Azure, consider Key Vault as one of the solutions in your arsenal to improve the security posture of your application.