SQL Server 2008的透明数据加密

　　对一个数据库管理员来说，当要保护你所支持的数据库时，安全是要考虑的最重要方面之一。我们使用多种机制和技术来保护我们的数据和数据库，例如防火墙、认证和数据加密。不过尽管我们为我们的环境设置了安全，但是关于数据库安全还总是有问题出现。尽管我们在保护我们的数据库，但是如果有人窃取mdf 文件或备份文件那么会怎么样呢?但是在SQL Server 2008之前没有什么方法来使用第三方解决方案控制这种场景也没有什么本地方法来处理这个问题。SQL Server 2008推出了一个新的特性来保护数据库，它叫做透明数据加密(Transparent Data Encryption)——TDE，它对整个数据库提供了保护。这篇文章的内容包括：

　　什么是透明数据加密?

　　TDE的执行。

　　我的数据库现在是安全的吗?

　　在激活TDE之前需要考虑什么?

　　当激活TDE之后会影响什么?

　　什么是透明数据加密?

　　Microsoft SQL Server 2008推出了另一个级别的加密——透明数据加密。TDE是全数据库级别的加密，它不局限于字段和记录，而是保护数据文件和日志文件的。在一个数据库上的TDE执行对于连接到所选数据库的应用程序来说是非常简单而透明的。它不需要对现有应用程序做任何改变。这个保护是应用于数据文件和日志文件以及备份文件的。一旦在一个数据库上激活了TDE，备份恢复到另一个SQL Server实例或附加数据文件到另一个SQL Server实例上去将是不允许的，除非用来保护数据库加密密钥(DEK)的证书是可用的。

　　TDE的加密特性是应用于页面级别的。一旦激活了，页面就会在它们写到磁盘之前加密，在读取到内存之前解密。有一点一定要记住，那就是SQL Server和客户端应用程序之间的通信渠道没有通过TDE来保护和加密。

　　下图显示了SQL Server怎样使用TDE加密一个数据库：

　　

　　透明数据加密使用一个数据加密密钥(DEK)用于加密数据库，它存储在数据库启动记录中。DEK由一个存储在主数据库中的证书来保护。可选的，DEK可以由一个放置在硬件安全模块(HSM)中的非对称密钥以及外部密钥管理(EKM)的支持来保护。证书的私钥由对称密钥的数据库主密钥来加密，它通常由一个强密码来保护。注意，尽管这个证书可以由一个密码来保护，但是TDE要求这个证书由数据库主密钥来保护。数据库主密钥由服务主密钥来保护，而服务主密钥由数据保护API来保护。

　　TDE的执行

　　如同上面所提到的，TDE的执行相对简单。下面是一个示例脚本，它使得在一个叫做TestDatabase的数据库上激活了TDE。

　　-- If the master key is not available, create it.

　　USE master;

　　GO

　　IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE name LIKE '%MS_DatabaseMasterKey%')

　　BEGIN

　　CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Pa$$w0rd4545';

　　END

　　GO

　　-- Create the certificate in the master database.

　　USE master;

　　GO

　　-- Since ENCRYPTION BY PASSWORD is not mentioned, the private key of the certificate

　　-- will be encrypted by database master key created above.

　　IF NOT EXISTS (SELECT * FROM sys.certificates WHERE name LIKE '%DEKCertificate%')

　　BEGIN

　　CREATE CERTIFICATE DEKCertificate WITH SUBJECT = 'DEK Certificate'

　　END

　　GO

　　-- Create Database Encryption Key (DEK) in the user database

　　USE TestDatabase

　　GO

　　IF NOT EXISTS (SELECT * FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('TestDatabase'))

　　BEGIN

　　CREATE DATABASE ENCRYPTION KEY

　　WITH ALGORITHM = AES_128

　　ENCRYPTION BY SERVER CERTIFICATE DEKCertificate

　　END

　　GO

　　-- Check whether the key is created

　　SELECT DB_NAME(database_id) AS DatabaseName, * FROM sys.dm_database_encryption_keys

　　-- This should return one row (or more if DEKs have been generated in other databases)

　　-- with the encryption_state of 1 (1 = unencrypted).

　　-- Set the DEK on in the TestDatabase.

　　ALTER DATABASE TestDatabase

　　SET ENCRYPTION ON

　　GO

　　-- Check whether the encryption_state is changed to 3. It should be.

　　SELECT DB_NAME(database_id) AS DatabaseName, * FROM sys.dm_database_encryption_keys

