摘要：# 对象存储的访问鉴权，配不好就是“裸奔”送数据 前阵子有个朋友半夜给我打电话，声音都抖了。他那创业公司的小程序，用户上传的身份证、合同照片，不知道怎么就被爬虫扒了个底朝天，直接挂在暗网论坛上叫卖。他第一反应是“服务器被黑了”，查了一圈，最后发现根子出在…

对象存储的访问鉴权，配不好就是“裸奔”送数据

前阵子有个朋友半夜给我打电话，声音都抖了。他那创业公司的小程序，用户上传的身份证、合同照片，不知道怎么就被爬虫扒了个底朝天，直接挂在暗网论坛上叫卖。他第一反应是“服务器被黑了”，查了一圈，最后发现根子出在对象存储的访问权限配置上——为了图省事，他直接开了个“公共读”的桶（Bucket），链接一泄露，文件就跟摆在马路牙子上没区别。

说白了，很多技术团队对服务器防火墙、数据库加密门儿清，但一到对象存储（比如阿里云OSS、腾讯云COS、AWS S3这些），就容易掉以轻心。觉着它就是个“网盘”，权限开关点一点就行。结果往往是，PPT上的安全方案一套套，真出了事才发现，最薄弱的环节是那个默认配置的存储桶。

今天咱不聊那些云里雾里的安全黑话，就坐下来，像给朋友出主意一样，掰扯掰扯对象存储的访问鉴权到底怎么配，才算真的把门锁好。

一、先搞明白：谁在敲门？想干什么？

配置权限前，你得先想清楚三个问题：

1. 谁来访问？ （是你的App服务器、某个用户、还是合作伙伴的系统？）
2. 访问什么？ （是读取一张公开的头像，还是上传一段私密视频？）
3. 怎么访问？ （通过你的应用间接访问，还是直接拿到链接就能下？）

想不清楚这个，所有配置都是瞎搞。我见过最离谱的，把核心财务数据的存储桶，用“密钥对”方式交给第三方外包团队开发，结果密钥硬编码在代码里传上了GitHub——这跟把银行金库钥匙挂在公告栏上有啥区别？

二、别再用“公共读写”了！从根上拧紧阀门

很多对象存储服务创建时，为了“友好”，默认可能就是“公共读”甚至“公共读写”。我的建议是，除非你在做一个完全公开的图库站，否则创建桶的第一步，就是立刻、马上，把整个桶的公共访问权限彻底关掉。

这个动作是基础中的基础。相当于把大楼的总闸先拉了，然后再给每个有需要的房间单独配钥匙和门禁卡。别嫌麻烦，安全从来都是“麻烦”堆出来的。

三、几种主流鉴权方式，怎么选不踩坑？

对象存储的访问控制，说白了就是发“门票”。门票形式不同，安全级别和适用场景天差地别。

1. 预签名URL：最灵活，也最考验手艺

这玩意儿好用啊。你不用把密钥给前端，而是由你的后端服务器，用密钥临时生成一个带签名的链接。这个链接有过期时间（比如30秒），并且可以精确指定只能对某个文件进行“读”或“写”操作。

适合场景： 用户上传头像、预览个人订单里的文件、分享一个限时查看的链接。 坑在哪里： 过期时间别设太长！我见过设7天的，那这链接一旦泄露，7天内都有效，风险窗口期太长。另外，生成签名的服务器本身必须绝对安全，它要是被攻破，攻击者就能批量签发任意文件的“通行证”。

2. 临时访问密钥（STS）：精细控制的“临时工牌”

这是比预签名URL更“重”一点的方案。不是直接给一个文件链接，而是颁发一套临时的密钥（AccessKeyId, SecretAccessKey, SecurityToken），这套密钥有指定的有效期（比如15分钟到几小时）和极其精细的权限策略（Policy）。

