Oracle提供用于控制数据访问规则的多种方式包括
同意安全机制(比如系统对象作用的优先特权)
同意执行安全(比如定义和触发特权)
虚拟私有数据库(VPD)
Ntier的验证(比如RADIUS的验证服务器)
现在让我们通过查看同意安全机制来开始一些最基本的知识并了解安全机制的优点和缺欠原始关系模型为用户提供了用于访问控制的同意特权的方法这一模型最初是由EF 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中你可以明确将权利赋予公用的列表这样就可以具备只读访问这种系统特权取代了功能安全机制并生成了漏洞如下所示
生成pubscustomer的公用同字义的用户
同意用户的公用选择
另一个重要漏洞是列表的公用同义字请记住Oracle在缺省情况下是nobody除非是对象允许执行列表的任何操作同样列表名称必须在SQL中定义如表C所示
现在当你与一个名为SCOTT的用户连接他是不能看到列表的行如表D中的例子所示
在这种情况下你知道列表是存在的但Oracle只承认有权限的列表名称(可参见表 E)
复杂性
从表面上看设计Oracle数据库的同意安全机制很复杂本文中提到的观点提供了建立Oracle安全机制的新方法以及同意执行模型和VPD在下面两个章节里我将会检查采用这些新方法的数据库设计
