Oracle 19c统一审计（Unified Auditing）配置与运维实践

一、适用范围

本文适用于Oracle Database 19c，包括：

• NON_CDB-非CDB架构数据库
• 多租户架构-CDB与PDB多租户数据库
• 从早期版本升级到19c的数据库
• 新上线的Oracle 19c数据库

不同数据库可能处于传统审计、混合审计或者纯统一审计模式。实施审计策略前，应先确认数据库当前使用的审计模式、数据库版本等基本信息。

二、审计的作用

数据库审计是指记录数据库中安全相关操作的信息，包括操作主体、操作时间、客户端来源、操作对象、SQL语句、执行结果和使用的权限等。

审计主要用于：

• 满足监管和合规要求
• 监控高权限用户和敏感账号
• 发现异常登录与可疑数据访问
• 跟踪用户、角色和权限变更
• 调查安全事件和误操作
• 为安全分析提供可追溯证据

审计不能替代身份认证、访问控制、最小权限和数据加密。它是数据库纵深防御体系中的重要组成部分。

审计会增加数据库需要完成的工作量并占用存储空间。审计范围应围绕安全目标和合规要求精准配置，避免无差别审计全部对象及高频操作。

三、Oracle 19c审计机制

Oracle 19c主要提供以下审计机制。

3.1 强制审计

Oracle会强制审计部分安全敏感操作。这类审计不能通过普通审计配置关闭，典型内容包括部分数据库启动、关闭和审计配置变更等操作。

强制审计记录的保存位置与数据库当前的审计模式有关：

• 混合模式下，部分强制审计记录仍可能进入传统审计线索；
• 纯统一审计模式下，审计信息通过统一审计体系管理；
• 当数据库无法写入内部统一审计表时，记录可能进入操作系统溢出文件。

3.2 传统审计

传统审计也称标准审计，通过AUDIT和NOAUDIT语句配置，并由AUDIT_TRAIL等初始化参数控制审计记录的保存位置。

常见的AUDIT_TRAIL参数值包括：

参数值	说明
NONE	不启用普通传统审计，但不能关闭强制审计
DB	将传统审计记录写入数据库审计线索，如SYS.AUD$
DB, EXTENDED	在数据库审计线索中额外保存SQL文本和绑定变量信息
OS	将传统审计记录写入操作系统文件
XML	将传统审计记录写入XML格式的操作系统文件
XML, EXTENDED	在XML审计文件中增加SQL文本和绑定变量信息

AUDIT_TRAIL是静态参数，修改后通常需要重启数据库。在纯统一审计模式下，AUDIT_TRAIL不再控制统一审计记录。

传统审计的操作系统文件位置通常由AUDIT_FILE_DEST控制。管理用户传统审计还需要结合AUDIT_SYS_OPERATIONS判断。

3.3 统一审计

Oracle Database 12c开始引入统一审计。统一审计使用统一的策略模型和记录格式，将多个审计来源的信息集中到统一审计线索中。

统一审计可以覆盖或整合以下类型的活动：

• SQL语句和系统权限使用
• 对象访问
• 用户、角色和权限管理
• 细粒度审计FGA
• Oracle Data Pump
• Oracle Recovery Manager
• SQL*Loader直接路径加载
• Oracle Database Vault
• Oracle Label Security
• Oracle Real Application Security

统一审计记录通过UNIFIED_AUDIT_TRAIL视图查询。底层审计数据由AUDSYS模式管理，不应直接查询、删除或修改底层内部表。

3.4 细粒度审计

细粒度审计（Fine-Grained Auditing，FGA）通过DBMS_FGA配置，可以按照敏感列、访问条件和SQL操作类型生成审计记录。

FGA适合以下场景：

• 访问特定敏感列时才审计；
• 查询结果满足特定业务条件时才审计；
• 仅审计SELECT、INSERT、UPDATE或DELETE中的特定操作；
• 记录SQL文本、绑定变量和对象访问上下文；
• 在触发审计条件时调用事件处理程序。

启用统一审计后，可以通过UNIFIED_AUDIT_TRAIL查询FGA产生的审计记录。

3.5 基于值的业务审计

如果需要保存业务字段修改前后的具体值，可以使用数据库触发器或应用审计表实现。

