Oracle数据安全解决方案——透明数据加密TDE

转载：http://www.linuxidc.com/Linux/2011-12/48689.htm

这可能是你的公司最恐怖的噩梦：有人偷走了数据库的备份磁带！当然，你可能构造了一个安全的系统，加密了最敏感的资产，然后围绕数据库服务器建了一圈防火墙来保护。但是，小偷却采取了最简单的方法：他偷走了备份磁带，在另外一个服务器上恢复数据库、启动了数据库，然后他就可以边喝咖啡边从容的浏览数据了。

保护数据以防这种小偷不只是一个好的实践，同时也是很多法律、规则、方针的要求，你如何保护你的数据库以防止这种漏洞呢？

                                           

一种解决方法是在数据库中将敏感数据加密，然后将加密密钥存储在一个不同的地方，这样即使数据被盗也是没有用的。然而，你必须在两个互相矛盾的概念间进行平衡：应用程序访问加密密钥的方便性、防止密钥被盗的安全性。为了能够遵从公司和政府的规章制度，你需要一个快速的解决方案，而不需要进行复杂的编码。

                                           

Oracle 10g R2提供了一个新的特性，让你只需要做如下动作：你可以不写一行代码，只需要声明你需要加密某列。当用户插入数据的时候，数据库透明的加密数据然后存储加密后的数据。同样的，当用户读取数据时，数据库自动进行节目。由于加解密操作对应用程序来说都是透明的，不需要应用程序修改代码，因此这个特性就叫做：透明数据加密（TDE）。

 

1 TDE如何工作？

                                           

我在January/February 2005 issue of Oracle Magazine上提到了Oracle 10g数据库加密的基本原理。现在我们概述一下关键点：加密时你需要应用一个加密算法和一个加密密钥对明文输入的数据进行加解密操作；为了能够成功的解密，你必须知道加密采用的算法和密钥。

                                           

在那篇文章中，我描述了如何使用Oracle提供的加密工具来构建一个加密框架。然而，使用Oracle 10g R2数据库和TDE，你将不需要自己构建这样一个框架。你所要做的只是定义需要加密的列，Oracle 10g数据库将为包含加密列的表创建一个私密（译者注：用户不需要知道）的安全加密密钥，然后采用你指定的加密算法加密指定列的明文数据。

                                           

这种机制下，保护表的加密密钥（以下简称“表密钥”）就显得非常重要了。Oracle 10g通过一个master密钥来对表密钥进行加密。master密钥保存在一个叫做“钱夹（wallet）”的安全的地方，钱夹可以是数据库服务器上的一个文件，加密的表密钥保存在数据字典中。

                                           

当用户插入数据到需要加密的列中的时候，Oracle 10g从钱夹中获取master密钥，用master密钥解密数据字典中的表密钥，然后用解密后的表密钥加密输入数据，再将加密后的数据保存在数据库中。如下图1所示：

 

图1：TDE工作原理

你可以加密表的部分或者所有列，例如一个表有4列，如上图1所示，第2列和第3列被加密，但Oracle只会生成一个表级的加密密钥，然后用这个密钥加密所有的加密列。在磁盘上，第1列和第4列是明文存储的，第2列和第3列是加密存储的。由于数据是加密存储的，所有后续的组建例如备份和归档日志，都是加密的格式。

                                           

当用户查询一个加密列的时候，Oracle 10g透明的（译者注：用户不可感知）将加密的表密钥从数据字典中取出，再取出master密钥，然后解密表密钥，再用解密后的表密钥来解密磁盘上加密的数据，最后返回明文给用户。

                                           

通过这种加密数据的方式，即使保存在磁盘上的数据被盗，由于master密钥并没有被盗，没有master密钥的情况下，数据无法被获取。即使“钱夹（wallet）”被盗，如果没有钱夹密码（译者注：TDE涉及3个密码，一个是钱夹密码，用来启动钱夹；一个是master密钥，用来加解密表密钥；一个是表密钥，用来加解密数据，钱夹密码是用户手工输入的，master密钥和表密钥是系统管理的），master密钥还是无法获取。因此，即使窃贼盗取了磁盘或者数据文件的拷贝，也无法解密数据。这样做满足了很多规则和指南的要求，而所有的这些并不需要修改应用程序或者编写复杂的加密和密钥管理系统。

                                           

