近來， 公眾和企業對于保護私有和私人信息的意識有了顯著的增強。 隨著許多國家/地區現在出臺了特定的法規， 保護個人信息數據現在已經不僅僅是項公共關系事務， 而且還是一項法定義務。

　　無論如何， 保護 IT 系統(無論是在事務處理 (OLTP) 還是在數據倉庫環境中)中的機密數據都是企業運營的首要考慮事項。 例如， 您能想象到一個在數據庫中未存儲客戶姓名、地址和信用卡卡號的銷售系統嗎?私人數據是當前系統的戰略資產， 因此公司應采取一種具有積極和健壯的綜合方法， 通過安全策略實施來保護機密數據。 從這個角度看來， 組織的戰略和戰術決策必須以最終結果為導向， 而不是集中于特定項目或當前的業務需要， 從而避免重新設計而帶來的高成本甚至是失去客戶。

　　通常會采用許多復雜措施阻止在網絡和操作系統級的未授權訪問， 并且將其集成到非定制或定制的應用程序系統中。 而實際存儲信息的的數據庫卻往往只使用標準的用戶名/口令機制進行保護。 Oracle 數據庫 10g 對這一機制的實現是最好的， 即使這樣， 如果口令泄密， 那么保護也將隨之不再存在了。 Oracle 數據庫可以通過 Oracle 虛擬專用數據庫、Oracle 標簽安全和其它機制提供更多保護， 但這些機制在實際生產中仍未得到充分應用。

　　在這篇技術文章中， 我將介紹(并通過演示說明)在假定一個或多個數據庫口令已經泄露的情況下， 如何實現安全機制。 此方法提供了一種簡單的方法來組合使用 Oracle 數據庫 10g 第 1 版中安全特性(Oracle9i 中包含有其中的一部分特性)， 使得在入侵者即使建立了數據庫連接的情況下， 仍能實現高級別的保護。 其主要目的是避免機密數據遭到未授權用戶(無論該用戶是外來的黑客還是公司內部的數據庫管理員)的破壞。 所提供的示例專用于事務環境， 但這于原理同樣可應用于商務智能和數據倉庫環境中。

　　數據庫安全性目標

　　Oracle 數據庫是實際安全實施的重要組成。 一般說來， 運行 Oracle 數據庫引擎的服務器得到了防火墻的很好保護， 但這并不能排除未授權訪問嘗試(包括內部員工的訪問嘗試)的可能性。 除了傳統的用戶名/口令方法之外， Oracle 數據庫引擎還提供了自身的安全機制， 以便即使在通過了其他所有安全障礙的情況下， 仍能保護它的數據內容。 以下各部分中確定的安全措施都假定入侵已滲透到數據庫級別， 這些措施將用作數據庫自身的最后一道防線， 但它們并不能用來代替外部保護。

　　在假定所有其他安全措施已被繞過， 并且未授權數據庫訪問已經開始了的前提下， 以下各部分定義的解決方案都用于構建數據庫防御特性， 以確保：

　　Oracle 應用服務器(作為數據庫的安全客戶端)可以在需要時讀取、插入和更新所有數據。 Oracle 應用服務器將使用它的內部安全機制和應用程序專用的安全機制來確保私人數據免遭表示層中的未授權用戶的入侵。

　　使用 SQL*Plus， 在錯誤解決過程中能夠進行安全的數據庫訪問， 包括能夠查看機密信息。

　　其他數據庫訪問無法檢索私人客戶端信息。

　　演示安裝

　　本練習包含一個典型的銷售類型數據模型， 其中要保護的數據存儲在 CUSTOMER 數據庫中， 具體而言是 CARD_NO 列中。 該示例使整個表對未授權請求顯示為空， 因此進行 SELECT * from CUSTOMER; 將檢索不到任何記錄。 一個表面上看起來不包含任何記錄的表將比包含記錄但將“令人感興趣”的列隱藏或屏蔽起來的表更不會引起入侵者的關注(他們認為前者可能根本未被使用)。

