Redis ACL用户权限细分与命令黑名单

Redis从6.0版本开始正式引入了ACL（Access Control List）功能，这彻底改变了以往仅靠密码鉴权的单一安全模式。很多团队在启用ACL后，仍然停留在创建用户、设置密码的初级阶段，完全没有发挥出命令黑名单和权限细分的真正威力。直接的问题是：当多个业务共用一个Redis实例时，一个业务误执行"FLUSHALL"可能导致全站缓存雪崩；一个开发者在调试时执行"KEYS *"可能直接拖垮生产服务器。ACL的精髓不在于你能创建多少用户，而在于你能把每个用户的操作边界限制得多死。

配置ACL权限时，核心思维要从“允许什么”转向“禁止什么”。Redis ACL同时支持白名单模式和黑名单模式，但实际生产环境中，两者必须组合使用才能达到安全效果。白名单通过"+"前缀添加允许的命令，黑名单通过"-"前缀禁止特定命令。一个典型的危险操作是只配置了白名单却忽略了子命令的权限扩散。比如你允许了"CONFIG"命令，用户就能执行"CONFIG SET"修改运行时配置，这相当于把服务器root权限交了出去。

Redis命令权限的粒度可以精确到子命令层面。以"ACL SETUSER"命令为例，你可以这样配置一个只读用户，同时明确禁止其执行任何管理类命令：

ACL SETUSER readonly_user on >secure_password123 ~* +@read -@admin -@dangerous -CONFIG -SHUTDOWN -SLAVEOF -REPLICAOF -DEBUG -FLUSHALL -FLUSHDB -KEYS -SCAN

上面这条规则中，"+@read"允许所有读命令，"-@admin"和"-@dangerous"禁止了管理类和危险命令组，最后又单独列出了一批高危命令进行二次封禁。这种层层递进的禁止策略，比单纯的白名单要安全得多。值得注意的是，"-SCAN"被单独列出是因为"SCAN"虽然属于读操作，但在大键值场景下同样会阻塞Redis，生产环境中对普通业务用户应当禁用。

命令黑名单的价值在于它能解决白名单无法覆盖的边界情况。假设你有一个专门做缓存预热的后台服务，它需要写入权限但不能执行删除操作，更不能修改键的过期时间。这种需求下，纯白名单配置会非常繁琐，而黑名单可以精准打击：

ACL SETUSER cache_warmer on >warmer_pass ~cache:* +@write -@keyspace -DEL -UNLINK -EXPIRE -EXPIREAT -PEXPIRE -PEXPIREAT -PERSIST -RENAME -RENAMENX -MOVE -MIGRATE -RESTORE -SORT -FLUSHALL -FLUSHDB

这条规则的精妙之处在于：首先用"~cache:*"限制了键的前缀访问范围，然后通过"+@write"开放写入权限，最后用黑名单把删除类、过期类、重命名类命令全部封死。"-@keyspace"这个命令组禁止了所有与键空间管理相关的操作，包括"DEL"、"EXISTS"等，但为了更精确控制，又把"EXISTS"这类无害命令通过后续的规则放行（如果需要的话）。这种配置方式让缓存预热服务只能执行SET、HSET等纯写入操作，无法对已有数据造成任何破坏性影响。

在一个中型以上的Redis集群中，至少应该划分出四类用户角色：全局管理员、应用读写用户、只读查询用户、监控采集用户。每种角色的命令权限矩阵需要严格定义。全局管理员拥有所有权限，但建议仍然禁止"DEBUG"和"MODULE"相关命令，因为这些命令可能导致不可预期的行为。应用读写用户的核心诉求是CRUD操作，必须禁止所有管理类命令、脚本执行命令和发布订阅命令（除非业务需要）。

监控采集用户是一个容易被忽视的角色。很多团队直接给监控系统配置管理员权限，这是极其危险的做法。监控系统只需要执行"INFO"、"PING"、"SLOWLOG GET"、"CLIENT LIST"等命令，完全不需要任何写入或管理权限。一个标准的监控用户配置如下：

ACL SETUSER monitor on >monitor_strong_pass ~* +@connection +INFO +SLOWLOG +LATENCY +MEMORY -@admin -@dangerous -@write -@keyspace -@scripting -CONFIG -SHUTDOWN

这里"+@connection"允许连接相关命令如"PING"、"ECHO"、"CLIENT"系列，"+INFO"、"+SLOWLOG"、"+LATENCY"、"+MEMORY"分别开放监控所需的核心诊断命令，其余所有可能修改数据或影响性能的命令全部通过黑名单禁止。这种配置下即使监控系统的凭证泄露，攻击者也无法对Redis数据造成任何损害。

