2、PII基础概念：定义、分类与常见类型
在构建任何隐私合规检测系统之前，必须首先建立对PII（Personally Identifiable Information，个人身份信息）的精确认知。PII是隐私保护的基石，也是数据脱敏、访问控制、加密存储等安全措施的“靶心”。如果对PII的边界定义模糊、分类错误，后续的检测规则、脱敏策略和合规审计都将失去依据。本章将系统梳理PII的法律与工程定义、直接标识符与间接标识符的划分逻辑、以及各类常见PII的识别特征与风险等级，为后续的PII masking项目实训打下坚实的理论基础。
2.1 PII的定义：从法律文本到工程语义
PII的核心定义并非一成不变，它随着法律框架和技术实现方式而演化。在工程实践中，我们通常采用“可关联性”作为判断标准：任何能够直接或间接关联到某个特定自然人的数据，均属于PII。这一定义超越了简单的字段名称匹配，要求我们从数据语义和组合风险的角度进行判断。
| 定义来源 | 核心表述 | 工程影响 |
|---|---|---|
| GDPR（欧盟） | “已识别或可识别的自然人”相关的任何信息 | 强调“可识别性”，包括间接识别 |
| 《个人信息保护法》（中国） | 以电子或其他方式记录的与已识别或可识别的自然人有关的各种信息 | 明确“匿名化”处理后不属于PII |
| NIST SP 800-122（美国） | 用于区分或追踪个人身份的信息，以及与之关联的其他信息 | 区分“直接”与“间接”标识符 |
| ISO/IEC 29100（国际） | 可识别数据主体的任何信息 | 强调数据主体控制权 |
在实训项目中，我们不应仅依赖字段名称（如“name”、“id_card”）来判断PII，而应结合数据内容格式和上下文关联性。例如，一个名为“备注”的字段中可能包含“张三，138xxxx1234”这样的混合内容，仅靠字段名无法识别，必须通过正则匹配和实体识别技术才能发现。
2.2 直接标识符与间接标识符：分类的核心逻辑
PII的分类是脱敏策略选择的基础。直接标识符（Direct Identifiers）可以单独、唯一地识别一个人，而间接标识符（Quasi-Identifiers / Indirect Identifiers）本身无法唯一识别，但多个间接标识符组合后可以锁定特定个体。这种分类直接决定了脱敏的优先级和脱敏算法选择。
2.2.1 直接标识符（唯一性字段）
直接标识符具有全局唯一性或高区分度，通常由权威机构签发或具有天然唯一属性。这类字段一旦泄露，等同于直接暴露个人身份。在脱敏时，通常需要采用不可逆脱敏（如哈希、令牌化）或强加密处理。
- 国家证件类：身份证号、护照号、驾驶证号、社保卡号、军官证号。
- 联系方式类：手机号码（在实名制背景下）、固定电话号码（含区号）。
- 生物特征类：指纹模板、虹膜扫描数据、人脸特征向量、DNA序列。
- 账户标识类：银行卡号、支付账号、电子邮箱地址（通常唯一）。
2.2.2 间接标识符（准标识符）
间接标识符单独存在时看似无害，但通过链接攻击（Linkage Attack）可以重新识别个人。例如，性别+出生日期+邮政编码这三项组合，在美国人口统计中可唯一识别约87%的人口。在PII masking项目中，间接标识符的处理往往比直接标识符更具挑战性，因为过度脱敏会破坏数据的分析价值。
| 间接标识符 | 单独风险 | 组合风险示例 | 脱敏建议 |
|---|---|---|---|
| 性别 | 低（50%概率） | 性别+生日+邮编 → 高概率唯一 | 泛化（男/女 → 性别类别） |
| 出生日期 | 低（365天分布） | 生日+姓名首字母 → 中等风险 | 保留年份，隐藏月日 |
| 邮政编码 | 低（约4万种） | 邮编+性别+职业 → 高风险 | 保留前3位，后2位置零 |
| 职位/公司 | 低 | 职位+公司+所在城市 → 可定位 | 泛化为行业类别 |
| 民族/宗教 | 低 | 民族+地区+姓氏 → 敏感推断 | 删除或加密 |
2.3 常见PII类型详解与识别特征
在实际数据集中，PII的呈现形式多种多样。以下按类别详细说明其格式特征、识别要点和脱敏优先级。这些内容将直接用于后续章节的检测规则编写。
2.3.1 姓名类
姓名是使用最频繁的PII，但也是最难精确检测的字段。中文姓名通常为2-4个汉字，英文姓名由字母和空格组成。检测难点在于：姓名与普通名词难以区分（如“高峰”、“杨柳”）。在实训中，建议结合上下文词典和姓氏库进行匹配。
// 中文姓名检测示例（简化正则）
[\u4e00-\u9fa5]{2,4}(?=先生|女士|同学|老师|客户|用户)
// 英文姓名检测示例
[A-Z][a-z]+ [A-Z][a-z]+2.3.2 身份证号（中国）
中国居民身份证号为18位，由6位地址码、8位出生日期码、3位顺序码和1位校验码组成。其格式固定，检测规则相对简单，但需注意校验码验证以避免误报。
// 身份证号正则（含基本校验）
^[1-9]\d{5}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$2.3.3 手机号码
中国大陆手机号码为11位，以1开头，第二位通常为3-9。检测时需注意与座机号、服务热线的区分。脱敏策略通常保留前3位和后4位，中间4位用*代替。
2.3.4 电子邮箱
邮箱格式为“用户名@域名”，用户名部分可能包含姓名、生日、数字等信息。邮箱本身是直接标识符，且常作为登录账号，泄露后可能导致账号撞库风险。
2.3.5 物理地址
地址信息包含省、市、区、街道、门牌号等层级。地址脱敏通常采用泛化策略，例如只保留到市级或区级。在物流、电商场景中，地址脱敏需要平衡配送需求与隐私保护。
2.3.6 生物特征信息
生物特征（指纹、人脸、虹膜、声纹）属于敏感PII，在GDPR和个保法中受到特殊保护。这类数据通常以模板或特征向量的形式存储，一旦泄露不可更改（不像密码可以重置）。在检测时，需要识别特定的数据格式（如人脸特征向量文件头、指纹模板的特定字节结构）。
① L1-直接标识符（身份证、手机号、生物特征）：必须脱敏，使用不可逆算法；
② L2-间接标识符（生日、邮编、性别）：根据场景泛化或加密；
③ L3-低风险PII（姓名、地址）：根据业务需求选择脱敏或保留。
2.4 案例拆解：一个用户表中的PII识别与分类
假设我们收到一份用户信息表，包含以下字段：user_id、name、id_card、phone、email、gender、birthday、zip_code、address、fingerprint_data。我们需要完成PII识别与分类，并制定脱敏策略。
| 字段名 | 示例数据 | PII类型 | 分类 | 脱敏策略 |
|---|---|---|---|---|
| user_id | 10001 | 内部标识 | 非PII（但需保护） | 保留或加密 |
| name | 张伟 | 姓名 | 直接标识符 | 替换为随机姓名或保留姓氏 |
| id_card | 110101199003077856 | 身份证号 | 直接标识符（敏感） | SHA-256哈希或保留后4位 |
| phone | 13812345678 | 手机号 | 直接标识符 | 保留前3后4，中间* |
| zhangwei@example.com | 邮箱 | 直接标识符 | 前缀哈希，保留域名 | |
| gender | 男 | 性别 | 间接标识符 | 泛化为“M/F”或删除 |
| birthday | 1990-03-07 | 出生日期 | 间接标识符 | 仅保留年份 |
| zip_code | 100080 | 邮编 | 间接标识符 | 保留前3位 |
| address | 北京市海淀区中关村大街1号 | 地址 | 直接标识符 | 泛化到“北京市海淀区” |
| fingerprint_data | 0x1A2B3C... | 生物特征 | 敏感PII | 不可逆加密，禁止明文存储 |
分析过程：首先，我们根据字段名和格式规则识别出所有PII字段。其次，判断每个字段的“唯一性”和“敏感性”。id_card和fingerprint_data属于最高风险等级，必须采用强脱敏；gender、birthday、zip_code单独风险低，但三者组合后可以唯一识别个体，因此需要泛化处理。最后，我们还需要检查address字段中是否包含电话号码或姓名等嵌套PII，这需要额外的实体识别扫描。
user_id这类内部标识。如果user_id与外部系统关联，它也可能成为间接标识符。此外，fingerprint_data如果以Base64编码存储，检测时不能仅靠文件头判断，需要结合字段语义和长度特征。
2.5 总结复盘：PII识别的核心原则
本章内容为PII masking项目提供了基础认知框架。在实际工程中，PII识别不是一次性的静态工作，而是一个持续演进的动态过程。以下是需要牢记的核心原则：
- 上下文优先：同一个数据在不同上下文中可能是PII，也可能不是。例如，员工的“工号”在公司内部不是PII，但对外部系统而言可能关联到个人。
- 组合风险思维：永远不要孤立地评估单个字段的风险，要检查字段之间的关联性。建议在检测规则中内置“组合字段风险评分”模块。
- 格式与语义并重：正则表达式可以识别格式，但无法理解语义。例如，“13812345678”可能是手机号，也可能是订单号。需要结合字段名、上下文和校验算法综合判断。
- 敏感PII的特殊性：生物特征、健康信息、宗教信仰等属于特殊类别PII，在脱敏时不仅要考虑“不可识别”，还要考虑“不可推断”。
- 脱敏粒度与数据可用性的平衡：过度脱敏会导致数据失去分析价值，脱敏不足则存在泄露风险。建议根据业务场景定义不同的脱敏级别（如开发环境、测试环境、生产环境）。