Redis ACL 限制命令和键 怎样处理

Redis ACL 限制命令和键时，最好把权限拆成两层：先决定用户能调用哪些命令，再决定这些命令能触碰哪些键。只写 ~app:* 并不等于整个实例都安全，因为 FLUSHALL、FLUSHDB、SWAPDB 这类面向全库的命令不依赖具体键模式。稳定做法是用 ACL SETUSER 从零建立用户，给出最小命令集合和业务前缀，最后用 ACL DRYRUN 逐个确认边界。

把“命令允许”和“键允许”分开配置；Redis 7 以后需要读写分离时，用 %R~、%W~ 或 %RW~ 表达键权限，而不是只扩大 ~*。

先把命令边界和键边界分开

假设应用只使用 app:cache: 和 app:data: 两类业务键。读缓存的账号只需要读命令和缓存前缀；写数据的账号需要读写命令，但仍然只能进入自己的业务前缀。这样排查 NOPERM 时，才能判断究竟是命令没有授权，还是键模式没有命中。

用 ACL SETUSER 建立最小权限

ACL SETUSER 会按从左到右的规则修改用户。已有用户不会因为再次调用而自动清空，所以正式配置建议把 reset 放在第一项，再补上启用状态、密码、键模式和命令规则。下面的密码只是占位符，实际应替换为独立的高强度凭据。

# 只读账号：只能读 app:cache: 前缀下的键
redis-cli ACL SETUSER app-reader reset on >REPLACE_WITH_LONG_PASSWORD resetkeys %R~app:cache:* +@read

# 读写账号：只操作 app:data: 前缀，并去掉高风险全库命令
redis-cli ACL SETUSER app-writer reset on >REPLACE_WITH_LONG_PASSWORD resetkeys ~app:data:* +@read +@write -flushall -flushdb -swapdb

# 查看最终规则，确认 resetkeys 没有留下旧的键模式
redis-cli ACL GETUSER app-reader
redis-cli ACL GETUSER app-writer

这里的 %R~app:cache:* 只授予读键权限，适合 Redis 7 及以后版本。~app:data:* 表示读写都允许；如果业务需要更细的控制，可以把它拆成 %R~ 与 %W~。命令类别也要谨慎使用：+@read、+@write 便于覆盖常用命令，但生产环境仍应按业务需要删除不该暴露的命令。

为什么只限制键模式仍可能不安全

键模式只约束命令参数中明确出现的键。面向整个数据库或键空间的命令不受 ~app:data:* 这种模式限制，因此不能把“键前缀匹配”当作全库安全边界。除了显式移除清空和交换数据库的命令，还应避免给业务账号开放配置、脚本管理或用户管理能力。

另一个容易忽略的点是 ACL 规则是增量修改。一次 ACL SETUSER app-writer +get 后，再执行 ACL SETUSER app-writer +set，最终会同时拥有 GET 和 SET；如果要收紧规则，使用 reset 重建，或用 ACL GETUSER 先读取实际结果再做定向删除。

用 ACL DRYRUN 判断到底是哪一层没命中

不要为了排查权限直接执行写入、删除或清空命令。Redis 7 提供的 ACL DRYRUN 会模拟某个用户执行命令，不产生该命令的业务副作用；返回 OK 说明命令和参数对应的权限都通过，返回 no permissions 则说明仍有边界未满足。

# 只读用户访问允许的缓存键，应返回 OK
redis-cli ACL DRYRUN app-reader GET app:cache:user-42

# 同一用户访问不匹配的键，应返回无权限提示
redis-cli ACL DRYRUN app-reader GET app:data:user-42

# 读写用户模拟写入，确认命令与键模式同时满足
redis-cli ACL DRYRUN app-writer SET app:data:user-42 "value"

# 先查看用户规则，再根据结果修改 ACL；不要用真实业务写入代替排查
redis-cli ACL LIST

如果允许的键也返回拒绝，先看 ACL GETUSER 中用户是否为 on、是否真的有对应命令；如果命令允许但目标键拒绝，再检查键名是否包含前缀、是否误用了读写方向。完成调整后再次 DRYRUN，确认的是权限匹配，不是业务数据结果。

常见问题

键模式能限制 FLUSHALL 吗？不能。FLUSHALL 作用于整个数据库，需要从命令权限中显式移除。

为什么重复执行 ACL SETUSER 后权限越来越多？它默认是增量修改，不会替你 reset；收紧时先读取 ACL GETUSER，必要时用 reset 重建。

ACL DRYRUN 会修改数据吗？它只模拟授权判断，不执行被测试的业务命令，适合在调整 ACL 后做无副作用核对。