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

最新推荐文章于 2023-05-13 03:20:37 发布

cuanyueju1441

最新推荐文章于 2023-05-13 03:20:37 发布

阅读量435

点赞数

Transparent Data Encryption透明加密技术是Oracle在10g版本之后推出的数据层加密技术。核心概念是借助外置于数据库的加密文件，对数据表列乃至表空间等多层次进行加密。这种技术对存储在数据库中的敏感信息，提供了简单可靠的安全防护解决方案。

透明加密技术概要

简单的说，Transparent Data Encryption（以下简称为TDE）是一种基于加密键key的访问控制系统。加密过的数据直接放置在数据库中，如果没有解密授权，从数据库中搜索出的数据都是不可读的非明文。只有指定的用户ID进行读取时，才进行自动的解密操作。

TDE的加密组件机制中包括主加密key（Master Encryption Key）和数据列加密key（Column Encryption Keys）。主加密key是保存在数据库外，通常是建立在一个安全目录的文件，受到系统级别安全管理。而数据列加密key是建立在数据库的数据字典中。在数据库外保存的主加密key也称为Oracle Wallet。

在工作的时候，Oracle是不需要利用如触发器等组件的协助实现TDE功能。只需要指定进行加密处理的对象（数据列、表空间等），Oracle自己进行数据的加密和解密操作。进行加密和解密的时候，Oracle首先使用主加密key对数据字典里的数据列key进行加解密，之后解密过的数据列key就可以数据列进行加解密操作。相当于将加解密的key分割在数据库内部和数据库外部两部分。

一、 TDE如何工作

使用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。

二、使用TDE

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

2.1指定钱夹位置

当你第一启用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=c:\orawall))

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

2.2创建钱夹

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

alter system set encryption key authenticated by "remnant";

这条命令完成如下功能：

在步骤1中指定的目录下创建了一个钱夹

设定了钱夹的密码为“remnant”

打开了用于TDE存储和获取master密钥的钱夹

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

2.3打开钱夹

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

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

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

alter system set encryption wallet close;

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

2.4 加密列

为了使用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.5性能考虑

由于加解密消耗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将忽略索引，而直接采用整表扫描。

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

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

2.6密钥和密码管理

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

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

alter table accounts rekey using 'aes256';

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

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

图2：Oracle Wallet Manager

2.7 如何处理“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。

2.8 导出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参数指定，且只会应用到本次导出，这个不是“钱夹”的密码。如下清单演示了在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

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

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无法导出有加密列的表。

三、总结

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

1.jpg

2.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12751636/viewspace-701990/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12751636/viewspace-701990/

cuanyueju1441

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Oracle数据安全解决方案——透明数据加密技术TDE

Transparent Data Encryption透明加密技术是Oracle在10g版本之后推出的数据层加密技术。核心概念是借助外置于数据库的加密文件，对数据表列乃至表空间等多层次进行加密。这种技术对存储在数据库中的敏感信息...
复制链接

扫一扫