MySQL审计是实现安全闭环的关键，用于追踪数据访问行为、满足合规要求并支持事后溯源。由于MySQL社区版缺乏原生审计功能，可通过MariaDB Audit Plugin实现细粒度日志记录，或采用ProxySQL、MaxScale等代理层方案进行透明审计。审计日志应以JSON格式输出，经Filebeat+Logstash导入Elasticsearch，通过Kibana分析并设置敏感操作告警。同时需结合最小权限原则、SSL加密、堡垒机等措施构建完整安全体系，从核心数据库试点逐步推广，确保“有记录、可追溯、能响应”。
为什么需要 MySQL 审计？
没有审计，就无法发现异常行为。比如某个应用账号突然执行大量 DELETE 操作，或非工作时间有高权限登录，这些都可能预示着风险。审计提供“谁、在什么时候、做了什么”的完整日志，是合规（如等保、GDPR）的基本要求，也是事后溯源的关键依据。
MySQL 原生审计能力的局限
MySQL 社区版本身不内置审计功能。官方提供的 MySQL Enterprise Audit 插件仅限企业版使用，且配置较为复杂。社区用户常面临以下问题：
- 无法记录细粒度操作（如具体 SQL 内容）
- 日志格式不统一，难于集中分析
- 开启后对性能有一定影响，需权衡取舍
基于插件的审计方案：MariaDB Audit Plugin
目前最主流的开源解决方案是使用 MariaDB 的 Server Audit Plugin（如 audit_plugin.so），它兼容 MySQL 5.6/5.7/8.0 等版本。
实施步骤：- 下载对应版本的 audit plugin 并放入 MySQL 插件目录
- 在 MySQL 中执行 INSTALL PLUGIN AUDIT SONAME 'libaudit_plugin.so';
- 通过 set global audit_json_log_file='/var/log/mysql/audit.json'; 配置日志路径
- 设置 audit_record_cmds 和 audit_record_objs 控制记录范围（如 ddl、dml）
该插件支持输出 JSON 格式日志，便于后续接入 ELK 或 SIEM 系统做结构化分析。
结合代理层实现透明审计
若不想在数据库实例上加载插件，可采用数据库代理中间件来实现审计，例如：
- ProxySQL：可在查询路由层记录所有经过的 SQL 请求，包含客户端 IP、用户名、执行时间等信息
- MaxScale：支持审计过滤器（filter），可将语句写入文件或发送到外部系统
这种方式的好处是无侵入，不影响原有数据库运行，适合不能修改生产库配置的场景。
审计日志的存储与分析建议
生成日志只是第一步，关键在于如何有效利用：
- 日志应独立存储，避免被恶意删除
- 使用 Filebeat + Logstash 将审计日志导入 Elasticsearch
- 在 Kibana 中建立仪表盘，监控高频操作、敏感指令（DROP、UPDATE 全表）、非常规时段访问等
- 设置告警规则，如单次查询返回超 10 万行自动通知 DBA
配套安全措施不可少
审计不是孤立功能，需与其他安全控制联动：
- 严格账号权限划分，遵循最小权限原则
- 启用 SSL 加密连接，防止抓包窃取凭证
- 定期审查账户和权限变更历史
- 结合堡垒机限制直接访问数据库的通道
基本上就这些。MySQL 审计落地不需要一步到位，可以从核心库开始试点，逐步覆盖全部实例。关键是建立起“有记录、可追溯、能响应”的机制，这才是安全体系真正的价值所在。
