minio信息泄露漏洞修复

上周五凌晨两点，信息泄我盯着监控面板上那个异常攀升的露漏GET请求数，后背一阵发凉。洞修攻击者正用脚本批量遍历某个未授权访问的信息泄MinIO存储桶，下载速度稳定在每秒40个对象。露漏这不是洞修理论上的风险，是信息泄实打实的数据裸奔。

问题出在MinIO的露漏匿名访问策略。默认配置下，洞修如果bucket的信息泄policy被误设为`*:ReadOnly`，任何知道端点地址的露漏人都能直接列出并下载文件。更麻烦的洞修是，很多团队用默认的信息泄`minioadmin/minioadmin`账号跑生产环境，等于把保险柜钥匙挂在门口。露漏我见过一个客户把数据库备份传上去，洞修三天后被人拖走2TB数据，勒索信直接发到CEO邮箱。

修复的第一步，先关掉匿名读。用`mc`命令行工具逐桶检查policy：
mc anonymous list myminio/bucket-name
输出结果里如果出现`download`字样，立刻执行
mc anonymous set none myminio/bucket-name
这一步能堵住90%的泄露路径。别嫌麻烦，写个循环脚本把几百个bucket全扫一遍，比事后删库跑路轻松得多。

接下来处理弱口令。别高估团队的安全意识，我见过运维把密码设成`Minio@123`然后贴在工位上。强制启用密码复杂度校验，在启动MinIO时加环境变量`MINIO_ROOT_USER`和`MINIO_ROOT_PASSWORD`，长度至少16位且包含特殊字符。改完密码记得重启服务，光改配置文件不重启等于白干。

还有个容易被忽略的漏洞——版本控制未开启。MinIO默认不保留对象历史版本，一旦被恶意覆盖或删除，数据直接蒸发。但反过来想，如果开了版本控制，攻击者删掉原始对象后，你还能从旧版本里恢复。执行
mc version enable myminio/bucket-name
再配上生命周期规则自动清理过期版本，既防泄露又防误删。

最后检查访问日志。MinIO的console界面里，`Audit Log`模块能记录所有API调用。我习惯每天扫一遍`ListObjects`和`GetObject`请求的源IP，如果发现陌生地址高频访问，十有八九是扫描器在试探。配合防火墙只放行公司出口IP段，比事后追溯强得多。

这套组合拳打下来，上周那个攻击者的IP已经被自动封禁，数据泄露量控制在12个测试文件内——都是我们故意放的蜜罐文档。别等出事才补漏洞，MinIO的修复成本极低，但泄露后的公关和赔偿费用，够你买十年云服务。