MySQL审计工具Audit插件使用

一、介绍MySQL AUDIT

MySQL AUDIT Plugin是一个 MySQL安全审计插件，由McAfee提供，设计强调安全性和审计能力。该插件可用作独立审计解决方案，或配置为数据传送给外部监测工具。支持版本为MySQL (5.1, 5.5, 5.6, 5.7)，MariaDB (5.5, 10.0, 10.1) ，Platform (32 or 64 bit)。从Mariadb 10.0版本开始audit插件直接内嵌了，名称为server_audit.so，可以直接加载使用。

二进制文件地址：https://bintray.com/mcafee/mysql-audit-plugin/release

macfee的mysql audit插件虽然日志信息比较大，对性能影响大，但是如果想要开启审计，请斟酌。

二、安装使用MySQL AUDIT

# unzip audit-plugin-mysql-5.6-1.1.5-774-linux-x86_64.zip

MySQL的插件目录为：

mysql>show global variables like 'plugin_dir'

+---------------+------------------------+

| Variable_name | Value                  |

+---------------+------------------------+

| plugin_dir    | /app/mysql/lib/plugin/ |

+---------------+------------------------+

1 row in set (0.00 sec)

复制库文件到MySQL库目录下

# cp audit-plugin-mysql-5.6-1.1.2-694/lib/libaudit_plugin.so /app/mysql/lib/plugin/

# chmod a+x /app/mysql/lib/plugin/libaudit_plugin.so

加载Audit插件

mysql>INSTALL PLUGIN AUDIT SONAME 'libaudit_plugin.so'

查看版本

mysql>show global status like '%audit%'

+------------------------+-----------+

| Variable_name          | Value    |

+------------------------+-----------+

| Audit_protocol_version | 1.0      |

| Audit_version          | 1.1.2-694 |

+------------------------+-----------+

2 rows in set (0.00 sec)

开启Audit功能

mysql>SET GLOBAL audit_json_file=ON

Query OK, 0 rows affected (0.00 sec)

执行任何语句(默认会记录任何语句)，然后去mysql数据目录查看mysql-audit.json文件(默认为该文件)。

当然，我们还可以通过命令查看audit相关的命令。

mysql>SHOW GLOBAL VARIABLES LIKE '%audit%'

其中我们需要关注的参数有：

1、audit_json_file

是否开启audit功能。

2、audit_json_log_file

记录文件的路径和名称信息。

3、audit_record_cmds

audit记录的命令，默认为记录所有命令。可以设置为任意dml、dcl、ddl的组合。如：audit_record_cmds=select,insert,delete,update。还可以在线设置set global audit_record_cmds=NULL。(表示记录所有命令)

4、 audit_record_objs

audit记录 *** 作的对象，默认为记录所有对象，可以用SET GLOBAL audit_record_objs=NULL设置为默认。也可以指定为下面的格式：audit_record_objs=,test.*,mysql.*,information_schema.*。

5、audit_whitelist_users

用户白名单。

三、查看审计数据

插入一些数据，查看一下mysql-audit.json文件信息（json格式），如下：

$ cat /app/mysql/data/mysql-audit.json

{"msg-type":"activity","date":"1517989674556","thread-id":"3","query-id":"39","user":"root","priv_user":"root","ip":"","host":"localhost","connect_attrs":{"_os":"Linux","_client_name":"libmysql","_pid":"1331209","_client_version":"5.6.27","_platform":"x86_64","program_name":"mysql"},"pid":"3472328296227680304","os_user":"0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","appname":"0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","rows":"10","cmd":"select","objects":[{"db":"sbtest","name":"sbtest1","obj_type":"TABLE"}],"query":"select * from sbtest1 limit 10"}

审计记录文件一般存放在mysql的数据目录下。

首先介绍下 pt-stalk，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。

pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息，这其中包括：

1. OS 层面的 CPU、IO、内存、磁盘、网络等信息；

2. MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。

