Oracle提供用於控制數據訪問規則的多種方式
包括
同意安全機制(比如系統
對象
作用的優先特權)
同意執行安全(比如定義和觸發特權)
虛擬私有數據庫(VPD)
N
tier的驗證(比如RADIUS的驗證服務器)
現在讓我們通過查看同意安全機制來開始一些最基本的知識
並了解安全機制的優點和缺欠
原始關系模型為用戶提供了用於訪問控制的同意特權的方法
這一模型最初是由E
F
Codd描述
並成為了多種商業關系數據庫交叉的標准
Oracle同意安全機制具有多種形式
對象同意
系統特權同意
以及基於功能的同意
這一形式的主要目的是使數據庫中的用戶可以批准訪問特定數據對象來控制數據訪問
Oracle安全機制 這是用於數據控制的Oracle設計的多章節的第二部分
如果你還沒有閱讀這一部分
可以先查看這一文章系列的第一部分《從開始就注意Oracle設計的安全性》
對象特權 對象特權分配執行一個特定對象的特定操作權利
這裡提供了對象特權分配的范例
同意選擇
在用戶插入fred
mary
joe
在定制列表中執行同意插入
同意所有的用戶執行fred
同意用戶查閱中對mary的選擇
你可以看到
對象特權的直接分配需要Oracle數據庫用戶的每一對象的特定同意
如果你有
個列表和
個用戶的數據庫
這就需要
獨立的同意聲明來分配安全機制
系統特權 系統特權包括很多訪問方式
比如任何列表的選擇
系統特權同意的范例包括以下
同意建立任何簇(cluster)用於customer_role
同意選擇任何列表用於fred
同意建立任何列表
同意建立tablespace用於dba_role
顯然
系統特權應該只限於安全級別不是很高的情況
因為一個簡單的同意聲明可以將列表上的所有安全機制去掉
基於功能的安全機制 功能安全機制可以允許你將相關的同意機制歸為一個集合
由於功能機制是一個定義好的特權集合
特權分配給用戶就會變得相當容易
比如以下范例
建立all_customer的功能安全機制
同意all_customer的選擇
更新
同意all_customer選擇item_table
功能安全機制的優點在於它的明顯性
這是因為功能安全機制允許你定義一套訪問規則
然後分配給合適的用戶
然而
與VPD安全機制不一樣
執行數據訪問的復雜規則是不可能的
同意安全機制的設計 如果你要執行Oracle數據庫的安全機制
你必須做一些仔細的前期計劃以確保每一功能都滿足不同用戶的訪問
而且功能上不沖突
設計同意安全機制的步驟如下
定義所有已經的不同類別的用戶的功能
定義每種功能的訪問規則
定義所有行
列的訪問限制
建立所有數據訪問的查看
分配功能的查看
分配用戶的功能
為了減少功能重復的可能性
很多Oracle設計者建立功能的等級性
如圖A所示
圖A 
用戶組訪問 可以注意到程序員和分析任務之間訪問特權的重復性
程序員必須非常地注意訪問的要點
在實際操作中
功能的設計可能會變得復雜
行和列訪問的設計 在實際設計中
同意訪問整個列表並不是很簡單
通常你需要在一個列表內限制特定行的訪問
唯一可實現的方法是建立每一行的限制獨立查看
然後將查看分配給用戶功能
例如
假設你是做基於下面商業規則的設計功能
只有管理者才能查看雇員的工資列(列限制)
其他雇員只能查看雇員名字和電話號碼(行限制)
為了能夠在Oracle中使用功能安全機制來執行這一設計
可以采用以下步驟
建立管理者和雇員的基本功能
建立合適的查看
同意功能的查看
在Oracle中
表A說明了這一設計
現在你可以分配合適的同意聲明
然後測試查看結果
並看看它們是怎麼工作(表B)
同意安全機制的漏洞 設計中同意安全機制產生漏洞有很多觀點
包括
分配同意給PUBLIC
使用WITH ADMIN選擇分配功能
重復
未設計的訪問功能
分配系統特權給功能
建立公共的同義字
例如
在Oracle中你可以明確將權利賦予公用的列表
這樣就可以具備只讀訪問
這種系統特權取代了功能安全機制
並生成了漏洞
如下所示
生成pubs
customer的公用同字義的用戶
同意用戶的公用選擇
另一個重要漏洞是列表的公用同義字
請記住
Oracle在缺省情況下是nobody
除非是對象允許執行列表的任何操作
同樣
列表名稱必須在SQL中定義
如表C所示
現在
當你與一個名為SCOTT的用戶連接
他是不能看到列表的行
如表D中的例子所示
在這種情況下
你知道列表是存在的
但Oracle只承認有權限的列表名稱(可參見表 E)
復雜性 從表面上看
設計Oracle數據庫的同意安全機制很復雜
本文中提到的觀點提供了建立Oracle安全機制的新方法
以及同意執行模型和VPD
在下面兩個章節裡
我將會檢查采用這些新方法的數據庫設計
From:http://tw.wingwit.com/Article/program/Oracle/201311/18544.html
