SQL Server安全（9/11）：透明数据加密（Transparent Data Encryption）

在保密你的服务器和数据，防备当前复杂的攻击，SQL Server有你需要的一切。但在你能有效使用这些安全功能前，你需要理解你面对的威胁和一些基本的安全概念。这篇文章提供了基础，因此你可以对SQL Server里的安全功能充分利用，不用在面对特定威胁，不能保护你数据的功能上浪费时间。

---

从让人眼花缭乱的客户端使用连接，通过到处分布的网络，尤其是互联网，关系数据库在各种应用程序里广泛使用。这使数据对任何人，在任何地方都可访问。数据库可以保存人类知识的很大部分，包括高度敏感的个人信息和让国际商务工作的关键数据。

对于想要偷取数据或通过篡改数据来伤害数据的拥有者的 人来说，这些功能使数据库成为有吸引力的目标。确保你的数据安全是SQL Server配置和使用它来保存数据的程序的重要部分。这个系列会探寻SQL Server 2012安全的基本，这样的话你可以保护你的数据和服务器资源，按你需要的安全等级来保护数据，免受这些威胁对你数据的影响。大部分信息对SQL Server的早期版本也适用，回到SQL Server 2005也可以，因为那是微软在产品里彻底检查安全的时候。但我也会谈论只在SQL Server 2012和后续版本里才有的功能。

如果攻击者能拿到包含数据库的磁盘文件的访问，即使做好防护的数据还是容易受到攻击。单元格级别的加密可以保护部分数据，但应付这列攻击的完整保护是必须加密文件而不是数据。这就是透明数据加密（Transparent Data Encryption (TDE)）要做的，在这篇文章里你会学到TDE做什么，如何工作，还有如何使用它来保护你的数据库文件。

透明数据加密（Transparent Data Encryption (TDE)）

在SQL Server 2008，微软引入了透明数据加密（Transparent Data Encryption (TDE)）。TDE可以在文件层对数据和日志文件进行实时加密和解密。不需要特定的编程，尽管有支持的T-SQL管理TDE，在这篇文章里稍后你就会看到。这让TDE很容易配置和维护，尽管当的复制和移动数据库到不同位置和SQL Server实例时需要更多工作。

TDE在写入数据库就加密数据，然后在读取的时候解密数据，一旦你在数据库启用TDE就会自动处理。TDE的目的是在数据库和日志里，保护休息时的数据库，保持它的安全，远离直接从文件直接访问数据的攻击者。有个特定的场景对此非常有用，当你需要通过一夜包裹投递服务来运输你的数据库文件，例如FedEx或UPS。没有TDE，攻击者可以从运输卡车后面偷取你的包裹，附加数据库到他有sysadmin权限的SQL Server实例，拿到数据访问。但如果在数据库上启用了TDE，整个数据被安全加密了；没有密匙的话，就不能访问到数据。其它TDE也很有用的场景是担心例如内部的攻击者，可以用任何方式获得物理文件的访问，或者你需要保持归档数据库副本的安全。

TDE如何工作

TDE需要证书来访问物理数据库文件。没有证书来加密数据库，数据只是无法使用的，加密的一堆胡言乱语。这就是说不能在数据库附近的任何地方放置证书的备份，这个非常重要——例如在用来运输数据库文件的同个FedEx包裹里！不然的话，攻击者有他想要的一切东西。他需要做的只是在他控制的SQL Server实例上安全证书，用它来附加数据库，给她解密数据的完全访问。

TDE加密所有写入数据库的数据，理解这个非常重要。然后它解密需要的数据来响应查询。因此只有当数据在休息的时候，存储在数据库里，它才受TDE保护。TDE在读写数据的时候会在8K的页里加密或解密数据。

如果SQL Server实例的任何数据库，即使几十个中的一个数据库附加到实例，受TDE保护的，那么SQL Server自动用TDE保护tempdb。即使受TDE保护的数据库不使用tempdb。这样做是有道理的，因为从受保护的一些数据会自动存储在tempdb。数据会在休息——即使很短的时间——因此完整保护tempdb同样需要使用TDE保护。这样会带来性能上的问题。所有的数据在tempdb里加密保存，在实例里所有的其它未受TDE保护的数据库，有任何数据存储在tempdb的话也会被加密。因此这些数据库的性能也会受到影响。

