[精]Oracle VPD详解(虚拟专用数据库)
2016-09-19 17:14
260 查看
所谓虚拟专用数据库(VPD)指的是,通过在数据库里进行配置,从而让不同的用户只能查看某个表里的部分数据。VPD分为以下两个级别。 行级别:在该级别下,可以控制某些用户只能查看到某些数据行。比如,对于销售数据表sales来说,每个销售人员只能检索出他自己的销售数据,不能查询其他销售人员的销售数据。
列级别:在该级别下,可以控制某些用户不能检索某个表的某个列的值。比如用户HR下的employees表中,含有工资(salary)列,由于该列比较敏感,因此不让其他用户查询该列的值。其他用户检索该列时,会发现其值全都为空(null)。
当Oracle在执行该语句时,如果发现sales_list表上存在FGAC政策,于是就会根据FGAC政策,按照如下方式改写该SQL语句:
对用户来说,这个添加where条件的过程是完全透明的,用户并不知道Oracle已经改写了他发出的SQL语句,从而过滤了查询结果。当然,如果该销售人员发出的语句为:
那么,当Oracle在改写该SQL语句时,则会改写为如下形式:
使用FGAC政策来限定返回记录的方式具有许多优点。比如,不需要改写应用程序、对用户完全透明、集中设置、便于管理等。 在使用FGAC时,会涉及应用程序上下文(ApplicationContext)的概念,使用应用程序上下文可以简化FGAC的实现。应用程序上下文是一个数据库对象,可以把它理解为数据库里的每个session的全局环境变量。一旦用户登录到数据库,从而创建出session以后,应用程序上下文就在整个session的生命周期里可用。在应用程序上下文里可以定义多个属性,并为这些属性设置具体的值。而用户不能直接修改属性的值,只能通过程序包来修改属性值。应用程序上下文总是由用户sys拥有。
比如,对于前面sales_list表的例子来说。我们可以创建一个应用程序上下文,当用户登录时,将该用户的ID号作为一个属性值放入该应用程序上下文中。然后在定义FGAC政策的时候,将该用户ID号取出,并作为限定条件短语(也就是where条件语句)返回给Oracle,从而实现FGAC。
在Oracle数据库里,已经为每个session都预先建立了一个应用程序上下文:userenv。一旦建立了session,该session就可以使用这个应用程序上下文。在userenv中已经预先定义了一些属性,比如ip_address、session_user和db_name等。在获取应用程序上下文里的属性值时,我们使用sys_context函数。该函数包含两个参数,第一个参数表示应用程序上下文的名称,第二个参数表示要显示的属性名称。如下所示:
我们也可以创建自己的应用程序上下文,如下所示:
在这里,sales_ctx是应用程序上下文的名称,而sales_app_pkg则是用来设置sales_ctx里属性的程序包。在创建应用程序上下文时,指定的、用来设置其中属性的程序包可以不必事先存在。但是在为应用程序上下文里设定属性值时,该程序包必须存在,否则报错。如果要删除应用程序上下文,则使用下面的命令:
创建了应用程序上下文以后,我们就可以在其中设置属性了。在设置具体的应用程序上下文属性时,必须使用Oracle提供的程序包dbms_session.set_context来设置其属性。其使用格式为:
我们只能在程序包里使用dbms_session.set_context,而不能直接在SQL*Plus里调用。如下所示:
我们创建oe.sales_app_pkg包,如下所示:
把执行oe.sales_app_pkg程序包的权限赋给所有用户以后,我们可以测试应用程序上下文是否生效了。
可以看到,应用程序上下文生效了。接下来,我们创建用于FGAC规则的函数。
在这里,我们主要关注where_condition函数,该函数会为FGAC规则返回限定条件。这种FGAC规则函数必须具有两个传入参数,第一个参数表示schema名称,第二个参数表示表的名称。表示对哪个schema下的哪个表添加FGAC规则。同时必须返回字符型的值,该返回值会被Oracle自动添加到SQL语句中的where条件部分。不过函数名称和参数名称可以按照需要进行指定。从这里定义的函数体中可以看出,如果登录的用户名以S开头,则会受到FGAC规则的限制,where条件里会添加seller_id='Sxxxx',Sxxxx表示登录的用户名。否则,如果以其他用户的身份登录,则不会受到FGAC规则的限制。
创建了用于FGAC规则的函数以后,我们开始定义FGAC规则。
如上所示,我们使用dbms_rls程序包来创建FGAC规则。我们为用户OE下的sales_list表创建了规则;该规则利用用户OE下的sales_app_pkg.where_condition函数返回where条件;该规则作用的SQL语句类型为select和update;update_check参数说明是否对更新以后的结果判断是否满足FGAC规则;在创建规则的同时,我们也启用该规则(enable设置为true)。
创建了FGAC规则以后,我们需要在用户登录到应用程序的时候,调用sales_app_pkg 程序包里的set_sales_context存储过程来设置该用户的应用程序上下文里的seller_id属性的值。在实际应用中,我们可以在登录界面上,当用户单击登录按钮的时候进行设置。在这里为了演示效果,我们创建一个登录触发器来设置,如下所示:
现在,我们可以开始测试FGAC规则的效果了。
以用户OE的身份登录以后,可以看到,三个销售人员各自的数据行数。然后以S0010的身份登录:
很明显看到,我们设置的FGAC规则生效了。我们继续测试更新操作:
由于我们在创建FGAC规则时,指定了update_check为true,当用户S0010登录以后更新sales_list表,将seller_id从S0010更新为S0020时报错,因为S0010无权查询和修改不属于他的销售数据。如果指定update_check为false,则允许这样的update语句成功。
FGAC规则的使用是非常灵活的,其关键就在于where_condition函数的写法。如果要删除FGAC规则,则执行下面的代码:
这里,我们创建了一个规则函数。与FGAC规则一样,该函数必须有两个传入参数,第一个表示要限定的表所属的schema名称,第二个表示要限定的表的名称。在该函数中,我们定义,如果登录用户为表的属主,则可以查看所有列;否则,登录用户不是表所属的用户,则不能查看指定列。
至于具体哪些列要被屏蔽,则需要在定义政策时进行指定,如下所示:
创建基于列VPD与创建FGAC政策一样,也是使用dbms_rls程序包里的add_policy存储过程。在这里,我们定义了一个名为hr_emp_col_policy的政策。该政策作用在用户HR下的employees表上;采用的政策函数为用户HR下的hr_col_vpd。
与FGAC政策不同的是,我们需要指定另外两个参数:sec_relevant_cols表示要屏蔽的列的名称,可以指定多个列,列与列之间用逗号隔开;sec_relevant_cols_opt设置为all_rows,则说明对employees表里所有的记录都屏蔽salary列。
我们以用户HR的身份登录,并显示salary列。
可以看到所有的salary列都显示出来了。然后以用户OE的身份登录,执行下面的SQL语句:
很明显,对于用户OE来说,salary列已经被屏蔽了。
列级别:在该级别下,可以控制某些用户不能检索某个表的某个列的值。比如用户HR下的employees表中,含有工资(salary)列,由于该列比较敏感,因此不让其他用户查询该列的值。其他用户检索该列时,会发现其值全都为空(null)。
一、基于行的VPD
基于行的VPD也叫作Fine-GrainedAccessControl,简称FGAC。FGAC通过定义规则实现,规则的集合叫做FGAC政策(policy)。如果对某个表设置了FGAC,则当用户对该表发出查询或者DML语句时,Oracle都会根据定义的FGAC政策,而自动改写这些SQL语句。其改写方式为自动在SQL语句后面添加where条件。 比如,我们在OE用户下有一个表sales_list,存放了所有的销售记录。每个销售人员只能查询他自己的销售记录。于是,我们在sales表上设置FGAC政策来实现这个业务需求。如果某个销售人员(假设其登录的用户名为S0020)发出下面的查询语句:Select*fromsales_list;
当Oracle在执行该语句时,如果发现sales_list表上存在FGAC政策,于是就会根据FGAC政策,按照如下方式改写该SQL语句:
Select*fromsales_listwhereseller_id='S0020';
对用户来说,这个添加where条件的过程是完全透明的,用户并不知道Oracle已经改写了他发出的SQL语句,从而过滤了查询结果。当然,如果该销售人员发出的语句为:
Select*fromsales_listwherevalues>1000;
那么,当Oracle在改写该SQL语句时,则会改写为如下形式:
Select*fromsales_listwhereqty_sold>1000andseller_id='S0020';
使用FGAC政策来限定返回记录的方式具有许多优点。比如,不需要改写应用程序、对用户完全透明、集中设置、便于管理等。 在使用FGAC时,会涉及应用程序上下文(ApplicationContext)的概念,使用应用程序上下文可以简化FGAC的实现。应用程序上下文是一个数据库对象,可以把它理解为数据库里的每个session的全局环境变量。一旦用户登录到数据库,从而创建出session以后,应用程序上下文就在整个session的生命周期里可用。在应用程序上下文里可以定义多个属性,并为这些属性设置具体的值。而用户不能直接修改属性的值,只能通过程序包来修改属性值。应用程序上下文总是由用户sys拥有。
比如,对于前面sales_list表的例子来说。我们可以创建一个应用程序上下文,当用户登录时,将该用户的ID号作为一个属性值放入该应用程序上下文中。然后在定义FGAC政策的时候,将该用户ID号取出,并作为限定条件短语(也就是where条件语句)返回给Oracle,从而实现FGAC。
在Oracle数据库里,已经为每个session都预先建立了一个应用程序上下文:userenv。一旦建立了session,该session就可以使用这个应用程序上下文。在userenv中已经预先定义了一些属性,比如ip_address、session_user和db_name等。在获取应用程序上下文里的属性值时,我们使用sys_context函数。该函数包含两个参数,第一个参数表示应用程序上下文的名称,第二个参数表示要显示的属性名称。如下所示:
SQL>selectsys_context('userenv','ip_address')"IP",
sys_context('userenv','db_name')"DB"fromdual;
IPDB
------------------------
152.68.32.60ora10g
我们也可以创建自己的应用程序上下文,如下所示:
SQL>createorreplacecontextsales_ctxusingoe.sales_app_pkg;
在这里,sales_ctx是应用程序上下文的名称,而sales_app_pkg则是用来设置sales_ctx里属性的程序包。在创建应用程序上下文时,指定的、用来设置其中属性的程序包可以不必事先存在。但是在为应用程序上下文里设定属性值时,该程序包必须存在,否则报错。如果要删除应用程序上下文,则使用下面的命令:
SQL>dropcontextsales_ctx;
创建了应用程序上下文以后,我们就可以在其中设置属性了。在设置具体的应用程序上下文属性时,必须使用Oracle提供的程序包dbms_session.set_context来设置其属性。其使用格式为:
dbms_session.set_context('context_name','attribute_name','attribute_value')
我们只能在程序包里使用dbms_session.set_context,而不能直接在SQL*Plus里调用。如下所示:
SQL>showuser
USERis"SYS"
SQL>execdbms_session.set_context('sales_ctx','seller_id','S0020');
BEGINdbms_session.set_context('sales_ctx','seller_id','S0020');END;
*
ERRORatline1:
ORA-01031:insufficientprivileges
ORA-06512:at"SYS.DBMS_SESSION",line90
ORA-06512:atline1
我们创建oe.sales_app_pkg包,如下所示:
SQL>connectoe/oe
SQL>createorreplacepackagesales_app_pkgis
2procedureset_sales_context;
3end;
4/
SQL>createorreplacepackagebodysales_app_pkgis
2procedureset_sales_contextis
3begin
4dbms_session.set_context('sales_ctx','seller_id',user);
5end;
6end;
7/
SQL>grantselectonsales_listtopublic;
SQL>grantupdateonsales_listtopublic;
SQL>grantexecuteonsales_app_pkgtopublic;
把执行oe.sales_app_pkg程序包的权限赋给所有用户以后,我们可以测试应用程序上下文是否生效了。
SQL>connecthr/hr
SQL>execoe.sales_app_pkg.set_sales_context;
SQL>selectsys_context('sales_ctx','seller_id')fromdual;
SYS_CONTEXT('SALES_CTX','SELLER_ID')
--------------------------------------------------------------------------------
HR
可以看到,应用程序上下文生效了。接下来,我们创建用于FGAC规则的函数。
SQL>createorreplacepackagesales_app_pkgis
2procedureset_sales_context;
3functionwhere_condition
4(p_schema_namevarchar2,p_tab_namevarchar2)
5returnvarchar2;
6end;
7/
SQL>createorreplacepackagebodysales_app_pkgis
2procedureset_sales_contextis
3v_uservarchar2(30);
4begin
5dbms_session.set_context('sales_ctx','seller_id',user);
6end;
7
8functionwhere_condition
9(p_schema_namevarchar2,p_tab_namevarchar2)returnvarchar2is
10v_seller_idvarchar2(100):=upper(sys_context('sales_ctx','seller_id'));
11v_where_conditionvarchar2(2000);
12begin
13ifv_seller_idlike'S%'then
14v_where_condition:='seller_id='||''''||v_seller_id||'''';
15else
16v_where_condition:=null;
17endif;
18returnv_where_condition;
19end;
20end;
21/
在这里,我们主要关注where_condition函数,该函数会为FGAC规则返回限定条件。这种FGAC规则函数必须具有两个传入参数,第一个参数表示schema名称,第二个参数表示表的名称。表示对哪个schema下的哪个表添加FGAC规则。同时必须返回字符型的值,该返回值会被Oracle自动添加到SQL语句中的where条件部分。不过函数名称和参数名称可以按照需要进行指定。从这里定义的函数体中可以看出,如果登录的用户名以S开头,则会受到FGAC规则的限制,where条件里会添加seller_id='Sxxxx',Sxxxx表示登录的用户名。否则,如果以其他用户的身份登录,则不会受到FGAC规则的限制。
创建了用于FGAC规则的函数以后,我们开始定义FGAC规则。
SQL>connect/assysdba
SQL>begin
2dbms_rls.add_policy(
3OBJECT_SCHEMA=>'oe',
4OBJECT_NAME=>'sales_list',
5POLICY_NAME=>'oe_sales_list_fgac',
6FUNCTION_SCHEMA=>'oe',
7POLICY_FUNCTION=>'sales_app_pkg.where_condition',
8STATEMENT_TYPES=>'select,update',
9UPDATE_CHECK=>true,
10ENABLE=>true);
11end;
12/
如上所示,我们使用dbms_rls程序包来创建FGAC规则。我们为用户OE下的sales_list表创建了规则;该规则利用用户OE下的sales_app_pkg.where_condition函数返回where条件;该规则作用的SQL语句类型为select和update;update_check参数说明是否对更新以后的结果判断是否满足FGAC规则;在创建规则的同时,我们也启用该规则(enable设置为true)。
创建了FGAC规则以后,我们需要在用户登录到应用程序的时候,调用sales_app_pkg 程序包里的set_sales_context存储过程来设置该用户的应用程序上下文里的seller_id属性的值。在实际应用中,我们可以在登录界面上,当用户单击登录按钮的时候进行设置。在这里为了演示效果,我们创建一个登录触发器来设置,如下所示:
SQL>connect/assysdba
SQL>createorreplacetriggerset_seller_id_on_logon
2afterlogononDATABASE
3begin
4oe.sales_app_pkg.set_sales_context;
5end;
6/
现在,我们可以开始测试FGAC规则的效果了。
SQL>connectoe/oe
SQL>selectseller_id,count(*)fromsales_listgroupbyseller_id;
SELLER_IDCOUNT(*)
------------------
S00101067
S0030968
S00201465
以用户OE的身份登录以后,可以看到,三个销售人员各自的数据行数。然后以S0010的身份登录:
SQL>connects0010/s0010
SQL>selectsys_context('sales_ctx','seller_id')fromdual;
SYS_CONTEXT('SALES_CTX','SELLER_ID')
---------------------------------------
S0010
SQL>selectseller_id,count(*)fromoe.sales_listgroupbyseller_id;
SELLER_IDCOUNT(*)
------------------
S00101067
很明显看到,我们设置的FGAC规则生效了。我们继续测试更新操作:
SQL>selectseller_id,qty_soldfromoe.sales_listwhereid=300;
SELLER_IDQTY_SOLD
-----------------
S00101
SQL>updateoe.sales_listsetseller_id='S0020'whereid=300;
updateoe.sales_listsetseller_id='S0020'whereid=300
*
ERRORatline1:
ORA-28115:policywithcheckoptionviolation
由于我们在创建FGAC规则时,指定了update_check为true,当用户S0010登录以后更新sales_list表,将seller_id从S0010更新为S0020时报错,因为S0010无权查询和修改不属于他的销售数据。如果指定update_check为false,则允许这样的update语句成功。
FGAC规则的使用是非常灵活的,其关键就在于where_condition函数的写法。如果要删除FGAC规则,则执行下面的代码:
SQL>begin
2dbms_rls.drop_policy(
3OBJECT_SCHEMA=>'oe',
4OBJECT_NAME=>'sales_list',
5POLICY_NAME=>'oe_sales_list_fgac');
6end;
7/
二、基于列的VPD
对于某些敏感列来说,比如员工的工资等,我们可以通过创建基于列的VPD,从而屏蔽这些敏感列,只有具有权限的用户才能访问这些列。 基于列的VPD与前面讨论的FGAC一样,也是通过设置政策来实现的。设置基于列的VPD时,我们首先需要创建一个政策所需要用到的函数,如下所示。SQL>connecthr/hr
SQL>createorreplacefunctionhr_col_vpd
2(p_ownerinvarchar2,p_objinvarchar2)
3returnvarchar2
4is
5l_retvarchar2(2000);
6begin
7if(p_owner=USER)then
8l_ret:=NULL;
9else
10l_ret:='1=2';
11endif;
12returnl_ret;
13end;
14/
这里,我们创建了一个规则函数。与FGAC规则一样,该函数必须有两个传入参数,第一个表示要限定的表所属的schema名称,第二个表示要限定的表的名称。在该函数中,我们定义,如果登录用户为表的属主,则可以查看所有列;否则,登录用户不是表所属的用户,则不能查看指定列。
至于具体哪些列要被屏蔽,则需要在定义政策时进行指定,如下所示:
SQL>begin
2dbms_rls.add_policy(object_schema=>'hr',
3object_name=>'employees',
4policy_name=>'hr_emp_col_policy',
5function_schema=>'hr',
6policy_function=>'hr_col_vpd',
7statement_types=>'select',
8sec_relevant_cols=>'salary',
9sec_relevant_cols_opt=>dbms_rls.all_rows
10);
11end;
12/
创建基于列VPD与创建FGAC政策一样,也是使用dbms_rls程序包里的add_policy存储过程。在这里,我们定义了一个名为hr_emp_col_policy的政策。该政策作用在用户HR下的employees表上;采用的政策函数为用户HR下的hr_col_vpd。
与FGAC政策不同的是,我们需要指定另外两个参数:sec_relevant_cols表示要屏蔽的列的名称,可以指定多个列,列与列之间用逗号隔开;sec_relevant_cols_opt设置为all_rows,则说明对employees表里所有的记录都屏蔽salary列。
我们以用户HR的身份登录,并显示salary列。
SQL>connecthr/hr
SQL>selectemployee_id,last_name,salaryfromhr.employeeswhererownum<4;
EMPLOYEE_IDLAST_NAMESALARY
-------------------------------
198OConnell2600
199Grant2600
200Whalen4400
可以看到所有的salary列都显示出来了。然后以用户OE的身份登录,执行下面的SQL语句:
SQL>connectoe/oe
SQL>selectemployee_id,last_name,salaryfromhr.employeeswhererownum<4;
EMPLOYEE_IDLAST_NAMESALARY
-------------------------------
198OConnell
199Grant
200Whalen
很明显,对于用户OE来说,salary列已经被屏蔽了。
相关文章推荐
- oracle vpd 虚拟专用数据库
- 利用Oracle VPD(虚拟专用数据库)实现类似EBS R12里的多OU屏蔽
- 利用Oracle VPD(虚拟专用数据库)实现类似EBS R12里的多OU屏蔽
- oracle 虚拟专用数据库详细介绍
- [Oracle] 数据库安全之 - 虚拟私有数据库 (VPD)
- 什么是Oracle10g中的虚拟专用数据库(VPD)
- 数据库安全 Oracle之虚拟私有数据库VPD
- Oracle 10g特性之虚拟专用数据库
- Oracle 10g特性之虚拟专用数据库
- Oracle中的虚拟私有数据库(VPD)
- 数据库树结构 oracle的专用方法
- 详解:数据库名、实例名、ORACLE_SID、数据库域名、全局数据库名、服务名及手工脚本创建oracle数据库
- 详解:数据库名、实例名、ORACLE_SID、数据库域名、全局数据库名、服务名
- 用ORACLE建立数据库(详解)
- Oracle大型数据库系统在AIX UNIX上的实战详解 答疑六 区别AIX中文件系统和目录
- Oracle大型数据库在AIX UNIX上的实战详解
- Oracle大型数据库系统在AIX UNIX上的实战详解 答疑五 AIX中的磁盘
- Oracle 10g数据库在linux (red hat 5)上的自动启动配置方法详解
- 详解:数据库名、实例名、ORACLE_SID、数据库域名、全局数据库名、服务名及手工脚本创建oracle数据库
- “Oracle大型数据库在AIX UNIX上的实战详解”的集中讨论十 dataguard中逻