In SQL-Server's Always Encrypted feature, is there a way to store the Master Key in a Centralized Key Vault?
I know I can use Azure Key Vault or Local Windows Key Store. But I was looking for another option to have it outside the server. For example, Symantec Encryption Management Server(pdf).
Related
The RDS User Guide says there are two ways to enable encryption of an RDS instance:
When you create it
You do it through (not shared) snapshot:
you can create a snapshot of your DB instance, and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.
I want to understand what level this encryption is applied to.
My guess is that the encryption only applies to each cell in the table. Otherwise, if the entire database is encrypted as a whole, then the schema, the table name, the column name cannot be seen, then how can an instance be restored from it?
Is my understanding correct?
only applies to each cell in the table
It does not. Its the entire EBS snapshot that is encrypted.
then how can an instance be restored from it
AWS will use your or AWS managed keys from KMS (AWS Key Managment Service) to decrypt your snapshot. This happens in the background and you don't see it. If you use your own KMS key, and you delete it, then your snapshots can't be decrypted and you loose all your data.
More on the EBS encryption is in How Amazon Elastic Block Store (Amazon EBS) uses AWS KMS
My project has a requirement to encrypt a sensitive field column in SQL server table but the encryption/decryption key shall be kept outside SQL environment to ensure maximum data security.
Thycotic server is one secret server to store and secure passwords. I am trying a POC to check if encryption key can be generated via Secret server and can be used to encrypt table column in SQL server.
I haven't found much related to this on the Thycotic website or on google.
How can this be achieved if feasible?
My requirement is:
Data from Azure Blob will load into Azure SQL server with 10 columns.
I need to encrypt the data for 3-4 columns in Azure SQL server.
Is it possible with Azure Key Vault?
Is this possible or is there any other secure way to do encryption in Azure SQL?
Yes, it's called Always Encrypted (also: Column-based Encryption). See here how to implement it: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-always-encrypted-azure-key-vault?tabs=azure-powershell
BTW it is Key Vault not Key Volt, From the docs Definition
Azure Key Vault is a tool for securely storing and accessing secrets.
A secret is anything that you want to tightly control access to, such
as API keys, passwords, or certificates.
Is it possible with Azure Key Volts?
No
If you want to encrypt data columns of SQL server you need to use Encryption at Rest
I have a lack of understanding regarding a particular area of TDE within Microsoft SQL Server (in my case, SQL Server 2016). Specifically what certificates/keys are required to restore an encrypted database on another server.
Microsoft Docs highlight the encryption hierarchy, running from service master key, database master key, certificate and database encryption key. It highlights the necessity of creating backups of the certificate to prevent data loss. It doesn't really mention anything of backing up anything above the certificate in the hierarchy.
However a Redgate article describes backing up the service master key and database master key in addition to the certificate.
In practice I am able to restore an encrypted database on another server using only the saved certificate/private key.. so what am I missing? If the certificate is protected by a master key that is not available, how does it work? Is that part of the encryption 'internal-only' - if so is there any instance where I would need to restore the service master key or database master key from a backup? I suppose keeping a backup of those wouldn't hurt anyway?
Many thanks
I've successfully restored a TDE-encrypted database onto a server that has only the certificate that was used for TDE. Said another way, the destination server had neither matching a matching database master key (DMK) on the master database nor a matching service master key (SMK). So long as the DMK for the master database is encrypted with the SMK on the target and the TDE certificate's private key is loaded into master and encrypted with that DMK, you should be good to go.
But! For something like this, you shouldn't take my (a random guy on the internet) word for it. This fundamentally affects your ability to restore your database. Restore-ability is Job One™ for a DBA, you should try it and convince yourself that not only what I'm saying is true but also that you can do it.
Also, as part of that restore plan, take that certificate (along with its private key), back it up to disconnected media, and put it somewhere for safe keeping (I like to give it to the legal department).
Consider an SQL Server in Azure with transparent data encryption enabled, and with the use of Azure Key Vault for key management. Data is encrypted at-rest in the Azure data center in <whatever> country, but the Key Vault sits on-premise in the customer's own data center.
Applications (also hosted in Azure and thus being physically placed in <whatever> country) can access the database from the time a successful round-trip to the Key Vault has been made.
To what entity is the data access bound (which entity holds the symmetric key)? Is it the database that holds the symmetric key so that all incoming connections will be able to see the unencrypted data? Or is the key stored per connection so that the database re-connectes to Key Vault when each new connection is established?
We would like to be able to shut down the database access, solely by shutting down the on-premise Key Vault. That is: no matter what happens to the data center, data access in the cloud can always be stopped from the Key Vault. Data can be decrypted only because the key is cached somewhere. Can we force the caching to timeout after, say X, seconds, thereby forcing the database to reconnect to Key Vault and ask for the key again? This would allow us to shut down the Key Vault, rendering the data useless after these X seconds.
SQL Server doesn't support an external DEK - it is stored in the database encrypted by the DEK protector, a cert or asymmetric key which can be in the Key Vault. In this scheme, the key vault is not needed on every I/O, but there is a timeout after which SQL Server needs the key vault to unwrap the DEK again.