1. 项目概述与核心价值

最近在做一个后台管理系统，用户信息管理是绕不开的核心模块。随着大家对隐私保护的意识越来越强，法规也越来越明确，直接明文存储和展示用户的手机号、身份证号这些敏感信息，已经不仅仅是技术问题，更是一个合规风险。我负责的这个项目，就要求必须实现一套完整的数据脱敏方案，确保从数据库存储到前端展示，敏感信息都得到妥善处理。这不仅仅是加个星号那么简单，它涉及到存储策略、查询逻辑、展示规则和权限控制的联动。今天我就把用Java和MySQL搭建这套符合隐私法规的用户信息安全管理后台的核心思路和踩过的坑，详细拆解一遍。

简单来说，这个后台要解决几个核心痛点：第一，数据库里不能存明文敏感数据，防止拖库导致信息泄露；第二，不同角色（比如客服、运营、管理员）看到的信息脱敏程度应该不同；第三，在需要的时候（比如用户本人验证、特定业务审批），授权人员能安全地看到完整信息；第四，整个流程要高效，不能因为脱敏拖慢查询速度。最终，我们基于Java Spring Boot和MySQL，设计了一套“存储加密+动态脱敏+权限网关”的组合方案，实测下来在保证安全性的同时，对性能的影响可控，完全满足了合规要求。

2. 整体架构设计与技术选型考量

2.1 为什么是“加密存储”结合“动态脱敏”？

在方案选型上，我们首先排除了纯前端脱敏和纯数据库视图脱敏。纯前端脱敏风险太高，数据在传输和后台日志中依然是明文。纯数据库视图或函数脱敏，虽然能实现，但把业务逻辑强耦合在数据库层，不利于维护和扩展，尤其是在微服务架构下。

我们最终确定的 核心架构 是： 后端存储层加密 + 业务层动态脱敏 。MySQL数据库里存储的是经过加密的密文，从根源上杜绝数据泄露风险。当业务代码从数据库取出数据后，再根据当前请求者的身份和权限，决定返回给前端的数据是脱敏后的（如 138****1234 ）还是解密后的完整信息。

技术栈选型理由：

  • Java (Spring Boot): 生态成熟，尤其是Spring Security在权限控制方面非常强大，可以无缝集成到我们的脱敏逻辑中。AOP（面向切面编程）能优雅地实现全局的脱敏拦截，避免业务代码被脱敏逻辑污染。
  • MySQL: 项目已有基础，且对于加密字段的等值查询，可以通过对查询条件同样加密后匹配来解决，虽然范围查询会麻烦些，但用户ID、手机号这类敏感信息的查询多以精确匹配为主。
  • 加密算法: 选择了 AES对称加密 。原因在于，同一用户的相同明文（如手机号）每次加密后产生的密文是固定的，这支持了等值查询。密钥管理通过KMS（密钥管理服务）或配置文件结合环境变量隔离，确保安全。非对称加密（如RSA）虽然更安全，但性能开销大，且不支持密文等值查询，不适合海量数据的存储场景。
  • 脱敏规则引擎: 没有引入重型规则引擎，而是基于注解和策略模式自研了一套轻量级规则。例如，用 @SensitiveField(type=FieldType.MOBILE_PHONE) 注解在DTO字段上，在序列化返回前端前，由统一的Jackson序列化器或AOP切面根据注解类型和当前用户权限进行脱敏处理。

注意： 密钥管理是生命线。绝对禁止将加密密钥硬编码在代码或提交到代码仓库。我们采用的方式是：在应用启动时，从安全的配置中心（如阿里云ACM、HashiCorp Vault）或受严格权限控制的服务器环境变量中获取加密密钥。生产环境和测试环境的密钥必须不同。

2.2 系统模块划分与数据流

整个后台可以划分为四个核心模块：

  1. 数据加密存储模块: 负责在数据持久化（INSERT/UPDATE）前，对指定的敏感字段进行加密。
  2. 权限认证与上下文模块: 基于Spring Security，识别当前登录用户的角色和权限，并将这些信息注入到本次请求的上下文（如 SecurityContextHolder 或自定义的 RequestContext ）中。
  3. 动态脱敏处理模块: 在数据查询出来后、返回给前端前，根据权限上下文和预定义的脱敏规则，对DTO对象进行加工。
  4. 解密授权服务模块: 提供一个高权限的、有审计日志的接口，供特定场景（如客服电话核实）临时申请查看完整信息。

