Azure Storage Encryption At Rest

Azure storage encryption can be a pretty misunderstood concept and so the goal of this post is to provide an overview of the feature set and discuss an interesting preview that is currently in progress.

What is Azure Storage Encryption?

By default, all data stored in Azure storage accounts are encrypted at rest. This is done transparently at the storage service layer using a 256-bit AES Encryption key. The service and key usage is FIPS 140-2 compliant. As per the documentation this encryption is enabled automatically and cannot be disabled.

From a data flow perspective, it looks something like this:

The encryption service offers 3 methods for encrypting your data on the underlying infrastructure. The first is the default which uses Microsoft-managed encryption keys and follows the flow above. Anyone with API access to the Azure storage account will be able to read the data, and, all data stored within the Azure storage account is encrypted using the same key. Microsoft manages the key, which effectively means that there is a key rotation process that happens in the background.

The second method is to use customer-managed keys. Here is the diagram from the docs page.

In this method, an encryption key is still stored as part of the encryption service, just like in the first scenario. The difference here is that the key stored in the encryption service is wrapped by a customer managed key. This customer-managed key acts as a key-encrypting key and is stored in Azure Key Vault.

The main benefit here would be around deletion of the data itself. Rendering the data irretrievable in this scenario would be as simple as deleting the customer managed key in the Azure Key Vault. This benefit comes at the cost of some important trade-offs. The first is that Azure Key Vault is priced in a per-operation perspective. Because the encryption service within the Azure storage account needs to decrypt the encryption key in order to use it, every operation will incur a call to Azure Key vault. Further, each call could result in increased latency as you’ve now added another service into the overall data flow. The last trade-off is that your customer managed key becomes a key that you will also have to rotate/manage/control.

The last method is called the customer-provided key. In this method, the flow above is the same, however, the encryption service no longer stores the encryption key (in any form) for the back-end data. Instead, the client sends up the key to use during both the read and write operations. This method provides the most control over which key is used to encrypt the data in the storage account at the expense of passing all the key management and distribution responsibilities to the client.

Encryption Scopes (Preview)

A feature that is currently in preview for Azure storage is encryption scopes. Based on my understanding of the feature, encryption scopes is designed to be an alternative to customer-provided keys. Effectively, you can now define multiple encryption keys that can be used in a given storage account. You can then define the default key to be used (at the container level, for example) and you can also specify which key to be used when individual blobs are created (as an override, perhaps).

The benefit here, over customer-provided keys, is that you don’t have to manage the storage and distribution of the key to all the various clients that would need access to the data. The disadvantage is that I do not believe there is any access controls on an encryption scope itself. Therefore, any client interacting with storage could use any of the encryption scopes currently defined.

A use case

At Keep Secure, we work with many start-ups that deal with customer data in a multi-tenant fashion. A potential use-case for encryption scopes is to allow for multi-tenant storage of data while giving customers fine grain control over the data stored.

For example, a SaaS provider could provision a key vault for each customer for whom they want to store data for. Using key vault authentication, they could provide access to customers to create a customer-managed key within that key vault. Then, they would create an encryption-scope tied to that customer which uses the created/shared key-vault. Now, all data tied to a given customer could be encrypted with a customer-specific encryption scope, tied to a key to which the end customer has full control over.

One of the key benefits I see for this approach is in off-boarding scenarios. With a simple action of deleting the customer-managed key in the key vault, all data stored against that key would be rendered useless. An effective way to provide various assurances to customers that data deletion was done properly.

Conclusion

There are a couple of neat new features as it relates to Azure storage that I hope to explore. Encryption scopes is one of them. I think this could provide some very interesting features particularly as it relates to data security and privacy regulations. I hope you enjoyed.

 

About Shamir Charania

Share This Article

Comments