刚陪客户完成了一轮等保三级安全测评的整改和复测其中最折腾的组件就是 Redis。在测评报告里Redis 经常被列为中高危问题项而且问题往往不是难整改而是不知道测评到底查什么、该拿什么标准去对照。这篇就把等保三级要求下 Redis 安全测评的完整做法写清楚给准备过检的安全运维、开发同学做个参考。我自己这几年参与过的三级系统测评项目不少Redis 几乎每次都会被测评师单独拎出来核查一遍。它既有网络服务、又能读写业务数据还经常部署在内网容易被横向渗透的位置属于典型的“风险传导组件”。如果等到测评师上门再临时补配置大概率会留下整改记录影响整体测评结论。所以提前搞懂测评点、按测评项做整改才是省时省力的做法。1. 等保三级测评到底会查 Redis 的哪些点位1.1 先搞清楚 Redis 在等保测评里的“身份”很多同学第一次接触等保测评时会以为 Redis 是“单独定级、单独测评”的组件其实不是。等保三级测评的对象是整个业务信息系统Redis 作为系统里提供缓存或数据存储能力的中间件是跟随业务系统一起纳入测评范围的。测评报告里不会单独给 Redis 出一份证书但会在“安全计算环境”“安全区域边界”等章节里对 Redis 的部署方式、身份鉴别、访问控制、安全审计等控制点逐项检查。理解这一点很重要因为它决定了整改思路Redis 所有安全措施都要围绕等保三级的通用控制要求来做而不是自己闷头加一堆安全功能。测评师手里拿的是统一的测评检查表每个控制点都要有对应实现和佐证材料。比如“身份鉴别”这一节测评师会检查 Redis 是否启用了身份鉴别机制、密码复杂度是否满足要求、是否具备登录失败处理能力“访问控制”这一节会检查是否存在默认账户、账户权限是否分离、是否配置了访问控制策略。另一个容易被忽视的点是 Redis 在网络拓扑里的位置。等保三级的测评对象通常是放在等级保护定级系统里的Redis 所在的服务器如果和核心业务数据库在同一安全域那么一旦 Redis 被攻破攻击路径就可能延伸到核心数据。所以测评师在核查时还会关注 Redis 是否暴露在不必要的网络区域、是否只对业务子网开放访问。1.2 测评关注的核心控制项与常见高危项根据等保测评实际执行时的检查习惯我整理了一张 Redis 相关的测评控制项对照表基本覆盖了测评师会现场核查的绝大部分内容。测评大类三级要求要点Redis 对应实操点身份鉴别对登录用户进行身份标识与鉴别口令有复杂度要求具备登录失败处理功能requirepass 或 ACL 口令设置密码长度与复杂度ACL LOG / fail2ban 等失败处理访问控制分配账户和权限默认账户处理权限分离和最小权限关闭或限制 default 用户基于业务创建最小权限用户禁用危险命令安全审计启用审计功能审计记录包含时间、用户、事件等审计记录保护并留存至少 6 个月开启 logfile记录认证、命令执行、慢查询日志logrotate 轮转留存入侵防范最小化安装关闭不需要的组件和服务及时修复漏洞使用新版本只加载需要模块以低权限用户运行关闭危险命令数据完整性重要数据传输和存储过程中应保证完整性RDB 自带 CRC64 校验备份任务校验数据保密性重要数据传输和存储应采用加密或其他保护措施启用 TLS 传输加密备份文件加密数据备份恢复本地备份与恢复功能异地实时备份RDB/AOF 持久化定时备份异地留存恢复演练从实际测评暴露的问题来看Redis 最容易踩中的高危项集中在这么几类未设置任何密码、存在未授权访问监听地址绑定了 0.0.0.0 且端口对外开放使用默认 6379 端口且未做网络访问控制版本过旧存在已知高危漏洞日志审计功能未开启FLUSHALL、CONFIG、KEYS 等危险命令未做限制。这几项只要中了一个测评时基本都会被记成中危或高危问题项。2. Redis 安全整改每个测评项怎么落到配置2.1 身份鉴别从 requirepass 到 ACLRedis 默认安装后是完全没有身份认证的任何能访问到 6379 端口的人都可以直接执行 INFO、KEYS、FLUSHALL 等命令这是测评里最严重的高危问题。等保三级对身份鉴别的要求很明确要有身份标识和鉴别机制口令要有复杂度要求还要具备登录失败处理能力。传统做法是在 redis.conf 里设置 requirepass一行配置就能挡住未认证连接requirepass 这里填强密码只用 requirepass 有两个问题一是所有客户端共用一个密码没法区分不同人员或应用的权限二是等保测评里如果访谈提到“账户权限是否分离”单靠 requirepass 很难交代。Redis 6.0 之后提供了 ACL 访问控制列表才是真正能对应等保要求的方案。ACL 可以创建多个用户每个用户单独设置密码、可用命令和可访问的 key 范围还能把默认的 default 用户直接禁用。登录失败处理这块Redis 自身没有类似 Linux 的账号锁定机制但不代表不能实现。Redis 6.0 以上版本有 ACL LOG 命令会记录认证失败的事件可以把这些日志接入告警脚本或第三方安全设备。我在实际项目里常用的是配合 fail2ban 监控 Redis 认证失败日志达到阈值后自动封禁来源 IP这样测评师问到“登录失败处理机制”时就有明确的技术实现可以演示。2.2 访问控制绑定、端口、危险命令一个不能少访问控制是等保三级测评里核查最细的一节也是 Redis 踩坑最多的部分。第一步先看监听地址很多服务器默认配置 bind 127.0.0.1 -::1这时候 Redis 只本机能访问相对安全但有些部署为了图省事直接不配 bind或者配了 0.0.0.0等于把服务暴露给了整个网络。正确做法是只绑定业务内网地址bind 10.24.1.10 127.0.0.1 protected-mode yesprotected-mode 是 Redis 提供的第二道防护当没有配置 bind 且没有设置密码时它只允许本机回环地址访问。测评师核查时经常盯着这个参数建议始终保持 yes。默认端口 6379 也是测评和渗透测试的重点对象。修改默认端口不能从根本上提升安全性但可以显著降低被批量扫描命中的概率。我一般建议改到一个不常用的高端端口比如 16379并同步调整防火墙放通策略。危险命令禁用在等保整改里几乎是必做项。Redis 的 KEYS、FLUSHALL、FLUSHDB、CONFIG、SHUTDOWN、DEBUG 等命令在生产环境里都有明显风险KEYS 会阻塞主线程CONFIG 能动态修改服务配置FLUSHALL 可能一键清空全部数据。整改时通过 rename-command 把这些命令禁用或改名rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG rename-command KEYS rename-command SHUTDOWN rename-command DEBUG 这里有个非常关键的坑如果 Redis 以集群模式运行rename-command 会导致集群节点间的内部通信异常启动时直接报错。所以集群环境不要用 rename-command而是靠 ACL 给不同用户划分命令权限再加上网络层限制来兜底。等保三级对资源控制也有要求对应到 Redis 就是最大连接数限制和空闲超时maxclients 512 timeout 300maxclients 要根据实际业务并发量评估设置太小会影响业务设置太大则起不到防护效果。我一般参考运维监控里峰值连接数留出 30% 到 50% 余量再定。2.3 安全审计日志留痕与 6 个月留存等保三级的审计要求里“留存不少于 6 个月”是测评师一定会核查的点。Redis 默认日志是输出到标准输出的systemd 环境下会被 journald 接管很多部署根本没配置 logfile导致测评时拿不出审计日志。整改第一步就是固定日志文件位置logfile /var/log/redis/redis-server.log loglevel notice日志文件本身要保护好避免被未授权删除或修改。我处理时会把日志目录权限改成 redis 用户所有文件权限设为 600并且避免让普通业务账号有操作权限。审计内容上Redis 可以在日志里记录启动关闭、配置变更、客户端连接等信息结合 ACL LOG 能覆盖认证失败和越权命令执行的审计需求。慢查询日志也是测评师比较认可的安全审计内容它记录了执行时间超过阈值的命令能反映是否有人运行了危险或超高消耗操作slowlog-log-slower-than 10000 slowlog-max-len 128日志留存除了本机保存还建议把日志实时转发到集中日志平台或安全审计系统。我过去的项目里用 logrotate 做按天轮转保留 180 天然后通过 auditbeat 或 syslog 转发到日志中心。这样测评现场既能看本机日志也能演示集中审计平台的检索记录两个层面都覆盖到。磁盘空间要提前估算。假设单日日志 20MB180 天就是 3.6GB看起来不大但如果哪天临时调成 debug 级别、或者有应用疯狂重试连接日志量可能暴涨到每天几百 MB。稳妥的做法是日志目录和使用盘分开挂载并设置 logrotate 的 maxsize 参数做双重限制。2.4 入侵防范版本、进程、最小化运行等保三级“入侵防范”控制点落在 Redis 上最直观的检查项是版本漏洞。测评前会做漏洞扫描老版本 Redis 的已知漏洞一抓一个准尤其 5.0 以下版本风险评估基本都是高风险。整改办法没有捷径升级到当前稳定版本。我写这篇内容时Redis 7.4 以上是 LTS 版本线至少也应该用 7.x低于 6.0 的版本连 ACL 和 TLS 都用不了很难满足等保要求。进程运行权限也要查。很多部署直接用 root 跑 Redis测评师看到进程属主是 root 就会记录安全问题。正确做法是创建单独的系统用户useradd -r -s /sbin/nologin redis chown -R redis:redis /var/lib/redis /var/log/redis然后修改 systemd 服务文件指定 Userredis 和 Groupredis确保 Redis 即使被攻击者利用进程权限也被限制在非特权用户范围内。最小化运行方面Redis 配置里不要随便加载用不到的模块比如某些云镜像会默认开启一些扩展模块不需要就移除。同时生产环境不建议开启 MONITOR 命令它会把所有客户端执行的命令原样输出任何能执行 MONITOR 的人都能窃取到其他应用写入 Redis 的敏感数据。2.5 数据保密性与备份恢复等保三级对数据传输的要求是加密或采用其他保护措施。Redis 6.0 之后原生支持 TLS可以把客户端到服务端、主从复制、集群通信的通道都加密起来这是最直接满足测评要求的做法。主要配置项port 0 tls-port 16379 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-auth-clients yes tls-replication yes tls-cluster yes把 port 设为 0 是彻底关闭明文端口只保留 TLS 端口。这个改动影响面比较大所有客户端连接命令都要加上证书参数redis-cli -h 10.24.1.10 -p 16379 --tls \ --cacert /etc/redis/tls/ca.crt \ --cert /etc/redis/tls/client.crt \ --key /etc/redis/tls/client.key如果业务客户端短期内没法全部支持 TLS退而求其次的方案是至少保证跨区域、跨信任域传输走专网或加密隧道并把测评访谈口径落在网络层隔离和访问控制上。但从合规角度讲测评师还是会更认可原生 TLS 方案。数据备份恢复在测评里主要看三点是否配置了持久化、是否有备份策略、是否做过恢复演练。Redis 的 RDB 文件自带 CRC64 校验机制加载时自动校验完整性这可以对应“数据完整性”的要求。备份策略建议每天全量 RDB 备份 定期 AOF 增量备份备份文件加密后传到异地对象存储或备份平台。恢复演练不需要多频繁但一定要有记录测评师看到最近几个月的恢复演练报告和结果记录这项基本就过了。3. 从“裸奔”到“过检”的完整整改实操记录3.1 先给实例做一次“安全体检”接到整改任务后我习惯先做一轮自助体检把实例当前状态摸清楚再逐项对照整改。体检命令都不复杂顺着执行一遍就能掌握大部分情况# 查看 Redis 版本 redis-cli -h 127.0.0.1 -p 6379 INFO server # 查看认证和网络相关配置 redis-cli -h 127.0.0.1 -p 6379 CONFIG GET bind redis-cli -h 127.0.0.1 -p 6379 CONFIG GET protected-mode redis-cli -h 127.0.0.1 -p 6379 CONFIG GET requirepass redis-cli -h 127.0.0.1 -p 6379 CONFIG GET logfile redis-cli -h 127.0.0.1 -p 6379 CONFIG GET maxclients # 查看 ACL 用户列表Redis 6.0 redis-cli -h 127.0.0.1 -p 6379 ACL LIST # 查看实际监听端口和进程用户 ss -lntp | grep 6379 ps -ef | grep redis-server把这些结果记录成一张检查表每项标注“符合”“不符合”“需整改”测评前沟通时直接发给测评机构做预审能减少现场很多来回。3.2 一套可直接套用的 redis.conf 改造片段下面是我在一套三级系统 Redis 整改时实际使用的核心配置片段去掉了环境相关的内容你可以根据自己的网络和证书路径调整后直接参考# 网络与保护模式 bind 10.24.1.10 127.0.0.1 protected-mode yes port 16379 tcp-backlog 511 timeout 300 tcp-keepalive 60 # 访问控制与资源限制 maxclients 512 maxmemory 4gb maxmemory-policy allkeys-lru # 持久化 save 900 1 save 300 10 save 60 10000 appendonly yes appendfilename appendonly.aof appendfsync everysec # 安全审计 logfile /var/log/redis/redis-server.log loglevel notice slowlog-log-slower-than 10000 slowlog-max-len 128 # 禁用危险命令单机/主从模式可用 rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG rename-command KEYS rename-command SHUTDOWN rename-command DEBUG 这份配置里有几个细节值得解释。端口我直接改成了 16379绕过默认端口扫描maxmemory 配了 4gb 和 allkeys-lru 策略防止内存写满导致 OOMappendfsync everysec 在性能和数据安全之间取了平衡AOF 开启后测评数据可恢复性这一项更容易过关。rename-command 的部分只适用单机或主从模式如果你们是集群这一段必须去掉改用 ACL 和网络策略。修改配置后一定要做一次完整的重启验证并在业务低峰期进行。重启后重点看三件事进程是否正常起来、日志有没有报错、应用连接是否恢复。如果应用用的是老客户端连接命令里没有带密码重启后直接连不上这种情况要把发布计划同步给应用负责人给足改造时间窗口。3.3 ACL 用户权限分离配置实例ACL 是满足等保访问控制控制点的重要工具。我在一个实际项目里做了三个用户只读用户给数据分析团队用读写用户给后台业务系统用管理用户给运维人员用default 用户直接禁用。每个用户密码独立权限范围也隔离# 登录后执行 # 禁用默认用户 ACL SETUSER default off # 创建业务读写用户 ACL SETUSER app_rw on \ 应用侧独立强密码 \ ~* \ all -admin dangerous::poly # 创建只读用户 ACL SETUSER app_ro on \ 报表侧独立密码 \ ~* \ read # 创建运维管理用户 ACL SETUSER ops_admin on \ 运维侧独立强密码 \ ~* \ all admin权限符号如果不熟很容易写错我这里解释一下~* 表示可访问所有 key实际生产建议按业务前缀收紧成 ~app:* 或 ~order:*all 表示允许全部命令组-admin 表示排除管理命令-admin 之后如果还想放开个别命令可以用 config|set 这种语法单独追加。用户建好后用 ACL LOG 可以审计所有认证和权限相关事件包括失败尝试和越权命令这正好对应安全审计里“对重要的用户行为和重要安全事件进行审计”的要求。3.4 日志轮转与采集入库日志不能只生成不管理否则半年留存要求根本落不了地。我在整改时给 Redis 配了 logrotate/var/log/redis/redis-server.log { daily rotate 180 compress delaycompress missingok notifempty create 600 redis redis maxsize 100M }这段配置的含义是每天轮转一次、保留 180 份、压缩存储文件属主和权限保持 600。maxsize 100M 防止单日日志异常增长把磁盘打满。轮转后 Redis 要重新打开日志文件一般通过 postrotate 里执行 CONFIG REWRITE 或者向进程发送信号实现systemd 环境下建议确认脚本对 Redis 服务没有副作用。本机留档之外我坚持把日志转发到集中审计平台。方式可以是 rsyslog 转发也可以装 agent 采集。这样现场检查时可以直接在平台上按时间范围检索 Redis 登录记录、命令执行记录对测评师来说这是非常直观的佐证材料。3.5 网络侧与主机侧配合整改Redis 服务端配置改得再完善网络层不设防也白搭。防火墙策略至少要精确到源 IP 和目的端口我在项目里的规则大概是这个思路# 仅允许业务子网访问 Redis 端口 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.24.1.0/24 port port16379 protocoltcp accept # 其他来源一律拒绝 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address0.0.0.0/0 port port16379 protocoltcp reject firewall-cmd --reload如果所用的环境是云安全组就在安全组规则里同样按“只允许业务网段访问端口”来配置拒绝规则优先。主机侧还有几个配合项Redis 服务以非 root 用户运行数据目录权限改为 redis:redis关闭服务器上不必要的系统服务SSH 服务限制可登录用户和来源 IP。这些虽然不是 Redis 本身但测评检查时会把 Redis 所在主机的安全配置一起核查主机本身中危项过多也会拖低整个系统的风险评分。3.6 测评佐证材料清单等保测评不是只看系统现状还要看管理过程记录。我整理了一份常用的材料清单整改过程中顺手把材料补齐现场会从容很多。材料类型具体内容配置核查记录Redis 配置项检查表、快照或截图账号权限清单Redis ACL 用户列表、账号审批单、权限变更记录审计日志记录日志留存策略说明、集中审计平台截图漏洞整改记录漏洞扫描报告、Redis 版本升级记录备份恢复记录备份策略、最近两次恢复演练报告管理制度文件口令管理制度、账号权限管理制度、安全运维规范材料里的账号审批单经常被忽略。很多团队 Redis 建用户没有申请审批流程测评访谈问到“账号新增和回收怎么管”时答不上来。提前把账号申请表模板建好哪怕补记录也好这个点过了就不用担心。4. 测评现场实录访谈、核查、渗透与常见坑4.1 访谈环节容易被问懵的问题测评现场访谈不是走过场测评师会根据控制点逐条问回答口径直接影响判定结果。Redis 相关的高频问题我整理过几类。身份鉴别方面会问“Redis 是否设置了身份鉴别机制”“密码策略是什么”“管理员登录是否有双因素认证”。实操中 Redis 命令行本身没法做双因子但运维登录一般通过堡垒机堡垒机上有动态口令或短信验证码就用堡垒机实现管理侧双因子来回答。应用连接 Redis 的账号是读写账号没有管理权限这样两级权限划分的表述在测评里很有说服力。审计方面会问“审计日志包括哪些内容”“留存多长时间”。回答口径要具体Redis 日志记录了启动、关闭、配置变更、客户端连接和异常认证事件ACL LOG 记录了所有认证和权限拒绝事件日志通过 logrotate 留存 180 天并实时转发到集中审计平台。每个说法后面都要有现场可以演示的支撑。数据安全方面会问“Redis 数据如何备份”“是否做过恢复演练”“备份是否异地保存”。回答时除了说明 RDB/AOF 策略最好拿出来最近的恢复演练记录具体到日期、范围、恢复结果。这一项是三类系统测评里经常作为问题项扣分的点很多团队平时不做演练到现场只能口头承诺测评师一般不会认可。4.2 配置核查与渗透测试现场怎么应对测评师现场核查 Redis 时通常会做几件事先看进程和端口监听情况再检查 redis.conf 或执行 CONFIG GET 获取运行参数还会尝试直接连接测试是否存在未授权访问。如果开放了端口且无认证现场执行 INFO 就能拿到服务器运行信息这条会被直接记录为高危未授权访问问题。建议在现场核查前先把自查和整改完成保证测评师执行 CONFIG GET 时看到的是整改后的状态。这里有一个容易犯的错有人在测评前临时用 CONFIG SET 改了运行参数但没写回配置文件一旦 Redis 重启就恢复原样。测评师如果同时对比运行配置和配置文件发现两者不一致也会作为问题项记录。所以整改必须做到运行配置和配置文件一致用 CONFIG REWRITE 把当前参数持久化到底层配置里。渗透测试环节Redis 是比较受关注的目标。测评团队会用扫描器识别开放端口和服务版本再尝试弱口令字典和未授权访问检测。如果版本老旧、密码简单、命令未限制被挖出问题几乎是必然的。反过来如果做了 ACL 权限隔离、危险命令禁用、非默认端口、防火墙限定源 IP这一部分的渗透结果基本是干净的。4.3 常见问题速查表问题现象可能根因解决方案端口对外可访问且无需密码bind 0.0.0.0、requirepass 未设置绑定内网地址开启 protected-mode配置强密码漏洞扫描报告 Redis 版本高危使用 5.0 等过旧版本升级到 7.x 稳定版本重新扫描验证日志文件不存在或为空logfile 未配置日志输出到 stdout配置 logfile 并检查日志轮转权限业务应用重启后连不上新增密码或 ACL 与客户端配置不一致同步应用连接串按发布流程灰度验证FLUSHALL 被禁用后业务报错应用依赖 FLUSHALL 清理数据改用 SCAN 分批删除或临时开通受限用户Cluster 模式启动失败rename-command 和集群模式冲突移除 rename-command改用 ACL 限制TLS 开启后客户端大量超时客户端未带证书参数连接先灰度分批次切换客户端连接方式审计日志留存不足半年未配置日志轮转或日志被清理logrotate 保留 180 天并转发集中平台这张表基本覆盖了我这些年遇到的高频问题。如果你在整改中遇到表里没有的情况核心排查思路是先看运行配置、再看配置文件、再看网络连通、再看应用调用链一层层缩小范围。4.4 整改中的几个典型坑与规避方法第一个坑是 requirepass 和 ACL 混用导致的权限混乱。有些旧客户端只认 requirepass 密码新环境又启用了 ACL两边配置不一致时会出现“密码正确但命令被拒绝”的怪现象。我的做法是先明确以 ACL 为准requirepass 只在迁移过渡期保留切换完成后立即移除。第二个坑是为了测评临时加密码却不通知开发侧。曾经有个项目运维在测评前一天给 Redis 加上密码第二天业务应用全部连接失败回滚后又回到无密码状态测评组直接判定未整改。整改动作一定要走变更流程配套客户端连接配置一起发布不能只动服务端。第三个坑是启用 TLS 时没有预留灰度窗口。TLS 切换不是改一行配置就结束的所有连接 Redis 的客户端、监控脚本、定时任务都要带上证书参数漏一个就断一个。我先在测试环境全部验证通过再按业务模块分批切换最后才关掉明文端口整个过程留了一周的观察期。第四个坑是日志量估算失误导致磁盘被写满。有次开启详细日志后没有配 logrotate一周内日志文件涨到十几 GB把系统盘占满Redis 进入只读保护模式。从那之后我所有日志方案必须同时包含轮转策略和磁盘容量监控缺一不可。第五个坑是集群环境直接抄单机配置。Redis Cluster 下 rename-command 会导致节点间通信问题启动报错。集群环境的整改重点应该放在 ACL 权限收紧、网络访问控制、TLS 加密和日志审计上而不是简单禁用命令。我个人在实际项目里的体会是Redis 的等保三级整改并不需要很高的技术门槛真正难的是把测评要求理解到位、把整改动作做完整、把佐证材料留清楚。很多团队不是不会配置 Redis而是不知道每一项配置对应测评里的哪一条要求导致改了一部分、漏了一部分。把这几个维度对照检查一遍Redis 这块基本就能稳过。最后再分享一个小技巧正式测评前两周主动把整改后的配置和日志记录发给测评机构做一次预沟通让他们提前看看有问题还有时间调整比现场被发现问题再整改要主动得多。