sql审计不能替代权限控制，仅用于事后追溯；必须结合细粒度权限管控（如存储过程封装+审批校验）与统一审计策略，同时严格保护审计日志访问权限。
不能靠sql审计本身确保授权，它只记录“谁删了”，不验证“能不能删”。 审计是事后追溯手段，不是事前拦截机制。真要确保合规授权，得靠权限控制 + 审计组合落地。
Oracle中启用DELETE操作的细粒度审计
直接对目标表开启AUDIT DELETE ON schema.table是最常用方式，但要注意：
• 必须用具有ALTER ANY AUDIT POLICY或ADMINISTER AUDIT POLICY权限的用户执行（通常是DBA或SECURITY_ADMIN角色）
• BY ACCESS比BY SESSION更精确，每次DELETE都记一条日志，但日志量大
• 审计记录默认写入SYS.AUD$，查询需SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE
• 如果用统一审计（Unified Audit），得先启用UNIFIED_AUDIT_TRAIL，再创建审计策略：CREATE AUDIT POLICY del_policy ACTIONS DELETE ON app.orders;
为什么v$session和v$sql在触发器里常查不到当前SQL？
你看到的博客里那个触发器：FROM v$sql q, v$session s WHERE s.audsid = (SELECT USERENV('SESSIONID') FROM DUAL) AND s.sql_id = q.sql_id，实际运行时大概率查不到结果，因为：
• v$session中sql_id字段在DML执行后可能已更新为新语句，旧DELETE的sql_id早已被覆盖
• v$sql缓存的是解析后的SQL，而触发器执行时原SQL可能已不在共享池中
• 更可靠的做法是用ORA_LOGIN_USER、SYS_CONTEXT('USERENV', 'IP_ADDRESS')和SYSDATE，放弃捕获完整SQL文本；如真需要SQL，应改用统一审计策略，它能稳定记录sql_text字段
把“授权检查”真正落到数据库权限层
合规授权必须前置到权限模型里，而不是指望审计“发现违规后再处理”：
• 不要给业务用户直接DELETE ANY TABLE或DELETE ON app.orders，而是通过存储过程封装删除逻辑
• 存储过程中加入检查：查app.auth_approval表确认该删除请求已被审批人status = 'APPROVED'且expire_date > SYSDATE
• 授权时只给EXECUTE ON app.delete_order_proc，不给表级DELETE权限
• 配合应用层单点登录凭证（如OAuth token）传入APP_CONTEXT，在存储过程中用SYS_CONTEXT('APP_CTX', 'request_id')关联审批流水号
• 这样审计记录里出现的就不是裸DELETE语句，而是CALL app.delete_order_proc(12345)，天然绑定审批上下文
最易被忽略的一点：审计日志本身也是敏感数据，DBA_AUDIT_TRAIL视图如果被普通用户查到，等于把“谁删过什么”全暴露了。务必回收SELECT ANY DICTIONARY，改用专用视图+行级安全策略（RLS）控制审计数据可见范围。
