开发测试账号严禁授予drop table等高危权限，须严格遵循最小权限原则：仅授create session、create table及必要对象权限，禁用drop any table、alter system等系统级权限；生产账号必须启用密码策略（如failed_login_attempts 3）、禁用远程sys登录，并通过独立角色（如dev_app_role/prod_readonly_role）、分离tns服务名与监听器ip白名单实现四层隔离。
开发测试账号不能有DROP TABLE权限
开发测试环境常因误操作导致表被删，但生产环境绝不能容忍这种风险。Oracle默认角色CONNECT和RESOURCE都隐含CREATE TABLE，但不自动带DROP——关键在于别把DBA或DELETE_CATALOG_ROLE这类高危角色授给开发账号。
- 测试账号只授予
CREATE SESSION+CREATE TABLE+SELECT ANY TABLE（如需查全库） - 禁用
DROP ANY TABLE、ALTER SYSTEM、GRANT ANY PRIVILEGE等系统级权限 - 若需清理测试数据，用
TRUNCATE代替DROP，并限制在指定schema内执行
生产账号必须启用密码策略与登录限制
生产账号一旦泄露，后果远超测试环境。Oracle 12c及以上版本支持细粒度密码策略，但很多人只设长度，忽略锁定机制。
- 用
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1防暴力破解 - 禁止生产账号使用
IDENTIFIED BY VALUES方式绕过密码复杂度校验 - 对DBA账号启用
SEC_CASE_SENSITIVE_LOGON=TRUE，避免大小写混淆导致的弱口令 - 生产实例中，
sys账号应禁用远程登录，仅允许本地sqlplus / as sysdba
用同名角色区分环境权限边界
直接给用户授予权限难维护，尤其当同一人既参与开发又需临时查生产数据时。角色是解耦的关键。
- 创建
dev_app_role和prod_readonly_role两个独立角色，不交叉授权 - 开发账号只
GRANT dev_app_role TO dev_user；生产只读账号只GRANT prod_readonly_role TO report_user - 角色内不包含
EXECUTE ANY PROCEDURE，敏感过程单独授权，且限定调用者IP范围（通过DBMS_NETWORK_ACL_ADMIN控制） - 避免角色嵌套过深，Oracle对嵌套层级有限制（默认20层），超限会导致
ORA-01928
连接串和服务名层面做硬隔离
光靠账号权限不够，得让开发根本连不上生产库。tnsnames.ora里别混写，更别用通配符别名。
- 开发用
ORCL_DEV，测试用ORCL_TEST，生产用ORCL_PROD，三者监听端口分离（如1521/1522/1523） - 生产TNS条目中显式配置
SERVER=DEDICATED，避免共享服务器模式下会话复用带来的越权风险 - 在监听器配置
listener.ora里用HOST绑定生产IP，拒绝非运维网段访问 - Java应用里用不同
spring.datasource.url配置，严禁用占位符拼接环境名（如jdbc:oracle:thin:@${env}.example.com:1521/orcl）
GRANT语句漏掉WITH ADMIN OPTION，可能让开发账号意外获得转授权；而监听器没设HOST白名单，哪怕账号权限再严，也能从跳板机直连生产。权限隔离不是单点配置，而是账号、角色、网络、连接串四层卡口同时生效。
