数据映射与流分析：数据流图绘制、数据血缘追踪、数据存储与传输路径识别

好，咱们进入第三个核心章节。数据映射与流分析，说白了就是搞清楚一件事：你的数据到底在哪儿、怎么流动、谁碰过它。CCPA合规不是靠嘴说“我们保护用户数据”就完事的，你得拿出证据。证据从哪来？就从数据流图、血缘追踪和路径识别里来。

我做过不少合规审计项目，见过最惨的情况是——公司被问“你们用户手机号存哪儿了”，CTO愣是答不上来。嗯，这其实挺常见的。所以今天咱们就把这块彻底讲透。

数据流图（DFD）不是画着好看的。它是你和审计人员沟通的通用语言。我个人习惯用分层DFD，从宏观到微观，逐层细化。

这一层只画一个系统框，外面是外部实体（用户、第三方API、合作伙伴）。箭头表示数据进出。说白了，就是告诉别人：我们的系统跟外界交换了哪些数据。

关键点：上下文图里，每个箭头都要标注数据类型。比如“用户手机号”、“支付记录”、“Cookie标识符”。别只写“用户数据”，太模糊了，审计会追问的。

把系统拆成主要功能模块。比如用户注册模块、订单处理模块、数据分析模块。每个模块之间怎么传数据，画清楚。

我在项目中遇到过一个问题：团队画DFD时，只画了正常流程，忘了画异常路径。比如用户注销后，数据到底删没删？备份里还有没有？这些不画出来，合规审计一查一个准。

这一层深入到数据库、缓存、消息队列。你要标出每个存储节点的数据类型、保留期限、加密状态。

我的小技巧：用不同颜色区分数据类型。红色代表敏感个人信息（如身份证号），黄色代表一般个人信息（如用户名），绿色代表匿名化数据。一眼就能看出风险点在哪。

数据血缘，就是数据的“族谱”。从采集、加工、存储到销毁，每一步都要能追溯。CCPA要求企业能回答“这个用户的画像数据是怎么生成的”，血缘追踪就是答案。

要素	说明	我的经验
数据源	原始数据从哪来（用户输入、第三方、埋点）	注意区分一手数据和衍生数据
转换逻辑	数据经过哪些ETL、聚合、脱敏操作	我曾经漏掉一个数据脱敏步骤，结果审计发现原始数据还在日志里
存储位置	数据最终落在哪个库、哪个表、哪个字段	别只写“MySQL”，要精确到库名和表名
访问记录	谁在什么时间、什么IP、什么操作	这是审计最常查的，一定要有日志

方式一：手动标注。适合小团队，在数据字典里手动记录每个字段的来源和去向。优点是简单，缺点是容易遗漏。

方式二：自动化工具。比如Apache Atlas、DataHub、OpenMetadata。这些工具能自动解析SQL、ETL脚本，生成血缘图。我建议中大型团队直接用工具，别省这个钱。

注意：自动化工具不是万能的。它们对存储过程、自定义UDF的支持往往不好。我曾经在一个项目里，工具死活解析不了某个复杂的PL/SQL函数，最后只能手动补全。所以，工具+人工审核才是王道。

数据存储和传输，是CCPA合规的两个重灾区。为什么？因为数据一旦离开你的控制范围，风险就指数级上升。

你想想看，一个用户的手机号，可能同时存在于主库、缓存、日志、备份、数据分析平台。每个地方都要有合规措施。我见过最离谱的是，某公司把用户身份证号明文存在S3桶里，桶权限还是公开的。嗯，这基本等于把用户信息贴在大街上。

数据传输分两种：内部传输和外部传输。

内部传输：服务间调用、数据库主从同步、消息队列。重点检查是否用了TLS加密。我建议所有内部通信都默认加密，别信“内网安全”这种鬼话。

外部传输：API接口、第三方SDK、合作伙伴数据交换。这里要特别注意：数据出境的合规要求。CCPA虽然主要是加州法律，但如果你把数据传输到加州以外的服务器，同样要满足相应法规。

实战建议：画一张“数据传输矩阵图”。横轴是数据源，纵轴是目标端，交叉点标注传输协议、加密方式、是否跨境。这张图在合规审计时能省你很多解释时间。

坑一：只画了生产环境，忘了测试环境。测试环境的数据往往是生产数据的脱敏副本，但脱敏不彻底的话，同样违规。我曾经在测试库发现了完整的用户地址数据，吓得赶紧补了脱敏流程。
坑二：数据流图不更新。系统架构变了，数据流图还是半年前的。审计一看就知道你管理混乱。我建议每季度至少更新一次数据流图。
坑三：忽略第三方依赖。你用了某个第三方SDK，它把你的数据传到了哪里？你根本不知道。CCPA要求你对第三方数据处理行为负责。所以，签合同前一定要审查第三方的数据处理协议。

好了，数据映射与流分析这块，核心就是三件事：画清楚、追得回、管得住。下一章咱们会讲如何把这些分析结果落地成具体的控制措施。先消化一下，有问题随时问。