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
Related
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).
I have a TDE protected database which I want to extend to Azure using replication. My question is, do I have to restore certificate on the Azure database before I start setting up the database as the subscriber?
do I have to restore certificate on the Azure database before I start setting up the database as the subscriber?
No. Per docs:
"Replication does not automatically replicate data from a TDE-enabled database in an encrypted form. You must separately enable TDE if you want to protect the distribution and subscriber databases. Snapshot replication, as well as the initial distribution of data for transactional and merge replication, can store data in unencrypted intermediate files; for example, the bcp files. "
Transparent Data Encryption and Replication
What is the difference between using SQL Server SSL (Encrypted=true in the connection string) + TDE, vs using SQL Server Always Encrypted?
With regards to RGPD, is one more adapted than the other?
Always Encrypted exists to solve more than just the issue of making sure data is encrypted in-transit. In fact, that's not even the primary concern that Always Encrypted solves.
The big issue that Always Encrypted solves is that with Transparent Data Encryption (TDE), the keys and certificates which secure the encrypted data are themselves stored in the database. This could be a concern for someone considering putting their SQL Server database in the cloud, because the cloud provider then ultimately has the secrets for decrypting the data.
With Always Encrypted, the Column Encryption Key (CEK), which is used to encrypt/decrypt column data, is stored in the database in its encrypted form. But here's the kicker - the key used to encrypt/decrypt the CEK is stored outside the database, leaving the database unable to decrypt the data on its own.
All the database can do is
Provide the encrypted CEK,
provide the location of the CMK, and
serve/store pre-encrypted data.
It's up to the client to get the Column Master Key (CMK) from the key/certificate store wherever that's located, then use the CMK to decrypt the CEK, and use the decrypted CEK to encrypt/decrypt data.
So that's the conceptual difference. Here are a couple pages that go into the details of it:
Overview of Key Management for Always Encrypted (Microsoft docs)
SQL Server Encryption: Always Encrypted (Redgate article)
Be aware that Always Encrypted comes with some hefty drawbacks with regard to querying data and other things. This article gives a pretty good list of limitations. Some of these drawbacks can be mitigated using Always Encrypted with secure enclaves.
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.