mysqldump 备份账号如何避免全库越权：MySQL 角色与 partial_revokes 实战

线上备份脚本最容易被忽略的一行，往往是连接 MySQL 的账号。为了让 mysqldump 少报一个权限错误，很多团队直接给它授予 *.* 上的全库权限；备份任务是成功了，但账号一旦泄露，读取 mysql 系统库和其他业务库的边界也一起被打开了。

备份账号为什么会变成“万能钥匙”

先看一个很常见的配置：定时任务使用 backup_job 连接数据库，账号被授予了 SELECT, SHOW VIEW, TRIGGER, LOCK TABLES 等权限，范围直接写成 *.*。开发者的出发点通常不是扩大权限，而是希望新增业务库后不用再改脚本。

问题在于，授权范围和备份目标范围不是一回事。今天脚本只导出 orders_app，账号却能看到 audit_db、临时测试库，甚至 MySQL 的系统库。备份凭据被放进 CI 变量、脚本配置和运维机器后，攻击路径也不再只有数据库连接本身。

先把资产和攻击路径写成可检查的边界

这次示例准备两个业务库：orders_app 存订单，audit_db 存审计记录。备份任务只需要导出前者的表结构和数据，不需要修改表，也不应该读取用户凭据、授权表或其他租户数据。

把风险拆开后，权限决策会清楚很多：

这里别急着改配置。先固定“允许什么、拒绝什么”，后面的 SHOW GRANTS 和连接测试才有判断标准。

用 MySQL 角色给备份任务划出最小范围

在权限管理员账号中创建角色，并只给 orders_app 授予备份所需权限：

CREATE ROLE 'backup_orders'@'%';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES
  ON `orders_app`.* TO 'backup_orders'@'%';

CREATE USER 'backup_job'@'10.20.%'
  IDENTIFIED BY 'use-a-secret-from-vault';
GRANT 'backup_orders'@'%' TO 'backup_job'@'10.20.%';
SET DEFAULT ROLE 'backup_orders'@'%' TO 'backup_job'@'10.20.%';

账号主机范围也要收紧。备份机在 10.20.0.0/16 内，就不要为了省事写成 '%'。密码示例只是占位，生产环境应由密钥管理系统注入，并按轮换策略更换。

如果应用库包含存储过程或事件，备份所需权限可能还会不同；不要照抄一组权限就结束，先在一份脱敏库上跑一次实际命令，再按报错补最小权限。

需要排除系统库时，partial_revokes 怎么用

优先推荐数据库级授权，因为它的边界最直观。只有当历史账号已经拥有全局权限、短期内不能拆成多个角色时，才考虑 partial_revokes：它允许保留全局权限，同时对指定 schema 做限制。

SET PERSIST partial_revokes = ON;

GRANT SELECT ON *.* TO 'backup_legacy'@'10.20.%';
REVOKE SELECT ON mysql.* FROM 'backup_legacy'@'10.20.%';
SHOW GRANTS FOR 'backup_legacy'@'10.20.%';

输出中应能看到全局授权和针对 mysql 的限制记录。这个机制不是“给账号加了一层防火墙”，也不是把所有隐含风险自动消除：全局权限仍然扩大了可见范围，未来新增 schema 也可能被覆盖。它更适合迁移期或确有全局权限需求的旧账号。

另外，schema 名称里如果带有通配符字符，开启该变量后授权语义会变化，迁移前要在测试实例上核对 SHOW GRANTS 输出，不要只看变更语句是否执行成功。

用允许和拒绝两组测试确认结果

授权完成后，用实际的 backup_job 账号做一次最小验证。允许路径读取订单表，拒绝路径访问另一个业务库和系统库；两组结果都要记录到变更单。

-- 允许：目标库可以读取
SELECT COUNT(*) FROM orders_app.orders;
SHOW CREATE TABLE orders_app.orders;

-- 拒绝：不在备份边界内
SELECT COUNT(*) FROM audit_db.audit_events;
SELECT User, Host FROM mysql.user;

不要只验证 SELECT。如果脚本需要锁表、视图或触发器定义，就把对应操作也跑一遍；如果使用了 GTID、二进制日志或特定导出选项，则按实际参数核对需要的管理权限。测试账号应和生产脚本使用同一个主机匹配规则，否则容易出现“测试通过、上线命中另一个同名账号”的假象。

审计和回退：权限变更要能在半夜恢复

权限调整前保存三份信息：账号的 SHOW CREATE USER、角色的 SHOW GRANTS、备份命令和目标库清单。不要把密码写进快照，快照只保留账号标识和授权语句。

上线后连续观察两次备份窗口，重点看导出返回码、缺失对象、视图/触发器告警和备份文件体积。如果只是角色权限过宽，回退时撤销角色即可；如果是新角色导致任务失败，恢复已验证过的旧授权语句，并在下一次窗口前重新做拒绝测试。

REVOKE 'backup_orders'@'%' FROM 'backup_job'@'10.20.%';
DROP USER 'backup_job'@'10.20.%';

生产环境不要把回退写成“临时授予 ALL”。真正可控的回退是恢复上一份明确的授权快照，并留下谁、何时、为什么恢复的记录。

常见问题：角色授权和 partial_revokes 的边界

只给 SELECT 就足够运行 mysqldump 吗？

不一定。视图、触发器、锁表和导出选项会影响权限需求。应在脱敏环境使用同一组参数跑完整命令，再补齐最小权限。

有了 partial_revokes，还需要拆分角色吗？

需要。partial_revokes 更适合限制已有全局授权，专用角色更容易审计、轮换和回退，新增业务库时也不会无意扩大备份范围。

为什么 SHOW GRANTS 通过了，脚本仍然失败？

可能是连接命中了另一个 Host 匹配账号，也可能是导出参数触发了额外对象权限。先确认当前用户身份，再逐项复现脚本实际操作。

把这套检查留在发布清单里

备份账号的安全边界不是一次授权语句，而是“目标库清单、角色权限、允许/拒绝测试、备份窗口观察、回退快照”五件事一起维护。新库上线时先问它是否真的属于备份范围；如果答案是否定的，最安全的默认状态就是没有权限。