下面是一个真实的例子，看完这个例子，就可以明白为什么VAULT对于保护敏感数据如此重要了。

作为政府部门重要的对外服务窗口，M市的社会保障局一直表现良好。客户的满意度也很不错。从日常的五保工作，到定期举办的人才培训和人才交流，市场和社会反响良好。除了源于大家努力的工作态度，后面还有一个运行安全可靠的应用系统来支撑。

一天下午，正在主持工作例会的M市社保局长突然接到一个电话，电话来自公安系统，内容是接到银行报案，怀疑有人突入社保应用系统内部修改系统数据，并涉嫌冒领养老金，请社保局协助调查相关案情。

作为局长几乎有点不相信眼前的事情。因为作为一个准金融单位，系统安全是他们设计时第一优先考虑的事，业务流程也有严格的规定和管理。按理说这种情况是不可能发生的。

事情的确令人费解。社会保障应用系统为了系统安全起见，从社保大厅窗口，到最后的主机系统，设立了包括防火墙，入侵检测，操作系统，密码保护等等软的，硬的设施共12道。正常情况下，保护措施可以令到连苍蝇都飞不进来。

可最后通过调查发现，是单位内部的系统管理维护人员，绕过了所有的这十二道防护措施，直接将数十个已经去世的参保人状态改成存活，然后将转账账户改成自己的号码。这样每个月嫌疑人就可以坐收这些死人养老金了。

几个月后，银行也是无意中发现，多个个人养老金发放，怎么会流向同一个账户呢？展开调查后，才使得真相大白。

从这个例子不难看到，虽然企业部署了严格的硬件、软件安全策略，但是绝大部分是针对外部用户的，而对于内部用户，尤其是系统管理员，数据库管理员而言，这些安全策略形同虚设、不堪一击。正所谓日防夜防，家贼难防。

从企业角度讲，对于这种系统核心人员，确实应该做到用人不疑，疑人不用。但是企业又不能将自己所有的核心机密仅仅建立在信任之上。而目前的数据库产品对于系统管理员和数据库管理员的约束很少，除了一些数据库加密之外的功能外，没有什么能限制数据库管理员的操作。加强审计、加强监控倒是可以找到最终的罪魁祸首，但是这两种手段都属于事后诸葛亮，对于阻止破坏性事务的发生并没有实质性的帮助。

而从DBA角度讲，尤其是产品DBA，负责数据库的安装、维护、优化、备份、迁移、升级等等维护管理性的操作，其实对数据库中保存的信息的含义并不关心。只是工作性质决定了DBA所具有数据库中最高的权限，而DBA一般也不需要通过这种权限来访问敏感业务数据。那么一旦发生了敏感的数据泄漏的事情，拥有最高权限的DBA首先被放到了被怀疑的位置上，这对于DBA来说又很“冤枉”。

从上面的分析不难看到，企业需要DBA和系统管理员来管理数据库，保证数据库高效、安全的运行，又不希望核心的敏感数据被拥有高权限的人员修改或查看。而DBA需要很高的权限来管理、维护数据库，但是又不需要访问业务数据的权限。那么最简单的方法就是数据库可以提供这样的功能，使得DBA有足够的权限来管理、维护数据库，又没有权限去随意的修改、查看业务用户下的数据。

而ORACLE DATABASE VAULT组件就具备这样的功能：

SQL> CONN SYS@YTK111 AS SYSDBA
输入口令: ****
已连接。
SQL> SHOW USER
USER 为 "SYS"
SQL> SELECT * FROM V$OPTION
  2  WHERE PARAMETER = 'Oracle Database Vault';

PARAMETER                                VALUE
---------------------------------------- -------------------------
Oracle Database Vault                    TRUE

SQL> CREATE USER TEST IDENTIFIED BY TEST;
CREATE USER TEST IDENTIFIED BY TEST
                               *
第 1 行出现错误:
ORA-01031: 权限不足

SQL> GRANT CONNECT, RESOURCE TO YANGTK;
GRANT CONNECT, RESOURCE TO YANGTK
*
第 1 行出现错误:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-47401: grant role privilege (在 CONNECT.  上) 的领域违规
ORA-06512: 在 "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: 在 line 31

可以看到，在ORACLE DATABASE VAULT的默认情况下，SYS用户甚至连创建用户和授权的权限都没有了。