　　前两个步骤显示了怎样创建主数据库中的数据库主密钥和证书。注意，ENCRYPTION BY PASSWORD 不是由CREATE CERTIFICATE 来指定，因此自签名的证书的私钥将由数据库主密钥来保护。下一步显示了在TestDatabase中创建DEK的方法。执行这个代码。它添加了DEK到TestDatabase。如果这个证书的私钥由一个密码保护，那么你将获得如下所示的错误信息：

　　Msg 33101, Level 16, State 1, Line 4

　　不能使用证书“DEKCertificateTest”，因为它的私钥没有显示出来或者它不是由数据库主密钥来保护的。SQL Server 需要自动访问这个操作所使用证书的私钥的能力。

　　sys.dm_database_encryption_keys 使你可以看到DEK被添加到服务器上。字段encryption_state 表示DEK是处于下面的哪个状态：没有加密、加密中、已加密、密钥改变中、和解密中，这些各自对应1、2、3、4、和5这几个数值。当你在设置ENCRYPTION之前运行DMV时，这个状态将显示为1，如果设置了，这个状态将显示为3。完成了。现在TestDatabase 已经是完全安全的了。

　　我的数据库现在是安全的吗?

　　尽管我们成功地使得在我们的数据库上激活了TDE，但是我们还需要确保它在所有级别都是安全的。我们将在这方面做两个测试。首先，我们将备份这个数据库并尝试恢复这个备份到另一个SQL Server 2008实例上去。这个恢复操作一定会失败的，除非这个证书用于保护DEK的私钥是可用于主数据库的。第二，我们将尝试在另一个实例中附加TestDatabase的mdf和ldf文件。它应该也不能起作用。这是用于测试的代码：

　　-- First step is backing up the TestDatabase.

　　BACKUP DATABASE [TestDatabase]

　　TO DISK = N'E:\TestDatabaseFull.bak'

　　WITH NOFORMAT, NOINIT, NAME = N'TestDatabase-Full Database Backup'

　　GO

　　-- Now connect with another SQL Server 2008 instance.

　　-- Try to restore the backup we have taken, in the new instance.

　　-- This statement should be failed.

　　RESTORE DATABASE [TestDatabase]

　　FROM DISK = N'E:\TestDatabaseFull.bak'

　　WITH FILE = 1,

　　MOVE N'TestDatabase' TO N'D:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDatabase.mdf',

　　MOVE N'TestDatabase_log' TO N'D:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDatabase_log.ldf',

　　NOUNLOAD, STATS = 10

　　GO

　　第一个步骤备份了这个数据库。第二部分需要运行在一个不同的SQL Server 2008实例上。当你尝试在一个不同的SQL Server 2008实例中恢复这个备份时，你将得到一个类似于下面所示的错误信息：

　　10 percent processed.

　　20 percent processed.

　　31 percent processed.

　　41 percent processed.

　　52 percent processed.

　　62 percent processed.

　　73 percent processed.

　　83 percent processed.

　　94 percent processed.

　　100 percent processed.

　　Msg 33111, Level 16, State 3, Line 1

　　Cannot find server certificate with thumbprint '0x8AD8C0A89476752FCC3D7A7005A2DCF546C38C58'.

　　Msg 3013, Level 16, State 1, Line 1

　　RESTORE DATABASE is terminating abnormally.

　　当你尝试将这个数据库附加到另一个实例中去时你将面对相同的问题。

　　USE [master]

　　GO

　　CREATE DATABASE [TestDatabase] ON

　　( FILENAME = N'D:\Test\TestDatabase.mdf'),

　　( FILENAME = N'D:\Test\TestDatabase_log.ldf')

　　FOR ATTACH

　　GO

　　上面代码的结果是：

　　Msg 33111, Level 16, State 3, Line 1

　　Cannot find server certificate with thumbprint '0x8AD8C0A89476752FCC3D7A7005A2DCF546C38C58'.

　　它起作用了。我们的数据库是安全的了。恢复或附加TestDatabase 到另一个实例中去的唯一方法是在第二个实例中添加相同的证书。学习下面的代码：

　　-- backup the certificate

　　-- The private key will be encrypted by the password specified

　　BACKUP CERTIFICATE DEKCertificate TO FILE = 'E:\DEKCertificate.cert'

　　WITH PRIVATE KEY

　　(

　　FILE = 'E:\Instance1PrivateKey.key',

　　ENCRYPTION BY PASSWORD = 'Pa$$w0rd5454'

　　)

　　-- create the certificate in the second instance by using the backup

　　-- Private key will be loaded from the saved file.

　　USE [master]

　　GO

　　CREATE CERTIFICATE DEKCertificate

　　FROM FILE = 'E:\DEKCertificate.cert'

