利用Oracle的同意安全机制来控制访问

　　Oracle提供用于控制数据访问规则的多种方式，包括：
　　
　　同意安全机制(比如系统、对象、作用的优先特权)
　　
　　同意执行安全(比如定义和触发特权)
　　
　　虚拟私有数据库(VPD)
　　
　　N-tier的验证(比如RADIUS的验证服务器)
　　
　　现在让我们通过查看同意安全机制来开始一些最基本的知识，并了解安全机制的优点和缺欠。原始关系模型为用户提供了用于访问控制的同意特权的方法。这一模型最初是由E.F. Codd描述，并成为了多种商业关系数据库交叉的标准。
　　
　　Oracle同意安全机制具有多种形式：对象同意，系统特权同意，以及基于功能的同意。这一形式的主要目的是使数据库中的用户可以批准访问特定数据对象来控制数据访问。
　　--------------------------------------------------------------------------------
　　Oracle安全机制
　　这是用于数据控制的Oracle设计的多章节的第二部分。假如你还没有阅读这一部分，可以先查看这一文章系列的第一部分《从开始就注重Oracle设计的安全性》
　　--------------------------------------------------------------------------------
　　对象特权
　　对象特权分配执行一个特定对象的特定操作权利。这里提供了对象特权分配的范例：
　　
　　同意选择，在用户插入fred, mary, joe；
　　
　　在定制列表中执行同意插入；
　　
　　同意所有的用户执行fred；
　　
　　同意用户查阅中对mary的选择；
　　
　　你可以看到，对象特权的直接分配需要Oracle数据库用户的每一对象的特定同意。假如你有100个列表和1，000个用户的数据库，这就需要100，000独立的同意声明来分配安全机制。
　　
　　系统特权
　　系统特权包括很多访问方式，比如任何列表的选择。系统特权同意的范例包括以下：
　　
　　同意建立任何簇(cluster)用于customer_role；
　　
　　同意选择任何列表用于fred；
　　
　　同意建立任何列表；
　　
　　同意建立tablespace用于dba_role。
　　
　　显然，系统特权应该只限于安全级别不是很高的情况，因为一个简单的同意声明可以将列表上的所有安全机制去掉。
　　
　　基于功能的安全机制
　　功能安全机制可以答应你将相关的同意机制归为一个集合。由于功能机制是一个定义好的特权集合，特权分配给用户就会变得相当轻易，比如以下范例：
　　
　　建立all_customer的功能安全机制；
　　
　　同意all_customer的选择，更新；
　　
　　同意all_customer选择item_table；
　　
　　功能安全机制的优点在于它的明显性，这是因为功能安全机制答应你定义一套访问规则，然后分配给合适的用户。
　　
　　然而，与VPD安全机制不一样，执行数据访问的复杂规则是不可能的。
　　
　　同意安全机制的设计
　　假如你要执行Oracle数据库的安全机制，你必须做一些仔细的前期计划以确保每一功能都满足不同用户的访问，而且功能上不冲突。设计同意安全机制的步骤如下：
　　
　　1.　　　定义所有已经的不同类别的用户的功能。
　　
　　2.　　　定义每种功能的访问规则。
　　
　　3.　　　定义所有行、列的访问限制。
　　
　　4.　　　建立所有数据访问的查看。
　　
　　5.　　　分配功能的查看。
　　
　　6.　　　分配用户的功能。
　　
　　为了减少功能重复的可能性，很多Oracle设计者建立功能的等级性，如图A所示。
　　
　　图A
　　利用Oracle的同意安全机制来控制访问

　　用户组访问
　　可以注重到程序员和分析任务之间访问特权的重复性。程序员必须非常地注重访问的要点。
　　
　　在实际操作中，功能的设计可能会变得复杂。
　　
　　行和列访问的设计
　　在实际设计中，同意访问整个列表并不是很简单，通常你需要在一个列表内限制特定行的访问。唯一可实现的方法是建立每一行的限制独立查看，然后将查看分配给用户功能。例如，假设你是做基于下面商业规则的设计功能：
　　
　　只有治理者才能查看雇员的工资列(列限制)。
　　
　　其他雇员只能查看雇员名字和电话号码(行限制)。
　　为了能够在Oracle中使用功能安全机制来执行这一设计，可以采用以下步骤：
　　
　　建立治理者和雇员的基本功能。
　　
　　建立合适的查看。
　　
　　同意功能的查看。
　　
　　在Oracle中，表A说明了这一设计。

　　
　　现在你可以分配合适的同意声明，然后测试查看结果，并看看它们是怎么工作(表B)。
　　
　　同意安全机制的漏洞
　　设计中同意安全机制产生漏洞有很多观点。包括：
　　
　　分配同意给PUBLIC。
　　
　　使用WITH ADMIN选择分配功能。
　　
　　重复、未设计的访问功能。
　　
　　分配系统特权给功能。
　　
　　建立公共的同义字。
　　
　　例如，在Oracle中你可以明确将权利赋予公用的列表，这样就可以具备只读访问。这种系统特权取代了功能安全机制，并生成了漏洞，如下所示：
　　
　　生成pubs.customer的公用同字义的用户；
　　
　　同意用户的公用选择；
　　
　　另一个重要漏洞是列表的公用同义字。请记住，Oracle在缺省情况下是nobody，除非是对象答应执行列表的任何操作。同样，列表名称必须在SQL中定义，如表C所示。
　　
　　现在，当你与一个名为SCOTT的用户连接，他是不能看到列表的行，如表D中的例子所示。
　　
　　在这种情况下，你知道列表是存在的，但Oracle只承认有权限的列表名称(可参见表 E)。
　　
　　复杂性
　　从表面上看，设计Oracle数据库的同意安全机制很复杂。本文中提到的观点提供了建立Oracle安全机制的新方法，以及同意执行模型和VPD。在下面两个章节里，我将会检查采用这些新方法的数据库设计。