首页 > 代码库 > 使用技术手段限制DBA的危险操作—Oracle Database Vault

使用技术手段限制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的需求。

技术分享

大家如果想详细了解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用户才可以修改表结构:

技术分享

使用技术手段限制DBA的危险操作—Oracle Database Vault