不能靠常规权限视图实时捕获提权尝试，必须启用审计并重点盯住V$POLICY_HISTORY和DBA_AUDIT_TRAIL；因DBA_SYS_PRIVS等视图仅反映当前已授予权限的快照，不记录失败的GRANT/SET ROLE等操作，而Database Vault拦截写入V$POLICY_HISTORY（重启清空），审计需启用AUDIT SYSTEM GRANT BY ACCESS等并查DBA_AUDIT_TRAIL中RETURNCODE≠0的记录。
直接结论：不能靠常规权限视图实时捕获提权尝试，必须启用审计（AUDIT）并重点盯住 V$POLICY_HISTORY 和 DBA_AUDIT_TRAIL，否则行为无声无痕。
为什么 DBA_SYS_PRIVS 或 USER_ROLE_PRIVS 查不到提权尝试
这些视图只反映「当前已授予」的权限状态，不是操作日志。用户执行 GRANT DBA TO scott 被拒绝、或用 SET ROLE dv_owner_role 触发 Database Vault 拒绝，这些动作本身不会写入 DBA_SYS_PRIVS —— 它们连“成功授权”都不是，更不会被记录在静态权限视图里。
常见错误现象：管理员查完 SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE='SCOTT' 发现没 DBA 权限，就以为“没人想提权”，其实攻击者可能刚被 V$POLICY_HISTORY 拦下三次，而你完全不知道。
- 权限视图是快照，不是流水账
- 提权失败 ≠ 没发生；失败操作只有审计能捕获
- Database Vault 策略拦截会写入
V$POLICY_HISTORY，但默认不归档，重启即丢
必须开启的审计类型和对应查询方式
Oracle 默认不审计特权操作。要监控提权尝试，至少启用以下三项：
-
AUDIT SYSTEM GRANT BY ACCESS;—— 捕获所有GRANT/REVOKE语句（无论成功失败） -
AUDIT ROLE BY ACCESS;—— 捕获SET ROLE、ENABLE ROLE类操作 -
AUDIT EXECUTE ON SYS.DBMS_RLS BY ACCESS;（如用细粒度访问控制）
开启后，失败的提权尝试会出现在 DBA_AUDIT_TRAIL 中，关键字段包括：
-
ACTION_NAME= 'GRANT' 或 'SET ROLE' -
RETURNCODE≠ 0（比如 ORA-01031 表示权限不足） -
SQL_TEXT包含原始语句，例如GRANT DBA TO attacker
示例查询（找最近一小时所有失败的授权尝试）：
SELECT TIMESTAMP, USERNAME, ACTION_NAME, RETURNCODE, SQL_TEXT
FROM DBA_AUDIT_TRAIL
WHERE ACTION_NAME IN ('GRANT', 'SET ROLE')
AND RETURNCODE != 0
AND TIMESTAMP > SYSDATE - 1/24;V$POLICY_HISTORY 是 Database Vault 提权拦截的唯一实时窗口
如果你启用了 Oracle Database Vault，所有策略触发（包括阻止提权）都会实时写入 V$POLICY_HISTORY。它比审计日志更快、更轻量，适合秒级响应。
注意点：
- 该视图只对
DVSYS用户可见，普通 DBA 需要SELECT_CATALOG_ROLE或显式授权 - 数据是内存驻留，数据库重启后清空；需配合定时采集落库，否则无法回溯
- 关键字段：
POLICY_NAME（哪个策略拦的）、RESULT（ALLOW / DENY / LOG）、CLIENT_IDENTIFIER（可关联应用会话）
典型拦截记录：
SELECT POLICY_NAME, RESULT, EVENT_TIME, CLIENT_IDENTIFIER, OS_USER FROM V$POLICY_HISTORY WHERE RESULT = 'DENY' AND EVENT_TIME > SYSDATE - 1/48;
容易被忽略的盲区：隐式提权路径
攻击者不一定直呼 GRANT DBA。以下行为同样构成提权尝试，但常被审计遗漏：
- 调用高权限包：如
EXECUTE IMMEDIATE 'ALTER USER scott IDENTIFIED BY ...'—— 需审计EXECUTEonSYS.DBMS_SQL - 利用 UTL_FILE/UTL_HTTP 写文件或外连 —— 属于“权限滥用”，需结合
DBA_TAB_PRIVS+DBA_PROFILES分析用户是否被误授了高危对象权限 - 通过同义词或视图间接访问
V_$SESSION、V_$PWFILE_USERS—— 这类元数据访问本身不触发审计，但可暴露敏感信息供后续提权
真正难防的不是明面上的 GRANT，而是用户已有权限组合出的隐式能力。监控必须从“动作”下沉到“能力面分析”——定期跑脚本检查谁有 SELECT ANY DICTIONARY + CREATE PROCEDURE，这类组合比单个 DBA 角色更危险。
