Redis安全需网络层（bind+防火墙）、认证层（ACL/requirepass）、命令层（rename-command+禁用高危命令）三重加固，缺一不可。
直接上结论：不设密码、不限IP、不禁危险命令，FLUSHALL 就是悬在头上的刀——攻击者连上就能清库，清完立刻引发缓存雪崩。安全基线不是“加个密码就完事”，而是网络层、认证层、命令层三道关卡必须同时卡死。
bind 127.0.0.1 和防火墙规则谁先生效？
两者不是二选一，而是叠加生效。Redis 的 bind 是服务端监听控制，防火墙是系统级流量过滤，缺一不可。
-
bind 127.0.0.1只让 Redis 监听本地回环地址，但若配置写成bind 0.0.0.0或漏掉该行，Redis 仍会监听所有网卡 - 即使绑定了
127.0.0.1，如果服务器开了公网 SSH，攻击者仍可能通过跳板机或内网横向移动连上 Redis - 生产环境必须配防火墙规则：
iptables -A INPUT -p tcp --dport 6379 -s 10.0.1.0/24 -j ACCEPT（只允许可信内网段），再加一条-j DROP拒绝其余所有 - 云环境别只信安全组——有些厂商默认放通全部端口，得手动收紧，且注意安全组规则顺序和优先级
requirepass 和 ACL 的权限粒度差异
Redis 6.0+ 推荐用 ACL 替代单一 requirepass，因为后者一旦泄露，等于交出全部钥匙；而 ACL 能按角色切分权限。
-
requirepass是全局密码，所有客户端用同一凭据，无法区分“只读监控”和“运维清缓存”场景 -
ACL SETUSER可创建最小权限用户，例如：ACL SETUSER cache_reader on >password123 ~cache:* +get +info，禁止执行DEL、FLUSHDB - 禁用
CONFIG命令必须用rename-command CONFIG ""，不能只靠 ACL——因为 ACL 不限制未登录用户的CONFIG GET尝试（部分旧版本存在绕过） - ACL 用户密码建议用
sha256哈希存储（ACL SETUSER u1 >$6a8...），避免明文出现在配置文件中
为什么 rename-command FLUSHALL "" 仍可能被绕过？
重命名只是障眼法，真正起作用的是配合 ACL 或彻底禁用。单独重命名在某些场景下形同虚设。
- 攻击者可通过
CLIENT LIST查看连接命令历史，猜出重命名后的字符串（比如rename-command FLUSHALL flush_all_now） - 若 Redis 版本 rename-command FLUSHALL "" +
rename-command FLUSHDB ""+rename-command KEYS "" - 更稳妥做法是：在
redis.conf中同时设置rename-command FLUSHALL ""和ACL规则，双重拦截 - 注意：重命名后，你自己运维脚本里所有
FLUSHALL调用也得同步改掉，否则自动化任务会失败
清缓存操作如何避免触发雪崩？
安全基线不仅要防攻击者清库，也要防自己人误操作。生产环境严禁直接跑 FLUSHALL 或 FLUSHDB。
- 批量清理必须走
SCAN+UNLINK组合：先SCAN 0 MATCH cache:* COUNT 1000分批获取键，再对每批用UNLINK（异步删除，不阻塞主线程） - 业务层写缓存时强制加随机 TTL 偏移，例如基础过期时间 3600 秒，再加
new Random().nextInt(1800)，避免整点集体失效 - 上线前检查是否有脚本或定时任务含
redis-cli -a xxx FLUSHALL—— 这类命令应替换为带确认逻辑的 wrapper 脚本 - 监控项必须包含：
redis_commandstat_flushall和redis_commandstat_flushdb的调用次数突增告警
最容易被忽略的一点：安全基线不是一次性配置动作，而是每次部署新实例、升级 Redis 版本、变更网络拓扑时都得重新校验。尤其注意 Redis Cluster 环境下，每个节点的 redis.conf 必须保持一致，否则某个节点漏配 bind 或 requirepass，整个集群就等于裸奔。
