oracle中无“仅dml”现成角色，授create table即开放ddl；须显式按schema.object授予select/insert/update/delete，禁用any权限、元数据视图及resource角色，并严格限制表空间配额与会话权限。
只给DML权限不等于不给CREATE TABLE系统权限
Oracle里没有“仅DML”的现成角色。db_datareader和db_datawriter是SQL Server的概念，Oracle中不存在——直接授CREATE TABLE就等于开了DDL口子。关键不是“授什么”，而是“不授哪些”+“限制所有权”。
常见错误现象：GRANT CREATE TABLE TO user_a后，用户能建表也能删自己建的表，因为默认成为对象owner；GRANT SELECT ANY TABLE看似只读，实则隐含跨schema访问能力，远超DML范围。
- 必须拒绝所有ANY级别系统权限：
DROP ANY TABLE、ALTER ANY TABLE、CREATE ANY TABLE等 - 不授予
CREATE TABLE系统权限——否则用户可在任意有配额的schema下建表，且自动获得DROP权 - 若业务真需要建表（极少见），应由DBA代建，并用
ALTER TABLE ... OWNER TO admin_role移交所有权，使用户无法DROP
按表粒度显式授予SELECT/INSERT/UPDATE/DELETE
Oracle的对象权限必须精确到schema.object，不能靠库级或角色兜底。哪怕只操作一张表，也得单独授权四次。
实操命令示例（以HR.EMPLOYEES为例）：
GRANT SELECT ON HR.EMPLOYEES TO app_user; GRANT INSERT ON HR.EMPLOYEES TO app_user; GRANT UPDATE ON HR.EMPLOYEES TO app_user; GRANT DELETE ON HR.EMPLOYEES TO app_user;
- 必须用
ON HR.EMPLOYEES写全schema名，省略schema会报错 - 如果目标表在
SCOTT下，不能写GRANT SELECT ON EMPLOYEES——Oracle会默认查当前用户下的同名对象 - 批量授权可用脚本生成：
SELECT 'GRANT SELECT, INSERT, UPDATE, DELETE ON ' || OWNER || '.' || TABLE_NAME || ' TO app_user;' FROM DBA_TABLES WHERE OWNER = 'HR' AND TABLE_NAME IN ('EMPLOYEES', 'DEPARTMENTS');
必须阻断元数据访问和执行能力
只控DML不拦元数据，等于留后门。用户可通过ALL_TAB_COLUMNS、USER_OBJECTS反推表结构，甚至调用UTL_HTTP等包发起外联攻击。
- 禁止查看定义：
DENY SELECT ON SYS.ALL_TAB_COLUMNS TO app_user不行——Oracle用REVOKE而非DENY，正确写法是REVOKE SELECT ON ALL_TAB_COLUMNS FROM app_user（但更稳妥的是不授任何SELECT_CATALOG_ROLE） - 禁用系统视图访问：
REVOKE SELECT ON SYS.V_$SESSION FROM app_user（防止查当前连接） - 撤回执行权限：
REVOKE EXECUTE ANY PROCEDURE FROM app_user，并确认未被CONNECT或RESOURCE角色隐式赋予 - 检查是否残留：
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'APP_USER'，确保没意外继承DBA或EXP_FULL_DATABASE
表空间配额与连接权限的最小化
用户能连上、能查表，不代表安全。两个常被跳过的硬性条件：无CREATE SESSION进不来，无表空间配额建不了临时段（哪怕只做SELECT也可能触发排序）。
- 基础连接权：
GRANT CREATE SESSION TO app_user——没这句，其他权限全无效 - 表空间配额必须严格限定：
ALTER USER app_user QUOTA 10M ON USERS，而非UNLIMITED TABLESPACE（后者等于开放存储层写入） - 避免用
RESOURCE角色：GRANT RESOURCE TO app_user会顺带授予CREATE TRIGGERCREATE SEQUENCE等无关DDL权限 - 验证是否生效：用
app_user登录后执行SELECT * FROM SESSION_ROLES，确认只看到CONNECT和自定义角色，无RESOURCE或DBA
真正难的不是写对那几条GRANT，而是每次新增表或调整业务逻辑时，都要同步更新对象权限列表，并复查DBA_TAB_PRIVS里有没有漏掉的INSERT或多余的EXECUTE。权限配置一旦松动，审计日志里就很难追溯是哪次变更埋的雷。
