4. 数据暴露路径之错误配置：存储桶公开访问、ACL配置错误、公共读写权限
这一章我们聊点“接地气”的。你做云安全，第一个要盯紧的其实是配置。不是漏洞，不是0day，就是配置。
我碰到过太多案例了——公司花了几百万买安全产品，结果最大的数据泄露是因为存储桶的ACL写了个“Everyone:FullControl”。嗯，说白了一句话：你把家钥匙挂在了大门口。
4.1 存储桶公开访问：一个开关的代价
先看最基础的：存储桶公开访问。以AWS S3为例，默认情况下桶和对象都是私有的。但只要一个开关没关，全世界都能读。
这个开关叫 Block Public Access。你在控制台、CLI、SDK都能设置。四个级别：
| 设置项 | 作用 |
|---|---|
| BlockPublicAcls | 阻止通过ACL授予公开访问 |
| IgnorePublicAcls | 忽略已有公开ACL |
| BlockPublicPolicy | 阻止桶策略授予公开访问 |
| RestrictPublicBuckets | 限制只有同一账号可访问公开桶 |
⚠️ 我踩过的坑： 有一次客户说“我们Block Public Access全开了，安全得很”。但我一检查，发现桶策略里写了 "Effect":"Allow","Principal":"*" ，而且 BlockPublicPolicy 是 false。所以记住：四个开关必须全开，少一个都可能漏。
为什么会有人关掉？我见过两种场景：一是开发时为了方便，临时关掉，上线忘了恢复；二是第三方工具要求桶公开才能正常工作。每次遇到这种，我都建议用预签名URL代替，别偷懒。
4.2 ACL配置错误：古老的权限模型还在用
ACL（访问控制列表）是S3最早期的权限模型，现在虽然被桶策略和IAM取代，但很多遗留系统还在用。而且新版S3控制台还在展示ACL，新手容易随手改出问题。
先看一个典型错误：桶ACL里给了 AllUsers 或 AuthenticatedUsers 权限。
# 错误的ACL示例（伪代码）
Grantee: AllUsers
Permission: READ
Grantee: AuthenticatedUsers
Permission: WRITE
AllUsers是指任何互联网用户，不需要登录AWS。AuthenticatedUsers是任何AWS账号用户。这两种赋予权限，在我眼中就是自爆。
我记得有个金融客户，他们的日志存储桶用了ACL，对AuthenticatedUsers开放了READ。结果隔壁账号的安全研究员扫到后顺手把数据爬走了。事后查日志，根本不知道是谁——因为对方可以用任意AWS账号登录，IP也不固定。
💡 实用建议： 能不用ACL就别用。现在AWS推荐统一用桶策略 + IAM策略。如果必须保留ACL，至少把 BlockPublicAcls 打开。
4.3 公共读写权限：最危险的三行代码
公共读写权限分两层：桶级别和对象级别。
- 桶级别：桶策略里写了
"Principal":"*"加上"Action":"s3:PutObject"或"s3:GetObject"。这是“任何人都能上传/下载”。 - 对象级别：单个对象的ACL设为
public-read或public-read-write。即便桶是私有的，对象权限也可能被覆盖（如果桶策略允许）。
这里有个细节很多人不知道：对象权限可以绕过桶的默认私有设置。比如桶ACL设为私有，但上传对象时指定了 x-amz-acl: public-read，该对象就公开了。除非你开启了 BlockPublicAcls 和 IgnorePublicAcls。
我曾经帮一家电商做过审计，发现他们的用户头像桶里混入了发票扫描件。为什么？开发在代码里写死了 public-read，上传所有文件都带这个头。结果用户头像变成公开无所谓，但发票也公开了。
核心原则： 默认拒绝 + 显式允许。所有存储桶默认私有，需要公开的单独处理。而且处理方式首选桶策略或预签名URL，而不是ACL。
4.4 一张图看懂错误配置暴露路径
下面这张图把三种错误配置串联起来，展示数据从存储桶到攻击者的完整路径。你想想看，攻击者只需要一个互联网连接，就能顺着这些配置漏洞摸到数据。
4.5 怎么发现和修复？
发现这些配置问题，我常用的手段有三个：
- 云平台自带的工具：S3控制台有“公开访问检查”面板，AWS Config可以配置规则
s3-bucket-public-read-prohibited和s3-bucket-public-write-prohibited。 - 第三方安全扫描工具：比如Prowler、Scoutsuite，能批量扫描所有桶的ACL和策略。
- 日志审计：开启CloudTrail的数据事件，记录谁调用过
PutBucketAcl、PutBucketPolicy等敏感API。
修复方法，嗯，也分三步：
- 第一步：对所有存储桶启用
Block Public Access，四个开关全开。如果是组织级别，可以设置aws:SourceAccount条件键来限制。 - 第二步：检查ACL，移除
AllUsers和AuthenticatedUsers条目。如果业务需要公开访问，改用桶策略配合aws:SourceIp或aws:Referer条件键。 - 第三步：扫描对象级别权限，用
get-object-acl批量检查。脚本可以参考下面这段：
# 快速检查所有对象的公开状态（部分示例）
aws s3api list-objects --bucket my-bucket --query "Contents[].Key" --output text |
xargs -I {} aws s3api get-object-acl --bucket my-bucket --key {} --query "Grants[?Grantee.URI=='http://acs.amazonaws.com/groups/global/AllUsers']"
💡 自动化建议： 把检查脚本放在CI/CD里，每次部署前自动跑一遍。我在团队中就用GitHub Actions，当天提交的桶配置如果出现公开策略，直接拦截，不给merge。
4.6 避坑总结
最后列几个我见过的典型翻车场景：
- 开发环境用了公开读写，测试数据被恶意加密勒索——桶里的文件全部被覆盖。
- 跨账号共享桶时，直接开放给
*而不限制对方账号ID。 - 用了S3静态网站托管，忘记设置
IndexDocument和ErrorDocument，结果整个桶内容被遍历。
我曾经帮一家公司做事故复盘，原因是运维同事在AWS控制台点了个“Make public”，然后去吃饭了。回来发现1.2T数据可读。其实只要开启 Block Public Access 的组织规则，这种误操作根本不会有任何影响。
配置错误是暴露路径里最蠢的一种——因为明明可以防住，却因为手滑、偷懒、或者不了解，把门打开了。别做那个开门的人。