接下来我将向你展示如何开启和使用TDE。

                                             

1.1 一次安装

                                           

你第一次使用TDE时，必须1）指定“钱夹”的位置，2）设置钱夹密码，3）打开钱夹。

                                    

指定钱夹位置

                                           

当你第一启用TDE，必须创建钱夹。缺省情况下，钱夹创建于$ORACLE_BASE/admin/$ORACLE_SID/wallet目录下。因此，如果$ORACLE_BASE是/u01/app/oracle且$ORACLE_SID是SWBT4，则钱夹将存储在/u01/app/oracle/admin/SWBT4/wallet目录下。你也可以通在位于$ORACLE_HOME/network/admin目录下的sqlnet.ora文件中指定的方式选择一个不同的目录。例如：如果你想讲钱夹放在/orawall目录下，在sqlnet.ora文件中写入如下内容：

                                           

ENCRYPTION_WALLET_LOCATION =

 (SOURCE=

   (METHOD=file)

     (METHOD_DATA=

       (DIRECTORY=/orawall)))

                                           

在如下的样例中，我们将假设钱夹位于缺省的位置下。你也应该在常规的备份中包含钱夹。

                                           

创建钱夹

                                           

现在，你必须创建钱夹，而且必须设定访问密码。为了能够完成此操作，通过如下的操作给一个用户赋予特权（privilege）：

                                           

alter system set encryption key

authenticated by "remnant";

                                           

这条命令完成如下功能：

• 在步骤1中指定的目录下创建了一个钱夹
• 设定了钱夹的密码为“remnant”
• 打开了用于TDE存储和获取master密钥的钱夹

钱夹密码是大小写敏感的且必须用双引号括起来。密码“remnant”在任何动态性能视图或者日志中都不会显示为明文。

                                           

打开钱夹

                                           

由于钱夹只需要创建一次，因此上面的两个步骤只需要执行一次。钱夹必须显式的在数据库启动后打开。当你创建钱夹的同时钱夹也被打开了。当创建钱夹且设定密码后，每次打开数据库的时候，你都必须使用密码按照如下方式打开钱夹：

                                           

alter system set encryption wallet open authenticated by "remnant";

                                           

你可以通过如下方式关闭钱夹：

                                           

alter system set encryption wallet close;

                                           

为了TDE能够正常工作，钱夹必须被打开。如果钱夹被关闭，你还是可以访问没有加密的列，但不能够访问加密的列。

                                           

1.2 加密列

                                           

为了使用TDE加密列，所有你需要做的只是在定义列的时候增加一个简单的谓词“ENCRYPT”。在定义之前，理所当然的你需要决定采用什么样的加密算法和密钥长度。详细讨论请参考我前面提到的文章“Encrypt Your Data Assets”。

 

在一个常规的schema中，假设你有一个如下定义的名称为“account”表：

                                           

ACC_NO      NUMBER

ACC_NAME    VARCHAR2(30)

SSN         VARCHAR2(9)

                                           

目前表的所有数据是明文的，你想转换SSN列为加密的，因此SSN保存了敏感的“社会保险号”，你可以通过如下方式设定：

                                           

alter table accounts modify (ssn encrypt);

                                           

这条语句完成了如下两件事：

• 为表创建了一个表密钥，如果你修改同一个表中的另外的列为加密的，将会使用同一个表密钥
• 将所有列的值转换为加密的形式

这条语句并不修改数据类型或者列的长度，也不创建触发器或者视图。

                                           

缺省情况下采用192位密钥长度的AES算法。你也可以选择不同的算法，只需要在SQL命令中指定即可。例如，如果要使用128位的AES算法，你可以采用如下语句：

                                           

alter table accounts modify (ssn encrypt using 'AES128');

                                             

你可以使用AES128、AES192、AES256、或者3DES168。这些值是自解释的，例如：AES256指采用AES算法、256位长度的密钥。

                                             

