超過口令的數(shù)據(jù)庫安全

近來， 公眾和企業(yè)對于保護私有和私人信息的意識有了顯著的增強。 隨著許多國家/地區(qū)現(xiàn)在出臺了特定的法規(guī)， 保護個人信息數(shù)據(jù)現(xiàn)在已經(jīng)不僅僅是項公共關(guān)系事務(wù)， 而且還是一項法定義務(wù)。

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

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

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

　　數(shù)據(jù)庫安全性目標

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

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

　　Oracle 應(yīng)用服務(wù)器(作為數(shù)據(jù)庫的安全客戶端)可以在需要時讀取、插入和更新所有數(shù)據(jù)。 Oracle 應(yīng)用服務(wù)器將使用它的內(nèi)部安全機制和應(yīng)用程序?qū)Ｓ玫陌踩珯C制來確保私人數(shù)據(jù)免遭表示層中的未授權(quán)用戶的入侵。

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

　　其他數(shù)據(jù)庫訪問無法檢索私人客戶端信息。

　　演示安裝

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

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

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

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

　　安全性實施

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

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

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

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

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

　　直接的 SQL*Plus 訪問

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

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

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

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

　　示例腳本中的數(shù)據(jù)列表演示了如上所述的內(nèi)容。

　　加密數(shù)據(jù)和程序包

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

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

　　但為了獨立于應(yīng)用程序， 支持文件中演示的示例將其他表列用作加密密鑰。 密鑰列中存儲的值必須是靜態(tài)的， 這是因為如果該值更改， 則 CARD_NO 數(shù)據(jù)將無法再被解密。 在本示例中， 我們?yōu)榇嗣荑�選擇了 CREATED_BY 列， 原因是記錄創(chuàng)建后它將不會進行更新。

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

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

　　操作加密數(shù)據(jù)

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

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

　　insert into CUSTOMER (NAME, CARD_NO)

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

　　轉(zhuǎn)換為：

　　insert into CUSTOMER (NAME, CARD_NO)

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

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

　　select NAME, CARD_NO

　　from CUSTOMER;

　　修改為：

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

　　from CUSTOMER;

　　保護環(huán)境

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

　　wrap iname=Secure_Package.sql oname=Secure_Package.sec

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

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

　　在不區(qū)分訪問的情況下審計對敏感數(shù)據(jù)的訪問

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

　　audit insert, update, select on SHIP2004.CUSTOMER;

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

　　可以使用 Oracle 提供的功能輕松地增強此處提供的示例， 從而加入電子郵件或?qū)ず魴C通知和激活條件， 以只生成特定事件的審計記錄。 有關(guān)數(shù)據(jù)庫審計策略和實現(xiàn)的其他信息， 請參閱 Oracle 文檔。

　　結(jié)論

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

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