概述
众所周知，在业务高峰期，某些针对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的需求。
大家如果想详细了解DV的功能，可以访问Oracle官网：http://www.oracle.com/technetwork/database/options/database-vault/index-085211.html
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用户才可以修改表结构：
