SQL Server WITH ENCRYPTION VS TDE

在SQL Server 2014(12.x)版本中,在BACKUP DATABASE的参数中增加了ENCRYPTION参数,即备份时,对写入文件的数据进行加密。那么该参数是如何使用的呢?WITH ENCRYPTION 加密对性能有怎样的影响?其和TDE有怎样的关系,两者对性能影响情况如何?本文将通过实例说明,给出该参数用法,并与TDE进行对比。

创建测试环境

创建数据库test,并在test库下创建表test,向表中插入一条记录:

USE master

GO

CREATE DATABASE test ON PRIMARY

(name='test',filename='D:\DB\Test\test.mdf')

LOG ON

(name='test_log',filename='D:\DB\Test\test_log.ldf')

USE test

GO

CREATE TABLE test ( id INT, name VARCHAR(10) )

INSERT  INTO test

VALUES  ( 1, 'Jack' )

要使用WITH ENCRYPTION 参数备份数据库,和TDE一样,首先需要创建数据库主秘钥、服务器证书,并备份证书:

USE master

GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD= 'jC`T?]K,v`{voD<'

CREATE CERTIFICATE TestBackOption

WITH SUBJECT = 'My DEK Certificate for test database backup option'

BACKUP CERTIFICATE TestBackOption

TO FILE ='D:\TestBackOption.cer'

WITH PRIVATE KEY(FILE='D:\TestBackOption_Key.pvk',

ENCRYPTION BY PASSWORD='[J,XJK8|AwE*rLk')

使用ENCRYPTION备份选项,在备份时,对备份文件加密:

BACKUP DATABASE [test]

TO DISK = N'D:\TestWithBackOptionEncryption.bak'

WITH

  COMPRESSION,

  ENCRYPTION 

  (

  ALGORITHM = AES_256,

  SERVER CERTIFICATE = TestBackOption

  ),

  STATS = 10

GO

注意,和TDE不用一样,需要创建数据库秘钥,然后在将数据库文件数据进行加密。使用ENCRYPTION加密备份文件,是在备份时,将数据加密后写入备份文件。

接下来,我们使用记事本打开数据库备份文件,查找“Jack”,我们发现,查不到明文“Jack”,验证确实达到了加密的效果。

WITH ENCRYPTION 有两个参数,分别是加密算法和加密方式,我们可以选用的加密算法包括: AES 128、AES 192、AES 256 和 Triple DES;加密方式可以是证书或非对称密钥。


日志备份、文件或文件组备份时也可以使用ENCRYPTION参数对数据进行加密。

使用TDE加密的数据库,仍然可以使用ENCRYPTION参数进行加密。

备份时加密的备份文件,还原的时候和TDE数据库一样,也需要先在实例上创建主秘钥,还原服务器证书、私钥,并不需要在还原脚本中增加参数。


从上文可以看出,相对TDE,WITH ENCRYPTION数据库备份方式,是在备份时将数据加密后写入备份文件的,这样我们可以合理安排备份策略,避开高峰期数据读写加密、解密对数据库性能的影响。那么我们是不是就可以弃用TDE了呢?使用数据库备份时对文件进行加密会有什么影响吗?

第一个问题很好回答,首先,因为数据库备份时对备份文件进行加密是SQL Server 2014(12.x)版本的新功能,SQL Server 2014以前的版本是不能使用的,所以还是不能直接替代的,除非您的组织愿意花费成本去将SQL Server升级到 2014或者更高的版本。其次因为数据库中的数据是没有进行加密的,线上数据更容易被黑客盗取。综上两个原因,TDE仍然是不可替代的。

下面我们将通过试验对比数据库备份时对数据库备份文件进行加密和TDE,我们使用《SQL Server 透明数据加密(TDE)的影响》一文中test数据库,为了保证数据库数据量一致,减少其他因素的影响,我们先使用WITH ENCRYPTION加密选项对数据库test进行备份:

DECLARE @bdatetime AS DATETIME=GETDATE()

SET STATISTICS IO ON

SET  STATISTICS TIME ON

BACKUP DATABASE [test]

TO DISK = N'D:\TestWithBackOptionEncryption.bak'

