敏感字段脱敏展示规范

敏感字段脱敏这件事，很多团队一开始都踩过同一个坑：要么脱得太干净，业务没法用；要么脱得太敷衍，日志里、接口返回值里、甚至前端页面上，敏感数据满天飞。真正规范的脱敏展示，不是简单打个星号就完事，而是要根据数据敏感等级、使用场景、展示端侧，建立一套可执行、可审计的规则。

敏感字段不只是身份证号和手机号。按照《个人信息保护法》和金融、医疗等行业标准，敏感字段至少包括四类：个人身份标识（姓名、身份证、护照、驾驶证）、联系信息（手机号、邮箱、地址）、金融信息（银行卡号、交易流水、余额）、生物特征和健康数据（人脸、指纹、病历）。实际业务中，IP地址、设备指纹、Cookie标识在某些场景下也属于敏感字段，因为可以关联到具体自然人。界定范围是脱敏的前提，范围没划清楚，后面所有规范都是空中楼阁。

很多人把脱敏和加密混为一谈，这是两个完全不同的操作。加密是可逆的，有密钥就能还原明文，用于存储和传输环节；脱敏是不可逆的，数据一旦脱敏，原始信息就不可恢复，用于展示环节。举个例子，用户绑卡后，数据库里存的是加密后的卡号，这是加密；但在用户个人中心页面展示“62221234”，这是脱敏。脱敏后的数据即使被截屏、被爬虫抓取、被内部人员导出，也不会造成实质泄露。所以脱敏规范的核心原则是：能展示脱敏数据的场景，绝不展示明文；需要明文才能做业务判断的场景，用加密加权限控制，而不是把明文直接抛到前端。

一个常见的错误是：所有场景用同一套脱敏规则。结果要么是客服后台看不到足够信息无法核实用户身份，要么是用户自己登录后连自己的完整手机号都看不到。正确的做法是按场景分级：

第一级，公开展示场景。比如评论区用户昵称、公开排行榜上的用户标识。这类场景脱敏最严格，手机号只保留前3后2，姓名只展示姓，其余用星号替代，且星号数量不反映原始长度，防止反推。

第二级，用户本人查看场景。用户登录后查看自己的完整信息，可以展示更多位数，比如手机号展示前3后4，银行卡展示后4位，但完整明文永远不在前端DOM中直接渲染，而是通过点击“查看完整号码”触发二次验证后，由服务端返回并在内存中短暂持有，页面失焦即清除。

第三级，内部运营和客服场景。这类场景权限最高，但风险也最大。必须配合动态脱敏网关，根据操作人员角色、查询时间、查询次数动态决定脱敏程度。客服在核实用户身份时，可以临时查看完整手机号，但操作全程留痕，截图水印自动叠加操作员工号和查询时间。

简单的“中间四位打星号”在有些场景下是不够的。比如身份证号，前6位是地区码，后4位是校验位和性别信息，如果只遮中间生日8位，熟悉编码规则的人结合其他信息完全可能反推出来。更安全的做法是：对身份证号，只保留前3位和后2位，中间全部用相同数量的星号替代，且不暴露原始长度规律。手机号同理，不要固定“前3后4”，而是根据业务需要动态调整保留位数，比如非必要场景只保留前3后2。邮箱脱敏要注意，@前面的部分至少保留首尾各1个字符，@后面的域名部分不脱敏，因为域名本身是公开信息，脱敏没有意义。

一个原则：脱敏逻辑必须在前端和服务端同时存在，但以服务端为准。前端脱敏只是UI层面的友好展示，不能作为安全防线。服务端在接口返回数据时，就应该根据用户权限和场景，直接返回脱敏后的数据，而不是返回明文让前端自己去处理。前端做脱敏最大的问题是：攻击者直接抓包就能拿到明文。所以接口设计上，敏感字段的返回值应该区分两个字段：一个是脱敏后的展示字段，一个是加密后的完整字段（仅在权限校验通过后返回，且前端解密密钥由独立的安全组件管理）。

代码层面，服务端脱敏可以抽象成一个通用工具类，避免每个业务开发自己写正则，导致规则不统一。以下是一个Java脱敏工具类的核心逻辑示例：

public class DataMaskingUtil {
    // 手机号脱敏：保留前3后4
    public static String maskMobile(String mobile) {
        if (mobile == null || mobile.length() != 11) return mobile;
        return mobile.substring(0, 3) + "" + mobile.substring(7);
    }
    
    // 身份证脱敏：保留前3后2
    public static String maskIdCard(String idCard) {
        if (idCard == null || idCard.length() < 5) return idCard;
        int maskLen = idCard.length() - 5;
        return idCard.substring(0, 3) + repeat("*", maskLen) + idCard.substring(idCard.length() - 2);
    }
    