数据流清晰明了：用户提交数据 -> 后端加密 -> 存入MySQL密文 -> 查询出密文 -> 根据权限决定是否解密及如何脱敏 -> 返回结果给前端。

3. 核心实现细节与实操要点

3.1 MySQL层：敏感字段的加密存储与查询

首先，不要在数据库层面使用MySQL自带的加密函数（如 AES_ENCRYPT ），因为这会导致密钥暴露在SQL语句或数据库日志中。我们的加密解密过程完全在应用层完成。

实体类与数据库表设计： 

// UserEntity.java
@Entity
@Table(name = "sys_user")
@Data
public class UserEntity {
    @Id
    private Long id;
    private String username; // 明文，用于登录
    @Column(name = "id_card_cipher")
    private String idCardCipher; // 身份证号密文
    @Column(name = "phone_cipher")
    private String phoneCipher; // 手机号密文
    private String email; // 邮箱，可考虑局部脱敏或加密
}

这里将敏感信息单独用 _cipher 后缀字段存储，与明文非敏感字段区分开。

加密服务实现： 

// SensitiveEncryptor.java
@Service
public class SensitiveEncryptor {
    @Value("${sensitive.encrypt.key}")
    private String encryptKey; // 密钥从配置中心注入

    private static final String AES_ALGORITHM = "AES/ECB/PKCS5Padding"; // ECB模式简单，但同明文同密文。如需更高安全可用CBC，但需处理IV。

    public String encrypt(String plainText) {
        // 校验plainText非空
        try {
            Cipher cipher = Cipher.getInstance(AES_ALGORITHM);
            SecretKeySpec keySpec = new SecretKeySpec(encryptKey.getBytes(StandardCharsets.UTF_8), "AES");
            cipher.init(Cipher.ENCRYPT_MODE, keySpec);
            byte[] encryptedBytes = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8));
            return Base64.getEncoder().encodeToString(encryptedBytes);
        } catch (Exception e) {
            throw new RuntimeException("加密失败", e);
        }
    }

    public String decrypt(String cipherText) {
        // 解密逻辑，略
    }
}

在MyBatis或JPA中的集成： 你可以使用 MyBatis的TypeHandler 或 JPA的 @PrePersist 、 @PreUpdate 和 @PostLoad 回调 ，自动完成加密解密。

// UserEntity.java 补充
@EntityListeners(AuditingEntityListener.class)
public class UserEntity {
    // ... fields

    @PrePersist
    @PreUpdate
    public void encryptSensitiveFields() {
        if (this.phoneNumber != null && !this.phoneNumber.startsWith("ENC:")) { // 简单判断未加密
            this.phoneCipher = sensitiveEncryptor.encrypt(this.phoneNumber);
            this.phoneNumber = null; // 清空临时明文字段
        }
        // 同理处理idCard
    }

    @PostLoad
    public void decryptSensitiveFields() {
        // 注意：这里通常不解密，解密应在高权限服务中按需进行。
        // 这里可以解密到一个 transient 字段，仅供内部特定逻辑使用，且需严格权限判断。
    }
}

更优雅的方式是使用MyBatis TypeHandler，在Mapper层参数和结果集映射时自动加解密，这样实体类保持干净。

等值查询的实现： 这是关键点。当需要根据手机号查询用户时，不能对 phone_cipher 字段解密后再匹配（全表解密性能灾难）。正确做法是将查询条件同样加密后匹配。

// UserMapper.xml
<select id="selectByPhone" resultType="UserEntity">
    SELECT * FROM sys_user
    WHERE phone_cipher = #{phoneCipher} <!-- 传入的已经是加密后的字符串 -->
</select>

// service层
public UserDTO getUserByPhone(String plainPhone) {
    String encryptedPhone = sensitiveEncryptor.encrypt(plainPhone);
    UserEntity entity = userMapper.selectByPhone(encryptedPhone);
    // ... 后续脱敏
    return convertToDTO(entity);
}

