MySQL 新技术系列第五期

📢 MySQL 新技术系列第五期

各位数据库同行、开发者朋友们，大家好！

欢迎回到「MySQL 新技术」系列。在前四期，我们依次全景解读了 9.x 版本策略、向量检索技术、JavaScript 多语言引擎，以及 Group Replication 高可用架构。这些话题分别聚焦于 AI-Ready 数据平台、开发范式变革和架构韧性提升，而本期我们将聚焦于贯穿所有技术演进的基础保障——安全。

随着 8.0 正式 EOL、9.7 LTS 接棒成为新一代长期支持版，MySQL 的安全能力也在 9.x 系列中经历了一场系统性重塑。从 9.0 坚决移除 mysql_native_password 插件，到 9.5 将复制加密设为默认行为，再到 9.6 实现审计日志组件化改造——MySQL 的安全演进脉络清晰可见：从「可选的加固项」走向「默认安全」。

本期将系统梳理 9.x 系列在身份认证、权限模型、数据加密、审计与脱敏等方面的安全增强，并结合开源生态的安全实践与企业级合规要求，提供面向生产环境的安全配置最佳实践。

一、9.x 安全演进全景

MySQL 9.x 系列的安全能力演进可以归纳为五个核心维度，覆盖了数据安全从「入口到落盘」的全链路：

安全维度	9.0	9.1	9.2	9.3	9.5	9.6	9.7 LTS
身份认证	移除 mysql_native_password	OpenID Connect 支持	—	—	SHA-1 认证弃用	错误提示标准化	caching_sha2_password 支持 PBKDF2
权限模型	—	CREATE_SPATIAL_REFERENCE_SYSTEM 权限细化	—	—	强制角色激活	Performance Schema 账户锁定表	—
数据加密	—	—	—	—	复制连接默认加密；密钥环增强	OpenSSL 升级至 3.0.18	—
审计与脱敏	—	—	—	—	—	审计日志组件化；MD5/SHA1 迁移至独立组件	动态数据脱敏（企业版）
可观测性	—	—	—	—	—	Performance Schema 锁定账户表；HOST_CACHE 增强	OpenTelemetry 集成

二、🔑 身份认证：弱认证的终结

2.1 mysql_native_password 的移除（9.0）

在 MySQL 8.0 时代，虽然默认认证插件已切换到 caching_sha2_password，但 mysql_native_password 插件仍然可用，大量遗留系统继续依赖 SHA-1 哈希算法进行密码认证。SHA-1 早已被证实存在碰撞攻击风险（详见 SHAttered 攻击）且不含盐值，在现代安全标准下已被视为不安全的哈希算法。

MySQL 9.0 迈出了决定性的一步：彻底移除 mysql_native_password 认证插件，不再接受来自仅支持该插件的旧客户端程序的认证请求。同时，MySQL 客户端工具默认不再包含对该插件的支持。

升级影响：在从 8.0 升级到 9.x 之前，DBA 必须检查所有应用程序的 MySQL 客户端库是否支持 caching_sha2_password。如果某个应用程序使用了过时的 Connector 版本（如 Connector/J 8.0.11 之前的版本），升级后将无法连接数据库。

2.2 OpenID Connect 与 MFA 支持（9.1 / 9.6）

MySQL 企业版在 9.1 版本中引入了 OpenID Connect 可插拔认证，使用户可以基于 OAuth 2.0 框架，通过外部身份提供商（如 Okta、Azure AD、Google Identity）的认证令牌登录 MySQL 服务器。该能力与 MySQL 8.0 就已引入的 LDAP、PAM 认证插件形成互补，使 MySQL 能够无缝融入企业级统一身份管理平台。

在 9.6 版本中，MySQL 进一步支持了多因素认证（MFA），单个账户最多可配置三种认证方法，从而实现两因素（2FA）或三因素（3FA）认证。这意味着 DBA 可以为高权限账户配置「密码 + WebAuthn 生物识别 + OIDC 令牌」的多层身份验证，显著提升账户安全性。

2.3 密码哈希强度提升（9.5 / 9.7 LTS）

9.5 版本：将 caching_sha2_password_digest_rounds 参数的默认值从 5000 大幅提升至 10000。哈希迭代次数翻倍意味着暴力破解的时间成本呈指数级上升。同时，SCRAM-SHA-1 认证方法被标记为弃用，默认改用更安全的 SCRAM-SHA-256。

