oracle 过程限制不允许操作,使用技术手段限制DBA的危险操作—Oracle Database Vault...

概述

众所周知，在业务高峰期，某些针对Oracle数据库的操作具有很高的风险，比如修改表结构、修改实例参数等等，如果没有充分评估和了解这些操作所带来的影响，这些操作很可能会导致故障，轻则导致应用错误，重则导致数据库服务不可用。

另外，在非业务高峰期，某些看似风险不大的操作也可能会导致严重后果，比如不按管理流程修改表结构，如果这个表正好是Oracle GoldenGate复制组的一部分，修改了源端结构而没有通知OGG的相关人员，没有在目标端进行相同的操作，而DDL复制功能也没有打开的情况下，就会导致复制进程故障，导致数据不一致，在某些应用场景下，这也是很严重的生产事故。

目前，传统的应对方法还是强调管理，不管是客户还是服务商都在不断强调制度和规范，希望从制度建设和工程师的职业素养上着手，防止DBA的这种随意的危险操作。

但是，管理制度毕竟是“软性”的，把希望寄托在工程师自觉地遵守制度和“自我修养”上，并不能保证万无一失。

Oracle提供的安全组件，可以用来限制、阻断这种随意的危险操作，用技术手段保证管理制度被遵守。

Oracle Database Vault简介

我们要讨论的是Oracle数据库的安全组件之一: Oracle Database Vault(DV)，它的主要功能是保护敏感数据和职责分离。

DV保护敏感数据主要通过Realm(安全域)，Realm可以简单理解为敏感数据的集合，DV通过realm的配置来指定用户是否可以访问Realm保护的数据，如果在DV中没有给访问权限，即使是sysdba也无权访问受Realm保护的数据，这是DV的核心功能，但不是本文的重点。

DV还有一个很重要的功能，Command Rules，就是可以按一定的判断条件，允许或阻止数据库用户执行DDL、DML以及DCL命令，而且对特权用户，包括sysdba都有效。这个功能正好可以满足我们限制dba的需求。

Oracle Database Vault最低支持的数据库版本是9.2.0.8，早期是单独的一个安装包。从11g开始，Oracle的数据库安装介质中包含了这个组件，想要使用这个组件的用户需要在安装时勾选Database Vault选项。除了安装相关的软件组件，还需要在创建数据库时，创建相关的数据库对象。

Database Vault可以使用相关的存储过程来实现命令行方式的配置、管理，也可以通过web管理界面来管理，在早期，必须安装EM，才能使用web管理界面，从11gR2起，数据库自带的dbcontrol也可以进行web界面的管理了。

除了前面讲到的Realm和Command Rules，还有两个概念要介绍一下，一个是Factor(认证因子)，另一个是Rule sets(规则集)。

Factor(认证因子)就是可以用于进行条件判断的因素，比如客户端主机名，客户端IP等等，Oracle内置了一些常用的Factor，用户也可以自己创建Factor，Factor可以是一个表达式，也可以是一个存储过程的返回值。

Rule Sets简单说就是判断条件的集合，类似SQL的where之后的判断条件，当规则集的判断条件返回为true时，DV允许用户访问数据或执行特定的命令。Rule sets中的Rule可以引用Factor做判断。

示例1：只允许在非业务时间执行drop命令

这个例子是最简单的，不需要使用Factor，只使用Rule Sets和Command Rules就可以完成。我们用数据库用户test来示范：

登录DV的管理页面：

创建一个Rule Set，名字叫”Can not drop table in business time”，选择Any True，意思是说规则集中的规则(判断条件)任何一个为True，规则集判断结果就为True。其实All True就相当于and，Any True就相当于or

这两个RULE也很好理解，就是判断当前时间是否为业务时间，在这里，为了便于做实验，把业务时间定义为11：45~11：55，这个规则集判断当前时间，如果当前时间不在业务时间内，规则集返回True。

然后创建Command Rule，如下图：

这个Command Rule的意思就是指定的Rule Set 返回True时，允许drop test用户下的表，否则即使是sysdba或表的owner也无权drop table。

效果：

其他我们想控制的Alter Table等Command Rule的设置方法类似。

实例2：只允许用户使用特定工具(应用)登录数据库

实际工作中，我们经常遇到这样的情况：应用开发人员都有应用用户的口令，他们可以随意用SQL*PLUS或PL/SQL Developer这样的工具连接到生产库上，如果一时搞混了生产库和测试库，就可能有悲剧发生。最好的解决方法就是限制应用用户所用的工具，应该只允许中间件以这个用户连接，其他工具都不允许连接。

这个例子会用到Factor，首先我们创建一个Factor，取用户会话的Module:

用SQL*PLUS登录数据库，验证这个Factor取出的值:

引用Factor的方法就是DVF.F$+Factor name，在Linux本机登录，Module就是上面显示的那样，在windows上远程登录，Module的值是“SQLPLUS.EXE”。

下面创建Rule Set，名字叫“Limit SQL*PLUS“，

注意是“Any True”

创建RULE：

创建Command Rule：

按照这种规则，除了SYS，SYSTEM，DV_MANAGER之外的用户，不管是本地还是远程，都不能用SQL*PLUS登录。

用SQL Developer登录正常：

实例3：使用Dual Key安全功能

现实场景中，我们希望DBA遵守制度，比如在修改表结构之前，通知OGG相关人。或者为了增加安全性，要求DBA做的重大操作，必须得到老板的批准。DV可以利用Dual Key功能满足这种需求。

简单说，我们可以写一个存储过程，判断流程中需要通知的人是否在线，如果在线，才允许执行相应的操作。而那个需要被通知的人，只要拥有connect数据库的权限就行，他(她)的登录动作就变成了一种授权或被通知后的确认。

具体步骤：

首先给DV的管理员授权，让用户可以访问字典视图和编写存储过程:

SQL> GRANT CREATE PROCEDURE TO dv_manager;

Grant succeeded.

SQL> GRANT SELECT ON V_$SESSION TO dv_manager;

Grant succeeded.

我们假设授权的用户是“BOSS“，而执行操作的用户是”TEST“，相应的判断BOSS是否在线的存储过程如下：

CREATE OR REPLACE FUNCTION check_boss_logged_in

return varchar2

authid definer as

v_session_number number := 0;

v_allow varchar2(10) := ‘TRUE‘;

v_deny varchar2(10) := ‘FALSE‘;

BEGIN

SELECT COUNT(*) INTO v_session_number

FROM SYS.V_$SESSION

WHERE USERNAME = ‘BOSS‘;

IF v_session_number > 0

THEN RETURN v_allow;

ELSE

RETURN v_deny;

END IF;

END check_boss_logged_in;

/

使用DV管理员创建这个Function，然后授权给DVSYS：

SQL>GRANT EXECUTE ON check_boss_logged_in to DVSYS;

创建Rule Set:

Name：Dual Key

Evaluation Options：Any True

规则如下：

创建Command Rule:

这个Command Rule达到的效果是，如果test用户想alter owner为test的table，必须boss用户同时在线，否则报错，无权限。如果是其他人修改test用户下的表，不受这个限制。

最后的效果：

BOSS用户没有在线，那么TEST用户alter table报错

只有在test用户通知了boss用户，或者按照流程，得到了boss用户的批准，boss用户用登录数据库这个动作来代表确认，test用户才可以修改表结构：

原文：http://www.cnblogs.com/raobing/p/6174551.html