MySQL数据库的安全问题很少来自单一漏洞，更多是配置疏忽、权限设计粗糙和运维习惯松散叠加后的结果。很多团队把精力放在防SQL注入和网络隔离上，却忽略了数据库自身从安装那一刻起就存在的默认风险。要建立真正可靠的安全基线，需要从身份认证、权限模型、审计追踪、数据加密、备份恢复和运行时监控几个层面同时收紧。

身份认证与账户管理：先清理入口

MySQL安装完成后，默认存在root账户且通常仅通过auth_socket或初始空密码即可本地登录，这在生产环境是不可接受的。第一件事是删除匿名账户、删除测试数据库，并为root设置强密码。执行以下命令可以快速清理默认账户：

DELETE FROM mysql.user WHERE User='';
DROP DATABASE IF EXISTS test;
ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '强密码';
FLUSH PRIVILEGES;

不要只关注root。任何拥有全局权限或能访问mysql系统库的账户都是高风险对象。建议定期检查mysql.user表中是否存在User列为空、Host列为%且权限异常的账户。对于远程连接，应强制使用SSL/TLS，避免密码明文在网络上传输。MySQL 8.0默认的caching_sha2_password插件比旧版mysql_native_password更安全，除非有旧客户端兼容需求，否则不要降级认证插件。

另一个常被忽视的点是账户锁定策略。对于面向应用的数据库账户，可以设置FAILED_LOGIN_ATTEMPTS和PASSWORD_LOCK_TIME，防止暴力破解。例如：

CREATE USER 'app_user'@'10.0.0.%' IDENTIFIED BY '强密码'
  FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1;

这样连续5次密码错误后账户自动锁定1天，能显著提升抗暴力破解能力。

权限模型：最小权限不是口号

绝大多数MySQL安全事件都与权限过度授予有关。应用账户动辄拥有ALL PRIVILEGES，甚至包含GRANT OPTION，一旦应用出现SQL注入，攻击者就能直接读取或篡改整个数据库。正确的做法是按业务模块拆分账户，每个账户只授予必要的库表权限和操作类型。

例如，一个只读报表账户应该只授予SELECT权限，并且限定在特定数据库：

GRANT SELECT ON reporting.* TO 'report_user'@'10.0.0.%';

写入账户则只授予INSERT、UPDATE、DELETE，不授予DDL权限。结构变更应通过独立的迁移账户或人工审批流程执行，应用运行账户不应具备CREATE、ALTER、DROP权限。对于需要执行存储过程的账户，单独授予EXECUTE权限，而不是直接给全局权限。

还需要警惕mysql系统库的访问权限。普通业务账户不应拥有对mysql.user、mysql.db等表的SELECT权限，否则攻击者可以通过读取这些表获取其他账户的密码哈希。定期使用SHOW GRANTS检查每个账户的实际权限，并回收不必要的授权。权限变更后务必执行FLUSH PRIVILEGES使其生效。

审计与日志：让操作可追溯

MySQL默认的general log和slow query log并不适合作为安全审计工具。general log记录所有SQL但开销巨大，slow query log只记录慢查询。真正有效的审计需要开启MySQL Enterprise Audit插件，或者使用Percona Server提供的审计插件。如果使用社区版MySQL，可以考虑在应用层记录操作日志，或者通过MySQL Proxy层做SQL捕获。

审计日志至少应记录以下信息：连接时间、断开时间、源IP、用户名、执行的SQL语句、影响行数。对于高风险操作如DROP TABLE、TRUNCATE、DELETE不带WHERE条件、修改权限等，应配置实时告警。日志文件本身也需要保护，避免被攻击者删除或篡改。建议将审计日志实时同步到独立的日志服务器或SIEM系统。

另一个常被忽略的审计点是错误日志。MySQL错误日志中可能包含连接失败、认证失败、复制异常等信息，这些是入侵检测的重要信号。配置log_error_verbosity=3可以让错误日志记录更详细的内容。定期分析错误日志中的异常模式，例如短时间内大量认证失败，往往意味着暴力破解正在发生。

数据加密：静态与传输都要覆盖

传输层加密相对容易实现。在MySQL配置中启用SSL，要求所有远程连接使用加密通道。配置示例：

[mysqld]
require_secure_transport=ON
ssl-ca=/etc/mysql/certs/ca.pem
ssl-cert=/etc/mysql/certs/server-cert.pem
ssl-key=/etc/mysql/certs/server-key.pem

启用require_secure_transport后，所有非SSL连接都会被拒绝。对于应用账户，可以在创建或修改账户时指定REQUIRE SSL，强制该账户必须使用加密连接。

静态数据加密分为表空间加密和备份加密。MySQL 8.0支持InnoDB表空间加密，通过keyring插件管理加密密钥。启用表空间加密需要在初始化时配置keyring_file插件，然后对敏感表执行加密：

ALTER TABLE sensitive_data ENCRYPTION='Y';

表空间加密对性能有一定影响，通常I/O密集型场景下性能损耗在5%到10%之间。建议只对包含敏感信息的表启用加密，而不是全库加密。备份文件同样需要加密，可以使用mysqldump配合openssl加密，或者使用Percona XtraBackup的加密功能。备份加密密钥应与数据库加密密钥分开管理，避免单点泄露。

备份与恢复：安全策略的最后防线

很多团队认为备份只是数据可用性问题，与安全无关。实际上备份是勒索软件和数据破坏事件后的唯一恢复手段。备份策略需要同时考虑备份频率、保留周期、异地存储和恢复验证。建议至少保留最近7天的每日全量备份和更长时间范围的每周备份，备份文件存储在与生产环境物理隔离的位置。

备份文件本身的安全同样重要。未加密的数据库备份一旦泄露，等同于数据库直接泄露。备份文件应使用强加密，并且访问备份文件的权限应严格限制。定期进行恢复演练，验证备份文件完整可用，避免出现备份成功但恢复失败的情况。

对于高可用架构，不要将主从复制误认为备份。主从复制只能解决硬件故障和部分可用性问题，无法防止误删除、逻辑错误或恶意破坏。从库上的数据破坏会同步到主库，因此独立的物理备份仍然是必需的。

运行时监控与加固：持续对抗风险

安全配置不是一次性工作，需要持续监控和调整。重点关注以下运行时指标：连接数异常增长、慢查询突然增多、临时表大量创建、InnoDB锁等待时间飙升。这些指标可能意味着SQL注入攻击、资源耗尽攻击或数据泄露行为。

操作系统层面的加固同样重要。MySQL数据目录的权限应限制为仅mysql用户可访问，配置文件不应允许其他用户读取。使用专用系统账户运行MySQL服务，不要使用root。定期更新MySQL小版本，安全漏洞修复通常只在小版本更新中提供。对于无法及时升级的情况，应关注官方安全公告并评估风险。

网络层面，MySQL默认端口3306不应直接暴露在公网。使用防火墙限制只有应用服务器和运维跳板机可以访问数据库端口。对于需要跨机房访问的场景，使用专线或VPN隧道，避免数据库端口直接暴露在不可信网络中。

最后，建立安全基线检查清单，定期自动化检查以下项目：是否存在匿名账户、是否存在空密码账户、root是否允许远程登录、是否开启SSL、是否启用审计日志、备份是否加密、数据目录权限是否正确、是否存在异常权限账户。将这些检查纳入CI/CD流程或定期运维任务中，确保安全配置不会因为日常操作而退化。