Redis 6.0 ACL权限控制：最小化命令授权提升安全性

一个必须前置的硬性前提：你的Redis必须升级到6.0+版本，否则ACL这套权限体系根本不起作用，连ACL这个命令都找不到。

顺便说一句，哪怕是升级到了6.0，default用户默认也是权限全开的，这一点很容易被忽略。

确认版本和默认用户权限是否已实际生效

先用redis-server --version确认版本号，输出必须是Redis server v=6.0.0或更高才行。低于这个版本，执行ACL SETUSER只会收到一个神秘的ERR unknown command `ACL`。启动之后，建议立刻跑一遍ACL LIST，你会看到类似user default on nopass ~* &* +@all这样的输出——这代表ACL模块虽然启动了，但default用户依旧拥有“上帝视角”，没有任何权限隔离。这时候，就算你辛辛苦苦创建了其他用户，只要客户端没有显式地用AUTH切换身份，所有操作还是走default用户，权限配置形同虚设。

按业务边界建模用户，严格绑定key pattern

ACL的~规则只支持glob模式匹配（比如~order:*），不支持正则表达式或通配符叠加。这意味着你没法用一个用户覆盖所有业务前缀，必须把不同业务拆分成独立的用户：

• 订单服务用户：权限限定在~order:*，只开放+@sortedset +@string，同时要禁用-FLUSHDB -KEYS这样的高危命令。

• 用户服务用户：权限限定在~user:*，开放+@hash +@string，禁用-CONFIG -DEBUG。

• 监控账号：只读权限，使用+@read ~monitor:*，并且显式剔除-CLIENT -INFO，以防暴露连接细节。

键模式这个细节非常关键。如果写成了~order而不是~order:*，那么这个用户将无法命中任何key，所有命令都会返回NOPERM，而且没有任何明确的错误提示。排查问题时，你可能会在权限判断环节卡很久，得特别注意。

命令权限顺序决定最终效果，避免+@category -command陷阱

ACL权限的生效规则是按命令输入顺序“最后一条生效”。但这里有个隐藏的坑：+@write这类类别内部已经预置了子命令列表，如果你在后面加一条-SET，它并不会覆盖类别中的SET权限。正确的做法是：

• 优先用细粒度列举：比如+GET +HGETALL +ZADD -FLUSHALL -KEYS -DEBUG。这样每个命令的权限都清清楚楚，不容易出错。

• 如果实在要用类别，务必确认-command位于+@category之后，并且确认这个命令确实属于该类别（可以通过ACL CAT @write来查）。

• +@all是高危操作，即使后面加个-FLUSHALL，也很可能漏掉一些未归类的子命令，比如某些模块扩展的命令。建议尽量避免使用。

测试时别只看命令输入的顺序，一定要用ACL GETUSER 查看commands字段的实际生效值。这个字段才是客户端真正拿到的权限快照。

客户端连接必须显式传用户名，旧版AUTH不兼容

Redis 6.0的AUTH命令已经从单参数升级为双参数：AUTH 。如果代码里还使用旧版的AUTH ，连接会悄悄fallback到default用户，你辛辛苦苦配置的ACL等于完全白费。生产环境中，这个环节是最容易被忽视的。

几个常见客户端配置要点：

• Spring Data Redis：默认不传用户名，需要显式配置spring.redis.username=order_svc。

• Node.js的ioredis：需要在构造选项中加上username: 'order_svc'。

• Python的redis-py：只有6.0+版本才支持username参数，旧版本会报TypeError。

简单说：权限配置得再严，只要客户端没切到正确的用户，所有操作还是发生在default用户的全权上下文里。这是最容易被忽略，也最容易捅娄子的环节。