要配置TDE，你需要有创建数据库主密匙，在mater数据里创建一个证书，在用户数据库上有CONTROL许可来启用TDE。大多数时间，sysadmin可以在数据库上启用TDE，因此需要的许可不是问题。

TDE的局限性

为了高效使用TDE，你应该理解TDE做什么和它有什么好和不好的地方。考虑下TDE的这些限制：

• 在数据库里你不能加密一部分数据；要么全部加密，要么都不加密。
• TDE不是通过数据库引擎限制数据访问的方法。数据访问不受TDE改变。如果你有一个用户运行的程序，用户和应用程序有访问数据库里数据的许可。TDE不会修改数据访问方法。它只是保护数据库文件。
• TDE不是保护你服务器、数据库实例或数据库里各个敏感数据的替代品，你还是要认真考虑，在各层使用安全措施保护你的数据库。TDE只是设计用来保护特定攻击（在数据或日志文件里休息时的数据）的一层保护。
• TDE一个最大的缺点之一是FILESTREAM数据不会加密。这个数据字节流存储在SQL Server之外，但受SQL Server管理和监控。
• TDE仅在SQL Server的企业版和开发版可用。很遗憾，这让不使用这2个版本的用户不能受TDE的保护。

如你所见，这些限制没有TDE作什么用的限制多，这表示它不能作为安全的灵丹妙药那么有用。但是如果对你数据的威胁对应于它提供的保护，TDE会是重要的安全功能。

TDE性能

但你看TDE时，有一个你要考虑的问题是性能。考虑到需要的处理周期，加密是个昂贵的操作。TDE表现还是相当不错的，因为TDE不在SQL 缓存里加密数据。只有当它写入磁盘时才加密数据。因此如果它不在缓存的话，每次你访问数据的时候也不需要加密，这提高了全局的效率。在数据库里，微软花了大量的时间让加密尽可能的高效。但当数据被读写时，还是会带来一定的性能问题，因为加密要用到复杂的算法。

使用TDE

现在我们通过实例来演示下你如何使用TDE，还有它在数据库上的作用。下列代码显示了备份AdventureWorks2012数据库，然后还原了一个新的数据库AdventureWorks2012Copy。你可以按照自己的实际情况修改文件路径，例如文件备份路径，C:\Data文件夹用来备份证书。

-- *** Beginning of setup code ***
-- *******************************

-- Make a copy of AdventureWorks2012 database
-- Change the path to the appropriate backup directory
BACKUP DATABASE AdventureWorks2012
    TO DISK = N'D:\SQLBackups\AdventureWorks2012.bak'
    WITH NOFORMAT, INIT, NAME = N'AdventureWorks2012 Full Database Backup',
    SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO

RESTORE DATABASE AdventureWorks2012Copy
    FROM DISK = N'D:\SQLBackups\AdventureWorks2012.bak'
    WITH 
        FILE = 1, NOUNLOAD, REPLACE, STATS = 10,
        MOVE 'AdventureWorks2012_Data' TO N'D:\SQLData\AdventureWorks2012Copy.mdf',
        MOVE 'AdventureWorks2012_Log' TO N'D:\SQLData\AdventureWorks2012Copy.ldf';
GO

-- *** End of setup code ***
-- *************************

一旦你进行了下列配置步骤，代码进行了4个步骤为数据库启用TDE：

1. 在master数据库里创建主密匙。
2. 创建/使用受主密匙保护的证书。
3. 创建受证书保护的数据库加密密匙。
4. 为数据库启用TDE。

代码9.1展示了在master数据库里创建证书需要的代码，在数据库里它用来保护数据库加密密匙。它创建数据库主密匙，使用强密码保护它，然后创建AdventureWorks2012TDECert证书。作为预防，代码然后备份证书到D:\Data目录。你应该在稳妥可靠的地方存储它，在你移动受TDE保护的数据库的时候就可以用到它。

USE master;
GO

-- TDE hooks into encryption key hierarchy in SQL Server
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '!drJP9QXC&Vi%cs';
GO

