KingbaseES 实战：审计追踪配置与运维实践

KingbaseES 实战：审计追踪配置与运维实践

一、前言

在数据库安全体系中，如果说身份鉴别是“门禁系统”，权限控制是“内部区域划分”，那么审计追踪就是全方位的“监控系统”。它记录着谁、在什么时间、从哪里、执行了什么操作、操作结果如何——这些信息不仅是事故溯源的“黑匣子”，更是满足等保合规要求的必备条件。

本文将深入 KingbaseES 的审计体系，从基础配置到高级运维，助你构建“可追溯、可控制、可运维”的安全审计能力。作为“KingbaseES 安全三部曲”的终章，本文将与前两篇《用户、会话与连接控制》、《对象访问权限管理》协同联动，共同构建事前预防、事中控制、事后溯源的关键防线，为数据库安全治理打下坚实基础。

---

二、审计体系全景认知

2.1 审计解决了什么问题？

面对“谁删除了业务数据”的故障复盘，若缺失审计日志，责任界定将陷入无据可查的盲区。审计的核心价值恰恰在于：

• 事故溯源：精准定位问题操作的时间、用户、IP 和 SQL 内容
• 异常发现：及时发现暴力破解、越权访问等可疑行为
• 合规报告：满足等保 2.0、GDPR 等法规对操作可追溯的要求
• 内部制衡：监督高权限用户的行为，防止权力滥用

2.2 KES 审计的三层架构

KingbaseES 提供了三种互补的审计粒度，根据官方文档定义：

审计类型	审计内容	类比理解	适用场景
服务器事件审计	服务器启动、停止、重载配置、用户登录、用户登出	监控系统开关门、断电等事件	追踪数据库服务状态、发现暴力破解
语句级别审计	对 DDL、DML、DQL、DCL、TCL 等语句引发的事件进行审计	监控“有人在操作”而不是“操作了什么”	发现高危操作（如 DROP、TRUNCATE）
模式对象级别审计	在确定的模式对象（表、视图、存储过程、函数、序列）上执行操作时引发的事件审计	监控“谁进了金库、拿了什么”	核心敏感表精细化追踪

2.3 三员分立下的审计权限与制衡

审计日志本身也是敏感信息，因此 KES 严格遵循“三员分立”原则，通过权限隔离实现相互监督：

角色	职责	查看范围	限制
SAO（审计管理员）	开启/关闭审计开关，配置对 SYSTEM 和 SSO 的审计策略	SYSTEM、SSO 的操作记录	不能创建业务表，不能修改 SSO 密码
SSO（安全管理员）	配置对 SAO 和普通用户的审计策略	SAO、普通用户的操作记录	不能创建业务表，不能修改 SAO 密码
SYSTEM（系统管理员）	日常业务运维	无法查看任何审计记录	受 SAO 监控

💡 核心机制：这种“交叉审计”设计确保了没有任何一个角色能“既当运动员又当裁判员”，从根本上杜绝了审计日志被篡改或隐瞒的风险。

2.4 审计作业全流程概览

为了更直观地理解审计系统的运作机制，我们将审计生命周期划分为配置、运行、审计三个阶段。下图展示了 SAO（审计管理员）、业务用户与系统之间的交互流程：

📊 流程关键节点解析：

1. 初始化阶段（左上虚线框）：由 SAO 用户 在业务数据库（如 test）中完成。包括加载 sysaudit 插件、开启全局开关及定义具体的审计规则。这是审计生效的前提。
2. 运行触发阶段（左下虚线框）：由 普通业务用户 在日常操作中触发。当用户的 SQL 操作命中 SAO 预设的规则时，系统会自动记录审计日志，对用户透明无感知。
3. 审计监督阶段（右侧虚线框）：由 SAO/SSO 用户 在 security 系统数据库 中完成。注意：审计记录不存储在业务库中，查询时必须切换至 security 库，体现了审计数据与业务数据的物理隔离。

三、审计配置实战

