📚 课程目录第2章敏感字段定义与识别

第二章：敏感字段定义与识别归纳总结

做令牌化之前，得先搞清楚一件事——到底哪些字段算敏感？

你可能觉得这问题很简单。手机号、身份证、银行卡号，谁不知道？但其实，真正埋坑的往往是那些「你以为不敏感」的字段。我见过不止一个团队，上线前一天被安全审计卡住，原因就是漏了一个看似人畜无害的字段。

这一章，我们就来把这些定义和识别方法彻底捋清楚。

2.1 到底什么是敏感字段

先说定义。敏感字段，说白了就是——一旦泄露，会对用户或平台造成实质性伤害的数据。

这个定义有点宽泛，对吧？那我们换个角度。你想想看，如果你的数据被公开了，谁最难受？

用户难受——身份被盗、钱财损失、隐私曝光
平台难受——合规罚款、声誉崩塌、用户流失
监管难受——数据安全法、个保法可不是摆设

我在一个电商项目中遇到过一件事。运营同事把用户订单的「备注信息」当普通字段导出了。结果备注里有人写了「妈妈的生日是1965-03-12」，还有人写「身份证照片在手机里」。你看，一个备注字段，瞬间变成了敏感字段。

所以我的经验是——别只看字段名，要看字段承载的实质内容。

⚠️ 我曾经踩过的坑： 以为「用户备注」是自由文本无所谓，结果数据泄露后被监管认定违反了《个人信息保护法》第6条——收集个人信息应当限于实现处理目的的最小范围。从那以后，我对「备注」这种自由输入字段格外敏感。

2.2 电商平台敏感字段全景分类

根据我在多个电商项目中的整理，敏感字段可以分成四大类。每一类的处理方式和令牌化策略都不一样。

分类	典型字段	泄露后果	令牌化优先级
PII（个人身份信息）	姓名、身份证号、手机号、邮箱、家庭地址	身份盗用、精准诈骗	⭐⭐⭐⭐⭐
支付信息	银行卡号、有效期、CVV、支付密码	盗刷、资金损失	⭐⭐⭐⭐⭐
账户凭证	登录密码、支付密码、Session 、	账户劫持、数据全量泄露	⭐⭐⭐⭐⭐
商业敏感数据	订单金额、折扣策略、供应商信息、商品成本	商业竞争劣势、定价策略暴露	⭐⭐⭐

你可能会问，商业敏感数据也要令牌化？我个人习惯是——先看合规要求，再看业务风险。PII和支付信息是强合规字段，必须令牌化。商业敏感数据呢？如果你的竞争对手拿到了你的商品成本价，那画面太美不敢看。

2.3 识别敏感字段的三种方法

光有分类不够，你得有一套方法，能在一堆数据库表里把敏感字段捞出来。我从实践中总结了三板斧。

2.3.1 正则表达式匹配

这是最直接的方法。尤其是身份证号、手机号、银行卡号，它们都有固定的格式。

import re

# 身份证号：18位，最后一位可能是X
id_card_pattern = r'^[1-9]\d{5}(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$'

# 手机号：11位，国内以1开头
phone_pattern = r'^1[3-9]\d{9}$'

# 银行卡号：16-19位数字
bank_card_pattern = r'^\d{16,19}$'

这个方法的好处是快。跑一次全表扫描，就能把匹配的字段标记出来。但有个问题——误报率不低。我记得有次把一串纯数字的订单号识别成了身份证号，还好人工复核时发现了。

💡 我的建议： 正则匹配适合做「初筛」，别完全依赖它。一定要加上人工复核和字段语义分析。

2.3.2 字段命名规范识别

这个方法更上层一点。你去看数据库的字段名，通常命名会暴露意图。

包含 id_card、phone、mobile、email 的，八九不离十
包含 password、pwd、、secret 的，必须处理
包含 bank、card_no、cvv、expire 的，支付相关跑不了

我习惯的做法是维护一个「敏感字段词典」，把历史项目中遇到过的敏感字段名都加进去。每次新项目来了，直接跑一遍字典匹配，省时省力。

2.3.3 数据分级分类——从治理层面解决

正则和命名匹配都是游击战。真正正规军的方式，是建立数据分级分类体系。

举个例子：

L1 - 公开数据：商品名称、店铺公告、用户评价（脱敏后）
L2 - 内部数据：订单数量、库存信息、一般运营数据
L3 - 敏感数据：用户手机号、邮箱、收货地址
L4 - 核心数据：身份证号、银行卡号、支付密码、生物特征

L3及以上的字段，才进入令牌化的候选清单。这个方法有一个明显的好处——你不用纠结「某个字段到底算不算敏感」，分级表拍在那，一目了然。

  📌 关键思路： 识别敏感字段不是一次性的工作。随着业务迭代，新的字段会不断加进来。我建议每个迭代都做一次「敏感字段复核」，把它加到发布流程里。

2.4 避坑指南：我在识别阶段踩过的三个坑

识别方法讲完了，说点实在的——我踩过的坑，你尽量别踩。

坑一：忘了JSON字段里的嵌套内容

有一次，我在一个 user_extra 的 JSON 字段里发现了明文的身份证号。表面上看表结构只有 id、name、extra 三个字段，但 extra 里嵌套了一个 identity_info 对象。

解决方案：把所有 JSON 字段也纳入扫描范围，递归展开检查。

坑二：日志系统里的「意外备份」

曾经有个项目，数据库字段确实令牌化了。但日志系统为了排查问题，把完整的请求体打了出来。结果呢？令牌化做了等于没做。

解决方案：审查所有日志输出，确保敏感字段在日志里也被脱敏或令牌化。

坑三：第三方接口的响应字段

调用支付网关时，对方返回了完整的银行卡号。我的系统没存，但日志里记了。嗯，又是一个血泪教训。

解决方案：对第三方接口的响应体也做敏感字段扫描，不能只盯着自己的数据库。

2.5 核心知识体系：一张图说透

下面这张 SVG 图，把本章的核心脉络串起来了。你可以把它当作一个检查清单，做项目时对着看，基本不会漏。

2.6 本章关键 takeaways

合上这一章之前，我把最核心的几个点再拎一下：

敏感字段的定义核心：不是看字段名叫什么，而是看泄露后会造成什么伤害
四分类法：PII、支付信息、账户凭证、商业敏感数据——覆盖电商平台99%的场景
识别三板斧：正则初筛 → 命名匹配 → 分级分类，从游击战走向正规军
避坑三连：JSON嵌套、日志备份、第三方响应——这三块是最容易被漏掉的

嗯，到这儿，敏感字段的定义和识别方法就算彻底讲透了。下一环节我们就要开始动手——怎么对这些字段做令牌化替换。但那是后面的事。先把识别这步做扎实，后面的路才走得稳。