小方有点小方做等保三级测评，Redis几乎是必查项。我现场测过的Redis实例不下几十个，印象最深的倒不是那些配置全裸的，而是那种“客户觉得我已经加固了，实际上还在裸奔”的。比如有一次客户自信满满说Redis已经设过密码了，结果我redis-cli连上去敲一条INFO，版本、运行时间、内存使用全裸露，后来一查，密码只写在业务配置文件里，进程根本没让配置生效。这种例子太多。这篇就把等保三级视角下Redis安全测评的核查思路和落地方法一次性讲清楚，适合测评工程师、安全运维和应用负责人一起看。
1. 为什么三级测评里Redis总是被揪出来扣分？
1.1 默认配置和等保基线之间差了不止一个密码
很多管理员觉得Redis安全就是“设一个密码”，这其实是把等保测评想简单了。Redis刚装完的默认状态，bind默认回环、protected-mode默认yes，看似安全；但实际生产部署中，为了给内网其他服务访问，很多人会把bind改成0.0.0.0，或者干脆不写bind，只靠protected-mode兜底。等保三级看的是控制措施有没有落实，默认配置那个保护级别放在公网或大内网里，等于没有。
更麻烦的是口令和审计。默认情况下requirepass是空的，任意用户连接后都能执行FLUSHALL、KEYS、CONFIG这些高危命令；日志默认输出到标准输出，进程重启后日志就丢了。这些在三级要求里分别对应身份鉴别、访问控制、安全审计、入侵防范多个控制点，每一项都能开出一条整改项。所以不是Redis本身容易被扣分，而是“默认配置+生产改动”这两个因素叠加，几乎必然踩线。
1.2 Redis经常不在资产台账里，测评范围先漏一半
我习惯在正式开始测评前先做一轮端口摸查。因为Redis常常不是基础架构团队装的企业级组件，而是应用研发在发布业务时顺手装在内网服务器上的，甚至跑在Docker容器里，没进CMDB。如果只按备案主机清单去查，很可能漏掉好几个实例。查法很简单：
bash复制ss -lntp | grep 6379
ps -ef | grep redis-server
然后顺着进程路径找配置和数据目录。遇到过一台应用服务器上同时跑着两个Redis实例共用一套密码的情况，也遇到过Redis装在/tmp目录下的临时包里。这些一定要在测评范围里写清楚，不然报告