Oracle 10G 新特性--透明数据加密技术(TDE)

转载：http://blog.csdn.net/cxin917/article/details/2180702

在Oracle的最新版本10gR2中，出现最及时的技术应该是透明数据加密技术(Transparent Data Encryption，TDE)。
 
TDE用来对数据加密，通常SQL执行的应用程序逻辑不需要进行更改，仍能正常运行。换言之，应用程序可以使用同一语法将数据插入到应用程序表中，并且Oracle数据库在将信息写入磁盘之前将自动对数据进行加密。随后的选择操作将透明地解密数据，因此应用程序将继续正常地运行。这一点很重要，因为当前的应用程序通常期望未加密的应用程序数据。显示加密数据至少会使应用程序用户迷惑不解，甚至还会破坏现有的应用程序。
 
设置加密密钥：
 
Oracle透明数据加密提供了实施加密所必需的关键管理基础架构。加密的工作原理是将明文数据以及秘密（称作密钥）传递到加密程序中。加密程序使用提供的密钥对明文数据进行加密，然后返回加密数据。以往，创建和维护密钥的任务由应用程序完成。Oracle透明数据加密通过为整个数据库自动生成一个万能密钥解决了此问题。在启动Oracle数据库时，管理员必须使用不同于系统口令或DBA口令的口令打开一个Oracle Wallet对象。然后，管理员对数据库万能密钥进行初始化。万能密钥是自动生成的。
 
性能：
由于索引数据未被加密，因此加密通常会影响现有的应用程序索引。Oracle透明数据加密对与给定应用程序表关联的索引值进行加密。这意味着应用程序中的相等搜索对性能的影响很小，甚至没有任何影响。例如，假设应用程序card_id存在一个索引，并且此应用程序执行以下语句：
 
准备用于加密的数据库：
 
在本部分内容中，您将更新sqlnet.ora、创建一个加密钱夹(ewallet.p12)、打开此钱夹并为TDE创建万能密钥。执行以下操作：
 
1.您需要更新sqlnet.ora文件以包含一个ENCRYPTED_WALLET_LOCATION条目。打开一个终端窗口，然后输入以下命令：
 
cd $ORACLE_HOME/network/admin
gedit sqlnet.ora
将以下条目添加到文件末尾：
 
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/admin/test97/wallet/)))
 
如果不加这一项的话，则会提示下面错误：
 
SQL> alter system set key identified by "hurray"
 2 ;
alter system set key identified by "hurray"
*
ERROR at line 1:
ORA-28368: cannot auto-create wallet
 
/opt/oracle/admin/test97/wallet/目录是用来存放生成的钱夹的。
可以为加密钱夹选择任何目录，但路径不应指向在数据库安装过程中创建的标准模糊钱夹(cwallet.sso)。 
 以上设置是指linux中设置，如果是在windows下，假设oracle安装在G:/oracle中，则只需要在g:/oracle/product/10.2.0/admin/oracle10/x下新建wallet文件夹即可
2.接下来，您需要打开钱夹并创建万能加密密钥。从终端窗口中，输入以下命令：
connect / as sysdba
alter system set key identified by "welcome1";
 
此命令的作用为：
 
l         如果指定的目录中不存在加密钱夹，则将创建加密钱夹(ewallet.p12)、打开此钱夹并创建/重新创建TDE的万能密钥。
l         如果指定目录中存在加密钱夹，则将打开此钱夹并创建/重新创建TDE的万能密钥。
 
之后，就可以测试数据了。
 
 
下面是实验记录：
首先以dba登录，执行alter system set key identified by "welcome1";
 
SQL> conn dodd/dodd123
create table test (id number,credit_card_number varchar2(16) ENCRYPT NO SALT);
 
SQL> insert into test values(1,'1231243242');
 
1 row created.
SQL> insert into test values(2,'33245235');
SQL> commit;
Commit complete.
 
SQL> select * from test;
 
       ID CREDIT_CARD_NUMB
---------- ----------------
        1 1231243242
        2 33245235
可见，数据查看是明文，因为这个时候，加密钱夹已经打开，数据可以解密。
 
这时，停止数据库，再打开：
SQL> shutdown immediate
 
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> SQL> startup
ORACLE instance started.
 
Total System Global Area 524288000 bytes
Fixed Size                 1979968 bytes
Variable Size            138414528 bytes
Database Buffers         377487360 bytes
Redo Buffers               6406144 bytes
Database mounted.
Database opened.
 
SQL> select * from dodd.test;
select * from dodd.test
                  *
ERROR at line 1:
ORA-28365: wallet is not open
 
 
SQL> select id from dodd.test;
 
       ID
----------
        1
        2
可以看到，因为数据库重启后，加密钱夹处于关闭状态，这时只要查询到加密的列，会提示加密钱夹没有打开。
 
如果用户想打开钱夹，必须具有alter system权限。
 
下面打开wallet：
SQL> conn / as sysdba
Connected.
SQL> alter system set wallet open identified by "welcome1";
 
System altered.
 
SQL> conn dodd/dodd123
Connected.
 
SQL> select * from test;
 
       ID CREDIT_CARD_NUMB
---------- ----------------
        1 1231243242
        2 33245235
 
可以看到，加密钱夹打开后，数据可以被解密。
 
还有一条：sys用户的表不能被加密。
 
可见：Oracle TDE是在数据层面上对表里的数据加密，而且不会影响数据库现有的权限控制策略。
 
l         salt实际上就是在加密过程中引入一个随机性。简单的说，就是一般来说，同样的明文产生同样的密文，这样就导致容易被解密者通过分析词频之类的方式（加解密我不太懂）来通过密文破解明文，如果指定salt，那么即使同样的明文加密后的密文也是不一样的。
 
no salt的话，自然就是相同的明文会产生相同的密文了。对于索引来说，要求no salt也就可以理解了
l         丢失ewallet加密钱夹的话，是不能再解密数据的。
 
Oracle 10gR2的 TDE 特性，对于防止机密信息的泄漏能起到事半功倍的作用！
 
SQL> Select cash from credit_card where card_id = '1025023590';


Oracle 数据库将使用现有的应用程序索引，尽管 card_id信息已经在数据库中加密。