Announcing Transparent Data Encryption for Azure SQL Database

Available today, SQL Database Transparent Data Encryption (preview) protects your data and helps you meet compliance requirements by encrypting your database, associated backups, and transaction log files at rest without requiring changes to your application.

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.

UPDATE: I've added a post with known issues.

Comments

• Anonymous
  April 29, 2015
  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!

• Anonymous
  April 29, 2015
  Queries will be readable - TDE only protects the files as rest, not in memory.

• Anonymous
  May 04, 2015
  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.

• Anonymous
  May 04, 2015
  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.

• Anonymous
  May 04, 2015
  Jack, thanks for your insight here. I didn't know the encryption/decryption key was also encrypted. Makes sense obviously.

• Anonymous
  May 10, 2015
  Hi Jack, 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.

• Anonymous
  May 11, 2015
  Shishir,

1. Each database gets a unique key and each server gets a certificate which it uses to protect all databases of that server.
2. Currently, we only support service managed keys so that we can maintain availability guarantees at all times.

• Anonymous
  May 11, 2015
  Hi Jack, 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 ?

• Anonymous
  May 12, 2015

1. Database Encryption Keys are a single key per database. If you want different encryption keys within a single database, consider Cell Level Encryption. See blogs.msdn.com/.../recommendations-for-using-cell-level-encryption-in-azure-sql-database.aspx.
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. You can use with Key Vault integration using SQL Server within an Azure VM. See blogs.technet.com/.../using-the-key-vault-for-sql-server-encryption.aspx.

• Anonymous
  June 09, 2015
  Thanks Jack, good info!  Any idea on when this will be promoted to General Availability?  It's recommended that we not use Preview in production.  Thanks.

• Anonymous
  June 09, 2015
  We are not prepared to discuss GA dates publicly yet - stay tuned for more.

• Anonymous
  June 09, 2015
  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. connect.microsoft.com/.../988715

• Anonymous
  June 09, 2015
  The comment has been removed

• Anonymous
  June 29, 2015
  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?

• Anonymous
  June 30, 2015
  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.

• Anonymous
  July 17, 2015
  Great news! We expect that since V12 announce. Thank you! Are there any plans for EKM support in SQL Azure Database? Can TDE be used in Standard Azure SQL Database Edition?