-- Create the certificate used to protect the database encryption key
CREATE CERTIFICATE AdventureWorks2012TDECert WITH SUBJECT = 'Certificate to implement TDE on AdventureWorks2012Copy';
GO

-- Backup the certificate
-- Either create the C:\Data folder or change it in the code below
BACKUP CERTIFICATE AdventureWorks2012TDECert TO FILE = 'D:\Data\AdventureWorks2012TDECert'
    WITH PRIVATE KEY ( FILE = 'D:\Data\AdventureWorks2012TDECertPrivateKey' , 
    ENCRYPTION BY PASSWORD = 'RISiS9Ul%CByEk6' );
GO

代码9.1：创建并备份用来保护TDE数据库的证书

在进一步使用TDE之前，运行代码9.2，这个列出的代码在SQL Server的当前实例里加密数据库，连同它们的加密状态，如果有的话。在新的，刚安装的SQL Server，这应该返回一个空的结果。接下来，在实施TDE后，你会看到状态如何改变。

SELECT DB_NAME(database_id) AS DatabaseName,
    key_algorithm AS [Algorithm],
    key_length AS KeyLength,
    CASE encryption_state
        WHEN 0 THEN 'No database encryption key present, no encryption'
        WHEN 1 THEN 'Unencrypted'
        WHEN 2 THEN 'Encryption in progress'
        WHEN 3 THEN 'Encrypted'
        WHEN 4 THEN 'Key change in progress'
        WHEN 5 THEN 'Decryption in progress'
    END AS EncryptionStateDesc,
    percent_complete AS PercentComplete
FROM sys.dm_database_encryption_keys;
GO

代码9.2 在SQL Server实例里列出加密数据库的状态

现在是时候对AdventureWorks2012Copy数据库启用TDE。执行代码9.3，它开始使用你刚才在master数据库里创建的证书创建数据库加密密匙。你会收到一条警告信息：如果你还没备份证书的话，请备份；请留意这个建议！然后代码使用SET ENCRYPTION ON子句的ALTER DATABASE语句为数据库启用TDE。取决于与数据库的大小和服务器的速度，完全加密数据库需要一些时间，可能几个小时或几天。

USE AdventureWorks2012Copy;
GO

-- Create the database encryption key for TDE. Analogous to database master key for data encryption.
CREATE DATABASE ENCRYPTION KEY 
    WITH ALGORITHM = TRIPLE_DES_3KEY
    ENCRYPTION BY SERVER CERTIFICATE AdventureWorks2012TDECert;
GO
-- Get a warning about backing up the key, if you haven't already
-- ...take the advice and back it up!

-- Now need to turn TDE on. 
ALTER DATABASE AdventureWorks2012Copy SET ENCRYPTION ON;

代码9.3：创建数据库加密密匙并启用TDE

当在加密数据库的时候，可以反复执行代码9.2来跟踪下进度。你会看到如插图9.1的结果，我在截屏的时候，已经100%完成了。注意插图显示了2个数据库：现在在实例里至少有一个数据库使用TDE，tempdb也会自动加密。一旦初始化加密完成，所有的数据库PercentComplete列会显示为0（是的，这个数字有点误导，因为当它完成的时候不是100%这样的显示）。

插图9.1：使用sys.dm_database_encryption_keys来监控数据库加密进度的结果

注意在图中AdventureWorks2012Copy数据库使用了Triple DES加密算法。那是我们在代码9.1里指定的算法，你可以用SQL Server支持的任何加密算法选项。还有tempdb默认也使用256位AES加密算法。

通过执行对数据库的查询测试加密，如代码9.4所示。在打开TDE之前，只要你有必要的许可访问数据库，你就能访问数据。这对任何应用程序的数据访问也是如此。

SELECT TOP 500 * FROM Production.Product;

代码9.4：在启用TDE后测试数据库访问的样本代码。

如果你想为数据库关闭TDE，你可以使用代码9.5：

ALTER DATABASE AdventureWorks2012Copy
    SET ENCRYPTION OFF;
GO

代码9.5：为数据库停用TDE

测试TDE

