With the release of SQL Server 2008, Microsoft expanded the database engine’s security capabilities by adding Transparent Data Encryption (TDE), a built-in feature for encrypting data at rest. TDE protects the physical media that hold the data associated with a user database, including the data and log files and any backups or snapshots. Encrypting data at rest can help prevent those with malicious intent from being able to read the data should they manage to access the files.
SQL Server TDE takes an all-or-nothing approach to protecting data. When enabled, TDE encrypts all data in the database, as well as some outside the database. You cannot pick-and-choose like you can with column-level encryption. Even so, TDE is relatively easy to enable, once you’ve decided this is the path you want to travel.
In this article, we look at how to implement TDE on a user database. The article is the second in a series about SQL Server encryption. The first one ( Encrypting SQL Server: Using an Encryption Hierarchy to Protect Column Data ) covers column-level encryption. If you’re new to SQL Server encryption, you might want to review that article first.
The TDE encryption hierarchyWhen I introduced you to column-level encryption, I discussed the encryption hierarchy and how SQL Server uses a series of keys and certificates to protect column data. The approach used for implementing TDE is similar, but different enough to take a closer look.
As with column-level encryption, the windows Data Protection API (DPAPI) sits at the top of the hierarchy and is used to encrypt the service master key (SMK), a symmetric key that resides in the master database. SQL Server creates the SMK the first time the instance is started. You can use the key to encrypt credentials, linked server passwords, and the database master keys (DMKs) residing in different databases.
In the TDE encryption hierarchy, the SMK sits below the DPAPI, and a DMK sits below the SMK. The DMK is a symmetric key, just like you find with column-level encryption. However, with column-level encryption, you create the DMK in the user database where the column data will be encrypted. With TDE, you create the DMK in the master database, even though you’ll be encrypting a user database. SQL Server uses the SMK and a user-supplied password to encrypt the DMK with the 256-bit AES algorithm.
Before we go any further with our description, take a look at the following figure, which shows the entire TDE encryption hierarchy, starting with the Windows DPAPI at the top and the SQL Server data at the bottom. As you can see, the next level down our hierarchy is a certificate, which you also create in the master database.
The DMK protects the certificate, and the certificate protects the database encryption key (DEK) in the user database. The DEK is specific to TDE and is used to encrypt the data in the user database in which the key resides.
You can skip the DMK and certificate altogether and instead use an Extensible Key Management (EKM) module to secure the DEK. SQL Server 2008 introduced the EKM infrastructure as a way for encryption keys to be stored in hardware outside of the database, essentially integrating the hardware into the encryption stack. That said, the topic of EKM is outside of the scope of this article, but one we might tackle later in this series.
For now, we’ll focus on the TDE encryption hierarchy as it is represented in the figure. From this, we can deduce that to implement TDE on a user database, we must take the following steps:
Create the DMK in the master database, if it doesn’t already exist. Create a certificate in the master database for securing the DEK. Create the DEK in the user database to be encrypted. Enable TDE on the user database.What is not included in the figure or in the steps is the importance of backing up the SMK, DMK, and certificate. If anything goes wrong in our production environment or we need to restore or move an encrypted database, we might need those keys or certificate, so we better make sure we have copies of them, stored securely in a separate location.
Later in the article, we’ll review how to back them up, but first let’s look at how to implement TDE on a user database. For that, we’ll need to set up a test database such as the one shown in the following T-SQL script:
USE master; GO CREATE DATABASE EmpData2; GO USE EmpData2; GO CREATE TABLE EmpInfo( EmpID INT PRIMARY KEY, NatID NVARCHAR(15) NOT NULL, LoginID NVARCHAR(256) NOT NULL); GO INSERT INTO EmpInfo(EmpID, NatID, LoginID) SELECT BusinessEntityID, NationalIDNumber, LoginID FROM AdventureWorks2014.HumanResources.Employee WHERE NationalIDNumber IS NOT NULL;The database and table created here are only slightly different from the ones we created in the first article in this series. The database includes the EmpInfo table and uses an INSERT statement to retrieve data from the HumanResources.Employee table in the AdventureWorks2014 database. However, I’ve named the new database EmpData2 in case you want to retain the database from the other article. (Note that I created all the examples on a local instance of SQL Server 2016.)
You don’t need to use this database to try out the examples in this article. If you have a different one you want to use (and it’s safe to experiment with it), just substitute the name for the database accordingly. You’ll want to keep the database small, however, so you don’t get bogged down during the initial encryption process.
Create the DMKTo create the DMK that will support a TDE-enabled database, you take the same steps you take when creating the DMK to support column-level encryption, except for one important difference. You must create the key in the master database, as shown in the following T-SQL code:
USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'pw1234!';The CREATE MASTER KEY statement supports no optional arguments; we need only specify a password, in addition to the basic syntax. (Of course, we would want to use a more robust password in the real world.)
To verify that the DMK has been created, we can query the sys.symmetric_keys catalog view:
SELECT name KeyName, symmetric_key_id KeyID, key_length KeyLength, algorithm_desc KeyAlgorithm FROM sys.symmetric_keys; _keys;The SELECT statement returns the results shown in the following table.
KeyName
KeyID
KeyLength
KeyAlgorithm
##MS_DatabaseMasterKey##
101
256
AES_256
##MS_ServiceMasterKey##
102
256
AES_256
Notice that the results include both the DMK and SMK. As already noted, SQL Server creates the SMK in the master database automatically. As you can see, the two keys are based on the 256-bit AES encryption algorithm.
Create the certificate The next step is to create a certificate in the