WITH

  COMPRESSION,

  ENCRYPTION 

  (

  ALGORITHM = AES_256,

  SERVER CERTIFICATE = TestBackOption

  ),

  STATS = 10

SET STATISTICS IO OFF

SET  STATISTICS TIME OFF

SELECT @bdatetime,GETDATE(),DATEDIFF(millisecond,@bdatetime,GETDATE())

GO


已处理百分之 10。

已处理百分之 20。

已处理百分之 30。

已处理百分之 40。

已处理百分之 50。

已处理百分之 60。

已处理百分之 70。

已处理百分之 80。

已处理百分之 90。

已为数据库 'test',文件 'test' (位于文件 1 上)处理了 328592 页。

已处理百分之 100。

已为数据库 'test',文件 'test_log' (位于文件 1 上)处理了 3 页。

BACKUP DATABASE 成功处理了 328595 页,花费 62.830 秒(40.858 MB/秒)。


 SQL Server 执行时间:

   CPU 时间 = 265 毫秒,占用时间 = 63160 毫秒。


 SQL Server 执行时间:

   CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

(1 行受影响)

对test库启动TDE

加密算法和数据库备份选项中的加密算法一样,均使用AES_256

USE test

GO

CREATE DATABASE ENCRYPTION KEY

WITH ALGORITHM= AES_256

ENCRYPTION BY SERVER CERTIFICATE TestBackOption

ALTER DATABASE test SET ENCRYPTION ON

查看动态视图 sys.dm_database_encryption_keys 中的列percent_complete ,确认其重新变为0后,说明加密完成:

SELECT  DB_NAME(database_id) DBName, percent_complete

FROM    sys.dm_database_encryption_keys

接下来我们来备份TDE数据库:

USE test

GO

DECLARE @bdatetime AS DATETIME=GETDATE()

SET STATISTICS IO ON

SET  STATISTICS TIME ON

BACKUP DATABASE [test]

TO DISK = N'D:\Test_TDE.bak'

WITH    STATS = 10

SET STATISTICS IO OFF

SET  STATISTICS TIME OFF

SELECT @bdatetime,GETDATE(),DATEDIFF(millisecond,@bdatetime,GETDATE())

GO

已处理百分之 10。

已处理百分之 20。

已处理百分之 30。

已处理百分之 40。

已处理百分之 50。

已处理百分之 60。

已处理百分之 70。

已处理百分之 80。

已处理百分之 90。

已为数据库 'test',文件 'test' (位于文件 1 上)处理了 328544 页。

已处理百分之 100。

已为数据库 'test',文件 'test_log' (位于文件 1 上)处理了 3 页。

BACKUP DATABASE 成功处理了 328547 页,花费 138.508 秒(18.531 MB/秒)。

 SQL Server 执行时间:

   CPU 时间 = 157 毫秒,占用时间 = 138843 毫秒。

 SQL Server 执行时间:

   CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

完成时间: 2020-02-26T14:04:50.9311361+08:00

可以看到TDE数据库备份消耗的时间是备份时加密备份文件消耗时间的1倍左右,而两者CPU消耗时间近乎一致,因为TDE数据库的备份是先加密后解密的过程。

结合《SQL Server 透明数据加密(TDE)的影响》,如果您已经在使用SQL Server 2014(12.x)或者更高版本的SQL Server 数据库,并且您已经使用其他安全措施,保证数据库数据的安全。可以考虑使用备份时对备份文件加密,即使用的备份的参数:

ENCRYPTION 

  (

  ALGORITHM = AES_256,

  SERVER CERTIFICATE = TestBackOption

  )

注意:但TDE是不可替代的,因为备份时对备份文件加密,存在的安全隐患,即生产环境数据库文件是没有加密的,此数据库文件被窃,或者被未授权的用户访问,或者被黑客攻击,仍然会暴露组织的隐私数据。

————————————————

版权声明:本文为CSDN博主「三空道人」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/zhoujunah/article/details/105946752

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,843评论 6 502
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,538评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,187评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,264评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,289评论 6 390
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,231评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,116评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,945评论 0 275
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,367评论 1 313
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,581评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,754评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,458评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,068评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,692评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,842评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,797评论 2 369
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,654评论 2 354