企业官网建设流程全解析

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_tenant（MySQL 模式），里面创建了专门用于测试的普通用户 aud_user 和管理员用户 aud_dba，避免全程用 root 操作导致审计结果缺乏区分度。

测试思路分成四条线：第一条是参数线，确认审计相关的参数怎么开、开到什么程度；第二条是场景线，覆盖登录、DDL、DML、权限变更四类核心动作；第三条是查询线，验证审计记录落在哪张表、字段怎么解读；第四条是问题线，记录测试过程中真实遇到的不符合预期的现象，以及排查过程。这样组织的好处是，最后不管是给安全团队交报告，还是给自己留一份可复用的操作手册，都有一条清晰的主线。

提示：本文所有命令执行环境为 OceanBase 4.2.1 的 MySQL 模式，其他版本或模式下的参数行为和表结构可能存在差异，以你实际部署的版本为准。

2. 审计开启：参数配置全解析

2.1 核心参数逐个拆解

OceanBase 的审计功能由一组 audit 前缀参数控制，平时用SHOW PARAMETERS LIKE '%audit%'就能看全。这里我把最关键的几个参数和它们的作用整理了一下：

一句话总结：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 不同操作类型的审计范围

在开始跑场景之前，先明确一下这次要覆盖的范围。我把审计场景分成四类，每一类的关注点不一样：

1. 登录审计：关注登录成功、密码错误、用户不存在、IP 来源、通过 OBProxy 与直连 OBServer 的区别；
2. DDL 审计：关注建表、删表、修改表结构这类高风险操作的记录是否完整，包括表名、语句、执行用户；
3. DML 审计：关注 INSERT、UPDATE、DELETE 这类数据变更的记录，以及 SELECT 的记录策略；
4. 权限审计：关注 CREATE USER、GRANT、REVOKE、ALTER USER 这类账号权限操作的记录。

这样分类的好处是，每一类操作对应的问题域是清楚的，比如登录审计要回答“暴力破解能不能被发现”，DDL 审计要回答“误删表能不能查到责任人”，权限审计要回答“权限提升有没有留痕”。测试的时候按这个框架设计用例，后面整理成报告也方便直接交付给安全团队。

3.2 测试账户与用例清单

我在业务租户里创建了两个测试用户，一个模拟普通业务账号 aud_user，一个模拟管理员账号 aud_dba，密码都设置成符合生产强度要求的复杂密码。然后设计了一份用例清单，每条用例包含操作描述、执行用户、预期审计结果三列：

用例设计的原则是：不追求把所有语句类型都穷举一遍，而是把最有审计价值的动作覆盖到。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_operation：

SELECT 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、DELETE，object_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、REVOKE，object_name 和 exec_statement 里能看到被操作的用户名和权限明细。我特意模拟了“管理员创建高权限账号并授权全部权限”的操作，审计记录里完整还原了这条授权链路。

权限变更审计的意义在于：数据库的权限链条是安全的基础，一旦出现越权提权行为，你要能追溯到是谁、什么时候、给谁加了什么权限。我在实际项目里遇到过权限被莫名放大的事件，最后就是靠授权审计记录定位到具体会话和客户端 IP 的。对安全团队来说，这类记录是事故分析的核心证据，所以就算其他审计项可以缩，权限变更审计我从来都是默认全开的。

5. 审计记录字段解读与日志维护

5.1 关键字段含义对照

在真正用审计数据之前，先把字段含义搞清楚能少走很多弯路。我把登录审计表和操作审计表的核心字段整理成两张简表：

登录审计（__all_tenant_audit_login）关键字段：

操作审计（__all_tenant_audit_operation）关键字段：

这里我特别想说一下 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 之后，业务操作审计表里一条记录都没有的情况。排查了一遍，发现问题出在登录的用户和租户匹配上。这里把最常见的五个坑列出来：

1. 查错了租户。审计记录按租户隔离，业务租户的操作要拿业务租户的 tenant_id 过滤，用 sys 租户的 ID 去查当然查不到。
2. 登录用户不在审计范围。sys 租户默认不审计，业务租户也需要确认用户确实是在该租户内执行的 SQL。
3. 参数只在单节点生效。集群环境下个别节点参数没刷新，请求恰好打到那个节点，导致部分操作没记录。
4. 时间过滤条件不对。审计表里时间字段是精确到毫秒的，用太粗的时间范围容易把记录过滤掉，我第一次就是 WHERE 条件写严了。
5. 连接串走到了非预期路径。通过 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 审计开着，哪怕是测试环境，等真正出问题的时候再开就晚了。最后提醒一句，无论你的审计策略怎么定，都一定要在正式环境切换前做一次小流量验证，确认记录真实落库、查询路径正确、清理策略无副作用，再逐步放开。审计这玩意，平时看着不起眼，关键时候就是救命稻草。