等保三级MySQL加固需四步：禁用高危账户（仅保留root本地登录、删除匿名用户及test库）、按角色授予最小权限（限定IP、禁用高危权限、限制information_schema访问）、启用SSL/TLS传输加密与InnoDB表空间加密（强制客户端校验证书、加密Redo/Undo日志）、审计日志独立部署并隔离权限（审计库独立、权限分离、日志路径物理隔离）。
必须分四步做：禁用高危账户、收紧权限粒度、启用传输与存储加密、打开审计日志并隔离权限。跳过任意一步，等保测评都可能被判定为“身份鉴别不充分”或“访问控制缺失”。
禁用root远程登录和匿名账户
生产环境的 root 账户若允许 % 或具体公网IP远程登录，等于把数据库大门钥匙挂在门口。等保三级明确要求“身份鉴别强度”，而默认配置下 root@'192.168.1.%' 这类授权就是典型不合规项。
- 先查当前 root 登录来源：
SELECT user, host FROM mysql.user WHERE user = 'root'; - 只保留
'localhost'、'127.0.0.1'、'::1'三条本地条目，其余全部删掉：DELETE FROM mysql.user WHERE user = 'root' AND host NOT IN ('localhost', '127.0.0.1', '::1'); - 删除匿名用户（空用户名）：
DROP USER ''@'localhost'; - 删除测试库：
DROP DATABASE IF EXISTS test; - 最后强制刷新：
FLUSH PRIVILEGES;
注意：MySQL 8.0+ 默认已删 test 库，但老版本或手动恢复过备份的实例仍可能残留，务必检查。
按角色创建最小权限业务账户
等保三级强调“三权分立”和“最小权限原则”，但现实中常见错误是给应用账号授予 ALL PRIVILEGES ON *.*，甚至复用 root 密码。这类配置在测评中属于“高风险项”，直接触发整改。
- 禁止使用通配符主机：
GRANT SELECT ON app_db.* TO 'app_user'@'%';是错的；应限定为内网段，如'app_user'@'192.168.10.0/24'或精确 IP - 避免授予高危权限：
DROP、ALTER、CREATE USER、SHUTDOWN等必须显式REVOKE - 推荐用角色管理（MySQL 8.0+）：
CREATE ROLE 'app_rw'; GRANT SELECT, INSERT, UPDATE ON app_db.* TO 'app_rw'; SET DEFAULT ROLE 'app_rw' TO 'app_user'@'192.168.10.%'; - 验证权限是否干净：
SHOW GRANTS FOR 'app_user'@'192.168.10.%';输出里不应出现ON *.*或GRANT OPTION
特别注意：很多团队会漏掉 information_schema 和 performance_schema 的访问控制——默认所有账号可读，敏感结构信息可能泄露，建议用 REVOKE SELECT ON information_schema.* FROM 'app_user'@'192.168.10.%'; 显式限制。
启用SSL/TLS传输加密与InnoDB表空间加密
明文传输和未加密存储是等保三级的硬性否决项。某金融系统曾因未启用 SSL 被一票否决，原因不是“没配”，而是配了但客户端未强制校验证书，导致中间人攻击仍可行。
- 服务端开启 SSL：在
my.cnf的[mysqld]段添加：ssl-ca = /etc/mysql/ssl/ca.pem、ssl-cert = /etc/mysql/ssl/server-cert.pem、ssl-key = /etc/mysql/ssl/server-key.pem - 强制客户端使用 SSL：
ALTER USER 'app_user'@'192.168.10.%' REQUIRE X509;（或更细粒度的REQUIRE SUBJECT '/CN=app-server'） - 表空间加密（TDE）：仅限 MySQL Enterprise 或兼容插件（如
tde插件），社区版需确认是否已安装：INSTALL PLUGIN tde SONAME 'andestde.so';，然后对核心表执行：ALTER TABLE user_info ENCRYPTION='Y'; - Redo/Undo 日志也必须加密，否则密钥未泄露但日志里仍有明文：
SET GLOBAL innodb_redo_log_encrypt = ON;、SET GLOBAL innodb_undo_log_encrypt = ON;
关键细节：SSL 配置后必须验证是否生效，运行 SHOW VARIABLES LIKE '%have_ssl%';，返回 have_ssl = YES 且 ssl_mode = REQUIRED 才算真正启用；否则只是“可选”，不满足等保要求。
审计日志独立部署与权限分离
审计日志本身若没保护好，等于写了本假账。等保三级要求“审计记录不可篡改”，但很多团队把审计表建在业务库，还给应用账号 INSERT + SELECT 权限，结果攻击者既能伪造日志又能删日志。
- 审计库必须独立：
CREATE DATABASE audit_db;，且不在主业务实例上（理想情况是写入远程审计服务器） - 审计表权限严格分离：
GRANT INSERT ON audit_db.access_log TO 'app_user'@'192.168.10.%';，但绝不给SELECT或UPDATE - 审计管理员账号（如
audit_admin）只授SELECT，且禁止登录业务库 - 禁用
init_connect写审计的方案——它依赖每个连接自动执行 SQL，一旦账号权限失控，审计逻辑就形同虚设；改用 MySQL Enterprise Audit Log Plugin 或 Percona Audit Log（开源替代） - 日志文件本身要设权限：
chown mysql:mysql /var/lib/mysql/audit.log、chmod 600 /var/lib/mysql/audit.log
最容易被忽略的一点：审计日志的存储路径必须和数据文件路径物理隔离。如果都放在 /var/lib/mysql 下，勒索软件加密整个目录，审计日志和数据一起完蛋——这违反等保“剩余信息保护”要求。