需要区分：

• 统一审计主要记录“谁在何时执行了什么操作”
• FGA主要根据列和条件记录敏感访问
• 触发器可以保存特定业务字段的OLD和NEW值

对业务表配置审计触发器前，应评估事务性能、异常处理、递归操作和审计表保护等问题。

四、混合审计与纯统一审计

Oracle 19c中的“统一审计”包含两种运行方式：混合审计和纯统一审计。

4.1 混合审计模式

混合模式同时支持传统审计和统一审计：

• 传统审计配置继续生效；
• 传统审计记录进入SYS.AUD$、OS、XML或其他传统位置；
• 统一审计策略生成的记录进入统一审计线索；
• AUDIT_TRAIL、AUDIT_FILE_DEST和AUDIT_SYS_OPERATIONS等参数仍有作用。

新创建的Oracle 19c数据库通常默认使用混合模式，并启用预定义策略ORA_SECURECONFIG和ORA_LOGON_FAILURES。从早期版本升级的数据库不一定自动启用这些策略，应以数据字典查询结果为准。

4.2 纯统一审计模式

纯统一审计模式只使用统一审计体系：

• 传统审计被关闭；
• AUDIT_TRAIL参数不再控制统一审计；
• 只有统一审计策略和强制审计产生新的统一审计记录；
• 原传统审计线索中的历史记录不会自动消失，仍需根据保留策略归档和清理。

对于Linux和Unix平台，启用纯统一审计通常需要停止数据库并重新链接Oracle可执行文件，例如：

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME

随后需要重启数据库和监听。RAC非共享Oracle Home环境需要在每个节点执行相应操作。Windows平台的处理方式不同，应严格参照当前19c补丁版本对应的Oracle官方文档。

该操作涉及数据库停机和ORACLE_HOME变更，实施前必须：

1. 备份ORACLE_HOME及相关配置；
2. 核实现有传统审计策略；
3. 将传统审计要求转换为统一审计策略；
4. 在测试或准生产环境先进行技术验证；
5. 准备回退方案；
6. 在维护窗口执行。

五、检查当前审计模式

5.1 查询纯统一审计状态

SQL>SELECT parameter,
       value
FROM   v$option
WHERE  parameter = 'Unified Auditing';

结果解释：

• TRUE：已经启用纯统一审计，传统审计关闭；
• FALSE：未启用纯统一审计，数据库可能使用传统审计或混合审计；
• FALSE不等于数据库没有任何审计。

5.2 查询传统审计参数

SQL>SELECT name,
       value,
       display_value,
       isdefault,
       issys_modifiable
FROM   v$parameter
WHERE  name IN (
           'audit_trail',
           'audit_file_dest',
           'audit_sys_operations',
           'audit_syslog_level'
       )
ORDER BY name;

在纯统一审计模式下，AUDIT_TRAIL参数与统一审计记录的生成无关；在混合模式下，该参数仍控制传统审计线索。

5.3 查询已启用的统一审计策略

SQL>SELECT policy_name,
       enabled_option,
       entity_name,
       entity_type,
       success,
       failure
FROM   audit_unified_enabled_policies
ORDER BY policy_name, entity_name;

5.4 查询策略定义

SQL>SELECT policy_name,
       audit_option,
       audit_option_type,
       object_schema,
       object_name
FROM   audit_unified_policies
ORDER BY policy_name, audit_option;

综合判断时应同时检查：

1. V$OPTION中的纯统一审计状态；
2. 传统审计参数；
3. 已启用的统一审计策略；
4. 实际审计记录保存位置。

六、预定义统一审计策略

6.1 ORA_SECURECONFIG

ORA_SECURECONFIG用于审计常见的安全配置操作，例如：

• 用户创建和删除；
• 角色及权限授予；
• 审计配置变更；
• 部分高风险系统权限使用；
• 外部作业和程序对象管理。

6.2 ORA_LOGON_FAILURES

ORA_LOGON_FAILURES用于记录失败登录，不记录所有成功登录。

可以检查策略是否已启用：

SQL>SELECT policy_name,
       entity_name,
       success,
       failure
FROM   audit_unified_enabled_policies
WHERE  policy_name IN (
           'ORA_SECURECONFIG',
           'ORA_LOGON_FAILURES'
       )
