小方有点小方做等保三级测评，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目录下的临时包里。这些一定要在测评范围里写清楚，不然报告结论就只能覆盖“已登记资产”，实际风险还是悬空。
1.3 等保三级安全计算环境里，和Redis直接挂钩的控制点
三级通用要求的“安全计算环境”章节，几乎每个控制项都能映射到Redis上。我整理了一张映射表，测评启动会上直接丢给客户也很有用：
| 控制点 | 三级要求摘要 | Redis对应核查点 |
|---|---|---|
| 身份鉴别 | 用户身份标识唯一、鉴别信息复杂度 | requirepass、ACL用户、口令强度 |
| 访问控制 | 默认口令修改、权限最小化 | protected-mode、bind、rename-command |
| 安全审计 | 审计覆盖每个用户，记录访问行为 | logfile、slowlog、syslog接入 |
| 入侵防范 | 最小化安装、关闭危险命令 | 高危命令禁用、版本漏洞、异常外连 |
| 数据保密性 | 鉴别数据、重要业务数据传输保密 | TLS、管理网段隔离 |
| 数据备份恢复 | 本地备份和异地备份 | RDB/AOF持久化、备份任务 |
| 剩余信息保护 | 存储空间释放后信息不可恢复 | 数据删除后的持久化重写 |
后面的内容就按这七个方向展开，每一项都有对应的核查命令和整改模板。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 测评前先摸清Redis部署形态：单机、主从、哨兵还是集群
2.1 架构识别：一分钟确认Redis当前形态
Redis测评之前，第一件事不是查参数，而是搞清楚它是什么架构。命令很简单：
bash复制redis-cli -h 10.10.1.10 -p 6379 INFO replication
重点看role字段是master还是slave，connected_slaves是不是大于0。要判断集群模式就看：
bash复制redis-cli -h 10.10.1.10 -p 6379 CLUSTER INFO
如果cluster_enabled:1，就是Cluster集群。再看一下配置文件里有没有replicaof指令、cluster-enabled yes之类的关键字。如果是容器部署，docker ps看看镜像，再进容器确认配置是否持久化到宿主机。这套识别动作花不了两分钟，但决定了后面整改方案怎么写。
2.2 不同部署形态的测评侧重点
| 部署形态 | 最容易出问题的点 | 核查侧重点 |
|---|---|---|
| 单机 | 没口令、危险命令全开、日志不落盘 | 身份鉴别、访问控制、日志留存 |
| 主从 | 主节点有密码但从节点masterauth没配；从节点可写 | 主从认证一致、replica-read-only |
| 哨兵 | redis.conf有密码但sentinel.conf没有auth-pass | 哨兵认证配置、failover可用性 |
| 集群 | 各节点requirepass不一致；16379集群总线端口暴露 | 认证一致性、总线端口防火墙 |
| 容器化 | 端口映射0.0.0.0:6379、配置文件不挂载 | 映射范围、卷权限、宿主机安全 |
这个表基本覆盖了实际环境里能见到的Redis部署方式。测评时不能只看一两个节点，同一套Redis无论怎么部署，每个节点的安全配置都要单独核查，节点之间配置不一致本身就是一条风险。
2.3 架构识别直接影响整改边界
这里说一个真实教训。之前一个系统用的是主从架构