redis安全需协同配置bind与protected-mode，优先保持protected-mode yes；密码须16位以上并禁用-a明文传参；config等高危命令应禁用而非重命名；key命名禁用敏感字段，改用hash结构；redis进程须降权运行且dir指向受限路径。
redis.conf 中 bind 和 protected-mode 必须协同配置
单独改 bind 127.0.0.1 不等于安全，尤其在 Redis 3.2+ 版本中：protected-mode yes 才是兜底机制。如果只改了 bind 却把 protected-mode 设为 no，而 requirepass 又为空，Redis 仍会允许非本地 IP 连接（只要网络层没拦住）。
实操建议：
- 优先保留
protected-mode yes（默认值），不要手动关掉； - 若必须监听外网 IP（如内网跨主机通信），则
bind必须显式列出可信网段，例如bind 192.168.10.0 10.0.1.0，不能写0.0.0.0； - 修改后务必执行
redis-cli config rewrite或重启服务，仅改文件不生效； - 验证方式：从另一台机器执行
redis-cli -h $IP ping，应返回NOAUTH或连接被拒绝，而非直接响应PONG。
requirepass 密码强度与客户端使用方式
设了 requirepass 但用 redis-cli -a 明文传参，密码会留在 shell 历史和进程列表里，等于白设。更危险的是，很多脚本直接拼接 -a $PASSWD，一旦环境变量泄露就全暴露。
实操建议：
- 密码至少 16 位，含大小写字母、数字、符号，避免字典词或日期类组合；
- 客户端连接时，优先用
AUTH命令交互式认证，而不是-a参数； - 生产环境禁用
redis-cli直连，统一走带认证的中间件或代理（如 redis-exporter + basic auth）； - 检查所有调用 Redis 的应用代码，确认未硬编码密码，且连接池初始化时使用
password字段而非 URL 查询参数（如redis://:pwd@host:6379/0）。
高危命令 rename-command 不是万能补丁
很多人以为把 CONFIG、FLUSHALL、EVAL 重命名就能防穿透，但攻击者只要知道新名字（比如 rename-command CONFIG GETCONF），照样能用。而且部分 SDK 或监控工具依赖这些命令，重命名后可能引发功能异常。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 真正要禁用的只有
CONFIG（可写磁盘路径）、MODULE（可加载恶意模块）、DEBUG（可触发内存操作）； -
FLUSHALL和KEYS建议保留，但通过运维流程控制权限，而非靠重命名糊弄； - 重命名后必须测试所有业务链路，尤其是备份脚本、慢日志导出、集群拓扑发现等依赖
CONFIG GET的环节； - 比重命名更有效的是：确保
dir配置指向非系统关键路径（如/var/lib/redis而非/root），并限制该目录的写权限。
Key 命名不规范会放大未授权访问后果
即使开了密码，如果 Key 名包含敏感语义（如 user:123:token、payment:order:xxx:secret），攻击者爆破或扫描 KEYS user:* 后仍能批量提取凭证。这不是 Redis 漏洞，而是业务层 Key 设计缺陷。
实操建议：
- 禁止在 Key 名中嵌入用户 ID、手机号、邮箱、订单号等可枚举字段；
- 敏感数据不存 Key 名，改用 Hash 结构，把 token 存在
HGET user:abc session_token这类二级字段里； - 所有 Key 必须加统一前缀（如
prod:cache:），并在 Redis ACL 中限制通配符权限（Redis 6+ 支持~prod:cache:*）； - 定期用
redis-cli --scan --pattern "user:*" | head -20抽样检查，发现明文敏感字段立即下线并轮换 Key。
最关键的其实是权限收敛：哪怕配置全对，只要 Redis 进程以 root 身份运行，且 dir 指向 /root/.ssh，攻击者拿到 AUTH 后仍能写公钥。所以 user 字段改普通用户、dir 改受限路径、chown 目录权限，这三步缺一不可。
