mysql权限变更如何记录日志_mysql审计方案解析

MySQL 默认不记录权限变更操作，必须启用 server_audit 插件并配置 QUERY_DDL 事件才能可靠审计 GRANT、REVOKE 等语句；general_log 和 binlog 均无法满足合规性要求。

MySQL 默认不记录 GRANT、REVOKE、CREATE USER 等权限变更操作，必须显式启用审计机制才能捕获——靠通用日志或二进制日志都不行，它们要么不记录权限语句（binlog 默认跳过），要么格式太粗（general_log 无结构、难过滤）。

用 server_audit 插件抓取权限变更事件

社区版 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'@'%'"

为什么 不能依赖 general_log 或 binlog？

通用日志看似“啥都记”，但对权限审计实际无效：它记录的是客户端发来的原始字符串，不解析语义，GRANT 语句混在大量业务 SQL 中极难提取；而二进制日志默认不记录权限变更（除非显式开启 binlog_format=ROW 并配合 log_bin_trust_function_creators=ON，但仍不保证稳定捕获）。

• general_log 开启后日志体积爆炸，且无用户上下文分离（比如无法区分是 root 执行还是应用账号执行）
• binlog 主要用于 数据恢复 和主从同步，GRANT 类语句在 STATEMENT 模式下可能被跳过，在 ROW 模式下根本不会出现
• 两者均不提供结构化字段（如操作类型、目标对象、执行结果成功 / 失败），无法做合规性回溯

企业版 audit_log 插件的差异点

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）
• JSON 格式天然支持解析，可直接用 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 恢复时批量写入系统表）
• 权限变更本质是元数据操作，不是业务表 DML，必须由服务端审计插件在 SQL 解析阶段捕获
• 真正需要审计权限变更的场景（如等保三级、GDPR），必须用插件 + 日志轮转 + 权限隔离三者结合，缺一不可

最容易被忽略的一点：插件日志文件本身必须严格控制权限，chown mysql:mysql /var/log/mysql/audit.log && chmod 600 /var/log/mysql/audit.log，否则审计日志可能被未授权用户篡改或删除——日志可信的前提，是日志自身不可抵赖。