ORDER BY policy_name;

如果确认需要启用失败登录审计，可以使用：

SQL>AUDIT POLICY ORA_LOGON_FAILURES
WHENEVER NOT SUCCESSFUL;

启用或修改策略前，应核对现有配置，避免重复审计产生不必要的记录。

七、审计管理角色

统一审计通过角色分离审计配置和审计查询职责。

7.1 AUDIT_ADMIN

AUDIT_ADMIN主要用于：

• 创建、修改和删除审计策略；
• 启用或停用审计策略；
• 管理和清理审计线索；
• 配置审计归档时间。

7.2 AUDIT_VIEWER

AUDIT_VIEWER主要用于：

• 查询统一审计记录；
• 查看审计策略和审计结果；
• 生成审计分析报告。

建议将策略管理和审计查看权限授予不同人员，避免长期使用SYS执行日常审计管理。

八、创建和管理统一审计策略

8.1 审计敏感对象访问

以下示例审计APP.CUSTOMER表的查询、修改和删除操作：

SQL>CREATE AUDIT POLICY app_sensitive_data_pol
    ACTIONS SELECT ON app.customer,
            UPDATE ON app.customer,
            DELETE ON app.customer;

将策略应用到指定用户：

AUDIT POLICY app_sensitive_data_pol
BY app_user;

停用策略：

SQL>NOAUDIT POLICY app_sensitive_data_pol
BY app_user;

删除策略前，应先确认策略已经停用：

SQL>DROP AUDIT POLICY app_sensitive_data_pol;

8.2 审计系统权限使用

SQL>CREATE AUDIT POLICY user_admin_pol
    PRIVILEGES CREATE USER,
               ALTER USER,
               DROP USER,
               GRANT ANY ROLE,
               GRANT ANY PRIVILEGE;

SQL>AUDIT POLICY user_admin_pol;

不指定BY或EXCEPT时，策略的实际作用范围应结合所在容器及Oracle语法规则确认。

8.3 仅审计失败操作

AUDIT POLICY user_admin_pol
WHENEVER NOT SUCCESSFUL;

8.4 仅审计成功操作

SQL>AUDIT POLICY user_admin_pol
WHENEVER SUCCESSFUL;

统一审计策略在被审计用户建立新会话后生效。如果用户在策略启用前已经登录，应让该用户重新连接数据库后再验证。

九、CDB与PDB中的统一审计

多租户环境中的统一审计策略可以分为：

• 本地策略；
• CDB公共策略；
• Application Common策略。

9.1 本地审计策略

本地策略只适用于当前容器。在PDB中省略CONTAINER时，默认通常为CONTAINER=CURRENT。

SQL>ALTER SESSION SET CONTAINER = APP_PDB;

SQL>CREATE AUDIT POLICY local_app_pol
    ACTIONS SELECT ON app.customer,
            UPDATE ON app.customer
    CONTAINER = CURRENT;

SQL>AUDIT POLICY local_app_pol BY app_user;

9.2 CDB公共审计策略

公共策略必须在CDB$ROOT中由具有相应权限的公共用户创建：

SQL>ALTER SESSION SET CONTAINER = CDB$ROOT;

SQL>CREATE AUDIT POLICY common_admin_pol
    PRIVILEGES CREATE ANY TABLE,
               DROP ANY TABLE
    CONTAINER = ALL;

SQL>AUDIT POLICY common_admin_pol BY c##sec_admin;

公共策略只能应用于符合公共对象、公共用户和公共角色规则的审计配置，不能使用一个公共策略直接审计所有PDB中的本地用户。

9.3 查询不同容器的记录

在PDB内，可以查询：

SQL>SELECT *
FROM   unified_audit_trail;

在CDB$ROOT中查看各容器记录，应查询：

SQL>SELECT con_id,
       event_timestamp,
       dbusername,
       action_name,
       object_schema,
       object_name,
       return_code
FROM   cdb_unified_audit_trail
ORDER BY event_timestamp DESC;

生产查询建议明确时间范围，避免对大量历史审计记录进行无条件全表查询。

十、查询统一审计记录

常用查询示例：

