mysql如何防止权限被滥用_mysql权限控制实践

mysql权限滥用核心风险是权限过大、账号复用与长期不审计；需用show grants查grant option或all privileges账号，收缩host范围，禁用grant all，强制ssl，限连数，8.0+可用角色但不可嵌套，grant/revoke后无需flush privileges。

MySQL 权限滥用的核心风险不在“没设权限”，而在“权限过大+账号复用+长期不审计”——最小权限原则必须落实到每个账号、每条 SQL、每次连接。

如何用 SHOW GRANTS 快速发现高危账号

直接查出谁有 GRANT OPTION 或全库 ALL PRIVILEGES，这类账号等于拥有“发权限的权限”，极易被横向提权：

select user, host FROM mysql.user WHERE Grant_priv = 'Y' OR Super_priv = 'Y';

再对每个可疑账号执行：

SHOW GRANTS FOR 'admin'@'%';

• 重点看是否含 WITH GRANT OPTION —— 除非是 dba 主账号，否则一律删掉
• 检查是否授予了 ON *.*（全实例权限）或 ON database.*（整库权限），而实际只需操作某张表
• 注意 'user'@'%' 这类通配 host：若应用只从内网 192.168.10.0/24 连接，就该缩为 'user'@'192.168.10.%'

创建应用账号时必须避开的三个默认陷阱

很多团队用 CREATE USER + GRANT ALL 一键生成账号，结果埋下隐患：

• GRANT ALL ON app_db.* TO 'app'@'%' → 实际应用通常只读写几张表，应拆成 SELECT, INSERT, UPDATE ON app_db.orders 和 SELECT ON app_db.products
• 忘记 require SSL：公网或混合云场景下，明文传输账号密码极危险，加一句 REQUIRE SSL 强制加密通道
• 未设 MAX_USER_CONNECTIONS：一个被攻破的应用账号可能发起数百并发连接拖垮实例，建议按应用 QPS 预估后设限，例如 MAX_USER_CONNECTIONS 20

用角色（ROLE）替代重复授权，但要注意 MySQL 版本差异

MySQL 8.0+ 支持角色，可把权限打包复用，但 5.7 及更早版本不支持，强行用会报错 Error 1396 (HY000): Operation CREATE ROLE failed：

CREATE ROLE 'app_reader';<br>GRANT SELECT ON sales.* TO 'app_reader';<br>CREATE USER 'report_user'@'10.0.2.%' IDENTIFIED BY 'xxx';<br>GRANT 'app_reader' TO 'report_user'@'10.0.2.%';

• 启用角色前确认 show variables like 'activate_all_roles_on_login'; 是否为 ON，否则用户登录后需手动 SET default ROLE
• 角色不能嵌套（MySQL 8.0.16+ 才支持），避免设计成 role_a → role_b → role_c 的链式依赖
• 回收权限时优先 revoke 角色，而非单个用户——否则下次新建同名用户会意外继承旧权限

权限变更后必须立即 FLUSH PRIVILEGES 吗？

不需要。只有直接修改 mysql.user 等系统表后才需刷新；所有通过 GRANT/REVOKE/DROP ROLE 做的操作，权限立即生效（无需 flush，也不建议 flush）。

误执行 FLUSH PRIVILEGES 反而可能触发 bug：在某些 MySQL 5.7 小版本中，它会重载权限表但忽略内存中的角色缓存，导致新授角色不生效。

真正该做的，是记录每次权限变更：GRANT 操作本身要进版本控制（如 ansible playbooks 或 SQL 变更工单），并定期用 SELECT * FROM mysql.role_edges;（8.0+）核对角色绑定关系是否符合预期。