4、敏感数据识别与分类：PII定义、分类标准与自动化工具实践
做数据合规，第一步不是写制度，而是搞清楚——你到底有哪些敏感数据？
我见过不少团队，上来就搞加密、搞脱敏，结果连自己手里存了多少个身份证号都没数。说白了，敏感数据识别与分类是所有隐私安全工作的地基。地基没打牢，后面建什么都是危楼。
4.1 PII（个人身份信息）到底指什么？
PII，全称 Personally Identifiable Information。翻译过来就是“能直接或间接识别到具体自然人的信息”。
我个人习惯把它分成两类：
- 直接标识符：看一眼就知道是谁。比如身份证号、手机号、邮箱、护照号、生物特征（人脸、指纹）。
- 间接标识符：单个看认不出，组合起来就能定位到人。比如性别+出生日期+邮编，或者设备ID+IP地址+浏览记录。
关键点：PII 的边界是动态的。一个字段是不是 PII，取决于它所在的上下文。比如“工号”在公司内部是直接标识符，但在外部系统里可能只是随机字符串。
我在项目中遇到过一件事：某业务方说“我们只存了用户的昵称和头像，不算PII吧？”结果一查，昵称是手机号脱敏后的后四位，头像里嵌了用户ID的水印。嗯，这其实已经踩线了。
4.2 敏感数据分类标准
光知道什么是PII还不够，你得给数据分个三六九等。不同等级的数据，保护措施天差地别。
目前业界比较通用的分类框架，我整理了一张表：
| 等级 | 定义 | 典型数据 | 保护要求 |
|---|---|---|---|
| L4 极度敏感 | 泄露即造成严重人身/财产/声誉损害 | 身份证号、银行卡号、生物特征、医疗记录 | 加密存储 + 严格访问控制 + 审计日志 |
| L3 高度敏感 | 泄露可能造成较大负面影响 | 手机号、邮箱、家庭住址、精确位置 | 加密存储 + 最小权限原则 |
| L2 中度敏感 | 泄露影响有限，但需谨慎处理 | 设备ID、IP地址、浏览偏好、年龄区间 | 脱敏或匿名化后使用 |
| L1 低敏感 | 公开或几乎无风险 | 用户名、公开文章、产品评价 | 常规保护即可 |
我的建议：分类标准别搞太复杂。4级刚刚好，再多一级，落地时业务方就懵了。我曾经见过一个公司搞了7级分类，结果没人记得住，最后全标成了“默认”。
4.3 自动化识别工具实践
手动翻数据库字段？别傻了。一个中型App的数据表少说几百张，字段上千个。靠人眼识别，不仅慢，还容易漏。
自动化识别，核心思路就三步：
- 扫描：遍历所有数据源（数据库、日志、文件、API响应）。
- 匹配：用正则、关键词、机器学习模型去命中敏感数据模式。
- 打标：给命中的字段或记录贴上分类标签。
下面是我常用的一个 Python 示例，用正则识别常见的 PII 字段：
import re
# 常见PII的正则模式
PII_PATTERNS = {
'phone': r'1[3-9]\d{9}',
'id_card': r'\d{17}[\dXx]',
'email': r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}',
'bank_card': r'\d{16,19}'
}
def scan_pii(text):
"""扫描文本中的PII"""
found = {}
for name, pattern in PII_PATTERNS.items():
matches = re.findall(pattern, text)
if matches:
found[name] = matches
return found
# 示例
sample = "用户手机13800138000，身份证110101199001011234"
result = scan_pii(sample)
print(result)
# 输出: {'phone': ['13800138000'], 'id_card': ['110101199001011234']}
注意：正则只能识别格式，不能验证真实性。比如“123456789012345678”符合身份证格式，但它是假的。所以自动化工具只能做初筛，最终还需要人工复核。
在实际工程中，我推荐用 扫描引擎 + 规则库 + 机器学习 的组合方案。规则库负责高精度匹配（比如身份证、手机号），机器学习负责模糊识别（比如非结构化文本里的姓名、地址）。
我曾经在某个项目中，用正则扫出了90%的敏感字段，但剩下的10%藏在PDF附件和客服聊天记录里。最后靠一个简单的BERT分类模型，把这部分也捞了出来。
4.4 敏感数据分类的整体流程
把上面这些串起来，就是一套完整的敏感数据识别与分类流程。我画了张图，方便你理解：
你看，整个流程是线性的，但中间有反馈闭环。比如机器学习模型发现了一批新的敏感模式，可以反哺到规则库里，让下一次扫描更准。
4.5 落地时常见的坑
最后聊几个我踩过的坑，希望能帮你省点时间：
- 只扫数据库，不扫日志：很多敏感数据泄露其实是从日志里出去的。API请求日志、错误堆栈、调试输出，这些地方经常“裸奔”着用户信息。
- 分类标准太细，落地困难：我见过有人把数据分了十几级，结果业务方直接摆烂，全标成“最高级”。分级是为了差异化保护，不是为了炫技。
- 自动化工具跑完就完事：敏感数据是活的。今天新增一个字段，明天上线一个新功能，你的分类清单必须持续更新。建议做成定时任务，每周全量扫描一次。
一个小技巧：在数据库字段命名上做文章。比如所有敏感字段统一加前缀 pii_，这样扫描工具一眼就能识别，也方便后续的脱敏和审计。
敏感数据识别这件事，说白了就是“知己”。你连自己家里有什么都不知道，怎么防贼？把PII定义搞清楚，分类标准定下来，自动化工具跑起来，这一步走扎实了，后面的合规工作才能事半功倍。