数据库账号权限的分层设计

很多项目的数据库里只有一个最高权限账号，应用、报表脚本、备份任务全用它连库。平时看不出毛病，一旦某个脚本所在的服务器被入侵，攻击者拿到的就是整库的读写权。分层设计的思路很简单：按用途拆账号，每个账号只拿它干活所需的最小权限。 一、三类账号各管一摊 业务账号给应用用，只授予业务库的增删改查；报表账号给取数脚本和报表工具用，只读，最好限定到具体的库和表；备份账号只给导出所需的权限，配定时任务使用。三类账号对应三种风险面：应用被入侵，损失限制在单个业务库；报表 SQL 写坏了，顶多拖慢数据库，改不了数据；备份任务泄露，影响的是数据可见性而不是完整性。风险面切开了，出事时的排查范围也就切开了。拆分的另一个好处是审计时分得清：连接日志里带着账号名，app_rw 的操作和 report_ro 的操作一眼分开，定位问题比混用一个账号快得多。 二、MySQL 里的落地命令 以 MySQL 为例，业务账号这样建： CREATE USER 'app_rw'@'10.0.%' IDENTIFIED BY '强密码'; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'app_rw'@'10.0.%'; 报表账号把授权换成只有 SELECT；备份账号配合 mysqldump 使用时需要 SELECT 加 LOCK TABLES 两项。来源主机写成内网网段 10.0.%，比放开 % 安全得多。两条红线要守住：不授 GRANT ALL，不加 WITH GRANT OPTION，账号之间不能互相授权。 三、定期核对与回收 权限给出去之后要有人查账。每个季度跑一遍 SHOW GRANTS FOR 'app_rw'@'10.0.%';，对照申请清单看有没有悄悄多出来的权限；下线脚本和离职人员对应的账号，直接 DROP USER 处理，不留"以后可能还用"的僵尸账号。核对结果记档，下次复核才有对照。新建账号一律从最小权限起步，不够再补；反过来先给全再收，基本收不干净。 分层不是多此一举，而是把一次事故的爆炸半径从整库缩到单点。顺云云服务器上自建数据库的团队，建议先把最高权限账号收回本机管理，业务连库全部换成按用途拆分的专用账号。