数据发现与扫描技术：你的敏感信息到底藏在哪？
好，我们开始第三章。前两章我们聊了“为什么要做”和“整体策略怎么搭”。这一章，咱们落地到具体操作——怎么把那些藏在犄角旮旯的敏感数据，一个一个揪出来。
很多人觉得数据扫描嘛，装个工具跑一遍就行。我刚开始也这么想。直到有一次项目复盘，发现数据库里躺着几万条明文身份证号，而扫描报告居然显示“无风险”。为什么？因为规则没配好，扫描范围也没覆盖全。你想想看，这后果有多严重。
3.1 扫描的核心思路：你在找什么？
数据发现不是瞎扫。你得先搞清楚：敏感信息的定义是什么？我个人习惯把它分成三类：
- 结构化数据：数据库表里的身份证、手机号、银行卡号。这类最好找，格式固定。
- 半结构化数据：JSON、XML、日志文件里的敏感字段。比如一个订单接口的请求日志，里面可能直接带着用户姓名和地址。
- 非结构化数据：Word、PDF、图片里的文字内容。嗯，这块最难搞。我在一个政府项目中遇到过，几十万份扫描版PDF，里面全是手工填写的表格，OCR识别率只有七成。
关键认知：扫描策略要按数据形态来分层设计。不要指望一套正则走天下。
3.2 自动扫描技术：三管齐下
实际落地中，我会同时部署三条扫描链路。说白了，就是“网络嗅探 + 数据库探测 + 文件系统爬取”。
3.2.1 网络扫描：先摸清家底
你连自己内网有多少台机器、跑了什么服务都不清楚，怎么扫？网络扫描是第一步。常用的手段有：
- 端口扫描：判断开放了哪些服务（MySQL、MongoDB、SMB）。
- 协议嗅探：抓取明文传输的敏感数据包。我在一次渗透测试中，发现某OA系统居然用HTTP传输员工工资条邮件……
- 指纹识别：识别数据库类型、版本号，为下一步的深度扫描做准备。
小技巧：网络扫描建议放在业务低峰期跑，避免影响生产环境。我曾经凌晨三点爬起来调扫描参数，就为避开日间流量高峰。
3.2.2 数据库扫描：深挖数据池
这是大头。数据库里存着最有价值也最容易被忽略的敏感字段。我的做法分三步：
第一步：元数据采集
先拉出所有表结构、字段名、注释信息。很多时候，字段叫id_card、phone_no，那基本八九不离十了。
第二步：内容匹配
用正则表达式去匹配实际数据。给你个常用规则示例：
# 身份证号（18位，含校验规则）
^[1-9]\d{5}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$
# 手机号（中国大陆）
^1[3-9]\d{9}$
# 银行卡号（16-19位数字）
^\d{16,19}$
# 电子邮箱
^[\w\.-]+@[\w\.-]+\.\w+$注意啊，规则不是越复杂越好。我曾经见过一个团队写了300多条正则，结果扫描一列“生日”字段（格式YYYY-MM-DD），误报率高达40%。后来精简到20条核心规则，准确率反而上去了。
第三步：样本抽样验证
全量扫描太费资源。我建议用分层抽样，比如每张表取前1000行，或者按数据分布随机抽取5%的样本。扫出来之后人工复核一批，确认规则是否靠谱。
| 数据来源 | 常用扫描手段 | 典型耗时（1TB数据） | 误报率 |
|---|---|---|---|
| MySQL/PostgreSQL | JDBC连接 + 正则匹配 | 2-4小时 | 中等 |
| MongoDB | BSON解析 + 字段遍历 | 1-3小时 | 较低 |
| HDFS/Hive | MapReduce并行扫描 | 0.5-1小时 | 较低 |
| 非结构化文件（SMB/NFS） | 文件遍历 + 内容提取 | 6-12小时 | 较高 |
3.2.3 文件系统扫描：别漏了“暗角”
文件系统是数据泄露的重灾区。很多人只盯着数据库，却忘了共享文件夹、FTP目录、个人工作目录里那些陈年老文件。
文件扫描要考虑几个难点：
- 文件格式多样性：.docx、.pdf、.xlsx、.txt、.csv，每一种的解析方式都不一样。
- 压缩包嵌套：一个.zip里面套着.rar，.rar里面还藏着加密过的.7z……我曾经在一个项目的共享目录里，找到过一个名为“2023年备份.zip”的压缩包，解压之后发现里面是整库明文导出的员工数据。这要是流出去，后果不敢想。
- 图片中的文字：需要OCR支持。但准确率没法100%保证，所以我的策略是：先扫出可能是敏感文件的图片，再人工标注。
避坑指南：文件扫描一定要设置“深度限制”。我曾经不小心把扫描器指向了系统根目录，结果它开始递归解析/dev、/proc这些虚拟文件系统，直接导致扫描Agent卡死。教训是：提前排好白名单路径。
3.3 扫描策略与调度：别让扫描变成“攻击”
扫描本身是有风险的。大流量、频繁I/O操作，可能会拖垮业务数据库。我的建议是：
- 分级扫描：核心生产库只做元数据扫描，内容匹配放到备用库或离线副本上做。
- 限速+限流：设置扫描速率，比如每小时不超过10万行记录。
- 时间窗口：固定凌晨2点到6点跑全量扫描，白天只做增量变更扫描。
下面这张图，是我在实际项目中总结的扫描流程。你可以把它当成你的标准作业程序（SOP）来参考。
3.4 常用的开源与商业工具
工具这块，我简单列几个用得比较多的，不展开讲细节，但你至少要了解它们各自擅长什么：
| 工具/平台 | 主要能力 | 适用场景 |
|---|---|---|
| Regex-based Scanner（自研） | 灵活定制正则规则，轻量级 | 适用于单一数据库或文件系统的快速扫描 |
| Apache Tika | 支持数百种文件格式的内容提取 | 非结构化文件的文本解析 |
| Tesseract OCR | 开源OCR引擎，可集成到扫描流程 | 图片/扫描件中的文字识别 |
| 商业DLP扫描器（比如Symantec、McAfee） | 一体化管理、策略联动、事件告警 | 大型企业合规项目，需要报表和审批流 |
一个血的教训：我曾经在一个客户现场，直接用tesseract跑100万张图片的OCR扫描。结果跑了三天三夜，服务器CPU烧到80度，最后发现一半图片都是空白页。从那以后，我坚持先做元数据筛选——先判断文件中是否包含足够多的文本块，再决定要不要丢进OCR管道。
3.5 避坑与最佳实践
最后，我把自己踩过的坑结个总，给你提个醒：
- 别扫描“影子数据”：开发环境、测试环境、个人桌面这些“暗角”，优先级反而要高于生产环境。因为攻击者最喜欢从这些防守薄弱的地方切入。
- 扫描结果要有“可行动性”：别只给一堆IP和字段名。你要标注出：风险等级、数据量大小、建议的加密/脱敏手段。老板要看的是“怎么做”，不是“哪里有问题”。
- 定期增量扫描：数据是活的。今天扫完，明天新增的表怎么办？我建议部署定时任务，每天凌晨对变更过的表做增量扫描。
数据发现这一步做得越扎实，后续加密策略的配置就越有底气。别偷懒，也别贪快。磨刀不误砍柴工，说的就是这个道理。