众所周知，在业务高峰期，某些针对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官网：

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的设置方法类似。