mysql服务器自身没有提供审计功能,但是我们可以使用init-connect + binlog的方法进行mysql的 *** 作审计。由于mysql binlog记录了所有对数据库长生实际修改的sql语句，及其执行时间，和connection_id但是却没有记录connection_id对应的详细用户信息。在后期审计进行行为追踪时，根据binlog记录的行为及对应的connection-id 结合 之前连接日志记录 进行分析，得出最后的结论。
1. 设置init-connect
1.1 创建用于存放连接日志的数据库和表
create database accesslog
CREATE TABLE accesslog.accesslog (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))
1.2 创建用户权限
可用现成的root用户用于信息的读取
grant select on accesslog.* to root
如果存在具有to *.* 权限的用户需要进行限制。
这里还需要注意用户必须对accesslog表具有insert权限
grant select on accesslog.* to user@’%’
1.3 设置init-connect
在[mysqld]下添加以下设置：
init-connect=’insertinto accesslog.accesslog(id, time, localname, matchname)
values(connection_id(),now(),user(),current_user())’
------注意user()和current_user()的区别
log-bin=xxx
这里必须开启binlog
1.4 重启数据库生效
shell>/etc/init.d/mysql restart
2. 记录追踪
2.1 thread_id确认
可以用以下语句定位语句执行人
Tencent:~ # mysqlbinlog --start-datetime='2011-01-26 16:00:00'
--stop-datetime='2011-01-26 17:00:00' /var/lib/mysql/mysql-bin.000010
| grep -B 5 'wsj'
COMMIT/*!*/
# at 767
#110126 16:16:43 server id 1 end_log_pos 872 Query thread_id=19exec_time=0 error_code=0
use test/*!*/
SET TIMESTAMP=1296029803/*!*/
create table wsj(id int unsigned not null)
--
BEGIN
/*!*/
# at 940
#110126 16:16:57 server id 1 end_log_pos 1033 Query thread_id=19exec_time=0 error_code=0
SET TIMESTAMP=1296029817/*!*/
insert into wsj(id) values (1)
--
BEGIN
/*!*/
# at 1128
#110126 16:16:58 server id 1 end_log_pos 1221 Query thread_id=19exec_time=0 error_code=0
SET TIMESTAMP=1296029818/*!*/
insert into wsj(id) values (2)
2.2 用户确认
thread_id 确认以后，找到元凶就只是一条sql语句的问题了。
mysql>select * from accesslog where id=19
+----+---------------------+---------------------+-----------+
| id | time| localname | matchname |
+----+---------------------+---------------------+-----------+
| 19 | 2011-01-26 16:15:54 | test@10.163.164.216 | test@%|
+----+---------------------+---------------------+-----------+
1 row in set (0.00 sec)
3. Q
Q：使用init-connect会影响服务器性能吗？
A：理论上，只会在用户每次连接时往数据库里插入一条记录，不会对数据库产生很大影响。除非连接频率非常高（当然，这个时候需要注意的就是如何进行连接复用和控制，而非是不是要用这种方法的问题了）---如果采用长连接并且缓存的话,可以提高性能
Q：access-log表如何维护?
A: 由于是一个log系统，推荐使用archive存储引擎，有利于数据厄压缩存放。如果数据库连接数量很大的话，建议一定时间做一次数据导出，然后清表。
Q：表有其他用途么？
A：有！access-log表当然不只用于审计，当然也可以用于对于数据库连接的情况进行数据分析，例如每日连接数分布图等等，只有想不到没有做不到。---可以用来测试读写分离,验证负载均衡等
Q：会有遗漏的记录吗？
A：会的，init-connect 是不会在super用户登录时执行的。所以access-log里不会有数据库超级用户的记录，这也是为什么我们不主张多个超级用户，并且多人使用的原因。--这种审计不会记录root等具有super权限的账号对数据库的访问
建立两个单域的表格。一个表格中为姓名列表(表格名：data)。另一个表格中是所插入字符的字符数(表格名：chars)。在data表格中定义一个触发器。
每次在其中插入一个新姓名时，chars表格中运行的总数就会根据新插入记录的字符数目进行自动更新。
(见列表A)
mysql>CREATE TABLE data (name VARCHAR(255))
Query OK, 0 rows affected (0.09 sec)
mysql>CREATE TABLE chars (count INT(10))
Query OK, 0 rows affected (0.07 sec)
mysql>INSERT INTO chars (count) VALUES (0)
Query OK, 1 row affected (0.00 sec)
mysql>CREATE TRIGGER t1 AFTER INSERT ON
data FOR EACH ROW UPDATE chars SET count = count + CHAR_LENGTH(NEW.name)
Query OK, 0 rows affected (0.01 sec)
列表A
理解上面代码的关键在于CREATE TRIGGER命令，被用来定义一个新触发器。这个命令建立一个新触发器，假定的名称为t1，每次有一个新记录插入到data表格中时，t1就被激活。
在这个触发器中有两个重要的子句：
AFTER INSERT子句表明触发器在新记录插入data表格后激活。
UPDATE chars SET count = count + CHAR_LENGTH(NEW.name)子句表示触发器激活后执行的SQL命令。在本例中，该命令表明用新插入的data.name域的字符数来更新 chars.count栏。这一信息可通过内置的MySQL函数CHAR_LENGTH()获得。
放在源表格域名前面的NEW关键字也值得注意。这个关键字表明触发器应考虑域的new值(也就是说，刚被插入到域中的值)。MySQL还支持相应的OLD前缀，可用它来指域以前的值。
可以通过调用SHOW TRIGGER命令来检查触发器是否被激活，如列表B所示。
mysql>SHOW TRIGGERS\G
*************************** 1. row ***************************
?Trigger: t1
?Event: INSERT
?Table: data
Statement: UPDATE chars SET count = count + CHAR_LENGTH(NEW.name)
Timing: AFTER
?Created: NULL
ql_mode:
1 row in set (0.01 sec)
列表B
激活触发器后，开始对它进行测试。试着在data表格中插入几个记录：
mysql>INSERT INTO data (name) VALUES ('Sue'), ('Jane')
Query OK, 2 rows affected (0.00 sec)
Records: 2?Duplicates: 0?Warnings: 0
然后检查chars表格看触发器是否完成它该完成的任务：
mysql>SELECT * FROM chars
+-------+
| count |
+-------+
| 7|
+-------+
1 row in set (0.00 sec)
data表格中的INSERT命令激活触发器，计算插入记录的字符数，并将结果存储在chars表格中。如果往data表格中增加另外的记录，chars.count值也会相应增加。
触发器应用完毕后，可有DROP TRIGGER命令轻松删除它。
mysql>DROP TRIGGER t1
Query OK, 0 rows affected (0.00 sec)
注意：理想情况下，你还需要一个倒转触发器，每当一个记录从源表格中删除时，它从字符总数中减去记录的字符数。这很容易做到，你可以把它当作练习来完成。提示：应用BEFORE DELETE ON子句是其中一种方法。
现在，要建立一个审计记录来追踪对这个表格所做的改变。这个记录将反映表格的每项改变，并向用户说明由谁做出改变以及改变的时间。需要建立一个新表格来存储这一信息(表格名：audit)，如下所示。(列表C)
mysql>CREATE TABLE audit (id INT(7), balance FLOAT, user VARCHAR(50)
NOT NULL, time TIMESTAMP NOT NULL)
Query OK, 0 rows affected (0.09 sec)
列表C
接下来，我将在accounts表格中定义一个触发器。(列表D)
mysql>CREATE TRIGGER t1 AFTER UPDATEON accounts
FOR EACH ROW INSERT INTO audit (id, balance, user, time)
VALUES (OLD.id, NEW.balance, CURRENT_USER(), NOW())
Query OK, 0 rows affected (0.04 sec)
列表D
要是已经走到这一步，就很容易理解。accounts表格每经历一次UPDATE，触发器插入(INSERT)对应记录的id、新的余额、当前时间和登录audit表格的用户的名称。
实现中的例子：用触发器审计记录
既然了触发器的基本原理，来看一个稍稍复杂的例子。常用触发器来建立一个自动“审计记录”，以记录各种用户对数据库的更改。为了解审计记录的实际应用，请看下面的表格(表格名：accounts)，它列出了一个用户的三个银行账户余额。(表A)
mysql>SELECT * FROM accounts
+----+------------+---------+
| id | label| balance |
+----+------------+---------+
|1 | Savings #1 |500 |
|2 | Current #1 |2000 |
|3 | Current #2 |3500 |
+----+------------+---------+
3 rows in set (0.00 sec)
表A
然后，检查触发器是否被激活：
mysql>SHOW TRIGGERS \G
*************************** 1. row ***************************
?Trigger: t1
?Event: UPDATE
?Table: accounts
Statement: INSERT INTO audit (id, balance, user, time)
VALUES (OLD.id, NEW.balance, CURRENT_USER(), NOW())
Timing: AFTER
?Created: NULL
Sql_mode:
1 row in set (0.01 sec)
再来看最后的结果(列表E)：
mysql>UPDATE accounts SET balance = 500 WHERE id = 1
Query OK, 1 row affected (0.00 sec)
Rows matched: 1?Changed: 1?Warnings: 0
mysql>UPDATE accounts SET balance = 900 WHERE id = 3
Query OK, 1 row affected (0.01 sec)
Rows matched: 1?Changed: 1?Warnings: 0
mysql>UPDATE accounts SET balance = 1900 WHERE id = 1
Query OK, 1 row affected (0.00 sec)
Rows matched: 1?Changed: 1?Warnings: 0
列表E
注意，对accounts表格所作的改变已被记录到audit表格中，将来如果出现问题，可以方便地从中进行恢复。
mysql>SELECT * FROM audit
+------+---------+----------------+---------------------+
| id| balance | user| time|
+------+---------+----------------+---------------------+
|1 |500 | root@localhost | 2006-04-22 12:52:15 |
|3 |900 | root@localhost | 2006-04-22 12:53:15 |
|1 |1900 | root@localhost | 2006-04-22 12:53:23 |
+------+---------+----------------+---------------------+
3 rows in set (0.00 sec)
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）