3. 数据隐私基础：敏感数据识别、分类与生命周期管理
做隐私增强网关，第一步不是搭架构，而是搞清楚：你到底在保护什么？
说白了，你连哪些数据是敏感的都搞不清楚，后面的加密、脱敏、审计全是瞎忙活。我记得刚接手一个金融项目时，团队上来就搞动态脱敏，结果上线第一天就发现——他们把业务员的工号当成身份证号给脱了，真正的信用卡号全裸奔。嗯，这就是识别没做好的下场。
3.1 敏感数据的定义与识别
什么样的数据算“敏感”？范围比你想的宽得多。
| 类别 | 典型字段 | 泄露后果 |
|---|---|---|
| 个人身份信息 (PII) | 身份证号、姓名、手机号、家庭住址 | 身份盗用、诈骗 |
| 金融数据 | 银行卡号、信用卡CVV、交易记录 | 经济损失、合规罚款 |
| 健康数据 | 病历、诊断结果、基因信息 | 隐私侵犯、法律诉讼 |
| 商业机密 | 源代码、客户名单、定价策略 | 竞争力丧失、商业损失 |
| 设备/网络标识 | IP地址、MAC地址、设备指纹 | 跟踪监控、精准攻击 |
识别这些字段，靠人工翻数据库肯定不现实。我建议用正则表达式加上样本数据扫描。比如身份证号是18位数字，信用卡号是16位，这些都有现成的模式。但要注意——不能光看格式，还要结合上下文。
3.2 数据分类标准与等级体系
数据识别出来了，接下来要分级。分几级？怎么做？
我个人习惯用四象限法，从“敏感性”和“合规要求”两个维度来切。这样分类后，每一类数据对应一种网关处理策略。
常用的四级分类体系
- 公开数据：如产品介绍、公司地址。网关可完全放行。
- 内部数据：如员工排班表、部门周报。网关需要做身份认证。
- 敏感数据：如身份证号、薪资信息。网关必须做动态脱敏或字段级加密。
- 绝密数据：如密钥材料、用户支付密码。网关禁止外传，仅限内部特定服务。
为什么这么分？你想想看，信用卡号和员工工号的处理方式能一样吗？不能。我在项目中见过一个糟糕的实践——把所有数据一股脑全加密，结果查询性能跌了80%不说，索引全都失效了。正确做法是分级对待。
3.3 数据生命周期管理
数据不是死的。它有生、老、病、死。一个敏感数据从产生到销毁，每一步都要有管控。网关在其中扮演的角色，其实就是一个门禁+摄像头+档案管理员。
- 采集阶段：网关要判断——这个数据的采集是否合规？用户有没有授权？比如用户注册时，收集手机号可以，收集通讯录就必须弹窗授权。
- 传输阶段：数据在服务间流转时，网关负责加密通道（TLS）、链路审计、防止中间人窃听。
- 存储阶段：网关本身不做持久化，但可以强制要求后端服务对敏感字段加密，并在出流量时做脱敏。
- 使用阶段：谁看了数据？什么时候看的？看的是什么字段？网关要打审计日志。我见过最有效的做法是——在response里嵌入水印，一旦数据泄露，就能追溯到是哪个用户、哪个时间点流出去的。
- 销毁阶段：数据过期了怎么办？网关可以做自动过期拦截。比如查询3年前的日志，直接返回“数据已过期，无法访问”。
这个生命周期，不是概念性的，而是每个阶段都要落地到网关的策略配置里。
3.4 数据分类在网关中的落地策略
前面说了这么多，最终都得落到代码和配置上。下面是一份我在项目中常用的数据分类-网关策略映射表，直接照着配就行。
| 数据等级 | 网关策略 | 示例配置（简化） |
|---|---|---|
| 公开 | 无处理，直接代理 | allow: true |
| 内部 | JWT身份验证 + 角色检查 | auth: jwt; role: employee |
| 敏感 | 动态脱敏 + 字段加密 + 全链路审计 | mask: id_card; encrypt: mobile; audit: all |
| 绝密 | 拒绝外部请求 + 服务间mTLS + 一次性密钥 | block_external: true; mtls: true |
这里有个细节——数据分类不是一成不变的。比如“用户手机号”，平时是敏感数据，但在风控场景下，需要明文做黑名单匹配。怎么办？
3.5 别忘了合规
最后聊点实际的。GDPR要求“数据最小化”，PCI-DSS要求“不可存储完整卡号”，《个人信息保护法》要求“告知同意”。这些合规要求，最终都会变成网关策略里的一个个规则。
我建议在实体框架设计阶段就把合规要求编码化。比如在API的Schema定义里，加上x-privacy-level: high这样的注解，网关自动解析，生成对应的策略。这样业务开发不用管隐私细则，合规团队也不用追着人改代码。