9.7 LTS：caching_sha2_password 认证插件新增对 PBKDF2（Password-Based Key Derivation Function 2）存储格式的支持，并可使用 SHA512 哈希算法。PBKDF2 是 NIST 推荐的标准密钥派生函数，通过引入盐值和可配置的迭代次数，有效抵抗彩虹表和暴力破解攻击。

2.4 错误提示标准化（9.6）

MySQL 9.6 统一了连接不存在的用户时的错误提示。此前不同版本、不同用户名长度下，MySQL 会返回略有差异的错误信息，攻击者可以利用这种信息差异推断账户是否存在。9.6 将所有失败连接统一返回「Access denied」错误，消除了账户枚举的信息泄露风险。

三、🛡️ 权限模型：SUPER 时代的终结

3.1 SUPER 权限的拆分与演进

在 MySQL 5.x 和早期 8.x 时代，SUPER 权限是一个「万能钥匙」，同时涵盖系统变量修改、连接管理、二进制日志控制、复制管理等众多特权。DBA 为了「图省事」，常常将 SUPER 授予大量用户，埋下了巨大的安全风险。

自 MySQL 8.0 开始，Oracle 逐步将 SUPER 权限拆分为多个细粒度权限。到了 9.x 时代，这一拆分已经基本完成。如今，DBA 可以根据最小权限原则，为不同角色授予精确的权限组合：

-- 示例：为运维人员创建运行时参数调整角色
CREATE ROLE role_ops_runtime;
GRANT SYSTEM_VARIABLES_ADMIN, CONNECTION_ADMIN ON *.* TO role_ops_runtime;
CREATE USER 'ops'@'10.%' IDENTIFIED BY 'strong-password';
GRANT role_ops_runtime TO 'ops'@'10.%';
SET DEFAULT ROLE role_ops_runtime TO 'ops'@'10.%';

上述示例中，SYSTEM_VARIABLES_ADMIN 仅允许修改系统变量，CONNECTION_ADMIN 仅允许管理客户端连接，二者合起来覆盖了运维人员的核心需求，但并未授予二进制日志管理或复制控制等更高风险的特权。

3.2 强制角色激活（9.5）

MySQL 9.5 引入了 activate_mandatory_roles 系统变量（默认开启），用于控制「强制角色」的激活逻辑。该变量与已有的 activate_all_roles_on_login 形成互补：

`activate_all_roles_on_login`	`activate_mandatory_roles`	登录后激活的角色
开启	忽略	所有已授予角色 + 强制角色
关闭	开启	默认角色 + 强制角色
关闭	关闭	仅默认角色

强制角色机制在金融、医疗等合规要求严格的场景中尤为实用——例如，可以创建一个「审计角色」，该角色拥有查看审计日志表的权限，然后将其设为强制角色。即便 DBA 在创建业务账户时「忘记」授予审计权限，系统也会自动强制激活该角色，确保审计合规。

3.3 权限相关的新增表（9.6）

Performance Schema 在 9.6 版本中新增了 TEMPORARY_ACCOUNT_LOCKS 表，用于查看被临时锁定的账户信息；HOST_CACHE 表也增加了账户锁定统计列，为安全审计和账户异常行为监控提供了更完善的数据支撑。

四、🔐 数据加密：从传输层到存储层

4.1 复制连接默认加密（9.5）

在 9.5 版本之前，MySQL 的复制加密需要 DBA 手动配置 SSL/TLS 相关参数，很多生产环境中复制流量以明文传输。9.5 将复制连接的加密设为默认行为：

参数	9.5 之前的默认值	9.5 及之后的默认值
`SOURCE_SSL`（CHANGE REPLICATION SOURCE TO）	0（未指定）	1（启用）
`group_replication_ssl_mode`	DISABLED	REQUIRED
`group_replication_recovery_use_ssl`	OFF	ON

这意味着主从复制、Group Replication 成员间的数据同步和恢复操作默认均使用加密通道，有效防御中间人攻击，尤其适合跨机房、云环境的部署场景。

4.2 OpenSSL 升级

MySQL 9.6 将捆绑的 OpenSSL 库升级至 3.0.18 版本，修复了 CVE-2025-9230（缓冲区溢出漏洞，CVSS 7.5）等多个安全漏洞。同时，opentelemetry-cpp 升级至 1.23.0，提升了系统的安全性和可观测性。

