假名化：定义、方法，以及和匿名化的区别

什么是假名化？

假名化（Pseudonymization）是把直接识别个人的数据，比如姓名、邮箱、客户编号，替换成一个代替值（假名），并把能把假名对应回本人的信息另外保存、加以保护。

GDPR 第 4 条第 5 款的定义是：对个人数据进行处理，使其「在不使用额外信息的情况下，无法再归属于特定数据主体」，前提是这些额外信息被单独保存，并受技术和组织措施保护。

假名化和匿名化

最常见的错误是把哈希或令牌化后的数据叫做「匿名」。只要你、或任何拿到密钥或候选值清单的人能还原，它就是假名数据。

常见的假名化方法

计算示例：为什么普通哈希不够

某分析表用 SHA256(小写(email)) 作为用户键。一个营销合作方手里有 5 万个客户邮箱，用同样的方法哈希自己的清单，就能匹配出两边都有的每一个用户，不需要任何密钥。这一列「哈希值」其实一直是个查找键。

换成带密钥的哈希 HMAC-SHA256(k, email)，密钥 k 只有你的数据团队持有，合作方就算不出同样的值。如果轮换或销毁 k，过去的假名就无法再和新数据关联，这是限制「可关联多久」的实用办法。

为什么要假名化

• 泄露时风险更低。 泄露的假名表暴露的信息远少于姓名和邮箱。
• 把数据最小化落到实处。 分析师可以按用户计数、分群、关联，却看不到用户是谁。
• 法规上的认可。 GDPR 把假名化列为安全保障（第 32 条）、默认数据保护设计（第 25 条）以及研究和统计（第 89 条）的适当措施。
• 更安全地共享和测试。 开发和测试环境用假名化的副本，而不是生产环境里的真实身份。

局限

• 通过其他字段重新识别。 位置、设备、时间戳的罕见组合，即使没有直接标识也能锁定某个人。
• 密钥管理。 持有密钥的人能还原假名：密钥要和数据分开存放，限制访问，记录使用。
• 仍在监管范围内。 访问请求、删除请求和保留期限依然适用于假名数据。

在 TapCub 里

TapCub 默认用到了其中几种方法。匿名网页访客用访客 ID 计数，这个 ID 由采集端把站点盐值和地址、浏览器信息一起哈希得到，网站脚本不写 Cookie。严格隐私预设每天轮换盐值，同一个浏览器跨天无法关联。两种预设都会在存储前截断 IP 地址。项目开启用户识别、并用邮箱作为登录 ID 时，邮箱会先转成小写再哈希。事件属性里放什么仍由你决定，见别让个人信息进统计数据、IP 截断与保留期限和哈希。

另见：什么是 PII？个人身份信息的定义、类型和例子。

参考资料

• GDPR. Article 4: definitions (5) pseudonymisation and Recital 26.
• ENISA. Pseudonymisation techniques and best practices (2019).
• NIST. Glossary: pseudonymization.