3.2 业务层：基于权限的动态脱敏策略

数据从数据库取出后（通常是Entity），我们会将其转换为前端所需的DTO（Data Transfer Object）。脱敏就发生在这个转换过程中，或者直接在DTO序列化为JSON时。

第一步：定义脱敏注解与规则枚举 

// SensitiveField.java
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@JacksonAnnotationsInside
@JsonSerialize(using = SensitiveJsonSerializer.class) // 指定自定义序列化器
public @interface SensitiveField {
    SensitiveType type();
}

// SensitiveType.java
public enum SensitiveType {
    /** 中文名 */
    CHINESE_NAME,
    /** 身份证号 */
    ID_CARD,
    /** 手机号 */
    MOBILE_PHONE,
    /** 邮箱 */
    EMAIL,
    /** 银行卡号 */
    BANK_CARD
}

第二步：实现自定义Jackson序列化器 这是核心，它集成了权限判断。

// SensitiveJsonSerializer.java
public class SensitiveJsonSerializer extends JsonSerializer<String> implements ContextualSerializer {
    private SensitiveType sensitiveType;

    public SensitiveJsonSerializer() {}
    public SensitiveJsonSerializer(SensitiveType type) { this.sensitiveType = type; }

    @Override
    public void serialize(String value, JsonGenerator gen, SerializerProvider provider) throws IOException {
        if (value == null) {
            gen.writeNull();
            return;
        }
        // 关键：获取当前用户权限上下文
        UserAuthContext authContext = SecurityContextUtil.getCurrentUser();
        boolean needMask = true; // 默认需要脱敏

        if (authContext != null) {
            // 规则1：用户本人查看自己的信息，通常可以看完整手机号（后几位）
            if (authContext.getUserId().equals(getCurrentTargetUserId(gen))) { // 需要从序列化上下文中获取当前对象ID
                needMask = false; // 或部分脱敏
            }
            // 规则2：拥有特定权限的角色，如“SENSITIVE_DATA_VIEW”
            if (authContext.hasPermission("SENSITIVE_DATA_VIEW")) {
                needMask = false;
            }
            // 规则3：根据角色细化，例如客服只能看后4位，运营看后6位，管理员看全部
        }

        String result = needMask ? mask(value, sensitiveType) : value;
        gen.writeString(result);
    }

    private String mask(String value, SensitiveType type) {
        switch (type) {
            case CHINESE_NAME: return DesensitizedUtil.chineseName(value); // -> "张*"
            case ID_CARD: return DesensitizedUtil.idCardNum(value, 6, 4); // -> "110101********1234"
            case MOBILE_PHONE: return DesensitizedUtil.mobilePhone(value); // -> "138****1234"
            case EMAIL: return DesensitizedUtil.email(value); // -> "a***@b.com"
            default: return value;
        }
    }

    @Override
    public JsonSerializer<?> createContextual(SerializerProvider prov, BeanProperty property) {
        SensitiveField annotation = property.getAnnotation(SensitiveField.class);
        if (annotation != null) {
            return new SensitiveJsonSerializer(annotation.type());
        }
        return this;
    }
}

第三步：在DTO上使用注解 

// UserDTO.java
@Data
public class UserDTO {
    private Long id;
    private String username;
    @SensitiveField(type = SensitiveType.MOBILE_PHONE)
    private String phoneNumber; // 这个字段在序列化时会被拦截处理
    @SensitiveField(type = SensitiveType.ID_CARD)
    private String idCard;
    private String email;
}

这样，在Controller返回 UserDTO 对象时，Spring MVC默认的Jackson序列化器就会调用我们的 SensitiveJsonSerializer ，根据当前用户权限自动决定输出脱敏还是明文。

3.3 权限上下文与细粒度控制

脱敏的核心驱动力是权限。我们利用Spring Security的 Authentication 对象来承载权限信息。

自定义UserDetails： 

public class CustomUserDetails implements UserDetails {
    private Long userId;
    private String username;
    private Set<String> permissions; // 权限标识集合，如 ["USER_VIEW", "SENSITIVE_DATA_VIEW"]
    // ... getters and setters
}

