Oracle中构建基于VPD特性的安全数据库

核心提示： 为了使应用程序符合新的隐私政策，银行有三种选择：修改应用程序代码，Oracle中构建基于VPD特性的安全数据库(2)，使所有SQL语句都包含一个判定词（WHERE子句），然而这种选择不能保证在应用程序之外执行隐私政策，没有完整定义该表，）示例应用的基本设置下面简单地给出示例银行应用的基本假

为了使应用程序符合新的隐私政策，银行有三种选择：

修改应用程序代码，使所有SQL语句都包含一个判定词（WHERE子句）。然而这种选择不能保证在应用程序之外执行隐私政策，而且如果将来政策又有变化，则必须再一次修改代码，所以从长远考虑这不是一个好方法。

保持应用程序不动，用一些必要的判定词创建表的一些视图，并用与表名一样的名字为这些视图创建同义词。从应用程序不变更和安全性的角度来看这种方法比较好，但可能难于管理，因为有大量潜在的视图需要跟踪和管理。

创建可动态生成判定词的政策函数来为每个AM创建一个VPD，通过利用内置的行级安全性（DBMS_RLS）来设置政策，这些函数随后可以用于所有对象，而不必考虑它们如何被访问。

最后一种选择提供了最佳安全性，它不增加管理负担，并能确保信息的安全隐私，这种方法就是所有账户经理根据他们自己的证书，可查看表的不同视图。

本文说明如何建立VPD安全性模型。我们将借助前面提到的银行例子通过创建函数、制定政策、然后测试结果来描述整个建立过程。（请注意，为使例子简单，没有完整定义该表。）

示例应用的基本设置

下面简单地给出示例银行应用的基本假设：

一个BANK模式拥有两个构成该应用的关键表--一个CUSTOMERS（客户）表：姓名　　　　 空？　　　 类型
CUST_ID　　　非空　　　 数字
CUST_NAME　　非空　　　 字符型变量2(20)

以及一个ACCOUNTS（账户）表：姓名　　　　 空？　　　类型
ACCT_NO　　　非空　　　数字
CUST_ID　　　非空　　　数字余额数字(15,2)

用于创建和填充这两个基本示例表的SQL脚本。

用户的SECMAN（安全性经理）拥有一个ACCESS_POLICY表，它识别AM以及他们各自客户的账户：姓名　　　　 空？　　　 类型
AM_NAME　　　非空　　　 字符型变量2(20)
CUST_ID　　　非空　　　 数字
ACCESS_TYPE　非空　　　 字符(1)