你的位置:首页 > 数据库

[数据库]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文件夹用来备份证书。

 1 -- *** Beginning of setup code *** 2 -- ******************************* 3  4 -- Make a copy of AdventureWorks2012 database 5 -- Change the path to the appropriate backup directory 6 BACKUP DATABASE AdventureWorks2012 7   TO DISK = N'D:\SQLBackups\AdventureWorks2012.bak' 8   WITH NOFORMAT, INIT, NAME = N'AdventureWorks2012 Full Database Backup', 9   SKIP, NOREWIND, NOUNLOAD, STATS = 10;10 GO11 12 RESTORE DATABASE AdventureWorks2012Copy13   FROM DISK = N'D:\SQLBackups\AdventureWorks2012.bak'14   WITH 15     FILE = 1, NOUNLOAD, REPLACE, STATS = 10,16     MOVE 'AdventureWorks2012_Data' TO N'D:\SQLData\AdventureWorks2012Copy.mdf',17     MOVE 'AdventureWorks2012_Log' TO N'D:\SQLData\AdventureWorks2012Copy.ldf';18 GO19 20 -- *** End of setup code ***21 -- *************************

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

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

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

 1 USE master; 2 GO 3  4 -- TDE hooks into encryption key hierarchy in SQL Server 5 CREATE MASTER KEY ENCRYPTION BY PASSWORD = '!drJP9QXC&Vi%cs'; 6 GO 7  8 -- Create the certificate used to protect the database encryption key 9 CREATE CERTIFICATE AdventureWorks2012TDECert WITH SUBJECT = 'Certificate to implement TDE on AdventureWorks2012Copy';10 GO11 12 -- Backup the certificate13 -- Either create the C:\Data folder or change it in the code below14 BACKUP CERTIFICATE AdventureWorks2012TDECert TO FILE = 'D:\Data\AdventureWorks2012TDECert'15   WITH PRIVATE KEY ( FILE = 'D:\Data\AdventureWorks2012TDECertPrivateKey' , 16   ENCRYPTION BY PASSWORD = 'RISiS9Ul%CByEk6' );17 GO

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

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

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

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

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

 1 USE AdventureWorks2012Copy; 2 GO 3  4 -- Create the database encryption key for TDE. Analogous to database master key for data encryption. 5 CREATE DATABASE ENCRYPTION KEY  6   WITH ALGORITHM = TRIPLE_DES_3KEY 7   ENCRYPTION BY SERVER CERTIFICATE AdventureWorks2012TDECert; 8 GO 9 -- Get a warning about backing up the key, if you haven't already10 -- ...take the advice and back it up!11 12 -- Now need to turn TDE on. 13 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之前,只要你有必要的许可访问数据库,你就能访问数据。这对任何应用程序的数据访问也是如此。

1 SELECT TOP 500 * FROM Production.Product;

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

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

1 ALTER DATABASE AdventureWorks2012Copy2   SET ENCRYPTION OFF;3 GO

代码9.5:为数据库停用TDE

测试TDE

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

 1 BACKUP DATABASE AdventureWorks2012Copy 2   TO DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak' 3   WITH NOFORMAT, INIT, NAME = N'AdventureWorks2012Copy Full Database Backup', 4   SKIP, NOREWIND, NOUNLOAD, STATS = 10; 5 GO 6  7 USE master 8 GO 9 DROP DATABASE AdventureWorks2012Copy;10 GO11 12 -- Oops! We lost the certificate and don't have a copy!13 -- Or, going to restore the database to another server instance14 DROP CERTIFICATE AdventureWorks2012TDECert; 15 GO

代码9.6:备份数据库,删除数据库,扔掉了证书

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

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

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

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

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

 1 -- Recover from the problem 2 -- Restore the certificate 3 CREATE CERTIFICATE AdventureWorks2012TDECert 4   FROM FILE = 'D:\DATA\AdventureWorks2012TDECert' 5   WITH PRIVATE KEY ( FILE = 'D:\DATA\AdventureWorks2012TDECertPrivateKey',  6   DECRYPTION BY PASSWORD = 'RISiS9Ul%CByEk6'); 7    8 -- Now try to restore the database 9 RESTORE DATABASE AdventureWorks2012Copy10   FROM DISK = N'D:\SQLBackups\AdventureWorks2012Copy.bak'11   WITH 12     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/