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