桶一旦能从公网访问，风险模型就变了：URL 会被爬虫扫到、会被转发到不该去的地方、出网带宽会因为别人的请求被打满。事后补救远不如上线前把该配的配好。这篇文章按"决定公开什么 → 控制谁能访问 → 限制能做什么"的顺序过一遍关键配置，命令与能力覆盖以 RustFS 的官方 S3 兼容性矩阵为参照。
先决定公开的是什么：整个桶还是某个前缀
"公开一个桶"有两种含义，配置路径完全不同。
全桶公开读：桶策略直接对整个桶的s3:GetObject放行，适合确定桶里全是公开内容的场景，比如静态站点资源、公开文档、软件分发包。
部分前缀公开：桶策略的 Resource 只覆盖公开前缀，其余前缀保持私有。策略形如：
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":"*","Action":"s3:GetObject","Resource":"arn:aws:s3:::my-bucket/public/*"}]}Resource 末尾那一段决定了暴露面。写成arn:aws:s3:::my-bucket/*就是把整个桶交出去，写成public/*才是只交出这一个前缀。这个字段是唯一能被审计的边界，靠"私密对象换个别的前缀名字"这种约定不可靠，一次误传就能打破。
还有一个容易被顺手加进去的动作是s3:ListBucket。只要给匿名主体放行列举，桶里所有对象名就能被一次性枚举出来，即使 GetObject 没放开，目录结构也已经泄露。AWS 的公开访问指南里也建议不要给匿名访问授予列举权限。公开读策略里把 Action 限定成s3:GetObject一项，是成本最低的一道收敛。
要注意策略匹配是前缀级的：public/*不会顺带保护public-backup/*这类名字，反过来如果你本意是公开public，写成pub*就会把private之外的一堆前缀一起放出去。写 Resource 时把目录层级想清楚，比事后改策略省事。
公开内容的第二条纪律是公开桶里别放任何带敏感信息的对象，包括带内网地址的日志、带密钥的配置文件、含个人数据的导出。桶策略管的是"谁能读"，管不住"这个对象本身就不该被看见"。
预签名 URL 是 bearer token
不想全桶公开的话，预签名 URL 是给单个对象限时访问的标准方式。AWS 官方文档对它的定位有一句很直接的原话：
In essence, presigned URLs are bearer tokens that grant access to those who possess them. As such, we recommend that you protect them appropriately.
bearer token 的含义是谁拿着 URL 谁就能访问，URL 本身就是凭证，服务端不再校验访问者身份。这决定了它的三个行为特征。
权限继承自生成者。URL 能做什么，取决于生成它的凭证有什么权限：生成者只有s3:GetObject，签出来的 URL 就只能读；带s3:PutObject才能签出可写的 URL。给应用配凭证时按最小权限走，预签名出去的 URL 权限跟着一起收窄。
有效期有限，过期点在请求时校验。AWS CLI 里指定有效期很直观：
aws s3 presign s3://my-bucket/report.pdf --expires-in3600SigV4 下有效期上限 7 天，控制台生成的上限是 12 小时。过期判定发生在发起 HTTP 请求那一刻，不是生成时锁死。RustFS 的兼容性矩阵里 Presigned GET 与 PUT URLs 都在已测试覆盖范围内，签名与过期机制遵循 S3 规范。
无法主动吊销。AWS 文档写明 URL 会在生成它的凭证被吊销、删除或停用时失效，即使 URL 里写了更长的过期时间也一样。想把已经发出去的 URL 收回来，唯一办法是动凭证，而那会影响该凭证签出的所有 URL。
可写的预签名 URL 风险更高一档。签出s3:PutObject的 URL 等于把一段写入权交出去，拿到的人可以往这个 key 写任意内容，把原有对象覆盖掉。给上传场景签 URL 时，把 key 限定在专门的前缀下，对象大小与类型在业务侧校验，别让上传点变成任意文件写入口。
把这三条合起来，预签名 URL 的使用纪律就清楚了：有效期给到业务需要的最短值，分发渠道按半公开渠道对待。一个 7 天有效期的 URL 被贴进工单系统或群聊，等于把这个对象公开 7 天，而这些地方的内容往往还能被检索、被转发。
分发链路本身也要过一遍：预签名 URL 一律走 HTTPS 分发，http 明文链路上任何中间节点都能截到完整签名，拿到就是有效期内的合法凭证。签发凭证还要按应用拆开，一个凭证签出的所有 URL 共用同一把"撤销开关"，凭证越集中，一次泄露要作废的 URL 就越多。
Block Public Access 的四项怎么用
预签名解决"给特定人限时访问"，防止桶被意外公开要靠另一套开关。AWS 把它拆成四项，各管一件事：
| 开关 | 管什么 |
|---|---|
BlockPublicAcls | 拒绝设置公开 ACL 的请求（PutBucketAcl / PutObjectAcl 失败） |
IgnorePublicAcls | 忽略已存在的公开 ACL，已生效的也一并失效 |
BlockPublicPolicy | 拒绝允许公开访问的桶策略（PutBucketPolicy 失败） |
RestrictPublicBuckets | 带公开策略的桶只允许本账户用户与 AWS 服务主体访问，同时拒绝所有匿名（未签名）请求 |
前两项管 ACL，后两项管桶策略。对"确定要公开读"的图床桶，BlockPublicPolicy和RestrictPublicBuckets都得关：前者会拦住公开策略的保存，后者会直接拒绝所有匿名请求，公开读一开就失效；ACL 类的两项保持开。对"绝不应该公开"的桶，四项全开，此时匿名访问会被显式拒绝。
配置可以写成一条命令，纳进桶的初始化脚本：
aws s3api put-public-access-block--bucketmy-bucket\--public-access-block-configuration\BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=false,RestrictPublicBuckets=falseRustFS 兼容性矩阵里 Public access block 标的是已测试覆盖，put、get、delete 三类配置操作都验证过，四项开关在 RustFS 上可用。
这四项的价值在于兜底：有人误操作放了公开策略、脚本误配了公开 ACL，开着阻断时这类请求会被直接拒绝。反过来也要记住它的副作用，开了BlockPublicPolicy之后公开读策略会配不上，"策略写对了却保存失败"的排查方向基本都在这里。生产桶不管要不要公开，都建议先定好四项各开哪些。
还有一条权限模型的纪律：公开面的管理尽量只走桶策略这一层，不要和对象 ACL 混用。ACL 与桶策略并存时判定逻辑叠加，两处各放行一半的情况很难靠肉眼审出来，意外公开大多出在这种混合配置里。上线的桶默认不动 ACL，权限变更全部落在桶策略上，审计时只需要看一个地方。
限制来源 IP 与 Referer 的真实效果
桶策略的 Condition 里可以加网络条件。限制来源 IP 用aws:SourceIp，AWS 官方给的示例形如：
"Condition":{"IpAddress":{"aws:SourceIp":"192.0.2.0/24"},"NotIpAddress":{"aws:SourceIp":"192.0.2.188/32"}}允许某个网段访问，同时排除其中一个地址。这个条件对直接访问桶的请求有效，在预签名场景下还有一层叠加效果：生成 URL 的凭证所在的身份策略带aws:SourceIp限制时，访问者 IP 不在范围内会被拒绝。于是"限时"之外又多了一层"限地"，给内部系统分发的 URL 可以这样收口。
还有一个部署形态的坑要提前知道：aws:SourceIp匹配的是到达存储服务端的直连源地址。桶前面挂了 Nginx 或 CDN 时，服务端看到的是代理 IP，不是真实客户端 IP，这条条件会整体失效。这种架构下 IP 限制要放到代理层做，桶策略里那条网段白名单匹配到的只会是代理自己。
Referer 防盗链是另一个常见需求，但 AWS 官方对这个条件的警告写得非常直白：
We recommend that you use caution when using the aws:Referer condition key. It is dangerous to include a publicly known HTTP referer header value. Unauthorized parties can use modified or custom browsers to provide any aws:Referer value that they choose. Therefore, do not use aws:Referer to prevent unauthorized parties from making direct AWS requests.
翻译过来，Referer 头是客户端可以任意伪造的，拿它防不住构造请求的访问者。官方给它的定位是防止数字内容被第三方站点引用（防盗链热链接），而不是访问控制。真要挡热链接，在 CDN 侧配 referer 规则通常更顺手，桶策略这层留着无妨，但别把它当成唯一防线。
限流与监控：账单和可用性的最后防线
S3 层面没有按 IP 或按用户的原生限流能力，实际做法是把限流放在接入层。
CDN 或反向代理层限流。Nginx 的limit_req/limit_conn、Cloudflare 的 rate limiting rule，都能按 URL 前缀或来源 IP 限流。代理在桶前面的话，一个最小配置形如：
limit_req_zone $binary_remote_addr zone=s3pub:10m rate=10r/s; server { location /public/ { limit_req zone=s3pub burst=20 nodelay; proxy_pass http://rustfs:9000; } }要划清这份配置的边界：Nginx 在这里只承担限流与代理，location前缀不构成访问隔离。S3 的鉴权判定发生在存储服务端，靠代理路径去区分公开与私密资源并不可靠，攻击者完全可以构造不经过这个 location 的请求。公开与私密的边界仍然要落在桶策略的 Resource 上，代理层只做加速、限流和 TLS。
静态公开内容前面挂一层 CDN 顺带解决两件事：缓存命中时不回源，出网压力落在边缘节点；边缘侧还能直接配 WAF 与地理封锁。代价是要管好回源路径：回源请求带专属鉴权头或专属凭证，源站侧拒绝不携带这组标识的直连请求，否则任何摸到源站地址的人都能绕过 CDN 直接访问桶。公开桶无所谓，混合前缀的桶这条必须卡死。
按前缀拆桶或拆前缀。公开内容单独放一个桶或前缀，出问题时可以单独收紧、单独下线，不用动主桶的策略。
监控请求量与出网流量。这两项是最容易被刷的指标，监控要按桶粒度拆分，异常上涨要能告警。自托管场景下账单风险换成了带宽和磁盘 I/O：被刷的桶会占满出网带宽，拖累同一台机器上的其他业务。好处是可以直接在网关层熔断，不必等结算周期结束才知道被刷了。
上线前的检查清单
把以上内容按"先决定公开什么、再限制谁能访问、最后限制能做什么"排了一遍：
可勾选的清单：
- 明确公开范围：整桶还是前缀，策略 Resource 写到哪个层级
- 私密内容不在公开桶里，或至少不在公开前缀里
- 预签名 URL 的有效期按最短需要设置，凭证按最小权限并按应用拆分，一律 HTTPS 分发
- Block Public Access 四项按桶的角色配好，写进初始化脚本
- 需要限来源的桶加
aws:SourceIp条件，不要只依赖 Referer - 接入层有限流，请求量有监控，出网流量有告警
- 手动签发的预签名 URL 有台账（谁、什么时候、多久）；程序批量签发的没法逐条记录，靠最短有效期和最小权限凭证兜底，凭证轮换时能估影响面
RustFS 在 Apache 2.0 许可下开源，仓库在 github.com/rustfs/rustfs，S3 兼容性矩阵公开在 docs.rustfs.com，上面提到的桶策略、公开访问阻断、预签名 URL 都是矩阵里已测试覆盖的能力。把这张清单在每次新桶上线时过一遍，比出事后翻日志找原因省太多时间。
