MySQL 权限最小化原则怎么落地
直接给
root或
DBA权限给开发人员，等于把数据库的钥匙塞进所有人手里。真正可行的做法是：按角色分组、按库/表粒度授权、禁用高危权限。比如开发只读账号不应有
DROP、
CREATE、
ALTER、
GRANT OPTION，连
SELECT也建议限制到具体库（如
app_production），而非用
*。
CREATE USER 'dev_ro'@'192.168.10.%' IDENTIFIED BY 'pwd123';
GRANT SELECT ON app_production.* TO 'dev_ro'@'192.168.10.%';
REVOKE DROP, ALTER, CREATE, GRANT OPTION ON *.* FROM 'dev_ro'@'192.168.10.%';执行
FLUSH PRIVILEGES;生效（MySQL 8.0+ 在部分场景下可省略，但显式调用更稳妥）
哪些权限属于“越权红线”必须禁用
开发日常只需
SELECT、有限
INSERT/
UPDATE（如测试环境）、
SHOW VIEW；其余基本都该禁。特别注意：
FILE：允许读写服务器文件系统，极易导致配置泄露（如读取
/etc/passwd或 MySQL 的
my.cnf）
SUPER：可 kill 线程、修改全局变量、绕过只读模式，等同于降级为 root
PROCESS：能看到所有 SQL（含敏感参数），违反最小披露原则
REPLICATION CLIENT和
REPLICATION SLAVE：除非明确参与主从调试，否则不应开放
GRANT OPTION：一旦开启，该账号可自行扩大权限，彻底破坏管控链条
如何快速检查现有账号是否越权
别靠人工翻文档，用 SQL 直接查。登录高权限账号后运行：
SELECT
u.User, u.Host,
GROUP_CONCAT(DISTINCT p.Privilege SEPARATOR ', ') AS Privileges
FROM mysql.user u
JOIN mysql.role_edges r ON u.User = r.Granted_role AND u.Host = r.Granted_host
JOIN mysql.role_edges r2 ON r.Granted_role = r2.Granted_role
JOIN mysql.role_edges r3 ON r2.Granted_role = r3.Granted_role
JOIN (
SELECT User, Host,
CASE WHEN Select_priv = 'Y' THEN 'SELECT' END AS Privilege FROM mysql.user
UNION ALL
SELECT User, Host, CASE WHEN Insert_priv = 'Y' THEN 'INSERT' END FROM mysql.user
UNION ALL
SELECT User, Host, CASE WHEN File_priv = 'Y' THEN 'FILE' END FROM mysql.user
UNION ALL
SELECT User, Host, CASE WHEN Super_priv = 'Y' THEN 'SUPER' END FROM mysql.user
UNION ALL
SELECT User, Host, CASE WHEN Grant_priv = 'Y' THEN 'GRANT OPTION' END FROM mysql.user
) p ON u.User = p.User AND u.Host = p.Host
WHERE u.User NOT IN ('root', 'mysql.sys', 'mysql.session')
GROUP BY u.User, u.Host
HAVING Privileges LIKE '%FILE%' OR Privileges LIKE '%SUPER%' OR Privileges LIKE '%GRANT OPTION%';结果为空才表示暂无明显越权账号。注意：MySQL 8.0+ 权限模型已改用
mysql.role_edges和
mysql.role_routines，上述查询需适配——但核心逻辑不变：查
mysql.user表中
File_priv、
Super_priv、
Grant_priv字段是否为
'Y'即可快速定位。
应用连接池里的账号要不要和开发账号分开
要，而且必须分开。开发账号用于本地调试、SQL 审核、故障排查；应用账号只供线上服务使用，权限进一步收窄（例如只允许
SELECT+ 指定几张表的
INSERT）。两者共用一个账号，意味着任何一次代码注入、日志打印、IDE 连接泄露，都会直接暴露生产操作能力。 应用账号命名建议带前缀，如
app_api_rw、
app_report_ro，避免与人名或临时账号混淆 密码必须独立管理，禁止硬编码在代码或
.env中；应通过密钥管理服务（如 HashiCorp Vault、阿里云 KMS）动态获取 应用账号默认启用
max_connections=5类似限制，防止误触发连接风暴 上线前用
SHOW GRANTS FOR 'app_api_rw'@'%';复核，确认没有意外继承的权限
实际中最容易被忽略的是权限回收动作——删掉离职人员账号不等于清除其创建的视图、存储过程或代理用户。只要没显式
DROP PROCEDURE或
REVOKE掉对应对象权限，残留风险就一直存在。
