3. 数据暴露面识别方法：攻击面分析与资产枚举
说实话，搞云安全这么多年，我最大的一个感受就是——你都不知道自己有什么，那肯定守不住。
很多团队一上来就搞WAF规则、搞渗透测试，结果呢？漏了个测试Bucket在外面裸奔，数据早被人拖走了。所以我个人的习惯是，先摸家底，再谈防御。这一章我们就聊聊：怎么系统地识别你的数据暴露面。
3.1 攻击面分析：你到底暴露了什么？
先讲个真事。有一次我去帮一家金融科技公司做审计，他们的安全负责人信誓旦旦说“我们所有资产都在VPC里，很安全”。结果我用一个简单的子域名枚举，找到了一个dev-billing-db.internal-company.com的DNS记录——解析到一个公网IP，端口5432还开着。你猜怎么着？那是他们生产环境的PostgreSQL，里面有几百万条交易记录。
为什么会这样？因为他们只盯着主域名和主账号，忘了开发人员随手搭的测试环境和影子IT。这就是典型的攻击面盲区。
3.1.1 攻击面的四个维度
我个人习惯把云上的攻击面分成四个维度来排查，这样不容易漏：
| 维度 | 典型暴露点 | 我的排查重点 |
|---|---|---|
| 网络面 | 公网IP、开放端口、负载均衡器 | NACL、安全组是否过度放行；是不是所有服务都必须挂公网ELB |
| 应用面 | API端点、Web控制台、管理接口 | 有没有未认证的API？管理后台是否暴露在公网？ |
| 身份面 | IAM角色、AK/SK、临时凭证 | AK是不是硬编码在代码里？角色信任策略是不是“*”？ |
| 数据面 | 公开的S3桶、未加密的数据库、配置错误的KMS | 对象存储的ACL是不是公开读写？RDS是不是开启了Public Access？ |
核心要点：攻击面不是静态的。你上线一个新服务、开一个安全组规则，攻击面就在变。所以我建议至少每周做一次自动化暴露面扫描。
3.2 资产枚举：把家底翻个底朝天
攻击面分析是“找漏洞”，资产枚举是“找资产”。没有后者，前者就是瞎蒙。
你想想看，如果你的一个离职员工手上还有AK/SK，这个AK能列出所有的S3桶内容。你光盯着CVE打补丁有什么用？那个AK本身就是个巨大暴露面。
资产枚举，说白了就是回答三个问题：
- 有什么？——所有云资源、子域名、API、账号
- 在哪？——属于哪个Region、VPC、项目组
- 谁在用？——关联的IAM身份、服务角色、外部集成
3.2.1 动手：枚举云上资产
我用AWS举个例。假设你有个账号，想看看所有的存储服务暴露情况。手工点控制台太慢，我建议走CLI：
# 1. 先枚举所有S3桶，看看哪个是Public的
aws s3api list-buckets --query "Buckets[].Name"
# 2. 查看某个桶的公开状态
aws s3api get-bucket-acl --bucket your-bucket-name
# 3. 枚举所有RDS实例，抓重点：PubliclyAccessible字段
aws rds describe-db-instances \
--query "DBInstances[?PubliclyAccessible==`true`].[DBInstanceIdentifier,Endpoint.Address]"
# 4. 看看安全组开了哪些公网端口
aws ec2 describe-security-groups \
--filters Name=ip-permission.cidr,Values="0.0.0.0/0" \
--query "SecurityGroups[].[GroupName,IpPermissions[].FromPort]"我之前有个客户，用这套命令一跑，发现三个RDS实例的PubliclyAccessible是true。一问，全是开发人员为了“本地调试方便”开的。嗯，还好发现的早。
3.2.2 别忘了“影子资产”
避坑指南：我曾经在一个项目里，翻遍了主账号的所有资源清单，都觉得没问题。结果后来通过DNS枚举发现一个 log-collector.staging.internal 解析到了公网IP——那是某位工程师用一个废弃的个人账号创建的EC2，上面跑着一个没认证的Logstash，里面全是用户行为日志。
这种资产，你从主账号永远查不到。它叫影子资产。
怎么抓影子资产？我给你三个方向：
- DNS枚举：用工具（比如Amass、Subfinder）枚举所有关联域名和子域名，找到那些没在资源清单里的记录。
- 凭证泄漏扫描：在GitHub、Pastebin上搜你的域名或关键桶名，看看有没有暴露的AK/SK或内网地址。
- 云API调用日志：在CloudTrail里找
SourceIP为公网IP、但UserAgent明显是SDK/CLI的调用——这些往往是没被管住的“野生”服务。
3.3 一张图看懂：暴露面识别流程
上面说了那么多，我把整个逻辑画成一张流程框架图。这张图是我自己梳理的，每次做新项目审计都按照这个节奏走，基本不会漏。
3.4 工具链推荐：自动化你的暴露面扫描
手工枚举一次还行，每周都这么搞肯定不现实。所以一定要用工具，我把自己常用的几个列出来：
| 工具 | 定位 | 我拿它做什么 |
|---|---|---|
| CloudSploit / ScoutSuite | 云配置审计 | 一键扫描S3公开桶、安全组过度放行、未加密存储 |
| Amass / Subfinder | 子域名枚举 | 找到那些不在资源清单里的“野生”子域名和公网服务 |
| Nmap / Masscan | 端口扫描 | 验证云上公网IP到底开了哪些端口，是不是应该关 |
| Prowler | CIS基线检查 | 对照最佳实践，看看你的IAM、日志、监控有没有缺漏 |
| Custom脚本（Python + Boto3） | 定制化枚举 | 把上面几步串起来，每天跑一遍，出报告发邮件 |
一个小技巧：你可以在CloudTrail里建一个异常暴露面告警。比如，当有人创建了一个新的安全组并且规则包含 0.0.0.0/0 时，立刻通过SNS通知你。这样你就不用等到周报才发现问题。
3.5 总结：思路比工具重要
到了这一步，你应该能回答：我的数据到底暴露在哪？
最后说一句掏心窝子的话——工具再好，如果不清楚自己有什么资产，不搞清楚数据的流转路径，那就是在瞎忙。我见过很多团队买了几十万美元的CASB、CSPM，结果连自己有多少个公网ELB都数不清楚。你说这钱花得冤不冤？
所以，从今天开始，别急着重金上工具。先把你现有的账号、资源、API、DNS记录翻个底朝天。把暴露面摸清楚，你的钱才能花在刀刃上。