如何运用Redis 6.0 ACL权限控制提升安全性_最小化命令授权防止高危操作

必须升级到Redis 6.0+，否则ACL命令不存在；默认用户仍具全权，需按业务建模独立用户并绑定key前缀（如~order:*），禁用危险命令，注意权限顺序及客户端显式传用户名。

必须升级到 Redis 6.0+，否则 ACL 命令根本不存在，所有配置都无效。

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

运行 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:* ~user:* 是非法语法）。因此不能靠一个用户覆盖多个业务前缀，必须拆分：

• 订单服务用户只能写 ~order:*，且只开放 +@sortedset +@string，禁用 -FLUSHDB -KEYS
• 用户服务用户只能写 ~user:*，开放 +@hash +@string，禁用 -CONFIG -DEBUG
• 监控账号只读，用 +@read ~monitor:*，并显式剔除 -CLIENT -INFO（避免暴露连接详情）

键模式一旦设错（比如写成 ~order 而非 ~order:*），该用户将无法命中任何 key，命令返回 NOPERM 但无明确提示，排查时容易卡在权限判断环节。

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

ACL 权限按命令输入顺序“最后一条生效”，但 +@write 这类类别内部已预置子命令列表，-SET 放在它后面不会生效。正确做法是：

• 优先用细粒度列举：+GET +HGETALL +ZADD -FLUSHALL -KEYS -DEBUG
• 若必须用类别，确保 -command 在 +@category 之后，且该命令确实在类别中（ACL CAT @write 可查）
• +@all 是高危操作，即使后续加 -FLUSHALL，也可能漏掉未归类的子命令（如某些模块扩展命令）

测试时别只信命令输入顺序，务必用 ACL GETUSER <username> 查看 commands 字段实际生效值，它才是客户端真实权限快照。

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

Redis 6.0 的 AUTH 已从单参数变为双参数：AUTH <username> <password>。如果代码里还用 AUTH <password>，连接会自动 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 全权上下文中运行——这是生产环境最常被忽略的一环。