Oracle如何查找权限分配过多的用户_风险评估方法-Oracle-PHP中文网

查DBA_TAB_PRIVS必须指定OWNER，否则混查多schema同名表；系统权限与对象权限分属DBA_SYS_PRIVS和DBA_TAB_PRIVS，需分别查询；权限视图大小写敏感且默认大写；PUBLIC授权和GRANTABLE=YES是高危风险点。

查 DBA_TAB_PRIVS 时漏写 OWNER 导致结果错乱

直接执行 select * from dba_tab_privs where table_name = 'emp' 会返回多个 schema 下同名表的权限记录，比如 scott.emp、hr.emp、test.emp 全部混在一起。这不是数据错误，而是 oracle 默认不绑定 schema 的行为。

真正要定位“谁对 SCOTT 用户的 EMP 表授了什么权”，必须显式加 OWNER = 'SCOTT' 条件。否则排查越权或收敛权限时，容易把其他用户的授权误判为当前目标对象的授权。

OWNER 是 schema 名，不是用户名（虽然多数情况下一致，但若用户被重命名或使用了 proxy 用户，二者可能分离）
表名和 OWNER 在建表未加双引号时默认大写，查询时也得用大写，否则查不到
如果只关心某用户“被授予了哪些表权限”，用 GRANTEE = 'USERNAME' 比反向查表更高效

DBA_SYS_PRIVS 和 DBA_TAB_PRIVS 混用导致权限漏检

系统权限（如 CREATE TABLE、DROP ANY TABLE）和对象权限（如对 EMP 表的 SELECT）存储在两张完全独立的视图里：DBA_SYS_PRIVS 和 DBA_TAB_PRIVS。有人想“一次性查清某用户所有权限”，只查其中一张，就会漏掉一半。

例如用户 APP_USER 被授予了角色 DBA，而 DBA 角色本身含大量系统权限——这些不会出现在 DBA_TAB_PRIVS 里；反过来，它被直接授予了 SELECT 权限在 HR.EMPLOYEES 上，这条记录也不会出现在 DBA_SYS_PRIVS 中。

查系统级能力：用 DBA_SYS_PRIVS + DBA_ROLE_PRIVS 递归展开角色
查对象级访问：用 DBA_TAB_PRIVS，注意区分 GRANTEE 是用户还是 PUBLIC
角色权限不自动展开，DBA_TAB_PRIVS 中的 GRANTEE 若是角色名，需再查 DBA_ROLE_PRIVS 找出该角色实际授予了哪些用户

用 ALL_* 或 USER_* 视图替代 DBA_* 时权限范围收缩明显

不是所有 DBA 都有 SELECT ANY DICTIONARY 权限。当执行 SELECT * FROM DBA_TAB_PRIVS 报错 ORA-00942: table or view does not exist，大概率是权限不足，而非视图不存在。

此时应降级使用 ALL_TAB_PRIVS（当前用户可访问的所有对象上的权限）或 USER_TAB_PRIVS（当前用户自己拥有的权限）。但要注意：这两者返回的结果集远小于 DBA_TAB_PRIVS，尤其在做风险评估时，容易误判“没发现高危授权”，其实是根本没权限看到。

QuantOracle

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

下载

ALL_TAB_PRIVS 不包含当前用户无 SELECT 权限的对象，哪怕该对象上已授予别人 SELECT ANY TABLE
USER_TAB_PRIVS 只返回“你作为被授权方”拿到的权限，不反映你作为授权方（GRANTOR）给了谁什么权
审计类任务必须用 DBA_* 视图，否则无法覆盖全量权限面

识别 PUBLIC 授权和 GRANTABLE=YES 是风险评估关键点

GRANTEE = 'PUBLIC' 出现在 DBA_TAB_PRIVS 中，意味着**任意数据库用户**（包括后续新建的）都能访问该对象。这是最常被忽略的高危配置。同样，GRANTABLE = 'YES' 表示被授权者还能把这权限转授出去，形成权限扩散链。

比如一条记录：OWNER='HR', TABLE_NAME='EMPLOYEES', GRANTEE='PUBLIC', PRIVILEGE='SELECT', GRANTABLE='NO'——已是严重问题；若 GRANTABLE='YES'，则任意用户都能再 GRANT SELECT 给别人，彻底失控。