去年帮朋友公司做等保三级测评整改测评机构进场第二天就发来一张截图内网扫描发现一台测试服务器上的 6379 端口对外开放用 redis-cli 直连没输密码直接返回了 info 信息。朋友当场就不说话了——他以为 Redis 设了密码就算合规结果测评人员告诉他这是高风险未授权访问整改期只有两周。这个场景在等保三级测评项目里太常见了。Redis 作为高并发应用的核心组件部署量极大但它默认配置天生不安全无认证、无 ACL、所有命令可用加上很多运维图省事用 root 跑、监听 0.0.0.0导致 Redis 几乎稳定“承包”了等保测评里安全计算环境的高危项。这篇文章不绕弯子直接把测评机构对 Redis 的检查思路、高危风险点、可抄走的加固配置、容易翻车的坑和自检命令一次讲清。不管你是运维、安全工程师还是刚接手等保整改的项目负责人照着做基本能把 Redis 这块从“高风险”拉回“符合”。1. 测评人员一进场Redis的核查线是这样打开的1.1 Redis在等保三级测评中的归属与权重等保三级测评依据 GB/T 22239-2019整套评估不是只盯着 Redis 一个组件而是针对定级系统做整体核查。但 Redis 作为安全计算环境里的典型应用组件几乎所有测评方案都会覆盖到。测评师会把 Redis 拆解到具体条款下面逐项看而不是笼统说一句“Redis 安不安全”。我整理了测评师实际会对照的核查点基本是这张表的样子等保三级技术条款Redis 对应核查点身份鉴别requirepass 是否设置、ACL 用户配置、密码复杂度与轮换、空闲超时访问控制bind 地址、protected-mode、端口暴露、防火墙白名单、最小权限安全审计logfile 配置、慢查询日志、Redis 日志是否接入统一审计平台入侵防范危险命令是否收敛、是否非 root 运行、版本是否存在已知漏洞、最小安装数据完整性与保密性持久化策略、备份恢复机制必要时检查 TLS资源控制maxmemory、连接数限制、主从高可用这里要特别提醒一句不要在测评时说“Redis 只是缓存数据在 MySQL 里不重要”。测评师不会因此放水反而会认为你对资产边界理解不到位。Redis 一旦被攻破主机权限可能沦陷后续数据库、内网全部暴露所以测评师对缓存组件的态度往往比业务系统还严格。1.2 测评师现场核查Redis的实际动作测评师不是只看配置文件就完事他们的核查节奏一般是“访谈 文档 现场验证”三条线并行。我第一次配合测评时被他们的动作速度惊到了进场当天下午就把内网扫了个大概。现场核查 Redis 的典型动作包括从资产清单和网络拓扑里定位 Redis 节点确认它在什么网段、是否跨信任域部署用 Nmap 等工具扫描常见端口6379、6380、16379、26379 这些都不会漏执行ps -ef | grep redis、systemctl status redis确认进程启动身份和启动参数直接读取 redis.conf或者用已认证客户端执行 CONFIG GET 查看运行期配置尝试无认证连接比如redis-cli -h 目标IP -p 6379 PING如果返回 PONG直接记录未授权访问核查 Redis 日志是否留存、是否接入集中日志平台留存周期是否满足要求。这些动作看着简单但真能揪出大量不合规实例。我见过不少项目业务跑得很稳Redis 却裸奔在公网安全组里连密码都没有测评师一抓一个准。所以做自检时最好也按这条线走一遍别只盯着配置文件看。2. 排在整改首位的高危项未授权访问、危险命令、Root运行2.1 未授权访问比弱口令更容易踩中也更容易翻车未授权访问在历次等保测评里都属于必检项而且一旦复现基本直接判高风险。问题根源往往很朴素开发环境快速搭建时图省事bind 0.0.0.0跨主机访问图方便把 protected-mode 关了云服务器安全组放行了 0.0.0.0/0 的 6379 端口容器启动命令没注意网络模式端口直接映射到宿主机。未授权访问带来的风险不用我多说数据被读取、被篡改、被清空Redis 历史上也有被利用写文件进而控制主机的攻击链。测评师验证它只需要一条命令但整改却涉及多处bind 收紧、protected-mode 开启、强密码设置、安全组白名单收敛四件事缺一不可。有个细节要注意哪怕你设置了 requirepass如果 bind 还是 0.0.0.0、安全组放行公网测评师依然会记录一条“网络暴露面过大”的风险。因为密码可以被暴力破解暴露面本身就该收敛。整改后一定要让测评师在相同命令下看到差异——之前 PING 返回 PONG整改后返回 NOAUTH截图留档这条才能彻底关闭。2.2 危险命令不收敛数据安全条款直接卡壳Redis 默认命令全集可用这也是测评师重点看的点。FLUSHALL、FLUSHDB、KEYS、CONFIG、DEBUG、EVAL、SHUTDOWN 这些命令只要客户端连上就能执行后果分别是清空数据、阻塞实例、读写配置、触发异常、停机。测评师可能只验证一条 CONFIG GET dir能拿到当前工作目录就说明攻击者具备读取配置的能力直接记不符合项。我在等保整改里经常给客户一张危险命令表照着处理就行命令主要风险整改建议FLUSHALL / FLUSHDB清空全部或当前库数据禁用日常清理用 SCAN DELKEYS数据量大时阻塞实例泄露 key 清单禁用用 SCAN 替代CONFIG读取或篡改运行配置禁用配置变更走文件 重启DEBUG调试命令可能触发异常禁用EVAL执行 Lua 脚本不必要时禁用SHUTDOWN直接停止服务建议重命名而非禁用保留运维通道这里有个实际经验rename-command SHUTDOWN 配了之后正常执行systemctl stop redis可能会受影响系统被迫走强杀流程反而产生脏数据。所以 SHUTDOWN 这类运维必需命令建议改成一个难猜的名字而不是直接禁用。测评师看到 FLUSHALL、CONFIG 这些高危命令已经被改名或禁用对“命令收敛”这一条就认可了。2.3 以Root身份运行被裁定的高概率是“高风险”很多 Redis 实例是用 root 起的因为编译安装默认在当前用户执行redis-serverapt 安装在某些系统上也会以 root 跑Docker 容器如果不指定 USER默认也是 root。测评师看ps -ef一眼就能识别。为什么等保对进程身份这么敏感因为进程一旦被利用写文件写出来的文件权限就跟着进程走。root 启动的 Redis 如果被攻破攻击者等于拿到了服务器最高权限这个后果已经超出 Redis 本身的数据安全范畴属于主机沦陷级别的事件。测评师把这条列为高风险完全合理。整改方案本身不难创建一个 redis 系统用户数据目录和日志目录的属主改成 redissystemd 启动文件里加上Userredis和Groupredis。但这里有个高频坑——很多人改完用户后Redis 因为没权限写日志或写 RDB 文件而启动失败于是又把 User 改回 root。正确做法是先把目录权限给足再切用户顺序反了就会踩坑。3. 可直接抄的redis.conf加固模板以及每个参数为什么这么写3.1 网络暴露面收窄bind、protected-mode、port先看最小必要配置bind 127.0.0.1 10.10.20.5 protected-mode yes port 6399bind 只写回环地址和确需访问 Redis 的内网 IP不要写 0.0.0.0也不要空着。如果 Redis 要被多个网段访问可以列多个 IP。protected-mode 的设计初衷是“在没有配置认证的情况下保护实例”这里显式开启和 requirepass 形成双保险。port 改成非默认端口不是等保强制项但能减少扫描器命中概率。如果业务侧不方便改端口保留 6379 也没问题关键看网络白名单。云上部署尤其注意安全组只放行需要访问 Redis 的源 IP 或网段千万别写 0.0.0.0/0。我见过有项目密码设得很复杂结果安全组忘收敛测评师照样记了一条“高风险端口暴露”。3.2 身份鉴别与命令管控requirepass、rename-command、ACL密码不要手敲直接用工具生成openssl rand -base64 24配置里加上requirepass 生成的强密码 masterauth 同样的强密码masterauth 是主从场景里从库连接主库时用的认证密码很多人只配 requirepass 忘了 masterauth主从同步会失败。密码复杂度至少要大小写字母、数字、特殊字符都有长度不低于 16 位。测评师除了看有没有密码还会问“密码多久轮换一次”“存在哪里”所以密码管理制度也要提前准备比如每季度轮换、通过密钥管理系统的环境变量注入而不是写在明文启动脚本里。命令管控这块在 redis.conf 里把危险命令收掉rename-command FLUSHALL rename-command FLUSHDB rename-command KEYS rename-command CONFIG rename-command DEBUG 如果要保留 SHUTDOWN可以改成一个内部才知道的名字例如rename-command SHUTDOWN OpsOnlyShutdown2024如果你的 Redis 版本是 6.0 以上我更推荐用 ACL 替代一部分 rename-command 的诉求。ACL 可以做到用户级权限隔离比如给应用账号只开放业务前缀 key 的读写权限给运维账号开放全部权限user app_prod on 应用连接强密码 ~app:* read write -admin ping user ops_admin on 运维管理强密码 ~* all这样做比单一 requirepass 更符合等保“身份标识唯一、权限分离”的要求测评师看到 ACL 配置认可度会明显提高。要注意 ACL 启用后客户端连接方式要从AUTH password调整为AUTH username password老客户端可能不兼容上线前要做回归测试。3.3 审计日志、资源限制与持久化缺一不可下面这几项是把“安全计算环境”里其他条款补齐的关键loglevel notice logfile /var/log/redis/redis-server.log slowlog-log-slower-than 10000 slowlog-max-len 128 timeout 300 tcp-keepalive 60 maxmemory 4gb maxmemory-policy allkeys-lru appendonly yes appendfsync everysec逐条说理由loglevel 用 notice 而不是 warningwarning 信息太少debug 又会爆量notice 在生产环境比较适中。slowlog 默认只保留 128 条内存日志不能直接当审计证据要定期拉取到外部平台这个后面专门讲。timeout 300 表示空闲连接 5 分钟自动断开对应等保里的登录会话超时要求。maxmemory 限制内存上限防止 Redis 内存打满拖垮宿主机对应资源控制条款淘汰策略按业务选纯缓存用 allkeys-lru数据敏感就选 noeviction 并配好告警。appendonly 开启 AOF 持久化appendfsync everysec 最多丢一秒数据比纯 RDB 模式更符合数据可靠性要求再配合定期备份数据安全条款才能拿分。3.4 文件权限、运行身份与TLS补充操作配置文件、日志文件、数据目录的权限要单独收一遍chmod 600 /etc/redis/redis.conf chmod 640 /var/log/redis/redis-server.log chown redis:redis /var/lib/redis配置文件 600 权限很关键。有人会质疑“Redis 密码在配置文件里是明文是不是也算不合规”实际处理中文件权限做到只有 root 可读写、密码长度和复杂度达标、轮换机制明确测评师一般会认可因为这是 Redis 产品机制本身决定的不属于可整改项。如果 Redis 要跨网段传输或者组织内部安全策略要求传输加密Redis 6.0 以上原生支持 TLStls-port 6380 tls-cert-file /etc/redis/tls/redis.crt tls-key-file /etc/redis/tls/redis.key tls-ca-cert-file /etc/redis/tls/ca.crt客户端连接时加--tls参数。如果不想动业务客户端也可以在 Redis 前面挂 stunnel 或云厂商的代理做 TLS 终结。至于“存储过程保密性”这个质疑标准答复口径是Redis 承担缓存角色不作为核心业务数据的最终存储敏感字段已在应用层加密测评师通常能接受这个解释。4. 三个最容易在测评整改中翻车的场景4.1 主从复制场景改了主库配置从库还在裸奔这是我亲手踩过的坑。某项目第一轮整改我把主库的 bind、requirepass、rename-command 全改了从库为了省事只同步了数据文件没更新配置。复测时测评师直接连从库发现不用密码就能执行 infoCONFIG 命令也还能用当场记了一个不符合。主从和集群场景下每一项安全配置都必须所有节点保持一致。从库要配 masterauth否则和主库做同步时认证失败从库建议加slave-read-only yes防止从库被写入脏数据rename-command 和 ACL 定义也必须在每个节点都生效否则主从切换后新主库等于没有安全防护。现在我用 Ansible 或脚本统一下发配置任何节点上线都从同一份安全基线生成不再手工逐个改。4.2 版本差异Redis 5.0和Redis 7.0的整改方案完全不同很多生产环境的 Redis 还停留在 5.0甚至更老。不同版本的整改方案差别很大千万别拿一套配置硬套Redis 5.0 及以下没有 ACL没有 TLS只能靠 requirepass 加 rename-command如果测评方坚持要求多用户权限隔离或者传输加密唯一的出路是升级。Redis 6.0引入 ACL 和 TLS可以用 user 指令定义不同权限账号也可以用 tls-port 开启 TLS整改手段丰富很多。Redis 7.0ACL 成为一等公民部分命令的权限模型做了调整升级后必须回归业务重点验证客户端兼容性。老版本如果存在已公开的安全漏洞测评对版本问题会非常敏感最好升到当前 LTS 版本。容器化部署也有版本坑。比如用了 redis:5-alpine 镜像镜像本身就没有 ACL 能力想用 ACL 只能换镜像重建实例。遇到测评才发现版本太老不要硬在旧版本上打补丁先评估升级时间和数据兼容性确实不能升级的把风险清单和安全补偿措施写清楚测评师可能接受中风险但会要求明确的整改计划。4.3 审计日志覆盖不足被判定“不满足安全审计”后的补救Redis 原生日志只记录启动、关闭、主从切换、慢日志这些关键事件不记录具体用户执行的每一条命令。这是产品机制决定的不是配置能补出来的。如果测评师按“审计覆盖每个用户的重要行为”来卡单靠 Redis 自身日志一定会被记不符合。我踩过这个坑后总结出一套组合方案所有管理操作入口收敛到堡垒机管理员对 Redis 的操作由堡垒机审计这是“登录操作审计”的主要来源。Redis 日志、慢查询日志统一接入日志平台比如 ELK 或 Loki保留周期不少于 6 个月。云上托管的 Redis 通常自带审计日志能力直接开启并接入日志服务。自建环境如果业务能接受可以短暂开启 MONITOR 并把输出导入日志系统但注意 MONITOR 对性能有损耗生产环境慎用。跟测评师沟通时话术要到位“Redis 的命令级审计由堡垒机和统一日志平台实现Redis 自身日志作为组件级审计补充”这符合等保里安全管理中心集中审计的设计思路而不是把锅全甩给 Redis。5. 提交测评前先用这几条命令给自己做一次预检5.1 从攻击者视角模拟测评师的验证动作预检第一步先模拟一次未授权访问探测redis-cli -h 127.0.0.1 -p 6399 PING如果返回NOAUTH Authentication required说明认证生效如果返回PONG说明认证没配置或者没生效马上整改。再检查监听范围ss -lntp | grep 6399预期看到127.0.0.1:6399和10.10.20.5:6399这样的地址千万别看到0.0.0.0:6399。如果 Redis 部署在云上还得从另一台机器扫描验证nmap -Pn -p 6399 对端IP确保只有业务网段能访问公网或外部网络扫不到。即便有密码0.0.0.0 监听依然存在暴力破解风险这个暴露面必须收。5.2 危险命令禁用、运行身份和日志留存检查然后用密码登录后跑一遍危险命令验证redis-cli -a 你的强密码 -p 6399 FLUSHALL redis-cli -a 你的强密码 -p 6399 CONFIG GET dir redis-cli -a 你的强密码 -p 6399 --scan --pattern app:* | head -5前两条预期返回ERR unknown command说明命令已被禁用第三条用 SCAN 替代 KEYS能正常列出 key说明运维替代方案可用。如果 FLUSHALL 或 CONFIG 没有被禁马上回第 3 章补配置。再检查进程身份和关键文件权限ps -ef | grep redis systemctl cat redis | grep -E User|Group ls -l /etc/redis/redis.conf /var/log/redis/redis-server.log ls -ld /var/lib/redis tail -n 50 /var/log/redis/redis-server.log预期结果进程属主是 redis 用户而不是 root配置文件权限 600、日志文件 640、数据目录属主 redis日志里有近期启动、AOF 重写等事件记录。日志文件如果是空的或者没有权限说明审计这个环节还有问题。5.3 给测评师的证据链提前整理成清单测评不是答辩比赛嘴上说“我们设置了强密码”没用证据链才是关键。我建议整改后就把下面这些整理成一个文件夹测评师要看什么直接给redis.conf 关键配置行截图bind、protected-mode、requirepass、rename-command 或 ACL、logfile、maxmemory、appendonly进程运行身份和端口监听结果主从所有节点的配置一致性检查记录日志接入平台或堡垒机审计的截图定期备份和恢复演练记录。上次整改时客户对着测评师说“我们密码用了大小写数字特殊字符肯定合规”测评师直接要证据最后把配置文件关键行和密码策略制度文档提交了这条才算过。所以提前把证据准备好比临时解释一百句都管用。最后再分享一个小技巧把 Redis 加固配置固化成一套模板纳入你的部署流程。我之前用 Docker Compose 启动 Redis 时直接把安全基线写进配置文件配合健康检查脚本新环境一起起来就自动合规。等保三级测评的 Redis 安全测评技术门槛真的没那么高难的是把安全基线变成部署习惯。把这份配置模板放进自己的运维仓库下个新环境直接复用下次测评进场你就能看着测评师敲完命令然后收到一句“Redis 这块没问题”。