4.3 企业版：透明数据加密（TDE）

MySQL 企业版提供了透明数据加密（TDE）功能，对数据文件执行实时的 I/O 加密和解密——数据写入磁盘前自动加密，从磁盘读取时自动解密，整个过程对应用完全透明。

TDE 通过密钥环组件（Keyring Component）进行密钥管理，支持多种后端存储，包括 KMIP 兼容的密钥管理服务器。在 9.5 版本中，密钥环组件获得了多项修复和增强，包括解决短路径配置文件读取问题以及修复无效参数处理异常。

TDE 与动态脱敏的对比：

维度	TDE（静态加密）	动态数据脱敏
目的	控制「数据是否可读」（磁盘层面）	控制「谁能看到明文」（访问层面）
数据状态	磁盘上为密文	磁盘上仍是明文
适用场景	保护静态数据，防止物理介质泄露	生产环境中限制非特权用户查看敏感字段

五、📋 审计日志：组件化与合规化

5.1 审计日志系统组件化重构（9.6）

MySQL 9.6 对审计日志系统进行了重大架构升级，将原有的单体审计模块拆分为独立的组件，支持按需安装和配置。

组件化带来的核心改进包括：

按需安装：用户可根据合规要求选择是否安装审计组件，避免不必要的资源开销
配置精细化：可独立设置日志格式（XML、JSON、CSV）、存储路径和缓冲区大小
权限分离：修改 audit_log_rotate_on_size 等关键参数需要 AUDIT_ADMIN 特权，增强了安全管控能力

在 9.6 版本中，审计日志插件（audit_log plugin）已被正式标记为弃用，由审计日志组件（audit_log component）全面替代。

5.2 审计策略建议

对于需要满足金融、医疗等行业的合规审计要求（如 PCI DSS、等保 2.0）的企业，建议：

启用审计日志组件，记录所有敏感操作（DDL、DCL、表结构变更、权限授予与回收）
将审计日志输出配置为 JSON 格式，便于与第三方日志分析平台集成
定期轮转审计日志文件并加密存储，防止日志被篡改或泄露

六、🔏 数据脱敏：动态保护敏感信息

6.1 MySQL 企业版数据脱敏组件

MySQL 企业版提供数据脱敏组件，将敏感数据的部分内容替换为掩码字符（例如将信用卡号除最后四位外的所有数字变为 ‘X’），在不影响数据可用性的前提下保护敏感信息。

主要脱敏函数包括：

函数	功能
`mask_pan()`	对信用卡号进行脱敏（保留后四位）
`mask_ssn()`	对社保号进行脱敏
`mask_inner()`	对字符串内部字符进行脱敏
`mask_outer()`	对字符串首尾字符进行脱敏

动态脱敏与静态脱敏的区别：动态脱敏在查询时实时返回脱敏结果，磁盘上的数据保持原样，适合生产环境中限制非特权用户的查询结果；静态脱敏则生成一份永久脱敏的数据副本，适用于开发测试环境或数据共享场景。

6.2 社区版的替代方案

MySQL 社区版不包含官方数据脱敏组件，但可以通过以下替代方案实现类似效果：

使用 SUBSTRING()、REPEAT()、CONCAT() 和 LPAD() 等内置函数组合实现基础脱敏
创建视图，在视图定义中对敏感字段进行脱敏处理
使用 MySQL Proxy Plugin API 拦截查询结果并动态修改数据缓冲区
在应用层实现脱敏逻辑

七、⚠️ 漏洞管理与 CVE 态势

7.1 9.x 系列重点漏洞

MySQL 9.x 系列自发布以来，Oracle 持续修复了大量安全漏洞。以下是值得重点关注的安全更新：

9.6.0（2026年1月） 修复了 14 个安全漏洞，其中两个为高危远程可利用漏洞：

CVE	严重程度	影响组件	说明
CVE-2025-6965	9.8（严重）	SQLite 库（Docker 镜像）	远程代码执行或拒绝服务
CVE-2025-9230	7.5（高危）	OpenSSL 库	缓冲区溢出漏洞，可远程利用

其余漏洞涉及 OpenSSL 组件、InnoDB、查询优化器和认证系统等多个核心组件。

9.7 LTS 修复漏洞：包括 CVE-2026-34272（优化器组件 DoS 漏洞，影响 9.0.0-9.6.0）和 CVE-2026-35234（分区管理组件 DoS 漏洞，影响 9.0.0-9.6.0）等，低权限攻击者可通过网络访问触发服务器崩溃或挂起。

