Oracle如何查询所有具有DBA权限的用户_审计查询实战-Oracle-PHP中文网

查DBA角色授予情况必须用DBA_ROLE_PRIVS视图，WHERE GRANTED_ROLE = 'DBA'；ADMIN_OPTION='YES'可再授权，DEFAULT_ROLE='YES'登录即激活；多租户需查CDB_ROLE_PRIVS且CON_ID=0；V$PWFILE_USERS须同步检查SYSDBA用户；审计DBA变更必须启用AUDIT_SYS_OPERATIONS并查OS审计文件。

查 DBA 角色授予情况必须用 `DBA_ROLE_PRIVS`

直接查 dba_role_privs 是唯一可靠方式，其他视图（如 user_role_privs 或 all_role_privs）只返回当前会话可见的角色，无法覆盖全局。必须以有 select 权限的账号（如 sys、system 或已授权访问数据字典的用户）执行。

常见错误是误用 user_role_privs 查自己账号——结果永远为空或仅显示当前用户；或者漏加 WHERE GRANTED_ROLE = 'DBA'，导致返回全部角色授权记录，难以定位。

SELECT GRANTEE, ADMIN_OPTION, DEFAULT_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA';
ADMIN_OPTION = 'YES' 表示该用户可再授予 DBA 角色（高危行为，需重点审计）
DEFAULT_ROLE = 'YES' 表示登录时自动激活 DBA 角色（即使未显式 SET ROLE）
多租户环境（CDB/PDB）下，需确认是否在根容器（CDB$ROOT）中查询，否则可能漏掉 CDB 级 DBA 用户

`V$PWFILE_USERS` 不等于 DBA 权限，但必须同步检查

V$PWFILE_USERS 显示的是拥有 SYSDBA / SYSOPER 系统权限的用户，这类权限独立于 DBA 角色，且能绕过常规审计和密码验证直接登录。它不反映 DBA 角色授予状态，但安全影响同等严重——两者都意味着近乎完全控制能力。

容易忽略的是：一个用户可能没有 DBA 角色，却通过 SYSDBA 登录后手动 GRANT DBA TO ...，此时 DBA_ROLE_PRIVS 里还没记录，但风险已存在。

SELECT USERNAME, SYSDBA, SYSOPER, SYSASM FROM V$PWFILE_USERS;
SYSDBA = 'TRUE' 的用户必须出现在你的高权限用户清单中，不能只盯 DBA 角色
该视图需 SELECT ANY DICTIONARY 或 SELECT_CATALOG_ROLE 权限，普通 DBA 用户默认无权查
注意：V$PWFILE_USERS 只反映口令文件中的条目，不包含通过外部认证（如 OS auth）获得 SYSDBA 的情况

审计 DBA 权限变更必须开启 `AUDIT_SYS_OPERATIONS`

仅查快照没用——关键是要捕获“谁在什么时候把 DBA 授给了谁”。默认情况下，GRANT DBA TO ... 这类操作不会被标准审计捕获，除非显式启用 AUDIT_SYS_OPERATIONS 并重启实例。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

典型误区是以为开了 AUDIT_TRAIL = DB 就够了，其实它只记录普通用户的 DDL/DML，对 SYS 或 SYSDBA 的权限操作无效。

启用命令：ALTER SYSTEM SET AUDIT_SYS_OPERATIONS = TRUE SCOPE=SPFILE;
重启数据库后，所有 SYS 用户及 SYSDBA 登录者的操作（含 GRANT、REVOKE）将写入操作系统审计文件，路径由 AUDIT_FILE_DEST 参数指定
不可依赖 DBA_AUDIT_TRAIL 查这类操作——它只存 AUDIT_TRAIL = DB 下的记录，而 AUDIT_SYS_OPERATIONS 强制走 OS 文件
审计文件是纯文本，需用系统命令（如 grep "GRANT.*DBA" *.aud）提取，无法用 SQL 直接查询

生产环境应定期导出并比对 DBA 清单

单纯“查一次”解决不了问题。DBA 权限常因临时排障被授予，事后遗忘回收。真正有效的做法是建立基线 + 差异检测机制。

最易被忽略的点是：COMMON 列在多租户中决定权限是否跨 PDB 继承。设为 'YES' 意味着该 DBA 授权在所有 PDB 中自动生效，但 DBA_ROLE_PRIVS 查询默认只返回当前容器结果，不带 CDB$ROOT 上下文会误判范围。

建议脚本每天凌晨执行：SELECT GRANTEE, ADMIN_OPTION, COMMON FROM CDB_ROLE_PRIVS WHERE CON_ID = 0 AND GRANTED_ROLE = 'DBA';
输出保存为带时间戳的 CSV，与前一日比对新增/删除项
对 ADMIN_OPTION = 'YES' 的用户，额外检查其是否曾执行过 GRANT DBA（需查 AUDIT_SYS_OPERATIONS 日志）
禁止在应用账号上设置 DEFAULT_ROLE = 'YES' for DBA——这会让连接即获得最高权限，失去最小权限控制