资产发现方法论概述
资产发现，说白了就是回答三个问题：我们有什么？在哪里？跑了什么？
我刚开始接触DSPM项目时，总以为装个扫描器跑一圈就完事了。后来发现，事情远没那么简单。一份真实的资产清单，背后藏着方法论的选择和博弈。
三种核心发现方法
我个人习惯把资产发现方法分成三类。它们各有长短，适用场景也不一样。
| 方法 | 原理 | 优势 | 短板 |
|---|---|---|---|
| API驱动 | 调用云平台/应用的开放接口 | 数据精准，带元数据 | 依赖接口权限 |
| 主动扫描 | 发送网络探测包 | 覆盖广，不依赖平台 | 可能影响业务 |
| 被动监听 | 旁路抓包分析流量 | 零打扰，发现影子资产 | 无法发现静默资产 |
API驱动发现
这是我最推荐的方式，也是大厂的首选。
原理很简单：云厂商或应用系统会提供管理API。你调用它，它就把资产列表吐给你。数据很干净，带标签、带配置、带状态。
我在项目中遇到过一个问题。某次调用AWS的EC2 DescribeInstances接口，返回了几千台实例。但仔细一看，有三分之一是关机状态。这些真的算活跃资产吗？
实际操作中，我习惯这么配置：
- 使用服务账号，权限最小化（只读优先）
- 设置分页参数，避免接口超时
- 记录每次请求的时间戳，做增量同步
# 伪代码示例：AWS EC2资产发现
import boto3
client = boto3.client('ec2')
response = client.describe_instances(
Filters=[
{'Name': 'instance-state-name', 'Values': ['running', 'stopped']}
],
MaxResults=200
)
# 处理分页逻辑...主动扫描发现
如果目标环境没有API可用，或者你想验证一下API的完整性，就得用主动扫描。
说白了，就是往IP段发包，看看谁在回应。Nmap是最常用的工具，但我不建议在生产环境直接上全端口扫描。
嗯，这里要注意。主动扫描会产生流量，可能触发安全设备的告警。我曾经在客户的环境里做了一次全端口扫描，结果人家SOC电话直接打过来了，场面一度很尴尬。
我建议的扫描策略是这样的：
- 先做Ping扫描（ICMP/TCP Ping）
- 筛选出存活主机
- 对存活主机做常见端口扫描
- 如果必要，再做服务版本识别
# 快速存活探测
nmap -sn -T4 10.0.0.0/24 --exclude 10.0.0.1
# 服务探测
nmap -sV -p 22,80,443,3306,6379 10.0.0.2-10方法各有适用场景。我记得有一次，API显示只有20台数据库。但我用主动扫描发现了一个隐藏的Redis实例，端口是6379，没有绑在API里。这就是互补的价值。
被动监听发现
这种方法我个人觉得最优雅，因为它不打扰任何人。
原理是旁路部署一个探针，抓取网络流量。从流量里解析出资产信息：IP、MAC、协议、端口、甚至应用层的数据。
它特别擅长发现那些你根本不知道在跑的东西。比如某位同事偷偷搭了一个GitLab，或者某个测试环境没关。
但也有限制。如果资产不说话（没有流量），你就是监听一年也发现不了它。这就是为什么我强调三种方法要混合使用。
完整流程：从获取到盘点
光有方法还不够，你得有一套完整的流程来支撑。我个人习惯分成五步：
- 获取：通过API/扫描/监听拿到原始数据
- 清洗：去重、补全、过滤噪声
- 归类：按类型/环境/负责人分门别类
- 标记：打上标签（敏感度、重要性、合规域）
- 同步：将结果写入资产库，并推送变更事件
这里还有一个容易被忽略的点：持续发现。资产不是静态的，今天发现的明天可能就变了。我建议至少保持天级全量同步，小时级增量同步。
好了，方法论讲完了。你可能会问：这三种方法到底怎么配合？
嗯，我整理了一张图，你可以看看它们的关系。
你看，API是主力，扫描是补充，监听是兜底。三者配合，才能做到真正的全面覆盖。
我个人最推荐的组合是：API为主，主动扫描为辅，被动监听做兜底。这样既保证了效率，又不会遗漏暗处的资产。