自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Oracle細粒度訪問控制的實例演示

數(shù)據(jù)庫 Oracle
以下的文章主要是對Oracle細粒度訪問控制的相關(guān)工作方式的具體描述,以下文章就是如何對Oracle細粒度訪問控制進行操作的具體描述。

Oracle細粒度訪問控制也就是虛擬專用數(shù)據(jù)庫 (VPD) ,它提供強大的行級安全功能。它是在 Oracle8i 中推出的,已經(jīng)受到廣泛的歡迎,并且在從教育軟件到金融服務(wù)等各種應(yīng)用程序得到采用。

VPD 的工作方法是,通過透明地更改對數(shù)據(jù)的請求,基于一系列定義的標準向用戶提供表的局部視圖。在運行時,所有查詢都附加了謂詞,以便篩選出準許用戶看到的行。例如,如果只允許用戶查看帳戶管理員 SCOTT 的帳戶,則 VPD 設(shè)置自動地將查詢:

 

  1. select * from accounts;  

 

重寫為:

 

 

  1. select * from accounts  
  2. where am_name = 'SCOTT';   

 

 

DBA 在表 ACCOUNTS 上設(shè)置了一項安全策略。該策略具有一個相關(guān)函數(shù),稱為policy function,它返回一個用作謂詞的字符串 where am_name = 'SCOTT'。如果您不熟悉該特性的全部功能,我建議您閱讀 Oracle 雜志的文章“利用 VPD 保持信息的私密性”。

生成謂詞所需的重復(fù)分析是一種在某些情況下可以進行修整的開銷。例如,在大部分實際情況中,謂詞并不象 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?,F(xiàn)在,讓我們來了解每種策略類型的意義以及如何在適當?shù)膱龊现惺褂盟鼈儭?/p>

動態(tài)策略。 為保持向后兼容性,10g 中的默認策略類型為“dynamic” — 正如 Oracle9i 中一樣。在這種情況下,對于每行以及每位用戶,在每次訪問表時都對策略函數(shù)進行重新求值。讓我們來詳細分析策略謂詞:

 

  1. where am_name = 'SCOTT' 

 

忽略掉 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)這種方法:

 

  1. policy_type => dbms_rls.context_sensitive 

 

在另一個示例中,我們有一個稱為 ACCOUNTS 的表,它擁有幾列,其中一列是 BALANCE,表示帳戶余額。假設(shè)允許某個用戶查看低于某特定余額的帳戶,而該余額由應(yīng)用程序上下文所決定。我們并不在策略函數(shù)中將此余額值固定,而是3是根據(jù)應(yīng)用程序上下文確定,如:

 

  1. create or replace vpd_pol_func  
  2. (  
  3. p_schema in varchar2,  
  4. p_table in varchar2  
  5. )   
  6. return varchar2  
  7. is  
  8. begin  
  9. return 'balance < sys_context(''vpdctx'', ''maxbal'')';   
  10. end; 

 

 

應(yīng)用程序上下文 VPDCTX 的屬性 MAXBAL 可以在會話的前期設(shè)定,而函數(shù)在運行時可以容易地獲得該數(shù)值。

請仔細注意該示例。謂詞有兩部分:小于號之前的部分和之后的部分。之前的部分是“balance”一詞,它是文字符。后面的部分從某種程度而言是靜態(tài)的,因為應(yīng)用程序上下文變量在改變之前一直是常量。如果應(yīng)用程序上下文屬性不變,則整個謂詞是常量,因此不需要重新執(zhí)行函數(shù)。

如果策略類型定義為對上下文敏感,則 Oracle 細粒度10g 可以識別此情況以用于優(yōu)化。如果在會話期間沒有發(fā)生會話上下文的變化,則不重新執(zhí)行該函數(shù),從而顯著提高了性能。

靜態(tài)策略。 有時業(yè)務(wù)操作可以確保謂詞更加靜態(tài)。例如,在上下文敏感的策略類型示例中,我們將用戶所見的最大余額定義為一個變量。當 web 應(yīng)用程序中的 Oracle userid 由許多 web 用戶共享,并且應(yīng)用程序基于這些用戶的權(quán)限來設(shè)置該變量(應(yīng)用程序上下文)時,這種方法很有用。

因此,web 用戶 TAO 和 KARTHIK 都是以用戶 APPUSER 連接到數(shù)據(jù)庫的,二者可以在其會話中擁有兩個不同的應(yīng)用程序上下文的值。此時 MAXBAL 的值并不依賴于 Oracle userid,而是依賴 TAO 和 KARTHIK 各自的會話。

在靜態(tài)策略的情況下,謂詞更具有可預(yù)測性,其說明如下。

LORA 和 MICHELLE 分別是 Acme Bearings 和 Goldtone Bearings 的帳戶管理員。當他們連接數(shù)據(jù)庫時,他們使用自己的 id,并且只應(yīng)該看到屬于他們的那些行。在 Lora 方面,謂詞變成 where CUST_NAME = 'ACME';而對于 Michelle,則是 where CUST_NAME = 'GOLDTONE'。

在這里,謂詞依賴于他們的 userid,因此他們所創(chuàng)建的任何會話在應(yīng)用程序上下文中始終具有相同的值。