加密列之后，当查看表的时候你可以看到如下信息：

                                           

SQL> desc accounts

 

Name           Null?         Type

------------   ------------   --------------------------------------------------

ACC_NO                       NUMBER

ACC_NAME                     VARCHAR2(30)

SSN                          VARCHAR2(9) ENCRYPT

                                           

需要注意的是ENCRYPT关键字在数据类型之后。如果需要查找数据库中加密的列，你可以在数据字典视图中搜索DBA_ENCRYPTED_COLUMNS（TDE不能在SYS所有的表中启用）.

                                           

2 性能考虑

                                           

由于加解密消耗CPU，因此你必须考虑性能的影响。当你访问表中不加密的列时，性能和不使用TDE的表没有任何差别。只有在访问加密列的时候，会有小的性能负担，包括查询加密列和插入加密列，因此你也许想有选择的加密列。

                                             

如果你不再需要对一个列加密，你可以通过如下方式关闭加密功能：

                                             

alter table account modify (ssn decrypt);

                                           

索引的使用也必须考虑。在上面的样例中，让我们假设在SSN列上有一个叫做in_accounts_ssn的索引。如果针对ACCOUNT表的查询有一个相等的谓词，如下所示：

                                             

select * from accounts

where ssn = '123456789';

                                           

这样in_accounts_ssn就会用到。如果用LIKE谓词来代替，如下所示：

                                             

select * from accounts

where ssn like '123%';

                                           

则索引不会被用到，而会采用整表扫描的方式。原因很简单，索引的B-树结构保证了具有相同前缀的值—例如"fraternal", "fraternity"等等在物理上是相邻的。当处理LIKE谓词时，Oracle 10g通过模式匹配来搜索索引入口（entry），物理上相邻有助于加快索引搜索速度，这样也比整表扫描要好一些。

然而，如果列被加密了，索引上实际的值就完全不一样了（因为它们被加密了），因此原来相邻的数据被分散在整个索引上了。这样导致索引扫描笔整表扫描更加消耗性能。因此对于LIKE谓词，Oracle 10g将忽略索引，而直接采用整表扫描。

                                             

在相等匹配的谓词情况下，搜索指定索引取代了按值进行模式匹配，所以使用索引执行比整表扫描要更快，数据库优化器会选择使用索引。

                                             

当你决定加密某列，考虑加密如何影响索引，而且要特别小心你可能想重写涉及加密列的特定查询。

                                             

3密钥和密码管理

                                           

万一有人得到了表密钥，或者你怀疑某人可能已经破解了加密的表密钥，你该如何操作？

你可以简单的为表创建一个新的密钥，换句话说就是重新生成密钥，然后通过如下语句将所有加密列用新密码重新进行加密。你也许会想选择另外一个算法进行加密，例如AES256，你可以通过如下方式同时完成两件事：

                                           

alter table accounts rekey using 'aes256';

                                           

万一有人得到了钱夹的密码怎么办呢？

                                             

你可以通过Oracle Wallet Manager修改钱夹密码，在命令行中输入OWM即可调用如下GUI工具。从顶上的菜单选择Wallet -> Open并且选择你指定的钱夹的位置，然后给出钱夹密码，选择Wallet -> Change Password修改钱夹密码。需要说明的是修改钱夹的密码不会修改master密钥。

 

 

图2：Oracle Wallet Manager

                                           

4 如何处理“Salt”

      

加密是关于如何隐藏数据的，但是如果原始的明文数据有很多重复的数据时，有时很容易能够猜出加密数据的原始值。例如，一个关于薪水信息的表将包含很多重复的值，这种情况下，加密后的值也是一样的。一个入侵者能够确定同一薪水的所有索引入口。为了防护这种情况，将“salt”加入到数据中使得即使原始值相同的数据加密后具有不同的加密值。TDE缺省情况下应用了“salt”技术。

                                             

如果你准备在一个加密的列上创建索引，因此你不能包含“salt”。通过以下方式可以将“salt”从SSN列上移除：

                                             

