Redis的ACL新特性实现多用户权限精细控制

Redis 6.0 版本引入的 ACL（Access Control List）机制，彻底改变了以往仅靠单一密码保护数据的粗放模式。过去，只要连上 Redis 实例，执行 AUTH 命令后就能获得全部命令的执行权限，这在微服务架构或多人协作场景下风险极高。ACL 的落地，让 Redis 拥有了类似关系型数据库的用户权限管理体系，能精确控制每个用户可执行的命令、可访问的键空间，甚至限制连接数和信道订阅。这意味着运维人员可以为自动化脚本、只读分析任务、开发人员分别创建独立账号，真正实现最小权限原则。

Redis ACL 围绕“用户”展开，默认用户 default 在未显式配置时拥有所有权限。通过定义命名用户，可以附加多组规则。每条规则对应一种允许或禁止的操作，规则之间按顺序匹配，先匹配到的生效。理解规则叠加逻辑是精细控制的基础。例如，可以先禁止所有命令，再仅开放 GET 和 SET，这样用户就只能执行这两种操作。

规则类型主要分为：命令规则、键规则、信道规则、密码规则以及连接限制。命令规则使用 + 和 - 前缀来允许或禁止具体命令，支持类别标记，如 +@read 表示允许所有只读命令。键规则通过 ~ 前缀定义可访问的键模式，支持通配符。信道规则用 & 前缀控制 Pub/Sub 频道的订阅权限。密码规则用 > 前缀存储密码哈希，一个用户可以有多个密码。连接限制则通过 nopass 标记免密，或设置 maxconnections 上限。

通过 ACL SETUSER 命令可以动态创建或修改用户，无需重启实例。创建一个名为 app_readonly 的只读用户，密码为 readonly123，仅允许 GET 命令，且只能访问以 app: 开头的键，配置如下：

ACL SETUSER app_readonly on >readonly123 ~app:* +get -@all

这条命令中，on 表示启用用户，>readonly123 设置密码，~app:* 限定键前缀，+get 允许 GET 命令，-@all 禁止所有其他命令。注意 -@all 必须放在最后，否则会覆盖前面的 +get。如果希望用户拥有读取所有键的权限，只需去掉 ~ 规则或使用 ~*。

对于需要写入权限的服务，可以创建一个具有更多命令的用户：

ACL SETUSER app_writer on >writer456 ~app:* +@write +@read -@dangerous

这里 +@write 和 +@read 允许所有读写命令，但显式禁止了 @dangerous 类别中的命令，如 FLUSHALL、CONFIG 等。Redis 内置了多个命令类别，包括 @admin、@slow、@fast、@keyspace、@pubsub 等，通过 ACL CAT 命令可以查看完整列表。这种基于类别的授权方式大幅简化了权限配置，无需逐个列出上百条命令。

配置文件 redis.conf 中同样支持 ACL。典型配置如下：

user default off
user app_readonly on >readonly123 ~app:* +get -@all
user app_writer on >writer456 ~app:* +@write +@read -@dangerous

第一行将默认用户关闭，强制所有连接必须使用命名用户认证，这是生产环境的推荐做法。配置文件的优势在于持久化，重启后依然生效。动态修改的用户可通过 ACL SAVE 命令持久化到外部文件，配合 aclfile 指令加载。

键模式是 ACL 中最容易被低估的特性。Redis 支持 glob 风格的通配符，* 匹配任意字符，? 匹配单个字符，[abc] 匹配字符集合，[^a] 排除字符。例如 ~user:*:profile 仅匹配 user: 开头、:profile 结尾的键，中间部分任意。这种粒度允许为不同微服务分配完全隔离的键空间，即使它们共享同一个 Redis 实例。

更复杂的场景下，可以定义多个键模式。比如一个用户需要访问 users: 和 sessions: 两个前缀：

ACL SETUSER multi_app on >pass123 ~users:* ~sessions:* +@all -@dangerous

键模式同样适用于 Pub/Sub 信道。通过 & 前缀限制订阅范围，防止敏感信道被未授权监听：

ACL SETUSER pubsub_client on >pspass ¬ifications:* &updates:* +@pubsub -@all

该用户只能订阅 notifications: 和 updates: 开头的信道，且仅能执行发布订阅相关命令。这种控制在事件驱动架构中尤为重要，避免消息泄露。

Redis ACL 支持两种密码存储方式：明文密码和 SHA256 哈希。使用 > 前缀时，Redis 会自动将密码进行 SHA256 哈希后存储，ACL LIST 或 ACL GETUSER 输出中显示的是哈希值。如果需要直接指定哈希值，可以使用 # 前缀。生产环境务必使用强密码，并定期轮换。一个用户可以拥有多个密码，便于无缝切换：

ACL SETUSER rotating_user on >oldpass >newpass ~* +@read

连接限制方面，nopass 标记允许无密码登录，仅适用于内网安全环境或监控探针。maxconnections 可限制单个用户的最大并发连接数，防止某个服务异常占用过多资源：

