SQL Server 2008的透明数据加密

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介:
对一个数据库管理员来说,当要保护你所支持的数据库时,安全是要考虑的最重要方面之一。我们使用多种机制和技术来保护我们的数据和数据库,例如防火墙、认证和数据加密。不过尽管我们为我们的环境设置了安全,但是关于数据库安全还总是有问题出现。尽管我们在保护我们的数据库,但是如果有人窃取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加密一个数据库:

SQL Server

  透明数据加密使用一个数据加密密钥(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的数据库的压缩备份文件不那么高效。

 

本文转自 你听海是不是在笑 博客园博客,原文链接:http://www.cnblogs.com/nuaalfm/archive/2010/04/15/1712560.html   ,如需转载请自行联系原作者

相关文章
|
3月前
|
关系型数据库 MySQL 网络安全
5-10Can't connect to MySQL server on 'sh-cynosl-grp-fcs50xoa.sql.tencentcdb.com' (110)")
5-10Can't connect to MySQL server on 'sh-cynosl-grp-fcs50xoa.sql.tencentcdb.com' (110)")
|
5月前
|
SQL 存储 监控
SQL Server的并行实施如何优化?
【7月更文挑战第23天】SQL Server的并行实施如何优化?
135 13
|
5月前
|
SQL
解锁 SQL Server 2022的时间序列数据功能
【7月更文挑战第14天】要解锁SQL Server 2022的时间序列数据功能,可使用`generate_series`函数生成整数序列,例如:`SELECT value FROM generate_series(1, 10)。此外,`date_bucket`函数能按指定间隔(如周)对日期时间值分组,这些工具结合窗口函数和其他时间日期函数,能高效处理和分析时间序列数据。更多信息请参考官方文档和技术资料。
|
4月前
|
SQL 安全 网络安全
"守护数据王国,揭秘SQL权限管理与安全配置秘籍!从创建用户到加密技术,全方位打造铜墙铁壁,让你的数据库安全无忧,远离黑客侵扰!"
【8月更文挑战第31天】数据库是信息系统的核心,存储了大量敏感数据,因此确保其安全至关重要。本文详细介绍了SQL权限管理与安全配置的方法,包括理解权限类型、创建用户和角色、分配权限、实施密码策略、使用加密技术、配置防火墙、定期审计备份及防止SQL注入等,帮助你全面保护数据库安全。通过这些步骤,你可以有效管理和配置数据库权限,防范潜在威胁,确保数据隐私和完整性。
108 0
|
5月前
|
SQL 存储 网络安全
关系数据库SQLserver 安装 SQL Server
【7月更文挑战第26天】
73 6
|
5月前
|
存储 SQL C++
对比 SQL Server中的VARCHAR(max) 与VARCHAR(n) 数据类型
【7月更文挑战7天】SQL Server 中的 VARCHAR(max) vs VARCHAR(n): - VARCHAR(n) 存储最多 n 个字符(1-8000),适合短文本。 - VARCHAR(max) 可存储约 21 亿个字符,适合大量文本。 - VARCHAR(n) 在处理小数据时性能更好,空间固定。 - VARCHAR(max) 对于大文本更合适,但可能影响性能。 - 选择取决于数据长度预期和业务需求。
469 1
|
4月前
|
SQL 安全 Java
驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接。错误:“The server selected protocol version TLS10 is not accepted by client
驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接。错误:“The server selected protocol version TLS10 is not accepted by client
536 0
|
5月前
|
SQL 监控 数据库
SQL Server 查询超时问题排查
【7月更文挑战第8天】排查 SQL Server 查询超时涉及五个主要方面:检查复杂查询、评估服务器性能、审视配置参数、更新统计信息和分析执行计划。关注点包括查询的结构(如连接、子查询和索引),服务器资源(CPU、内存、网络延迟),连接和内存设置,以及统计信息的时效性。通过这些步骤可定位并解决性能瓶颈。
139 0
|
5月前
|
SQL 存储 Oracle
TDengine 3.3.2.0 发布:新增 UDT 及 Oracle、SQL Server 数据接入
**TDengine 3.3.2.0 发布摘要** - 开源与企业版均强化性能,提升WebSocket、stmt模式写入与查询效率,解决死锁,增强列显示。 - taos-explorer支持geometry和varbinary类型。 - 企业版引入UDT,允许自定义数据转换。 - 新增Oracle和SQL Server数据接入。 - 数据同步优化,支持压缩,提升元数据同步速度,错误信息细化,支持表名修改。 - 扩展跨平台支持,包括麒麟、Euler、Anolis OS等。
134 0
|
20天前
|
存储 SQL 安全
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
随着互联网的普及,网络安全问题日益突出。本文将介绍网络安全的重要性,分析常见的网络安全漏洞及其危害,探讨加密技术在保障网络安全中的作用,并强调提高安全意识的必要性。通过本文的学习,读者将了解网络安全的基本概念和应对策略,提升个人和组织的网络安全防护能力。