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.
Related
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.
I need to build a web app that accesses some encrypted columns on a DB. All must be hosted in the client's azure account. I have searched for a couple of days and read a lot of tutorials but I can't find an answer to my problem.
I have mainly followed these:
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-always-encrypted
http://www.bradleyschacht.com/always-encrypted-with-azure-key-vault/
I was able to run a web app on my machine with the certificate generated by SSMS encryption wizard and a SQL DB hosted on azure. I couldn't do it with an azure vault key.
Now I need to publish my web app on azure but I'm unable to access/modify the DB data. I need to either use the certificate from my machine or use the azure vault. Can anyone explain to me how it's done?
I tried to export the certificate to the azure vault, but I don't know how to "reference" it
I tried to create a new table on the db and encrypting it with a vault key, but I get:
Failed to decrypt a column encryption key. Invalid key store provider
name: 'AZURE_KEY_VAULT'. A key store provider name must denote either
a system key store provider or a registered custom key store provider.
Valid system key store provider names are: 'MSSQL_CERTIFICATE_STORE',
'MSSQL_CNG_STORE', 'MSSQL_CSP_PROVIDER'. Valid (currently registered)
custom key store provider names are: . Please verify key store
provider information in column master key definitions in the database,
and verify all custom key store providers used in your application are
registered properly."
I read somewhere that I need to give permission in the AD to my application, but I don't have permissions from my client (the owner of the Azure subscription) to do that.
I read also that a stored procedure must be used to read and write to the DB. Is this true?
Thanks in advance for any help.
I need to either use the certificate from my machine or use the azure
vault. Can anyone explain to me how it's done?
It depends on your use-case. Actually Selecting Keystore Provider for your Column Master key is depends on which driver and version you are using. There are two high-level categories of key stores : Read here
Local
Centralized Key Store
Local
If you planning to deploy your App in On-Prem/VM, then you can generate our own Certificate and keep the certificate within your Local VM.
Centralized Key Store
If you planning to deploy your App in azure web APP/Cloud then you should keep your Key Store in a centralized Secure Vault which may be here as Azure Key Vault
As a best practice, you should not store the provider in the Local machine, Which would be a problem if you VM is compromised then your DB certificate also be compromised.
I tried to export the certificate to the azure vault, but I don't know
how to "reference" it
CREATE COLUMN MASTER KEY [TESTMASTERKEY]
WITH
(
KEY_STORE_PROVIDER_NAME = N'AZURE_KEY_VAULT',
KEY_PATH = N'' --Paste your Key Identifier
)
GO
I tried to create a new table on the DB and encrypting it with a vault
key, but I get:
Always try to download the latest SSMS version.
Assume you are using Azure SQLDB. Always encryption will work only on SQL Server
2016 and above in on-prem and all versions of Azure SQLDB
Set the connection string to Column Encryption Setting=enabled
The behavior you describe is a bug in CTP 3.0 and SSMS October update. The issue, as you surmised, is that the Azure Key Vault provider is not registered if you open the Query Editor window opening the Always Encrypted wizard first. We’ve already fixed this for the next update of SSMS! In the meantime, the workaround is to open the Always Encrypted wizard (you can close it/cancel immediately after opening) which will cause the Azure Key Vault provider to get registered.
This bug manifests itself only through this specific case (using the Query Editor before the wizard), and won’t at all impact your ability to use the Always Encrypted wizard or use the Azure Key Vault provider with any of your client applications.
So try to download the latest SSMS version.
I read somewhere that I need to give permission in the AD to my
application, but I don't have permissions from my client (the owner of
the Azure subscription) to do that.
This is mainly for the Client side. You need to register your app in order to get the client id and client secret for your client-side application to talk with encrypted data in DB. Read here for how to register your client app. Unless you register your app, you couldn't able to connect from any client-side(Except SSMS). You need to contact the subscription owner to register the app.
I read also that a stored procedure must be used to read and write to
the DB. Is this true?
Depends on your Encryption Type. There are two types of Encryption Read here about it
Deterministic
Randomized
Each having its own pro and cons.
Deterministic encryption always generates the same encrypted value for any given plaintext value. Using deterministic encryption allows point lookups, equality joins, grouping and indexing on encrypted columns. However, but may also allow unauthorized users to guess information about encrypted values by examining patterns in the encrypted column, especially if there is a small set of possible encrypted values, such as True/False, or North/South/East/West region. Deterministic encryption must use a column collation with a binary2 sort order for character columns.
Randomized encryption uses a method that encrypts data in a less predictable manner. Randomized encryption is more secure, but prevents searching, grouping, indexing, and joining on encrypted columns.
Full explanation of all aspects related to this topic here: https://www.codeproject.com/Articles/5355073/Full-Tutorial-on-using-Always-Encrypted-with-Azure
I tried to cover in the article both legacy projects and new approaches and also transition phase.
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
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/)
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.