等保三级Redis安全测评与整改指南

等保三级复测那天，测评工程师没有先看核心业务系统，而是蹲在一台Redis服务器前翻了大半个小时。回来后拿着一页检查记录问我：端口还是默认的6379？配置文件里没有看到requirepass？日志路径为什么是空的？FLUSHALL怎么还原样挂着？当时现场的负责人脸色就不好看了，一个Redis能牵出四五个整改项，这在等保三级测评里其实非常常见。

这篇文章就是要把等保三级要求下Redis安全测评这件事彻底说清楚：测评机构到底看哪些配置、用什么方法查、每一项为什么被查、整改时应该怎么改。我会把每一次踩坑和客户现场的真实处理方式都写出来，适合正在准备等保三级测评的运维、安全、开发同学参考。不需要你有等保理论基础，只要照着配置和思路走，Redis这块基本不会成为失分重灾区。

1. 测评机构盯Redis时到底在查什么：先看清楚规则再动手

1.1 Redis归属的测评域与对应检查项

知道测评老师为什么问那些问题，比直接抄配置重要得多。等保三级不是按“Redis专项清单”来测的，而是依据GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》里的通用控制项，把要求落到Redis这个具体组件上。

Redis在一套系统里通常属于“安全计算环境”的范畴，同时还会牵涉到“安全通信网络”里的传输加密要求。落到具体的测评项，主要包括下面这几类：

• 身份鉴别：Redis是否有访问密码？密码强度够不够？是否空口令？是否有账号隔离？
• 访问控制：Redis监听的地址是什么？是否暴露到公网或非受信网段？是否使用默认端口？配置文件的权限是否被改了？
• 安全审计：Redis日志是否落盘？日志内容能否覆盖用户、时间、操作行为？留存时间是否≥6个月？
• 入侵防范：高危命令（FLUSHALL、CONFIG、KEYS等）是否被禁用？Redis进程以什么用户运行？版本是否满足安全要求？
• 数据备份恢复：是否开启RDB/AOF持久化？备份文件是否做了权限控制？
• 资源控制：是否设置maxmemory、maxclients等连接和内存限制？

这些不是Redis特有要求，而是等保三级对关键组件的通用要求。测评机构不会管你用的Redis还是Memcached，只关心这个组件能不能满足这些控制项。

1.2 测评现场最常用的四种检查手段

我参加过多次等保测评和复测，大概率会遇到下面这四种做法，提前有个心理准备：

1. 访谈管理员：问账号几个人在用，密码怎么保存，多久换一次。这个时候你拿不出成文的口令策略，或者回答“大家共用redis-cli直接连”，身份鉴别项就会被记问题。
2. 直接读配置文件：这是核心动作。测评老师会打开redis.conf，重点看bind、protected-mode、port、requirepass、rename-command、logfile、maxmemory这几个参数。Redis的配置集中，反倒好查。
3. 用redis-cli做无害验证：比如直接执行redis-cli -h <ip> -p 6379 ping，看看能不能绕过AUTH连接；或者尝试CONFIG GET requirepass，看能不能直接读到配置。这一步和漏洞验证场景很像，一旦能连上，基本就是高危项。
4. 查运行证据：看进程运行用户（ps aux）、systemd unit文件、日志轮转配置、目录权限。一个Redis以root身份跑，在测评老师眼里就是不正常的。

理解了这个逻辑，你就明白后面所有整改动作都是在给测评老师提供“证据”。现场不需要背话术，配置拿出来、日志打开来，比解释一百句都管用。

2. 未授权访问整改：bind、protected-mode、端口，一个都不能裸奔

2.1 为什么未授权访问是等保测评里的“必考题”

Redis未授权访问在业内已经不算新闻了，很多安全事故就是从这里撕开口子的。默认配置下Redis只监听127.0.0.1，看起来安全，但问题出在很多部署过程中，操作人员会把bind改成0.0.0.0，让所有客户端都能连上，结果Redis就像在公网上裸奔。

等保测评里这也是必查项，因为检查成本太低：一条redis-cli -h IP -p 6379 ping就能判断。如果返回PONG，或者执行CONFIG GET requirepass能拿到内容，那就是未授权访问，测评结论直接提级。这个风险点基本属于“一票否决”级别的。

2.2 三件套整改：bind、protected-mode、port

对未授权访问的整改不是一个参数能搞定的，需要三个配合：

bind参数：只允许Redis监听内网地址或回环地址，绝对不要出现0.0.0.0。比如Redis所在服务器内网IP是192.168.10.10，配置：

code复制bind