如何应对事关业务生死的数据泄露和删改？-InfoQ

一、引言

1. 什么是数据库审计？

对于一个仓库，如果要防盗，常见做法是出入口全装上监控，一旦有问题了，调监控查找异常情况。对数据库来说也类似，数据库也有出入口，对所有连接出入口监控，可以记录下所有的动作，一旦有问题了，通过查询历史动作并进行分析，可以找到关键信息。

故数据库审计可以理解为是记录用户访问数据库行为，定位非法动作，事后追根溯源，提高数据库安全性的功能。

2. 常见的审计方式

常见的审计方式包括以下几个类别：

（1）应用层审计

在应用系统中直接审计，语句还没往数据库后台发就先做了审计，不影响数据库性能，对底层用的是什么数据库也不关心，但对应用系统压力比较大，并且应用系统需要解析语句，有一定复杂度。

（2）传输层审计

往往抓包解析实现，对上下层都没什么影响，但同样要解析语句，有一定复杂度，并且如果传输层是通过加密通讯，将无法解析。

（3）内核审计

直接在内核上实现，所有功能都能实现，也能将性能影响降到最低，但是对后台稳定性会有影响，对开发人员要求高，不管是开源还是非开源数据库，都会非常慎重考虑直接在内核上支持审计。

（4）插件审计

对于开源数据库，通常都有提供插件方式增加功能。审计可以以插件直接嵌在内核上，当然会对数据库性能有一定影响，但同样因为直接嵌在内核，很多一手信息能直接拿到，比方说上面没办法回避的语法解析就不用做，而且还能直接拿更多的运行态信息，能开发功能强大又灵活的审计功能。

其中插件式审计由于对内核侵入小，可以动态安装、卸载和升级等优点，是较受青睐的审计实现方式。MySQL 上也有不少审计插件，例如 Macfee 插件，官方 audit plugin，mariadb audit plugin，Percona audit plugin。

从功能上而言，审计插件大同小异，只是展示的审计内容和格式略有差异。从实现方式而言，审计插件的数据来源近乎相同，而在规则过滤和刷盘策略上有较大的差别。从性能上而言，除了 macfee 插件外，其它几个性能相差不多，宣称都是 15%左右影响，macfee 则可能达到 50%或更多。

总体而言，审计的性能影响不能一概而论，其与使用场景强相关。审计以 query 为单位记录审计日志，性能开销与 QPS 成正比。在 OLAP 场景下，一条 query 运行几秒，甚至几十秒，此时审计对性能的影响几乎可以忽略不计。如果场景被设定为简单查询语句，QPS 高达几十万的话，可想而知对性能会造成一定影响。

3. MySQL 官方审计插件

MySQL 支持了 MYSQL_AUDIT_GENERAL_ALL、MYSQL_AUDIT_CONNECTION_ALL 等十余种审计插件的类型，用于对客户端连接、query 处理、error log 日志落盘、general log 落盘等场景进行审计，审计插件的接口实现在 sql 目录下的 sql_audit.h 和 sql_audit.cc 中。

不同的插件类型对应不同的代码观察点。审计插件的定义中需要选择一种或多种注册类型，审计插件安装后，相应的代码观察点即可被激活。当程序运行到被激活的代码观察点处时，将携带这些审计信息跳转至审计插件定义的对应观察点处理函数中，进行审计日志的规则判断，落盘等处理。

Query 在运行过程中，程序会记录诸如用户名、客户端 ip、操作类型等审计信息。以 MYSQL_AUDIT_GENERAL_ALL 为例，其记录的审计信息如下所示：

二、TXSQL 审计的实现

TXSQL 是腾讯云数据库团队维护的 MySQL 内核分支，100%兼容原生 MySQL 版本，TXSQL 提供了类似于 MySQL 企业版的诸多功能，如企业级透明数据加密、审计、线程池、加密函数、备份恢复等功能。

1. 数据库审计架构

腾讯云数据库 MySQL 提供了基于 TXSQL 内核插件的数据库审计服务，其沿用了官方审计插件接口，并支持同步审计、异步审计两种审计架构。

（1）同步审计模式

同步审计模式的架构如下图所示，左侧灰色部分对应数据库服务器 mysqld，它采用线程池中相对固定的工作线程来处理所有用户的连接。工作线程每执行一个 query 或处理一个新的连接会生成一个审计 event。

工作线程需要结合审计规则判断当前 event 是否需要记录，如果需要记录，则将审计 event 按一定格式转化为审计日志，并拷贝到公共的 Audit buffer 中。

Flush thread 负责异步将 Audit buffer 中的审计日志落盘到本地。Audit agent 负责将本地的 audit log 推送到 CTSDB（腾讯云推出的一款分布式、可扩展、支持近实时数据搜索与分析的时序数据库）上进行存储，并提供查询。

接下来，详细介绍一下同步审计的实现。下图左侧是一条 query 的执行过程，包括连接，语句解析、分析、语句重写、语句优化、语句执行、语句返回和资源释放等几个步骤。

为了能获取 query 执行的影响行数、执行时间、错误码等内容，TXSQL 审计选择了在语句返回之后，资源释放之前的观察点处理审计逻辑。

