集群为何要单独加固
集群的加固要求与单机 Redis 基本一致，但多出一条：节点之间的通信也要认证。设置 requirepass 之后，节点彼此握手与复制时必须配置相同的 masterauth，否则 MEET、复制、投票都会失败；Redis 6.0 起还可以用 masteruser 指定 ACL 用户。此外集群总线端口固定为业务端口加 10000（如 6379 对应 16379），它承载 gossip 流量，只应在可信内网开放。
基本信息
| 认证 | requirepass（客户端）+ masterauth（节点间），两者必须匹配 |
|---|---|
| ACL 用户 | 6.0+ 支持 masteruser 指定节点间通信使用的账号 |
| 总线端口 | 业务端口 + 10000，例如 6379 对应 16379 |
| 网络 | 仅放行内网网段与安全组，禁止暴露公网 |
| 危险组合 | protected-mode no 且无密码且公网可达 |
典型使用场景
- 生产集群上线的安全基线检查：认证、端口暴露面、危险命令
- 定期轮换访问口令，验证节点间复制在换密后仍然正常
- 安全扫描整改：把此前为图方便暴露在公网的端口收回内网
- 多业务共用一套集群时用 ACL 给不同业务分配最小权限
- 配合堡垒机与跳板访问，把运维登录路径与业务访问路径分开
配置示例
配置示例
requirepass <强口令> # 客户端连接必须认证
masterauth <同一强口令> # 节点之间握手与复制使用
masteruser appuser # 6.0+ ACL 场景，节点间使用指定用户
protected-mode yes # 无认证且非本机访问时拒绝连接
# 按需禁用高危命令，注意会影响部分运维工具
rename-command FLUSHALL ""
rename-command KEYS ""加固后验证
加固后验证
redis-cli -p 7000 -a <口令> PING # 认证可用
redis-cli -p 7000 -a <口令> CLUSTER INFO | grep cluster_state # 集群状态仍 ok
redis-cli -p 7000 -a <口令> ROLE # 主从角色与复制连接正常
firewall-cmd --list-rich-rules | grep 16379 # 确认总线端口的来源限制加固项对照
| 加固项 | 配置 | 缺失的后果 |
|---|---|---|
| 访问认证 | requirepass | 任何人可读可写，可直接落库脚本 |
| 节点认证 | masterauth / masteruser | 复制与握手失败，集群状态异常 |
| 总线端口限制 | 内网放行 + 安全组 | gossip 被干扰，攻击面等同业务端口 |
| 危险命令禁用 | rename-command | 一条误操作即可清空全库 |
6.0 起的 ACL 可以按业务给不同账号分配键空间与命令权限，比所有业务共用一个 requirepass 更细，也更便于追责。
限制总线端口时要注意节点互访是双向的，逐个节点放行来源容易漏配，导致某个节点被孤立而触发误判下线。