10g 可以利用這種情況,在 SGA 中對謂詞進行高速緩存,并在會話中重用該謂詞,而不必重新執(zhí)行策略函數(shù)。策略函數(shù)類似于以下形式:

 

  1. create or replace vpd_pol_func  
  2. (  
  3. p_schema in varchar2,  
  4. p_table in varchar2  
  5. )   
  6. return varchar2  
  7. is  
  8. begin  
  9. return 'cust_name = sys_context(''vpdctx'', ''cust_name'')';   
  10. end;  

 

 

而策略定義為: 

 

 

  1. policy_type => dbms_rls.static 

 

這種方法確保策略函數(shù)只執(zhí)行一次。即使應(yīng)用程序上下文在會話中改變,也從不重新執(zhí)行該函數(shù),使得此過程的速度非常快。

 

建議將靜態(tài)策略用于在幾個用戶中托管應(yīng)用程序的情況。在這種情況下,單個數(shù)據(jù)庫擁有幾個用戶的數(shù)據(jù)。當每個用戶登錄時,登錄后觸發(fā)器可以設(shè)置用于策略函數(shù)的應(yīng)用程序上下文的值,以便快速生成謂詞。

但是,將策略定義為靜態(tài)也是一把雙刃劍。在以上的示例中,我們假設(shè)應(yīng)用程序上下文屬性 VPDCTX.CUST_NAME 的值在會話中不改變。如果這種假設(shè)不正確,將會怎樣呢?如果該值改變,策略函數(shù)將不會執(zhí)行,因此在謂詞中將不會使用新值,而返回錯誤的結(jié)果!因此,在將策略定義為靜態(tài)時要非常小心;您必須絕對確信該值不會改變。

如果您不能作這種假設(shè),則最好將策略定義為對上下文敏感。

共享策略類型。 為了重用代碼并最大限度地利用已經(jīng)分析過的代碼,您可以決定為幾個表使用通用的策略函數(shù)。例如,在上述示例中,我們可能對于不同類型的帳戶擁有不同的表 — SAVINGS 和 CHECKING — 但是規(guī)則仍然是相同的:限制用戶查看余額超過其授權(quán)范圍的帳戶。

這種情況要求為 CHECKING 和 SAVINGS 表上的策略使用統(tǒng)一的函數(shù)。該策略創(chuàng)建為 context_sensitive。

假設(shè)事件按如下順序發(fā)生:

1. 連接會話

2. 設(shè)置應(yīng)用程序上下文

 

3. select * from savings;

 

4. select * from checking;

 

即使應(yīng)用程序上下文在第 3 步與第 4 步之間沒有改變,策略函數(shù)也會重新執(zhí)行,因為現(xiàn)在所選擇的表已經(jīng)不同。這不是我們所希望的情況,因為策略函數(shù)相同,不需要重新執(zhí)行該函數(shù)。

 

10g 中的新功能是能夠在對象間共享策略。在上述示例中,您可以將這些策略的策略類型定義為:

 

  1. policy_type => dbms_rls.shared_context_sensitive 

 

將策略聲明為 "shared" 可以在以上所示的情況中不再執(zhí)行該函數(shù),從而提高了性能。

 

上述的相關(guān)內(nèi)容就是對Oracle細粒度訪問控制的工作方式的詳細介紹,希望你會在Oracle細粒度訪問控制的相關(guān)學(xué)習(xí)中有所收獲。

2007-11-14 來自:xuejinyoulan [收藏到我的網(wǎng)摘]

【編輯推薦】

  1. Oracle 10g數(shù)據(jù)庫的相關(guān)內(nèi)容描述
  2. Oracle移植到mysql中應(yīng)注意的事項
  3. 探討Oracle中rownum的用法
  4. 聯(lián)機備份Oracle數(shù)據(jù)實施是什么?
  5. 不可不知的Oracle查看鎖表進程
責(zé)任編輯:佚名 來源: csdn
相關(guān)推薦

2024-06-27 08:00:00

存儲數(shù)據(jù)庫細粒度

2010-04-14 11:04:53

Oracle細粒度

2010-04-16 16:39:25

Oracle細粒度

2010-04-22 13:39:31

Oracle細粒度訪問

2009-04-16 17:59:25

細粒度權(quán)限

2009-10-27 09:31:24

Windows Ser口令策略

2024-04-26 12:13:45

NameNodeHDFS核心

2010-10-20 15:09:05

2018-02-25 04:05:16

2010-12-30 14:34:43

云計算供應(yīng)商

2018-02-07 14:53:42

2022-06-27 17:58:42

pwrueBPF工具

2025-02-18 09:10:00

2009-03-31 11:20:10

2010-04-20 08:53:42

Oracle左連接

2022-11-07 12:15:13

開源深度學(xué)習(xí)

2025-03-04 04:00:00

擴散模型DDPM

2015-03-03 14:00:12

SQL ServerDBA數(shù)據(jù)恢復(fù)

2025-03-12 03:00:00

Finer-CAM醫(yī)學(xué)影像深度學(xué)習(xí)
點贊
收藏

51CTO技術(shù)棧公眾號