Redis ACL 怎样按命令类别授予最小权限

我第一次把 Redis ACL 用到业务账号上时，直觉是给“读缓存”账号加上 +@read 就结束。实际排查时才发现，这只解决了“能不能执行读类命令”，没有解决“能读哪些键”，更没有解决 Pub/Sub 频道范围。按命令类别授权很方便，但最小权限必须同时看命令、键和频道三层。

推荐的落地顺序是：先用 ACL CAT 了解实例实际的类别成员，再从 -@all 或新用户的受限状态开始，按业务需要添加命令类别，最后用 ~模式、%R~模式 和频道规则收窄资源范围。类别授权适合稳定的职责边界，单命令授权适合非常窄的接口，+@all -@dangerous 只适合你能持续审查新增命令的受控场景。

先把三类权限分开

Redis ACL 的规则至少有三个维度。第一层是命令权限，例如 +@read、+@string 或单独的 +get；第二层是键权限，例如 ~cache:*，它决定命令参数中的键能否被访问；第三层是频道权限，例如 Redis 6.2 及之后可用的 &events:*，它约束 Pub/Sub 频道。

因此，命令类别不是数据范围。账号拥有 +@read，并不代表它自动拥有所有键；同样，拥有读写类别也不等于可以订阅所有频道。生产配置里最好把这三个维度写在同一份角色说明中，后续改动才不容易遗漏。

先用 ACL CAT 看清类别边界

ACL CAT 不需要你凭记忆猜类别。无参数时可以列出当前实例支持的类别，带类别名时可以查看该类别包含的命令。模块命令和 Redis 核心命令的关系也要留意：官方文档说明，除了 +@all 外，其他类别通常不会自动包含模块命令。

# 查看当前实例可用的命令类别
ACL CAT

# 查看 read 类别实际包含哪些命令
ACL CAT read

# 查看 string 类别，确认 GET、MGET 等命令是否属于当前类别
ACL CAT string

这一步的价值在于把授权依据落到当前实例，而不是照抄另一套 Redis 版本或模块环境的清单。类别名称和命令成员应作为角色设计的输入，不能把网上的固定列表当作永远不变的合同。

三种授权方式怎样取舍

按命令类别授权的优点是短、易读、适合职责稳定的账号。例如缓存读取账号通常可以从 +@read 开始，再结合键模式限制数据域。缺点是类别是一个集合，未来类别成员的变化会影响授权面，所以仍要在升级或模块变更后重新查看。

按单命令授权更精确。只允许 GET、MGET、EXISTS 这样的账号，审查时一眼就能看到接口边界，代价是业务一扩展就需要修改 ACL。它更适合只调用少量 Redis 命令的网关、健康检查或专用 worker。

“先全量再排除”写法，例如 +@all -@dangerous，表达的是允许当前和未来加载的命令，再排除一组危险命令。Redis 官方文档特别提醒，模块加载的新命令可能进入 +@all 的范围，因此这种写法必须有持续审查能力，不能把它当作天然的最小权限。

给只读缓存账号补齐最小权限

下面的角色只负责读取 cache: 前缀下的键。示例使用单命令，是为了展示最窄的授权边界；如果业务还需要 TTL、EXISTS 或其他只读命令，可以逐项增加，或者改用经盘点后的 +@read。

# 创建一个从关闭状态开始的缓存读取账号
ACL SETUSER cache_reader reset on >replace-with-a-secret ~cache:* +get +mget

# 如果业务需要读取剩余时间，再显式补充 TTL
ACL SETUSER cache_reader +ttl

# 用结构化结果查看命令、键和频道三类规则
ACL GETUSER cache_reader

这里的 reset 用来清掉旧密码、旧键模式、旧频道和旧命令，再建立一份可解释的规则。密码示例只表示位置，不要把真实凭据写进 ACL 文件、脚本或文章；生产环境应使用密钥管理系统提供的值。

如果账号要订阅事件，需要另外声明频道，而不是只增加 +@pubsub 就认为范围已经足够窄：

# 只开放订单事件频道，命令类别与频道范围分别表达
ACL SETUSER order_events on >replace-with-a-secret +@pubsub &orders:*

# 清空已有频道范围后再重新声明，避免历史规则残留
ACL SETUSER order_events resetchannels &orders:*

命令类别解决“能调用什么”，键模式和频道模式解决“作用于哪里”。这也是我在实际配置中最容易漏掉的一层：账号看起来已经是只读，实际却因为 ~* 或 &* 触达了过宽的数据域。

用复查命令确认授权是否符合预期

ACL GETUSER 适合检查账号当前的 flags、commands、keys、channels 等字段。若需要按某个用户和命令组合做不改变数据的权限试跑，可以使用 ACL DRYRUN；它的作用是返回该用户执行命令时是否会被 ACL 拒绝，不能代替对真实业务键名、子命令和模块命令的审查。

# 复查账号的完整权限摘要
ACL GETUSER cache_reader

# 只做权限判断，不执行 GET，也不改变缓存内容
ACL DRYRUN cache_reader GET cache:demo

# 用不匹配的键名确认键模式确实收窄了范围
ACL DRYRUN cache_reader GET session:demo

复查时建议至少记录四个结论：目标命令是否允许、命令参数中的键是否匹配、Pub/Sub 频道是否匹配、账号是否仍处于 on 且有可用密码。任何一个维度不清楚，都不要用“只读”这个标签掩盖它。

我的选择规则

如果账号的职责是“读取某个数据域”，我会优先选择 -@all 加少量命令或经盘点的读类别，再配合明确的键模式；如果账号只调用两三个固定命令，单命令授权更容易审计；如果是运维角色，才会考虑全量后排除，并把 ACL CAT、模块变更和升级复查写进变更流程。

最终可以用这张决策表收口：命令集合越窄，越偏向单命令；职责越稳定、命令越成组，越偏向类别；越依赖未来模块或动态命令，越不能把全量授权当成默认安全方案。最小权限不是少写几个字符，而是让命令、键、频道三层边界都能被读懂和复查。

相关问题

只写 +@read 就能访问所有键吗？

不能。命令类别和键模式是两个独立维度，仍需根据数据域配置键权限。

为什么新用户执行命令会返回 NOPERM？

新建用户默认没有可用命令、键和密码，需要显式开启用户、设置密码并添加规则。

+@all -@dangerous 是最小权限吗？

不是天然最小权限。它仍可能覆盖未来加载的命令，且“危险”类别不能替代对业务实际命令集合的逐项审查。