第 23 章：安全实战

zjc 于 2026-01-23 发布

这是《Redis 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。默认 Redis 设计运行在可信内网，不代表生产可以裸奔。公网暴露、无密码、root 运行、任意命令执行，都是常见事故入口。本章覆盖认证、ACL、TLS、网络隔离、审计与命令治理。

23.1 安全模型

网络层: 谁能连到 Redis
认证层: 连上来的是谁
授权层: 这个用户能执行什么
传输层: 数据是否加密
数据层: value 是否需要业务加密/脱敏
审计层: 谁做了什么

Redis 不是权限完整的数据库，最佳策略是网络隔离优先，最小权限补足。

23.2 网络隔离

bind 10.0.0.5
protected-mode yes

要求：

Redis 不监听公网；
安全组只放行应用网段；
运维跳板机单独访问；
Sentinel/Cluster 总线端口同样受控；
不同业务环境不互通。

云上常见错误：

0.0.0.0:6379 暴露公网
无密码
root 启动

这会直接导致数据被清空或勒索。

23.3 requirepass

兼容密码方式：

requirepass strong-password
masterauth strong-password

从节点连接主节点也需要 masterauth。

连接：

redis-cli -a strong-password

更安全的方式是用环境变量 REDISCLI_AUTH 或 secret 注入，避免密码进入 shell history。

23.4 ACL 用户体系

Redis 6 引入 ACL：

ACL WHOAMI
ACL LIST
ACL USERS
ACL CAT
ACL GETUSER app

创建业务用户：

ACL SETUSER order-service on >order-strong-pass ~order:* +ping +get +set +del +expire +hget +hset

含义：

片段	含义
`on`	启用用户
`>password`	设置密码
`~order:*`	只允许访问该 pattern 的 key
`+get`	允许 GET
`-keys`	禁止 KEYS
`+@read`	允许读命令类别
`+@write`	允许写命令类别

更完整示例：

ACL SETUSER app_read on >read-pass ~shop:* +ping +get +mget +hget +hmget +exists

ACL SETUSER app_write on >write-pass ~shop:* +@read +@write -keys -flushall -flushdb -shutdown -config

持久化：

aclfile /etc/redis/users.acl

ACL SAVE

23.5 命令治理

高危命令：

KEYS
FLUSHALL / FLUSHDB
SHUTDOWN
DEBUG
CONFIG
SCRIPT FLUSH
CLUSTER RESET

通过 ACL 限制：

ACL SETUSER app ... -keys -flushall -flushdb -shutdown -config -debug

原则：

应用用户无运维命令；
运维命令走管理员账号和审批；
生产禁用交互式 redis-cli -a 常驻脚本；
变更记录审计日志；
使用 SCAN 替代 KEYS。

23.6 TLS

配置：

port 0
tls-port 6379
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 关闭明文端口；
复制和 Cluster 总线也要启用 TLS；
客户端必须支持 TLS；
会增加 CPU 和延迟，需要压测；
证书轮换要有流程。

客户端：

RedisURI uri = RedisURI.builder()
        .withHost("redis.example.com")
        .withPort(6379)
        .withAuthentication("default", "pass")
        .withSsl(true)
        .build();

23.7 数据安全

Redis 不理解业务字段，敏感数据必须在业务层处理：

手机号、身份证、token 可以加密后存储；
日志和监控不得输出完整敏感 value；
缓存 DTO 只放必要字段；
会话 token 设置短 TTL；
跨租户访问必须在应用层校验；
key 中避免直接放敏感明文。

示例：

不推荐: user:13800138000
推荐:   user:1001
value:  加密手机号或 hash 后的引用

23.8 进程与文件权限

useradd -r redis
chown -R redis:redis /data/redis /etc/redis
chmod 600 /etc/redis/redis.conf

建议：

非 root 用户运行；
配置文件和数据目录最小权限；
RDB/AOF 目录不开放给普通用户；
禁止容器 privileged 运行。

systemd 示例：

[Service]
User=redis
Group=redis
ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
LimitNOFILE=65535
NoNewPrivileges=true
ProtectSystem=full

23.9 审计与变更

最低要求：

记录 ACL 变更；
记录 CONFIG SET；
记录发布/回滚；
记录高危命令执行审批；
监控异常登录来源；
定期导出配置快照对比。

Redis 本身审计能力有限，可结合：

跳板机命令审计；
配置管理工具；
网络流日志；
应用侧操作日志；
代理层审计（如有）。

23.10 安全检查清单

网络:
  [ ] 不暴露公网
  [ ] bind 内网地址
  [ ] 安全组按应用网段放行
  [ ] Sentinel/Cluster 总线端口受控

认证授权:
  [ ] requirepass 或 ACL
  [ ] 应用用户独立
  [ ] key pattern 限制
  [ ] 禁止高危命令
  [ ] 密钥进 secret 系统

传输:
  [ ] 敏感场景启用 TLS
  [ ] 复制和总线同步启用

数据:
  [ ] 敏感字段加密/脱敏
  [ ] TTL 与权限匹配
  [ ] 日志不打印敏感 value

运维:
  [ ] 非 root 运行
  [ ] 文件权限最小化
  [ ] 定期漏洞扫描与版本升级
  [ ] 审计与回滚流程

本章小结

安全先是网络隔离，再是认证授权；
ACL 可以按用户、key pattern、命令类别精细控制；
高危命令必须从应用用户剥离；
TLS 保护传输，业务加密保护敏感内容；
配置审计和最小权限是长期安全的底线。

思考题

只设置 requirepass，为什么仍然不够安全？
多业务共用 Redis 时，如何用 ACL 做 key 隔离？
开启 TLS 后性能下降，如何评估是否值得？