3.1 环境准备与插件加载

审计功能依赖 sysaudit 插件。关键前置条件：确保 max_worker_processes 参数值有足够余量，否则审计后台进程无法启动。

-- 1. 检查并发进程数是否满足要求
SHOW max_worker_processes;

⚠️ 资源预留建议： KingbaseES V9R1 版本中，max_worker_processes 默认值为 30。虽然审计进程仅需少量 worker，但考虑到生产环境可能同时开启并行查询、逻辑复制等功能，建议确保该值至少为 8 以上。若当前值过小，需在配置文件中调整并重启数据库。

# 2. 编辑配置文件，添加审计插件
vim /data/kingbase.conf
shared_preload_libraries = '..., sysaudit'  # 在原有插件列表后添加

# 3. 重启数据库
sys_ctl restart -D /data

3.2 开启全局审计

审计功能由 SAO 用户统一管理：

-- 以 SAO 身份连接
\c test sao

-- 开启全局审计总开关
ALTER SYSTEM SET sysaudit.enable = 'on';
SELECT sys_reload_conf();

-- 确认开启状态
SHOW sysaudit.enable;

3.3 审计参数详解

sysaudit 插件提供的主要审计参数如下：

参数	使用说明	推荐配置
sysaudit.serverevent	⭐ 服务器事件审计开关（启停、重载）	on (生产必开)
sysaudit.userevent	⭐ 用户事件审计开关（登录登出）	on (生产必开)
sysaudit.enable	审计功能总开关	on
sysaudit.syntaxerror	语法错误审计开关	off (按需开启)
sysaudit.bgw_workers	审计后台进程数，默认为 1	默认即可
sysaudit.shared_cache	审计共享内存大小，默认 10MB	内存充裕可调大
sysaudit.third_store_num	批量提交审计日志条数，默认为 1	高并发可调至 100

3.4 配置语句级审计（SAO 视角）

语句级审计关注“某类操作”。注意权限边界：SAO 用户只能为 SYSTEM 和 SSO 用户配置审计规则。

-- 以 SAO 身份登录
\c test sao

-- 审计 system 用户的表创建和删除操作
SELECT sysaudit.set_audit_stmt('CREATE TABLE', 'system', null, null);
SELECT sysaudit.set_audit_stmt('DROP TABLE', 'system', null, null);

-- 查看已配置的审计规则
SELECT * FROM sysaudit.all_audit_rules;

⚠️ 配置说明：

1. 语句类型格式：set_audit_stmt 的第一个参数通常需使用大写英文，支持具体命令（如 'CREATE TABLE', 'DROP TABLE'）或大类（如 'DDL', 'DML'）。
2. 性能警示：不推荐使用 ALL 类型审计。该类型会无差别记录所有操作，对系统性能有显著影响，且无法实现针对特定对象的精细化控制。生产环境应尽量避免使用。

3.5 配置模式对象级审计（SSO 视角）

对象级审计实现精细化监控。注意权限边界：SSO 用户负责为普通用户和 SAO 用户配置审计规则。

3.5.1 准备测试环境

首先创建测试用户和测试表：

-- 以 SYSTEM 身份连接
\c test system

-- 创建测试普通用户 user01
CREATE USER user01 PASSWORD 'Kingbase@123';

-- 创建测试业务表
CREATE TABLE business_info (id int, info text);
CREATE TABLE account_info (id int, account_no text, balance numeric);

-- 授予 user01 必要的权限
GRANT SELECT, INSERT, UPDATE, DELETE ON business_info TO user01;
GRANT SELECT, INSERT, UPDATE, DELETE ON account_info TO user01;

-- 插入测试数据
INSERT INTO business_info VALUES (1, 'test data');
INSERT INTO account_info VALUES (1001, '6228480012345678', 10000.00);

3.5.2 配置对象级审计规则

-- 以 SSO 身份登录配置审计规则
\c test sso