7.2 8.0 EOL 的风险升级

2026 年 4 月 21 日，MySQL 8.0 发布了最后一个版本 8.0.46，正式进入 Oracle 的 Sustaining Support 阶段。从 2026 年 5 月 1 日起，Oracle 不再为 8.0 提供任何新的安全补丁和 bug 修复。

运行 MySQL 8.0 的生产实例将面临以下风险：

风险维度	具体表现	影响程度
安全漏洞	新发现的 CVE 无官方补丁	极高
合规审计	PCI DSS 4.0.1、等保 2.0 等可能不通过	极高
第三方依赖	OpenSSL、cURL、zlib 等库的 CVE 同样无补丁	高

建议：尽快将生产环境升级至 8.4 LTS 或 9.7 LTS，避免长期安全风险累积。

八、📦 社区版 vs 企业版安全能力对比

安全能力	社区版（9.7 LTS）	企业版（9.7 LTS）
身份认证	caching_sha2_password、LDAP、PAM（需自行集成）	OpenID Connect、LDAP、PAM、WebAuthn（MFA）
权限管理	细粒度权限（拆分后的 SYSTEM_VARIABLES_ADMIN 等）	细粒度权限 + 强制角色激活
传输加密	SSL/TLS（需手动配置）	复制连接默认加密 + 企业级配置工具
存储加密	不支持 TDE	透明数据加密（TDE）+ 密钥环管理
审计日志	无官方审计组件	审计日志组件（组件化、JSON/XML/CSV 输出）
数据脱敏	无官方脱敏组件（可通过视图/函数模拟）	数据脱敏组件（完整掩码函数集）
防火墙	无	企业防火墙（SQL 注入防御）

值得注意的是，9.7 LTS 已将多项原企业版能力开放至社区版，包括向量函数、Hypergraph 优化器、JSON Duality Views 等，但核心安全组件（TDE、审计日志、数据脱敏、防火墙）仍保留在企业版中。

九、开源生态的安全实践

9.1 Percona 的安全策略

Percona 作为 MySQL 生态中最重要的开源分支之一，在安全策略上具有两个突出特点：

1. 快速漏洞响应：Percona 密切跟踪 Oracle 发布的安全公告，通常在一周内为受影响的 Percona Server 版本提供补丁。企业可以通过 Percona 的订阅服务获得优先的安全更新。

2. 供应链安全：2026 年 4 月，Percona 与供应链安全厂商 Chainguard 宣布建立合作关系，旨在简化 Percona 全线产品（MySQL、PostgreSQL、MongoDB、MariaDB、Valkey、Redis）的工作流程，推动「安全即默认」（Secure-by-Default）的开源数据库实践。

9.2 社区审计方案

MySQL 社区版缺乏原生审计功能，企业可通过以下第三方方案实现审计：

MariaDB Audit Plugin：可嵌入 MySQL 社区版，实现细粒度日志记录
ProxySQL / MaxScale：在代理层实现透明审计，支持 JSON 格式日志输出
Percona Audit Log Plugin：部分 Percona Server 版本中包含了增强版审计日志功能

十、生产环境安全加固清单

基于 9.x 系列的安全能力，以下是一份可供直接落地的生产环境安全加固检查清单：

✅ 基础配置

[ ] 移除默认的匿名账户和 test 数据库
[ ] 为所有账户设置强密码（大小写字母 + 数字 + 特殊字符，长度不少于 16 位）
[ ] 修改 MySQL 默认端口 3306，避免被自动化扫描工具探测
[ ] 禁用 local_infile 和 secure_file_priv 以防止本地文件读取攻击

✅ 身份认证

[ ] 确认所有应用程序的 MySQL Connector 版本支持 caching_sha2_password
[ ] 将 caching_sha2_password_digest_rounds 保持为 10000 或更高
[ ] 为高权限账户启用 MFA（企业版，9.6+）

✅ 权限管理

[ ] 停止使用 SUPER 权限，改用细粒度权限（SYSTEM_VARIABLES_ADMIN、CONNECTION_ADMIN 等）
[ ] 使用 ROLE 进行权限分组，严格遵循最小权限原则
[ ] 定期审查账户权限，移除不再使用的账户

✅ 网络与传输加密

