Application security with Azure Key Vault
By Christos Matskas, Premier Azure Dev PFE at Microsoft
Azure Key Vault is a new(ish) service offered by the Azure team. This Platform-as-a-Service (PaaS) feature, now in general availability(GA), allows you to securely manage and protect cryptographic keys and secrets which can be used by cloud-enabled applications and services. There are a few compelling reasons why someone may choose to use Azure Key Vault:
- It can be used to encrypt keys and secrets (authorisation keys, storage account keys, data encryption keys, etc) using the keys that are stored within the Azure Key Vault service, which are protected by Hardware Security Modules (HSM).
- Alternatively, the stored secrets and keys can be consumed by the application or used directly to encrypt/decrypt sensitive data.
- When we look into Azure deployment automation, we can integrate Key Vault with our ARM templates to remove the need to store sensitive information inside the templates. Consequently, no sensitive passwords or connections strings related to the production environment stored in source control.
Key Vault is one of these services that once integrated to your solution, it can become an invaluable resource. For developers, it allows us to easily implement cryptographic functionality in an application without having to worry about key management. In addition, application settings can be pulled directly off Key Vault making the whole implementation even more secure. To further improve performance and lock down security, instead of using the Key Vault account and key to access the service, you can use a certificate to authenticate the application against the Key Vault service.
For devops, Key Vault brings additional benefits. ARM templates can directly work with Key Vault to consume secrets as parameters. PowerShell and the Azure CLI can also benefit from using Key Vault with Azure Active Directory Service Principals to minimise permissions and apply proper access controls while executing scripts.
Having a service to properly manage and store symmetric or asymmetric keys is important for improving the security of your solution. This is particularly important because key management is one of the weakest links in any encryption implementation right after selecting weak encryption algorithms (DES, for example is a weak choice). In addition to storing keys, the service can be used to store secrets (small pieces of encrypted data). Although this may not sound as important, the fact that sensitive data can be further decoupled from the main application data is a major benefit.
Azure Key Vault SDK
For developers, the Azure Key Vault can be consumed using one of the 4 available SDKs
- .NET SDK
- REST API
All SDKs are just a thin wrapper around the REST API. The wrappers have been carefully designed to abstract away the underlying complexities for setting the necessary request headers and it's a great choice if you're already using one of these languages.
A deep dive into the service (the juicy parts)
Azure Key Vault allows you to store securely cryptographic keys and secrets (encrypted data) on the cloud. The security of the data can be further complemented by using Hardware Security Modules (HSMs). The provided SDKs offer an easy way to manage the keys and secrets and perform certain operations against your data, such as sign/validate, encrypt/decrypt etc. The service supports the JSON Object Signing and Encryption specifications as defined by the IETF. You can find more info about the standards here:
At this point, it may be useful to break down the terminology so that you can bet a better understanding as we go through the different features:
Vault: You can have multiple vaults in multiple geographic areas. Each vault consists of a collection of cryptographic keys and cryptographically protected data. You can think of them as folders in the file system. These folders contain sensitive information and group together logical entities, and all keys and secrets relevant to a specific application are bundled together
Keys: These are cryptographic keys. Azure Key Vault currently only supports asymmetric keys (RSA 2048). The keys can be either standard (Software Protected) or Hardware Security Module(HSM) protected. Software-protected keys also benefit from HSM protection when stored and, in effect, offer the same assurances such as isolation etc.
Secrets: Secrets are small chunks of encrypted data less than 10KB in size. They are useful for storing sensitive application settings in a protected manner. However, you're not limited in using secrets for applications settings, so anything can be stored as a secret as long as it fits in size.
All objects stored in Azure Key Vault are versioned. Every time you update an existing key or secret, instead of overwriting the existing object, a new version is created. Interacting with Key Vault objects becomes more flexible because you can use different identifiers to access them.
You can use the key/secret name (e.g. "MyKey") to perform certain operations. Accessing the key/site this way will always use the latest available version. Alternatively, you can use the key/secret name and a specific version identifier to access the non-default/latest object. Each key version has a unique identifier and URL. These allow you to directly access any key without having to request the key version list first. The object name, used as a unique identifier, must be a string between 1-127 characters and cannot contain any special characters. The name is case-insensitive and immutable. The object version, used as an extended unique identifier, is a system generated, 32-character string i.e. a GUID.
Supported encryption and hashing algorithms supported
The service currently supports symmetric RSA keys but there is already scope for adding asymmetric and elliptic curve key support in future releases. The keys can be generated either by using the service or you can choose to import existing keys. For keys generated using the service, there are 2 types of supported algorithms:
- Simple RSA
More details around the supported algorithm types can be found here.
There's a set of operations that can be performed on key objects:
- List versions
Since keys cannot be exported once created in the Key Vault, the Backup and Restore operations can fill that gap. However, keys retrieved using a Backup operation are in protected form and can't be used outside Azure Key Vault.
Cryptographic operations supported by the keys
Once a key has been created and stored in Azure Key Vault, you can perform the following operations:
- Sign and Verify: This feature can only be applied to hashes. It can’t be used directly on data. In simple terms, you can sign and verify hashes but not data objects.
- Key Wrap and Unwrap: This feature is used to protect other keys. You can use one key in the Vault to protect other keys. When you apply this operation to an asymmetric key, you effectively encrypt/decrypt the key. Symmetric keys, on the other hand, are wrapped and unwrapped. Since this is a computationally heavy operation, it's recommended that it's performed locally.
- Encrypt/Decrypt: This feature is used to encrypt and decrypt data. Again, this operation should be performed locally for better performance.
The set of operations that can be performed on secret objects is listed below:
Managing permissions on the Key Vault Service
Access to keys and secrets can be managed either on a per key/secret case or on the whole of Key Vault. Key access policies are different to secret access policies. Ideally you should be using a Service Principal (SP) with explicit permissions to Key Vault. For example, if your application only needs to read configuration settings then the SP should only have read rights to a subset of secrets.
Azure Key Vault is an excellent service and a invaluable addition to the overall Azure infrastructure. It promotes the secure management of cryptographic keys and secrets without the associated overhead, which is an important step to adopting and implementing better security within our applications.