　　但對 DBMS_RLS.ADD_POLICY 調用稍微進行修改后， 此解決方案將隱藏(顯示為 NULL)或屏蔽(顯示為 ****)受保護列 CARD_NO 的值， 但顯示其他列的值的記錄。 可以通過在 DBMS_RLS.ADD_POLICY 調用中指定 sec_relevant_cols 和 sec_relevant_cols_opt 參數來實現功能。 本文的支持文件中的 initial_setup.sql 腳本創建了一個非常基本的 CUSTOMER 表， 該表作為本過程中的示例。

　　最好避免使用模式所有者身份來訪問數據;而是應一個不同的帳戶(如 AppSvr),該帳戶由所有客戶端連接共享， 并由 Oracle 應用服務器處理。 AppSvr 數據庫用戶不擁有任何對象， 并且只擁有 CREATE SESSION 系統權限， 但擁有對所有包含模式所有者(如 SHIP2004 模式的所有者)應用程序數據的表的 SELECT、INSERT、UPDATE 和 DELETE 權限。

　　支持文件中的 enable_connection.sql 腳本創建一個通常由運行在 Oracle 應用服務器上的應用程序使用的用戶(如上所述)。

　　安全性實施

　　為實現所述的安全目標， 除非您“授權”了連接(由在預定的 IP 地址處運行的 Oracle 應用服務器啟用)， 我們將使用一個數據庫策略來隱藏 CUSTOMER 表中的記錄， 。 此策略在安全管理器用戶(如 Sec_Manager)下實現， 因此即使從 SHIP2004 或 AppSvr 模式中也看不到它。

　　確定要使用的環境變量以及要由安全謂詞檢查的特定值是實現的問題。 大量的潛在組合和特殊的網站詳細信息將創建重要的入侵嘗試障礙。

　　為安全實現中使用的所有定義創建一個沒有任何權限(甚至是 CONNECT)的單獨模式(如 Sec_Manager)作為占位符是比較可取的。 所有對象將由 Sec_Manager 模式中的數據庫管理員帳戶創建。 由于沒有權限， 此用戶名甚至無法用于登錄到數據庫， 因此所擁有的安全性定義將得到可靠地保護。 (任何人甚至看不到與安全性相關的對象的定義。 )

　　但本文最初的目標之一是為幾個維護和支持人員成員實現 SQL*Plus 級別的訪問。 此緊急訪問需要一個“安全通道”， 它可以被授權用戶輕松記住， 但由于太長而無法寫入到桌面即時貼中(可由任何人看到)， 這種由于所保留的口令數目所導致的不利情況。 本示例使用 CLIENT_IDENTIFIER 環境變量， 但它可以為您所選擇的任何環境變量或環境變量組合。

　　create_setup.sql 腳本(位于支持文件中)演示了如何根據以上描述創建安全實現模式、謂詞函數以及安全策略。 它還生成了幾個數據列表， 并使用不同的數據庫登錄權限演示了將在 CUSTOMER 表中看到(或看不到)的不同連接。 它還演示了如何使用 dbms_session.set_identifier 函數進行解密， 以通過 SQL*Plus 連接訪問數據。

　　直接的 SQL*Plus 訪問

　　由于 Oracle 應用服務器具有強健的內置安全特性(用于驗證和授權請求)， 因此直接的 SQL*Plus 訪問是入侵者通常使用的入口點。 實現如上所述的安全策略后， 將具備以下功能：

　　即使 AppSvr 口令已被破壞， 且某個人使用 AppSvr 登錄以通過 SQL*Plus 進行未授權訪問， CUSTOMER 數據也不會顯示， 這是因為 IP 地址和/或外部會話名稱不是安全謂詞所預期的—系統甚至不會顯示受保護的表中存在有任何記錄。

　　聯網應用程序將不會使用模式所有者帳號登錄。 它將只用于維護目的， 因此會嚴格控制它的發放人數。 此外， 它們將必須正確地完成一個或多個環境設置(本示例中為 CLIENT_IDENTIFIER)才能查看 CUSTOMER 數據。 即使口令遭到破壞(例如， 某個人找到桌面上的即時貼)， 只要安全謂詞中隱藏的后門設置未被泄露， 受保護的表也將對訪問它的未授權用戶顯示為空。 由于入侵者甚至不知道該表中存在數據， 因此根本不可能對其進行進一步的研究。

