每隔几个月技术媒体上就会出现一条熟悉的新闻某公司的云存储桶暴露在公网数以百万计的用户记录任何人拿到一个 URL 就能直接下载。复盘报告的结论几乎总是相同的——攻击者没有突破任何防线入口从一开始就是开着的。对象存储领域的泄露事件多数不是漏洞利用的结果而是有人忘了关上一扇门。桶的权限是错的凭证是默认的控制台直接挂在公网上传输是明文的。RustFS 是用 Rust 写的 S3 兼容分布式对象存储Apache 2.0 协议开源1.0.0 已于 9 月 16 日 GA10 月 3 日刚出过补丁版 1.0.1一条 docker run 就能拉起来。安装简单是优点也是风险实例跑起来和有资格上线之间隔着一段不少人不肯走的路。官方文档其实把该做的安全动作都写了只是散落在安装指南、检查清单和集成页里没人替你把它们串起来。这份清单就是做这件事的五个动作每一条都给出官方文档出处逐条做完再接网络。把 rustfsadmin 换掉再谈别的RustFS 出厂自带一组默认凭证和大多数软件一样全世界的实例长着同一张脸。互联网上的扫描器对 S3 兼容端点的探测从不停歇新实例挂上公网早晚会被扫到。默认凭证的问题就在这里全世界都知道这把钥匙长什么样。这也是为什么官方把它放在安装文档的第一屏。安装指南开篇单独设了一节立即更改默认凭证要求在将 RustFS 接入网络前为 RUSTFS_ACCESS_KEY 和 RUSTFS_SECRET_KEY 设置唯一值原话的意思很直白rustfsadmin 这个全球通用的默认值一个字符都别留。Docker 部署页重复了同样的警告并给了补救路径容器启动时未设置自定义凭证的停掉它用两个 -e 选项重新创建rustfs-data 卷会保持不变数据不丢。已经用默认凭证跑了一阵子的实例光改环境变量还不够默认凭证在这段时间里等于公开重建容器之后把这段窗口期的访问日志翻一遍有异常就当已泄露处理。所以正经的启动命令应该长这样两个凭证变量在容器创建时就传进去控制台端口只绑本机回环原因下一节讲dockerrun-d\--namerustfs\--restartunless-stopped\-p9000:9000\-p127.0.0.1:9001:9001\-vrustfs-data:/data\-eRUSTFS_ACCESS_KEYyour-access-key\-eRUSTFS_SECRET_KEYyour-secret-key\-eRUSTFS_ADDRESS:9000\-eRUSTFS_CONSOLE_ADDRESS:9001\-eRUSTFS_CONSOLE_ENABLEtrue\-eRUSTFS_OBS_LOGGER_LEVELerror\-eRUSTFS_OBS_LOG_DIRECTORY/var/log/rustfs/\rustfs/rustfs:latest\/data密钥本身的生成方式也有讲究。安全检查清单的凭证保护一节要求初始化后立即设置唯一的访问密钥和强随机密钥例如使用 openssl rand -base64 24 生成示例里的占位符值绝不带进生产环境。官方 Docker 页的原话更直接绝不要将占位符值用于生产环境。二进制和 systemd 部署的路径不同把两个值写进 /etc/default/rustfs然后重启 rustfs 服务动作是等价的。这一关过了静态密钥之外还有个进阶方向。IAM 页对根凭证的口径很明确原话是请仅使用根凭证引导部署然后创建 IAM 用户和服务账户来处理日常工作。服务账户可以设过期时间STS 签发的临时凭证有效期在 15 分钟到 12 小时之间IAM 管理、OIDC 外部身份提供商两个章节都在安全与合规专区里。钥匙从永久有效变成按时作废泄露之后的影响窗口就完全不同了。9000 和 9001别同时对着公网RustFS 默认开两个端口9000 跑 S3 API9001 跑控制台。控制台是整个存储系统的管理面谁拿到它谁就能建桶、删桶、换策略它暴露在公网上的后果比数据面被扫到还重。安全检查清单的 API 安全一节为此写了三条使用防火墙或安全组限制对 S3 API端口 9000和控制台端口 9001的访问使用反向代理例如 Nginx不要直接公开存储节点禁用未使用的端口不要向公共互联网公开管理界面。具体开哪些口网络检查清单的防火墙一节给了一个最小集合- TCP 9000 (S3 API; also used for internal node-to-node communication) - TCP 9001 (RustFS Console) - TCP 443 (only if you terminate HTTPS on a reverse proxy / load balancer)注意 9000 的双角色多节点部署时它还承担节点间通信所以必须在集群内部全通但对公网可以一个端口都不给。443 只在你把 HTTPS 终结在反向代理或负载均衡上时才需要证书和流量压力都挪到了前置层存储节点本身继续待在内网。网络检查清单在 IP 分配一节还要求将管理网络与数据网络分离为存储节点分配连续的 IP 地址段并预留扩容空间对应到部署上就是控制台只绑内网地址运维要碰它先过跳板机。这一步在云上是安全组几条规则的事在 IDC 里是交换机 ACL 几行配置的事成本都不高跳过它的代价却可能是整站数据被人打包带走。检查方法也简单从一台公网机器上 telnet 这两个端口两个都连不上才算及格业务和运维的入口都收在 443 反代和跳板机后面。TLS 只是两个环境变量的事存储里的数据不该明文过网内部网络也不例外一旦有机器被拿下同网段的流量就是现成的窃听现场。安全检查清单对传输加密的要求很明确启用 TLS/SSL强制 TLS 1.2 以上建议外部和内部访问使用不同的证书证书用受信任 CA 签发私钥靠严格的文件权限保护多域名场景下用强加密算法例如 2048 位 RSA 或 256 位 ECC。落到操作上TLS 配置页写得相当短。证书必须命名为 rustfs_cert.pem 和 rustfs_key.pem放进任意一个目录然后在 /etc/default/rustfs 里指向它RUSTFS_TLS_PATH/opt/tlssystemctl restart rustfs重启之后 TLS 同时作用于两个监听器S3 API 和控制台都走 https不需要分开配两遍。容器部署则是挂载证书目录并传入同一个变量docker run -d \ --name rustfs \ -e RUSTFS_TLS_PATH/opt/tls/ \ -v /opt/tls:/opt/tls \ -p 9000:9000 \ -p 127.0.0.1:9001:9001 \ -v /data:/data \ rustfs/rustfs:latest这里有个文档专门提醒的坑容器默认以 rustfs 用户运行证书文件如果不归这个用户所有RustFS 会因为读不了私钥而配不上 TLS。报错信息往往和证书权限看起来毫无关系排查时先看文件属主再看 TLS 配置本身。私钥的保管同样属于检查清单里证书管理一条的范畴文件权限收紧到属主可读是底线。证书到期时间也建议纳入监控TLS 配好之后被一张过期证书打回明文是运维事故统计里出现频率很高的一种难堪。审计日志要放到系统外面出了安全事件你需要回答三个问题谁在什么时候动了哪个桶。答案只在日志里而日志只有在攻击者碰不到的地方才算数。安全检查清单的日志和审计一节要求启用审计日志并将其导出到外部系统给出的可选目标是 HTTP Webhook、Kafka、ELK、Splunk同时为登录失败、异常访问模式、批量删除这类行为设置告警。日志只留在本机不算数机器一旦被入侵被顺手清掉的往往就是日志本身这正是导出到外部系统的意义。RustFS 官方的 Docker Compose 文件自带 grafana、prometheus、otel-collector 和 jaeger 这组可观测性服务克隆仓库后一条命令整套拉起docker compose --profile observability up -d只想要 RustFS 本体的话把服务名单独指过去docker compose -f docker-compose.yml up -d rustfs不过要说清楚这套 compose 栈管的是指标和追踪跟审计日志要的外部不是一回事。审计日志对应的是检查清单里 Webhook、Kafka、ELK、Splunk 那条导出路径目标系统必须独立于存储主机拉起一套本机 Grafana不等于完成了审计导出。日志收集方式官方也给了参考用 systemd、Docker 或 K8s 这些标准工具收集再通过 ELK 或 Grafana Loki 分析。选型可以后置规则要先建异常访问模式这类信号只有提前定义了才会被看见事后翻日志永远慢一步。告警阈值的设计也有讲究批量删除是最值得盯的信号之一一次正常的运维清理和一次灾难性的误操作在日志里的形状可能一模一样差别只在有没有告警把它拦下来给人过目。留存时长则有一条硬性的法定底线《网络安全法》要求网络日志留存不少于六个月等保和行业审计的要求只会更严按最严的那条执行。纠删码不是备份Docker 页的生产环境之前一节把上线前的固定动作列了一遍完成预安装检查清单使用多节点部署架构启用 TLS 加密通信配置日志轮转策略并设置定期备份策略。备份被官方写进了上线前动作清单原因在安装页的部署模式对比表里写得很清楚单节点单磁盘模式没有任何容错能力需要依赖备份单节点多磁盘只能容忍节点内的磁盘故障跨服务器的磁盘级和节点级容错要靠多节点多磁盘加纠删码。也就是说容错能力再强的架构也不替代备份纠删码防的是磁盘坏防不了误删、恶意删和数据损坏。备份解决机器坏版本控制解决人手滑。安全检查清单的 WORM 合规一节要求启用版本控制和对象锁定以满足法规要求。开着版本控制的桶覆盖和误删都还有回退余地对象锁定再把对象钉死在保留期内勒索软件把文件加密重写那条最常见的技术路线也就走不通了。这两项是 S3 兼容生态的标准能力金融、医疗这类数据合规定得严的行业尤其用得上。备份本身的存放位置同样是个决策备份和源数据放在同一套存储里一场针对存储系统的故障或攻击会把两者一起带走异地或异系统的第二副本才是真正能兜底的最后一张牌。这五项检查全部是部署侧的配置动作但官方清单并不止这五项基于策略的访问控制和最小权限、不在代码里硬编码凭证、应用补丁并保持操作系统和依赖比如 OpenSSL为最新都在同一页上这五个是底线不是上限。