数据库安全从来不只是防火墙和权限配置的问题，更重要的是当可疑操作发生后，你能不能回答三个问题：是谁做的、做了什么、什么时候做的。DB2的审计机制正是为回答这三个问题而设计的。其中audit database是DB2审计体系中最常用的一个层级，用于记录数据库范围内的各类事件，比如连接尝试、授权检查、对象操作、SQL语句执行等。本文将系统讲解audit database的原理、配置方法和日志分析技巧。
DB2审计体系的基本架构与audit database的定位
DB2的审计功能分为几个不同的层级，理解这些层级的区别是正确使用audit database的前提。DB2审计采用分级设计，从上到下依次是实例级审计、数据库级审计、表级审计和语句级审计。实例级审计由db2audit工具统一管理，记录的日志存放在实例所有者主目录下的db2audit目录中；而数据库级审计，也就是本文重点讨论的audit database，则是通过AUDIT语句在数据库内部配置的，审计记录通过系统管理的方法写入日志，可以用EXTRACT FROM DATABASE命令提取。
audit database的覆盖范围相当广泛，它又细分为多个子类别。审计上下文（CONTEXT）记录操作的完整上下文信息，审计对象（OBJEC TS）记录对表、视图等对象的访问，审计执行（EXECUTE）记录授权ID执行的静态或动态SQL语句，审计函数调用（FUNCTIONS）记录用户自定义函数的执行情况。此外还有判断是否记录（WHENEVER）的语句成功失败控制，以及授权检查（VALIDATE）等类别。管理员可以根据实际需求组合这些类别，避免记录过多无用信息导致日志膨胀。
需要特别注意的是，audit database记录的日志在数据库激活时会写入事务日志之外的特殊文件。通过设置数据库配置参数AUDIT_BUF_SZ可以指定审计缓冲区大小，该缓冲区用于暂存审计记录，缓冲区写满后会刷新到磁盘。如果对性能要求较高，适当增大这个参数可以减少磁盘IO次数。
如何配置audit database：从权限准备到AUDIT语句实战
配置audit database之前，必须确认操作账号具备相应权限。执行AUDIT语句需要数据库级别的SECADM权限，这是DB2中安全管理的最高权限。在DB2 9.7及以后的版本中，SECADM权限已经从SYSADM中分离出来，普通DBA账号如果只有DBADM权限，是无法直接执行AUDIT语句的。下面是一个完整的配置演示。
-- 首先连接到目标数据库 db2 connect to SAMPLE -- 对数据库范围启用审计，记录上下文和对象访问事件 db2 "AUDIT DATABASE USING CATEGORIES OBJEC TS CONTEXT STATUS BOTH ERROR TYPE NORMAL" -- 对特定表启用审计，记录所有对该表的访问 db2 "AUDIT TABLE EMPLOYEE USING CATEGORIES OBJEC TS STATUS BOTH" -- 查看当前审计配置 db2 "SELECT * FROM SYSCAT.AUDITPOLICIES" -- 对特定用户启用审计（DB2 9.7+ 支持审计策略） db2 "CREATE AUDIT POLICY SENSITIVE_POLICY CATEGORIES EXECUTE WITH DETAILS STATUS BOTH ERROR TYPE AUDIT" db2 "AUDIT USER AUDITOR USING AUDIT POLICY SENSITIVE_POLICY"
上面的语句中，STATUS BOTH表示无论操作成功还是失败都记录审计日志，这一点在排查攻击行为时非常重要，因为失败的尝试往往比成功的操作更能暴露问题。ERROR TYPE NORMAL表示发生错误时记录简要信息，如果改为ERROR TYPE AUDIT，则在审计子系统本身出错时也会记录详细信息。WITH DETAILS选项会额外记录SQL语句的详细内容，代价是日志量会明显增大，建议只对核心敏感表启用。
如果需要修改或取消审计设置，可以使用带有RESET选项的AUDIT语句。例如AUDIT TABLE EMPLOYEE RESET会清除对该表的审计设置，AUDIT USER AUDITOR RESET则取消对指定用户的审计。生产环境调整审计配置时，建议先在测试库验证，确认日志量和性能影响在可接受范围内后再推到生产。
审计日志的提取、格式化与分析方法
audit database产生的日志默认以二进制格式存放，不能直接阅读，需要借助db2audit工具的EXTRACT功能提取并格式化。对于数据库级审计，使用EXTRACT FROM DATABASE子句，日志会从数据库中导出并转换为可读的文本。下面是完整的操作流程。
-- 提取数据库级审计日志并格式化为del文件 db2audit describe > audit_describe.txt db2audit extract from database delimited asc file audit_output.del -- 只提取指定时间范围的记录 db2audit extract from database delimited asc file audit_output.del time 2024-01-01-08.00.00 to 2024-01-31-18.00.00 -- 查看提取结果的头部说明 head -5 audit_output.del
提取出来的文件每行一条审计记录，字段之间用指定分隔符隔开，常见的字段包括时间戳、事件类型、授权ID、应用程序ID、数据库名称、表名以及执行的语句文本等。对于大批量日志，直接用文本编辑器打开效率很低，推荐的做法是先把del文件导入到一张分析表中，再用SQL进行统计。可以创建一个结构与审计记录对应的外部表，通过LOAD命令快速导入，之后就能用熟悉的SQL做聚合分析，比如统计某账号一天内的失败登录次数，或者筛选出对敏感表的全量导出操作。
另一个实用技巧是结合SYSCAT.AUDITUSE系统目录视图排查审计覆盖情况。这个视图记录了哪些表、哪些用户绑定了审计策略，定期检查它可以避免出现审计盲区。同时要注意审计日志的保留策略，二进制日志文件会持续增长，应该制定定期提取归档并清理原始文件的机制，否则磁盘占满后新的审计记录将无法写入，这在合规审计中是重大事故。
生产环境使用audit database的注意事项
第一个要关注的问题是性能。开启EXECUTE WITH DETAILS级别审计后，每一条SQL都会产生审计记录，对高并发OLTP系统的影响可能达到两位数百分比。建议采取分级策略：对数据库整体只开启OBJEC TS和VALIDATE等低开销类别，对核心业务表再叠加EXECUTE审计，这样能在安全与性能之间取得平衡。
第二个问题是审计日志自身的安全。审计日志最怕被篡改，尤其是被拥有高权限的人删除。实践中可以把审计日志定期归档到只有审计员可访问的独立存储，同时开启操作系统的文件完整性监控。另外DB2支持将审计日志发送到syslog外部设施，通过AUDIT配置指定远程日志服务器，这样即使数据库主机被入侵，审计记录仍然安全。
最后建议建立常态化的审计分析流程，而不是出事之后才翻日志。可以编写定时任务每天提取前一日的审计记录，自动生成异常行为报告，比如非工作时间的批量导出、权限变更操作、连续失败的授权尝试等。把审计从被动取证变成主动监控，才是audit database配置的最终价值所在。通过合理规划审计类别、控制日志增长、保护日志安全这三步，你就能搭建一套既满足合规要求又不拖累业务性能的DB2审计体系。
DB2 audit databaseDB2审计数据库安全审计修改时间：2026-09-04 21:28:39