而且 pt-stalk 是一个 Shell脚本，对于我这种看不懂 perl 的人来说比较友好，脚本里面的监控逻辑与监控命令也可以拿来参考，用于构建自己的监控体系。

三、使用

接着我们来看下如何使用这个工具。

pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件，当触发条件时收集相关诊断数据。

触发条件相关的参数有以下几个：

function：

∘ 默认为 status，代表监控 SHOW GLOBAL STATUS 的输出；

∘ 也可以设置为 processlist，代表监控 show processlist 的输出；

variable：

∘ 默认为 Threads_running，代表 监控参数，根据上述监控输出指定具体的监控项；

threshold：

∘ 默认为 25，代表 监控阈值，监控参数超过阈值，则满足触发条件；

∘ 监控参数的值非数字时，需要配合 match 参数一起使用，如 processlist 的 state 列；

cycles：

∘ 默认为 5，表示连续观察到五次满足触发条件时，才触发收集；

连接参数：host、password、port、socket。

其他一些重要参数：

iterations：该参数指定 pt-stalk 在触发收集几次后退出，默认会一直运行。

run-time：触发收集后，该参数指定收集多长时间的数据，默认 30 秒。

sleep：该参数指定在触发收集后，sleep 多久后继续监控，默认 300 秒。

interval：指定状态参数的检查频率，判断是否需要触发收集，默认 1 秒。

dest：监控数据存放路径，默认为 /var/lib/pt-stalk。

retention-time ：监控数据保留时长，默认 30 天。

daemonize：以后台服务运行，默认不开启。

log：后台运行日志，默认为 /var/log/pt-stalk.log。

collect：触发发生时收集诊断数据，默认开启。

∘ collect-gdb：收集 GDB 堆栈跟踪，需要 gdb 工具。

∘ collect-strace：收集跟踪数据，需要 strace 工具。

∘ collect-tcpdump：收集 tcpdump 数据，需要 tcpdump 工具。

1.存储引擎的选择如果数据表需要事务处理，应该考虑使用InnoDB，因为它完全符合ACID特性。如果不需要事务处理，使用默认存储引擎MyISAM是比较明智的。并且不要尝试同时使用这两个存储引擎。思考一下：在一个事务处理中，一些数据表使用InnoDB，而其余的使用MyISAM.结果呢？整个subject将被取消，只有那些在事务处理中的被带回到原始状态，其余的被提交的数据转存，这将导致整个数据库的冲突。然而存在一个简单的方法可以同时利用两个存储引擎的优势。目前大多数MySQL套件中包括InnoDB、编译器和链表，但如果你选择MyISAM，你仍然可以单独下载InnoDB，并把它作为一个插件。很简单的方法，不是吗？

2.计数问题如果数据表采用的存储引擎支持事务处理（如InnoDB），你就不应使用COUNT（*）计算数据表中的行数。这是因为在产品类数据库使用COUNT（*），最多返回一个近似值，因为在某个特定时间，总有一些事务处理正在运行。如果使用COUNT（*）显然会产生bug，出现这种错误结果。

3.反复测试查询查询最棘手的问题并不是无论怎样小心总会出现错误，并导致bug出现。恰恰相反，问题是在大多数情况下bug出现时，应用程序或数据库已经上线。的确不存在针对该问题切实可行的解决方法，除非将测试样本在应用程序或数据库上运行。任何数据库查询只有经过上千个记录的大量样本测试，才能被认可。

4.避免全表扫描通常情况下，如果MySQL（或者其他关系数据库模型）需要在数据表中搜索或扫描任意特定记录时，就会用到全表扫描。此外，通常最简单的方法是使用索引表，以解决全表扫描引起的低效能问题。然而，正如我们在随后的问题中看到的，这存在错误部分。

5.使用“EXPLAIN”进行查询当需要调试时，EXPLAIN是一个很好的命令，下面将对EXPLAIN进行深入探讨。

---