mysql数据库中审计日志的配置与安全分析

MySQL社区版默认不提供审计日志功能；企业版需手动安装audit_log插件并配置audit_log=FORCE_PLUS_PERMANENT等参数才能启用，且默认未开启。

MySQL 审计日志是否默认开启？

不开启。MySQL 社区版（即最常用版本）**默认完全不提供审计日志功能**，AUDIT_LOG 插件仅存在于 MySQL Enterprise Edition（企业版），社区版用户直接执行 INSTALL PLUGIN audit_log SONAME 'audit_log.so' 会报错 Plugin 'audit_log' is not loaded。

如果你用的是社区版，必须借助第三方方案，比如：

• mysql-audit（McAfee 开源插件，需自行编译适配版本，支持 5.7/8.0）
• 启用通用查询日志（general_log）并配合日志轮转与访问控制——但性能开销大、无结构化事件类型
• 使用代理层（如 ProxySQL、MaxScale）记录客户端行为

如何验证 audit_log 插件是否已正确加载（企业版）

即使安装了企业版，audit_log 插件也**不会自动启用**，需手动加载并确认状态：

INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';

若返回 PLUGIN_STATUS 为 A

CTIVE，说明加载成功；否则检查错误日志中是否有类似 Can't open shared library 'audit_log.so' 的提示——常见原因是插件路径不对或 SELinux 阻止了动态库加载。

关键配置项（需写入 my.cnf 并重启）：

• audit_log=FORCE_PLUS_PERMANENT：强制加载且不可卸载（推荐）
• audit_log_format=NEW：输出 JSON 格式（兼容性好，便于解析）
• audit_log_policy=ALL：记录所有连接、查询、管理命令（LOGINS 或 QUERIES 可缩小范围）
• audit_log_file=/var/log/mysql/audit.log：确保 MySQL 进程对该路径有写权限，且磁盘空间充足

audit_log 输出内容里哪些字段最关键？

JSON 格式的每条审计记录包含大量字段，但实际安全分析中应优先关注：

• "name":"connect" 或 "name":"query"：区分是登录事件还是 SQL 执行事件
• "status":0 表示成功，非零值（如 1045）代表认证失败，高频出现可能意味着暴力破解
• "user":"app@10.10.20.5"：含来源 IP，比仅看用户名更能定位异常访问源
• "query":"DROP TABLE users"：敏感操作明文记录（注意：长查询会被截断，受 audit_log_read_buffer_size 影响）
• "timestamp":"2025-04-12T09:23:41"：时区为 UTC，做关联分析时需统一时间基准

不要依赖 "os_login" 或 "priv_user" 字段做权限判断——它们在普通连接下常为空，真实权限由 user + host 组合决定。

审计日志的性能与落盘风险怎么平衡？

开启 audit_log 后，每个语句都会触发一次磁盘 I/O 写入，QPS 超过 500 时可能明显拖慢响应。更隐蔽的风险是：audit_log 默认同步写入（audit_log_flush=ON），一旦磁盘满或挂载点不可写，MySQL 可能直接拒绝新连接（ERROR 2013 (HY000)）。

缓解方式：

• 设 audit_log_flush=OFF 改为异步刷盘（但崩溃时最多丢失 1 秒日志）
• 用 audit_log_strategy=ASYNCHRONOUS（8.0.26+），进一步降低阻塞概率
• 禁止将审计日志和数据文件放在同一块物理盘上
• 用 logrotate 配合 audit_log_rotate_on_size 自动切分，避免单文件过大

真正棘手的是：当攻击者拿到 DBA 权限后，可直接执行 SET GLOBAL audit_log_policy = NONE; 关停审计——所以审计日志本身必须由独立账号只读采集，并实时外发到 SIEM 系统。