We would like to make use of Azure Key vault for storing our sensitive key in azure key vault and make use of stored sensitive key for encrypting our string/plain text data before sending to service. Again Service will interact with Azure Key vault, retrieve sensitive key for decrypting encrypted string send by client. can any one throw some light on how to make use of azure key vault for above scenario.
Azure Key vault has built-in encryption method for encrypt the data, does it mean client has to sent data to azure key vault for encryption. Is it correct. If yes, is there roll over for every 30 minutes changes in Key used for encryption.
sorry for asking very noob question
Regarding roll over, at this time Key Vault does not do auto-rollover of keys. The key vault owner must explicitly roll keys. You do this via the Add-AzureKeyVaultKey cmdlet or REST API, passing in the same key name as earlier. A new version is added to the key.
(More in-depth on how Azure Key vault works here:
http://tomkerkhove.ghost.io/2015/07/22/securing-sensitive-data-with-azure-key-vault/)
Related
Hi everyone im trying to receive my blob storage data via my spring boot client application. I can retrieve the data however it is encrypted.
In my Storage Account settings the encryption type is "Microsoft-managed keys". Now, where do find the key i need for decrypting my data? I am kinda confused i'm just not able to find the key.
Thanks a lot in advance
Azure Storage encrypts all data in a storage account at rest. By
default, data is encrypted with Microsoft-managed keys
All data that is written into Azure storage will be automatically encrypted by Storage service prior to persisting, and decrypted prior to retrieval. Encryption and decryption are completely transparent to the user. All data is encrypted using 256-bit AES encryption, also known as AES-256—one of the strongest block ciphers available. With encryption enabled by default.
Reference: https://azure.microsoft.com/en-in/blog/announcing-default-encryption-for-azure-blobs-files-table-and-queue-storage/
And The Microsoft managed keys used for encryption are not available
In Your scenario check the encryption type at the client side Data that is already encrypted when it is received by Azure. With client-side encryption, cloud service providers don’t have access to the encryption keys and cannot decrypt this data. You maintain complete control of the keys.
For more details refer this document: https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest
we used Encrypt and decrypt blobs using Azure Key Vault to protect our files from dev ops person or any unwanted access to files.
i have created the RSA key like below
now i have few doubts
#1 : if i set expiration date to this key,( let's say 2 year from today's date ) will it effect my encryption? -
for example, after 2 year, i will create new RSA key and old files which is already encrypted wont be able to decrypt ? if answer is no - how the version changed will make sure decryption keep working?
#2 : which RSA key size i have to use ? what is best as per industry standards?
#3 : in blob files, have metadata properties added by SDK : "encryptiondata" - what is that, and it include "EncryptedKey" also, what's that use?, seems like SDK is doing behind the process, when we set "BlobEncryptionPolicy"
#4 : when we set KEY to azure key vault - is it private key or public key? will we're able to see it's content ?
let's say someone got to know the RSA key from key vault in plain text..he/she will download encrypted files directly from blob and use that key in separate program and unlock/decrypt it?
Thanks,
#1 In Azure Keyvault the encryption keys don't have an expiry by default. But it is a good practice to set one. And then rotate the keys.
Rotation would involve Generate new key(s),
Re-encrypt all data that was encrypted using the old key, using new key(s)
Delete old encrypted data and old encrypted key.
Azure supports three models with respect to Data Encryption.
1)Server-side encryption using Service-Managed keys
2)Server-side encryption using customer-managed keys in Azure Key Vault
3) Server-side encryption using customer-managed keys on customer-controlled hardware
You can read more about that here. https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-models
and choose the option that you need.
If you need to bring your own keys in azure storage - https://learn.microsoft.com/en-us/azure/storage/common/customer-managed-keys-overview
Rotation process can be automated with Events, event grid, functions.
For example A secret near expiry gets triggered when the secret is near its expiry date and that is captured in an event grid and the necessary action is taken via an azure function who's trigger is that event grid mapping for this event.
Azure runbook based automation options are also possible.
#2 Bigger keysize is tougher or takes time to crack is what I know and from what I read 2048 or 4096 should be good. But again there are schools of thought on not using standard keysize etc. I guess you can consult a security/cryptography expert for the specifics.
#3 those properties refer to the default encryption at rest done in azure storage. Refer the data encryption models available for azure storage.
#4 In Azure keyvault a Cryptographic key is represented as JWK (JSON Web Key)
for Example a .pfx certificate file that contains a pair of public & private keys.
The API call to GetKeyAsync doesn't return private key data.This is why the DecryptAsync wrapper method does use the Key Vault API for decryption.
It would be great to know
what are they,
what are they used for
why would one prefer one versus the other.
A very simple answer:
Key
A Cryptographic key represented as JWK (JSON Web Key)
Example: store A .pfx certificate file that contains a pair of public & private keys
Secret
KV accepts any value and stores it as a binary (there is a max size limitation)
Example: A password or API key
Further Reading
About Keys and Secrets
Key Vault Keys:
Keys in Azure Key Vault are 'Cryptographic keys' used to encrypt information without releasing the private key to the consumer(users\Service). It acts like a black box to encrypt and decrypt content using the RSA algotithm.
The RSA algorithm, involves a public key and private key. The public key can be known to everyone; it is used to encrypt messages. Messages encrypted using the public key can only be decrypted with the private key.
Scenario:
Assume you have to store the customer CreditCard, the secure way to keep it in your DB is to store it encrypted, during the software design and
business requirements it is perfect clear that you should encrypt it,
what most people don't realize or don't bother is how you protect your
encryption keys, most of the time, stored as part of your software
configuration, if the attacker or employee has access to the key, the
information is not secure anymore.
Using key vault keys, you could send the CreditCard information to KeyVault and it will encrypt the information and return to the caller the enccrypted value.
On high performance scenarios, you could get the public key from KeyVault, use it for encrypting the information from Application side and store in DB already encrypted without sending the data to KV.
The only way to get the real data back would be sending the encrypted data to KV where it will return the decrypted CreditCard.
Key Vault Secrets
Secrets in Azure Key Vault are octet sequences with a maximum size of 25kb each. It is described as octet because it does not care about the data type being stored, the only limitation is the size of 25kb. Once you send the data, it is encrypted and stored, you can retrieve it at any time if you have the permissions to do so. It is used to store information like application settings, tokens and if you will database connection strings, passwords and so on.
The good side of Key Vault Secrets is that you can use pre-defined rotation values defining the Expiration/NotBefore values. So you could register temporary values that will be rotated at specified periods, while the reader has access to the Key Vault with Get permission, they will be able to read the current ones only, while the future ones are already defined and not visible to the Get operation.
The Azure Key Vault (KV) can store 3 types of items: (1) secrets, (2) keys, & (3) certificates (certs).
Secrets - provides secure storage of secrets, such as DB connection strings, account keys, or passwords for PFX (private key files). An auth app can retrieve a secret for use in its operation. More on AZ KV Secrets
(Cryptographic) Keys - keys represented as JWK (JSON Web Key). Supports multiple key types and algorithms, and enables the use of Hardware Security Modules (HSM) for high value keys. More on AZ KV Keys
Cert - is a managed X.509 certificate, which are built on top of keys and secrets and add an automated renewal feature/auto-rollover. More on AZ KV Certificate
I want to increase my safety of my web app in case of an attack.
The following components are present in my system:
Azure Web App
Azure Blob Storage
Azure SQL Azure
Azure KeyVault
Now there is the scenario that the app encrypts and stores uploaded documents.
This works as described:
1) User Uploads doc to the web app
2) random encryption key is generated
3) random encryption key is stored to the azure key vault
4) sql azure stores the blob url and the key url
Now my question is:
How is using the key vault safer in case of hacking the web app instance? I mean there is the client id and client secret in the app.config to access the keyvault, we need it to read and write keys. So if i use key vault or not does not increase safety in terms of hacking the web app, right?
The Key Vault is an API wrapped around an HSM. What makes the Key Vault or HSM Secure is that the keys can not be extracted from them once imported / created. Also, the crypto (encrypt / decrypt in your case) operations happen inside the vault so the keys are never exposed, even in memory.
If someone was able to hack your web application and get the credentials to your key vault they could use the vault to decrypt the data. So, in this case you could regenerate the credentials for the Key Vault and still continue to use the same keys that are in the vault - because they were never exposed. Meaning any data that is encrypted that the attacker didn't already decrypt is still safe because the keys were never exposed.
Typically HSMs aren't designed to store a large number of keys in only a few really important keys. You might want to consider using a key wrapping solution where you have one key in the vault.
You probably want to encrypt the client id and client secret in your config and decrypt them at runtime - this adds another layer of security. Now the attacker either needs to read the keys out of your application memory while it is running on your Cloud Service / VM (not an easy task). Or the attacker would need to obtain the config file and the private key of the certificate used to encrypt your config values (easier than reading memory, but still requires a lot of access to your system).
So if i use key vault or not does not increase safety in terms of
hacking the web app, right?
It all depends at what level they were able to hack the site. In the case you describe, if they obtained your source code then - yes, its game over. But it doesn't have to be that way. It truly comes down to your configuration.
However, most of the time, developers forget that security is a layered approach. When you're talking about encryption of data and related subjects, they are generally a last line of defense. So if a malicious actors has acquired access to the encrypted sensitive data they have breached other vulnerable areas.
The problem is not Key Vaults but your solution of using client secret. Client secret is a constant string which is not considered safe. You can use certificate and thumbprint as a "client secret". Your application needs to read the .pfx file which is stored in web app, then decrypt to grab thumbprint. Once thumbprint is retrieved successfully then you Key Vault secret is retrievable. Moreover, in Key Vault you are given the ability to use your own certificate rather than just a masked string in Secret. This is so-called "nested encryption".
The hacker if getting access to your app.config, he get nothing than the path of .pfx file which he does not know where to store, even how it looks like. Generating the same pfx file becomes impossible. If he could he would break the entirely crypto world.
I am developing a .NET application that uploads files to Azure Storage. I am leveraging client-side encryption as done in the tutorial at https://azure.microsoft.com/en-us/documentation/articles/storage-encrypt-decrypt-blobs-key-vault/
The application works, i.e. I can successfully upload an encrypted blob to a selected storage account and container.
However, I have some concerns about the security of the RSA key. If the client application gets the key from Key Vault to use in the BlobEncryptionPolicy, that key could get compromised? The only thing the application really needs is the public key of the RSA pair, the private key should remain stored on the server (decrypting only happens by a trusted web app).
The other concern I have is that it is trivial for the AAD integration info to be obtained from the app.config. How does one work around that?
(note: the workstations on which the upload app will run are not necessarily trusted)
Some additional reading of the Azure Storage and Key Vault walkthrough document at https://azure.microsoft.com/en-us/documentation/articles/storage-encrypt-decrypt-blobs-key-vault/ has provided the answer:
"The Storage client itself never has access to KEK."
The KEK is the "Key Encryption Key" which encrypts the actual one-time-use symmetric encryption key used to encrypt the actual blob.
All you need is a public key to encrypt a random symmetric key and use that symmetric key to encrypt your data. The server process (Function or similar) has access to the private key used to decrypt the symmetric key, and then decrypt the blob. Access the the private key, held in KV, can be restricted using RBAC policy and applying a managed identity to the process that needs to read the private key.
Finally, the public key really should not be a naked key, it should be in a X.509 cert so you can verify the authenticity of the server end point.