SQL>SELECT event_timestamp,
       dbusername,
       userhost,
       os_username,
       client_program_name,
       action_name,
       object_schema,
       object_name,
       sql_text,
       return_code,
       unified_audit_policies,
       con_id
FROM   unified_audit_trail
WHERE  event_timestamp >= SYSTIMESTAMP - INTERVAL '1' DAY
ORDER BY event_timestamp DESC;

其中：

• EVENT_TIMESTAMP：事件发生时间；
• DBUSERNAME：数据库用户名；
• USERHOST：客户端主机；
• ACTION_NAME：执行的数据库操作；
• OBJECT_SCHEMA、OBJECT_NAME：被访问对象；
• SQL_TEXT：相关SQL文本；
• RETURN_CODE：返回码，0通常表示成功；
• UNIFIED_AUDIT_POLICIES：命中的审计策略；
• CON_ID：容器编号。

查询失败登录：

SQL>SELECT event_timestamp,
       dbusername,
       userhost,
       os_username,
       client_program_name,
       return_code
FROM   unified_audit_trail
WHERE  action_name = 'LOGON'
AND    return_code <> 0
ORDER BY event_timestamp DESC;

查询高权限用户操作：

SQL>SELECT event_timestamp,
       dbusername,
       action_name,
       object_schema,
       object_name,
       sql_text,
       return_code
FROM   unified_audit_trail
WHERE  dbusername IN ('SYS', 'SYSTEM')
ORDER BY event_timestamp DESC;

是否能看到某项SYS操作，仍取决于强制审计范围、审计模式和已启用的审计策略，不能简单认为所有SYS操作都会被完整记录。

十一、细粒度审计示例

以下示例在访问敏感列且满足指定条件时生成FGA记录：

SQL>BEGIN
    DBMS_FGA.ADD_POLICY(
        object_schema   => 'APP',
        object_name     => 'CUSTOMER_ACCOUNT',
        policy_name     => 'FGA_HIGH_BALANCE',
        audit_condition => 'BALANCE >= 100000',
        audit_column    => 'ID_CARD_NO,BANK_ACCOUNT',
        statement_types => 'SELECT,UPDATE',
        enable          => TRUE
    );
END;
/

删除FGA策略：

SQL>BEGIN
    DBMS_FGA.DROP_POLICY(
        object_schema => 'APP',
        object_name   => 'CUSTOMER_ACCOUNT',
        policy_name   => 'FGA_HIGH_BALANCE'
    );
END;
/

FGA条件和敏感列必须结合实际数据结构设计，并在测试环境验证是否会产生过多记录。

十二、统一审计记录的存储机制

Oracle 19c通常将统一审计记录直接写入AUDSYS模式下受保护的内部关系表，并通过UNIFIED_AUDIT_TRAIL视图提供查询。

需要注意：

• 不要直接对AUDSYS底层审计表执行DML或DDL；
• 不要直接使用DELETE或TRUNCATE清理统一审计底层表；
• 数据库无法写入内部表时，可能产生操作系统溢出文件；
• 溢出文件通常位于$ORACLE_BASE/audit相关目录；
• DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL从Oracle 12.2开始已废弃，不应作为19c常规运维操作。

应持续监控：

• 审计记录每日增长量；
• 审计相关表空间增长；
• 操作系统审计目录空间；
• 是否存在统一审计溢出文件；
• 清理任务是否正常执行。

十三、审计归档与清理

审计记录属于安全和合规证据。清理前必须根据组织制度确定：

• 保存周期；
• 归档位置；
• 归档数据完整性；
• 查询和恢复要求；
• 清理审批流程。

不应为了释放空间而未经归档直接删除审计记录。

13.1 设置已归档时间点

以下示例表示90天以前的统一审计记录已经完成归档：

SQL>BEGIN
    DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
        audit_trail_type  => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
        last_archive_time => SYSTIMESTAMP - INTERVAL '90' DAY
    );
END;
/

执行前必须确保对应记录已经被可靠归档。

13.2 清理已归档记录

BEGIN
    DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
        audit_trail_type        => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
        use_last_arch_timestamp => TRUE
    );
END;
/

13.3 创建定期清理任务

