五種型別的策略、列相關策略以及列遮蔽使得 VPD 成為 DBA 的安全工具箱中一種功能更加強大的工具

虛擬專用資料庫 (VPD) 也稱為細粒度訪問控制，它提供強大的行級安全功能。它是在 Oracle8i 中推出的，已經受到廣泛的歡迎，並且在從教育軟體到金融服務等各種應用程式得到採用。

VPD 的工作方法是，透過透明地更改對資料的請求，基於一系列定義的標準向使用者提供表的區域性檢視。在執行時，所有查詢都附加了謂詞，以便篩選出准許使用者看到的行。例如，如果只允許使用者檢視帳戶管理員 SCOTT 的帳戶，則 VPD 設定自動地將查詢：

select * from accounts;

重寫為：

select * from accounts
where am_name = 'SCOTT';

DBA 在表 ACCOUNTS 上設定了一項安全策略。該策略具有一個相關函式，稱為policy function，它返回一個用作謂詞的字串 where am_name = 'SCOTT'。如果您不熟悉該特性的全部功能，我建議您閱讀 Oracle 雜誌的文章“利用 VPD 保持資訊的私密性”。

策略型別

生成謂詞所需的重複分析是一種在某些情況下可以進行修整的開銷。例如，在大部分實際情況中，謂詞並不象 am_name = 'SCOTT' 那樣是靜態的；它基於使用者的身份、使用者的許可權級別、使用者向哪個帳戶管理員進行報告等情況,可能更具有動態性。由策略函式建立並返回的字串可能會具有很強的動態性，而為了保證其結果，Oracle 必須每次重新執行策略函式，既浪費資源又降低效能。在這種型別的策略中，謂詞每次執行時可能會有很大的差別，該策略稱為“動態”策略，在 Oracle9i 資料庫以及以前的版本中已經提供了這種策略。

除了保留動態策略之外，Oracle 資料庫 10g 還基於謂詞的構造推出了幾種新型別的策略，為提高效能提供了更好的控制：context_sensitive、shared_context_sensitive、shared_static 和 static。現在，讓我們來了解每種策略型別的意義以及如何在適當的場合中使用它們。

動態策略。為保持向後相容性，10g 中的預設策略型別為“dynamic” — 正如 Oracle9i 中一樣。在這種情況下，對於每行以及每位使用者，在每次訪問表時都對策略函式進行重新求值。讓我們來詳細分析策略謂詞：

where am_name = 'SCOTT'

忽略掉 where 子句，謂詞就具有兩個不同的部分：在等式運算子之前的部分 (am_name) 和等式運算子之後的部分 ('SCOTT')。在大多數情況下，後面的部分更象是變數，因為它是由使用者的資料提供的（如果使用者是 SCOTT，則其值為 'SCOTT'）。在等號前面的部分是靜態的。因此，即使函式不必為生成適當的謂詞而對每行求出策略函式的值，由於瞭解前面部分的靜態性以及後面部分的動態性，也可以提高效能。在 10g 中，可以在 dbms_rls.add_policy 呼叫中使用 "context_sensitive" 型別的策略作為引數來實現這種方法：

policy_type => dbms_rls.context_sensitive

在另一個示例中，我們有一個稱為 ACCOUNTS 的表，它擁有幾列，其中一列是 BALANCE，表示帳戶餘額。假設允許某個使用者檢視低於某特定餘額的帳戶，而該餘額由應用程式上下文所決定。我們並不在策略函式中將此餘額值固定，而是3是根據應用程式上下文確定，如：

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 可以在會話的前期設定，而函式在執行時可以容易地獲得該數值。

請仔細注意該示例。謂詞有兩部分：小於號之前的部分和之後的部分。之前的部分是“balance”一詞，它是文字元。後面的部分從某種程度而言是靜態的，因為應用程式上下文變數在改變之前一直是常量。如果應用程式上下文屬性不變，則整個謂詞是常量，因此不需要重新執行函式。如果策略型別定義為對上下文敏感，則 Oracle 資料庫 10g 可以識別此情況以用於最佳化。如果在會話期間沒有發生會話上下文的變化，則不重新執行該函式，從而顯著提高了效能。

靜態策略。有時業務操作可以確保謂詞更加靜態。例如，在上下文敏感的策略型別示例中，我們將使用者所見的最大餘額定義為一個變數。當 web 應用程式中的 Oracle userid 由許多 web 使用者共享，並且應用程式基於這些使用者的許可權來設定該變數（應用程式上下文）時，這種方法很有用。因此，web 使用者 TAO 和 KARTHIK 都是以使用者 APPUSER 連線到資料庫的，二者可以在其會話中擁有兩個不同的應用程式上下文的值。此時 MAXBAL 的值並不依賴於 Oracle userid，而是依賴 TAO 和 KARTHIK 各自的會話。

在靜態策略的情況下，謂詞更具有可預測性，其說明如下。

LORA 和 MICHELLE 分別是 Acme Bearings 和 Goldtone Bearings 的帳戶管理員。當他們連線資料庫時，他們使用自己的 id，並且只應該看到屬於他們的那些行。在 Lora 方面，謂詞變成 where CUST_NAME = 'ACME'；而對於 Michelle，則是 where CUST_NAME = 'GOLDTONE'。在這裡，謂詞依賴於他們的 userid，因此他們所建立的任何會話在應用程式上下文中始終具有相同的值。

10g 可以利用這種情況，在 SGA 中對謂詞進行快取記憶體，並在會話中重用該謂詞，而不必重新執行策略函式。策略函式類似於以下形式：

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

這種方法確保策略函式只執行一次。即使應用程式上下文在會話中改變，也從不重新執行該函式，使得此過程的速度非常快。

