通過init-connect + binlog 實(shí)現(xiàn)MySQL審計(jì)功能
背景：
假設(shè)這么一個(gè)情況，你是某公司mysql-DBA，某日突然公司數(shù)據(jù)庫(kù)中的所有被人為刪了。
盡管有數(shù)據(jù)備份，但是因服務(wù)停止而造成的損失上千萬(wàn)，現(xiàn)在公司需要查出那個(gè)做刪除操作的人。
但是擁有數(shù)據(jù)庫(kù)操作權(quán)限的人很多，如何排查，證據(jù)又在哪？
是不是覺得無能為力？
mysql本身并沒有操作審計(jì)的功能，那是不是意味著遇到這種情況只能自認(rèn)倒霉呢？
本文就將討論一種簡(jiǎn)單易行的，用于mysql訪問審計(jì)的思路。

關(guān)鍵字：init—connect,binlog,trigger
概述：
其實(shí)mysql本身已經(jīng)提供了詳細(xì)的sql執(zhí)行記錄–general log ，但是開啟它有以下幾個(gè)缺點(diǎn)
無論sql有無語(yǔ)法錯(cuò)誤，只要執(zhí)行了就會(huì)記錄，導(dǎo)致記錄大量無用信息，后期的篩選有難度。
sql并發(fā)量很大時(shí)，log的記錄會(huì)對(duì)io造成一定的印象，是數(shù)據(jù)庫(kù)效率降低。
日志文件很容易快速膨脹，不妥善處理會(huì)對(duì)磁盤空間造成一定影響。
基本原理：
由于審計(jì)的關(guān)鍵在于DML語(yǔ)句，而所有的DML語(yǔ)句都可以通過binlog記錄。
不過遺憾的是目前MySQL binlog 中只記錄，產(chǎn)生這條記錄的connection id（隨連接數(shù)自增，循環(huán)使用），這對(duì)之后的反查沒有任何幫助。
因此考慮通過init-connect，在每次連接的初始化階段，記錄下這個(gè)連接的用戶，和connection_id信息。
在后期審計(jì)進(jìn)行行為追蹤時(shí)，根據(jù)binlog記錄的行為及對(duì)應(yīng)的connection-id 結(jié)合 之前連接日志記錄 進(jìn)行分析，得出最后的結(jié)論

正文：
1. 設(shè)置init-connect
1.1創(chuàng)建用于存放連接信息的表
create database AuditDB default charset utf8;
use AuditDB;
create table accesslog (ID int primary key auto_increment,ConnectionID int, ConnUserName varchar(30), PrivMatchName varchar(30), LoginTIme timestamp);

1.2 保證所有的用戶對(duì)此表有寫權(quán)限
insert into db (Host,Db,User,Insert_priv) values (‘%’,'AuditDB’,”,’Y');
flush privileges;

1.3 設(shè)置init-connect
在my.cnf 中的 [mysqld] 的block 添加以下配置；
init-connect=’insert into AuditDB.accesslog (ConnectionID,ConnUserName,PrivMatchName,LoginTime) values(connection_id(),user(),current_user(),now());’
log-bin

1.4 重啟數(shù)據(jù)庫(kù)生效
service mysqld restart

2. 記錄追蹤
2.1 thread_id確認(rèn)
假設(shè)想知道在2009年11月25日，上午9點(diǎn)多的時(shí)候，是誰(shuí)吧test.dummy這個(gè)表給刪了。可以用以下語(yǔ)句定位
mysqlbinlog –start-datetime=’2009-11-25 09:00:00′ –stop-datetime=’2009-11-25 09:00:00′ binlog.xxxx | grep ‘dummy’ -B 5
會(huì)得到如下結(jié)果(可見thread_id為5)：

# at 300777 #091124 16:54:00 server id 10 end_log_pos 301396 Query thread_id=5 exec_time=0 error_code=0 SET TIMESTAMP=1259052840; drop table test.dummy;

2.2 用戶確認(rèn)
thread_id 確認(rèn)以后，找到元兇就只是一條sql語(yǔ)句的問題了。
select ID,LoginTime,PrivMatchName,ConnUserName fromAuditDB.accesslog where ConnectionID=5 ;

就能發(fā)現(xiàn)是testuser2@localhost干的了。

(root:local_test:)[(none)] 02:23:22> select * from auditdb.accesslog limit 1; +----+--------------+----------------+----------------+---------------------+ | id | connectionid | connusername | privmatchname | logintime | +----+--------------+----------------+----------------+---------------------+ | 1 | 5 | root@localhost | root@localhost | 2013-10-07 14:17:01 | +----+--------------+----------------+----------------+---------------------+

3. Q&A
Q：使用init-connect會(huì)影響服務(wù)器性能嗎？
A：理論上，只會(huì)在用戶每次連接時(shí)往數(shù)據(jù)庫(kù)里插入一條記錄，不會(huì)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生很大影響。除非連接頻率非常高（當(dāng)然，這個(gè)時(shí)候需要注意的就是如何進(jìn)行連接復(fù)用和控制，而非是不是要用這種方法的問題了）
Q：access-log表如何維護(hù)?
A: 由于是一個(gè)log系統(tǒng)，推薦使用archive存儲(chǔ)引擎，有利于數(shù)據(jù)厄壓縮存放。如果數(shù)據(jù)庫(kù)連接數(shù)量很大的話，建議一定時(shí)間做一次數(shù)據(jù)導(dǎo)出，然后清表。
Q：表有其他用途么？
A：有！access-log表當(dāng)然不只用于審計(jì)，當(dāng)然也可以用于對(duì)于數(shù)據(jù)庫(kù)連接的情況進(jìn)行數(shù)據(jù)分析，例如每日連接數(shù)分布圖等等，只有想不到?jīng)]有做不到。
Q：會(huì)有遺漏的記錄嗎？
A：會(huì)的，init-connect 是不會(huì)在super用戶登錄時(shí)執(zhí)行的。所以access-log里不會(huì)有數(shù)據(jù)庫(kù)超級(jí)用戶的記錄，這也是為什么我們不主張多個(gè)超級(jí)用戶，并且多人使用的原因。

轉(zhuǎn)載于:https://blog.51cto.com/ace105/1333607

總結(jié)

以上是生活随笔為你收集整理的mysql 审计（audit）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。