    // 银行卡脱敏：只保留后4位
    public static String maskBankCard(String cardNo) {
        if (cardNo == null || cardNo.length() < 4) return cardNo;
        return "" + cardNo.substring(cardNo.length() - 4);
    }
    
    // 姓名脱敏：保留姓，名用*替代
    public static String maskName(String name) {
        if (name == null || name.length() == 0) return name;
        return name.substring(0, 1) + repeat("*", name.length() - 1);
    }
    
    private static String repeat(String s, int count) {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < count; i++) sb.append(s);
        return sb.toString();
    }
}

这个工具类要作为公共库强制所有业务线使用，禁止各业务自行实现脱敏逻辑。同时，脱敏规则要配置化，比如保留位数、替代字符可以通过配置中心动态下发，这样一旦监管要求变化，不需要改代码重新发布。

生产环境中，大量敏感数据泄露不是发生在数据库被拖库，而是日志打印不当。开发调试时随手一个log.info把整个请求体打出来，里面可能包含用户的身份证、密码、Token。日志脱敏规范要明确几点：第一，禁止在日志中打印完整请求体和响应体，除非经过脱敏过滤器处理；第二，日志框架层面统一配置脱敏规则，比如Logback或Log4j2的Converter，在日志输出前自动匹配手机号、身份证等正则并替换；第三，敏感字段的日志级别必须设为DEBUG，且生产环境默认关闭DEBUG日志。日志脱敏不是事后补救，而是日志系统设计阶段就必须内建的能力。

很多系统在DAO层查出来数据后，直接返回给Service层，Service层再手动脱敏，这中间任何一个环节遗漏都会导致明文泄露。更好的做法是在ORM框架层面做拦截，比如MyBatis的Interceptor或JPA的EntityListener，对标注了敏感字段注解的实体属性，在读取时自动应用脱敏规则。这样无论哪个业务方查询，拿到的都是脱敏后的数据，除非显式声明需要明文并经过权限校验。注解可以这样设计：

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface SensitiveField {
    SensitiveType type(); // MOBILE, ID_CARD, BANK_CARD, NAME, EMAIL
    int keepPrefix() default 3;
    int keepSuffix() default 4;
}

在实体类中，对敏感属性加上这个注解，拦截器在读取时自动根据类型和配置进行脱敏。这种方案的好处是零侵入，业务代码不需要任何改动，而且脱敏规则集中管理，不会出现各业务方脱敏不一致的情况。

前端脱敏展示有几个容易被忽略的细节。第一，脱敏后的文本要禁止复制？不需要。脱敏的目的就是让数据可以展示但不可还原，如果脱敏做得足够彻底，复制出去也没有风险。禁止复制反而影响正常使用场景，比如用户复制自己的脱敏卡号去客服聊天窗口。第二，脱敏字段的HTML标签要统一用span包裹，并添加自定义属性data-masked="true"，方便自动化测试脚本检测页面上是否存在未脱敏的敏感数据。第三，移动端展示空间有限，脱敏后的字段如果过长，可以用省略号截断，但截断位置不能破坏脱敏规则，比如手机号“1388000”被截成“1388...”就会让后四位失去意义，应该在脱敏段之前截断，显示“138...”即可。

规范制定得再好，没有审计就是纸上谈兵。需要从三个层面建立审计：一是接口自动化扫描，在CI/CD流水线中集成敏感数据检测工具，对所有API返回的JSON进行正则匹配，一旦发现未脱敏的手机号、身份证等模式，直接阻断发布；二是前端自动化测试，用Puppeteer或Playwright编写脚本，遍历关键页面的DOM节点，检查是否存在未包裹在data-masked标签内的敏感格式数据；三是定期人工抽查日志，重点看异常堆栈和请求参数打印，是否夹带了明文敏感信息。审计结果要纳入团队质量看板，脱敏漏洞的修复时效要和线上故障同等对待。

很多公司的脱敏规范停留在“敏感数据要脱敏”这种原则性描述上，开发拿到需求还是不知道怎么执行。一份可落地的脱敏规范手册至少要包含：敏感字段定义表（字段名、敏感类型、脱敏算法、保留位数）、各场景脱敏规则矩阵（公开展示、本人查看、内部运营、系统日志、数据库导出等场景分别的脱敏策略）、代码实现示例（后端工具类、前端组件、日志配置）、审计检查清单、违规处理流程。手册要随着业务变化和监管要求持续更新，每季度至少评审一次。新员工入职的安全培训中，脱敏规范要作为必考项，考试不通过不允许提交代码。

脱敏展示这件事，本质上是在数据可用性和安全性之间找平衡点。过度脱敏会让数据失去业务价值，脱敏不足则是定时炸弹。好的规范不是最严格的，而是最合适的——让该看到的人看到刚好够用的信息，让不该看到的人拿到一堆无意义的星号，同时让整个脱敏过程对业务代码尽可能透明。