SQL Database TDE is based on SQL Server’s TDE technology which encrypts the storage of an entire database by using an industry standard AES-256 symmetric key called the database encryption key. SQL Database protects this database encryption key with a service managed certificate. All key management for database copying, Geo-Replication, and database restores anywhere in SQL Database is handled by the service – just enable it on your database with 2 clicks on the Azure Preview Portal: click ON, click Save, done.

Transparent Data Encryption for Azure SQL Database is built on top of the same Transparent Data Feature that has been running reliably on SQL Server since 2008. We have made updates to this core technology that will be available cloud first on Azure SQL Database, including support for Intel AES-NI hardware acceleration of encryption. This will reduce the CPU/DTU overhead of turning on Transparent Data Encryption.

Additionally, Transparent Data Encryption is built on top of the secret management service we use to isolate Azure SQL Database Tenants. Azure SQL Database has for years securely managed the hardware and virtual machines that Azure SQL Database runs on top of, as evidenced by the many certifications and audits we have passed – see the Microsoft Azure Trust Center for more details. We use this infrastructure to manage unique certificates per Azure SQL Database Server to protect your database encryption keys. We also use it to distribute these certificates as needed when you restore your database to a new server or setup a Geo-Replication – and update these when the certificate is rotated every 90 days for you. This enables a seamless experience where you just turn on Transparent Data Encryption and use the service without having to think about certificates or keys.

We hope this meets many of your needs for Encryption at Rest in a manner that lets you focus on the work that is important to you. For more information, see MSDN.

Join the conversation

Great! Love this! With TDE in place, will we be able to query using SQL Server management studio and the results be readable or will they show encrypted? If yes, that makes sensitive data available to our employees which could be a negative thing from a security standpoint, but a positive thing for troubleshooting. Thanks!

Symmetric encryption isn't that much less secure than asymmetric? My understanding is that in symmetric encryption the same key is used to encrypt as to decrypt, so if one gets compromised then it's game over.

Symmetric key is actually a stronger encryption at significantly shorter bit lengths than asymmetric key encryptions – it's trade-off is, as you mention, is key exchange. Asymmetric keys are much slower and require much larger keys to provide equivalent encryption, but allow separate keys for encryption and decryption.

The industry standard solution is to encrypt data using a symmetric key and then encrypt the symmetric key using an asymmetric key to make it easier to exchange the symmetric key. This is what TLS, bitlocker, and TDE do, to name a few. Nothing new here with TDE for Azure SQL DB – just continuing and industry best practice.

That is a great news for us, we were waiting for this and it came in at the right time for us. I have a few questions

1. As mentioned in your note "TDE is built on top of the secret management service we use to isolate Azure SQL Database Tenants". Does this mean there will be a separate Key / certificate for each of our tenant in case we have multi tenant Azure SQL DB

2. Is there a way that our tenants can own / possess and store their key / certificate with them so that we as their vendor do not get access to their data unless they explicitly provide us access to their key / certificate.

Thank you so much for your quick response, this is very helpful. I had following further questions

1. If we have a multi tenant single database with Tenant_ID filter as a logical separator between individual tenant data within a single database then can we use a separate Key for each tenant ?

2. I believe Azure Key vault is the service which manages the key in this case. Can we give admin access of azure Key vault to our customers so that they can manage their own key ? Can we use Azure Key Vault in multi tenant model ?

2. Azure Key Vault's unit of isolation is a vault, not an individual key. Giving access to a vault means giving access to every key within that vault. Of course this is all theoretical as SQL Database does not yet integrate with Key Vault.

Glad to hear AES-NI being called for the encryption/decryption operations. Any information if that has made its way into SQL Server 2016 and possibly some of the earlier versions? I submitted a Connect request for this a while back and it seemed like it might happen at some point in the future.

Yes, Joie – checkout 2016 CTP 2 to see TDE with AES-NI in action. We had an engineer putting in overtime (weekends, birthdays, anniversaries, etc. – we really owe him!) to get this done in the core engine and then it was a race to see whether SQL 2016 or Azure SQL DB would ship it first :-). We're excited to finally deliver this to our customers (and hopefully enjoy future anniversaries, birthdays, and weekends :-)).

Thank you! I'm using an unstable 3rd party managed database to reach HIPAA compliance in my business. It's been a nightmare. I'll start to plan my move to Azure now! Am I able to start using this in production?

Generally we do not recommend using preview features in production environments, but if you reach out to me directly (jack.richins at microsoft.com or dm my twitter account in my profile), we may be able to arrange supporting you depending on your needs.