ACL SETUSER limited_user on >mypass ~* +@all maxconnections 10

此外，Redis 7.0 增强了 ACL 的日志记录功能。通过 ACL LOG 命令可以查看被拒绝的命令尝试，包含时间戳、用户、客户端 IP 和具体命令。这为安全审计和故障排查提供了关键线索。日志条数可通过 acllog-max-len 参数调整，默认 128 条。

场景一：微服务共享实例。多个服务共用 Redis 时，为每个服务创建独立用户，按前缀隔离键空间。用户服务使用 user_svc 用户，仅访问 user:* 键；订单服务使用 order_svc 用户，仅访问 order:* 键。这样即使订单服务出现代码缺陷，也无法误删用户数据。同时禁止所有服务使用 FLUSHALL 等危险命令。

场景二：读写分离与只读副本。在读写分离架构中，为只读副本创建专用用户，仅授予 @read 类别命令。应用程序在读取操作时使用该用户连接副本，写入操作使用主库用户。这从应用层强制了读写分离，避免误写副本导致数据不一致。

场景三：开发与运维权限分离。开发人员使用 dev 用户，仅能访问开发环境键空间，且禁止执行 CONFIG、DEBUG、SHUTDOWN 等管理命令。运维人员使用 admin 用户，拥有完整权限但受限于内网 IP 白名单。通过 ACL 结合 bind 和 protected-mode 配置，构建多层防护。

场景四：临时只读访问。数据分析团队需要导出数据时，创建一个有效期短暂的只读用户，授予 ~* +@read 权限，任务完成后立即通过 ACL DELUSER 删除。配合 maxconnections 限制并发查询数，避免影响线上服务。

最佳实践中，务必关闭 default 用户或为其设置强密码并限制权限。定期使用 ACL LIST 审查现有用户配置，移除不再使用的账号。利用 ACL GENPASS 生成随机强密码，避免人工设定弱密码。将 ACL 配置纳入版本控制，通过自动化脚本在部署时同步更新。

在 Sentinel 哨兵模式下，每个 Redis 节点都需要配置相同的 ACL 规则，否则故障转移后客户端可能因权限不足而无法连接。建议将 ACL 规则写入配置文件并通过配置管理工具分发，或使用 ACL SAVE 生成的独立 aclfile 统一部署。Sentinel 本身也需要认证，需在 sentinel.conf 中配置 sentinel auth-pass 和 sentinel auth-user。

Cluster 集群模式下，ACL 规则同样需要在所有节点同步。由于集群节点间通过 Gossip 协议通信，内部连接也需要认证。设置 requirepass 和 masterauth 仅影响 default 用户，如果关闭了 default 用户，必须为集群通信创建专用用户并配置在 cluster-auth-user 参数中。迁移槽位时，源节点和目标节点都需要有相应键空间的访问权限，否则 MIGRATE 命令会失败。

一个常见的陷阱是，集群模式下键的哈希槽分布与 ACL 键模式无关。即使某个用户只能访问 order:* 键，如果 order:* 的槽位分布在多个节点上，该用户依然可以连接任意节点，只是命令执行时会被 ACL 拦截。因此 ACL 不能替代集群的访问隔离，两者需配合使用。

ACL 检查在命令执行前进行，Redis 采用内存中的用户规则集进行快速匹配。对于大多数场景，ACL 带来的性能开销可忽略不计，通常在微秒级别。但过于复杂的键模式（如大量通配符或正则）可能增加匹配耗时，建议使用简单前缀模式，避免过度嵌套的通配符。可通过 Redis 的 SLOWLOG 监控是否存在因 ACL 检查导致的延迟。

监控方面，INFO 命令输出的 acl 相关指标较少，但可通过 ACL LOG 分析拒绝记录，结合客户端连接数指标观察各用户连接情况。使用 CLIENT LIST 可查看每个连接的认证用户，便于排查连接泄漏问题。对于大规模部署，建议将 ACL LOG 内容采集到集中日志系统，设置告警规则，当拒绝次数突增时及时响应。

Redis 7.2 进一步引入了 ACL 的 dry-run 模式，允许在不实际执行命令的情况下测试权限：

ACL DRYRUN app_readonly SET app:key value

该命令返回是否允许执行，非常适合在权限变更前进行验证，避免因配置错误导致服务中断。

ACL 的引入标志着 Redis 在安全治理上迈出了关键一步。它不仅解决了多租户共享实例的权限隔离问题，还为合规审计提供了基础能力。在实际落地中，建议从梳理现有连接方式开始，逐步将各客户端迁移到命名用户，最终关闭 default 用户。整个过程可以渐进式推进，先创建新用户并验证权限，再切换应用配置，最后禁用旧认证方式。配合外部密钥管理服务轮换密码，Redis 的安全水位将得到质的提升。对于任何将 Redis 作为核心基础设施的团队而言，掌握 ACL 的精细配置已不再是可选项，而是生产环境稳定运行的必要保障。