Oracle 10G 新特性--透明資料加密技術(TDE)

在Oracle的最新版本10g R2中，出現最及時的技術應該是透明資料加密技術(Transparent Data Encryption，TDE)。

 

TDE用來對資料加密，通常 SQL 執行的應用程式邏輯不需要進行更改，仍能正常執行。 換言之，應用程式可以使用同一語法將資料插入到應用程式表中，並且 Oracle 資料庫在將資訊寫入磁碟之前將自動對資料進行加密。 隨後的選擇操作將透明地解密資料，因此應用程式將繼續正常地執行。 這一點很重要，因為當前的應用程式通常期望未加密的應用程式資料。 顯示加密資料至少會使應用程式使用者迷惑不解，甚至還會破壞現有的應用程式。

 

設定加密金鑰：

 

Oracle 透明資料加密提供了實施加密所必需的關鍵管理基礎架構。 加密的工作原理是將明文資料以及祕密（稱作金鑰）傳遞到加密程式中。 加密程式使用提供的金鑰對明文資料進行加密，然後返回加密資料。 以往，建立和維護金鑰的任務由應用程式完成。 Oracle 透明資料加密通過為整個資料庫自動生成一個萬能金鑰解決了此問題。 在啟動 Oracle 資料庫時，管理員必須使用不同於系統口令或 DBA 口令的口令開啟一個 Oracle Wallet 物件。 然後，管理員對資料庫萬能金鑰進行初始化。 萬能金鑰是自動生成的。

 

效能：

由於索引資料未被加密，因此加密通常會影響現有的應用程式索引。 Oracle 透明資料加密對與給定應用程式表關聯的索引值進行加密。 這意味著應用程式中的相等搜尋對效能的影響很小，甚至沒有任何影響。 例如，假設應用程式 card_id存在一個索引，並且此應用程式執行以下語句：

 

SQL> Select cash from credit_card where card_id = '1025023590';

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)。 

 

2. 接下來，您需要開啟錢夾並建立萬能加密金鑰。從終端視窗中，輸入以下命令：

connect / as sysdba

alter system set key identified by "welcome1";

 

此命令的作用為：

 

l          如果指定的目錄中不存在加密錢夾，則將建立加密錢夾 (ewallet.p12)、開啟此錢夾並建立/重新建立 TDE 的萬能金鑰。

l          如果指定目錄中存在加密錢夾，則將開啟此錢夾並建立/重新建立 TDE 的萬能金鑰。

 

之後，就可以測試資料了。

 

 

下面是實驗記錄：

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 特性，對於防止機密資訊的洩漏能起到事半功倍的作用！

   --The End--

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7220098/viewspace-193965/，如需轉載，請註明出處，否則將追究法律責任。