应通过递归查询DBA_ROLE_PRIVS获取所有直接或间接拥有DBA角色的用户，再结合DBA_SYS_PRIVS、V$PWFILE_USERS等视图检查系统权限、SYSDBA/SYSOPER登录权限及危险权限组合，最后需关联业务行为与审计日志综合研判。
直接查 DBA 角色持有者不等于找全高权限用户——DBA_ROLE_PRIVS 只显示直接授予权限，漏掉角色嵌套和系统级特权。
查 DBA 角色的完整继承链
Oracle 中 DBA 角色可能通过多层角色嵌套授予，仅查 DBA_ROLE_PRIVS 会漏掉间接获得 DBA 权限的用户。必须用递归查询展开整个授权路径。
- 执行以下语句获取所有最终拥有 DBA 角色的用户（含嵌套）：
SELECT DISTINCT CONNECT_BY_ROOT grantee AS username FROM dba_role_privs WHERE granted_role = 'DBA' CONNECT BY PRIOR grantee = granted_role;
- 注意：该查询依赖
dba_role_privs视图，仅 DBA 用户可执行；普通用户无权访问此视图 - 如果返回空，不代表没有高权限用户——可能有人被直接授予了
ALTER DATABASE、UNLIMITED TABLESPACE等关键系统权限，而非通过 DBA 角色
查关键系统权限持有者
有些用户没拿 DBA 角色，但被单独授予了危险权限，比如 SELECT ANY DICTIONARY 或 ADMINISTER DATABASE TRIGGER，这类权限同样构成高风险。
- 重点检查这些权限：
ALTER SYSTEM、ALTER DATABASE、SELECT ANY DICTIONARY、EXECUTE ANY PROCEDURE、UNLIMITED TABLESPACE - 示例（查
SELECT ANY DICTIONARY授予者）：SELECT grantee, admin_option FROM dba_sys_privs WHERE privilege = 'SELECT ANY DICTIONARY';
-
ADMIN_OPTION = 'YES'表示该用户还能把此权限再授给别人，危害更大
查 SYSDBA / SYSOPER 登录权限用户
能以 SYSDBA 或 SYSOPER 身份登录的用户，权限远超普通 DBA 角色——他们绕过数据字典权限检查，可直接操作控制文件、重做日志等核心结构。
- 查询方式不是查数据字典，而是查密码文件：
SELECT username, sysdba, sysoper FROM v$pwfile_users;
- 这个视图只对具有
SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE的用户可见 - 密码文件本身（
orapw<sid>）不在数据库内，无法通过 SQL 删除或修改其内容，必须用ORAPWD工具重建
容易被忽略的权限组合风险
单个权限可能看似无害，但组合起来就构成提权路径。比如同时有 CREATE PROCEDURE + EXECUTE ANY PROCEDURE，就能创建并调用恶意包劫持会话。
- 典型危险组合：
CREATE ANY TRIGGER+ALTER ANY TABLE；CREATE JOB+ALTER SESSION - 不要只盯着“DBA”标签，要逐条比对
dba_sys_privs和dba_tab_privs中的权限交叉点 - 生产环境建议定期导出结果并人工复核，自动化脚本很难覆盖所有业务逻辑层面的权限滥用场景
真正难发现的高权限用户，往往藏在角色嵌套深处，或靠几个分散但协同的权限实现越权。查完视图只是第一步，得结合具体业务账号行为和审计日志交叉验证才可靠。
