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