MySQL默认不记录权限变更操作,必须启用server_audit插件并配置QUERY_DDL事件才能可靠审计GRANT、REVOKE等语句;general_log和binlog均无法满足合规性要求。
MySQL 默认不记录 GRANT、REVOKE、CREATE USER 等权限变更操作,必须显式启用审计机制才能捕获——靠通用日志或二进制日志都不行,它们要么不记录权限语句(binlog 默认跳过),要么格式太粗(general_log 无结构、难过滤)。
社区版 MySQL 最可靠的方式是加载 server_audit 插件,并明确开启 QUERY_DDL 和连接类事件。它能原生识别 GRANT、REVOKE、DROP USER 等语句,并打上 QUERY 或 CONNECT 类型标签。
plugin_dir(如 /usr/lib/mysql/plugin/),再执行:INSTALL PLUGIN server_audit SONAME 'server_audit.so';
my.cnf 并重启,或动态设置):SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DML';
SET GLOBAL server_audit_logging = ON;
SET GLOBAL server_audit_file_path = '/var/log/mysql/audit.log';
QUERY_DDL 是重点:它覆盖所有数据定义类操作,包括权限管理语句;而 QUERY_DML
只捕获增删改查,不包含权限变更user、host、query 字段,例如:"query":"GRANT SELECT ON mydb.* TO 'auditor'@'%'"
通用日志看似“啥都记”,但对权限审计实际无效:它记录的是客户端发来的原始字符串,不解析语义,GRANT 语句混在大量业务 SQL 中极难提取;而二进制日志默认不记录权限变更(除非显式开启 binlog_format=ROW 并配合 log_bin_trust_function_creators=ON,但仍不保证稳定捕获)。
general_log 开启后日志体积爆炸,且无用户上下文分离(比如无法区分是 root 执行还是应用账号执行)binlog 主要用于数据恢复和主从同步,GRANT 类语句在 STATEMENT 模式下可能被跳过,在 ROW 模式下根本不会出现MySQL Enterprise Edition 的 audit_log 插件支持更细粒度策略,比如只审计特定用户或只记录失败的权限操作,但社区版做不到。如果你用的是企业版,配置更简洁:
[mysqld]
plugin-load = audit_log.so
audit_log_format = JSON
audit_log_policy = ALL
audit_log_file = /var/log/mysql/audit.log
audit_log_policy = ALL 会记录所有连接和查询,包括权限语句;设为 LOGINS 则只记登录,QUERIES 只记查询(不含 DDL)jq 提取权限操作:jq 'select(.query | contains("GRANT") or contains("REVOKE"))' /var/log/mysql/audit.log
audit_log.so,不是 server_audit.so,加载失败通常因文件名或路径错误有人想在 mysql.user 或 mysql.db 表上建触发器来监听权限变更,这在 MySQL 中不可行:系统表不允许创建用户触发器,执行会报错 ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s)。
mysqldump --all-databases 恢复时批量写入系统表)最容易被忽略的一点:插件日志文件本身必须严格控制权限,chown mysql:mysql /var/log/mysql/audit.log && chmod 600 /var/log/mysql/audit.log,否则审计日志可能被未授权用户篡改或删除——日志可信的前提,是日志自身不可抵赖。