SQLServer2008的透明数据加密

SQLServer2008的透明数据加密
对⼀个数据库管理员来说，当要保护你所⽀持的数据库时，安全是要考虑的最重要⽅⾯之⼀。

我们使⽤多种机制和技术来保护我们的数据和数据库，例如防⽕墙、认证和数据加密。

不过尽管我们为我们的环境设置了安全，但是关于数据库安全还总是有问题出现。

尽管我们在保护我们的数据库，但是如果有⼈窃取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。

　
前两个步骤显⽰了怎样创建主数据库中的数据库主密钥和证书。

注意，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⽂件。

它应该也不能起作⽤。

这是⽤于测试的代码：
第⼀个步骤备份了这个数据库。

第⼆部分需要运⾏在⼀个不同的SQL Server 2008实例上。

当你尝试在⼀个不同的SQL Server 2008实例中恢复这个备份时，你将得到⼀个类似于下⾯所⽰的错误信息：
当你尝试将这个数据库附加到另⼀个实例中去时你将⾯对相同的问题。

上⾯代码的结果是：
Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint '0x8AD8C0A89476752FCC3D7A7005A2DCF546C38C58'.
它起作⽤了。

我们的数据库是安全的了。

恢复或附加TestDatabase 到另⼀个实例中去的唯⼀⽅法是在第⼆个实例中添加相同的证书。

学习下⾯的代码：
这个代码的第⼀部分将这个证书备份到了⼀个⽂件中。

它还备份了这个证书的私钥。

代码中指定的密码是⽤于加密私钥的。

代码的第⼆部分需要运⾏在第⼆个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。

使⽤下⾯的代码进⾏测试：
⾸先这个代码创建了⼀个具有三个数据⽂件的数据库，这三个⽂件叫做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的数据库上压缩并不怎么⾼效：　
这个代码创建⼀个数据库并插⼊⼀些记录到数据表中。

然后这个数据库被备份两次，⼀次没有压缩另⼀次有压缩。

然后你需要在这个数据库上激活TDE并执⾏其它的与激活TDE之前备份所使⽤的相同代码。

备份⽂件规模是：
在激活TDE之前完全备份1,365 KB
在激活TDE之前有压缩的完全备份124KB
激活TDE之后的完全备份1,365 KB
激活TDE之后有压缩的完全备份 1,278 KB
你可以看到它们的不同。

结果证明激活了TDE的数据库的压缩备份⽂件不那么⾼效。