-- 审计普通用户 user01 对 business_info 表的所有操作
SELECT sysaudit.set_audit_object('TABLE', 'user01', 'public', 'business_info');

-- 审计所有用户对 account_info 表的操作
SELECT sysaudit.set_audit_object('TABLE', null, 'public', 'account_info');

-- 查看已配置的审计规则
SELECT * FROM sysaudit.all_audit_rules;

执行结果示例：

 audit_id | audit_target | audit_type | audit_users | audit_schema | audit_objname | audit_objoid | creator_name
----------+--------------+------------+-------------+--------------+---------------+--------------+--------------
    16400 | Object       | table      | user01      | public       | business_info |        16387 | sso
    16407 | Object       | table      |             | public       | account_info  |        16401 | sso

从审计规则查询结果可以看出：

• audit_id：系统为每条审计规则分配的唯一标识符。
• audit_users：被审计的用户，第一条为 "user01"，第二条为空表示所有用户。
• audit_objname：被审计的对象名称。
• creator_name：规则创建者。

3.5.3 验证审计效果

以 user01 身份执行一系列操作，触发审计记录：

-- 以 user01 身份连接
\c test user01

-- 执行业务操作
SELECT * FROM business_info;
INSERT INTO business_info VALUES (2, 'more data');
UPDATE business_info SET info = 'updated' WHERE id = 1;
DELETE FROM business_info WHERE id = 2;

-- 查询核心表
SELECT * FROM account_info WHERE id = 1001;

3.5.4 查询审计记录

以 SSO 身份登录 security 数据库，查看 user01 的审计记录：

-- 以 SSO 身份连接 security 数据库
\c security sso

-- 查询 user01 的审计记录
SELECT username, opr_type, obj_name, result, audit_ts 
FROM sysaudit_record_sso 
WHERE username = 'user01' 
ORDER BY audit_ts DESC;

执行结果示例：

 username | opr_type |   obj_name    | result |           audit_ts
----------+----------+---------------+--------+-------------------------------
 user01   | 查询     | account_info  | 成功   | 2026-03-02 20:46:00.293064+08
 user01   | 删除     | business_info | 成功   | 2026-03-02 20:45:59.595305+08
 user01   | 更新     | business_info | 成功   | 2026-03-02 20:45:59.595301+08
 user01   | 插入     | business_info | 成功   | 2026-03-02 20:45:59.595293+08
 user01   | 查询     | business_info | 成功   | 2026-03-02 20:45:59.595266+08

📌 要点说明：

• SSO 只能审计普通用户和SAO 用户的操作，无法审计 SYSTEM 和自身。
• set_audit_object 中的 audit_schema 参数必须指定已存在的模式名，本例中使用 public 模式。
• audit_users 参数设为 null 表示审计所有SSO 权限范围内的用户。
• 审计记录存储在 security 数据库的 sysaudit_record_sso 视图中。

3.6 审计规则的取消

-- 取消编号为 16400 的审计策略（需由创建者执行）
CALL sysaudit.remove_audit(16400);

-- 取消所有审计策略
CALL sysaudit.remove_audit(null);

📌 注意：取消审计策略不会删除已产生的审计记录，仅停止后续操作的审计。

3.7 审计记录的查询（核心机制）

不同身份的审计员通过不同视图查询记录，这是三员分立的直接体现。

SAO 视角：查看 SYSTEM 和 SSO 的操作

\c security sao
SELECT username, opr_type, obj_name, result, audit_ts
FROM sysaudit_record_sao
WHERE audit_ts > current_date - interval '7 days'
ORDER BY audit_ts DESC;

SSO 视角：查看 SAO 和普通用户的操作

\c security sso
SELECT username, opr_type, obj_name, result, audit_ts
FROM sysaudit_record_sso
ORDER BY audit_ts DESC;

❗ 关键执行前提：

