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