[ ] 启用 SSL/TLS 连接（require_secure_transport=ON）
[ ] 确认复制通道已启用加密（9.5+ 默认为启用状态，但需检查升级后的兼容性）
[ ] 配置防火墙或安全组，仅允许授权的 IP 段访问数据库端口

✅ 数据加密与脱敏

[ ] 对存储敏感数据的表空间启用 TDE（企业版）
[ ] 为非特权用户配置动态脱敏规则（企业版）
[ ] 对备份文件进行加密存储

✅ 审计与监控

[ ] 安装并配置审计日志组件（企业版，9.6+）
[ ] 将审计日志输出至集中式日志平台（ELK、Splunk 等）
[ ] 配置 OpenTelemetry 导出器，将安全事件与可观测性体系整合（9.7 LTS）

✅ 漏洞管理

[ ] 订阅 MySQL 安全公告，及时获取 CVE 信息
[ ] 每季度评估一次漏洞影响并制定补丁计划
[ ] 若仍在使用 8.0，尽快规划向 8.4 LTS 或 9.7 LTS 的升级

十一、展望

展望未来 MySQL 10.x 创新版，值得关注的安全演进方向包括：

更强的默认安全：继续减少需要手动配置的安全项目，推动「安全即默认」理念
AI 驱动的异常检测：将机器学习引入审计日志分析，自动识别异常访问模式
字段级加密：支持更细粒度的存储加密能力，而非仅限整个表空间
开源安全组件的开放：随着 Oracle 逐步将企业版功能下放至社区版的承诺持续兑现，审计日志、数据脱敏等核心安全功能在未来 LTS 版本中有望向社区版开放

十二、总结

本期我们系统解读了 MySQL 9.x 系列在安全领域的技术演进：

身份认证：从 9.0 彻底移除 mysql_native_password，到 9.5 提升密码哈希强度，再到 9.6 支持 MFA、9.7 支持 PBKDF2，MySQL 的认证体系完成了从「弱认证」到「强认证」的全面升级
权限模型：SUPER 权限的拆分在 9.x 时代全面落地，配合 9.5 的强制角色激活和 9.6 的 Performance Schema 锁定账户表，权限管控已进入精细化时代
数据加密：9.5 将复制加密设为默认行为，结合企业版 TDE，MySQL 实现了从传输层到存储层的全链路加密
审计与脱敏：9.6 完成审计日志组件化重构，企业版提供动态数据脱敏能力，为合规审计提供了坚实基础
社区版 vs 企业版：核心安全组件仍主要保留在企业版中，社区版可通过 Percona 分支、ProxySQL 等开源方案进行补充
8.0 EOL：2026 年 5 月 1 日起 8.0 不再获得安全补丁，升级至 9.x 已是安全合规的刚需

下一期预告：MySQL 新技术系列第六期——「MySQL 9.x 云原生实践：容器化、可观测性与自动化运维」。我们将深入探讨 9.6 的 container_aware 特性、OpenTelemetry 可观测性集成、MySQL Shell 自动化能力升级，以及云环境下的部署最佳实践。敬请期待！

欢迎大家在评论区留言交流，告诉我你最想深入了解的主题，我会在后续系列中优先安排！

📚 参考资料

MySQL 9.0 Release Notes – Removal of mysql_native_password
MySQL 9.1 Release Notes – OpenID Connect Authentication
MySQL 9.5 Release Notes – Security Enhancements（复制加密默认启用、密码哈希强度提升）
MySQL 9.6 Release Notes – Audit Log Component, MD5/SHA1 Migration, MFA
MySQL 9.7 LTS Announcement – PBKDF2 Support, OpenTelemetry Integration
MySQL 9.6 Reference Manual – Enterprise Data Masking
MySQL 9.6 Reference Manual – Performance Schema TEMPORARY_ACCOUNT_LOCKS Table
Oracle Blog: MySQL 9.0 – It‘s Time to Abandon the Weak Authentication Method
严少安：MySQL 8.0 结束生命周期，8.4.9 LTS、9.7.0 LTS 发版上线
IT邦德：MySQL 9.6.0 正式 GA 刚刚发布，有重大变更
技术栈网：MySQL 9.6.0 创新版正式发布
ABI.EE: MySQL 9.6.0 Release
掘金：MySQL 9.6.0 创新版正式发布
Gihyo.jp：第269回 SUPER権限のその後
Percona + Chainguard Partnership Announcement