Redis ACL 怎样只允许键前缀操作

如果一个应用只应该访问 app:*，Redis ACL 不能只配置一个用户名和密码，还要同时限制“能执行哪些命令”和“这些命令能触碰哪些键”。最稳妥的做法是为用户先清空旧规则，再显式打开业务命令，最后用 ~app:* 或 Redis 7.0+ 的 %R~、%W~ 收紧键范围。

键前缀权限不是命令白名单的替代品。GET、SET 等命令必须被允许，目标键又必须匹配 app:*；两层都通过，应用请求才会成功。

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

下面用一个应用账号做完整示例：它可以操作 app:user:1001，不能操作 other:user:1001，也不能借助没有明确键范围的管理命令绕过前缀限制。

Redis ACL 的限制其实有两层

Redis ACL 的规则可以分成命令权限、键模式和认证状态三部分。命令权限决定用户能否调用 GET、SET、DEL；键模式决定这些命令允许提及哪些 key。~app:* 是一个 glob 风格的键模式，不是 SQL 的前缀表达式。

这也是为什么不能只写一条 ~app:* 就认为用户已经完成隔离。它只描述 key 的范围；如果用户仍然拥有过宽的命令权限，像清空数据库这类管理动作并不会因为目标 key 不叫 app:* 就自动安全。

先创建只允许 app:* 的读写用户

如果业务只需要几个基础数据命令，推荐显式列出命令，而不是一开始就给用户整组高权限。下面的示例在 redis-cli 交互提示符中执行；示例密码只是占位符，生产环境应换成密码管理系统生成的随机值。

# 在 redis-cli 交互提示符中执行，先清空旧规则，再设置最小读写白名单
ACL SETUSER app-worker reset on >change-me ~app:* +get +set +del +exists +expire +ttl

# 只允许同一前缀下的键；这两条请求的结果应当不同
ACL DRYRUN app-worker GET app:user:1001
ACL DRYRUN app-worker GET other:user:1001

# 没有被白名单打开的管理命令不应通过
ACL DRYRUN app-worker FLUSHALL

这条规则表达了三个约束：用户已启用、只接受指定命令、命令涉及的 key 必须匹配 app:*。ACL DRYRUN 只模拟权限判断，不会真的读取、写入或删除业务数据，适合在把账号交给应用前做边界检查。

如果应用还需要 MGET、MSET、HGET 或 HSET，应按实际调用清单逐个加入；不要为了省事把 +@all 当成默认配置。命令越少，后续排查“谁能做什么”越直接。

Redis 7.0+ 可以把读写键范围拆开

普通的 ~app:* 表示对匹配前缀拥有完整键访问。Redis 7.0 开始，ACL 还可以把键权限拆成读和写：%R~app:* 只允许处理匹配前缀中的用户数据，%W~app:* 只允许更新或删除这些键，%RW~app:* 等价于完整读写。

# 报表账号只读 app:*；命令白名单仍然要单独配置
ACL SETUSER app-report reset on >report-password %R~app:* +get +mget +exists +ttl

# 写入账号只修改 app:*；不要把读取命令自动混进来
ACL SETUSER app-writer reset on >writer-password %W~app:* +set +mset +del +expire

读写拆分适合把报表、缓存刷新、后台任务分成不同身份。它不能替代命令白名单：一个用户即使拥有 %R~app:*，如果没有 +get，调用仍会被拒绝；反过来，只有 +get 而没有匹配的键模式，也不能读取 other:*。

如果部署环境低于 Redis 7.0，就不要发送 %R~ 或 %W~ 规则。可以退回普通的 ~app:* 加命令白名单，或者在应用层拆分账号；不要把新语法当成老版本兼容配置。

怎样确认规则真的生效

配置完成后，至少查看“用户最终规则”和“几个代表性请求”。ACL GETUSER 适合看一个用户的结构化权限，ACL LIST 适合查看所有用户的 ACL 文件格式表示，ACL DRYRUN 适合逐条模拟命令。

# 查看单个用户的 flags、commands、keys 等有效字段
ACL GETUSER app-worker

# 查看全部用户的最终规则，确认没有误留旧用户或宽泛模式
ACL LIST

# 用允许、越界和危险命令各测一次；这些命令只做权限模拟
ACL DRYRUN app-worker SET app:user:1001 value
ACL DRYRUN app-worker SET other:user:1001 value
ACL DRYRUN app-worker CONFIG GET maxmemory

复查时不要只测试一条成功的 SET app:user:1001。至少要覆盖同前缀的允许请求、跨前缀的拒绝请求，以及一个没有被命令白名单打开的管理命令。这样才能分辨问题来自命令权限、键模式还是用户状态。

多前缀、集群和无键命令要单独处理

多个业务前缀：可以为同一个用户加入多个键模式，例如 ~app:user:* 和 ~app:session:*。如果不同前缀需要不同的读写级别，优先拆成不同用户；Redis 7.0+ 也可以用 selector 表达独立的一组规则，但规则会更难审计。

无键命令：~app:* 对没有 key 参数的命令没有约束力，因此命令权限要显式收紧。不要因为键前缀已经设置，就顺手加上 +@all；如果确实采用命令类别，也要明确移除危险命令，并在升级后重新检查类别变化。

集群脚本：如果应用后续使用 Lua 或 Function，同时传入多个 key，要遵守 Redis Cluster 的同槽位要求，通常用 hash tag 设计相关 key。ACL 负责“能否访问”，不负责替你解决脚本的槽位路由。

规则持久化：在线修改后要按部署方式保存 ACL 配置，并把配置变更纳入审计。不要只在测试实例中执行 ACL SETUSER，然后期待重启后自动保留；具体保存动作要结合实例的 ACL 配置文件和运维流程处理。

几个容易混淆的问题

只有 ~app:* 能阻止 FLUSHALL 吗？ 不能。键模式只约束会触碰 key 的命令；对危险的无键管理命令，要从命令权限中移除或根本不要授予。

ACL SETUSER 再执行一次会覆盖旧规则吗？ 默认是增量修改。想从一个干净状态开始，应使用 reset，再按顺序设置启用状态、认证方式、键模式和命令白名单。

读写权限规则从哪个版本开始可用？ 官方 ACL 文档将 %R~ 和 %W~ 标为 Redis 7.0 及以后可用；低版本使用普通键模式配合命令白名单。

为什么 GET 被允许却仍然报权限错误？ 先分别看 ACL GETUSER 中的命令与 keys 字段，再用 ACL DRYRUN 对同前缀和跨前缀 key 各试一次，通常很快能定位是哪一层没有匹配。

最小配置应该记住什么？ 先用 reset 清理历史授权，再明确命令白名单，最后用 ~app:* 或读写键模式限制数据范围，配置后用三个复查命令覆盖允许、越界和危险操作。