数据映射与分类分级：从资产盘点到落地实操
说实话，数据隐私合规这件事，最怕的就是「不知道自己有什么数据」。我见过太多项目，上来就谈GDPR、谈PIPL，结果一问数据在哪、谁在用、怎么流转的，全员沉默。嗯，这就是我们今天要聊的核心——数据映射与分类分级。
我个人习惯把这件事分成三步走：先盘点、再画图、后分级。别嫌麻烦，这三步走扎实了，后面的合规工作才能站得住脚。
一、数据资产盘点：别让数据「黑盒化」
数据资产盘点，说白了就是搞清楚你手里到底有什么牌。我在项目中遇到过最典型的情况：业务部门说「我们没存用户手机号」，结果一查数据库，字段名叫user_phone，存得明明白白。为什么会这样？因为很多公司对数据的认知是割裂的。
盘点的核心目标有三个：
- 摸清家底：哪些系统、哪些数据库、哪些文件服务器存了数据
- 识别敏感数据：身份证、手机号、生物识别信息、金融账户等
- 明确数据责任人：谁对这个数据集负责？谁有访问权限？
盘点时常用的字段清单，我整理了一个模板：
| 字段类别 | 示例字段 | 敏感级别 |
|---|---|---|
| 个人身份信息 | 姓名、身份证号、护照号 | 高敏感 |
| 联系方式 | 手机号、邮箱、家庭地址 | 高敏感 |
| 生物识别信息 | 指纹、人脸特征、虹膜 | 极高敏感 |
| 行为数据 | 浏览记录、搜索历史、点击流 | 中敏感 |
| 设备信息 | IMEI、MAC地址、设备型号 | 中敏感 |
二、数据流图绘制：让数据「可视化」
盘完资产，下一步就是画数据流图。你想想看，数据从用户那里收集进来，经过哪些系统、被谁处理、存到哪里、最后怎么删除的？画出来，一目了然。
我建议用DFD（数据流图）的方式，别搞太复杂。核心要素就四个：
- 外部实体：用户、第三方API、合作伙伴
- 处理过程：注册、登录、支付、数据分析
- 数据存储：MySQL、Redis、HDFS、S3
- 数据流：箭头表示数据流向，标注传输协议和加密方式
避坑指南：我曾经在一个项目中，数据流图画了三个版本才通过合规评审。第一个版本漏掉了日志系统——用户行为数据被记录到ELK里，但没人意识到这也算「处理个人信息」。所以画图时，日志、备份、测试环境这些「灰色地带」一定要覆盖到。
画图工具方面，我个人习惯用draw.io或者Lucidchart，免费且支持导出。如果团队有合规平台，也可以用OneTrust或TrustArc内置的数据映射模块。
三、数据分类分级标准：ISO 27701 怎么落地？
分类分级这件事，很多公司喜欢自己拍脑袋定标准。但我建议直接参考ISO 27701，它是ISO 27001在隐私信息管理上的扩展，框架成熟，也容易被审计认可。
ISO 27701的核心思路是：根据数据对个人权益的影响程度来分级。我一般会拆成四个级别：
- L1 公开数据：企业公开信息、已脱敏的统计数据。风险极低。
- L2 内部数据：员工工号、部门信息。泄露影响有限。
- L3 敏感数据：手机号、邮箱、地址。泄露可能导致骚扰或诈骗。
- L4 高度敏感数据：身份证、金融账户、生物识别、医疗健康。泄露可能造成严重人身或财产损失。
注意：分级不是一成不变的。同一个字段，在不同场景下敏感度可能不同。比如「手机号」在营销场景下是L3，但如果用于二次验证或支付，就应该升到L4。我建议每半年重新评估一次分级标准。
分类方面，ISO 27701建议按数据类别来分：
- 个人身份信息（PII）
- 敏感个人信息（SPI）
- 行为数据
- 设备数据
- 财务数据
- 生物识别数据
每个类别再对应到具体的业务场景。比如「生物识别数据」在考勤系统和支付系统中，处理方式完全不同。
四、实操工具介绍：别光说不练
理论讲完了，来点实在的。我这些年用过不少工具，挑几个我觉得靠谱的说说：
| 工具名称 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| OneTrust | 数据映射、DSAR、Cookie管理 | 功能全面，支持自动化扫描 | 价格贵，小团队慎入 |
| TrustArc | 隐私影响评估、合规管理 | 模板丰富，审计友好 | 学习曲线陡 |
| BigID | 数据发现、分类分级 | AI驱动，能自动识别敏感字段 | 部署复杂 |
| Privitar | 数据脱敏、隐私保护 | 支持动态脱敏，性能好 | 偏数据工程，合规功能弱 |
| 开源方案：Apache Atlas + Ranger | 数据血缘、访问控制 | 免费，可定制 | 需要自己搭，维护成本高 |
如果你团队预算有限，我建议先从开源方案入手。我自己在早期项目里就用Apache Atlas做数据血缘，配合Apache Ranger做访问控制，虽然配置起来有点折腾，但胜在灵活。
举个简单的例子，用Atlas标记敏感字段：
// 通过Atlas REST API创建分类
POST /api/atlas/v2/types/typedefs
{
"classificationDefs": [{
"name": "PII_Sensitive",
"description": "个人敏感信息",
"superTypes": ["PII"],
"attributeDefs": []
}]
}
// 将字段标记为敏感
PUT /api/atlas/v2/entity/guid/{entity_guid}/classification
{
"classification": {
"typeName": "PII_Sensitive"
}
}
嗯，代码看着简单，但实际落地时要注意：分类的粒度。我见过有人把整个表标记为「敏感」，结果导致所有查询都走审批，业务直接瘫痪。正确的做法是字段级标记，比如只标记id_card和phone，其他字段正常访问。
五、总结一下
数据映射与分类分级，说白了就是先知道自己有什么，再知道它有多重要，最后知道怎么管。这三件事做扎实了，后面做隐私影响评估、制定数据保留策略、响应数据主体请求，都会轻松很多。
我记得有一次帮一家金融科技公司做合规改造，他们之前完全没做过数据映射，结果被监管问询时连数据存储位置都说不清楚。后来我们花了两周时间，用OneTrust跑了一遍全量扫描，再配合人工梳理，终于把数据地图画出来了。从那以后，他们每季度都会做一次增量盘点。
最后送大家一句话：数据映射不是一次性工程，而是持续运营的过程。别想着「做完就完事」，业务在变、系统在变、法规也在变，定期更新才是王道。