Oracle的行級安全性為用戶提供了他們自己的虛擬專有數(shù)據(jù)庫。鑒于隱私法，如美國的HIPAA（健康保險移植和責任法案）、Gramm-Leach-Bliley法案、Sarbanes-Oxley法案以及歐共體的安全港法律（Safe Harbour Law），確保適當?shù)男畔㈦[私是當今眾多企業(yè)迫切關心的一個問題。其他隱私指令，如Visa的持卡人信息安全計劃（Cardholder Information Security Program，CISP）也要求企業(yè)確保對信息的訪問是得到嚴格控制的。 Oracle一直都提供授權（或拒絕）用戶訪問數(shù)據(jù)庫對象的能力，但是這些訪問權限是在對象級別上定義的--是對于整張表，而不是對于表中特定的行而定義的。雖然對于許多應用程序來說這種方法已經(jīng)足夠了，但涉及金融、健康或其他類型的個人信息的應用程序通常需要對訪問和授權進行更加獨立的控制。 Oracle8i中引入的Oracle行級安全性（row-level security，RLS）特性提供了細粒度的訪問控制--細粒度意味著是在行一級上進行控制。行級安全性不是向對表有任何訪問權限的用戶打開整張表，而是將訪問限定到表中特定的行。其結果就是每個用戶看到完全不同的數(shù)據(jù)集--只能看到那些該用戶被授權可以查看的數(shù)據(jù)--所有這些功能有時被稱為的Oracle虛擬專有數(shù)據(jù)庫（或稱為VPD）特性。 使用Oracle的VPD功能不僅確保了企業(yè)能夠構建安全的數(shù)據(jù)庫來執(zhí)行隱私政策，而且提供了應用程序開發(fā)的一個更加可治理的方法，因為雖然基于VPD的政策限制了對數(shù)據(jù)庫表的訪問，但在需要的時候可以很輕易地對此做出修改，而無需修改應用程序代碼。 例如，假設銀行的賬戶經(jīng)理（AM）向高凈值賬戶持有者提供個人客戶支持。AM使用定制的銀行應用程序來幫助他們檢查客戶的余額、存款或提取的款項，以及對貸款要求做出決定。銀行的政策曾經(jīng)答應所有AM可以訪問所有賬戶持有人的信息，但在最近，對該政策做了改變。現(xiàn)在，分配給AM一個特定的客戶集，他們只需訪問只與這些客戶有關的信息。政策的變化必須反映在應用程序中，該應用程序現(xiàn)在向每個AM顯示所有客戶的信息，而不只是關于分配給AM的那些客戶的信息。 為了使應用程序符合新的隱私政策，銀行有三種選擇： 修改應用程序代碼，使所有SQL語句都包含一個判定詞（WHERE子句）。然而這種選擇不能保證在應用程序之外執(zhí)行隱私政策，而且假如將來政策又有變化，則必須再一次修改代碼，所以從長遠考慮這不是一個好方法。 保持應用程序不動，用一些必要的判定詞創(chuàng)建表的一些視圖，并用與表名一樣的名字為這些視圖創(chuàng)建同義詞。從應用程序不變更和安全性的角度來看這種方法比較好，但可能難于治理，因為有大量潛在的視圖需要跟蹤和治理。 創(chuàng)建可動態(tài)生成判定詞的政策函數(shù)來為每個AM創(chuàng)建一個VPD，通過利用內置的行級安全性（DBMS_RLS）來設置政策，這些函數(shù)隨后可以用于所有對象，而不必考慮它們如何被訪問。 最后一種選擇提供了最佳安全性，它不增加治理負擔，并能確保信息的安全隱私，這種方法就是所有賬戶經(jīng)理根據(jù)他們自己的證書，可查看表的不同視圖。 本文說明如何建立VPD安全性模型。我們將借助前面提到的銀行例子通過創(chuàng)建函數(shù)、制定政策、然后測試結果來描述整個建立過程。（請注重，為使例子簡單，沒有完整定義該表。） 示例應用的基本設置 下面簡單地給出示例銀行應用的基本假設： 一個BANK模式擁有兩個構成該應用的要害表--一個CUSTOMERS（客戶）表： 姓名 空？　 類型CUST_ID　非空　 數(shù)字CUST_NAME非空　 字符型變量2(20)　以及一個ACCOUNTS（賬戶）表： 姓名 空？　類型ACCT_NO　非空　數(shù)字CUST_ID　非空　數(shù)字余額數(shù)字(15,2)用于創(chuàng)建和填充這兩個基本示例表的SQL腳本。 用戶的SECMAN（安全性經(jīng)理）擁有一個Access_POLICY表，它識別AM以及他們各自客戶的賬戶： 姓名 空？　 類型AM_NAME　非空　 字符型變量2(20)CUST_ID　非空　 數(shù)字ACCESS_TYPE　非空　 字符(1)　AM_NAME字段存儲賬戶經(jīng)理的用戶ID；CUST_ID用于識別客戶；ACCESS_TYPE定義指定的訪問權限--S(SELECT--查詢)、I(INSERT--插入數(shù)據(jù))、D(DELETE--刪除數(shù)據(jù))以及U(UPDATE--更新數(shù)據(jù))。ACCESS_POLICY表中有這樣一些記錄： AM_NAME　 CUST_ID　 ACCESS_TYPE-------　 -------　-----------SCOTT123　 SSCOTT123　 ISCOTT123　 DSCOTT123　 USCOTT456　 SSCOTT789　 SLARA 456　 ILARA 456　 D LARA 456　 ULARA 456　 S　正如你所看到的，客戶123的AM SCOTT擁有所有權限--S、I、D和U--客戶456的AM LARA也具有這些權限。還有，由于SCOTT可以批準LARA的客戶456的賬戶結余，所以他擁有對客戶456的S權限。 第一步 創(chuàng)建政策函數(shù) 無論AM何時要查看客戶的賬戶信息，他都必須動態(tài)地應用銀行的訪問規(guī)則（包含在ACCESS_POLICY表中）。第一步是創(chuàng)建政策函數(shù)，用于返回要應用到表上的適當判定詞。和對ACCESS_POLICY表的處理一樣，出于安全考慮，政策函數(shù)也由用戶的SECMAN創(chuàng)建和控制。最好是使隱私規(guī)則與它們將要應用到的表分開。 讓我們仔細看一看政策函數(shù)get_sel_cust_id: 準確接收兩個參數(shù)：模式名稱（p_schema in varchar2）和表名（p_table in varchar2）。 只返回一個字符串值--return varchar2 as l_retstr varchar2(2000)，它包含將要添加到表的每個查詢中的判定詞。 使用一個游標例程--for cust_ rec in--來獲得值的列表，因為每個用戶可能有表中列出的幾個cust_id。 返回一個結構化的字符串l_retstr，無論用戶何時試圖訪問基本表都將它用做一個判定詞。 該函數(shù)返回判定詞where cust_id in，隨后是用戶(am_name = USER)能夠看到的客戶賬戶名單（由逗號分隔）。 請注重在進入構建用戶cust_id名單的循環(huán)之前，先檢查該用戶是否為表的所有者BANK，若是則返回NULL，如下所示： if (p_schema = user) then 1_retstr := null;　構建完該函數(shù)后，你需要通過測試一些示例數(shù)據(jù)來確保它返回相應的判定詞。以SECMAN身份連接數(shù)據(jù)庫，向ACCESS_POLICY表中插入一些記錄，授予SECMAN在幾個示例賬戶上的讀權限，如下所示： insert into access_policy values ('SECMAN',123,'S');insert into access_policy values ('SECMAN',456,'S');insert into access_policy values ('SECMAN',789,'S');　下面來執(zhí)行該函數(shù)： 　 　select get_sel_cust_id ('BANK','CUSTOMERS') from dual;　該函數(shù)返回一個將被用作判定詞的字符串，如下面的示例輸出所示： 　GET_SEL_CUST_ID('BANK','CUSTOMERS')------------------------CUST_ID IN (123,456,789)　你需要為其他類型的訪問創(chuàng)建類似的函數(shù)。為簡單起見，為所有其他訪問類型創(chuàng)建一個單一的函數(shù)--UPDATE, DELETE, INSERT。但是注重，對于現(xiàn)實世界中的應用，每種訪問類型應該有自己的單獨定義的函數(shù)，以確保相應的隱私。 政策函數(shù)基本上是一樣的，唯一的區(qū)別是通過使用ACCESS_CONTROL表中的信息進一步限定了判定詞： and access_type in ('I', 'U', 'D')創(chuàng)建政策函數(shù)僅僅是第一步。現(xiàn)在你需要通過定義在你的系統(tǒng)中控制該函數(shù)的使用政策來確保這個函數(shù)將被使用。 第二步 定義政策 政策是用Oracle提供的DBMS_RLS包定義的。要知道政策本身并不是任何用戶（schema）擁有的數(shù)據(jù)庫對象，它們是邏輯結構。擁有對DBMS_RLS包的執(zhí)行權限的用戶可以修改或刪除由其他用戶創(chuàng)建的政策。對DBMS_RLS的執(zhí)行權限應該受到嚴謹?shù)目刂啤?在下面的例子中，用戶SECMAN被（SYS）授予對DBMS_RLS包的執(zhí)行權限： grant execute on dbms_rls to secman;創(chuàng)建了一個關于模式BANK的CUSTOMERS表的政策，命名為CUST_SEL_POLIC。該政策將模式SECMAN擁有的函數(shù)GET_SEL_CUST_ID所返回的判定詞應用到對該表的所有SELECT操作語句。 同樣，對其他訪問類型該表應遵循不同的政策。該政策應用于對CUSTOMERS表的INSERT、UPDATE和DELETE操作語句。 該政策與SELECT政策幾乎一樣，但它包含如下一項檢查以確保即使執(zhí)行完UPDATE該政策仍然得到遵循： 　 　update_check => TRUE除非遵守該政策，否則數(shù)據(jù)不能被添加到該表中。