Redis ACL 用户权限怎么最小化：SETUSER、命令类别与连接验证

线上报表服务只需要读取 report:*，却一直沿用默认用户的全量权限。真正危险的不是密码太短，而是这个账号能不能改键、删键，甚至查看不该接触的业务数据。Redis ACL 的收紧动作要同时覆盖用户状态、命令类别和键名模式，改完还要用真实连接验证。

先把报表账号的权限目标写清楚

假设报表服务只查每日汇总：允许读取 report:daily 和同前缀键，禁止写入、删除、改配置，也不允许访问用户资料键。这个边界比“创建一个只读用户”更具体，后面的每条 ACL 规则都能对应到一次检查。

Redis ACL 规则可以拆成四层：用户是否启用、如何认证、能调用哪些命令、命令作用于哪些键。缺一层，最小权限都可能只是表面收紧。

用 SETUSER 建立最小规则

先在维护窗口准备一个随机密码，并确认客户端支持 ACL。下面示例把 report_ro 设为启用用户，只开放读取类命令，并把键范围锁到 report:*：

ACL SETUSER report_ro resetkeys resetpass on
ACL SETUSER report_ro >一段仅存于密钥管理器的长密码
ACL SETUSER report_ro resetchannels +@read -@dangerous ~report:*
ACL GETUSER report_ro

这里的重点不是命令行本身，而是每个规则都要能解释。resetkeys 防止旧键模式残留，resetchannels 让发布订阅范围从空集开始；+@read 再按需要开放读取类命令，~report:* 限制访问键名。生产环境不要把真实密码写进脚本或工单。

用 ACL DRYRUN 先验证允许与拒绝

直接拿生产账号试错会把“验证权限”变成“修改数据”。先用 ACL DRYRUN 检查同一用户对典型命令的判断：

ACL DRYRUN report_ro GET report:daily
ACL DRYRUN report_ro SET report:daily 2026-08-26
ACL DRYRUN report_ro GET users:1001
ACL DRYRUN report_ro DEL report:daily

第一条应该允许，后面三条应该拒绝。若 GET users:1001 也被允许，先查键模式是否误写成了 ~*；若 SET 仍然通过，检查是否遗留了 +@all 或具体的 +SET 规则。这个阶段只看权限判定，不改变任何键。

真实连接要补一次端到端检查

DRYRUN 验证的是规则，客户端连接还要验证认证方式、默认数据库和连接池配置。用临时环境变量传入凭据，分别执行读取和写入测试；写入测试应在专用测试键上完成，且确认返回权限错误：

redis-cli --user report_ro --pass "$REDIS_REPORT_PASSWORD" GET report:daily
redis-cli --user report_ro --pass "$REDIS_REPORT_PASSWORD" SET report:permission-check 1

第二条失败并不代表连接坏了，关键是错误应指向权限不足，而不是认证失败、键名不匹配或网络超时。报表程序的连接池也要重新建立连接，避免旧连接继续使用默认用户。

上线前保留审计、回滚与误配检查

把 ACL LIST 和 ACL GETUSER report_ro 的脱敏结果保存到变更记录，记录规则变更前后差异。不要保存密码字段，也不要把完整连接串贴到日志。

回滚时优先恢复上一份经过评审的规则，而不是临时执行 +@all。如果报表突然出现大量权限错误，先确认用户是否启用、键前缀是否变化、连接池是否已刷新，再决定是否回滚。

常见问题

只开放 @read 就一定安全吗？

不一定。还要限制键名范围，并检查读取类命令是否暴露了不该给报表账号的数据。

为什么 ACL DRYRUN 通过，应用仍然报权限错误？

常见原因是应用使用了另一个用户名、旧连接未刷新，或实际访问的键名不匹配 report:*。

修改 ACL 后需要重启 Redis 吗？

通常不需要重启即可生效，但仍应按目标 Redis 版本核对持久化、复制和重启后的恢复行为。

把权限检查变成发布清单

一份可复用的 Redis ACL 变更至少应包含：目标用户、允许命令、键名模式、两条允许样例、两条拒绝样例、脱敏后的规则快照和回滚版本。这样权限收紧不是一次性的命令操作，而是可以被复查的发布结果。