不够。resource角色隐式含unlimited tablespace且允许创建存储过程、触发器等高风险对象，远超多数应用需求；生产环境应显式授予create session、create table、create view等最小必要权限，禁用resource，并清理public网络包权限、慎授dba。
创建用户时只给CONNECT和RESOURCE就够了吗？
不够。这是最常见的误判点。RESOURCE角色在Oracle中隐式包含UNLIMITED TABLESPACE，且允许创建存储过程、触发器、序列等高风险对象——这远超多数应用账号的真实需求。
- 生产环境新建应用用户，应显式授予：
CREATE SESSION（等价于CONNECT）、CREATE TABLE、CREATE VIEW等单个系统权限，而非整包角色 - 禁用
RESOURCE后，若需序列，单独授CREATE SEQUENCE；若需存储过程，再评估是否真需CREATE PROCEDURE - 检查已存在用户：执行
SELECT privilege FROM dba_sys_privs WHERE grantee = 'APP_USER'，确认无ALTER SYSTEM、DROP ANY TABLE等越权项
PUBLIC角色权限必须清理
所有用户自动继承PUBLIC权限，而默认安装中PUBLIC常被授予EXECUTE on UTL_HTTP、UTL_SMTP等网络包——这等于给任意能连库的账号开了外网出口。
- 立即执行：
REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC、REVOKE EXECUTE ON UTL_SMTP FROM PUBLIC - 检查残留：
SELECT table_name, privilege FROM dba_tab_privs WHERE grantee = 'PUBLIC' - 注意：某些老应用依赖
DBMS_LOB或DBMS_RANDOM，清理前先用SQL_TRACE捕获实际调用，避免误杀
DBA权限不能直接给运维账号
把DBA角色给日常运维账号，等于交出数据库“管理员钥匙”。真实场景中，95%的运维操作（查锁、杀会话、收集统计信息）完全可用更细粒度权限替代。
- 替代方案示例：
– 查锁：SELECT ANY TABLE+SELECTonV_$SESSION,V_$LOCK
– 杀会话：ALTER SYSTEM（仅限KILL SESSION子集，通过GRANT ALTER SYSTEM TO user WITH ADMIN OPTION控制）
– 收集统计信息：ANALYZE ANY或指定表的ANALYZE权限 - 禁止远程
SYSDBA登录：设置remote_login_passwordfile=NONE，强制DBA必须本地登录或走跳板机 - 用
V$PWFILE_USERS定期核对：确保只有SYS和极少数核心DBA在列表中
金仓/兼容库迁移时权限语义差异
迁移到金仓等Oracle兼容库时，CREATE SESSION不等于自动可连——它必须显式授予LOGIN系统权限，否则报错permission denied to create table不是权限问题，是根本没连上。
- 金仓中必须执行：
GRANT LOGIN TO app_user（Oracle里该权限隐含在CONNECT中） -
RESOURCE角色在金仓中不存在，需拆解为CREATE TABLE、CREATE SEQUENCE等独立权限 - Oracle的
SELECT_CATALOG_ROLE在金仓对应SELECT ANY DICTIONARY，但后者默认关闭，需DBA手动启用
GRANT DBA。每次加权限前，先问一句：这个操作今天发生几次？有没有日志证明它真被用到了？