建議將靜態策略用於在幾個使用者中託管應用程式的情況。在這種情況下，單個資料庫擁有幾個使用者的資料。當每個使用者登入時，登入後觸發器可以設定用於策略函式的應用程式上下文的值，以便快速生成謂詞。

但是，將策略定義為靜態也是一把雙刃劍。在以上的示例中，我們假設應用程式上下文屬性 VPDCTX.CUST_NAME 的值在會話中不改變。如果這種假設不正確，將會怎樣呢？如果該值改變，策略函式將不會執行，因此在謂詞中將不會使用新值，而返回錯誤的結果！因此，在將策略定義為靜態時要非常小心；您必須絕對確信該值不會改變。如果您不能作這種假設，則最好將策略定義為對上下文敏感。

共享策略型別。為了重用程式碼並最大限度地利用已經分析過的程式碼，您可以決定為幾個表使用通用的策略函式。例如，在上述示例中，我們可能對於不同型別的帳戶擁有不同的表 — SAVINGS 和 CHECKING — 但是規則仍然是相同的：限制使用者檢視餘額超過其授權範圍的帳戶。這種情況要求為 CHECKING 和 SAVINGS 表上的策略使用統一的函式。該策略建立為 context_sensitive。

假設事件按如下順序發生：

1. 連線會話
2. 設定應用程式上下文
3. select * from savings;
4. select * from checking;

即使應用程式上下文在第 3 步與第 4 步之間沒有改變，策略函式也會重新執行，因為現在所選擇的表已經不同。這不是我們所希望的情況，因為策略函式相同，不需要重新執行該函式。

10g 中的新功能是能夠在物件間共享策略。在上述示例中，您可以將這些策略的策略型別定義為：

policy_type => dbms_rls.shared_context_sensitive

將策略宣告為 "shared" 可以在以上所示的情況中不再執行該函式，從而提高了效能。

選擇性的列

現在設想一種情況，只有在選擇了特定列時才會應用 VPD 策略。在上述示例的表 ACCOUNTS 中，各行如下所示：

ACCTNO ACCT_NAME    BALANCE
------ ------------ -------
1 BILL CAMP    1000
2 TOM CONNOPHY 2000
3 ISRAEL D     1500

不允許 Michelle 檢視餘額超過 1600 的帳戶。當她執行類似以下的查詢時：

select * from accounts;

她將看到：

ACCTNO ACCT_NAME    BALANCE
------ ------------ -------
1 BILL CAMP    1000
3 ISRAEL D     1500

acctno 2 的餘額超過 1600，它已禁止顯示。對於 Michelle 而言，表中只有兩行，而不是三行。當她執行類似以下的查詢時：

select count(*) from accounts;

該查詢只計算表中的記錄數，輸出是二，而不是三。

但是，此時我們可以決定將安全策略稍微放鬆一些。在本查詢中，Michelle 不能檢視帳戶餘額等秘密資料；她只是計算表中所有記錄的數目。在與安全策略一致的情況下，我們可以允許此查詢計算所有記錄的數目，無論是否允許她檢視這些記錄。如果需要這樣，則在對 10g 的 dbms_rls.add_policy 的呼叫中的另一個引數允許實現此功能：

sec_relevant_cols => 'BALANCE'

現在，當使用者選擇列 BALANCE 時，無論是顯式選擇還是隱含在 select * 中，VPD 策略都會介入，對行作出限制。否則將會選擇表中所有的行，因為在查詢中使用者只選擇了總計行數，而沒有選擇列 BALANCE。如果將以上引數設定為所示的形式，則查詢

select count(*) from accounts;

將顯示三列，而不是兩列。但是查詢：

select * from accounts;

仍將只返回兩條記錄，與預期的情況相同。

列遮蔽

現在，讓我們對當前的示例再增加些要求。我們不禁止顯示那些餘額高於閾值的行，而是希望顯示所有的行，同時遮蔽那些數值超過閾值的餘額列。與安全性相關的列仍然是 BALANCE。

不允許 Michelle 看到餘額超過 1600 的帳戶。當她執行類似以下的查詢時：

select * from accounts;

她將只看到兩行，acctnos 1 和 3。但是，我們可能希望她看到：

ACCTNO ACCT_NAME    BALANCE
------ ------------ -------
1 BILL CAMP    1000
2 TOM CONNOPHY 
3 ISRAEL D     1500

注意，顯示都所有行，但是 acctno 2 的列 BALANCE 的值顯示為空（顯示為），它的餘額實際上是 2000，超過閾值 1600。這種方法稱為“列遮蔽”，可以透過在對 dbms_rls.add_policy 的呼叫中指定引數來實現：

sec_relevant_cols_opt =>  dbms_rls.all_rows

在只有某些特定列值很重要的情況下，這種策略才可能非常有用，並且不需要複雜的自定義程式碼。它也是一種很好的變通方法，不需要對儲存資料進行加密。

結論

在 Oracle 資料庫 10g 中，VPD 已經發展為一種功能非常強大的特性，它能夠支援多種需求，例如基於策略有選擇性地遮蔽列，只在訪問特定列時應用策略等。利用應用程式特有的性質，還可以透過多種型別的策略來提高策略的效能，使得該特性適用於多種情況。

有關 VPD 和 dbms_rls 程式包的更多資訊，請參閱 PL/SQL 程式包和型別參考的第 79 章以及。您還可以閱讀由我與 Don Burleson 合著的一本關於該主題的書籍 Oracle 保密安全性審計 (Rampant TechPress)。

摘錄自

Oracle安全 - 虛擬專用資料庫 VPD

相關文章