GRANT SELECT ANY TABLE 是高危系统级权限可读取所有用户含SYS的任意表并用于提权应严格遵循最小权限原则按需授予具体对象权限或角色误授后须及时回收并检查依赖对象。为什么 GRANT SELECT ANY TABLE 是数据库里的“万能钥匙”它不是普通权限而是绕过对象级授权的系统级通行证——只要用户拥有这个权限就能读取数据库中任意用户包括 sys、system下的任意表哪怕那张表根本没显式授权给他。更关键的是它还能被用来提权。比如创建一个指向 SYS 模式的存储过程再用 EXECUTE IMMEDIATE 执行动态 SQL就能悄悄执行 GRANT DBA TO ... 这类操作把普通用户变成管理员。常见错误现象SELECT * FROM dba_users 突然能执行了但你没给用户 DBA 角色使用场景仅限 DBA 日常巡检或紧急故障排查且应通过临时会话审计日志严格约束参数差异和 SELECT ANY DICTIONARY 不同前者能查所有业务表后者只覆盖数据字典视图授予权限时怎么避免掉进 ANY 权限陷阱最小权限不是口号是必须落地的操作原则。绝大多数应用需求完全不需要 ANY 权限——它们真正需要的只是对几个特定 Schema 下几张特定表的查询权。正确做法先确认目标对象例如业务用户 APP_USER 只需查 HR.EMPLOYEES 和 HR.DEPARTMENTS那就执行 GRANT SELECT ON HR.EMPLOYEES TO APP_USER 和 GRANT SELECT ON HR.DEPARTMENTS TO APP_USER替代方案如果涉及多个表且属同一 Schema可建角色如 hr_reader批量授权后再授角色便于后期回收容易踩的坑用脚本批量授 SELECT ANY TABLE 应对“开发说连不上表”结果让测试账号拥有了读取加密密钥表、审计日志表的能力已经误授了 SELECT ANY TABLE怎么安全回收直接 REVOKE SELECT ANY TABLE FROM user_name 是最干净的做法但要注意两点一是确认该用户没有正在运行的依赖此权限的作业二是检查是否曾用它创建过高危对象如前面提到的跨 Schema 存储过程。 文心快码 文心快码Comate是百度推出的一款AI辅助编程工具