it need to have some understanding on Azure storage account encryption.
MS docs are bit confusing/missing some details.
I know there are 2 ways of encrypting the data in Storage account
Server-side encryption
(SSE) which is default behavior and MS in this case holds and maintain all the keys (CEK and KEK)
using CMK which encrypts the key that encrypts the data (KEK) and customer is responsible for maintaining just the KEK? or both? is so, how?
Client side encryption - all the details here pretty understandable.
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
On this page about secret management on cloud.google.com, there is a paragraph that reads:
Use application layer encryption using a key in Cloud KMS. With this
option, you implement encryption on objects or buckets in Cloud
Storage on top of existing Google encryption, using a key stored in
Cloud KMS. This is the recommended option.
Right below that, the next paragraph states that Google Cloud Storage encrypts data by default at rest:
Use the default encryption built into the Cloud Storage bucket. GCP
encrypts customer content stored at rest, using one or more encryption
mechanisms. As the name implies, this encryption is available by
default and requires no additional action on your part.
For the uninitiated, why is application-layer encryption recommended here? If the GCS bucket(s) that store your objects are protected with IAM, and GCS already encrypts that data, what benefits are gained?
It’s about who controls the keys, when the data is encrypted, where the data is encrypted, and who encrypts the data.
With GCS only, your data is encrypted at rest with keys Google stores and manages. You can’t revoke Google’s keys here. Additionally, the data is only protected at rest and in transit with TLS (but any person or app with the ability to terminate that TLS would see the secret in plaintext).
With GCS + KMS (often called “Customer Managed Encryption Keys” CMEK), data is encrypted before it’s written to GCS. GCS only stores the encrypted data (which is then encrypted again with keys Google manages). You, the customer, have full control over the rotation and revocation of those encryption keys. You can also use HSM-backed keys with Cloud HSM. Additionally, when following best practices, the data is protected in transit. Even if someone terminates TLS, the secret remains encrypted until something with IAM permission to decrypt the value does so.
If you’re looking for an opinionated way to store secrets on GCP, check out berglas.
We have a windows service which monitors a folder (using filewatcher of C#) for files and uploads the files to a blob. Windows service retrieves the Write only SAS token , which is used to generate the blob client to upload to a blob, from a WebAPI endpoint(TLS 1.2) secured with ADFS 2.0 by passing the JWT retrieved from ADFS WS-Trust 1.3 endpoint passing user name and password.
My experience is limited in the area of security. I have two questions.
1- Should there be an encryption before I upload the data to blob? If yes, how can I implement it.
2- Would retrieving the SAS token from an endpoint, even though it is secured with ADFS and is over https, possess any kind of security risk
1- Should there be an encryption before I upload the data to blob? If yes, how can I implement it.
Per my understanding, if you want extra security during transit and your stored data to be encrypted, you could leverage Client-side encryption and refer to this tutorial. At this point, you need to make programmatic changes to your application.
Also, you could leverage Storage Service Encryption (SSE) which does not provide for the security of the data in transit, but it provides the following benefit:
SSE allows the storage service automatically encrypt the data when writing it to Azure Storage. When you read the data from Azure Storage, it will be decrypted by the storage service before being returned. This enables you to secure your data without having to modify code or add code to any applications.
I would recommend you could just leverage HTTPs for your data in transit and SSE to encrypt your blobs. For how to enable SSE, you could refer to here. Additionally, you could follow here about Azure Storage security guide.
2- Would retrieving the SAS token from an endpoint, even though it is secured with ADFS and is over https, possess any kind of security risk
SAS provides you with a way to grant the limited permissions to resources in your storage account to other clients. For security consideration, you could set interval over which your SAS is valid. Also, you could limit the IP addresses which could Azure Storage would accept the SAS. Per my understanding, the endpoint for generating SAS token is secured with ADFS 2.0 over HTTPs, I assumed that it is safe enough.
I would appreciate clarification and advice on the following:
My project requires me to use symmetric data encryption (using AES), in a Nodejs environment, to secure data on a database (mongodb). Ideally, I would like to do this as follows:
Store the symmetric key in Azure Key Vault as a Key, then make 'encrypt' calls to the vault to perform AES encryption on the data with the Key. The encrypted data is sent in the response to my app and then stored in the database in its encrypted form.
I am confused after reading MS Azure's documentation and related blog posts, where some sources claim symmetric key encryption is supported, but there is no official documentation on this.
Can anyone advise whether this an exhaustive list of all key types and algorithms supported for Azure's Key Vault?
https://msdn.microsoft.com/en-us/library/azure/dn903623.aspx#BKMK_KeyTypes
It also seems this may be an option (http://www.nuget.org/packages/Microsoft.Azure.KeyVault.extensions) but only for environments on .NET. Any love for Nodejs?
If indeed symmetric keys/encryption are not currently supported, can anyone offer an alternative means to my approach described above?
Thanks and much appreciated.
I agree the documentation/blogs do seem a little confusing on this topic. From my understanding the key vault does not yet currently support symmetric encryption. I believe the closest you can get is storing symmetric keys as secrets and using them outside of the vault.
This article talks about doing such. See the section where the heading is Use Key Vault secrets
I understand your using node.js and that example is in powershell just trying to illustrate the example of symmetric encryption with a secret. Obviously the crypto operations happen outside the vault. So, at rest the keys are more secure but do get exposed in memory anytime an operation occurs.
Hope that helps.
Here is an example in PowerShell of creating a secret in Key Vault that can be used as a SymmetricKey.
SymmetricKey sec = (SymmetricKey) cloudResolver.ResolveKeyAsync(
"https://contosokeyvault.vault.azure.net/secrets/TestSecret2/",
CancellationToken.None).GetAwaiter().GetResult();
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.