RDB/AOF文件最小必要权限为仅Redis用户可读写，需设dir目录权限700、属主redis，并禁用CONFIG/FLUSHALL/SLAVEOF等高危命令，备份须加密传输与落盘，严防AOF重写临时文件泄露。
如何设置RDB/AOF文件的最小必要文件权限
RDB和AOF文件本身是明文可读的（尤其是AOF，本质是Redis命令日志），一旦被非授权用户拿到，敏感业务数据（如用户token、订单ID、手机号哈希）可能直接泄露。不能只靠“藏路径”，必须从操作系统层设限。
-
默认风险：Redis启动用户（如
redis）创建的dump.rdb或appendonly.aof，常被赋予-rw-r--r--（644），同组/其他用户可读 -
正确做法：在
redis.conf中显式指定持久化文件属主与权限：dir /var/lib/redis→ 确保该目录仅redis用户可进入（chmod 700 /var/lib/redis）dbfilename dump.rdb→ 文件由Redis进程创建，默认继承目录权限，但需额外加固appendfilename appendonly.aof→ 同理 -
关键加固步骤：
启动前执行：chown redis:redis /var/lib/redis且chmod 700 /var/lib/redis
确保Redis以非root用户运行（如redis），避免进程提权后绕过权限 -
验证方式：用非
redis用户执行ls -l /var/lib/redis/，应看不到任何文件内容，且返回Permission denied
为什么bind + firewall还不够，必须禁用公网持久化路径
即使绑定了127.0.0.1并配了iptables，若RDB/AOF路径设在/tmp、/var/www等Web可读目录，攻击者通过任意文件读取漏洞（如Nginx路径穿越、PHP LFI）仍能直接下载快照——这是真实攻防中高频利用链。
-
典型错误配置：
dir /tmp或dir /var/www/html/redis-backup，看似“方便备份”，实则裸奔 -
安全路径原则：
必须为Redis专属目录（如/var/lib/redis）
该路径不能被Web Server、FTP、Samba等任何其他服务映射或访问
禁止使用/home、/tmp、/var/log等共享性高或权限松散的系统目录 -
云环境特别注意：ECS实例若挂载了共享NAS或对象存储挂载点（如
/mnt/oss），绝不可将dir指向其下——NAS权限模型与本地FS不同，容易失效
rename-command对FLUSHALL无效？持久化文件仍可能被清空
很多人以为重命名FLUSHALL就万事大吉，但只要攻击者拿到Redis连接权限，仍可通过CONFIG SET dir和CONFIG SET dbfilename把恶意payload写入任意路径，再用SLAVEOF或MODULE LOAD触发执行——而这些命令不在传统“高危命令”名单里。
-
真正有效的防护组合：
rename-command FLUSHALL ""+rename-command CONFIG ""+rename-command SLAVEOF ""
尤其CONFIG必须禁用，否则CONFIG SET dir /etc/cron.d/配合CONFIG SET dbfilename redis.sh可直接写定时任务 -
ACL替代方案（Redis 6.0+）：
创建专用账号：ACL SETUSER cacheuser on >mypass ~cache:* &all -CONFIG -FLUSHALL -SLAVEOF
比配置文件重命名更可控，且支持动态生效 -
注意陷阱：重命名后客户端代码若硬编码调用
FLUSHALL会报错；ACL方式需确保所有业务连接都切换到新账号，否则仍走default用户（默认全权限）
备份文件传输过程中的加密盲区
本地RDB权限设得再严，一旦备份到对象存储（OSS/S3）、NAS或另一台机器，传输和落盘环节就可能暴露——比如rsync未加--compress或scp走默认SSH通道虽加密，但目标端存储未加密，等于“锁了门却把钥匙留在门口”。
-
传输阶段：
禁用ftp、http、netcat等明文协议传RDB
用rsync -e "ssh -o StrictHostKeyChecking=no"或gpg --encrypt --recipient先加密再传 -
落盘阶段：
对象存储开启服务端加密（SSE-KMS或SSE-S3）
本地备份目录启用LUKS或fscrypt（Linux）加密文件系统
避免“备份即解密”：不要在脚本里用gpg --decrypt自动还原，应人工介入校验 -
时间窗口风险：备份脚本若先
cp dump.rdb /backup/再gpg，中间几秒的明文文件可能被ls -la /backup/扫出——应直接gpg --encrypt ... < /var/lib/redis/dump.rdb > /backup/dump.rdb.gpg
最易被忽略的一点：AOF重写（BGREWRITEAOF）期间生成的临时文件appendonly.aof.tmp，权限常为644且位于同一目录，攻击者可在重写完成前抢读——必须确保dir目录权限严格，且监控appendonly.aof.tmp生命周期。
