3. 令牌化对象建模

令牌化不是把整张表“一键加密”，而是先回答三个问题：哪些字段值得令牌化、它们有多敏感、令牌化后要保留什么可用性。对象建模就是把这三点固化成可执行的字段级决策，让后续的令牌生成、映射存储、权限控制和审计都有依据。

一、从数据资产清单到候选字段

对象建模的起点不是数据库表结构，而是业务数据流。建议按“系统—实体—字段—使用场景”四层梳理：先列出订单、用户、支付、物流等实体，再展开每个实体的字段，最后标注字段在哪些业务中被读写。例如电商订单实体中，user_id、receiver_name、receiver_phone、receiver_address、bank_card_no、id_card_no 都是候选对象；而 order_amount、create_time 通常不需要令牌化。

候选字段筛选可依据四条经验规则：第一，能直接或间接定位到自然人的标识符；第二，一旦泄露会造成财产、声誉或合规风险；第三，在非生产环境、外包、测试、分析等场景中被广泛复制；第四，业务上需要保留格式、长度或关联关系。满足其中两条以上，就应进入候选清单。

二、数据分类分级与敏感度评估

分类解决“是什么”，分级解决“有多重要”。分类可按个人信息、账户信息、交易信息、设备信息、公开信息划分；分级建议采用四级：L1 公开、L2 内部、L3 敏感、L4 高敏感。敏感度评估不能只看字段名称，而要看组合效应。例如单独的 receiver_phone 是 L3，但与 receiver_name、receiver_address 组合后可能构成 L4 级可识别信息。

评估维度建议包括：可识别性（能否定位到个人）、可关联性（能否与其他数据拼接）、泄露影响（财产/声誉/合规）、使用范围（生产/测试/分析/外包）、法规要求（如个人信息保护法、PCI DSS）。每个维度按 1～3 分打分，加权求和后映射到等级。示例：bank_card_no 可识别性 3、可关联性 3、泄露影响 3、使用范围 3、法规要求 3，总分 15，定为 L4；user_id 可识别性 2、可关联性 3、泄露影响 1、使用范围 3、法规要求 1，总分 10，定为 L3。

三、令牌化策略设计

策略设计要回答“用什么令牌、存在哪里、谁能用、多久失效”。令牌类型上，L4 字段建议使用不可逆令牌（如 HMAC-SHA256 加盐后截断），确保即使映射表泄露也无法还原；L3 字段可使用可逆令牌，但映射表必须独立存储、独立授权、独立审计。格式保留方面，手机号令牌应保持 11 位数字，银行卡令牌保持 16～19 位数字，便于下游系统无需改造即可接收。

映射存储建议采用“令牌库 + 密钥管理”分离架构：令牌库只存 token → 密文，密钥由 KMS 管理，应用通过令牌服务接口换取明文，且每次换取都记录调用方、字段、时间、用途。访问权限按最小必要原则分配：测试环境只能拿到令牌，生产客服只能看到脱敏后的后四位，风控系统可按需申请完整明文但需二次审批。

生命周期上，建议为每个字段定义令牌有效期和轮换策略。例如 bank_card_no 令牌有效期 90 天，到期后重新生成；receiver_phone 令牌有效期 180 天。跨环境一致性要求同一明文在同一业务域内生成相同令牌，避免关联分析断裂，但不同业务域之间应使用不同盐值，防止跨域拼接。

四、可执行的字段级策略表

下表是一份可直接参考的字段级策略示例，字段、等级、令牌类型、格式保留、映射存储、访问角色和有效期均可按实际业务调整。

总结来说，令牌化对象建模的核心产出是一张“字段—等级—策略”对照表，它把数据分类分级、敏感度评估和令牌化策略设计串成一条可执行、可审计、可复用的工程链路。后续的令牌生成、映射存储和权限控制，都应以此表为唯一依据。