[Question] Secure way to persist keys on Azure
Closed this issue · 5 comments
I would like to have some guidance for securely manage DataProtection on Azure.
1/ Persistence
For now, there is three ways to persist keys on Azure.
- Into the instance-shared file storage
- Into Redis database
- Into an Azure blob storage
Are those implementations secured ?
Are those implementations secured by default ?
I imagine that each implementation require to be secured correctly. Is there any guidance ?
Is KeyVault a valuable option ?
Related : #92
2/ Key protection
- With DPAPI/DPAPI NG : Not on Azure
- With a certificate
Is KeyVault a valuable option ?
Related : #178
By default any shared storage is not encrypted. You need to layer x509 on top of it. You can use a certificate if, and only if, you target .NET Framework, rather than .NET Core, which doesn't have the right classes yet. That would be the safest option, however not that on azure web apps you cannot upload a certificate to use unless you're on the higher SKUs.
We have a branch for keyvault to protect the keyring, but when you rotate the keyvault master key it will no longer be accessible, so all data protection keys protected with it suddenly can't load (unlike with certificates where we can still decrypt, just not encrypt new items). Until that changes, and we've asked, we feel pushing the KeyVault package out could result in data loss.
If I resume, Azure web apps key ring may be secured on any shared storage, if I am capable to use certificates.
Certificates usage require adequate SKU & .Net Framework.
Any visibily on .Net core required class? I had an issue on trying to build a client certificate authentication middleware.
With KeyVault, if nobody rotate the keys, is there any matter?
Or shouldn't we store the keys as secret instead of keys?
You should always rotate keys, it's just best practice. We don't store the keys themselves as secrets, as the API for reading secrets has way way too much overhead.
We've been working with the KeyVault team, and finally hope to have an answer for our 2.0 time frame.
This issue was moved to dotnet/aspnetcore#2519