在登录认证成功后，将用户的权限列表查询出来，放入 CustomUserDetails 。

权限判断工具类： 

// SecurityContextUtil.java
public class SecurityContextUtil {
    public static CustomUserDetails getCurrentUser() {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        if (authentication != null && authentication.getPrincipal() instanceof CustomUserDetails) {
            return (CustomUserDetails) authentication.getPrincipal();
        }
        return null; // 或匿名用户
    }

    public static boolean hasPermission(String permission) {
        CustomUserDetails user = getCurrentUser();
        return user != null && user.getPermissions().contains(permission);
    }
}

在脱敏序列化器中，就是调用这个工具类来获取当前用户的权限，进行细粒度判断。权限数据可以来自数据库、Redis缓存，确保高效。

4. 高级功能与审计日志

4.1 临时解密与授权审批流程

有些场景下，低权限用户（如客服）需要临时查看用户的完整手机号来处理客诉。我们不能直接给客服永久权限，而是要走一个 临时授权审批流程 。

  1. 前端发起申请： 客服在界面上点击“查看完整手机号”，提交申请，包含事由（如“用户投诉未收到短信，需核实手机号”）。
  2. 后端生成审批单： 创建一个 DataAccessAudit 记录，状态为“待审批”，关联操作人、目标用户、敏感字段类型、申请理由。
  3. 管理员审批： 拥有审批权限的管理员在后台收到待办，审核通过或拒绝。审批通过后，系统生成一个 有时效性的访问令牌（Token） ，例如有效期为10分钟。
  4. 令牌化访问： 客服前端使用这个令牌，调用一个特定的高权限API（如 GET /api/secure/user/{userId}/phone?token=xxx ）。该API校验令牌的有效性、权限和范围。
  5. 执行解密并记录： 服务端校验通过后，从数据库取出密文，解密，返回完整信息。同时，在 DataAccessAudit 记录中更新状态为“已授权”，并记录访问时间、IP等信息，完成闭环审计。

这个流程确保了每次对敏感数据的访问都是可追溯、有理由、受控的。

4.2 完整的审计日志设计

除了临时解密的审计，所有对敏感数据的操作（包括加密存储、解密查看）都应记录审计日志。审计日志表 audit_log 应包含以下核心字段：

  • id : 主键
  • operator_id : 操作人ID
  • operator_name : 操作人姓名
  • target_type : 目标类型（如“用户信息”）
  • target_id : 目标数据ID
  • operation : 操作（“QUERY_SENSITIVE”, “UPDATE”, “EXPORT”等）
  • sensitive_field : 涉及的敏感字段（“phone”, “id_card”）
  • detail_before : 变更前内容（脱敏后或哈希值，避免记录明文）
  • detail_after : 变更后内容（同上）
  • access_token : 关联的临时令牌（如果有）
  • reason : 操作事由
  • ip_address : 操作IP
  • user_agent : 客户端信息
  • created_at : 操作时间

记录审计日志最好使用AOP或注解，避免业务代码中到处是日志记录语句。例如，可以定义一个 @DataAccessAudit 注解，标注在需要审计的Controller方法上。

5. 性能优化与踩坑实录

5.1 性能瓶颈与优化策略

  1. 加密解密开销： AES加密解密是CPU密集型操作。大量数据插入或查询时可能成为瓶颈。
    • 优化： 对于批量导入操作，可以考虑在应用层分批处理，或使用数据库的批量操作接口，减少网络IO和单条加密的开销。对于查询，务必使用加密后的值进行等值查询，避免全表扫描后逐条解密。
  2. 脱敏规则判断开销： 每次序列化都要走权限判断，如果权限信息需要频繁查询数据库，会影响性能。
    • 优化： 将用户权限信息在登录后缓存到Redis中，并设置合理的过期时间（如30分钟）。在 SecurityContextUtil 中优先从缓存获取权限。
  3. 模糊查询难题： 手机号加密后，失去了原顺序性，无法进行 LIKE ‘138%’ 这样的模糊查询。这是加密存储的固有代价。
    • 妥协方案：
      • 业务规避： 重新设计产品逻辑，尽量不依赖敏感信息的模糊查询。例如，通过用户ID、昵称、注册时间等非敏感字段进行检索。
      • 冗余明文字段（部分）： 在极端且合规允许的情况下，可以存储一个“手机号前缀”的明文字段（如前3位），用于非常粗略的筛选，但这会降低安全性，需谨慎评估。
      • 使用可搜索加密（Searchable Encryption）： 这是一项前沿技术，但实现复杂，性能损耗大，目前在生产环境中大规模应用较少。