• 数据库上下文：审计记录统一存储在名为 security 的系统数据库中。上述代码中的 \c security 命令至关重要，若在当前业务库（如 test）中直接执行 SELECT，系统将报错“关系不存在”。
• 权限隔离机制：SAO 无法查看自身的操作记录（由 SSO 监督），SSO 无法查看自身的操作记录（由 SAO 监督），SYSTEM 用户无法查看任何审计记录。这种交叉监督设计确保了审计数据的独立性。

3.8 完整示例

-- === 步骤 1：system 用户创建测试表 ===
\c - system
CREATE TABLE demo_tbl (id int);

-- === 步骤 2：sao 用户开启审计、配置规则 ===
\c - sao
ALTER system SET sysaudit.enable = on;
SELECT sys_reload_conf();
SELECT sysaudit.set_audit_stmt('DROP TABLE', 'system', null, null);

-- === 步骤 3：查看审计规则 ===
SELECT * FROM sysaudit.all_audit_rules;

-- === 步骤 4：system 执行操作触发审计 ===
\c - system
DROP TABLE demo_tbl;

-- === 步骤 5：sao 登录 security 库查看审计日志 ===
\c security sao
SELECT username, opr_type, obj_name, result FROM sysaudit_record_sao 
WHERE opr_type = '删除表' ORDER BY audit_ts DESC;

-- === 步骤 6：取消审计规则 ===
\c test sao
SELECT sysaudit.remove_audit(16421);

📌 注意：建议先通过 SELECT DISTINCT opr_type 查看所有操作类型。在某些 locale 设置下，操作类型可能显示为中文描述（如“删除表”），需确保查询条件与之匹配。

---

四、审计记录的运维管理

4.1 审计记录转储机制

随着业务运行，审计表会逐渐膨胀。KES 通过“转储”机制将历史审计记录从在线表迁移到加密文件中，释放在线存储空间。

手动转储

-- === 查看当前审计记录量 ===
SELECT COUNT(*), MIN(audit_ts), MAX(audit_ts) FROM sysaudit_record_sao;

-- === 转储 30 天前的记录 ===
SELECT sysaudit.dump_auditlog(30);

-- === 查看生成的转储文件 ===
SELECT sysaudit.show_audlog_dump_file();

-- === 需要时从文件恢复 ===
SELECT sysaudit.restore_auditlog('AUDIT_DUMP_FILE-20260123_143000');

自动转储

前置准备： 在执行以下 SQL 前，请务必在操作系统层面完成目录创建与授权：

mkdir -p /archive/audit_dump
chown kingbase:kingbase /archive/audit_dump
chmod 700 /archive/audit_dump

配置命令：

-- === 配置自动转储参数 ===
ALTER SYSTEM SET sysaudit.auditlog_dump_dir = '/archive/audit_dump';
ALTER SYSTEM SET sysaudit.enable_auto_dump_auditlog = 'on';
ALTER SYSTEM SET sysaudit.max_auditlog_size = '10GB';
ALTER SYSTEM SET sysaudit.auditlog_keep_days = 90;

SELECT sys_reload_conf();

🛡️ 运维重要提示：

• 权限校验：若未提前创建目录或目录属主非数据库运行用户（kingbase），自动转储任务将静默失败，导致在线审计表持续膨胀直至占满磁盘空间。
• 状态监控：建议定期检查转储日志，确认 dump 任务是否按预期触发。

4.2 远程审计部署

KES 支持将审计日志存储到独立的审计数据库中，实现审计数据与生产数据的物理隔离：

-- === 配置远程审计数据库连接 ===
ALTER SYSTEM SET sysaudit.audit_table_hostaddr = '192.168.126.16';
ALTER SYSTEM SET sysaudit.audit_table_port = '54321';
ALTER SYSTEM SET sysaudit.audit_table_user = 'sao';
ALTER SYSTEM SET sysaudit.audit_table_password = '******';
ALTER SYSTEM SET sysaudit.local_sao_password = '******';

SELECT sys_reload_conf();

🔒 安全加固建议： 配置文件中明文存储 audit_table_password 存在潜在风险。生产环境建议：

