Redis默认情况下没有开启密码认证，服务器启动后监听在6379端口。如果监听地址被设置成0.0.0.0，并且所在主机有公网IP或处于不隔离的内网，攻击者可以用一个简单的扫描脚本在极短时间内完成未授权访问检测。未授权访问Redis的后果不只是数据泄露，攻击者常利用CONFIG SET修改持久化路径、写入SSH公钥、创建cron任务，甚至直接执行FLUSHALL清空数据。密码认证作为第一道屏障，确实能挡住一部分自动化扫描，但它的配置方式、密码强度、命令权限以及网络暴露面共同决定了最终防护效果。下面从基础密码认证开始，逐步拆解生产环境应该怎么做。
一、requirepass：最基础的密码认证
requirepass参数是Redis最直接的认证开关，配置在redis.conf中，默认是注释状态。设置后客户端执行任何命令前都需要先通过AUTH命令验证，否则会返回NOAUTH Authentication required。这个参数适合作为第一层防线，但前提是密码本身不能太弱，否则形同虚设。
最简单的配置方式是在redis.conf中写入：
# 监听地址只允许本机 bind 127.0.0.1 # 开启保护模式 protected-mode yes # 设置访问密码 requirepass YourStrongPassword123!
也可以运行时动态设置：CONFIG SET requirepass "YourStrongPassword123!"。但要注意动态设置只对当前进程有效，Redis重启后会失效，需要执行CONFIG REWRITE或者手动修改配置文件。验证连接可以使用redis-cli -a YourStrongPassword123! ping，如果返回PONG说明认证成功。Redis配置文件可能存放在不同路径，Linux下常见为/etc/redis/redis.conf，Windows环境下通常位于C:\Program Files\Redis\redis.windows.conf。
requirepass有两个明显短板：一是所有客户端共用一个密码，无法区分不同应用的权限；二是密码以明文形式保存在配置文件中。如果配置文件被其他用户读取，密码就会泄露。Redis 6之前的版本只有这一种密码机制，因此很多老旧环境只能通过配合网络限制和命令重命名来增强安全。
二、ACL：把单一密码升级为账号权限
Redis 6版本开始内置ACL（Access Control List），允许创建多个用户，每个用户拥有独立密码、命令权限和键访问模式。相比requirepass，ACL解决了两个问题：不同应用可以不再共用同一个密码，某个客户端只能执行被允许的命令。即使Redis 5或更早版本没有完整ACL，也可以通过rename-command做部分弥补，但控制粒度远不如ACL。
下面通过redis-cli创建两个用户：一个只读用户只能操作cache:开头的键，另一个管理员用户可以执行所有命令。
# 查看当前ACL用户 redis-cli ACL LIST # 创建一个只读用户，密码为read_pass，只能访问cache:开头的key redis-cli ACL SETUSER app_readonly on >read_pass ~cache:* +get +mget +ttl +exists # 创建一个管理员用户，允许所有命令和所有key redis-cli ACL SETUSER db_admin on >admin_pass ~* +@all # 禁用默认用户，避免使用无密码的default redis-cli ACL SETUSER default off
ACL规则中，+@all表示允许所有命令，~*表示允许访问所有键，>password用来设置密码。ACL可以存储在redis.conf的user指令中，也可以使用独立的ACL文件，通过aclfile参数加载。推荐使用ACL文件，修改后通过ACL LOAD热加载，不必重启Redis。主从复制和哨兵模式中，也需要为复制用户设置ACL，主节点可以通过masteruser和masterauth完成验证，旧版本则使用masterauth配合requirepass。
ACL虽然强大，但配置错误也可能把自己锁在门外。例如直接禁用default用户又没有创建管理员用户，会导致所有连接被拒绝。因此生产环境调整ACL时，建议先保留一个可用的管理员用户，并在测试环境验证完整权限后再应用到线上。
三、网络层防护与高危命令重命名
密码认证不能替代网络隔离。Redis默认的bind 127.0.0.1只允许本机访问，但很多部署为了跨主机访问会改成0.0.0.0。如果Redis暴露在公网或不可信网络，仅靠密码很容易被暴力破解。最佳实践是通过防火墙或云安全组限制来源IP，只允许应用服务器访问6379端口。同时保持protected-mode yes，在未设置密码且绑定非回环地址时，Redis会拒绝外部连接。
高危命令也需要一并处理。CONFIG、FLUSHALL、FLUSHDB、EVAL等命令一旦被攻击者利用，可能导致配置被篡改、数据被清空或恶意脚本执行。可以通过rename-command将这些命令禁用或改为只有内部人员知道的名称。
# 只监听内网地址 bind 192.168.1.10 # 开启保护模式 protected-mode yes # 重命名高危命令，禁用CONFIG rename-command CONFIG "" # 禁用FLUSHALL和FLUSHDB rename-command FLUSHALL "" rename-command FLUSHDB "" # 重命名EVAL为随机字符串，避免脚本执行 rename-command EVAL "eval_x9k2"
重命名命令时要注意，如果主从复制、哨兵或监控工具依赖这些命令，需要同步调整。禁用CONFIG后，运行时修改配置将不可用；而FLUSHALL被禁用后，某些运维脚本可能会报错，因此需要提前评估影响。更高安全要求的环境可以启用TLS。Redis 6以上支持原生TLS，需要配置tls-port、tls-cert-file、tls-key-file等参数。如果使用旧版本，可以在客户端和Redis之间架设stunnel或Spiped加密隧道，避免密码在网络上被明文截获。
四、完整配置模板与常见误区
下面给出一个面向内网应用服务器的安全配置模板，覆盖监听地址、密码、ACL、命令重命名和持久化。该模板假设Redis仅被内网中的业务系统访问。
# 网络 bind 192.168.1.10 protected-mode yes port 6379 timeout 300 # 基础认证 requirepass YourStrongPassword123! # ACL文件 aclfile /etc/redis/users.acl # 重命名高危命令 rename-command CONFIG "" rename-command FLUSHALL "" rename-command FLUSHDB "" # 持久化 save 900 1 save 300 10 save 60 10000 dir /data/redis
对应的ACL文件示例：
user default off user app_readonly on >read_pass ~cache:* +get +mget +ttl +exists user db_admin on >admin_pass ~* +@all
实际使用中常见误区包括：只设置requirepass却把bind改成0.0.0.0；所有业务共用一个root密码，导致权限无法区分；密码写在代码仓库或配置文件里未做权限控制；动态执行CONFIG SET后忘记持久化，重启后认证失效；禁用了CONFIG、FLUSHALL等高危命令却未测试主从同步和备份流程；认为内网绝对安全而忽略同网段其他被攻陷主机。安全配置不是一次性动作，需要结合日志审计、异常连接告警和定期密码轮换。
Redis密码认证安全配置应分层推进：先确保bind和protected-mode缩小暴露面，再用强密码或ACL实现身份验证和权限分离，最后通过命令重命名、TLS和网络访问控制降低被利用的风险。每一层都可以独立提升安全性，但只有组合使用才能把未授权访问和横向移动的路径有效切断。