应弃用resource角色，显式授予create session等最小权限，用quota限制表空间，脚本化精确授对象权限，连接池场景可用identified by values同步密码哈希，定期审计回收冗余权限。
为什么直接用 create user + grant connect, resource 不行
因为 resource 角色在 oracle 12c 及以后版本中默认包含 unlimited tablespace 和隐式授予 create type、create cluster 等 20+ 个权限，远超 web 应用 crud 所需。你给的不是“最小权限”，是“历史遗留宽泛权限”。
实操建议：
- 彻底弃用
RESOURCE角色——它不是为最小化设计的，而是为向后兼容保留的 - 只显式授予应用真正需要的系统权限，例如：
CREATE SESSION、SELECT ANY DICTIONARY（仅当应用含元数据查询） - 用
ALTER USER ... QUOTA 5M ON users替代UNLIMITED TABLESPACE，防止表空间耗尽
如何按业务模块拆分对象权限而非全库授权
应用通常只读写固定几张表，但很多人习惯性 GRANT SELECT, INSERT, UPDATE ON schema.* TO app_user —— Oracle 不支持通配符批量授对象权限，这种写法会报错 ORA-00942: table or view does not exist。
正确做法是脚本化生成精确授权语句：
SELECT 'GRANT SELECT, INSERT, UPDATE ON ' || owner || '.' || table_name || ' TO app_user;'
FROM dba_tables
WHERE owner = 'APP_SCHEMA'
AND table_name IN ('ORDERS', 'ORDER_ITEMS', 'CUSTOMERS');
关键点：
- 避免用
GRANT ALL ON ...，即使只读场景也应明确写SELECT - 触发器、序列、视图等对象需单独授权，例如：
GRANT SELECT ON APP_SCHEMA.ORDER_SEQ TO app_user - 如应用使用存储过程封装逻辑，优先授
EXECUTE权限而非底层表权限，进一步收窄面
连接池场景下 ALTER USER ... IDENTIFIED BY VALUES 的真实用途
很多 Java 应用用 HikariCP 或 UCP 连接池，密码硬编码或存于配置中心。若频繁重置密码，连接池可能因缓存旧凭据持续失败，报错 ORA-01017: invalid username/password。
这时不要急着改应用配置，可利用 Oracle 密码哈希复用机制：
- 先在测试库用已知密码创建用户：
CREATE USER app_user IDENTIFIED BY mypass123; - 查出其密码哈希：
SELECT password FROM dba_users WHERE username = 'APP_USER'; - 在生产库执行：
ALTER USER app_user IDENTIFIED BY VALUES 'F894844C34402B67'（填上查到的哈希值）
这样应用无需重启、不改配置，就完成了密码同步。注意：该方式仅适用于传统密码（非 Oracle 12c+ 的强密码语法），且要求两端数据库兼容同一加密算法（如 11g 默认用 DES，12c+ 默认用 SHA-2）。
审计与权限回收的两个易忽略点
最小权限不是一劳永逸。常被跳过的实际环节：
-
DBA_SYS_PRIVS视图里残留的临时调试权限（比如曾为排查加过SELECT ANY TABLE，事后没清理）——建议每月跑一次检查：SELECT * FROM dba_sys_privs WHERE grantee = 'APP_USER' AND privilege NOT IN ('CREATE SESSION', 'SELECT ANY DICTIONARY') - 角色嵌套导致权限泄露：如果
APP_USER被授予了某个自定义角色，而该角色又包含EXP_FULL_DATABASE，那导出权限就意外开放了。用SELECT * FROM role_role_privs WHERE role = 'YOUR_ROLE'逐层展开验证
真正的最小化，是权限随功能上线而增、随需求下线而删，而不是建库时设一次就再不管。