1. 严格限制配置文件权限（chmod 600）。
2. 优先采用密码文件或外部密钥管理服务管理连接凭证。

---

五、审计性能影响及优化策略

5.1 审计对性能的影响机制

审计功能对数据库性能的影响主要来源于：

• 记录生成：提取操作信息、格式化处理
• 写入开销：审计记录写入系统表产生 I/O
• 内存占用：审计缓存占用共享内存
• 进程开销：审计后台进程消耗 CPU 资源

5.2 审计规则粒度与性能关系

三种审计类型对性能的影响程度：

服务器事件审计 < 语句级别审计 < 模式对象级别审计

官方明确提示：不推荐使用 ALL 类型审计，对性能有显著影响。

5.3 生产环境优化建议

基于前文实践案例，我们可以总结出一套实用的分级审计策略。

分级审计策略矩阵

级别	审计对象	审计类型	审计用户	适用场景
L1	核心敏感表	对象级审计	所有用户	资金账户、客户信息等，需全量记录
L2	重要业务表	对象级审计	特定应用户	业务流水表，仅审计应用账号，减少干扰
L3	普通业务表	语句级审计	所有用户	配置表、字典表，仅关注 DDL 结构变更
L4	日志/临时表	无审计	-	数据量大且价值低，不创建规则

-- ✅ L1：核心敏感表做对象级审计（对所有用户）
SELECT sysaudit.set_audit_object('TABLE', null, 'public', 'account_info');
SELECT sysaudit.set_audit_object('TABLE', null, 'public', 'customer_info');

-- ✅ L2：重要业务表做对象级审计（仅对特定用户）
SELECT sysaudit.set_audit_object('TABLE', 'app_user', 'public', 'transaction_log');
SELECT sysaudit.set_audit_object('TABLE', 'app_user', 'public', 'order_info');

-- ✅ L3：普通业务表只审计 DDL 操作
SELECT sysaudit.set_audit_stmt('DDL', 'app_user', 'public', null);

参数调优建议

-- 内存充裕时可增大审计缓存，减少磁盘 I/O
ALTER SYSTEM SET sysaudit.shared_cache = '20MB';

-- 高并发场景调整批量提交条数，平衡内存占用与写入频率
ALTER SYSTEM SET sysaudit.third_store_num = '100';

-- 配置自动转储阈值，防止单表过大影响查询性能
ALTER SYSTEM SET sysaudit.max_auditlog_size = '10GB';
ALTER SYSTEM SET sysaudit.enable_auto_dump_auditlog = 'on';

SELECT sys_reload_conf();

📢 调优原则：

• third_store_num 需根据实际并发负载动态调整，设置过大可能导致共享内存占用激增。
• 始终遵循“最小必要”原则：在满足合规需求的前提下，尽可能缩小审计范围、降低审计粒度。

---

六、实战案例——构建合规的审计体系

6.1 需求背景

某交易系统需满足：

1. 等保三级合规要求
2. 审计记录保留 2 年

6.2 实施方案

步骤 1：审计策略规划

审计对象	审计类型	审计内容	配置角色	保留策略
系统事件	服务器事件审计	启停、登录失败	SAO	6 个月
核心交易表	对象级审计	所有 DML 操作	SSO	2 年
重要业务表	对象级审计	仅对应用户审计	SSO	1 年
普通业务表	语句级审计	仅 DDL 操作	SSO	1 年

步骤 2：审计配置实施

-- === 1. 以 SAO 身份配置基础审计 ===
\c security sao
ALTER SYSTEM SET sysaudit.serverevent = 'on';
ALTER SYSTEM SET sysaudit.userevent = 'on';

-- === 2. 配置对象级审计（SSO 负责） ===
\c test sso

-- 核心交易表：对所有用户做对象级审计
SELECT sysaudit.set_audit_object('TABLE', null, 'public', 'account_info');

-- 重要业务表：仅对应用户做对象级审计
SELECT sysaudit.set_audit_object('TABLE', 'app_user', 'public', 'business_info');

