database vault 能限制 dba 访问敏感数据，但需正确配置 realm（显式添加对象并启用）、command rules（绑定有效 rule set）及禁用绕过权限（如 exempt access policy），否则保护失效。
Database Vault 能真正限制 DBA 访问敏感数据，但前提是 Realm 配置正确、授权未被绕过、且命令规则未被禁用——否则 SYS 或 SYSTEM 仍可能绕过保护。
Realm 必须显式添加对象并关闭隐式访问
默认 Realm 不保护任何对象；即使创建了 HR Realm，scott.emp 表也不会自动受保护。必须手动执行 dvsys.dbms_macadmin.add_object_to_realm 才生效。常见错误是只建了 Realm，没加对象，结果 DBA 照样能查表。
- Realm 创建后，状态必须为
ENABLED（可通过dba_dv_realm查询） - 对象加入 Realm 后，所有非授权用户（含
SYS）执行SELECT会报错：ORA-47418: Realm violation for object SCOTT.EMP - 不要依赖“所有者自动有权限”——Realm 下所有者也需显式授权，用
dvsys.dbms_macadmin.add_auth_to_realm添加auth_options => 1（Owner）或2（Participant）
Command Rules 比 Realm 更容易被忽略但更危险
Realm 控制“能不能读”，Command Rules 控制“能不能改”。DBA 可能不碰数据，但执行 ALTER TABLE、DROP USER、GRANT DBA 这类操作才是高危点。DV 自带的 CREATE USER 规则默认启用，SYS 登录后直接 CREATE USER 就会报 ORA-47401: Command rule violation。
- 检查现有规则：查询
dba_dv_command_rule，重点关注ENABLED = 'Y'的规则 - 规则绑定的是 Rule Set，不是用户——修改
rule_set_name对应的条件逻辑（比如加时间判断），会影响所有使用它的 Command Rule - 误禁用规则（如把
ALTER SYSTEM规则设为DISABLED）等于主动打开后门
授权规则集（Rule Set）决定 Realm 和 Command Rule 的生效时机
一个 Realm 授权是否生效，取决于它绑定的 Rule Set 返回值。Rule Set 默认返回 TRUE，但如果定义成“仅工作日 9–17 点返回 TRUE”，那晚上 SELECT 就会失败——这在测试环境容易漏验。
- Rule Set 本身可包含多个条件函数，例如
dvsys.dbms_macutl.is_daytime或自定义 PL/SQL 函数 - 修改 Rule Set 后，必须重新编译（
dvsys.dbms_macadmin.compile_rule_set），否则变更不生效 - 用
dvsys.dbms_macadmin.get_rule_set_status查看当前状态，避免误以为已启用却实际是DISABLED
DBA 绕过 DV 的常见路径必须堵死
DV 不是银弹。如果 DBA 仍有 EXEMPT ACCESS POLICY 权限、或数据库启用了 OS_AUTHENT_PREFIX + 操作系统级登录、或使用了未纳入 Realm 的同义词/视图，保护就形同虚设。
- 确认
EXEMPT ACCESS POLICY未授予任何用户（包括SYS）：查dba_sys_privs - 禁用远程 OS 认证：设置
os_authent_prefix=''并重启实例（否则sqlplus / as sysdba可跳过 DV） - Realm 只保护基表，不保护视图——若业务层用
CREATE VIEW v_emp AS SELECT * FROM scott.emp，必须把该视图也加进 Realm
最易被忽略的点是：Realm 授权和 Command Rule 都依赖 Rule Set 的实时求值，而 Rule Set 中的自定义函数若抛异常，默认按 FALSE 处理，导致权限意外关闭——上线前务必在真实负载下验证规则逻辑的健壮性。
