云环境下MySQL安全加固基线由合规要求、云平台能力与业务暴露面动态决定，需兼顾数据库配置、云平台策略（如安全组、IAM、KMS加密）及应用接入方式，缺一不可。
云环境下 MySQL 的安全加固基线不是一套固定数值，而是由「合规要求 + 云平台能力 + 业务暴露面」三者动态决定的。直接套用本地部署的 checklist 很可能漏掉关键项，比如云上安全组规则、IAM 策略、托管服务的权限委托机制等。
怎么看云厂商对 MySQL 实例的默认控制粒度
不同云平台对 MySQL 的管控深度差异极大：
- AWS RDS：不开放
mysqld进程权限，my.cnf只能通过参数组修改，plugin-load、skip-grant-tables等高危配置被禁止；但允许你配置 SSL 强制、审计日志导出到 CloudWatch - 阿里云 RDS：支持自定义参数组，但禁用
local_infile和secure_file_priv修改；审计日志需单独开通并付费，且只保留 180 天 - 腾讯云 CDB：允许绑定安全组和网络 ACL，但无法限制单个账号的 IP 白名单（只能靠数据库层
GRANT ... ON ... TO 'u'@'x.x.x.x'）
关键动作：先查你所用云平台的「RDS 权限限制白皮书」或「MySQL 托管服务功能对比表」，确认哪些加固项根本不可行——比如在 RDS 上执行 INSTALL PLUGIN validate_password SONAME 'validate_password.so' 会直接报错 ERROR 1227 (42501): Access denied，必须改用平台提供的密码策略开关。
云环境里最容易被忽略的“非数据库配置”项
很多团队花大量时间调 validate_password_length，却忘了云上真正暴露风险的是网络与身份层：
- 安全组是否放通了
3306到0.0.0.0/0？哪怕数据库设了强密码，只要端口暴露，就可能被暴力扫描撞库 - 数据库账号是否绑定了云 IAM 角色？例如 AWS RDS Proxy 后接 Lambda，应使用 IAM 认证而非硬编码密码
- 备份快照是否加密？RDS 默认开启 KMS 加密，但自建 MySQL + ECS 的快照可能未启用 EBS 加密，导致备份数据可被拖走
-
mysql_history文件在云主机上是否已软链到/dev/null？云镜像常带预装 MySQL，历史记录可能残留 root 密码明文
等保三级场景下必须验证的云原生检查点
等保三级明确要求“通信传输保密性”和“访问控制策略集中管理”，在云环境不能只看 MySQL 自身配置：
- SSL 是否强制？RDS 提供
require_secure_transport=ON参数，但必须配合应用端设置ssl-mode=REQUIRED，否则连接仍可降级为明文 - 审计日志是否留存 ≥180 天且不可删改？公有云审计日志（如阿里云 ActionTrail、AWS CloudTrail）需关联 RDS 数据库事件，仅开 MySQL 的
general_log不满足等保要求 - 账号生命周期是否对接云 AD/LDAP？等保要求“身份鉴别信息丢失后应有措施防止被冒用”，静态密码轮换不如对接企业统一身份源
- 是否禁用
root@%并删除test库？云平台控制台创建实例时可能默认保留这些，需人工确认或通过 Terraform 模板固化清除逻辑
最常踩的坑是把云 MySQL 当成本地数据库来加固：改完 my.cnf 就以为万事大吉，却没意识到安全组开着全通、备份没加密、审计日志没对接 SIEM。云环境的安全基线，本质是数据库配置、云平台策略、应用接入方式三者的交集，缺一不可。
