audit_admin是安全管理员专用的审计开关权限，不可授予审计员；审计员只需select权限读取审计表或os文件读取权，且必须禁用show databases等高危权限并强制ssl连接。
AUDIT_ADMIN 不是给审计员用的权限，而是给安全管理员管“开关”的——授错了直接等保不通过。
为什么不能把 AUDIT_ADMIN 授给 audit_admin 账号
很多人看到 AUDIT_ADMIN 这个名字，就以为它是“审计管理员专属权限”，立刻 GRANT AUDIT_ADMIN ON *.* TO 'audit_admin'@'%'。这是最危险的误操作：
-
AUDIT_ADMIN允许执行INSTALL PLUGIN audit_log、SET GLOBAL audit_log_policy = 'OFF'、UNINSTALL PLUGIN等操作——本质是控制审计功能启停，不是读日志 - 一旦审计员自己能关审计，就彻底破坏“审计不可干预”原则，等保2.0 第六章明确否决该做法
- MySQL 官方文档（8.0.28+）特别强调：
AUDIT_ADMIN应仅由 security_admin 持有，且必须与审计执行账号物理隔离
audit_admin 账号真正需要的权限组合
审计员只做一件事：**读已生成的日志内容**。具体给什么权限，取决于你用哪种日志落地方式：
- 若用
audit_log插件写文件（如/var/log/mysql/audit.log）：不需要任何数据库权限，只需 OS 层面mysql用户对日志路径的读取权（cat /var/log/mysql/audit.log） - 若用自建审计表（如
audit_db.access_log）：GRANT SELECT ON `audit_db`.`access_log` TO 'audit_admin'@'%'，且必须REVOKE SHOW DATABASES, PROCESS, SUPER ON *.* FROM 'audit_admin'@'%' - 若查
performance_schema.events_statements_history_long：GRANT SELECT ON performance_schema.* TO 'audit_admin'@'%'（默认禁止访问该库） - 所有场景下都必须强制 SSL：
CREATE USER 'audit_admin'@'%' IDENTIFIED BY 'StrongPass!2026' REQUIRE SSL
audit_log 插件启用和 audit_admin 权限配置必须分离
加载插件、开启策略、指定日志路径，这三件事必须由有 SYSTEM_VARIABLES_ADMIN 和 SYSTEM_USER 权限的账号（比如 security_admin）完成，和 audit_admin 完全无关：
- 加载插件：
INSTALL PLUGIN audit_log SONAME 'audit_log.so'（需重启或运行时加载） - 开启全量记录：
SET GLOBAL audit_log_policy = 'ALL'（注意：该值只在运行时生效，要持久化必须写进my.cnf的[mysqld]段并重启） - 指定日志路径：
audit_log_file = /var/log/mysql/audit.log必须在配置文件中设置，SET GLOBAL audit_log_file = '...'会报错 - 路径权限检查：确保
/var/log/mysql/目录属主为mysql:mysql，且 SELinux 上下文正确（ls -Z /var/log/mysql应含mysqld_log_t）
最容易被忽略的两个硬性约束
很多配置看似成功，但审计日志实际静默失效，往往卡在这两点：
-
AUDIT_ADMIN权限无法被授予普通用户账号——它只能授予root或明确具有SYSTEM_USER的账号；试图GRANT给非 SYSTEM 用户会报错ERROR 3713 (HY000): The operation cannot be performed with a user that has the SYSTEM_USER privilege revoked - 审计日志默认不加密，敏感字段（如 SQL 文本）可能明文落盘；若启用
audit_log_encryption = ON，必须提前用AES-256-GCM密钥初始化，并确保密钥文件权限为600且仅mysql可读
