Redis ACL 分类规则如何限制危险命令集合

Redis ACL 限制危险命令，关键不是把几个高风险命令逐个列出来，而是先看当前实例的命令分类，再按用户职责建立最小权限。业务账号优先放行实际需要的读写类别；确实需要广泛运维能力的账号，才考虑用 +@all -@dangerous，并单独复查模块命令、键前缀和 Pub/Sub 频道。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/

下面用一个只能读缓存键的业务账号和一个受控运维账号说明配置顺序。图中内容均为静态结构说明，不是 Redis 控制台截图，也不是现场执行证据。

先确认当前 Redis 的分类边界

Redis 的 ACL 规则从左到右应用，分类内容会随版本和模块变化，因此不要直接复制旧文章里的完整命令表。先用 ACL CAT 查看类别，再查看 dangerous 具体包含什么：

# 先列出当前实例认识的全部 ACL 类别
ACL CAT
# 再查看危险类别中的具体命令，配置前以实例返回值为准
ACL CAT dangerous

dangerous 是风险提示，不等于所有命令都应对所有用户禁用；例如运维流程可能需要 INFO，但普通业务账号通常不需要 CONFIG、DEBUG、FLUSHALL 或 REPLICAOF。先建立职责矩阵，比单纯追求“禁得越多越安全”更可靠。

从干净权限集开始创建业务用户

新用户默认没有可用命令，生产配置仍建议显式写出重置动作，避免后续增量修改留下历史权限。下面的账号只允许读取 cache: 前缀的键：

# 清空 alice 的旧权限，避免历史授权残留
ACL SETUSER alice reset
# 开启账号、设置密码，只允许读取 cache: 前缀
ACL SETUSER alice on >change-this-secret ~cache:* +@read
# 用机器可读的形式复查用户状态
ACL GETUSER alice

这里的 +@read 只表达读类别，不会自动授予写入权限；~cache:* 又把键空间缩小到缓存前缀。Redis 7 及以后还可以用 %R~cache:* 与 %W~... 分别限制读写键模式，但上线前要根据实例版本确认语法和客户端兼容性。

用类别规则排除危险命令集合

如果某个受控运维账号确实需要大部分内置命令，可以采用“先全量、再扣除危险类别”的写法：

# 运维账号需要广泛能力，但显式排除危险类别
ACL SETUSER ops on >change-this-secret ~* +@all -@dangerous
# 查看最终的命令、键和频道权限
ACL GETUSER ops

这不是万能黑名单：官方文档特别提醒，除 +@all 外，其他类别默认不包含模块命令。若使用模块或自定义命令，应额外用 ACL CAT、具体命令权限和模块文档核对。更稳妥的业务账号仍是 -@all 起步，再添加少量类别和单命令，而不是把 +@all 当默认模板。

还要记住规则是增量应用的。连续两次 ACL SETUSER alice +get、ACL SETUSER alice +set 会同时留下两项权限；修改策略时先 reset，再完整重建，能减少“以为删掉、实际仍在”的误判。

把键、频道和复查动作一起纳入方案

只限制命令类别还不够。允许 +@read 但仍使用 ~*，账号依然能读取不属于本业务的键；使用 Pub/Sub 时则要显式配置 &orders:* 之类的频道模式。建议按以下顺序复查：

1. 用 ACL GETUSER 用户名 检查 flags、commands、keys、channels 是否都符合职责。
2. 用业务允许的键前缀和无关前缀分别验证读取结果，禁止项应返回 NOPERM。
3. 对 FLUSHALL、CONFIG、DEBUG 等高风险命令做明确拒绝测试，并记录变更人和时间。
4. 使用外部 ACL 文件时，再通过 ACL LOAD 载入；不要只改文件而不检查当前运行状态。

最终配置的判断标准是“每个用户都能完成自己的工作，但不能顺手触及别人的键、频道或管理命令”。类别规则负责缩短配置，键和频道规则负责缩小数据范围，ACL GETUSER 负责让这三层边界可读、可审计。

常见问题

-@dangerous 能保证所有危险操作都被禁止吗？

不能。它只针对当前命令表中属于该类别的命令；模块命令、业务自定义流程和未来版本变化仍要单独核对。

为什么加了 +@read 仍然读不到数据？

ACL 同时检查命令权限和键模式。若用户没有匹配目标键的 ~、%R~ 规则，即使命令允许，也会因为键权限不足返回 NOPERM。