不能只靠权限控制防删用户，因回收DROP USER权限会迫使DBA用SYSDBA绕过，更危险；应结合系统级DDL触发器（AFTER DDL ON DATABASE）精准拦截DROP USER，并通过上下文变量实现安全放行。
为什么不能只靠权限控制来防删用户
oracle 的 drop user 操作默认只要拥有 dba 角色就能执行，而 dba 通常需要高权限完成日常维护。单纯回收 drop user 系统权限会导致很多合法运维无法进行（比如清理测试账号），反而促使人用 sysdba 登录绕过——这更危险。真正要防的是「非计划性、无审批的删除」，不是禁掉能力本身。
- 权限回收后，DBA 可能改用
CONNECT / AS SYSDBA执行，触发器仍可拦截 - 系统级触发器在语句解析后、执行前触发，比权限检查更早一步
- 触发器可以结合时间、IP、终端、SQL 文本做细粒度判断，权限模型做不到
创建系统级 DDL 触发器拦截 DROP USER
必须用 SYS 用户创建，且需开启数据库级别触发器支持（默认开启）。关键点在于捕获 DDL 事件类型，并精确匹配 DROP USER 动作，而不是笼统拦截所有 DROP。
- 触发器类型必须是
AFTER DDL ON DATABASE，BEFORE不可用（Oracle 限制） - 使用
ora_sysevent = 'DROP'且ora_dict_obj_type = 'USER'双重判定，避免误伤DROP TABLE等 - 必须用
RAISE_APPLICATION_ERROR中断执行，返回自定义错误码（如-20001），不能仅写日志 - 示例代码片段：
CREATE OR REPLACE TRIGGER tr_prevent_drop_user
AFTER DDL ON DATABASE
DECLARE
BEGIN
IF ora_sysevent = 'DROP' AND ora_dict_obj_type = 'USER' THEN
RAISE_APPLICATION_ERROR(-20001, 'DROP USER blocked: contact DBA team for approval');
END IF;
END;
/如何允许特定场景下删除用户
硬拦截会阻碍紧急恢复或自动化脚本，得留安全出口。常见做法是通过会话上下文或临时标记绕过，而不是关闭触发器（那等于撤防）。
- 利用
DBMS_SESSION.SET_CONTEXT设置命名空间变量，在触发器中检查：SYS_CONTEXT('my_app_ctx', 'allow_drop') = 'YES' - 删除前先执行：
EXEC DBMS_SESSION.SET_CONTEXT('my_app_ctx', 'allow_drop', 'YES'); - 触发器内加判断：
IF SYS_CONTEXT('my_app_ctx', 'allow_drop') != 'YES' THEN ... RAISE ... END IF; - 注意：上下文需提前用
CREATE CONTEXT声明，且只能由DEFINER模式调用，防止普通用户伪造
容易被忽略的绕过点和加固建议
这个触发器看似简单，但实际运行中存在几个隐蔽缺口：
-
DROP USER ... CASCADE和DROP USER ... NO CASCADE都会被捕获，没问题；但ALTER SYSTEM KILL SESSION后再删用户不会触发——因为会话已断，触发器不运行 - 如果用
expdp+impdp先导出再删用户，触发器拦不住；但这是数据迁移流程，不属于“误操作”范畴 - 触发器本身可能被
DROP TRIGGER删除，所以应限制CREATE ANY TRIGGER权限，仅保留给安全管理员 - 日志必须写入外部表或告警系统（如
AUD$或自定义审计表），不能只依赖DBMS_OUTPUT，否则看不到记录
真正在生产环境长期有效，靠的不是“写一个触发器”，而是把触发器作为整个变更控制链的一环：审批工单 → 临时放行上下文 → 操作执行 → 审计回溯。单独拎出来用，三天内就会被绕过。