配置完权限后，真正的安全工作才刚刚开始。Redis提供了"ACL LOG"命令来记录被拒绝的操作，这个功能必须开启且要定期审查。默认情况下，ACL日志最多存储128条记录，可以通过"acllog-max-len"参数调整。生产环境中建议将这个值设置到1024以上，并编写脚本定期采集日志内容发送到集中式日志平台。

查看ACL日志的方式很简单：

ACL LOG 50

这会返回最近50条被拒绝的操作记录，每条记录包含被拒绝的用户名、客户端IP、执行的命令、拒绝原因和时间戳。通过分析这些日志，你能发现两种关键信息：一是业务代码中是否存在越权调用，比如某个应该只读的服务尝试执行写操作；二是是否存在外部攻击行为，比如某个IP频繁尝试执行"CONFIG"或"SHUTDOWN"命令。这些信息反过来又能指导你进一步收紧ACL规则，形成安全策略的持续优化闭环。

很多人配置ACL时直接在redis-cli中执行"ACL SETUSER"，重启Redis后发现所有规则丢失，这是生产事故的常见诱因。ACL规则有两种持久化方式：写入redis.conf配置文件，或者使用独立的aclfile文件。推荐使用独立的aclfile，因为它的语法更清晰，且支持"ACL LOAD"和"ACL SAVE"命令进行热加载和热保存，无需重启Redis。

在redis.conf中启用aclfile的配置如下：

aclfile /etc/redis/users.acl

users.acl文件的内容格式非常直观，每行一个用户定义：

user default off
user admin on >admin_ultra_secret ~* +@all -DEBUG -MODULE
user app_service on >app_password ~app:* +@all -@admin -@dangerous -CONFIG -SHUTDOWN -SLAVEOF -REPLICAOF -DEBUG -FLUSHALL -FLUSHDB -KEYS -SCAN -SCRIPT -EVAL -EVALSHA -MULTI -EXEC -DISCARD -WATCH -UNWATCH
user readonly on >readonly_pass ~* +@read -@admin -@dangerous -CONFIG -SHUTDOWN -KEYS -SCAN
user monitor on >monitor_pass ~* +@connection +INFO +SLOWLOG +LATENCY +MEMORY +PING -@admin -@dangerous -@write -@keyspace -@scripting

特别注意第一行的"user default off"，这行禁用了默认用户。Redis在未配置ACL时，所有连接都使用default用户，它拥有全部权限。如果不显式禁用default用户，那么任何没有认证的连接仍然可以执行任意命令，你的ACL配置就形同虚设。修改aclfile后，执行"ACL LOAD"即可让新规则立即生效，无需中断服务。

在实际业务中，有些需求看似简单，实则对权限控制要求极高。比如一个需要执行Lua脚本的业务，你既不能完全开放"EVAL"和"EVALSHA"命令（因为恶意脚本可以执行任意Redis命令），又不能完全禁止脚本功能。这时需要结合Redis 7.0引入的ACL对脚本内容的控制能力，或者通过命令重命名机制配合ACL来实现间接限制。

另一个高频场景是多租户环境下的键空间隔离。ACL中的"~"前缀可以限制用户可访问的键模式，但这个功能需要和命令权限配合使用。比如你允许了"SORT"命令，即使用户的键模式被限制在"tenant_a:*"，"SORT"命令仍然可能通过"BY"和"GET"子句读取到其他租户的键。这种情况下，黑名单必须包含"SORT"命令，或者通过"ACL"的"%"权限修饰符来控制命令对键的访问模式。

对于Redis集群模式，ACL的配置需要在每个节点上保持一致。建议通过配置管理工具（如Ansible、SaltStack）统一分发aclfile，并在文件变更后通过自动化脚本执行"ACL LOAD"。集群环境下的ACL还有一个特殊点："CLUSTER"系列命令的权限需要谨慎分配。普通业务用户应当完全禁止"CLUSTER"命令，只有运维管理用户才能执行集群管理操作。

启用ACL对Redis的性能影响微乎其微，因为权限检查发生在命令解析阶段，属于纯内存操作，延迟增加通常在微秒级别。但有一个容易被忽视的性能陷阱：如果ACL规则中使用了大量复杂的键模式匹配（例如多层通配符），在高并发场景下可能略微增加CPU开销。建议键模式尽量使用简单的前缀匹配，避免使用"*"出现在模式中间位置的正则表达式。

最后梳理一条核心原则：永远以最小权限原则配置ACL，先默认全部禁止，再按需开放。每开放一个命令，都要问自己“这个命令可能被滥用吗”。对于无法确定是否安全的命令，先加入黑名单观察业务运行情况，通过ACL日志确认无影响后再考虑放行。Redis ACL不是一次性配置完就束之高阁的静态规则，它需要随着业务演进持续迭代，与代码审查、安全扫描、监控告警形成完整的安全防护体系。