This is the first part of the series around Bring Your Own Key (BYOK) model in Azure. I decided to write multiple posts around this area because otherwise, no-one would have time to read such exhaustive and long post about encryption in Azure. This series will have the following posts
- Introduction to BYOK model
- Encrypt Virtual Machine Disks with BYOK
- Encrypt Storage Service with BYOK
The first post is more of an introduction where I’m going to elaborate on challenges I have faced when leveraging Azure encryption with BYOK. This is a bit different post than I normally write, more strategic approach.
What is BYOK?
Bring Your Own Key aka BYOK is an encryption model where you create your own key and bring it to Azure. The key will be stored in an Azure Key Vault. With BYOK you can add an additional layer to encryption process (more info below).
Common Questions Around BYOK
Common questions I have faced during the on-going BYOK case are:
- How many Key Vaults are needed when there are tens of subscriptions?
- How encryption with BYOK actually works in different use cases?
- How many master keys is needed?
- What are the operational differences between Microsoft managed and customer managed key?
- How architecture will look alike?
- Restore operations when BYOK is in use?
In next section, I’m trying to answer these questions and hopefully, you can avoid banging your head to the wall as much as I have done:)
How many Key Vaults is needed when there are tens of subscriptions?
This is an excellent question and there isn’t a silver bullet for this one. Basic consultant answer is – it depends. The primary factor for planning is how Key Vaults and keys, secrets and certificates are managed and how processes are defined around maintenance operations.
In general best practice, applications must not share a Key Vault unless they trust each other and they need access to the same secrets at runtime. One option would be to create the Key Vaults based on functionality, one general example below:
- Virtual Machine disk encryption
- Azure Information Protection
- Database encryption
- Applications specific Key Vaults
How many master keys are needed?
The organization Security Policy and Certificate Practices Statement (CPS) documents will define normally how many keys are needed. Options for the guideline to follow:
- Environment-level (Dev, QA, Prod) – With this method, only three keys would be needed. From a security point of view, this would not be the optimal solution but would save a lot of time if creating keys at on-premises is a time-consuming task.
- Functionality based – in this scenario multiple master keys are needed. If this model is the chosen one, processes around key management are in the center of the solution.
What are the operational differences between Microsoft managed and customer managed key?
The following table identifies the operations that you can do, depending on the topology that you’ve chosen (example from Azure Information Protection guide).
| Life cycle operation | Microsoft managed | Customer-managed (BYOK) |
|---|---|---|
| Revoke your tenant key | No (automatic) | Yes |
| Rekey your tenant key | Yes | Yes |
| Backup and recover your tenant key | No | Yes |
| Export your tenant key | Yes | No |
| Respond to a breach | Yes | Yes |
How architecture will look alike?
There isn’t a’ right or wrong way to build Key Vault architecture and one possible way is found from below. In this approach, Key Vaults are used by functionality based and BYOK is used in some of the workloads which are defined in organization security policy.
How To Restore Key Vault
By default, the Key Vault doesn’t have recycle bin feature enabled. In case something is deleted, it’s gone. For that reason, the recommendation is to enable the soft-delete feature which allows restoration of deleted vaults and key vault objects. Description how Key Vault restore process works from docs.microsoft.com
A backup taken of a key from a key vault in one Azure location can be restored to a key vault in another Azure location, as long as both of these conditions are true:
- Both of the Azure locations belong to the same geographical location
- Both of the key vaults belong to the same Azure subscription
For example, a backup taken by a given subscription of a key in a key vault in West India, can only be restored to another key vault in the same subscription and geo location; West India, Central India or South India.
Key vault recovery
Upon deleting a key vault, the service creates a proxy resource under the subscription, adding sufficient metadata for recovery. The proxy resource is a stored object, available in the same location as the deleted key vault.
Key vault object recovery
Upon deleting a key vault object, such as a key, the service will place the object in a deleted state, making it inaccessible to any retrieval operations. While in this state, the key vault object can only be listed, recovered, or forcefully/permanently deleted.
At the same time, Key Vault will schedule the deletion of the underlying data corresponding to the deleted key vault or key vault object for execution after a predetermined retention interval. The DNS record corresponding to the vault is also retained for the duration of the retention interval.
Summary
That ends up introduction part and in part two I will dig deeper to Azure Virtual Machine encryption.
Sam's Corner 
Sami – Good article. I have a couple of questions. I cannot find a list of Azure services where BYOK is an option – have you seen such a list anywhere in your investigations? Also I realised that some BYOK options are tied to a specific third-party HSM, for example nCipher for O365 BYOK. What options are available if you are using other HSMs?
Data encryption at rest white paper has quite a good list of supported services
https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest#data-encryption-models