在 GBase 8c 里做审计，我更在意的是“能查到、留得住、查得动”，而不是只把开关打开

我最近看 GBase 8c 相关资料时，一个感受特别明显：很多项目提到“数据库审计”，最先想到的动作往往只是把审计功能打开，但真正到了生产环境，问题很快就会变成另外三个层面——审计项到底配到什么粒度、审计日志能不能长期保留下来、出了问题以后能不能快速把那段操作链路还原出来。GBase 8c 本身提供了比较完整的审计能力，既支持登录注销、数据库启动停止、权限授予回收、对象 DDL、DML、SELECT、COPY、函数执行、SET 参数等不同维度的审计项，也支持通过函数和日志目录去查结果。更关键的是，审计总开关和多数审计项支持动态生效，不一定要停库重启。

从落地角度看，这种能力并不只是为了“合规检查时能交材料”。在真实环境里，审计更常见的用途反而是下面几类：

• 查谁在什么时间删了数据；

• 查一段时间里哪些账号做过越权或敏感访问；

• 查某个对象为什么突然结构变了；

• 查批量导入、函数调用、参数修改是不是在错误时间窗口执行；

• 做事后追溯，给故障排查补上证据链。

我自己理解下来，GBase 8c 的审计如果要真正落地，不能只停留在“开了没开”这一级，而是要沿着下面这条线往下看：先决定审计边界，再决定采集粒度，再决定保存策略，最后再决定查询和巡检方式。 这几个环节只要有一个没处理好，审计很容易要么太重、把系统拖慢，要么太轻、事后查不到东西。

一、先别急着全量审计，第一步应该先定义“到底要审什么”

GBase 8c 的审计项覆盖面比较广。社区整理里列出的常用配置就已经包括：登录注销审计 audit_login_logout、数据库启动停止恢复切换审计 audit_database_process、用户锁定解锁审计 audit_user_locked、越权访问审计 audit_user_violation、权限授予回收审计 audit_grant_revoke、对象 DDL 审计 audit_system_object、DML 审计 audit_dml_state、SELECT 审计 audit_dml_state_select、COPY 审计 audit_copy_exec、函数执行审计 audit_function_exec、系统函数执行审计 audit_system_function_exec、SET 审计 audit_set_parameter、事务 ID 记录 audit_xid_info 等。默认情况下，并不是所有项目都开启。比如 DML 和 SELECT 审计默认就是关闭的。

这个地方我个人比较在意，因为很多人一看审计项很全，就容易直接往“全开”走。
但真正落到现场时，最先要回答的问题其实是：

你是为了安全合规、运维追溯，还是为了业务数据留痕？

这三类目标，关注点并不一样。

之所以不建议上来就把 SELECT 和所有表 DML 全量打开，原因也不复杂：这类日志增长会非常快，尤其是报表类、查询密集型业务。如果没有明确边界，最后很容易从“审计系统”变成“日志堆积系统”。这一点从官方给出的日志保存策略参数也能看出来，GBase 8c 对审计目录、空间上限、最小保存时长、文件数量阈值都单独给了配置项，显然不是按“无限留存”来设计的。

二、GBase 8c 的审计更适合按“默认基础项 + 重点对象补充项”来设计

我自己更倾向于把审计拆成两层。

第一层：默认基础审计

这层主要保证系统级动作和安全边界有记录，通常建议至少覆盖：

• 用户登录与注销；

• 数据库启动、停止、恢复、切换；

• 用户锁定与解锁；

• 权限授予与回收；

• 核心对象的 CREATE / ALTER / DROP；

• 必要的参数修改操作。

这类项有一个共同点：日志量通常可控，但排障价值很高。

第二层：重点对象审计

这层是围绕关键表、关键账号、关键时间窗口做补充。
比如：

• 财务清分表：重点审 INSERT / UPDATE / DELETE；

• 运维管理员账号：做更高粒度的审计；

• 夜间批量窗口：重点审 COPY 和函数执行；

• 敏感分析库：必要时补 SELECT 审计。

