oracle不支持列级select授权，直接授表权限会暴露薪资等敏感字段；必须通过显式列列表的只读视图隔离数据，并严格回收基表权限。
直接授表权限会暴露薪资列，这是最常踩的坑
Oracle 不支持列级 GRANT SELECT，哪怕你只想要用户查 name 和 hire_date，一旦执行 GRANT SELECT ON employees TO dev_user，对方就能看到整张表所有列——包括 salary、bonus、id_card 等敏感字段。这不是配置遗漏，而是 Oracle 本身的权限模型限制（12c 及之前完全不支持；12c+ 仍无原生列级 SELECT 授权能力）。
创建显式列列表的只读视图是最稳妥的做法
视图天然隔离未包含的列，用户执行 SELECT * FROM emp_public_view 时，salary 根本不会出现在结果集中，不是被 NULL 替换，而是压根不存在。
操作要点：
- 必须显式列出需要暴露的列，严禁使用
*：例如CREATE VIEW emp_public_view AS SELECT emp_id, name, hire_date FROM employees - 授权对象只能是该视图：
GRANT SELECT ON emp_public_view TO dev_user - 确认
dev_user没有基表权限：登录后执行SELECT * FROM session_privs，输出中不应含SELECT ANY TABLE；执行SELECT * FROM session_roles，不应含RESOURCE或DBA角色 - 验证是否生效：用
dev_user登录，尝试SELECT salary FROM employees→ 报ORA-00942: table or view does not exist；查视图则正常返回三列
带 WHERE 的视图能控制行级可见性，但要注意性能和语法限制
如果还要限制“只能看本部门员工”，可以在视图定义里加 WHERE dept_id = (SELECT dept_id FROM users WHERE username = USER) 这类子查询。
但注意：
- Oracle 不允许在视图定义中直接写绑定变量（如
:dept_id），必须由应用层拼 SQL 或改用 VPD - 子查询若无索引支撑，且基表数据量大（比如百万级
employees），可能导致全表扫描，拖慢所有走该视图的查询 - 这种写法对开发透明，但 DBA 很难快速判断某次慢查询是否源于视图内部子查询
真正防住高权限用户（如 DBA）得靠 Database Vault 或 VPD
普通视图挡不住有 SELECT ANY TABLE 权限或 DBA 角色的人——他们可以直接绕过视图查基表。这时需更底层机制：
-
Database Vault能封禁 SYSTEM/DBA 对指定 Schema（如HR）的访问，连SELECT * FROM hr.employees都会被拦截 -
VPD（Virtual Private Database）策略函数可在 SQL 执行前自动注入WHERE条件，甚至支持列遮蔽（如把salary列动态替换为NULL或脱敏值），且对应用完全透明 - 两者都需要额外许可和配置，不是单纯 SQL 就能搞定；尤其 VPD 的策略函数若逻辑复杂或未绑定执行计划，容易引发隐式转换或硬解析问题
最容易被忽略的一点：权限清理比建视图更重要。很多团队花大力气写了视图，却忘了回收旧的表级授权，或者把开发者加进了 RESOURCE 角色——那视图就形同虚设。
