redis 6.0集群中仅靠acl无法真正禁用keys或flushall，必须配合redis.conf中rename-command flushall ""和rename-command keys ""配置，且所有节点需统一生效，否则存在绕过风险。
Redis 6.0 集群中仅靠 ACL 无法真正禁用 KEYS 或 FLUSHALL —— 必须配合 rename-command 配置，否则 ACL 规则会被绕过。
ACL 的 -@dangerous 组不拦截 KEYS 和 FLUSHALL？
很多人以为给用户配置 acl setuser myapp -@dangerous 就万事大吉，结果发现 FLUSHALL 还能执行。问题出在：Redis 的 rename-command 机制优先级高于 ACL，但反过来，ACL 并不自动屏蔽被归类为 “危险” 的命令——@dangerous 组里压根不包含 KEYS（它属于 @read），而 FLUSHALL 在部分版本中默认也不在 @dangerous 列表里。
验证方式：redis-cli ACL CAT dangerous 查看实际包含的命令；你会发现 FLUSHALL 常缺席，KEYS 从来不在其中。
-
KEYS属于@read，删它等于禁掉所有读操作，不现实 -
FLUSHALL在 Redis 6.0–7.0 多数发行版中未被默认划入@dangerous，需手动排除 - ACL 对未显式授权的命令默认拒绝，但前提是该命令名“存在”——如果
rename-command FLUSHALL ""已生效，ACL 根本收不到这个命令
rename-command 必须写在 redis.conf 的 SECURITY 区域之后
顺序错了就白配。Redis 按配置文件从上到下加载，同名 rename-command 后出现的会覆盖前面的。常见翻车点：
- 用了
include /etc/redis/conf.d/*.conf，但主 conf 里没写rename-command，而子 conf 里写了两次，后一次把前一次覆盖了 - 配置写在
# SECURITY注释之前，被后面 SECURITY 区域里的默认配置顶掉 - Docker 启动时挂载了旧配置，或用
redis-server /tmp/custom.conf手动启动却忘了更新路径
确认是否生效最靠谱的方式：redis-cli CONFIG GET rename-command，返回结果里必须看到 "flushall" "" 这样的键值对；如果为空或没这项，说明配置根本没加载。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
集群环境下所有节点（含 Proxy、Sentinel、Cluster 分片）必须统一配置
Redis Cluster 不会同步 rename-command 配置，每个 shard、每个 Sentinel、每个 Proxy（如 Codis 或 Twemproxy）都得单独改。漏掉一个节点，就等于留了一扇没锁的门。
- 主从复制正常，但某从节点没配
rename-command FLUSHALL ""→ 运维连过去一执行就清空整从库，接着全量同步污染主库 - Proxy 层没禁
KEYS，客户端走 Proxy 发KEYS *，Proxy 转发给后端任意分片 → 卡死那个分片，整个集群响应变慢 - 哨兵节点若允许
CONFIG SET，攻击者可动态开启 AOF 或改dir，再配合未禁用的DEBUG直接崩溃进程
别信“我只在主节点配了就行”。集群不是单机，是多个独立 Redis 实例组成的协作体，每个实例的命令白名单都得自己管。
禁用后仍要防替代路径：SCAN + 客户端聚合 = 新式 KEYS*
KEYS 禁了，不代表风险消失。SCAN 是合法命令，但客户端若循环调用 SCAN cursor MATCH * COUNT 10000 并本地合并结果，效果和 KEYS * 几乎一样——只是延迟更高、更难监控。
这类行为 ACL 拦不住，rename-command 也拦不了，只能靠外部手段：
- 用
redis-cli --scan --pattern "*"测试时，观察 slowlog 是否有大量scan记录 - 在 proxy 层（如 RedisInsight、自研网关）限制单连接单位时间内的
SCAN调用频次 - 对业务账号强制要求使用带业务前缀的 key（如
order:123），避免通配符滥用
真正难防的不是命令本身，而是人用合法命令干非法的事。配置只是第一道门，后面还得有监控、审计、连接打标和超时熔断。