这种分层方式的好处是，能把审计做得更接近真实场景。
真正落地时，我一般不会把“审计覆盖率”理解成“所有动作都记录”，而是更看重“关键动作能不能有足够证据”。

三、审计开关能动态生效，这点在生产环境里很实用

社区文章里明确提到，GBase 8c 的审计总开关 audit_enabled 支持动态加载，运行期间修改后可立即生效；很多具体审计项也支持动态修改，无需重启数据库。默认 audit_enabled=on。这一点非常适合线上临时加审计、窗口期提级留痕，或者问题结束后再收缩粒度。

比如临时需要追一张关键表的 DML 行为，我一般会采用这种方式：

gs_guc reload -N all -I all -c "audit_dml_state = 1"
gs_guc reload -N all -I all -c "audit_dml_state_select = 1"

如果只是想确认当前目录或参数，也可以直接在库里看：

SHOW audit_directory;
SHOW audit_enabled;
SHOW audit_dml_state;
SHOW audit_dml_state_select;

这里更适合这样理解：
动态生效意味着审计可以做成“可控加压”，而不是永远固定一个重配置。
这对生产库很关键，因为很多时候你不是一直想保持最高粒度审计，而是只在敏感时期、问题窗口、变更期提升留痕级别。相关参数和查询方式在社区示例里都有直接说明。

四、只会查日志还不够，我更建议把 pg_query_audit 当成第一入口

GBase 8c 社区里给了一个很实用的办法：直接通过 pg_query_audit(起始时间,终止时间) 查询指定时间段的审计动作；如果需要进一步核对原始日志，再通过 SHOW audit_directory 找到底层审计文件目录。对于“想看某段时间到底执行过哪些系统 SQL / DML / SELECT”的场景，这个入口非常顺手。

一个更贴近日常使用的查询方式可以这样写：

SELECT detail_info, type, result
FROM pg_query_audit('2026-03-25 09:00:00', '2026-03-25 10:00:00')
WHERE type IN ('dml_action', 'dml_action_select')
  AND detail_info LIKE '%acct_trade_detail%';

如果是查某个对象的 DDL 变化，也可以把过滤条件换成对象名和动作类型。
如果是查某个账号的操作轨迹，通常就会把时间段、用户名、对象名一起带上。

这个点我个人比较在意，因为很多团队做审计，最后停留在“日志文件存在”，但一旦真要排故障，大家又得去翻 OS 目录、grep 文件、拼时间窗口，效率很低。
而 pg_query_audit() 这种方式，本质上就是给现场排查留了一个更适合 SQL 视角的入口。

五、真正麻烦的不是“有没有日志”，而是“日志保留策略有没有把自己逼到角落里”

我最近整理资料时发现，GBase 8c 对审计日志维护给出的参数其实已经很完整了：

• audit_directory：审计文件存储目录；

• audit_resource_policy：审计日志保存策略；

• audit_space_limit：审计文件总空间上限；

• audit_file_remain_time：最小保存时间；

• audit_file_remain_threshold：审计目录下最大文件数量阈值。

官方社区还提到，如果通过 gs_om 部署，默认审计目录一般在 /var/log/gaussdb/用户名/pg_audit。

从实际场景看，这几个参数最容易出现两类问题。

1）空间上限太保守

刚开始觉得审计只是辅助功能，给了很小的空间；
结果某次排查窗口临时打开了 DML / SELECT，几小时就把目录吃满，后面日志保留策略开始不断回收，真正关键的证据反而没留住。

2）保留时间和业务周期不匹配

很多公司月结、季结、审计抽查都不是按 7 天来算。
如果 audit_file_remain_time 太短，等到真正有人来追溯，文件可能早就滚没了。官方默认示例里给出的最小保存时间是 90。这个数字并不一定适合所有环境，但它至少说明 GBase 8c 设计审计时，默认就是按“长期留痕”思路考虑的。

所以我更建议把审计保留策略按场景分层：

六、GBase 8c 为什么更偏向把审计结果写到 OS 文件，而不是只放表里