-- === 3. 查看已配置的审计规则 ===
SELECT * FROM sysaudit.all_audit_rules;

步骤 3：自动转储配置

-- === 配置自动转储 ===
ALTER SYSTEM SET sysaudit.auditlog_dump_dir = '/data/audit_archive';
ALTER SYSTEM SET sysaudit.enable_auto_dump_auditlog = 'on';
ALTER SYSTEM SET sysaudit.max_auditlog_size = '10GB';
ALTER SYSTEM SET sysaudit.auditlog_keep_days = 730;  -- 2 年

SELECT sys_reload_conf();

步骤 4：验证审计效果

-- 以 app_user 身份执行操作后，SSO 查询审计记录
\c security sso

-- 查询 app_user 对 business_info 表的操作
SELECT username, opr_type, obj_name, result, audit_ts
FROM sysaudit_record_sso
WHERE username = 'app_user' AND obj_name = 'business_info'
ORDER BY audit_ts DESC;

-- 查询所有用户对 account_info 表的操作
SELECT username, opr_type, obj_name, result, audit_ts
FROM sysaudit_record_sso
WHERE obj_name = 'account_info'
ORDER BY audit_ts DESC;

---

七、常见问题排查指南

Q1：开启了审计，但查不到记录？

标准化排查步骤：

1. 确认数据库上下文：检查当前是否已连接至 security 数据库。
2. 检查总开关状态：

   SHOW sysaudit.enable;
   

3. 检查后台进程：

   SELECT * FROM sys_stat_activity WHERE backend_type LIKE '%audit%';
   

4. 核对审计规则：

   SELECT * FROM sysaudit.all_audit_rules;
   

5. 验证视图权限：确认当前登录角色与查询视图匹配（SAO 查 sysaudit_record_sao，SSO 查 sysaudit_record_sso）。

Q2：审计表增长太快怎么办？

解决方案：

1. 优化策略：审查并删除过于宽泛的规则（如 ALL 类型）。
2. 调整阈值：降低 max_auditlog_size 参数值，触发更频繁的转储。
3. 手动清理：执行 SELECT sysaudit.dump_auditlog(0); 立即转储并清理在线数据。

Q3：审计影响性能怎么办？

性能优化检查清单：

• 是否使用了非必要的宽泛审计规则？
• 审计粒度是否可以细化（如从语句级调整为对象级）？
• 在线审计表是否过大，是否需要执行转储？
• shared_cache 和 third_store_num 参数是否适配当前负载？

Q4：转储任务执行失败？

排查思路：

1. 目录检查：确认 OS 层面目录存在且属主正确 (ls -ld <目录>).
2. 日志分析：查阅 dbms_log，搜索 "dump" 或 "audit" 关键词，定位具体错误（如 "Permission denied"）。

---

八、总结

至此，我们完成了KingbaseES安全体系的三部曲：

1. 通过《用户、会话与连接控制》守好大门，防止非法接入
2. 通过《对象访问权限管理》划分内部禁区，确保最小权限原则
3. 通过本文的《审计追踪配置》装上全方位监控，实现事后溯源与合规

三者合一，方能构建坚不可摧的数据安全堡垒。

通过本文的深入解析，我们掌握了：

1. 审计体系：服务器事件、语句级别、模式对象级别的三层架构
2. 权限控制：SAO、SSO的审计视图分离与交叉监督机制
3. 配置方法：从插件加载到规则设置的全流程操作
4. 运维管理：转储机制解决海量日志问题
5. 性能平衡：精确配置、定期转储是优化关键

在实际应用中，建议始终遵循“最小必要”原则：在满足合规和安全需求的前提下，尽可能缩小审计范围、降低审计粒度，找到安全与性能的最佳平衡点。

---

延伸阅读：

• KingbaseES实战：深度解析用户、会话与连接控制
• KingbaseES实战：深度解析数据库对象访问权限管理
• 金仓数据库官方文档：数据库审计

---