数据库账号权限最小化实践
发布时间：2026-04-24 19:10
更新时间：2026-04-25 16:09
一个应用一个账号、一个账号只碰一个库，这条规矩能挡住大部分事故的扩散面。权限最小化不是安全洁癖，是给"出事时能坏多大"设一个上限。
一、业务账号只给单库
应用连库账号的权限范围精确到库名，甚至表名：
CREATE USER 'shop_app'@'10.0.0.%' IDENTIFIED BY '强密码';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'shop_app'@'10.0.0.%';
FLUSH PRIVILEGES;
三个要点：只给增删改查，不给 ALTER、DROP 这类结构权限，结构变更有专门的发布流程；host 限定内网网段，不写 %；一个业务一个账号，别多项目共用，出了问题说不清是谁动的。账号命名也定个规矩，比如项目名加角色后缀，一眼能看出账号是给谁用的。
二、只读账号给报表
报表、取数、数据分析单独建只读账号：
GRANT SELECT ON shop.* TO 'report_ro'@'10.0.0.%';
只读的价值是防误操作——报表 SQL 手滑写个 UPDATE，没权限就只是报错，比删了数据再走恢复流程便宜得多。从库上再配一份同名只读账号，把分析查询引过去，主库压力也顺带降了。报表账号尤其别给锁表权限，一条大查询把表锁住，拖垮的是整个从库的复制。
三、root 收回日常不用
root 或所有带 ALL PRIVILEGES 的账号，只用于变更操作和紧急处理，不进应用配置文件、不进代码仓库。配置文件里出现 root 密码，巡检时应当场整改。管理员日常操作也建议用受限普通账号，操作有痕、责任可溯。确实需要高权限操作时，做完及时退出，别开着高权限会话去干别的事。
四、定期审计
每个季度过一遍账号清单：
SHOW GRANTS FOR 'shop_app'@'10.0.0.%';
逐个确认还要不要：离职人员的账号、下线项目的账号、权限悄悄变大的账号，都是审计要抓的对象。清理用 DROP USER，别只改密码了事。审计结果记一份简单台账：账号、权限、负责人、确认时间四个字段就够，有台账才有对照。
权限给得越小，单次事故的爆炸半径越小，这笔投入稳赚不赔。