alter table accounts modify

(ssn encrypt no salt);

                                           

如果你准备在一个包含“salt”的加密列上创建索引，你将得到一个错误提示，就像下面的样例所示：

                                             

SQL> create index in_acc_01

on accounts (ssn);

 

ORA-28338: cannot encrypt indexed column(s) with salt

                                           

当你准备加密一个包含“salt”的列时，你将会得到同样的错误。同样的，如果列上有一个隐含的索引，例如列是主键的一部分，或者列被定义为unique，你将也不能使用加密。以此推断，当一个列是外键的一部分时，你也不能使用salt。

                                             

5 导出TDE加密数据

                                           

缺省情况下，如果你使用EXPDP工具导出一个拥有加密列的表，在导出文件（dump file）中列是明文的，即使列定义为加密也是如此。如下命令导出ACCOUNTS表（包括加密的列），将会返回一个警告：

                                             

$ expdp arup/arup tables=accounts

 

ORA-39173: Encrypted data has been stored unencrypted in dump file set.

                                           

当然，这只是一个警告，不是错误，数据还是会被导出。

                                             

为了在数据导出文件中保护你的加密的列数据，你可以在导出表的时候通过密码保护机制来保护导出文件。这个密码通过在EXPDP命令中的ENCRYPTION_PASSWORD参数指定，且只会应用到本次导出，这个不是“钱夹”的密码（译者注：和TDE没有关系）。如下清单演示了在EXPDP命令中加上“pooh”密码。需要注意的是清单1中的密码并不会显示为“pooh”，而是通过*号来隐藏。最终导出来的dump文件中将不会看到通过TDE加密的列的明文数据了。

                                             

代码清单1：导出密码保护的dump文件

                                             

$ expdp arup/arup ENCRYPTION_PASSWORD=pooh tables=accounts

 

Export: Release 10.2.0.0.0 - Beta on Friday, 01 July, 2005 16:14:06

 

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

 

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 - Beta

With the Partitioning, OLAP and Data Mining options

Starting "ARUP"."SYS_EXPORT_TABLE_01":  arup/******** ENCRYPTION_PASSWORD=********* tables=accounts

Estimate in progress using BLOCKS method...

Processing ...

                                           

当你导入加密的dump文件时，你也必须提供同样的密码，代码清单2显示了如何操作：

                                             

代码清单2：导入密码保护的dump文件

 

$ impdp arup/arup ENCRYPTION_PASSWORD=pooh tables=accounts table_exists_action=replace

 

Import: Release 10.2.0.0.0 - Beta on Friday, 01 July, 2005 16:04:20

 

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

 

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 - Beta

With the Partitioning, OLAP and Data Mining options

Master table "ARUP"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded

Starting "ARUP"."SYS_IMPORT_TABLE_01":  arup/******** ENCRYPTION_PASSWORD=********* table_exists_action=replace

Processing ...

                                           

如下样例展示了在导入的时候不输入ENCRYPTION_PASSWORD参数时的结果：

                                             

$ impdp arup/arup tables=accounts

      

ORA-39174: Encryption password must

be supplied.

The following shows the result if you provide the wrong password:

$ impdp arup/arup ENCRYPTION_PASSWORD

=piglet tables=accounts

 

ORA-39176: Encryption password is

incorrect.

                                           

注意：原有的导出工具EXP无法导出有加密列的表。

                                             

6 总结

                                           

保护你的数据使其免遭攻击且使其符合数不清的管理业务相关的法律不是一件微不足道的事情。TDE让你快速的提供数据加密功能，并且不需要任何代码和复杂的密钥管理就能够符合这些法律，因此你可以更多的聚焦你的战略成就！

                                             

更多学习

更多加密信息

oracle.com/technology/oramag/oracle/05-jan/o15security.html

www.dbazine.com/olc/olc-articles/nanda11

更多TDE信息

Oracle Database Advanced Security Administrator's Guide

 

7 补充

除了对列进行加密外，Oracle TDE还可以对表空间进行加密，至于何时选择对列进行加密，何时选择对表空间加密，请另外搜索。