隐私保护基础：数据生命周期、敏感数据识别、隐私威胁模型

不管做哪种隐私保护技术，底层逻辑都绕不开三个东西：数据在哪、什么数据是敏感的、谁可能来搞它。我做了几年隐私工程，发现很多团队一上来就堆技术，结果漏了基础，方案要么过设计要么漏风。今天把这三个基础说透。

数据生命周期——隐私保护的时空坐标系

数据从产生到销毁，每个阶段都有不同的隐私风险。我个人习惯把生命周期分成六个阶段：

• 创建/采集——APP 弹窗、表单填写、传感器收集。踩过坑：采集阶段没做最小化，后面清洗怎么都清不干净。
• 存储——数据库、对象存储、日志。核心原则：存储位置和加密策略必须和数据分类挂钩。
• 使用——模型训练、报表查询、业务 API 调用。这里最容易出内部泄露。
• 共享——第三方接口、跨部门流转。共享前必须做脱敏或差分隐私。
• 归档——冷数据存储。经常被遗忘，一旦泄露就是批量事故。
• 销毁——物理删除、覆写、消磁。有人只删了索引文件，数据还在原地。

你想想看，tokenization 主要在「使用」和「共享」阶段发挥作用，把原始令牌换成无意义的 。但前提是你得知道前几个阶段里，哪些字段必须保护。

敏感数据识别——你不找到它，怎么保护它？

识别敏感数据其实是一场分类分级工程。我见过最夸张的案例：公司把生日、身份证、手机号全塞进一张表，还只用了明文 varchar。那时候我就在想，隐私工程第一步应该是做好元数据管理。

常见的敏感数据类型包括四大类：

类别	典型字段	风险等级
个人身份信息 (PII)	姓名、身份证号、地址	高
财务信息	银行卡号、交易记录	极高
健康信息	病历、基因数据	极高
凭证/令牌	密码、会话 、	极高
行为轨迹	GPS、浏览历史	中高

识别方法我推荐三步走：

1. 自动扫描：用正则/ NLP 工具识别常见模式（如身份证 18 位、信用卡 Luhn 校验）。
2. 人工标注：业务方确认字段的业务含义，尤其是自定义字段名（比如叫 user_extra 实际存了手机号）。
3. 自动分类：打上标签，比如 pii_level、financial_flag，然后写入数据字典。

隐私威胁模型——你得知道对手在哪儿

隐私威胁不能只防外部黑客。我经历过一次内部审计，发现一个开发小哥在测试环境直接查了生产库的明文身份证。他不恶意，但风险实实在在。所以威胁模型必须同时覆盖内部和外部攻击者。

攻击者类型	典型场景	核心风险
外部攻击者	SQL 注入、API 滥用、数据泄露后批量爬取	批量获取原始敏感数据，直接造成合规罚款
内部恶意员工	有权限的员工未经授权导出数据、卖给黑产	数据源可信，难以通过技术完全阻止
内部无意泄漏	错误配置 S3 桶、日志打印敏感字段	往往可被外部发现，且存在时间窗口
合作伙伴/第三方	接入 API 后过度缓存、二次转售	法律边界模糊，技术控制难

怎么建模？我个人习惯用 STRIDE 维度的简化版：

• Spoofing（冒充）：攻击者伪装成合法用户获取数据。
• Tampering（篡改）：内部人员修改 映射表。
• Repudiation（抵赖）：访问日志不完整，事后无法追溯。
• Information Disclosure（信息泄露）：典型威胁，也是最直接的隐私伤害。
• Denial of Service（拒绝服务）：针对 服务的 DDoS。
• Elevation of Privilege（权限提升）：比如测试用户通过未授权接口拿到生产级 映射。

每个威胁都要绑定一个生命周期阶段。比如「信息泄露」在存储阶段对应数据库泄露，在使用阶段对应模型反推，在共享阶段对应 API 泄露。

三者关系：一张图讲清楚

数据生命周期是时间线，敏感数据识别是定位线，威胁模型是攻击面。三者交织成隐私保护的设计依据。下面这张图能帮你快速建立整体框架：

这个框架图不是画着好看的。实际做合规方案时，我习惯拿它当检查清单：每个阶段对应哪些敏感字段，每个字段又对应哪些威胁。缺一个，补一个。