　　任何其他數據庫用戶(甚至擁有數據庫管理員權限的用戶)都看不到受保護表中的記錄。 然而， 即使其他數據庫用戶通過某種方式獲得了 SHIP2004 表的訪問權限， 以上所述的注意事項也仍然有效。 (用戶必須了解安全特性才能看到私人數據。 )

　　示例腳本中的數據列表演示了如上所述的內容。

　　加密數據和程序包

　　加密 CARD_NO 數據可以確保為機密數據再添加一層數據保護。 可以使用外部進程中定義的靜態密鑰或數據庫的列中存儲的靜態密鑰進行加密。 一個比較可取的方法是將加密組件(密鑰和函數)劃分到兩個單獨的服務器， 以增加環境的復雜性和潛在的入侵者檢索所有所需信息以解密受保護數據所需的工作量。

　　如果在應用程序中定義密鑰， 則攻擊者將不但必須進入數據庫服務器， 而且必須進入應用服務器才能獲得此密鑰以解密數據。 即使某個人攻破了以上各部分中描述的訪問保護， 他仍必須破解程序包代碼(按下個部分“保護安全環境”中的描述進行編碼)才能知道所應用的加密函數。 攻擊者還必須破解位于應用服務器中的已編譯的應用程序代碼才能識別所使用的密鑰。 如果此密鑰未存儲在任何明文文件(如參數文件或源代碼)中， 而是只存儲在已編譯的版本中， 則通過未授權訪問檢索實際加密數據所需的技能和難度將隨之提高。

　　但為了獨立于應用程序， 支持文件中演示的示例將其他表列用作加密密鑰。 密鑰列中存儲的值必須是靜態的， 這是因為如果該值更改， 則 CARD_NO 數據將無法再被解密。 在本示例中， 我們為此密鑰選擇了 CREATED_BY 列， 原因是記錄創建后它將不會進行更新。

　　最大限度地減少加密所需的額外工作的最便捷的解決方案是創建一個程序包， 該程序將用于從根本上隱藏對 Oracle 的加密實用程序調用。 開發人員將只需生成一個函數調用而不是直接使用受保護的列， 這是為獲取安全保障而產生的一個很小的不便之處。 本示例使用 DBMS_CRYPTO 程序包中的 ENCRYPT 和 DECRYPT 函數， 該程序包提供了許多加密方法(有關其他詳細信息， 請參閱 Oracle 文檔)。 大量的選項組合(針對所選擇的密鑰)增加了攻破所提供解決方案的復雜度， 尤其是按如下所述對定制程序包的源代碼進行了打包后。 (create_packages.sql 腳本為本文描述的加密/解密函數提供了示例設置。 )

　　Oracle 數據庫 10g 第 2 版提供了隨取隨用的透明數據加密， 使您能夠透明地加密任何常規數據庫列(日期、字符串、數字)并在用戶通過了必需的訪問控制檢查時自動將其解密。 Oracle 引擎本身(不受數據庫用戶的控制)可以處理加密密鑰， 因此對表的應用程序或 SQL 訪問不必再管理這些密鑰。 通過擴展， 數據庫管理員可以管理表但看不到實際的數據值， 這將解決以上設置所涉及的部分問題。

　　操作加密數據

　　Oracle 應用服務器應用程序使用 Sec_Manager.Secure_Package 程序包中的例程存儲加密格式的私人數據(如使用 Secure_Package.Secure_Data 存儲 CARD_NO 數據)。 根據 create_packages.sql(位于支持文件中)中描述的定制加密程序包的定義， 對 CARD_NO 列的訪問已被函數調用所取代， 該函數調用的參數是要存儲在列中的值以及用于數據解密的密鑰。

　　例如， 要將“a1b2c3d4”用作加密密鑰， 必須將最初如下所示的典型 INSERT 語句

　　insert into CUSTOMER (NAME, CARD_NO)