　　WITH PRIVATE KEY (

　　FILE = 'E:\Instance1PrivateKey.key'

　　, DECRYPTION BY PASSWORD = 'Pa$$w0rd5454'

　　)

　　这个代码的第一部分将这个证书备份到了一个文件中。它还备份了这个证书的私钥。代码中指定的密码是用于加密私钥的。代码的第二部分需要运行在第二个SQL Server 2008实例上。它使用备份证书创建了一个证书。当这个代码运行后，你将可以恢复或附加TestDatabase数据库到新的实例中去。

　　在激活TDE之前需要考虑什么?

　　在你在数据库上激活TDE之前只有很少的事情需要注意，那就是：

　　TDE是否影响所执行的灾难复原计划?

　　设想一个简单的灾难复原计划，备份和恢复。你可能开发了这个计划而且它执行没有任何问题。你激活了TDE，仍然没有问题，时间表作业备份了你的数据库。假设这个服务器开始产生严重错误导致你需要重新安装操作系统和SQL Server。你可能不做它想就轻松地重新安装，因为你有数据库备份。当数据库恢复时问题出现了。你可能具有不是加密格式的数据库完全备份，你可能有一些在激活TDE之后进行的事务型备份，所以它们是加密的。你没有用于TDE的证书备份。这导致你处于一个不可预料的境地。因为你没有所用证书的备份，所以你将不能恢复事务型备份。

　　想想在激活TDE之前灾难复原计划的开发。如果你有计划，那么确保这个计划在激活TDE之后仍然可用。这不只用于备份和恢复策略，它还用于其它计划，例如日志传送和数据库镜像。

　　在你的数据库中有只读文件组吗?

　　如果数据库有只读文件组，那么TDE将会失败。一旦TDE激活了，那么encryption_state的数值将永远不可能是3(加密的)而是2(加密中)。SQL Server在运行TDE代码时不会抛出任何异常。激活TDE之后，如果你打开数据库的属性窗口，你将会发现属性Encryption Enabled的值被设为了true。使用下面的代码进行测试：

　　-- create a new database for testing TDE on readonly file groups

　　USE master

　　GO

　　CREATE DATABASE [TestDatabase2] ON PRIMARY

　　( NAME = N'TestDatabase2_Primary', FILENAME = N'E:\TestDatabase2_Primary.mdf' , SIZE = 3072KB , FILEGROWTH = 1024KB ),

　　FILEGROUP [FG1_Default]

　　( NAME = N'TestDatabase2_FG1', FILENAME = N'E:\TestDatabase2_FG1.ndf' , SIZE = 3072KB , FILEGROWTH = 1024KB ),

　　FILEGROUP [FG2_ReadOnly]

　　( NAME = N'TestDatabase2_FG2', FILENAME = N'E:\TestDatabase2_FG2.ndf' , SIZE = 3072KB , FILEGROWTH = 1024KB )

　　LOG ON

　　( NAME = N'TestDatabase2_log', FILENAME = N'E:\TestDatabase2_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)

　　GO

　　-- Set the FG1_Default file group as the default one.

　　USE [TestDatabase2]

　　GO

　　IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name = N'FG1_Default')

　　ALTER DATABASE [TestDatabase2]

　　MODIFY FILEGROUP [FG1_Default] DEFAULT

　　GO

　　-- Add a table to the default file group

　　USE [TestDatabase2]

　　GO

　　CREATE TABLE TestTable1 (Id int PRIMARY KEY, [Text] varchar(100))

　　GO

　　INSERT INTO TestTable1 VALUES (1, 'hello')

　　-- Add a table to the FG2_ReadOnly file group

　　CREATE TABLE TestTable2 (Id int PRIMARY KEY, [Text] varchar(100))

　　ON [FG2_ReadOnly]

　　GO

　　INSERT INTO TestTable2 VALUES (1, 'hello')

　　GO

　　-- Set the file group FG2_ReadOnly file group as READONLY

　　IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name = N'FG2_ReadOnly')

　　ALTER DATABASE [TestDatabase2]

　　MODIFY FILEGROUP [FG2_ReadOnly] READONLY

　　GO

　　-- Create Database Encryption Key (DEK) in the user database

　　USE TestDatabase2

　　GO

　　IF NOT EXISTS (SELECT * FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('TestDatabase2'))

　　BEGIN

　　CREATE DATABASE ENCRYPTION KEY

　　WITH ALGORITHM = AES_128

　　ENCRYPTION BY SERVER CERTIFICATE DEKCertificate

　　END

　　GO

　　-- Enable TDE on the database

　　ALTER DATABASE TestDatabase2

　　SET ENCRYPTION ON

　　GO