社区资料里专门对两种审计日志保存方式做过比较：如果审计结果保存在数据库表里，理论上查询方便，但只要用户拥有相应对象权限，就存在被访问甚至被非法操作的风险；而写到 OS 文件，虽然需要用户维护日志，但从安全角度更可靠，因为即使能访问数据库，也不一定就能访问操作系统层面的审计文件。GBase 8c 从安全角度出发，更强调用 OS 文件保存审计结果。

这个设计我自己是比较认可的。
因为审计的核心诉求之一就是“独立可信”。如果审计和业务数据都放在同一个权限边界里，那么一旦真遇到高权限误操作或恶意篡改，审计记录本身也可能失去说服力。社区文章还提到，GBase 8c 甚至设置了专门的安全审计员角色，用于独立审计管理和查看审计数据。

所以如果放到治理视角里，这件事不是“文件查询不如表查询方便”，而是“审计证据要不要尽量和业务权限分层”。
我更倾向于后者。

七、真正上线时，我更建议用“小步启用”的方式做一次审计基线

如果让我给 GBase 8c 审计落地梳一遍更稳妥的顺序，我一般会按下面这套来。

第一步：先上基础安全项

先开启登录注销、数据库进程、权限授予回收、对象 DDL、锁定解锁。
这一步日志量通常不夸张，但已经能覆盖大部分常见排查线索。

第二步：确认目录和保留策略

核对：

SHOW audit_directory;
SHOW audit_resource_policy;
SHOW audit_space_limit;
SHOW audit_file_remain_time;
SHOW audit_file_remain_threshold;

这一步不是形式检查，而是为了防止“开了审计但没留住”。相关参数含义在维护审计日志说明里都有。

第三步：按关键对象补 DML / SELECT

不要全库一把梭，先围绕关键表、关键账号、关键时间段加粒度。
比如月结窗口、敏感表、审计抽查期。

第四步：形成固定查询模板

至少准备三类：

• 按时间窗口查；

• 按对象名查；

• 按动作类型查。

比如：

SELECT detail_info, type, result
FROM pg_query_audit('2026-03-25 00:00:00', '2026-03-25 23:59:59')
WHERE detail_info LIKE '%fin_settle_result%';

第五步：把审计纳入日常巡检

重点看两件事：

• 审计目录增长速度是否异常；

• 是否存在超出预期的大量 SELECT / DML 留痕。

八、我更认可的一种审计思路：别追求“全记录”，而要追求“关键动作可还原”

我自己理解下来，GBase 8c 的审计能力已经足够把很多关键问题讲清楚。
它既能对登录、权限、对象变更做系统级留痕，也能在需要时对 DML、SELECT、COPY、函数执行、SET 参数做更细粒度跟踪；再配合 pg_query_audit()、审计目录和日志维护策略，基本可以把“谁、在什么时间、对什么对象、做了什么动作、结果如何”串起来。

真正落到现场，我更看重的不是“审计项是不是开到了最多”，而是下面这几件事：

• 关键账号有没有留痕；

• 关键表有没有证据链；

• 关键变更窗口能不能追溯；

• 日志是不是能在需要的时候还在；

• 查询入口是不是足够顺手。

如果这几件事都做到了，GBase 8c 的审计就不只是一个合规功能，而会真正变成数据库治理里的基础设施。
出了问题以后，不是靠猜，也不是靠口头确认，而是能直接把操作轨迹拉出来说话。这个价值，在生产环境里通常比“配置项记住了多少”更实在。

参考资料

[1] 南大通用GBase 8c审计功能简述
https://www.gbase.cn/community/post/4410

[2] GBase 8c维护审计日志（一）
https://www.gbase.cn/community/post/1964

[3] 如何查看8c执行过的系统sql - GBase 8c
https://www.gbase.cn/community/post/5544

[4] GBase 8c 数据库审计概述（八）
https://www.gbase.cn/community/post/2481

[5] GBase 8c数据库安全审计
https://www.gbase.cn/community/post/1953

[6] GBase 8c 开发者手册
https://cdn.gbase.cn/products/34/Pr3MGDrcOeeWwC9kdNEjM/GBase%208c%20V5_3.0.1_%E5%BC%80%E5%8F%91%E