4、数据资产发现（上）：自动发现技术原理与支持的数据源
说到数据资产发现，很多团队一上来就问我：“薛工，有没有一把梭的扫描器？扫一遍全出来？”我每次的回答都一样——没有银弹。数据资产发现从来不是单一技术能搞定的活儿，它得是三种技术路线混合着来。
这一章我们先讲清楚自动发现的技术原理，以及它覆盖的数据源类型。你搞明白了底层逻辑，后面部署的时候才知道什么时候该用扫描，什么时候该接API，什么时候必须装Agent。
4.1 三大技术路线：网络扫描、API对接、Agent采集
自动发现的核心，说白了就是怎么把藏在你网络里、云上、SaaS里的数据资产给找出来。我个人习惯把技术路线分成三类，每一类的适用场景和局限都很鲜明。
4.1.1 网络扫描
网络扫描是最直接的手段。你想想看，只要发一个探测包出去，就能知道目标端口开没开、服务是什么类型。我们在DSPM里用网络扫描，主要是为了解决“黑盒环境”下的资产摸底。
核心原理： 通过发送TCP/UDP探测报文，根据响应特征识别主机、端口、服务类型及版本。
典型扫描场景：
- 内网/外网暴露面梳理：快速找到哪些IP在开放数据库端口，比如3306（MySQL）、5432（PostgreSQL）
- 设备指纹采集：获取OS、数据库版本、中间件类型
- 非授权部署探测：发现未在CMDB里登记的“影子服务”
我在项目中发现，网络扫描其实是个“快但浅”的手段。它能告诉你那个IP开了一个MySQL服务，但它读不到表名、列名、分区信息，更别提里面存了哪些敏感数据。所以网络扫描最适合做前置摸底——先把资产清单从0做到1。
我的一个小习惯：做网络扫描之前，一定先跟网络团队确认哪些IP段不能碰。曾经有个同事没打招呼就扫了核心交换机的管理口，结果整个下午都在写事故报告。嗯，这是真事。
4.1.2 API对接
API对接是让DSPM平台通过云平台、数据库管理平台、SaaS服务商的管理API来获取元数据。这是三种技术里信息量最大的方式。
为什么我更推荐API？ 因为它拿到的不是“端口开放”这种粗糙信号，而是结构化的元数据：数据库实例列表、Schema结构、表分区、访问权限、加密状态等等。
我曾经在某个金融客户那里做过对比：同一个数据库，网络扫描只能看到“MySQL 8.0.27 on 10.0.0.18:3306”；通过云平台的RDS API，却能直接拿到该实例下128张表的建表DDL、行数预估、以及最近30天的慢查询记录。差距不是一星半点。
| 对比维度 | 网络扫描 | API对接 |
|---|---|---|
| 信息深度 | 浅（端口/服务/版本） | 深（Schema/表/字段/权限） |
| 效率 | 高（秒级出结果） | 依赖API限频和并发控制 |
| 局限性 | 无法获取元数据 | 需要云平台或数据库管理侧开放API |
| 典型实现 | Nmap + 指纹库 | RESTful / SDK / 数据库驱动 |
4.1.3 Agent采集
Agent是部署在主机或数据库服务器上的轻量级程序。它通过操作系统的进程快照、数据库的连接池元数据、文件系统扫描来获取资产信息。
Agent能干哪些事？
- 数据库层级：直接通过驱动连上去，执行
SHOW DATABASES、SELECT table_schema, table_name FROM information_schema.tables - 文件系统级：扫描数据目录下的文件类型、大小、最后修改时间
- 进程级：监控当前正在运行的数据服务进程、连接数、资源消耗
注意：Agent部署是有侵入性的。有些生产环境不允许装任何第三方Agent，或者对性能开销很敏感。我个人习惯给客户画一个决策树：如果环境开放API优先用API；如果无法开放API且能管控主机，才上Agent。
4.2 支持的数据源类型
数据源的类型决定了你该用哪种发现技术。我见过最惨的翻车现场，就是用网络扫描去扫SaaS应用——人家SaaS根本不在你的网段里，扫个寂寞。
4.2.1 关系型数据库
这块是DSPM的重头戏。几乎每个客户的核心数据都在关系库里，不管是自建的MySQL/PostgreSQL，还是云上的RDS、Aurora。
自动发现能拿到什么？
- 实例级：版本号、运行状态、字符集
- Schema级：库名、表名、列名、数据类型
- 字段级：字段长度、是否可空、默认值、主外键
- 权限级：每个用户对哪些表有什么权限
避坑指南（我曾踩过的坑）： 用API发现数据库的时候，一定要特别注意并发连接数限制。有大平台的RDS API在不加限流的情况下，单次Call返回的元数据量能高达几百MB，直接把DSPM平台的内存打满。后来我做了两层处理：一是按分页分批拉取，二是把元数据转存到队列里异步处理。
4.2.2 对象存储
对象存储（AWS S3、阿里云OSS、华为云OBS）是另一个数据重灾区。我见过有些企业把客户CSV、PDF、甚至日志明文都往S3桶里丢，结果桶的ACL是公开读。
对象存储的发现难点：
- 它不是“数据库”，你需要通过API去列举桶、目录、对象
- 对象的元数据字段很有限（Key、Size、ETag、LastModified），没有Schema概念
- 扫描所有对象的时间成本和API费用都很高
我建议的做法是：先通过API枚举所有桶和顶层目录，然后采样扫描。比如每个目录取前100个对象，检查文件类型和大小分布。真有敏感文件，后面再做深度内容扫描。不要一上来就拉全量，不然S3的账单能让你哭。
4.2.3 SaaS应用
SaaS应用（Salesforce、飞书、钉钉、Jira、GitHub等）是自动发现里最特殊的一类。它们的数据不在你网络里，也不在你主机上，而是存在SaaS厂商那边。
我处理SaaS应用发现的套路是：
- 先确认该SaaS是否提供元数据导出API（比如Salesforce的Describe Global API）
- 把SaaS当作“外部数据源”注册到DSPM平台里
- 通过OAuth2.0授权后，定时拉取对象定义、字段列表、权限模型
举个例子，你如果想发现飞书文档里的敏感信息，不能写个爬虫去扫，必须通过飞书开放平台的文档API，获取文档元数据（标题、创建者、权限范围），然后对文档内容做异步的敏感信息匹配。
一个小经验：SaaS应用的API一般都有严格的调用额度（Rate Limit）。你最好在DSPM里设计一个适配器模式：每个SaaS写一个独立的adapter，里面封装了限流、重试、断点续传的逻辑。这样就算SaaS API改了，也只动adapter，不动核心引擎。
4.3 知识体系框架图
下面这张图概括了本章讲的核心知识点：数据源类型、对应的发现技术、以及它们能获取的信息层级。你可以把它当作后续部署DSPM的选型参考。
4.4 小结
这一章我们把自动发现的三驾马车讲透了：网络扫描负责“找得到”，API对接负责“拿得全”，Agent采集负责“挖得深”。数据源方面，关系型数据库、对象存储、SaaS应用各有各的脾气，你选对技术路线就是成功的一半。
我个人对本章最后想强调一点：不要追求一步到位。你哪怕先只部署网络扫描+API对接，跑出来一份粗略的资产清单，也比什么都强。等团队跑顺了，再逐步往里面加Agent和SaaS适配器。先立后破，工程化落地的铁律。