OceanBase 的审计功能很多 DBA 下意识以为就是开个参数记 SQL真到排查和合规审计时才发现登录失败的记录、sys 租户操作、通过 OBProxy 进来的连接这些细节要么没开对要么数据躺在内部表里不知道怎么查。这次我基于 OceanBase 4.2.1 的 MySQL 模式做了一轮完整的审计功能专项测试从参数配置、场景设计、日志查询到问题排查全部过了一遍。这篇文章就是这次测试的完整记录内容包括实操命令、测试结果和踩坑经验适合正在规划生产环境审计方案的 DBA以及刚接手 OceanBase 运维的兄弟们参考。1. 测试背景与审计功能定位1.1 为什么审计功能值得单独拉出来测生产环境的数据库安全不是你上了防火墙、收紧了账号权限就完事的。一旦出现误删数据、越权查询或者账号被暴力破解的迹象你需要的是事后可以追溯的依据。审计功能就是干这个的——它把登录、SQL 执行、权限变更这些关键动作按时间线记下来出了问题能回溯到人、到 IP、到具体语句。OceanBase 的审计跟传统单机 MySQL 的 general log 完全是两码事。general log 更像是“全量 SQL 流水”而 OceanBase 的审计是安全审计重点记录“谁在什么时候从哪里登录、执行了什么操作、成功还是失败”。它更像 Oracle 的审计体系而不是简单的日志开关。这个定位上的差异直接决定了你后续的配置思路和测试方法如果按 general log 的思路去理解审计后面查记录的时候很容易找错方向。1.2 测试环境与整体测试思路这次测试我用的是一套 OceanBase 4.2.1 的三节点集群部署形态是标准的多数派协议多副本前端挂了一台 OBProxy 作为统一接入入口。集群里除了 sys 租户之外单独建了一个业务租户 ob_audit_tenantMySQL 模式里面创建了专门用于测试的普通用户 aud_user 和管理员用户 aud_dba避免全程用 root 操作导致审计结果缺乏区分度。测试思路分成四条线第一条是参数线确认审计相关的参数怎么开、开到什么程度第二条是场景线覆盖登录、DDL、DML、权限变更四类核心动作第三条是查询线验证审计记录落在哪张表、字段怎么解读第四条是问题线记录测试过程中真实遇到的不符合预期的现象以及排查过程。这样组织的好处是最后不管是给安全团队交报告还是给自己留一份可复用的操作手册都有一条清晰的主线。提示本文所有命令执行环境为 OceanBase 4.2.1 的 MySQL 模式其他版本或模式下的参数行为和表结构可能存在差异以你实际部署的版本为准。2. 审计开启参数配置全解析2.1 核心参数逐个拆解OceanBase 的审计功能由一组 audit 前缀参数控制平时用SHOW PARAMETERS LIKE %audit%就能看全。这里我把最关键的几个参数和它们的作用整理了一下参数名默认值作用audit_enabledFalse审计总开关开启后系统才会记录审计事件audit_sys_operationsFalse是否审计 sys 租户内用户比如 rootsys的操作audit_sys_user_operationsFalse是否审计 sys 租户的用户登录行为audit_sys_execute_againFalsesys 租户审计模式下是否重新执行被审计的 SQLaudit_sys_operation_whitelist空sys 租户审计时跳过指定内部用户的白名单一句话总结audit_enabled是总闸剩下几个都是围绕 sys 租户做细化的。业务租户的审计只要开了总开关就有但 sys 租户内部的操作默认不审需要额外打开audit_sys_operations。这个设计其实挺符合多租户安全的直觉——租户之间要隔离sys 作为管理面默认不开放审计是为了控制内部审计日志的开销但安全要求高的场景必须打开。这里有个容易误解的点audit_enabled只决定“要不要记录”它不决定“记录哪些租户”。sys 租户和业务租户是两套逻辑业务租户开了总开关就能审sys 租户还要叠加单独的参数。我第一次测试的时候只开了总开关结果在 sys 租户里执行了一堆操作审计表里静悄悄后来补上audit_sys_operations才看到记录。这个坑后面细说。2.2 开启审计的标准操作与验证方法我在测试环境里的操作是分两步走的。第一步先开总开关在 sys 租户下执行ALTER SYSTEM SET audit_enabled True;注意这里有个细节ALTER SYSTEM SET在 OceanBase 里是集群级生效不需要在每个 OBServer 上单独设置。执行完以后我习惯用下面这条确认参数在所有节点上的值都是 True避免出现某个节点参数没刷新的假象SHOW PARAMETERS LIKE audit_enabled;第二步再根据测试需要打开 sys 租户审计ALTER SYSTEM SET audit_sys_operations True; ALTER SYSTEM SET audit_sys_user_operations True;参数开完以后我没有直接跑大场景而是先做了两个小验证。一是执行一条无关紧要的 SQL比如在业务租户里SELECT 1然后立刻去查对应的审计内部表有没有新增记录二是故意用错误密码登录一次再查登录审计表。如果这两条路都有记录说明审计链路是通的。这个方法比单纯看参数靠谱得多因为参数开了不代表所有环节都正确特别是涉及多节点和代理的场景眼见为实。注意审计参数属于集群级配置修改后建议通过SHOW PARAMETERS核对全部 OBServer 节点再用真实操作验证不要只看一条命令的返回结果就认为审计已生效。3. 测试场景设计与执行3.1 不同操作类型的审计范围在开始跑场景之前先明确一下这次要覆盖的范围。我把审计场景分成四类每一类的关注点不一样登录审计关注登录成功、密码错误、用户不存在、IP 来源、通过 OBProxy 与直连 OBServer 的区别DDL 审计关注建表、删表、修改表结构这类高风险操作的记录是否完整包括表名、语句、执行用户DML 审计关注 INSERT、UPDATE、DELETE 这类数据变更的记录以及 SELECT 的记录策略权限审计关注 CREATE USER、GRANT、REVOKE、ALTER USER 这类账号权限操作的记录。这样分类的好处是每一类操作对应的问题域是清楚的比如登录审计要回答“暴力破解能不能被发现”DDL 审计要回答“误删表能不能查到责任人”权限审计要回答“权限提升有没有留痕”。测试的时候按这个框架设计用例后面整理成报告也方便直接交付给安全团队。3.2 测试账户与用例清单我在业务租户里创建了两个测试用户一个模拟普通业务账号 aud_user一个模拟管理员账号 aud_dba密码都设置成符合生产强度要求的复杂密码。然后设计了一份用例清单每条用例包含操作描述、执行用户、预期审计结果三列用例编号操作内容执行用户预期结果TC01正常登录业务租户aud_user登录审计表新增成功记录TC02使用错误密码登录aud_user登录审计表新增失败记录TC03登录不存在的用户任意登录审计表新增失败记录TC04通过 OBProxy 登录后执行 SELECTaud_user操作审计表新增 SELECT 记录TC05创建测试表 tbl_auditaud_dba操作审计表新增 CREATE TABLETC06修改表结构增加字段aud_dba操作审计表新增 ALTER TABLETC07删除业务表aud_dba操作审计表新增 DROP TABLETC08插入、更新、删除数据aud_user操作审计表新增 DML 记录TC09创建新用户并授予权限aud_dba操作审计表新增用户与授权记录TC10回收权限aud_dba操作审计表新增 REVOKE 记录用例设计的原则是不追求把所有语句类型都穷举一遍而是把最有审计价值的动作覆盖到。CREATE USER、GRANT 这类操作是所有安全审计里必查的项目所以单独拆出来即便它们跟 DDL 在实现上同属一类记录也值得单独验证。另外每个用例都配上预期结果跑完以后能快速判断是功能异常还是预期行为省去反复猜测的麻烦。4. 核心场景实测与结果分析4.1 登录审计成功与失败记录的真实差异登录审计记录落在内部表__all_tenant_audit_login里查询时需要切到 sys 租户。我执行了 TC01 到 TC03 之后用下面的 SQL 查结果SELECT tenant_id, user_name, client_ip, server_ip, cmd_type, result, ret_code, login_time FROM oceanbase.__all_tenant_audit_login WHERE tenant_id 业务租户ID ORDER BY gmt_create DESC LIMIT 20;实测下来正常登录的记录 result 是 0表示成功错误密码和用户不存在的记录 result 非 0同时 ret_code 会带上具体的错误码。测试中密码错误场景返回的错误码是 4012对应的就是访问被拒绝这一类权限错误用户不存在场景同样落在 4012 上区别主要体现在 user_name 上。这个结果符合预期也说明失败登录确实会老老实实落在审计表里。这里有个有价值的细节失败的登录也会沉淀到同一张表里而且记录时间精确到毫秒。这就意味着如果线上出现大量连续失败登录完全可以直接通过这张表做来源 IP 聚合分析定位是不是暴力破解。我测试完顺手跑了一条聚合 SQL按 client_ip 统计失败次数效果很直观几秒钟就能列出来源排名。对于安全巡检来说这比翻应用日志高效得多。另一个值得注意的现象是 OBProxy 场景。通过 OBProxy 登录时client_ip 记录的是发起连接的客户端真实 IP而不是代理节点的 IP这对我这种靠审计日志做来源追溯的场景非常友好。直连 OBServer 时则记录的是实际来源 IP。两种方式都能定位到真实客户端但前提是网络环境里没有再做额外的 NAT 转发这点在网络拓扑复杂的现场环境要特别留意。4.2 DDL 操作审计结构变更全留痕DDL 是审计里最不能漏的一块。我用 aud_dba 依次执行了建表、加字段、删表三个操作对应 TC05 到 TC07然后查询操作审计表__all_tenant_audit_operationSELECT user_name, operation, object_name, status, execute_time FROM oceanbase.__all_tenant_audit_operation WHERE tenant_id 业务租户ID AND operation IN (CREATE TABLE, ALTER TABLE, DROP TABLE) ORDER BY gmt_create DESC;结果三条记录全都命中operation 字段很干净CREATE TABLE、ALTER TABLE、DROP TABLE 分得清清楚楚object_name 是操作对象的完整名字status 表示执行结果。这里我特意看了一眼即使 DROP TABLE 执行成功记录里也一样完整这正好满足了“误操作能不能查”的诉求。执行语句本身也存在审计记录里字段叫 exec_statement。我验证过DDL 的语句是完整保留的不像部分高频查询会被截断处理。这一点在生产上很有用——查结构变更事故时不光能看到谁在什么时间 DROP 了表还能看到完整的语句上下文包括是不是带 IF EXISTS、是不是带分区定义。我见过不少线上的结构变更事故最后定责靠的就是这条记录。4.3 DML 与 SELECT 的审计策略DML 场景我跑的是 TC08分别执行了 INSERT、UPDATE、DELETE。查询操作审计表以后三条语句都有对应记录operation 字段分别是 INSERT、UPDATE、DELETEobject_name 指向目标表exec_statement 能看到实际执行的语句。这个结果说明对于数据变更类操作审计的覆盖是可靠的业务上最关心的“谁改了数据”有据可查。不过 SELECT 的情况跟 DML 不完全一样。我连续执行了多次 SELECT审计表里也确实出现了 SELECT 记录但这里要提醒一句生产环境如果对某张高频表做全量 SELECT审计日志的膨胀速度会非常快。OceanBase 的审计机制会把执行的 SQL 语句写进内部表QPS 一高内部表的写入压力就上来了。所以我的建议是业务核心表的高频查询审计要谨慎优先保证登录、DDL、权限、DML 这些高价值动作SELECT 审计结合业务安全等级按需取舍不要一上来全量审计。4.4 权限变更审计最容易忽略的高危动作TC09 和 TC10 我验证的是 CREATE USER 和 GRANT/REVOKE。这两类操作在操作审计表里的记录非常清晰operation 字段能区分出 CREATE USER、GRANT、REVOKEobject_name 和 exec_statement 里能看到被操作的用户名和权限明细。我特意模拟了“管理员创建高权限账号并授权全部权限”的操作审计记录里完整还原了这条授权链路。权限变更审计的意义在于数据库的权限链条是安全的基础一旦出现越权提权行为你要能追溯到是谁、什么时候、给谁加了什么权限。我在实际项目里遇到过权限被莫名放大的事件最后就是靠授权审计记录定位到具体会话和客户端 IP 的。对安全团队来说这类记录是事故分析的核心证据所以就算其他审计项可以缩权限变更审计我从来都是默认全开的。5. 审计记录字段解读与日志维护5.1 关键字段含义对照在真正用审计数据之前先把字段含义搞清楚能少走很多弯路。我把登录审计表和操作审计表的核心字段整理成两张简表登录审计__all_tenant_audit_login关键字段字段名说明tenant_id所属租户 IDuser_name登录用户名client_ip客户端真实 IPserver_ip实际接入的 OBServer IPcmd_type连接类型登录/登出result执行结果0 为成功ret_code错误码失败时非 0login_time登录时间session_id会话 ID操作审计__all_tenant_audit_operation关键字段字段名说明tenant_id所属租户 IDuser_name执行用户client_ip客户端来源 IPoperation操作类型比如 CREATE TABLE、GRANTobject_name操作对象如表名、用户名status执行状态0 为成功ret_code错误码execute_time执行时间exec_statement实际执行的语句session_id会话 ID这里我特别想说一下 client_ip 和 server_ip 的区别。client_ip 是发起请求的客户端地址server_ip 是这次请求实际打到哪台 OBServer。在多节点集群里同一个客户端的请求可能分布在不同的 OBServer 上只看 server_ip 会以为来源分散了实际上要看 client_ip 才能聚合出真实来源。我在测试时把这两列单独拉出来对照过刚开始很困惑为什么同一个客户端一会儿出现在这台机器一会儿出现在那台后来才意识到这是负载均衡的正常效果。这个细节在做跨节点追溯时特别重要。5.2 审计日志的存储、查询与清理审计记录存在内部表里默认没有独立存储目录所以它会占用租户的资源。测试阶段数据量不大看不出问题但生产环境必须提前规划容量。我的做法是给审计表的增长做一轮估算按照业务 QPS、每条审计记录平均大小、留存周期三个参数算出来再决定日志保留策略。比如每天产生多少条审计、单条记录大概多少字节、目标保留 30 天乘一下就是需要的存储增量再把这个值纳入容量规划表。查询方面除了按时间过滤我建议提前建好两个维度一是按 tenant_id 过滤避免把多个租户的审计记录混在一起查二是按操作类型过滤比如只查 DROP 和 GRANT 相关记录定位高危动作更快。清理方面OceanBase 的审计内部表没有像日志文件那样的自动轮转机制需要自己定期清理。我测试时采用的是按时间范围 DELETE 的方式只清理超过留存周期的历史记录保留最近 30 天的数据用于安全回溯。清理前务必在测试环境演练并且要确认删除条件不会误伤在线审计记录这个动作只适合 sys 租户操作。注意审计表数据不适合长期无限堆积建议配一个“审计表当日新增行数”的监控指标超过阈值提前告警别等磁盘满了再处理。6. 常见问题与排查实操记录6.1 审计开了却没记录先查这五个点第一次测试时我就遇到过开启 audit_enabled 之后业务操作审计表里一条记录都没有的情况。排查了一遍发现问题出在登录的用户和租户匹配上。这里把最常见的五个坑列出来查错了租户。审计记录按租户隔离业务租户的操作要拿业务租户的 tenant_id 过滤用 sys 租户的 ID 去查当然查不到。登录用户不在审计范围。sys 租户默认不审计业务租户也需要确认用户确实是在该租户内执行的 SQL。参数只在单节点生效。集群环境下个别节点参数没刷新请求恰好打到那个节点导致部分操作没记录。时间过滤条件不对。审计表里时间字段是精确到毫秒的用太粗的时间范围容易把记录过滤掉我第一次就是 WHERE 条件写严了。连接串走到了非预期路径。通过 OBProxy 和使用直连地址记录的 server_ip 不一样如果只盯着某一台机器的日志看会漏掉另一部分。排查思路就一句话先查参数再查租户 ID最后用一次确定性的操作比如错误密码登录做小范围验证。别一上来就怀疑功能有问题大多数时候是查的方式不对。6.2 性能影响与日志膨胀的处理审计不是零成本的。开启审计之后每个被审计的操作都会多一次内部表的写入这对高并发业务是有影响的。我实测过的经验是在低 QPS 的测试场景下感知不明显但在几百并发连续写入的场景下审计表的写入会成为额外负担。测试时我开过一个短时间的高并发写入用例审计表的行数增长曲线几乎是直线上升虽然 OBServer 本身没有出现明显抖动但这种额外开销在高配低延迟要求的业务里不容忽视。我的建议是按阶段启用审计第一周只审计登录和 DDL 高危操作先把链路跑通第二周再评估是否需要开启 DML 审计SELECT 审计除非安全要求强制否则建议默认关闭或者只针对特定对象临时开启。日志膨胀的处理也不是等爆了再清理而是要先定好留存周期然后通过定时任务清理避免手工清理的随意性。清理任务的执行时间建议放在业务低峰期减少对审计写入链路的干扰。6.3 多租户与代理场景的典型误区多租户场景下最容易犯的错是拿业务租户的管理员账号去查审计内部表。OceanBase 的审计内部表属于系统表只能从 sys 租户访问业务租户的管理员即使权限再高也不应该在业务租户里执行内部表查询。正确做法是统一从 sys 租户查询再按 tenant_id 分发。我在测试里特意用业务租户的管理员试了一次直接报权限不足这其实是对的保护机制。OBProxy 场景还有一个细节如果 OBProxy 后面的 OBServer 发生切换连接会重建审计记录里可能出现多次登录记录。这属于正常现象不能误判成反复登录。判断方式很简单看时间戳和 server_ip 字段如果是毫秒级连续多次登录大概率是代理重建连接而不是真实用户在频繁登录。另外测试过程中我还发现审计日志里的 exec_statement 对于超大 SQL 可能做截断展示真正要拿完整语句做分析时不能只依赖审计表这一条链路最好结合应用侧日志交叉验证两条路对上了才敢下结论。7. 最后说点个人体会测完这一轮我的感受是 OceanBase 的审计功能在设计上足够完整登录、DDL、DML、权限都有对应的审计记录字段也考虑了来源 IP、执行结果、错误码这些安全分析最常用到的维度。但功能完整不代表直接打开就能用参数层级、租户隔离、日志维护这几个点必须在启用之前就想清楚。我个人现在的新项目里已经养成了一个习惯任何新数据库上线第一周就把登录审计和 DDL 审计开着哪怕是测试环境等真正出问题的时候再开就晚了。最后提醒一句无论你的审计策略怎么定都一定要在正式环境切换前做一次小流量验证确认记录真实落库、查询路径正确、清理策略无副作用再逐步放开。审计这玩意平时看着不起眼关键时候就是救命稻草。