　　values ('Jane Doe', '1234123412341234');

　　轉換為：

　　insert into CUSTOMER (NAME, CARD_NO)

　　values ('Jane Doe', Sec_Manager.Secure_Package.Secure_Data('1234123412341234','a1b2c3d4'));

　　同樣， Oracle 應用服務器應用程序還使用 Sec_Manager.Secure_Package 中的例程讀取加密格式的數據， 如 CARD_NO 數據的 Secure_Package.Clear_Data。 然后利用插入值時使用的加密密鑰來以明文格式取回受保護信息。 這種情況下， 必須將最初為如下所示的典型 SELECT 語句

　　select NAME, CARD_NO

　　from CUSTOMER;

　　修改為：

　　select NAME, Sec_Manager.Secure_Package.Clear_Data(CARD_NO,'a1b2c3d4')

　　from CUSTOMER;

　　保護環境

　　當完成所有開發(希望由值得信任的人員完成)后， 還可以將升級后的代碼加密， 以便甚至連升級腳本的數據庫管理員都無法確切了解安全性的實現方法。 通過 Oracle 提供的實用程序實現加密， 可以使用如下所示命令

　　wrap iname=Secure_Package.sql oname=Secure_Package.sec

　　打包后， 可以在 SQL*Plus 提示符后象執行任何明文腳本一樣執行 Secure_Package.sec， 且 Oracle 引擎還將對其進行解釋。 同一概念也可應用于任何其他與安全性相關的 PL*SQL 腳本。 此方法不但禁止了參與代碼升級的人員(數據庫管理員、開發人員、支持和管理人員)查看程序包內容， 而且程序包內容還以加密格式部署到數據庫中， 因此以后要嘗試破解這些程序包內容是很難的。

　　即使具有數據庫管理員權限的入侵者將 CONNECT 權限授予安全對象所有者 Sec_Manager 以查看保護和加密程序包的內容， 也不會有任何明文會存儲在這些對象的數據庫中。 由于 Oracle 未提供任何“解包”實用程序， 因此入侵者將必須破解 Oracle 的加密算法才能夠查看程序包內容。

　　在不區分訪問的情況下審計對敏感數據的訪問

　　即使所有安全措施都已經到位了， 了解是否對機密數據進行了未授權訪問仍很重要。 最簡單的方法是使用內置的數據庫審計功能在表級別監視對受保護數據的訪問(SELECT、INSERT、UPDATE、DELETE)， 而不管請求事務的數據庫連接如何， 命令如下：

　　audit insert, update, select on SHIP2004.CUSTOMER;

　　但使用 Oracle Fine Grained Auditing (FGA)， 您可以進一步改進訪問監視以最小化處理開銷并提供有意義的信息。 enable_fga.sql 中提供的示例使用 DBMS_FGA 程序包啟用基本的審計策略。 數據庫中的內置審計機制禁止用戶繞過審計， 從而確保了它的精確性。 可以在 DBA_FGA_AUDIT_TRAIL 視圖以及 DBA_COMMON_AUDIT_TRAIL 視圖中查看審計記錄， 在策略指定 audit_trail = DBMS_FGA.DB_EXTENDED 的情況下， 審計記錄甚至可以包含 SQLBIND 和 SQLTEXT 信息。

　　可以使用 Oracle 提供的功能輕松地增強此處提供的示例， 從而加入電子郵件或尋呼機通知和激活條件， 以只生成特定事件的審計記錄。 有關數據庫審計策略和實現的其他信息， 請參閱 Oracle 文檔。

　　結論

　　隨著入侵嘗試變得日益復雜， 系統架構師和管理員必須定義更好的方法來保護他們的數據庫內容。 以非常的方式組合一系列常用方法可以使入侵者如同進入了迷宮， 無功而返。

　　即使當 AppSvr 和 SHIP2004 模式的口令被“意外”泄露時， 本文描述的方法也是行之有效的， 因此可以將它用作安全環境中的組件來保護戰略數據資源并增加客戶對于私人數據的保密性的信心。 從長遠看來， 這有助于改善客戶關系并拓展商機。