GRANT ANY PRIVILEGE 是高危系统权限，不能直接授予普通用户，因其允许持有者任意授予包括 CREATE USER、ALTER DATABASE 等关键权限，等同于赋予部分 DBA 权限，一旦被攻破或误操作将导致数据库安全边界崩溃。
GRANT ANY PRIVILEGE 是高危系统权限，不能直接授予普通用户；必须用角色隔离、最小化授权、审计跟踪三者配合控制。
为什么 GRANT ANY PRIVILEGE 不能直接给用户
这个权限允许持有者任意授予任何系统权限（包括 CREATE USER、ALTER DATABASE、ADMINISTER DATABASE TRIGGER 等），相当于把 DBA 的一部分“发号施令权”交出去。一旦该用户被攻破或误操作，整个数据库安全边界就塌了。
常见错误现象：
- 执行
GRANT SELECT ON hr.employees TO app_user成功，但后续发现app_user又把SELECT ANY TABLE授给了测试账号 - DBA 查
DBA_SYS_PRIVS发现非 DBA 用户名下赫然出现GRANT ANY PRIVILEGE记录 - 审计日志里频繁出现
GRANT ... TO ...操作，来源却是本不该有授权能力的运维子账号
用角色封装 + WITH ADMIN OPTION 限定传递范围
不把 GRANT ANY PRIVILEGE 直接给用户，而是创建专用授权角色，并严格限制谁可以使用它。
- 新建角色：
CREATE ROLE obj_grant_admin; - 仅由 DBA 授予该角色：
GRANT GRANT ANY OBJECT PRIVILEGE TO obj_grant_admin; - 再把角色授予可信人员：
GRANT obj_grant_admin TO ed_user WITH ADMIN OPTION; - 注意：这里用的是
WITH ADMIN OPTION（角色级传递），不是WITH GRANT OPTION（权限级传递）——后者对系统权限无效
这样 ed_user 就能执行 GRANT SELECT ON rst.search_log_monitor TO jf，但无法把 obj_grant_admin 再转授给其他人，除非你显式加 WITH ADMIN OPTION。
用 DBA_SYS_PRIVS 和审计定位越权源头
一旦发现异常授权行为，靠查询视图快速定位谁在滥用权限：
- 查谁有高危权限：
SELECT grantee, privilege, admin_option FROM DBA_SYS_PRIVS WHERE privilege IN ('GRANT ANY PRIVILEGE', 'GRANT ANY OBJECT PRIVILEGE', 'GRANT ANY ROLE'); - 查授权链路：
SELECT * FROM DBA_ROLE_PRIVS WHERE granted_role = 'OBJ_GRANT_ADMIN'; - 开启细粒度审计（推荐）：
AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;，日志会记录谁、何时、对哪个对象执行了授权
特别注意：Oracle 默认不审计 GRANT 语句，不主动开启就等于“睁眼瞎”。
替代方案：用 DEFAULT PRIVILEGES 减少手动授权需求
如果问题本质是“总要反复给新表授权”，与其放任 GRANT ANY OBJECT PRIVILEGE，不如从源头减少授权动作：
- 在 schema 创建后立即设置默认权限：
ALTER DEFAULT PRIVILEGES IN SCHEMA rst GRANT SELECT ON TABLES TO jf; - 该语句只影响此后在
rst下新建的表，不影响已有对象，但能大幅降低日常运维中手写GRANT的频次 - 注意：此语法在 Oracle 中不支持（是 PostgreSQL/金仓特性），Oracle 必须用触发器或脚本定期扫描
DBA_OBJECTS补授权 —— 这恰恰说明，Oracle 环境下更不能依赖GRANT ANY OBJECT PRIVILEGE来偷懒
真正难的不是写一条 GRANT，而是确保每条授权都可追溯、可回收、不越界。权限一旦放出，回收比授予难十倍。