5.2 常见问题与排查技巧

问题1：加密后数据无法匹配查询。

  • 排查： 首先确认加密密钥是否一致。检查加密算法和模式（AES/ECB/PKCS5Padding）是否完全一致。确保待加密的字符串没有不可见的空格或特殊字符。 调试时，可以写一个单元测试，用相同的明文和密钥加密两次，看结果是否相同。

问题2：脱敏注解不生效。

  • 排查： 检查DTO对象是否被正确的Jackson ObjectMapper 序列化。在Spring Boot中，默认的 ObjectMapper 会扫描注解。如果使用了 new ObjectMapper() ，则需要手动注册模块。检查自定义的 SensitiveJsonSerializer 是否被正确实例化和调用。可以在 serialize 方法里打日志。

问题3：权限上下文获取为null。

  • 排查： 这通常发生在异步调用（如 @Async ）或新线程中。Spring Security的上下文默认是线程绑定的。解决方案是：在异步任务执行前，手动将上下文传递过去。 
    @Async
public void asyncTask() {
    // 错误：这里SecurityContextHolder.getContext()可能是空的
}
// 正确做法
@Async
public void asyncTask() {
    Authentication originalAuth = SecurityContextHolder.getContext().getAuthentication();
    // 在新线程中重新设置
    SecurityContextHolder.getContext().setAuthentication(originalAuth);
    // ... 执行任务
}
    或者使用Spring Security提供的 DelegatingSecurityContextRunnable 等工具类。

问题4：审计日志表数据量增长过快。

  • 排查： 审计日志只记录关键操作。避免将普通的查询操作也记录。可以对日志进行分级，例如只记录 QUERY_SENSITIVE （查看敏感信息）和 UPDATE （修改信息）操作。定期（如每月）将旧的审计日志归档到历史表或冷存储中。

问题5：密钥轮换问题。

  • 场景： 出于安全考虑，需要定期更换加密密钥。但旧密钥加密的历史数据如何解密？
  • 方案： 实现 多密钥版本管理 。在加密后的密文前，或单独的元数据字段中，存储一个 key_version （如 v1 , v2 ）。解密时，根据版本号选择对应的密钥。密钥轮换是一个有计划的操作：新数据用新密钥加密，旧数据在后台有低优先级任务逐步重新加密（解密后用新密钥再加密）。这个过程必须保证数据一致性和服务可用性。

这套基于Java和MySQL的数据脱敏与安全管理方案，我们从设计到上线花了近两个月，期间在密钥管理、模糊查询妥协、异步任务权限传递这几个点上踩坑最多。最终上线的系统，在通过内部安全审计和外部合规检查时，都获得了不错的评价。它的核心价值在于，将隐私保护从一种被动的合规要求，转变为了主动的、嵌入到研发流程中的技术能力。对于任何处理用户敏感信息的后台系统，这类设计都应该是标配而非选配。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

让飞牛NAS多一个AI管家：Hermes常驻运行、微信调用与远程管理

avatar AI Agent技术社区

2026年企业级Agent工具深度横评：对标Claude Code的选型指南

最近调研了多款主流企业AI Agent工具，覆盖国内主流办公生态产品与海外成熟开发类Agent，最终选择了飞书 aily，核心原因是它能把AI生成能力和国内团队日常协作流程深度打通，不需要额外做跨系统适配就能直接落地到真实业务场景中。

avatar AI Agent技术社区
cover

agent面试必备43-AI Agent 核心架构：高级记忆框架（MemGPT / Mem0）

avatar AI Agent技术社区