第4章：敏感属性分类——显式标识符、准标识符、敏感属性及其角色

做隐私保护，第一步就是要搞清楚手里到底有哪些数据、它们分别是什么属性。

很多人一上来就写过滤规则，结果没过几天就被业务方追着问：「为什么用户姓名被封了？」「为什么订单金额还能查？」——说白了，就是没把属性的角色分清楚。

我个人习惯，先给数据贴标签，再动规则。今天就聊聊这三个核心分类。

4.1 三大属性分类

我们通常把属性分成三类。这张表能帮你快速区分：

分类	定义	典型例子	脱敏策略
显式标识符	能唯一指向某个个体的信息	身份证号、手机号、姓名、邮箱	必须加密或直接移除
准标识符	单独看不唯一，组合后可定位个体	出生日期、性别、邮编、民族	泛化或抑制处理
敏感属性	涉及个人隐私的核心字段	疾病史、收入、性取向、信仰	l-多样性约束的重点保护对象

4.2 显式标识符：最显眼的靶子

这类属性最好理解。你看一眼就知道「哦，这是能直接找到人的」。

• 识别规则：是否能独立指向一个自然人。
• 处理原则：在脱敏前，必须做不可逆处理。
• 避坑点：有些字段叫法很迷惑，比如「用户编号」「工号」，在公司内部确实是唯 一的，但在外部视角可能不算显式标识符。我建议，凡是你拿来能找到具体某个人的，先按显式标识符处理。

4.3 准标识符：隐形的拼图

这玩意儿最坑人。单个拿出来，啥也不是。但几个拼在一起，杀伤力比显式标识符还大。

为什么会这样？你看一个例子：

• 出生日期：1950-03-15 —— 很多人都有这天出生的。
• 性别：男 —— 一半人口都符合。
• 邮编：100101 —— 覆盖好几千人。

但是！把这三个合起来，这个组合很可能就指向唯一一个人了。这就是准标识符的威力。

维度	显式标识符	准标识符
唯一性	高	组合后才高
识别难度	低	中等（需要组合）
脱敏难度	低（直接删/加密）	高（需要泛化/扰动）
常见误区	忽略别名	低估组合风险

4.4 敏感属性：我们要守护的核心

你想想看，做 l-多样性，本质就是为了保护敏感属性不被逆向推断出具体用户。

• 定义：用户不愿意被公开的私密信息。
• 常见类型：医疗诊断、收入区间、信用评级、政治观点、宗教信仰、性取向。
• 在 l-多样性中的角色：它是「最后一道防线」的守卫对象。规则中要求每个等价类内，敏感属性至少有 l 种不同的值。

比如说，一个等价类里 10 个人，如果 9 个人都得了同一种罕见病，那这个等价类的 l-多样性就是 1，fail。如果一个等价类里 5 个人有 5 种不同的病，那 l-多样性就是 5，pass。

4.5 三者之间的相互影响 & 一张图讲明白

这三个属性不是孤岛。它们的关系可以这样理解：

1. 显式标识符是「门牌号」，直接告诉你住在哪。
2. 准标识符是「拼图的碎片」，几片拼起来也能找到你。
3. 敏感属性是「房间里的秘密」，是最不想让人知道的。

攻击者的手法，通常是利用显式标识符或准标识符来「链接」到你身上，然后偷看你的敏感属性。

4.6 实战中如何做分类

我建议按以下流程来：

1. 先拉字段清单：把表里的所有列列出来。
2. 标显式标识符：直接标记，准备加密或摘除。
3. 识别准标识符：哪些字段在外部也能查到？比如性别、年龄、地域。
4. 标记敏感属性：业务中最需要注意的隐私字段。
5. 确认组合风险：把准标识符两两组合测试，看能锁定多少比例的用户。

# 分类示例：用户表 schema
字段列表：
- user_id          → 显式标识符（立即加密）
- name             → 显式标识符（脱敏或删除）
- birth_date       → 准标识符（需泛化到年份）
- gender           → 准标识符
- city             → 准标识符
- diagnosis_code   → 敏感属性（l-多样性重点保护）
- annual_income    → 敏感属性（l-多样性重点保护）