不能直接当生产环境的安全审计工具用。general_log 记录所有语句、无上下文区分、无事件分类与告警，开启后I/O压力大、日志爆炸、明文泄露密码，且无法过滤高危操作，漏报率高。

MySQL 自带的 general_log 能不能当安全审计用？

不能直接当生产环境的安全审计工具用。它记录所有语句（包括 SELECT、SET、密码明文等），开启后 I/O 压力大、日志体积爆炸，且不区分用户操作上下文，也缺乏事件类型分类和告警能力。

• general_log = ON 会显著拖慢高并发写入场景，尤其在 SSD 性能受限或日志落盘慢的机器上
• 日志中 mysql -u root -p123456 这类命令可能泄露密码，不符合最小权限与敏感信息脱敏原则
• 无法过滤出高危操作（如 DROP TABLE、GRANT、ALTER USER），需人工 grep，漏报率高

MySQL 8.0+ 的 audit_log 插件怎么启用和配置？

这是官方推荐的轻量级审计方案，只记录连接、查询、管理类事件，支持 JSON 格式输出和白名单过滤，但必须用企业版或 MySQL Community Server 8.0.30+（社区版从该版本起内置）。

INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SET GLOBAL audit_log_policy = 'ALL';
SET GLOBAL audit_log_format = 'JSON';
SET GLOBAL audit_log_file = '/var/log/mysql/audit.log';

• 启动前确认 audit_log.so 文件存在：ls /usr/lib/mysql/plugin/audit_log.so
• audit_log_policy = 'LOGINS,QUERIES' 比 ALL 更可控，避免记录无意义的空连接
• 日志文件路径需确保 MySQL 用户有写权限，否则插件加载成功但实际无输出
• JSON 格式里 "status": 0 表示执行成功，非零值（如 1045）才是认证失败类风险事件

如何用 pt-audit 分析 audit_log 输出的 JSON 日志？

pt-audit（Percona Toolkit 中的工具）是目前最实用的日志解析器，能把原始 JSON 转成可读表格、按用户/命令/错误码聚合统计，还能导出 CSV 供 SIEM 系统接入。

pt-audit --format json /var/log/mysql/audit.log \
  --filter 'event["status"] != 0' \
  --report \
  --group-by user,event[command]

• 必须加 --format json，否则默认按旧版 XML 解析会报错
• --filter 支持 Python 表达式，比如 'event["command"] in ["DROP", "GRANT", "ALTER USER"]' 可精准捕获权限变更行为
• 注意 pt-audit 不实时监听，适合离线分析；如需实时告警，得配合 tail -f + awk 或 Filebeat
• 若 audit_log 开启了 rotation（audit_log_rotate_on_size），需轮询多个文件，pt-audit *.log 会自动合并处理

审计日志权限本身该怎么控制？

审计日志文件和 MySQL 内部 audit_log 相关变量，必须严格限制访问权限，否则审计就失去意义。

• OS 层面：chown mysql:adm /var/log/mysql/audit.log && chmod 640 /var/log/mysql/audit.log，禁止普通用户读取
• MySQL 层面：禁用非管理员查看 audit_log 变量，执行 REVOKE SELECT ON *.* FROM 'auditor'@'%'; 后再 GRANT SELECT ON performance_schema.* TO 'auditor'@'%';，避免其看到 audit_log_policy 等敏感配置
• 不要把 audit_log 写到 /tmp 或 web 可访问路径下，曾经有案例因配置错误导致 audit.log 被 HTTP 直接下载

audit_log 插件不记录 SQL 参数（如 WHERE id = ? 中的值），所以对防 SQL 注入类行为无能为力；真要覆盖这类场景，得上代理层（如 ProxySQL）或专用 WAF，不是靠日志审计能解决的。