当前SYS还是可以做一些数据库级或实例级的维护和管理操作的：

SQL> SHOW PARAMETER OPEN_CURSORS

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                         integer     300
SQL> ALTER SYSTEM SET OPEN_CURSORS = 500;

系统已更改。

SQL> ALTER SYSTEM SWITCH LOGFILE;

系统已更改。

SQL> CREATE TABLESPACE TEST DATAFILE 'E:\ORACLE\ORADATA\YTK111\TEST01.DBF' SIZE 100M;

表空间已创建。

只是和用户创建、授权等相关的权限从SYS和SYSTEM等DBA用户中被移除。在VAULT中，有了一个新增的用户DVSYS专门负责这部分权限的管理：

SQL> CONN DVSYS@YTK111
输入口令: ****
已连接。
SQL> CREATE USER TEST IDENTIFIED BY TEST DEFAULT TABLESPACE TEST;

用户已创建。

SQL> GRANT CONNECT TO TEST;

授权成功。

SQL> CONN SYS@YTK111 AS SYSDBA
输入口令: ****
已连接。
SQL> GRANT RESOURCE TO TEST;

授权成功。

SYS和DVSYS二者各司其职，SYS没有创建用户、赋予CONNECT角色的权限，而DVSYS则没有权限授予UNLIMITED TABLESPACE和CREATE TABLE等系统权限。

SQL> CONN TEST@YTK111
输入口令: ****
已连接。
SQL> CREATE TABLE T (ID NUMBER);

表已创建。

SQL> INSERT INTO T VALUES (1);

已创建 1 行。

SQL> COMMIT;

提交完成。

SQL> CONN SYS@YTK111 AS SYSDBA
输入口令: ****
已连接。
SQL> SELECT * FROM TEST.T;

        ID
----------
         1

默认情况下SYS是可以访问其他用户下对象的。

下面通过建立REALM，使得用户数据得到保护：

SQL> CONN DVSYS@YTK111
输入口令: ****
已连接。
SQL> EXEC DBMS_MACADM.CREATE_REALM('TEST_REALM', 'REAML FOR TEST', 'Y', 0)

PL/SQL 过程已成功完成。

SQL> EXEC DBMS_MACADM.ADD_OBJECT_TO_REALM('TEST_REALM', 'TEST', '%', '%')

PL/SQL 过程已成功完成。

创建了一个名为TEST_REALM的REALM，然后将TEST用户的所有对象放到这个REALM中，下面再次尝试利用SYS访问TEST用户下的对象：

SQL> CONN SYS@YTK111 AS SYSDBA
输入口令: ****
已连接。
SQL> SELECT * FROM TEST.T;
SELECT * FROM TEST.T
                   *
第 1 行出现错误:
ORA-01031: 权限不足

可以看到，这时SYS已经没有权限去访问TEST用户下的对象了。这说明通过VAULT中REALM的保护，DBA已经没有权限看到业务用户下的敏感数据了。

这里展示的只是VAULT包含敏感数据的一个小例子，VAULT在安全性方面的功能远不止这些，比如VAULT可以限制访问为本地访问、可以限制访问的时间区域，可以限制访问的IP范围等等。

社保系统包括社保、医保、就业、工伤、生育五个系统，其中这些系统中又包括共享的公共信息。如果将这些系统都独立到不同的数据库，确实可以保证各个子系统的数据安全。但是这种方式不利于公共信息数据的共享，而为了达到数据共享的目的所部署的复制、同步环境又将带来新的不安全因素。

如果使用了DATABASE VAULT，那么问题就简单多了。对于社保系统而言，可以创建6个REALM，分别对应社保、医保、就业、工伤、生育和公共信息6个用户组。通过添加数据库用户到REALM，使得社保、医保、就业、工伤和生育对应的用户均只能访问各自的业务数据以及公共信息业务数据。而公共信息对应的用户则只能访问公共信息。对于系统管理员，可以根据需要来进行设置，可以允许系统管理员访问业务数据或公共信息，也可以完全禁止系统管理员访问任何的业务数据。

总的来说，Oracle Database Vault在数据库的基础上增加了强大的安全性支持，充分的利用Vault所提供的功能，可以确保企业核心敏感数据不会被任何不必要的人所访问，无论这个人是在企业外部还是在企业内部，甚至是系统管理员或者数据库管理员。