创建最小权限用户需先执行CREATE USER和GRANT CREATE SESSION，再显式授予目标视图的SELECT权限，禁用RESOURCE等隐含宽泛角色，逐条授权且禁止SELECT ANY TABLE或SELECT_CATALOG_ROLE，最后通过实际连接测试验证权限隔离效果。
创建用户时禁用默认权限
oracle 默认不会给新用户任何对象访问权限，但新手常误以为 create user 后就能查视图——其实连 select 权限都没有，更别说连接数据库。必须显式授权才能登录和查询。
执行以下语句创建最小权限用户：
CREATE USER v_reader IDENTIFIED BY "StrongPass123!"; GRANT CREATE SESSION TO v_reader;
注意：CREATE SESSION 是登录前提，没它会报 ORA-01045: user V_READER lacks CREATE SESSION privilege；但此时仍无法查任何视图。
只授予特定视图的 SELECT 权限
不能用 SELECT ANY TABLE 或 SELECT_CATALOG_ROLE，那会绕过限制。必须对每个目标视图单独授权，且只能是 SELECT（不带 WITH GRANT OPTION）。
- 如果视图
sales_summary在hr用户下：执行GRANT SELECT ON hr.sales_summary TO v_reader; - 若视图依赖底层表的列级权限（如含虚拟列或函数），需确认视图定义中引用的对象本身可被
hr访问（即hr创建视图时已拥有对应权限） - 多个视图要逐条授权，Oracle 不支持
GRANT SELECT ON ALL VIEWS IN SCHEMA hr这类批量语法
验证权限是否真正受限
切勿仅靠“没授其他权限”就认为安全。必须用该用户实际测试：
CONNECT v_reader/StrongPass123!; SELECT * FROM hr.sales_summary; -- 应成功 SELECT * FROM hr.employees; -- 应报 ORA-00942: table or view does not exist SELECT * FROM dba_users; -- 应报 ORA-00942（即使有同名视图，也不在搜索路径里）
常见疏漏点：
- 用户被意外授予了
RESOURCE角色（隐含UNLIMITED TABLESPACE和部分系统权限） - 视图定义中用了
SYSDATE、USER等函数，但用户无SELECT_CATALOG_ROLE仍可执行——这不是漏洞，是 Oracle 对内置函数的宽松处理 - DBA 忘记回收
SELECT ANY DICTIONARY等高危权限（如果之前临时加过）
避免通过角色间接获得额外权限
角色可能携带未察觉的权限。检查该用户是否被赋予了非必要角色：
SELECT granted_role FROM dba_role_privs WHERE grantee = 'V_READER';
如果返回 CONNECT，问题不大（Oracle 21c+ 的 CONNECT 仅含 CREATE SESSION）；但如果返回 SELECT_CATALOG_ROLE 或自定义角色，必须收回：
REVOKE SELECT_CATALOG_ROLE FROM v_reader;
关键点：视图访问权限必须直接授予用户，而非通过角色中转——否则 DBA 很难审计清楚实际权限边界。
真正的难点不在创建，而在持续确保没有隐式路径泄露数据。比如某个 DBA 为调试临时给 v_reader 授了 SELECT 权限，忘了回收；或者视图重建后依赖关系变更，导致底层表权限失效却没人检查。
