Mysql8中的無插件方式審計
需求
在mysql 8中記錄用戶對數據庫表的操作內容,操作時間,客戶端源ip地址。
在mysql5.7完美地采用MariaDB的server_audit插件來記錄{時間,節(jié)點,用戶,源IP,事件類型,庫,語句,影響行數}等審計,但從mysql8開始已不支持該插件,同類的第三方插件也無法使用。
目前找到的方式:
[ binlog + init-connect ],binlog可以審計到所有數據記錄及表結構變更相關的記錄,但,不記錄連接的信息,要通過額外的手段來記錄,比如show full processlist;
是可得出連接信息中的process id,與binlog中的thread id進行關聯(lián)分析,得到連接的信息{用戶名、登錄時間、源ip},為了永久記錄process id,采用init-connect 方式記錄到數據庫表中。
1. 創(chuàng)建init-connect用于記錄的庫和表
mysql> create database mysql_access_log; mysql> create table mysql_access_log.access_log ( conn_id int(11) default null, `time` timestamp, `localname` varchar(30), `matchname` varchar(30));
2. 授權用戶于該庫的表mysql_access_log.accesslog有insert權限
如用戶user_web
mysql> grant insert on `mysql_access_log`.`access_log` to 'user_web'@'%';
3. 配置用戶登錄日志插入表
my.cnf中 [mysqld] 下添加,并重啟mysql生效
init-connect='insert into mysql_access_log.access_log values(connection_id(),now(),user(),current_user());'
4. 特別注意
①init-connect只記錄非super權限用戶,所以好好管理用戶,按情況回收super權限;
②非super權限用戶登錄都受init-connect影響,未授權對mysql_access_log.access_log有insert權限的用戶即無法登錄成功!
③當重啟mysql后connection_id會存在不按歷史續(xù)增長而重復出現,所以查記錄時注意多個重復的id記錄。
5. 開啟mysql-binlog日志記錄
在my.cnf中 [mysqld] 下添加,并重啟mysql生效
# 二進制日志 log-bin=mysql-bin # binlog-do-db=db #僅作用的庫 expire_logs_days = 20 max_binlog_size = 300m
6. 從binlogi日志 取thread_id去查用戶名和源ip
模擬刪除book庫books表中的一條記錄-----過程省略!
解密mysql-bin查看內容,找到DELETE操作的thread_id號,如這里的8。
[root@localhost data]# mysqlbinlog --base64-output=decode-row -vv mysql-bin.000003 > ./mysql-bin.000003--vv.log [root@localhost data]# tail -n 30 ./mysql-bin.000003--vv.log #200712 18:24:01 server id 1 end_log_pos 1008 CRC32 0x62294de5 Query thread_id=8 exec_time=0 error_code=0 SET TIMESTAMP=1594549441/*!*/; SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/; #200712 18:24:01 server id 1 end_log_pos 1079 CRC32 0x0723c708 Table_map: `book`.`books` mapped to number 95 #200712 18:24:01 server id 1 end_log_pos 1187 CRC32 0xc96cc08e Delete_rows: table id 95 flags: STMT_END_F ### DELETE FROM `book`.`books` ### @1=44 /* INT meta=0 nullable=0 is_null=0 */ ### @2='XML 完全探索' /* VARSTRING(765) meta=765 nullable=1 is_null=0 */
根據thread_id號去找init-connect記錄表的登錄用戶和源ip
[root@localhost data]# mysql -u root -p -e "select * from mysql_access_log.access_log where conn_id=8 ;" | conn_id | time | localname | matchname | +---------+---------------------+-------------------------+------------+- | 8 | 2020-07-12 18:23:41 | user_web@192.168.53.119 | user_web@% | +---------+---------------------+-------------------------+------------+-
7. 開啟general-log日志記錄
[ binlog + init-connect ] 方式,受限于binlog本身記錄日志的局限,無法審計一些并不記錄在binlog中的內容。
比如無SELECT、Connect;可同時開啟mysql的general-log記錄,記錄執(zhí)行的所有的語句的信息。
在my.cnf中 [mysqld] 下添加,并重啟mysql生效
general-log=1 general_log_file = /opt/mysql/data/general_log_file.log #按你實際路徑,注意權限
但存在的不足
- a. 無論所執(zhí)行語句是否正確執(zhí)行,都會記錄,會導致大量的無用信息,后面的篩選不易操作;
- b. 當server的并發(fā)訪問非常大時,log的記錄會對IO產一定的影響,以致于影響server的性能;
- c. 日志文件很容易快速增長;
總結
以上為個人經驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關文章
mysql存儲過程之引發(fā)存儲過程中的錯誤條件(SIGNAL和RESIGNAL語句)實例分析
這篇文章主要介紹了mysql存儲過程之引發(fā)存儲過程中的錯誤條件(SIGNAL和RESIGNAL語句),結合實例形式分析了mysql使用SIGNAL和RESIGNAL語句來引發(fā)存儲過程中的錯誤條件相關操作技巧與注意事項,需要的朋友可以參考下2019-12-12