　　首先这个代码创建了一个具有三个数据文件的数据库，这三个文件叫做TestDatabase2_Primary、TestDatabase2_FG1和TestDatabase2_FG2。文件组FG1_Default 设置为默认文件组，在其中创建了TestTable1。在FG2_ReadOnly文件组中创建了TestTable2。然后FG1_ReadOnly文件组被标识为READONLY。

　　最后，在TestDatabase2 中创建了DEK，Encryption属性设置为true。所有的语句都成功执行。如果你查询sys.dm_database_encryption_keys，你将看到TestDatabase2的encryption_state是2，这表示加密结束了但没有完成。

　　是否使用了FileStream数据类型?

　　使用了filestream类型的数据库可以使用TDE来进行加密，但是文件流数据不会被加密。

　　当激活TDE之后会影响什么?

　　在一个数据库上激活TDE会影响以下事情：

　　事务日志

　　一旦TDE激活了，SQL Server 通过将文本数据清理出去从而确保日志文件不包含文本数据。SQL Server 从具有加密格式的新VLF开始。

　　TEMPDB系统数据库

　　当你在任何数据库上激活了TDE之后这将会自动加密。这会导致使用tempdb数据库的非加密数据库性能下降。

　　日志传送和数据库镜像

　　如果你在一个传送日志到另一个数据库的数据库(意味着激活了日志传送的数据库)上激活了TDE，那么日志传送操作将会在辅助数据库上失败，除非在辅助服务器上证书可用。

　　压缩备份

　　下面是在一个激活了TDE的数据库上进行压缩备份的测试，看起来在激活TDE的数据库上压缩并不怎么高效：

　　-- create a new database for testing compressed backup on TDE enabled database

　　USE master

　　GO

　　CREATE DATABASE [TestDatabase3] ON PRIMARY

　　( NAME = N'TestDatabase3', FILENAME = N'E:\TestDatabase.mdf' , SIZE = 3072KB , FILEGROWTH = 1024KB ),

　　LOG ON

　　( NAME = N'TestDatabase3_log', FILENAME = N'E:\TestDatabase3_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)

　　GO

　　-- Create a table and insert some records

　　USE TestDatabase3

　　GO

　　CREATE TABLE TestTable (Id int primary key, [Value] char(8000))

　　GO

　　INSERT INTO TestTable VALUES (1, 'value1')

　　INSERT INTO TestTable VALUES (2, 'value1')

　　INSERT INTO TestTable VALUES (3, 'value1')

　　INSERT INTO TestTable VALUES (4, 'value1')

　　INSERT INTO TestTable VALUES (5, 'value1')

　　INSERT INTO TestTable VALUES (6, 'value1')

　　-- Backup the TestDatabase3 without compressing it

　　BACKUP DATABASE [TestDatabase3]

　　TO DISK = N'E:\TestDatabase3Full.bak'

　　WITH NOFORMAT, NOINIT, NAME = N'TestDatabase3-Full Database Backup'

　　GO

　　-- Backup the TestDatabase3 with compression

　　BACKUP DATABASE [TestDatabase3]

　　TO DISK = N'E:\TestDatabase3Full_Compressed.bak'

　　WITH NOFORMAT, NOINIT, NAME = N'TestDatabase3-Full Database Backup (Compressed)', COMPRESSION

　　GO

　　-- Now enable TDE on this

　　-- Use the code we used with first example

　　-- Backup the TestDatabase3 again (after TDE enabled) without compressing it

　　BACKUP DATABASE [TestDatabase3]

　　TO DISK = N'E:\TestDatabase3Full_Encrypted.bak'

　　WITH NOFORMAT, NOINIT, NAME = N'TestDatabase3-Full Database Backup (encrypted)'

　　GO

　　-- Backup the TestDatabase3 with compression

　　BACKUP DATABASE [TestDatabase3]

　　TO DISK = N'E:\TestDatabase3Full_Encrypted_Compressed.bak'

　　WITH NOFORMAT, NOINIT, NAME = N'TestDatabase3-Full Database Backup (Encrypted and compressed', COMPRESSION

　　GO

　　这个代码创建一个数据库并插入一些记录到数据表中。然后这个数据库被备份两次，一次没有压缩另一次有压缩。然后你需要在这个数据库上激活TDE并执行其它的与激活TDE之前备份所使用的相同代码。备份文件规模是：

　　在激活TDE之前完全备份1,365 KB

　　在激活TDE之前有压缩的完全备份124KB

　　激活TDE之后的完全备份1,365 KB

　　激活TDE之后有压缩的完全备份 1,278 KB

　　你可以看到它们的不同。结果证明激活了TDE的数据库的压缩备份文件不那么高效。