Darran S on Fri, 06 Nov 2015 15:19:25
We are currently designing the architecture for a high availability solution that will use Traffic Manager to fail-over from a primary region (Europe North) to a secondary region (Europe West) in the case of failure. We wish to use Key Vault to store not only infrastructure related secrets (connection strings, etc), but also per user secrets. However, if we fail over from the primary data centre to the secondary, then we will no longer have access to these per-user secrets.
Is there a way to replicate secrets between two Key Vaults in different Azure regions? Or will we need to implement this ourselves?
Girish Prajwal on Sat, 07 Nov 2015 13:27:43
Thanks for posting here.
We are working on this and will involve our experts for quick solution.
Sumedh Barde [Microsoft] on Sun, 08 Nov 2015 23:35:33
Can you elaborate on "per user secrets"? (Feel free to reach us at AzureKeyVault@microsoft.com if you need.)
Key Vault was designed to store application secrets such as connection strings, storage account keys, and cryptographic keys. While the API won't prevent you from storing other kinds of secrets, it is not optimized to be a general purpose store. e.g. if you want to store passwords/certificates for thousands of your users, consider Active Directory.
As for your fail over question -- you likely have two categories of secrets:
- Secrets that are specific to Europe West and to Europe North. e.g. your storage account keys for your local storage. Recommendation for these is to store the Europe North secrets in a key vault in Europe North, and the Europe West secrets in a key vault in Europe West. This insulates your entire stack as much as possible from incidents outside that region.
- Secrets that must be shared by your application in both Europe West and Europe North. Minimize these as much as you can. Put these in a key vault in either of the two regions. Use the same URI from both regions. Microsoft will fail over the Key Vault service internally (we will post more details on this shortly as this seems to be a FAQ.)
Darran S on Mon, 09 Nov 2015 10:08:15
Thank you for your detailed reply. Our original intention to ensure complete data segregation between different users of our application was to store a unique KEK per user in Key Vault and then use this to secure randomly generated DEK per item of data, be that in storage or SQL Azure. However it is becoming clear from further reading and your response that this is not the idiomatic design. Rather we should probably consider a 3 tier approach with Key Vault securing a master KEK, used to encrypt a per user KEK stored against the user in AD or elsewhere, with this per user key encrypting the DEK for each data item.
You are indeed correct that should we follow this process, there will be very few keys that need to be shared between the two data centres. To hear that this will be failed over internally is excellent news. I shall look forward to the documentation being posted.