《个人信息保护法》2021 年施行后，券商客户信息从"公司资产"变成了"受委托处理的个人信息"，法律性质一变，系统里那堆明文身份证号就成了负债。但券商又是个必须看客户资料才能干活的行业：客服要核对身份，柜员要办业务，合规要查异常。脱敏系统的全部工作，就是在"必要的最少"和"业务可用"之间画一条可审计的线。这篇讲这条线怎么画。
字段分级：先分类，再谈脱敏
脱敏的第一步不是写掩码函数，是给字段定级。券商客户数据的实际分级大致是这样：
| 级别 | 字段 | 典型要求 |
|---|---|---|
| 高敏 | 身份证号、银行卡号、联系方式 | 默认掩码，全量查看需审批留痕 |
| 中敏 | 资产余额、盈亏、交易记录 | 按岗位需要授权，柜面可见、客服区间化 |
| 低敏 | 姓名、性别、风险等级 | 可见，但批量导出受控 |
注意这个分级的业务含义：客服电话核对身份，只需要"身份证后四位"和"姓名"，不需要看全号。那系统设计就应该让客服界面结构性看不到全号，而不是"能看到但要求不许抄"。这是《个人信息保护法》里"最小必要"原则的系统化翻译：做不到结构性隔离，出一次内部泄露就是不可证明尽职。
掩码规则的数学：可逆与不可逆
掩码函数本身简单，身份证号保留前 3 后 4：110***********1234。工程上有三个决定要做：
位置：掩码放哪一层？选项有前端渲染时掩码、API 网关返回时掩码、数据库视图掩码。常见做法是网关层统一处理——服务内部流转明文，出网时按调用方角色脱敏。这样只需维护一份规则，但前提是内网信任域的边界清晰。更严格的架构（金融级常见）是库里就分 id_no 和 id_no_mask 两列，高敏列单独加密、单独密钥、单独访问审计，应用层无感知拿掩码列，需要全量的场景走单独的解密服务并强制留痕。两种架构的取舍就是信任域边界的取舍：内网越可信，掩码越靠外层；出过一次内鬼事件，就都想往库里收。
可逆性：掩码是不可逆的（信息丢弃），但业务需要"用身份证后四位加姓名核对身份"，这要求比对操作能落在密文/掩码上。做法是比对接口化：不给明文，给 verify_id_no(customer_id, 用户输入) 返回布尔。密钥和明文永远不出解密服务，这直接堵死了"应用日志里打印了客户身份证号"这一类泄露通道——明文根本流不到应用层，想打日志也没东西可打。
统计可用性：资产余额这类字段，掩码成区间（"50~100 万"）会毁掉客服排查问题的能力。折中是按角色返回不同粒度：客服看区间，柜员看精确值，且柜员查询弹窗确认用途。粒度本身就是权限的一种表达。
访问矩阵与留痕
把角色和字段交叉起来就是访问矩阵：
- 客服：身份字段全掩码、资产区间化、能核对不能查全量；
- 柜员：业务办理需要的字段可见，跨营业部客户降级为掩码；
- 合规/风控：全量可见，但每一次全量查看都记录"谁、何时、查了谁、用途"，用途必填——这是为事后审计准备语境；
- 开发/测试：生产数据原则上不可见。测试环境必须用脱敏后的克隆数据，脱敏要做关联性保持（同一个客户在测试库里的掩码值要稳定，不然关联测试全废）。
留痕系统单独说两句，因为它是这套体系的可证明性来源。每次全量查看生成一条审计记录（哈希链存储，《审计日志》那篇展开），定期跑批统计"谁在异常时间大量查询"。处罚通报里"某员工违规查询并泄露客户信息"的案例，事后能被认定，靠的就是这条链完整；反过来，如果留痕本身能被柜员删除，整套体系形同虚设。
批量导出：泄露的主通道
单条查询的泄露是 spoon，批量导出是 pipe。所有"能按条件筛选并导出明细"的界面都是高风险点，管控手段有三层：导出按钮本身要独立授权；导出行数超过阈值（比如 500 行）转审批流，部门负责人加合规双签；导出文件加水印（含工号和时间戳），文件落地即登记。水印是个朴素的威慑：文件流到外面，第一个被问话的是导出者本人。
一个反直觉的结论
这套系统做完，最直接的体感是查询变慢、办事变烦——客服核对身份多十秒，柜员查跨营业部客户看到的是掩码，合规每次调全量都要填用途。这个摩擦不是缺陷，是功能：可证明尽职依赖"越权操作的摩擦足够大、痕迹足够多"。真正要压的成本是摩擦背后的技术开销——掩码规则统一管理、比对接口化、留痕自动化——让"合规的默认路径"恰好也是"高效的默认路径"，这套体系才活得下去。凡是靠制度要求"请大家自觉少看"的系统，最后都形同虚设。