I would like to know if Azure Storage's Client-Side encryption also applies to file blobs or just strings. I could find some documents on how to do client-side "data encryption" for Azure but they don't specify what data types are valid for client side encryption.
If for example, I have a JPEG file, can it be encrypted before upload and then decrypted before download, using the Azure Storage's Client Side Encryption?
Short answer: Yes.
If you have a JPEG file (or for that matter any file) you will be able to encrypt that file and store it in encrypted format in Azure Storage. It doesn't just apply to strings only.
There are some caveats though for client side encryption to work and for that I suggest you read this article on Azure documentation site which explains the whole process very well: https://learn.microsoft.com/en-us/azure/storage/storage-client-side-encryption.
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 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 would like you please to guide me, and let me know if it's possible to encrypt data in the hard-drives (Azure), they are sensitive videos and images, I am retrieving them via a website, but I want them to be encrypted in the hard drive as second challenge if there is any attack on my server.
Is it possible to do it and in the same time the encrypted data will be indexed in the website and watchable?
The problem with encryption is who hold the keys. With asymmetric encryption it is certainly possible to store encrypted files (either in blob storage or elsewhere) and then decrypt them.
However, if your website can decrypt them then they hold the keys. So if your website is compromised and exposes that key then anyone can read them.
The question becomes what kind of attack/server intrusion are you really trying to avoid.
One approach might be 2 servers. 1 with your website and 1 with storage and then set up a connection between those servers in such a way that your storage is only accessible from your first server.