公共读桶清不干净：对象存储权限审计的三个盲区

一、ACL 之外还有两扇门
对象存储的访问控制从来不止 ACL 一种。桶策略可以给匿名主体 * 授予 GetObject 权限，效果和公开读完全一样，但很多巡检脚本只看 ACL，直接漏掉。

第二扇门是预签名 URL。它把一次访问权限编码进链接本身，持有链接的人不需要任何身份就能下载对象。有效期可以从几分钟配到 7 天，一旦被贴进工单、聊天记录或前端代码，就等于把文件公开了。审计时如果只扫桶权限，这条路径完全隐形。

判断方法很直接：查桶策略里有没有 Principal: "*"，再统计预签名 URL 的签发量及其有效期分布。按经验值，一个中型账号的桶策略条目往往是桶数量的三到五倍，逐条人读并不现实。

二、备份、日志和 CDN 回源会继承权限
生产桶改成私有之后，问题常常并没有结束。

备份桶往往是独立的，由备份服务用服务角色写入，权限模型是另一套；日志桶由各业务账号跨账号投递，常被配成"谁都能写"；CDN 回源则可能通过源站鉴权或回源 IP 白名单放行。这三类桶的共同点是不承载业务数据，所以没人盯着，但它们复制的是同一批文件。

一个常见的组合是：生产桶私有、备份桶公开读、备份内容每日全量同步。审计报告上生产桶是绿色的，实际泄露面一点没变。更隐蔽的一种情况是灾难恢复演练：为了验证备份可用，临时给备份桶开了读权限，演练结束没人回收，这条授权就留在了生产环境里。

三、匿名访问与跨账号授权最难扫
最容易被忽略的是"合法但不该存在"的授权。桶策略里给某个外部账号授了读权限，可能是三年前一次数据交换留下的；也可能是测试环境为了联调临时放开，之后没人回收。

这类授权不会出现在公开读列表里，也不会触发任何告警，只能靠定期导出全部桶策略、逐条比对 Principal 才能发现。规模一大，人工比对基本失效。

四、可落地的审计路径
第一步，把 ACL、桶策略、预签名签发记录三份数据合并成一张资产视图，不要只依赖控制台里那个"公开"标签。

第二步，对每个桶问三个问题：谁能读、通过什么方式读、这条授权是什么时候加的。第三个问题决定它该不该留。

第三步，把回收动作自动化。给外部账号的授权设置到期时间，给预签名 URL 设有效期上限，备份桶默认跟随源桶私有。审计的价值不在于发现，而在于发现之后能在一天内闭环。

结语
对象存储的权限问题很少是"配错了"，更多是"配过就忘了"。公共读桶之所以清不干净，是因为入口比想象中多，而巡检脚本通常只认识其中一个。把 ACL、桶策略、预签名链接和备份链路放在同一张图上，才谈得上真正的收敛。

标签：云安全、对象存储、权限审计、数据泄露、