开发账号不得留存生产库，因哪怕只读权限也可能拖垮主库或误执行危险操作；必须严格分离环境账号、锁定开发账号、按最小权限授予权限并启用统一审计留痕。
开发账号为什么不能在生产库上留着
开发账号在生产库上留着，等于把钥匙挂在门把手上。哪怕只读权限，也可能被误执行 SELECT * FROM users 拖垮主库；更别说有人顺手连错环境跑了个 DROP TABLE。真实事故里，80% 的线上数据异常源于开发账号未清理或权限未回收。
实操建议：
- 上线前必须执行自动化检查：
SELECT user, host FROM mysql.user WHERE user = 'dev_user';（注意：这是 MySQL 示例，Oracle 对应为SELECT username, account_status FROM dba_users WHERE username = 'DEV_USER';），扫描所有生产实例，脚本失败即阻断发布 - 禁止跨环境复用账号名——
dev_user和prod_app必须是两个独立账号，不能靠密码不同区分 - Oracle 中显式限定登录来源：
CREATE USER dev_user IDENTIFIED BY "Pass123!" ACCOUNT LOCK;，建完立刻锁住，避免误激活
Oracle 三环境账号该怎么建才安全
不是“建一个用户，改三次密码”，而是每个环境用独立用户、独立表空间、独立 profile，且权限粒度必须按实际 SQL 行为反推。
常见错误现象：
- 开发库用
CREATE USER app_dev IDENTIFIED BY ...后直接授CONNECT+RESOURCE，结果迁移时发现应用其实只用SELECT和INSERT，但测试阶段因权限过大掩盖了真实依赖 - 生产账号没设
QUOTA，导致建临时表或索引时报ORA-01950: no privileges on tablespace 'USERS' - 没单独建 profile，密码策略全靠 DEFAULT，无法控制失败登录次数或密码有效期
正确做法示例：
CREATE USER app_prod IDENTIFIED BY "StrongPass2026!" DEFAULT TABLESPACE app_data TEMPORARY TABLESPACE temp QUOTA 500M ON app_data; CREATE PROFILE prod_profile LIMIT FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LIFE_TIME 90 PASSWORD_REUSE_MAX 5; ALTER USER app_prod PROFILE prod_profile;
然后只授最小集：
GRANT CREATE SESSION TO app_prod;-
GRANT SELECT, INSERT, UPDATE ON app_prod.orders TO app_prod;（注意：Oracle 默认不隐式授予自己 schema 内对象的 DML 权限） - 绝对不授
DBA、EXP_FULL_DATABASE、UNLIMITED TABLESPACE
如何防止跨环境连接字符串泄露凭证
看到 jdbc:oracle:thin:@//db:1521/ORCL 配套的 app_dev/weakpass 出现在 config.yml 或 .env 里，基本等于把凭证塞进公开仓库。扫描工具一跑，dev_user 密码就进了黑客的字典。
实操建议：
- 开发环境用本地密钥管理器：macOS 上用
security find-generic-password -s oracle-dev-cred -w，Windows 上用cmdkey /list+ 应用层调用 - 生产环境强制走配置中心：Vault 中存
app_prod凭证，应用启动时通过 API 拉取，不落地、不缓存明文 - CI/CD 流水线中禁用
.env提交，用git secrets预检钩子拦截含user=、password=、jdbc:oracle的行
权限变更怎么留痕又可控
DBA 手动执行 GRANT SELECT ON orders TO app_finance 后没记录，过两周谁也说不清为什么 app_prod 突然有了 FILE 权限——而这个权限恰好被新上线的导出功能滥用，导致敏感文件泄露。
Oracle 原生审计能力有限，必须组合使用：
- 开启统一审计（Unified Auditing）：
AUDIT GRANT ANY PRIVILEGE BY app_dba;，确保每条GRANT/REVOKE写入UNIFIED_AUDIT_TRAIL - 配合 DBMS_AUDIT_MGMT 管理审计日志生命周期，避免日志膨胀拖慢查询
- 所有权限变更必须走变更窗口（如每周三 22:00–23:00），并关联 Jira 工单号与操作人邮箱，写入审计备注字段
真正容易被忽略的是继承关系：比如 app_dev 被加进了 dev_role，而 dev_role 又继承了 dba_role —— 这种嵌套授权在权限回收时极易漏掉，必须定期用 SELECT * FROM role_role_privs 和 role_tab_privs 扫描。
