📢 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
