文章內(nèi)容

Oracle 10g第2版新特性之SQL和PL/SQL

發(fā)布時(shí)間: 2012/7/13 15:22:39

對(duì)于加密，許多用戶深感矛盾：他們既感興趣，又因意識(shí)密鑰管理的復(fù)雜性而感到慎重，如果處理不當(dāng)，則會(huì)導(dǎo)致設(shè)置的效率低下。加密和解密值還會(huì)帶來相關(guān)的性能開銷，這使得大部分應(yīng)用程序架構(gòu)師不太樂于接受該過程。結(jié)果是，很多系統(tǒng)設(shè)計(jì)根本沒有加密，只是構(gòu)筑了強(qiáng)大的外圍防護(hù)，如強(qiáng)大的口令和適當(dāng)?shù)氖跈?quán)方案。

　　但是，請(qǐng)想象一下如果整個(gè)服務(wù)器被盜了，甚至只是磁盤被盜，這些磁盤可以裝配在具有相同操作系統(tǒng)的服務(wù)器上，然后其中的數(shù)據(jù)將被銷毀殆盡�；蛘哂幸粋€(gè)的 DBA 品行不端，在日常業(yè)務(wù)活動(dòng)中惡意突破了外圍防護(hù)，然后將您所有重要的客戶信息洗劫一空。在這兩種情況下，如果所涉及的商業(yè)機(jī)構(gòu)是在加利福尼亞州(可能不久之后在美國(guó)的其他州)，它們?cè)诜缮嫌胸?zé)任將安全漏洞的情況通知給所有受到影響的客戶。

　　在上述罕見(但確是事實(shí))的情況中，認(rèn)證方案沒有實(shí)際意義。這就是為什么對(duì)于那些將安全作為頭等大事的機(jī)構(gòu)而言，透明數(shù)據(jù)加密 (TDE) 是一個(gè)如此有用的特性;它支持加密，同時(shí)將密鑰管理的復(fù)雜性交給數(shù)據(jù)庫引擎來處理。同時(shí)，它允許 DBA 在不必實(shí)際看到數(shù)據(jù)的情況下管理數(shù)據(jù)庫表。

　　在 Oracle 數(shù)據(jù)庫 10g 第 2 版中使用 TDE 時(shí)，可以隨時(shí)地對(duì)表中的一列或多列進(jìn)行加密;只需將列定義為加密形式即可，不用編寫代碼。請(qǐng)記住，加密需要使用密鑰和算法對(duì)輸入值進(jìn)行加密。TDE 為特定的表生成單獨(dú)的密鑰。這種方法方便了密鑰管理卻也更易被他們竊取，所以數(shù)據(jù)庫提供了另一種密鑰 — 萬能密鑰 — ，它可以在數(shù)據(jù)庫級(jí)別上設(shè)置。表密鑰是利用萬能密鑰進(jìn)行加密的，要獲得表密鑰就需要這個(gè)萬能密鑰。因此，對(duì)列進(jìn)行解密時(shí)需要萬能密鑰和表密鑰。

　　萬能密鑰存儲(chǔ)在數(shù)據(jù)庫外一個(gè)稱為“錢夾”的地方 — 默認(rèn)位置在 $ORACLE_BASE/admin/$ORACLE_SID/wallet。在概念上，它類似于下圖。

　　在配置 TDE 之后 — 或者更明確地說是配置了錢夾和萬能密鑰之后 — 您可以使用它來保護(hù)數(shù)據(jù)值。要為表的一列加密，需要使用以下 SQL：

以下是代碼片段：
create table accounts
　　(
　　acc_no number not null,
　　first_name varchar2(30) not null,
　　last_name varchar2(30) not null,
　　SSN varchar2(9) ENCRYPT USING 'AES128',
　　acc_type varchar2(1) not null,
　　folio_id number ENCRYPT USING 'AES128',
　　sub_acc_type varchar2(30),
　　acc_open_dt date not null,
　　acc_mod_dt date,
　　acc_mgr_id number
　　)