4. Implementing TDE
In this section, we will implement TDE using the HomeLending
database. Our TDE implementation, in comparison to cell-level
encryption, will be very simple. There are no modifications to the
schema required, there are no permissions that need to be granted to
database users and roles in order to use TDE, and there are no
additional database objects that must be created to perform the
encryption and decryption methods.
On the other hand, the person performing the implementation of TDE does require specific permissions; namely CONTROL permissions on the Master and HomeLending databases. It is recommended to perform this process while the database is not in use by other users.
4.1 Backup before Proceeding
It is a general best practice to backup a database
prior to making modifications. However, it is especially important when
implementing TDE, in order to ensure that, should the TDE
implementation need to be reversed, you can cleanly recover the
database in its original form.
In addition, by performing a database backup, a new checkpoint will be
established in the transaction log. The creation of a checkpoint
truncates all inactive items in your transaction log prior to the new
checkpoint. This will ensure that your transaction log is free from
unencrypted items, prior to the TDE implementation. Listing 1 shows the backup command for the HomeLending database.
With the backup successfully completed, we can begin the process of implementing TDE.
4.2 The Master Database
Our first step is to create a database master key for our Master database, using the CREATEMASTERKEY method, as shown in Listing 2.
Notice that, while ENCRYPTEDBYPASSWORD is a required argument to the method,
is to instead protect the database master key with the service master
key. This option is automatically available to us, upon creation of the
database master key.
A search against the sys.key_encryptions catalog view for the ##MS_DatabaseMasterKey## key, as shown in Listing 3, returns ENCRYPTION BYMASTERKEY, in reference to the service master key.
The next step is to create a self-signed certificate that is protected by the database master key of our Master
database. All certificates created within SQL Server, as opposed to
being imported, are self-signed. This associates the certificate to the
database.
Certificates are created using the CREATECERTIFICATE method. Since this certificate is located in the Master database and will be used to protect the database encryption key of our HomeLending database, we will name this certificate MasterCert, as shown in Listing 4.
By omitting the ENCRYPTIONBYPASSWORD argument, we are specifying that the certificate is to be protected by the database master key.
At this point in the process you should perform a backup of the certificate with its private key, using the BACKUPCERTIFICATE command shown in Listing 5. In the event that the HomeLending database needs to be restored, this certificate and its private key will be required.
Since our MasterCert certificate is protected by the Master database master key, the DECRYPTIONBYPASSWORD argument is not included in the WITH PRIVATEKEY argument of this command.
