配置Oracle 19c统一审计模型下的用户访问监控

统一审计没启用，所有策略都白搭——不是配置细节出错，而是根子上没激活。必须先完成二进制重链接并重启数据库，否则 audit policy、dbms_audit_mgmt.init_cleanup 这些操作全都会静默失效，连个报错都不给你。

先泼盆冷水：别光盯着 V$OPTION 里显示 TRUE 就觉得万事大吉。那个返回值只说明数据库“支持”统一审计，不代表已经生效。真正要确认启用状态，得同时满足三个条件：

• SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing' 返回 TRUE；
• SELECT * FROM UNIFIED_AUDIT_TRAIL WHERE ROWNUM = 1 不报 ORA-00942，且能查到任意一行（哪怕结果集为空也成）；
• SHOW PARAMETER audit_trail 的返回值必须是 NONE（不能是 DB、XML 或者混合模式下的残留值）。

这三个条件但凡有一个不满足，说明系统仍停留在传统审计或混合模式，后续你配再多策略也是瞎子点灯白费蜡。

确认 Unified Auditing 是否真正启用

好了，确认启用后咱们来落地策略。统一审计下的“用户访问”得拆成具体动作——登录失败、查询敏感表、执行 DDL 等等，不能指望一个通用策略包打天下。得按场景选好 ACTIONS：

• 监控登录失败：CREATE AUDIT POLICY login_fail_policy ACTIONS LOGON WHENEVER NOT SUCCESSFUL
• 监控 SELECT 敏感表：CREATE AUDIT POLICY select_hr_policy ACTIONS SELECT ON hr.employees, hr.departments
• 监控所有 DDL：CREATE AUDIT POLICY ddl_policy ACTIONS CREATE ANY TABLE, DROP ANY TABLE, ALTER ANY TABLE

这里有个容易踩的坑：策略创建后必须显式启用，否则根本不会触发。举个例子：
AUDIT POLICY login_fail_policy BY ALL USERS（全库生效），或者 AUDIT POLICY select_hr_policy BY zabbix_mon, app_user（指定用户）。不执行 AUDIT POLICY 命令，策略就是一张废纸。

细粒度访问审计要用 DBMS_FGA，不是 AUDIT POLICY

如果目标更具体——比如想知道“谁在什么时候查了工资字段”，那 AUDIT POLICY 就无能为力了，它不捕获列级读取。这时候必须请出 DBMS_FGA。但注意：FGA 和统一审计是并行机制，不是子集关系。

• DBMS_FGA.ADD_POLICY 的 audit_column 参数必须与表中实际列名的大小写完全一致（例如表定义是 SALARY，就不能写成 'salary'）；
• 策略是否触发，取决于执行计划是否物理读取该列——如果查询走索引覆盖或者函数索引跳过了列访问，FGA 就不会记录；
• 还有一条关键前提：SHOW PARAMETER audit_trail 不能是 NONE，否则 DBMS_FGA 加策略会静默失败。统一审计启用后，FGA 的日志默认进入 UNIFIED_AUDIT_TRAIL，但策略本身的创建和管理仍由 FGA 独立控制。

查不到日志？优先验证这三处

策略配好了，操作也做了，回头一查日志空空如也？别急着怀疑数据库坏了，问题大概率卡在以下环节：

• 执行操作的用户是否真有对应权限？比如 DROP ANY TABLE 策略只捕获拥有该系统权限的用户去删除别人的表；如果用户只是删自己 schema 下的表，需要单独配 ACTIONS DROP ON schema.table。
• 操作是否落在策略定义的精确对象上？ACTIONS SELECT ON hr.employees 不会捕获 SELECT * FROM hr.emp_backup，对象名得一字不差。
• 策略的启用范围是否覆盖了当前会话用户？AUDIT POLICY xxx BY SYSTEM 对 SCOTT 登录的操作完全无效。

统一审计的日志默认存在 UNIFIED_AUDIT_TRAIL 视图里，但这个视图本身依赖底层模块的加载——没走重链接，连视图都不存在，更别说查数据了。所以回过头来，第一件事还是确认二进制重链接是否真的做完了。