mysql中多因素认证与数据库安全

MySQL 8.0+ 的 authentication_policy 不能真正启用标准MFA,它仅支持同一用户在不同连接上下文启用多个认证插件,并非联合验证;真正接近MFA的是密码+客户端证书组合,需手动配置REQUIRE SUBJECT/ISSUER/CIPHER并强制SSL。

MySQL 8.0+ 的 authentication_policy 能否真正启用多因素认证?

不能直接启用「标准意义上的 MFA」。MySQL 官方不支持短信/OTP/生物识别等第二因子验证,authentication_policy 是个误导性变量名——它实际只控制「多个认证插件是否可同时启用」,且仅限于同一用户在不同连接上下文(如本地 vs 远程)使用不同插件,并非真正 MFA。

真正接近 MFA 的方案是组合使用:caching_sha2_password(主因子:密码) + authentication_ldap_sasl 或客户端证书(次因子),但二者需手动串联逻辑,MySQL 本身不校验“两个因子都通过才放行”。

  • MySQL 8.0.27+ 引入的 authentication_policy 只接受 OFF / ON,设为 ON 后允许对同一用户配置多个 IDENTIFIED WITH ... BY ... 子句,但登录时仍只匹配第一个满足条件的认证方法
  • 所谓“双因子”实操中常指:应用层先做 LDAP 绑定,再用返回的 token 换取 MySQL 短期账号(类似 OAuth flow),这不是数据库内建能力
  • 若强行在 CREATE USER 中写两个 IDENTIFIED WITH,第二个会被忽略,除非用 ALTER USER ... ADD AUTHENTICATION(仅限企业版 8.0.30+,且仍不触发联合验证)

require ssl 和客户端证书实现类 MFA 效果

这是最接近生产可用的“双因子”路径:密码(知识因子) + 客户端证书私钥(持有因子)。MySQL 原生支持,无需中间件,但需严格管理证书生命周期。

CREATE USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'weakpass' REQUIRE SUBJECT '/CN=app-client/C=CN' AND ISSUER '/CN

=MyCA/C=CN' AND CIPHER 'ECDHE-ECDSA-AES256-GCM-SHA384';

关键点:

  • REQUIRE SUBJECT 校验客户端证书 DN,ISSUER 防止伪造 CA,CIPHER 限定 TLS 握手加密套件(避免降级到不安全协议)
  • 必须配合 ssl_mode=REQUIRED 在客户端连接参数中显式声明,否则即使服务端要求 SSL,客户端也可能静默降级
  • 证书过期后用户无法登录,但错误提示是 Access denied for user,不是明确的证书失效,排查时容易误判为密码错误

validate_password 插件和 password_history 的真实约束力

它们只管“新密码是否合规”,不管“旧密码是否被重用”或“密码是否泄露”。开启后仍可能因运维习惯(如批量改密脚本硬编码旧密码)导致策略形同虚设。

  • validate_password.length 设为 12 并不能阻止用户设 123456789012 —— 插件默认不校验字符多样性,需额外设 validate_password.mixed_case_count=1validate_password.number_count=1
  • password_history=5 仅检查最近 5 次修改记录,若用户用 ALTER USER ... IDENTIFIED BY RANDOM PASSWORD 绕过密码输入,历史记录不更新
  • 插件不拦截 SET PASSWORD 语句,DBA 仍可用该命令绕过所有策略,权限模型上没隔离“密码策略执行者”和“密码修改者”

审计日志(audit_log)开不开,差别远不止“有没有日志”

开启后性能下降 5–15%,但更关键的是默认日志格式(JSON)难以直接 grep,且不记录 SQL 语句体(只记语句类型),对溯源攻击价值有限。

  • 必须设置 audit_log_policy=ALL 才记录 DDL/DML,audit_log_policy=LOGINS 只记连接事件,连谁删了表都看不到
  • 日志文件权限若为 644,任何有服务器 shell 权限的用户都能读取,等于把审计日志变成明文密码本
  • MySQL 不提供日志轮转自动压缩,audit_log_file 写满磁盘会导致 mysqld crash,需配合外部 logrotate 并发 FLUSH LOGS

真正的风险点不在功能有没有,而在证书怎么分发、密码策略谁来审计、日志谁有权删——这些环节一旦脱钩,再全的认证选项也只是装饰。