测试下安全功能确保它如你预计的正常工作总是明智的。样本代码包含测试TDE的一些步骤，包括你不小心删除用来为TDE保护数据库加密密匙的证书。代码9.5备份AdventureWorks2012Copy数据库，删除AdventureWorks2012TDECert证书，模拟丢失证书。（这也模拟了当你附加加密数据库到不同的SQL Server实例，它上面并没有安装原始的证书。）

BACKUP DATABASE AdventureWorks2012Copy
    TO DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'
    WITH NOFORMAT, INIT, NAME = N'AdventureWorks2012Copy Full Database Backup',
    SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO

USE master
GO
DROP DATABASE AdventureWorks2012Copy;
GO

-- Oops! We lost the certificate and don't have a copy!
-- Or, going to restore the database to another server instance
DROP CERTIFICATE AdventureWorks2012TDECert; 
GO

代码9.6：备份数据库，删除数据库，扔掉了证书

接下来，尝试使用代码9.7还原数据库，你会收到如插图9.2的错误信息。这是TDE在起作用的保护：如果数据库实例没有安装原始加密证书，是不可能还原或附加数据库的。

RESTORE DATABASE AdventureWorks2012Copy
    FROM DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'
    WITH 
        FILE = 1, NOUNLOAD, REPLACE, STATS = 10;

代码9.7：尝试还原受TDE保护的数据库

插图9.2：尝试在没有安装保护证书的数据库上还原数据库

但如果你备份了证书，并没有丢失全部！使用代码9.8从备份文件里还原证书，使用文件里刚才用来保护证书的密码，然后尝试还原数据库。这次完全可用的数据库——还是用TDE保护——已经成功还原。

-- Recover from the problem
-- Restore the certificate
CREATE CERTIFICATE AdventureWorks2012TDECert
    FROM FILE = 'D:\DATA\AdventureWorks2012TDECert'
    WITH PRIVATE KEY ( FILE = 'D:\DATA\AdventureWorks2012TDECertPrivateKey', 
    DECRYPTION BY PASSWORD = 'RISiS9Ul%CByEk6');
    
-- Now try to restore the database
RESTORE DATABASE AdventureWorks2012Copy
    FROM DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'
    WITH 
        FILE = 1, NOUNLOAD, REPLACE, STATS = 10;

代码9.8：从备份文件还原删除的证书，然后再次尝试还原数据库

TDE与列级别数据加密比较

通过在这篇和上一篇文章，你应该能很好的理解SQL Server提供的两种主要加密方式，还有什么时候使用它们。总结下与在列级别数据库加密的主要不同：

• 加密更加颗粒化。你可以在单个数据库里单个列加密。
• 加密的数据只有使用的时候才会解密。如果数据不使用，基本就不会被解密。
• 你需要修改表架构来适应加密的字节流数据，修改应用程序来包含加密和解密代码。
• 你不能简单的搜索和排序加密数据，索引毫无用处。有一些变通方法，但它们没有效率并暴露数据特征，攻击者可以用来得到解决困难的方法。

通常，你会想为小量数据使用列级别数据加密来保护大多数敏感信息，在服务器上节约处理周期。

这引出了一个问题：在SQL Server 2008和后续版本应该使用哪个加密方式？关键是要理解你要保护面对的威胁，但实施任何安全功能时，这个是关键。

如果威胁是窃取、数据库和日志文件的滥用，使用透明数据加密（Transparent Data Encryption）。TDE会阻止附加数据库到另一个SQL Server实例和获得数据访问。

如果威胁是在你服务器上的入侵数据，列级别加密没准是更好的选择。当黑客在数据库服务器上拿到访问后，正确实施的列级别数据加密可以阻止数据访问。

如果你两者之间不能选择，你可能需要同时面对两种威胁。幸运的是，2个可以结合使用，各个会阻止它特定的威胁。

小结

透明数据加密（Transparent Data Encryption）进行数据和日志文件的实时加密和解密。这个会在数据库和日志里加密所有数据，阻止攻击着从另一个SQL Server实例附加数据库，获得数据访问。如果你需要防范的威胁是数据文件的滥用，TDE可以提供强的数据保护，不需要架构和程序改变。使用得当的话，它可以为整体深度防御，提供强大的安全层。

原文链接

http://www.sqlservercentral.com/articles/Stairway+Series/125948/