适合场景： 移动端App直接上传大文件到存储桶，但又不想把主密钥放在客户端。或者给第三方应用一个临时访问你某个存储目录的权限。 举个接地气的例子： 你的App有个“上传视频”功能。你可以让用户先向你的服务器申请一套临时密钥，这套密钥的权限被死死限定为“只能向 user-upload/video/ 目录下，以用户ID命名的文件夹里，上传后缀为.mp4/.mov的文件”。这样，即使密钥被截获，黑客也干不了别的事。

3. 存储桶策略（Bucket Policy）& 用户策略（IAM Policy）：管好“自己人”

这两个经常一起用，容易搞混。

• 存储桶策略 是贴在桶上的“门卫手册”，规定了这个桶允许或拒绝哪些访问。
• 用户策略（IAM Policy） 是发给具体用户（或角色）的“工作职责说明书”，规定了他能操作哪些云资源。

怎么用才安全？ 遵循 “最小权限原则” 。别动不动就 "Action": "*"（允许所有操作），或者 "Resource": "*"（允许操作所有资源）。你要备份，就只给 GetObject 和 ListBucket 的权限；你要让某个程序自动清理垃圾文件，就只给 DeleteObject 权限，而且最好把资源路径限制在 temp/ 目录下。

四、几个容易被忽略，但能要命的细节

1. 日志审计一定要开！ 对象存储的访问日志（Access Logging）必须开启，并定期检查。很多异常访问（比如来自奇怪国家IP的频繁列举请求）都是攻击的前兆，日志是你事后追查和事前预警的唯一依据。别等数据丢了才想起来看日志。
2. Referer防盗链不是万能的。 通过检查HTTP请求头的Referer字段来限制来源，能防住普通的外链盗用，但稍微懂行的人伪造个Referer太容易了。它只能作为一道辅助防线，不能当成核心鉴权。
3. 小心“内鬼”遍历。 即使你用了临时密钥或签名，如果权限策略里包含了 ListBucket（列举桶内对象），而你的文件命名又有规律（如 user_001.jpg, user_002.jpg...），攻击者就可能通过遍历猜出所有文件。对于敏感数据，最好的办法是关闭列举权限，或者使用无规律的随机文件名（如UUID）。
4. 跨域（CORS）配置要收窄。 如果你的存储桶需要被浏览器直接访问（比如前端JS直接上传），CORS配置是必须的。但千万别配成 AllowedOrigin: "*"（允许所有来源）。精确填写你的前端域名，比如 https://www.yourdomain.com。

五、给你一个简单粗暴的配置自查清单

如果你的业务涉及用户数据、商业资料等敏感信息，照着下面这个单子过一遍：

• [ ] 存储桶的公共访问权限已设置为“私有”。
• [ ] 所有访问都通过后端服务代理，或使用预签名URL/STS临时密钥。
• [ ] 所有签名的有效期都设置得足够短（根据业务场景，几分钟到几小时）。
• [ ] IAM用户或角色的策略遵循“最小权限原则”，没有使用通配符*滥授权。
• [ ] 存储桶访问日志已开启，并有监控告警（如异常高频访问）。
• [ ] 敏感文件的命名无规律，且已关闭不必要的ListBucket权限。
• [ ] CORS配置仅允许明确的、可信的源域名。
• [ ] 主账号的Access Key（那个有最高权限的）没有在任何前端代码、配置文件里明文写过。

说到底，对象存储的安全，核心思想就一个：别相信任何默认配置，把每一次访问都当成一次需要审查的请求来处理。 它不像服务器，有防火墙的“城墙”感，它的安全是隐形的、策略化的，更像一套遍布角落的传感器和门禁系统。

配置的时候多花十分钟，总比出事之后熬夜排查、登报道歉、甚至面临法律风险要强得多。你的数据，值得你为它多拧上这几道锁。

行了，关于鉴权的大实话就聊这么多。赶紧去检查一下你的桶吧，说不定有“惊喜”呢。