SQL Server 2005 introduced the ability to encrypt data at rest, meaning data stored within the database itself. Known as cell-level encryption,
this was a welcome addition to the other encryption features in earlier
versions that allowed encryption of data in transit, such as network
encryption with SSL.
While cell-level encryption is a valuable
enhancement, it requires changes to both applications and database
schema to work. Most notably, the columns chosen for encryption have to
be changed to the varbinary data type, and encrypted data is read and
written with functions, requiring changes to application code, stored
procedures, or both.
As a result, cell-level encryption in SQL Server
2005 is typically used in limited situations and for specific data, such
as credit card details or passwords. What's missing is a way of
encrypting everything without requiring any database schema or application changes. Enter SQL Server 2008 and Transparent Data Encryption.
1. Transparent Data Encryption
ransparent Data Encryption (TDE) allows us to
encrypt the entire database without requiring any changes to the
structure of the database or the applications that access it. It
protects the database in situations where someone breaches physical and
login security and obtains access to the .mdf (data) files or .bak
(backup) files. Without TDE or another third-party encryption solution,
the files could be taken offsite and attached or restored.
Later in this section we'll look at some of the
restrictions of TDE that may limit its usefulness in certain situations.
For the moment, though, let's take a look at implementing TDE with
T-SQL scripts.
Encrypting a database
The first step in implementing TDE is in creating a master key.
Intended to protect the private keys of certificates and other keys,
the master key is created as a symmetric key using the Triple DES
algorithm along with a password supplied by the user creating it:
-- Create a Master Key
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'jGKhhg6647##tR';
GO
Next, we create a certificate, used to protect the database encryption key, which we'll create shortly:
-- Create a Certificate
USE MASTER
GO
CREATE CERTIFICATE tdeCertificate WITH SUBJECT = 'TDE Certificate';
GO
At this point, it's crucial that we back up the
certificate. When a TDE-encrypted database is backed up, the backup
itself is encrypted. If we want to restore an encrypted database to
another server, the certificate used to encrypt the database needs to be
loaded to the other server to enable the database to be restored.
Further, should we suffer a catastrophic server failure, the newly
installed server will also require the certificate in order to restore
the database.
The certificate backup should be stored in a
secure location, and ideally separated from both the database backups
and private key backup. We can back up the certificate and private key
as follows:
-- Backup the certificate
-- Required if restoring encrypted databases to another server
-- Also required for server rebuild scenarios
USE MASTER
GO
BACKUP CERTIFICATE tdeCertificate TO FILE = 'g:\cert\tdeCertificate.backup'
WITH PRIVATE KEY (FILE = 'e:\cert\tdeCertificatePrivateKey.backup',
ENCRYPTION BY PASSWORD = 'jjKiid_%%4-9')
GO
Now, let's change focus from the master database
to the database we want to encrypt (AdventureWorks in this example) and
create the database encryption key (DEK), used for encrypting the database with Transparent Data Encryption:
-- Create a Database Encryption Key
USE [AdventureWorks2008]
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE tdeCertificate
GO
In this example, we used the AES encryption
algorithm with a 128-bit key. In addition, 192- and 256-bit keys are
supported, as well as Triple DES. Now that we've created our DEK, we can
encrypt the database:
-- Encrypt the database using Transparent Database Encryption (TDE)
-- Encryption will proceed as a background task
-- Use the sys.dm_database_encryption_keys DMV to check progress
ALTER DATABASE [AdventureWorks2008]
SET ENCRYPTION ON
GO
The encryption process will now start as a
background task. During this time, some functions, such as modifying the
database files and detaching the database, won't be available. The
sys.dm_database_encryption_keys Dynamic Management View (DMV), fully
described in BOL, can be used to inspect the progress of the encryption
process.
Finally, earlier we discussed the need to back
up the certificate for recovery purposes and to enable encrypted
databases to be restored to another server. Attempting to restore a
backup of a TDE-encrypted database to another server that doesn't have
the appropriate certificate installed will result in failure of the
restore process, resulting in an error like that shown in figure 2.
Let's take a quick look at the process of
restoring a certificate on another server in preparation for restoring
an encrypted database:
-- Create the Master Key if it doesn't already exist
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'jGK__g6647##tR';
GO
-- Restore the Certificate
CREATE CERTIFICATE tdeCertificate
FROM FILE = ' g:\cert\tdeCertificate.backup'
WITH PRIVATE KEY (FILE = 'e:\cert\tdeCertificatePrivateKey.backup'
, DECRYPTION BY PASSWORD = 'jjKiid_%%4-9');
GO
Now that the certificate is loaded on the new server, we can successfully restore backups of the TDE-encrypted database.
Despite the clear advantages of Transparent Data Encryption, there are a number of restrictions to be aware of.
TDE restrictions
The key restrictions of TDE are summarized as follows:
While data at rest is encrypted, data
transmitted over the network is not, we can use SSL or IPSec to achieve this.
TDE
decrypts data as it's read into memory, meaning that if a person or
process is able to access the memory contents of the server, the data
could potentially be accessed in an unencrypted form.
While
the CPU overhead of TDE is moderate (Microsoft estimates a 3- to
5-percent overhead), it's a consideration nonetheless for systems close
to CPU capacity. In large databases with only a small percentage of
sensitive data, cell-level encryption (discussed shortly) may present a
better alternative,
The tempdb database will be automatically encrypted on a SQL Server instance in which any
of the databases are encrypted with TDE. This is an important
consideration in instances in which there are one or more databases that
make heavy use of the tempdb database.
FileStream data,
can't be encrypted with TDE. For a TDE-encrypted database containing
sensitive FileStream data, consider alternate means of securing such
data.
The new backup compression feature in SQL Server 2008 has minimal effects on databases encrypted with TDE, with a very low
compression yield. For this reason, enabling backup compression on
TDE-encrypted databases isn't recommended.
With these restrictions in mind, cell-level encryption may prove to be a better alternative in particular cases.
2. Cell-level encryption
Typically, only certain parts of a database are
sensitive enough to require encryption. Cell-level encryption, first
introduced in SQL Server 2005, offers a more granular level of
encryption compared to TDE, and for custom-written applications the
additional work required in altering application code and database
schema may be quite manageable.
Although data encrypted with cell-level
encryption is still transmitted over the network in an unencrypted form,
it avoids some of the restrictions of TDE, such as the impact on
tempdb, and depending on the volume of data encrypted, may yield a much
better backup compression ratio compared to that of a TDE-encrypted
database. A further benefit of cell-level encryption is that the
encrypted data remains encrypted until required and explicitly
decrypted. As we mentioned earlier, one of the restrictions of TDE is
that data is stored in an unencrypted form in memory, leaving it
susceptible to inspection.
