MySQL 安全规范核心是“最小权限 + 分层防护 + 持续审计”，包括：1. 账号权限按需分配、禁用宽泛授权、定期清理闲置账号；2. 强制 SSL 加密传输、禁用旧 TLS 版本；3. 敏感字段加密存储、日志脱敏与限权；4. 备份加密离线、每日校验、预置应急账号。
制定 MySQL 数据库安全规范，核心是“最小权限 + 分层防护 + 持续审计”。不是堆砌技术，而是建立可落地、可检查、可追责的管理习惯。
账号与权限：只给够用的，不给多余的
生产环境严禁使用 root 连接应用；每个业务系统应分配独立账号，并严格限制其数据库、表、操作类型。
- 创建账号时明确指定 host（如 ‘app1’@’192.168.10.5′），禁用 ‘user’@’%’ 这类宽泛授权
- 权限按需授予：不给 INSERT/UPDATE/DELETE 权限，就别给 SELECT；只读服务一律用 SELECT + LOCK TABLES（仅限必要）
- 定期清理闲置账号（如三个月未登录），用 SELECT user, host, password_last_changed FROM mysql.user WHERE account_locked = ‘N’ 辅助排查
连接与传输：默认不裸奔
MySQL 默认明文传输密码和数据，公网或跨网段访问必须加密，内网也建议统一启用。
- 强制开启 SSL：在 my.cnf 中配置 require_secure_transport = ON，并为账号添加 REQUIRE X509 或 REQUIRE SSL
- 禁用旧协议：设置 tls_version = TLSv1.2,TLSv1.3，避免 TLSv1.0 等已知风险版本
- 应用连接字符串中显式指定 &tls=true（如 JDBC 的 useSSL=true&requireSSL=true），不依赖服务端默认行为
敏感数据 与日志：看不见，才安全
数据库不是保险箱，而是放大器——存了什么，就可能泄露什么。
- 身份证、手机号、银行卡等字段必须加密存储：优先用 AES_ENCRYPT() 配合应用层密钥管理，避免硬 编码 密钥
- 慢查询日志、通用查询日志默认关闭；如需开启，确保日志路径不在 Web 可访问目录，且禁止记录 INSERT/UPDATE/DELETE 的完整值（设 log_output = TABLE 并过滤敏感语句）
- 错误日志中避免暴露表结构或 SQL 片段，调整 log_error_verbosity = 1（只记错误级别）
备份与应急：救得回来才算真安全
安全不只是防入侵，更是防误操作、防勒索、防硬件故障。
- 备份文件须加密（如用 gpg –cipher-algo AES256）并离线存放，权限设为 600，归属专用备份用户
- 每日校验备份可用性：用 mysqlcheck –check –databases 或还原到临时实例执行简单查询
- 预置应急账号（如 recover@localhost），仅含 SELECT 和 LOCK TABLES 权限，密码离线保管，不录入任何配置管理系统
不复杂但容易忽略：安全规范的生命力不在文档厚度，而在每次上线前是否执行权限复查、每次变更后是否更新审计日志、每次故障后是否回溯访问来源。把动作变成 checklist，比写一百页策略更有效。
