MySQL权限管理须遵循最小权限原则，禁用root远程登录、按业务模块建库并精确授表级权限、动态分发凭证、启用审计日志监控GRANT/REVOKE、部署ProxySQL拦截高危语句，并将权限策略嵌入研发流程。
MySQL 用户权限分配必须遵循最小权限原则
开发人员直接在生产环境执行 GRANT 操作，是多数数据泄露事件的起点。权限一旦赋予，就脱离了审计与回收路径；尤其当账号长期未清理、密码硬编码进脚本、或使用通配符主机（如 'user'@'%'）时，风险急剧放大。
实操建议：
- 禁用
root远程登录，所有管理操作通过跳板机 + 临时授权账号完成 - 为每个业务模块单独建库，再创建仅对该库有
SELECT, INSERT, UPDATE权限的账号，明确拒绝DROP、ALTER、CREATE - 避免使用
GRANT ... ON *.*或GRANT ... ON database.*，而应精确到表级，例如GRANT SELECT ON mydb.orders TO 'app_rw'@'10.20.30.%' - 定期用
SELECT user, host, authentication_string FROM mysql.user检查是否存在异常主机段或过期账号
禁止开发人员接触生产数据库的账号密码
很多团队把 MySQL 连接信息写进 .env 或配置中心，但没做分级隔离——开发、测试、预发环境共用一套凭证，或让开发能直连生产库的账号出现在 CI/CD 流水线中。一旦某台开发机被入侵或配置误提交，等同于交出钥匙。
实操建议：
- 生产数据库连接凭据必须由 DBA 或密钥管理系统（如 HashiCorp Vault、阿里云 KMS）动态下发，不可静态存储
- CI/CD 中所有数据库操作（如 Flyway 迁移）应使用专用只读账号，且该账号权限仅限于迁移所需表结构变更，不包含数据读写
- 禁止在代码仓库中搜索到
password=、PASSWORD=、mysql://等明文凭证模式；可用git secrets或gitleaks做提交前拦截
启用 MySQL 的审计日志并监控 GRANT/REVOKE 行为
默认 MySQL 不开启审计功能，general_log 和 slow_query_log 都不记录权限变更语句。没有日志，就无法追溯是谁、何时、给谁开了什么权限——等于放任越权行为野蛮生长。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
实操建议：
- 启用企业版审计插件（
audit_log）或社区替代方案（如 MariaDB 的server_audit插件），重点过滤GRANT、REVOKE、CREATE USER、DROP USER - 将审计日志输出到远程 syslog 或 ELK，设置告警规则：1 小时内同一 IP 执行超过 3 次
GRANT即触发通知 - 对 DBA 账号也启用操作留痕，避免“内部人绕过流程”的情况发生
用 ProxySQL 或数据库网关截断非法权限请求
即使权限已收紧，攻击者仍可能利用应用层漏洞（如 SQL 注入）拼接出 SELECT ... INTO OUTFILE 或调用 LOAD_FILE() 读取系统文件；更危险的是 SSRF 场景下，后端服务若用用户可控参数构造 MySQL 连接串，可能被诱导连接内网其他数据库实例。
实操建议：
- 在应用与 MySQL 之间部署
ProxySQL，配置mysql-query_rules拦截含INTO OUTFILE、LOAD DATA INFILE、SELECT ... FROM mysql.的语句 - 禁用
local_infile=OFF（服务端）和secure_file_priv=""（必须设为非空目录或NULL） - 对敏感库（如
mysql、information_schema）在 ProxySQL 层做路由屏蔽，任何尝试访问都返回统一错误
真正难防的不是技术漏洞，而是开发人员在“赶进度”时顺手加的一条 GRANT ALL PRIVILEGES。权限策略必须嵌入研发流程——比如 GitOps 方式管理账号定义、PR 合并前自动校验 SQL 权限语句、上线检查清单强制包含权限复核项。否则，再细的配置也会被一次疏忽绕过。
