1. 审计功能整体设计与测试思路1.1 OceanBase审计到底是什么OceanBase作为分布式关系数据库天然要面对一个现实问题谁在什么时间对哪些数据做了什么操作这个问题在传统单机数据库上都不好回答放到分布式架构里更难。审计功能就是用来回答这个问题的——它按照你设定的规则把数据库里发生的操作记录下来形成一条条可追溯的审计记录。我这次测下来OceanBase的审计功能主要解决三类需求。第一类是合规审计等保、金融行业监管、企业内部安全规范都要求数据库具备审计能力出了安全问题能溯源第二类是业务安全追踪异常登录、越权访问、敏感表的查询行为第三类是故障排查数据莫名其妙被改了或者删了审计记录能帮你定位是谁干的。审计功能的定位决定了我怎么设计测试方案。它不像性能调优那样追求跑分也不像高可用切换那样看RPO/RTO审计功能的核心评价标准只有三条记不记得全、查不查得到、有没有干扰正常业务。围绕这三条我在测试环境上从配置、功能、性能、稳定性四个维度做了验证。1.2 两种审计模式应该怎么选OceanBase的审计分为用户级审计和租户级审计两个层面这个设计一开始容易把人绕晕。我花了不少时间才理清楚这里直接用最直白的方式说。用户级审计是细粒度的它针对具体的用户、具体的操作类型、具体的表对象做审计。比如我要审计哪个账号查了customer表就用用户级审计。它的特点是精确但配置成本高你得一条一条去定义规则。租户级审计是粗粒度的只要开启租户级审计开关这个租户下所有用户的所有操作都会记录特点是省事但会产生海量审计日志后期检索和存储压力都要考虑。选择逻辑其实很简单能明确知道要盯谁盯什么用用户级不知道谁会搞事情想全部留痕用租户级。最理想的用法是两者配合租户级兜底保证全量留存用户级针对核心敏感表做精细化记录。我这次测试两种都跑了为的是摸清各自的性能和存储开销方便后续给生产环境制定方案。1.3 测试目标与评判标准测试之前我列了一份评分表每一项都有明确的验收条件避免测完说不清楚效果怎么样。测试维度测试内容验收标准功能完整性DML、DDL、登录、失败操作是否被记录各类操作均能产生对应审计记录记录准确性审计记录中的用户、时间、对象、SQL内容是否正确与实操记录完全一致配置灵活性用户级、租户级审计能否独立开关配置后即时生效互不影响性能影响开启审计前后QPS、TPS、延迟变化性能损耗可接受业务无感知稳定性连续写入审计日志观察是否有阻塞、丢日志长时间运行稳定无异常这个表是后面几天测试的总纲每完成一项就勾一项。实际执行下来有些结果在预料之内有些结果确实让我重新审视了之前的一些判断这些细节后面都会单独展开。2. 测试环境准备与核心参数配置2.1 环境清单与测试工具先交代一下测试环境。我用的是OceanBase 4.2.1版本三台服务器组成的集中式部署形态每台机器16核32G内存操作系统是CentOS 7.9。客户端工具用的OBClient压测工具是sysbench。整体架构不复杂但足够模拟生产环境的基本形态。有一点值得提醒审计功能测试尽量在独立的测试集群上做别拿开发环境直接开。因为租户级审计一旦开启所有操作都会记录系统日志表和审计文件会快速增长开发环境那点磁盘很容易被撑爆。我就是先在一台单机CentOS上把流程跑通再放到三节点集群上做并发测试。环境准备好了之后我习惯先做一件事记录基线状态。包括各个关键参数当前的配置值、sys租户下有哪些用户、测试租户的数据量大小。这样后面改配置、测功能回头对比时有个依据不会改完参数忘了原来是什么值。2.2 审计开关与核心参数逐项说明OceanBase审计功能的核心控制参数集中在几个系统变量上配错一个就可能导致审计记录缺失。我把关键的几个列出来按配置顺序讲。第一个是审计总开关。在系统租户下用ALTER SYSTEM SET audit_trail DB_EXTENDED;开启。这个参数有几个取值NONE表示关闭审计DB表示审计记录写入数据库内部的审计日志查询视图但不包含SQL文本DB_EXTENDED除了记录基本信息还会额外记录SQL文本和SQL绑定变量排查问题的时候信息更全。我推荐直接用DB_EXTENDED特别是你要分析具体操作内容时光有操作类型没有SQL文本等于白记。第二个是租户级审计开关参数是audit_tenant_level。同样在系统租户下执行ALTER SYSTEM SET audit_tenant_level ON;开启。这个参数一旦打开所有租户的所有操作都会进入审计范围属于重量级开关。使用前先想清楚日志量能不能扛住后面我会专门讲性能实测的结果。第三个是审计日志的落盘位置。OceanBase支持把审计记录写到操作系统日志文件里这个通过参数控制。我的建议是测试阶段同时开启数据库记录和OS文件记录两边对照着看更方便排查问题。生产环境如果审计要求严格也建议两边都开毕竟OS文件比数据库表更难被篡改合规审计更有说服力。参数修改有个细节audit_trail和audit_tenant_level都是动态参数用ALTER SYSTEM SET改完后即时生效不需要重启OBServer节点。我用OBClient执行完配置后立刻做了验证新产生的操作马上就被记录了效率很高。不过要注意ALTER SYSTEM SET需要在系统租户sys租户下执行普通业务租户没有这个权限。另外提一句OceanBase审计功能还支持通过audit_rule_action_type之类的参数控制具体记录哪些操作类型以及通过用户级审计命令细化到具体表。如果你只想审计SELECT不想审计INSERT可以通过这些参数做过滤。我这次为了验证全量记录先全部开启再逐步收窄规则看过滤效果是否正常。2.3 配置验证与一个容易踩的坑配置完之后最重要的一步是验证配置真的生效了。我见过太多人改完参数就以为审计开了结果一条记录都没有。验证方法很简单第一步在系统租户下执行SHOW VARIABLES LIKE audit_trail;和SHOW VARIABLES LIKE audit_tenant_level;确认参数值是DB_EXTENDED和ON第二步随便执行一条SQL然后查审计记录有记录说明通了。我第一次配置的时候就踩了一个坑在业务租户下执行了ALTER SYSTEM SET audit_trail系统直接报权限不足。当时我还以为是版本不支持排查了半天后来才反应过来必须在sys租户下操作。这个坑说大不大但确实浪费时间建议配置前先确认当前会话所在的租户。还有个容易忽略的点用户级审计命令AUDIT操作的不是单个用户而是要指定访问路径。比如AUDIT SELECT ON tpcc.customer BY access;这条命令表示对customer表的查询操作按访问次数记录审计。如果你写成BY SESSION那就变成按会话记录一个会话内对同一张表查十次只记录一次。BY ACCESS和BY SESSION的差异在生产环境选择时要想清楚追求审计证据完整性用BY ACCESS想控制日志量用BY SESSION。3. 功能实操验证过程从DML到DDL的全记录3.1 用户级审计的配置与验证用户级审计我是这样测的。先创建一个专门用于测试的普通账号audit_user授予它tpcc库下customer表的查询和修改权限。然后用这个账号执行AUDIT SELECT ON tpcc.customer BY ACCESS;命令紧接着就用这个账号跑了几条查询语句比如SELECT * FROM tpcc.customer WHERE c_id 1;然后再查审计记录看有没有对应记录。实际验证结果让我印象很深只要配置了审计规则用户一执行匹配的操作审计记录立刻就能查到不需要等刷新时间。审计记录里能看到操作时间、执行用户、操作类型、对象名、来源IP和SQL文本。customer表的查询操作被完整记录下来了SQL文本和SQL绑定变量都在拿去做问题溯源完全够用。接着我测试了DDL操作。用audit_user创建了一张临时表再执行DROP TABLE同样能看到对应的审计记录。DDL的审计记录比DML信息更丰富除了基本字段外还能看到执行脚本的完整文本。这对于追踪表结构变更非常有用比如线上突然有人删了一张表审计记录会清清楚楚地告诉你谁在什么时间执行的DROP TABLE。注意一个细节用户级审计只对该用户后续的操作生效配置之前这个用户已经执行过的操作不会被追溯记录。所以生产环境部署审计功能的时间点很重要越早开启越安全早开一天就多一天的数据可追溯。3.2 租户级审计的配置与验证租户级审计的配置我在前面已经提到了这里说下具体验证过程。在系统租户下开启audit_tenant_level ON之后我切换到业务租户里用普通账号做了几个操作查了一张表、改了一条数据、删了一张临时表、登录登出几次。然后回到系统租户查询审计记录这四种操作全部被记录在案。租户级审计的覆盖范围确实比用户级大得多日志量翻了好几个量级这是预料之内的。我大概估算了一下一个普通的OLTP业务每分钟产生几百次数据库交互如果全部记录一天下来就是几十万条审计日志存储压力非常明显。这也印证了一个观点租户级审计是最后的兜底手段不能轻易全量开启至少要在上游做好日志归档策略。还有一个发现值得一说登录登出也会有审计记录。不管是成功登录还是密码错误登录失败都有对应记录。这个对安全排查太重要了。你想一下如果有人拿着弱口令尝试登录数据库审计记录里全是失败尝试记录这能在第一时间帮你发现暴力破解的苗头。我在测试时故意用错误密码连续登录了十次每次失败的尝试都被记录得清清楚楚包括来源IP和连接时间。安全上你可以设定阈值连续多次审计失败后人工介入这个能力比业务侧自己埋点要可靠得多。租户级审计还记录了一个容易被忽略的信息操作是在哪个租户下执行的。多租户场景下这个字段特别有用生产环境通常一个集群跑多个业务租户出了问题能快速定位是哪个业务侧的哪个操作导致的。3.3 审计记录内容解析与查看方式审计记录怎么查、长什么样我觉得还是直接展示字段更直观。核心的审计查看方式是通过系统视图或表查询。OceanBase的审计记录在数据库内部会写到特定的系统日志表和视图中你可以执行类似SELECT * FROM audit_log_table WHERE ...这样的语句去查。由于不同版本的表名和视图名会有差异我这里不写死具体的表名大家测试时先用SHOW TABLES LIKE %audit%之类的命令去系统租户下搜一下找到对应的日志表或视图再查询。我在4.2.1版本上实测这个搜索方式是有效的。查出来的审计记录大致的字段包含操作时间精确到微秒、操作用户、客户端IP、数据库名、对象类型、操作类型SELECT/INSERT/DELETE等、SQL文本、执行结果成功或失败。组合起来就能还原一个完整的安全事件。举个例子我查到一条记录是audit_user在某个时间点执行了DELETE FROM tpcc.customer WHERE c_id 100来源IP是10.0.12.34执行成功。从这条记录出发你可以去问这个用户为什么要删除这条数据、是谁授权的、执行前有没有走变更流程。这一整套链路下来审计功能的价值才算真正体现。我还额外验证了两个细节。第一记录的时间戳很准确和客户端执行SQL的时间一致这对多租户、多节点场景下的时序排查很重要。第二SQL文本记录得比较完整参数值做了保留这样即使绑定变量场景下也能看到具体参数内容不会有参数被替换成问号导致看不明白的情况。3.4 特权用户操作与SQL失败操作怎么记录这个部分我特意单独测了因为和实际安全场景关系很大。特权用户的操作是否记录我用rootsys这个系统租户超级管理员账号在业务租户下执行了SELECT * FROM tpcc.customer LIMIT 1;然后去查审计记录。结果是没有对应记录。原因是系统租户的内置管理员账号属于集群管理层面默认不在用户级和租户级审计范围内。换句话说OceanBase有自己的安全设计逻辑审计功能本身是给业务租户和业务用户设计的不记录系统管理员的高权限操作。这也意味着在生产环境中系统管理员的高权限操作更多要依赖运维审计和堡垒机来做合规管控不能完全靠数据库自身审计。SQL执行失败是否记录我故意执行了几条错误SQL比如不存在的表、语法错误的SQL、权限不足的查询。结果让人满意失败的SQL同样被记录而且记录了失败原因。这个能力对检测攻击行为非常有用攻击者尝试注入或者越权时会产生大量失败的SQL记录有经验的安全人员通过分析这些记录能很快定位可疑行为。从测试结果来看只要是业务租户内的操作不论成功失败都会留下记录覆盖能力没问题。缺陷在于系统管理员操作默认不入库这个需要在企业安全方案设计时提前做好补充手段。4. 性能影响实测与结果分析4.1 性能测试方案与压测参数审计功能好不好用光看记不记得全还不够对正常业务有没有影响才是生产环境最关心的问题。我是用sysbench对同一张表做了三组对比测试关闭审计、开启租户级审计、开启用户级审计。每组测试跑5分钟用相同的并发线程数16和相同的表数据量50万行记录QPS、TPS、平均延迟、P95延迟这几个核心指标。选择sysbench的原因很简单它对OceanBase的支持成熟压测脚本改起来也方便。测试过程中我没有调整任何数据库参数保证三组测试的环境变量完全一致只有审计开关不同。这样测出来的差异才能归因到审计功能本身。测试数据我也做了个基准测试前用sysbench的oltp_read_write混合读写模式跑了一轮保证表结构和数据量都没问题。测试表是tpcc.customer50万行数据索引完整统计信息已更新。环境干净没有其他业务干扰。4.2 开启审计前后的性能数据对比实测数据我整理了一下放在下面的表格里。绝对值每个环境都不一样大家看相对变化就好。测试场景QPSTPS平均延迟(ms)P95延迟(ms)未开启审计2380019004.27.8开启用户级审计2150017505.19.3开启租户级审计1680013506.812.6结论很明确租户级审计对性能的影响最明显QPS下降了约30%延迟增加了超过60%用户级审计相对温和QPS下降约10%延迟增加约20%。这个差异背后的逻辑并不复杂租户级审计要对每条SQL都做记录I/O和CPU开销都上去了性能损耗自然大。我个人的建议是审计方式和业务形态要匹配。如果业务是交易类系统TPS高、延迟敏感慎用全量租户级审计优先选择用户级审计针对核心表做记录如果是管理类系统、后台数据维护平台并发低、操作频繁度低租户级审计也可以接受。生产环境上线审计功能前一定先做性能基线测试评估影响后再决定开不开。4.3 审计日志增长与磁盘风险评估这是一个很容易被忽视、但实际最麻烦的问题。审计日志的存储开销大多数人一开始都预估不足。我做了个简单测试来估算。在开启租户级审计的情况下随机执行了1000条DML操作查看审计日志占用的磁盘空间大约是几十MB的量级。以此推算如果一个中大型业务每天产生几万到十几万条操作审计日志一天的增量就可能达到数GB甚至更多一个月下来就相当可观了。日志增长太快带来两个后果。第一是磁盘空间可能被撑爆数据库写入失败甚至OBServer异常第二是审计记录查询性能下降日志表越来越大查一条记录要扫很久。应对的办法无非两个方向一是定期归档清理把旧的审计日志导出到外部存储保住数据库磁盘二是按需收窄审计范围比如业务租户只保留操作类型、不保留SQL文本或者只记录DDL不记录DML日志量能下降一大截。我测试完以后把租户级审计关掉了。生产环境如果要开启必须事先规划好日志保留周期、归档方案和磁盘容量否则审计功能带来的副作用可能比你想解决的问题还大。5. 常见问题与排查技巧实录5.1 审计记录查不到问题出在哪这是我测试中遇到的第一个问题也是群里朋友问得最多的一个问题——配置完审计之后执行了操作但查不到审计记录。排查思路从两个方向入手。第一个方向确认审计开关的生效范围。如果你把audit_trail配置在了某个业务租户上但用系统租户去查记录很可能查不到因为系统租户和业务租户的审计数据是分开管理的。我在测试中明确体会到了这一点租户级审计要在系统租户下配置用户级审计要在对应业务租户下配置查记录也要去对应租户查。第二个方向确认SQL操作确实落到了审计规则覆盖范围内。比如你配置了AUDIT SELECT ON tpcc.customer但实际执行的是SELECT COUNT(*) FROM tpcc.orders那自然没有记录。另外用户级审计的设置是对当前用户后续操作生效的如果切换了连接、换了用户之前配置的审计规则可能就不覆盖新用户了。最后一个容易忽略的问题是我没有查看对应版本的审计日志表名。不同版本的OceanBase审计日志的存储表名或视图名会有差异查错表当然什么都查不到。建议先在系统租户或者对应租户下执行SHOW TABLES LIKE %audit%找到正确的表名再去查询。5.2 修改审计参数不生效怎么办有朋友遇到过执行配置命令成功但查参数值发现没变的情况。我也遇到过类似问题一般是这几个原因。第一确认参数名没有拼写错误多一个字母少一个字母配置照样会报错或者静默失败。第二确认是在正确的租户下配置的audit_trail能不能在业务租户下配置每个版本限制不完全一样一律建议在系统租户下操作。第三确认参数配置已经COMMITALTER SYSTEM SET执行之后不是马上对所有会话生效的需要提交事务或等待参数刷新。如果这些都排除了还是不生效就考虑版本兼容性。OceanBase社区版和企业版在审计功能上可能有些差异某些参数在特定版本上不支持或行为不一致。遇到这种情况翻官方文档对照你当前版本的Release Notes确认功能支持范围。5.3 审计日志占用空间过大怎么处理测试环境无所谓生产环境审计日志铺天盖地增长迟早要出问题。我自己的处理思路供大家参考。第一设置合理的审计保留策略。能清理就清理能归档就归档不要让审计日志无限增长。第二控制审计粒度。前面已经反复提过业务上只需要DDL审计的话别把DML全量记录打开只需要记录敏感表查询的话尽量用用户级审计限定小范围。第三定期监控审计日志表大小和磁盘使用率建个简单的巡检脚本达到阈值自动告警。磁盘满了再动手就晚了。这个建议同样适用于其他数据库产品审计日志的管理是一个持续的过程不是配好就能一劳永逸的。5.4 关于审计功能测试的几点体会这套流程测下来我的一个核心感受是审计功能不是装上去就完事的它是一个需要持续运营的安全组件。配置占20%的精力日志管理、容量规划、性能评估、定期检查这些占80%。如果只是把开关打开就放着不管迟早会被审计日志的副作用反噬。第二点体会是任何安全能力都要结合业务场景做取舍。租户级审计覆盖全但性能消耗大用户级审计性能影响小但需要精细配置。做方案设计时先想清楚这个系统最重要的资产是什么最怕什么样的安全事件围绕这两个问题去定审计策略比上来就全量开审计要靠谱得多。最后分享一个小技巧测试完审计功能后记得清理测试数据。我在压测完成后把测试租户直接删掉了避免测试期间产生的海量审计日志占用磁盘空间。如果是生产环境审计数据要保留到合规要求的期限测试环境就没必要留着了该清理就清理。OceanBase的审计功能整体上讲是完整可用的能覆盖大部分企业安全审计的需求。但也别神话它系统管理员操作默认不记录这个限制就决定了数据库审计必须和外部审计手段结合才能形成完整的合规闭环。做数据库安全方案时把审计功能当成其中一块拼图而不是全部这才是稳妥的思路。