关键字:init—connect,binlog,trigger 概述: 其实mysql本身已经提供了详细的sql执行记录–general log ,但是开启它有以下几个缺点 无论sql有无语法错误,只要执行了就会记录,导致记录大量无用信息,后期的筛选有难度。 sql并发量很大时,log的记录会对io造成一定的印象,是数据库效率降低。 日志文件很容易快速膨胀,不妥善处理会对磁盘空间造成一定影响。 基本原理: 由于审计的关键在于DML语句,而所有的DML语句都可以通过binlog记录。 不过遗憾的是目前MySQL binlog 中只记录,产生这条记录的connection id(随连接数自增,循环使用),这对之后的反查没有任何帮助。 因此考虑通过init-connect,在每次连接的初始化阶段,记录下这个连接的用户,和connection_id信息。 在后期审计进行行为追踪时,根据binlog记录的行为及对应的connection-id 结合 之前连接日志记录 进行分析,得出最后的结论 声明: 本文只是探讨思路的可行性,并没有经过严格的线上测试。请慎重使用在生产环境! 正文: 1. 设置init-connect 1.1创建用于存放连接信息的表 createdatabase AuditDB default charset utf8;use AuditDB;createtable accesslog (ID intprimarykey auto_increment,ConnectionID int, ConnUserName varchar(30), PrivMatchName varchar(30), LoginTIme timestamp); 1.2 保证所有的用户对此表有写权限 1.3 设置init-connect 在my.cnf 中的 [mysqld] 的block 添加以下配置;
1.4 重启数据库生效 2. 记录追踪2.1 thread_id确认 假设想知道在2009年11月25日,上午9点多的时候,是谁吧test.dummy这个表给删了。可以用以下语句定位 mysqlbinlog –start-datetime=’2009-11-25 09:00:00′ –stop-datetime=’2009-11-25 09:00:00′ binlog.xxxx | grep ‘dummy’ -B 5 会得到如下结果(可见thread_id为5): # at 300777 #09112416:54:00 server id 10 end_log_pos 301396 Query thread_id=5 exec_time=0 error_code=0SETTIMESTAMP=1259052840; droptable test.dummy; 2.2 用户确认 thread_id 确认以后,找到元凶就只是一条sql语句的问题了。 select ID,LoginTime,PrivMatchName,ConnUserName fromAuditDB.accesslog where ConnectionID=5 ; 就能发现是testuser2@localhost干的了。 +——+——————————-+——————————-+—————————–+|ID|LoginTime|PrivMatchName|ConnUserName|+——+——————————-+——————————-+—————————–+|5|2009-11-2510:57:39| testuser2@localhost| testuser2@%|+——+——————————-+——————————-+—————————–+ 3. Q&AQ:使用init-connect会影响服务器性能吗? A:理论上,只会在用户每次连接时往数据库里插入一条记录,不会对数据库产生很大影响。除非连接频率非常高(当然,这个时候需要注意的就是如何进行连接复用和控制,而非是不是要用这种方法的问题了) Q:access-log表如何维护? A: 由于是一个log系统,推荐使用archive存储引擎,有利于数据厄压缩存放。如果数据库连接数量很大的话,建议一定时间做一次数据导出,然后清表。 Q:表有其他用途么? A:有!access-log表当然不只用于审计,当然也可以用于对于数据库连接的情况进行数据分析,例如每日连接数分布图等等,只有想不到没有做不到。 Q:会有遗漏的记录吗? A:会的,init-connect 是不会在super用户登录时执行的。所以access-log里不会有数据库超级用户的记录,这也是为什么我们不主张多个超级用户,并且多人使用的原因。 |
mysql 开启审计日志
精选 转载文章标签 mysql 审计日志 文章分类 数据库
-
zabbix开启日志审计功能
序言:本文搭建日志审计系统,8g内存+1T硬盘,单机实现每秒3000eps的吞吐量,主要架构如下:客户端日志监听工具: evtsys:监听主机系统,网络设备的日志 filebeat:监听应用日志日志服务器接收日志: logstash:监听客户机发送的日志,做简单的处理,规整日志日志服务器存储日志: elasticsearch:存储日志,类似于nosql数据库,按
zabbix开启日志审计功能 elasticsearch logstash kafka beats