如何控制Oracle虛擬專用數(shù)據(jù)
導讀：安全問題威脅著各大數(shù)據(jù)庫系統(tǒng)，人們一直都在和安全問題抗爭，可一直沒有一個切實有效的方法來確保數(shù)據(jù)庫安全。隨著數(shù)據(jù)庫技術(shù)的應用越來越廣泛，使用數(shù)據(jù)庫的用戶數(shù)量的增多以及數(shù)據(jù)內(nèi)容的敏感程度的加強，數(shù)據(jù)庫的安全也變得更加重要。為了保證數(shù)據(jù)庫中的數(shù)據(jù)不受到非授權(quán)的查看和修改，必須控制用戶對數(shù)據(jù)的訪問。細粒度訪問控制也就是虛擬專用數(shù)據(jù)庫，它提供強大的行級安全功能。
細粒度訪問控制的工作方法是，通過透明地更改對數(shù)據(jù)的請求，基于一系列定義的標準向用戶提供表的局部視圖。在運行時，所有查詢都附加了謂詞，以便篩選出準許用戶看到的行。例如，如果只允許用戶查看帳戶管理員admin的帳戶，則細粒度訪問控制設(shè)置自動地將查詢：
select * from accounts;
where am_name = 'admin';
DBA在表ACCOUNTS上設(shè)置了一項安全策略。該策略具有一個相關(guān)函數(shù)，稱為policy function，它返回一個用作謂詞的字符串where am_name = 'admin'。
生成謂詞所需的重復分析是一種在某些情況下可以進行修整的開銷。例如，在大部分實際情況中，謂詞并不象 am_name = 'SCOTT' 那樣是靜態(tài)的;它基于用戶的身份、用戶的權(quán)限級別、用戶向哪個帳戶管理員進行報告等情況，可能更具有動態(tài)性。由策略函數(shù)創(chuàng)建并返回的字符串可能會具有很強的動態(tài)性，而為了保證其結(jié)果，Oracle必須每次重新執(zhí)行策略函數(shù)，既浪費資源又降低性能。在這種類型的策略中，謂詞每次執(zhí)行時可能會有很大的差別，該策略稱為“動態(tài)”策略，在Oracle9i數(shù)據(jù)庫以及以前的版本中已經(jīng)提供了這種策略。
除了保留動態(tài)策略之外，Oracle數(shù)據(jù)庫10g還基于謂詞的構(gòu)造推出了幾種新類型的策略，為提高性能提供了更好的控制：context_sensitive、shared_context_sensitive、shared_static和static。現(xiàn)在，讓我們來了解每種策略類型的意義以及如何在適當?shù)膱龊现惺褂盟鼈儭?/p>
為保持向后兼容性，10g中的默認策略類型為“dynamic” — 正如Oracle9i中一樣。在這種情況下，對于每行以及每位用戶，在每次訪問表時都對策略函數(shù)進行重新求值。讓我們來詳細分析策略謂詞：
where am_name = 'admin'
忽略掉where 子句，謂詞就具有兩個不同的部分：在等式操作符之前的部分(am_name)和等式操作符之后的部分 ('SCOTT')。在大多數(shù)情況下，后面的部分更象是變量，因為它是由用戶的數(shù)據(jù)提供的(如果用戶是 SCOTT，則其值為 'SCOTT')。在等號前面的部分是靜態(tài)的。因此，即使函數(shù)不必為生成適當?shù)闹^詞而對每行求出策略函數(shù)的值，由于了解前面部分的靜態(tài)性以及后面部分的動態(tài)性，也可以提高性能。在10g中，可以在dbms_rls.add_policy調(diào)用中使用 "context_sensitive" 類型的策略作為參數(shù)來實現(xiàn)這種方法：
policy_type => dbms_rls.context_sensitive
在另一個示例中，我們有一個稱為ACCOUNTS的表，它擁有幾列，其中一列是BALANCE，表示帳戶余額。假設(shè)允許某個用戶查看低于某特定余額的帳戶，而該余額由應用程序上下文所決定。我們并不在策略函數(shù)中將此余額值固定，而是3是根據(jù)應用程序上下文確定，如：
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'balance < sys_context(''vpdctx'', ''maxbal'')';
end;
應用程序上下文VPDCTX的屬性MAXBAL可以在會話的前期設(shè)定，而函數(shù)在運行時可以容易地獲得該數(shù)值。
請仔細注意該示例。謂詞有兩部分：小于號之前的部分和之后的部分。之前的部分是“balance”一詞，它是文字符。后面的部分從某種程度而言是靜態(tài)的，因為應用程序上下文變量在改變之前一直是常量。如果應用程序上下文屬性不變，則整個謂詞是常量，因此不需要重新執(zhí)行函數(shù)。如果策略類型定義為對上下文敏感，則Oracle數(shù)據(jù)庫10g可以識別此情況以用于優(yōu)化。如果在會話期間沒有發(fā)生會話上下文的變化，則不重新執(zhí)行該函數(shù)，從而顯著提高了性能。
有時業(yè)務(wù)操作可以確保謂詞更加靜態(tài)。例如，在上下文敏感的策略類型示例中，我們將用戶所見的最大余額定義為一個變量。當Web應用程序中的Oracle userid 由許多Web用戶共享，并且應用程序基于這些用戶的權(quán)限來設(shè)置該變量(應用程序上下文)時，這種方法很有用。因此，Web用戶TAO和KARTHIK都是以用戶APPUSER連接到數(shù)據(jù)庫的，二者可以在其會話中擁有兩個不同的應用程序上下文的值。此時MAXBAL的值并不依賴于Oracle userid，而是依賴TAO和KARTHIK各自的會話。
在靜態(tài)策略的情況下，謂詞更具有可預測性，其說明如下。
LORA和MICHELLE分別是Acme Bearings和Goldtone Bearings的帳戶管理員。當他們連接數(shù)據(jù)庫時，他們使用自己的id，并且只應該看到屬于他們的那些行。在Lora方面，謂詞變成where CUST_NAME = 'ACME';而對于Michelle，則是where CUST_NAME = 'GOLDTONE'。在這里，謂詞依賴于他們的 userid，因此他們所創(chuàng)建的任何會話在應用程序上下文中始終具有相同的值。
10g可以利用這種情況，在SGA中對謂詞進行高速緩存，并在會話中重用該謂詞，而不必重新執(zhí)行策略函數(shù)。策略函數(shù)類似于以下形式：
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'cust_name = sys_context(''vpdctx'', ''cust_name'')';
end;
而策略定義為：
policy_type => dbms_rls.static
這種方法確保策略函數(shù)只執(zhí)行一次。即使應用程序上下文在會話中改變，也從不重新執(zhí)行該函數(shù)，使得此過程的速度非常快。
建議將靜態(tài)策略用于在幾個用戶中托管應用程序的情況。在這種情況下，單個數(shù)據(jù)庫擁有幾個用戶的數(shù)據(jù)。當每個用戶登錄時，登錄后觸發(fā)器可以設(shè)置用于策略函數(shù)的應用程序上下文的值，以便快速生成謂詞。
但是，將策略定義為靜態(tài)也是一把雙刃劍。在以上的示例中，我們假設(shè)應用程序上下文屬性VPDCTX.CUST_NAME 的值在會話中不改變。如果這種假設(shè)不正確，將會怎樣呢?如果該值改變，策略函數(shù)將不會執(zhí)行，因此在謂詞中將不會使用新值，而返回錯誤的結(jié)果!因此，在將策略定義為靜態(tài)時要非常小心;您必須絕對確信該值不會改變。如果您不能作這種假設(shè)，則最好將策略定義為對上下文敏感。
【編輯推薦】