上图右侧是同步审计的具体流程，工作线程在语句返回之后、进入审计观察点，如果实例没有开启审计，则直接进入资源释放步骤。

如果用户开启了审计，进一步判断当前审计 event 是否需要记录。如果需要则获取审计内容并计算审计内容的长度。

计算完审计日志长度后，加锁在公共 Audit buffer 中进行内存占位，接下来立刻释放锁，在无锁的情况下将审计 event 转化为 json 格式的审计日志并拷贝到公共 Audit buffer 中已占领的位置处。Flush 线程异步将 Audit buffer 中的审计日志落盘到本地，等待 Audit agent 进行消费。

（2）异步审计模式

同步审计模式在绝大多数场景下性能优异，但是在配置了多个正则审计匹配规则并且 QPS 非常高的场景下将出现大幅的性能下降。

性能下降的根因是正则匹配的过程中需要 malloc 内存，在高并发高压力下 malloc 系统调用在内核态出现锁瓶颈，影响了整体性能。为了解决同步审计在个别场景下的性能问题，TXSQL 还支持了异步审计模式。

上图是异步审计的架构图，由图可见，工作线程只需要将 audit event 交付给审计 event 队列后即可返回。新增 write thread 负责消费审计 event 队列，并完成剩余的审计规则判断、内存拷贝等工作。

由于每个时间点并发 malloc 的线程数大幅下降，因此 malloc 系统调用的锁瓶颈不复存在。

下图是异步审计的具体实现。write thread 负责观察审计 event 队列，如果有需要处理的 audit event，则将其摘下进行审计规则判断，如果需要记录该审计 event 则进一步进行审计内容长度计算、加锁进行内存占位、无锁内容转换和内存拷贝等工作。

2. 数据库审计规则

目前 TXSQL 的数据库审计支持以下类型设置：客户端 IP，数据库帐户，数据库名。支持的匹配方式为：包含，不包含，等于，不等于，正则方式匹配。

每条规则为一个结构对象，多条规则为一个链表，规则保存在内存中，全局共享，审计启动时从规则配置文件加载，修改、增加、删除时重新加载。

Rule list: 规则链表，每个规则对应前台配置的一个或多个，不能合并的多个规则之间是或（||）关系。

Content list: 单个审计规则，规则内容包含 username，host, database3 项。在 Content 规则内部，不同内容项之间是与（&&）的关系。

结构简图如下：

3. 数据库审计性能

TXSQL 提供的数据库审计开启后，对用户的数据库实例会有少许性能损耗，但远低于业内的其他解决方案。（业务使用场景、QPS、规则设置等均会影响数据库审计的性能开销）

同步审计模式的最大的特点在于工作线程在生产审计日志的过程中，计算审计内容长度、内容 json 转换和 Audit buffer 拷贝都是在无锁的情况下进行的。

整个过程只有内存占位需要持有锁，临界区足够小，使得 Audit buffer 的写锁没有成为系统瓶颈，从而在绝大多数场景下保持了极高的性能。平均的性能影响只有 6%。

异步审计模式对数据库审计性能有了进一步的提升，对实例的性能损耗更低。不论在正则规则下，还是在普通规则下，性能损耗最高只有 3%左右，其能力领先于业界其它的数据库审计插件。

4. 数据库审计最佳实践

理论上可以不对规则条数和语法进行做限制，但必须说明数据库审计的规则对整体性能消耗会产生一定的影响，为了能够在相同的规则下降低对数据库数据库实例的性能影响，提升数据库审计能力，在这里提出以下几点审计规则的最佳实践：

（1）规则合并

多个规则之间如果指定的类型相同，应该尝试合并规则。如 A 规则审计数据库 db1 的 select 操作，B 规则审计数据库 db1 的 update 操作，应当合并成审计 db1 的 select 和 update 操作。

（2）优先原则

对同个实例上不能合并的多个审计规则，优先使用命中率高的特征。只要有一个规则匹配上就会对该 SQL 进行审计，其它规则不需要再进行判断，因此需要把命中率最高的规则放前面优先用。

（3）正则表达式最后匹配

在规则内部，容易否定的规则项优先匹配，精确范围值优先匹配，然后精确值，然后不包含和包含值，最后正则表达式值。

三、结语

TXSQL 提供了同步和异步两种审计模式，内置丰富的审计规则，满足不同用户的个性化需求，同时在性能损耗方面把控得十分优秀，一般情况下的内存损耗只有 3%，远低于业界其他插件。

有了 TXSQL 的审计功能，DBA 就能够实时查看数据库活动，对于数据库的所有操作都会有迹可循，当数据库遇到疑似风险行为时，及时进行处理，对攻击行为进行阻断。

同时，借助 TXSQL 审计不同的审计模式，丰富的规则和超低的性能损耗，可以让 DBA 专注于运维本身，通过对用户访问数据库行为的记录、分析和汇报，进行事后生成合规报告、事故追根溯源，最终加强内外部数据库网络行为记录，提高数据资产安全。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

如何应对事关业务生死的数据泄露和删改？

发布

暂无评论