BEGIN
    DBMS_AUDIT_MGMT.CREATE_PURGE_JOB(
        audit_trail_type           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
        audit_trail_purge_interval => 24,
        audit_trail_purge_name     => 'PURGE_UNIFIED_AUDIT_JOB',
        use_last_arch_timestamp    => TRUE
    );
END;
/

该示例每24小时运行一次清理任务。还应配套更新最后归档时间点，否则任务可能没有符合条件的记录可清理。

生产环境实施前，应在测试环境验证过程参数、权限、容器范围及归档流程。

十四、性能与容量建议

统一审计相比同时维护多个传统审计线索更便于管理，但不能认为其性能开销始终可以忽略。

审计开销主要取决于：

• 被审计操作的执行频率；
• 审计策略覆盖的用户和对象数量；
• 是否审计高频DML；
• 是否记录SQL文本和绑定变量；
• 是否存在重复或重叠策略；
• 审计存储的I/O性能；
• 审计记录的归档和清理周期。

建议：

1. 围绕安全目标配置策略，不要无差别审计所有对象；
2. 优先审计高权限操作、权限变更、敏感对象访问和失败登录；
3. 避免多个策略重复覆盖相同用户和操作；
4. 上线前在测试环境评估审计记录量；
5. 监控审计存储增长和查询性能；
6. 建立归档及定期清理机制；
7. 对审计配置变更本身进行审批和复核。

十五、安全最佳实践

• 坚持最小权限原则；
• 锁定长期未使用的账号；
• 使用个人账号执行管理操作，避免多人共享账号；
• 审计策略管理和审计记录查看职责分离；
• 重点审计SYS、SYSTEM及其他高权限账号的对象操作；
• 审计用户、角色、权限及审计策略的变更；
• 审计敏感表的查询和修改；
• 持续分析失败登录和异常客户端来源；
• 将审计记录归档到受保护的集中平台；
• 限制对审计文件、审计表空间和归档文件的访问；
• 定期验证审计策略是否仍符合业务及合规要求；
• 使用相关安全组件前确认版本、平台和许可范围。

十六、常见误区

误区一：V$OPTION返回FALSE表示审计关闭

错误。它只表示纯统一审计没有启用，数据库可能仍在使用传统审计或混合审计。

误区二：创建审计策略后立即生效

策略必须通过AUDIT POLICY启用。对于已经登录的被审计用户，通常还需要重新建立会话。

误区三：混合模式下所有记录都在UNIFIED_AUDIT_TRAIL

错误。传统审计记录和统一审计记录可能同时保存在不同位置。

误区四：所有SYS操作都会自动完整记录

错误。具体记录范围取决于强制审计、审计模式、AUDIT_SYS_OPERATIONS和已启用的统一审计策略。

误区五：统一审计没有性能开销

错误。过于宽泛的策略仍可能产生大量记录并影响性能和存储。

误区六：可以直接删除AUDSYS底层表的数据

错误。统一审计记录应通过DBMS_AUDIT_MGMT进行归档和清理。

十七、总结

Oracle 19c统一审计提供了集中、统一和策略化的数据库活动审计能力，但正确使用它的前提是区分传统审计、混合审计和纯统一审计。

实施统一审计时，应遵循以下流程：

1. 确认当前审计模式；
2. 盘点传统审计和统一审计策略；
3. 根据安全目标设计审计范围；
4. 在测试环境验证记录内容及性能影响；
5. 正式启用审计策略；
6. 持续监控审计记录和存储增长；
7. 建立审计归档、清理和复核机制。

统一审计不是简单地“记录得越多越安全”。有效的审计应能够以合理的性能和存储成本，持续记录真正有安全和合规价值的数据库活动。

参考资料

• Oracle Database 19c Security Guide：Introduction to Auditing
• Oracle Database 19c Security Guide：Managing the Unified Audit Trail
• Oracle Database 19c Security Guide：Unified Auditing in a Multitenant Environment
• Oracle Database 19c Security Guide：Predefined Unified Audit Policies
• Oracle Database 19c Security Guide：Creating Unified Audit Policies
• Oracle Database 19c PL/SQL Packages Reference：DBMS_AUDIT_MGMT
• Oracle Database 19c Upgrade Guide：Turning Off Traditional Auditing