Spring Boot REST应用特定JSON字段加解密通用实现方案咨询

• 加密方案适配场景：
  适合需要前端按需获取明文的场景，比如用户本人查看完整银行卡号、后台风控系统调用原始敏感数据的场景；加密密钥可按业务域、用户级别拆分，权限管控颗粒度更细，符合电子银行类应用的等保要求；注意优先选国密SM4对称加密算法，符合金融行业合规要求。
• 令牌化方案适配场景：
  适合跨系统调用不需要原始敏感数据的场景，比如支付链路中用令牌替代卡号传递，即使链路被窃听也不会泄露真实数据；令牌无业务含义，无法反推原始值，安全性更高，不需要额外维护加密密钥的轮换风险；缺点是需要单独维护令牌和原始值的映射关系，要额外做映射表的高可用和权限管控，适合不需要前端解密拿原始值的场景。

架构选型优先选网关层统一处理 + 微服务注解兜底的组合方案：纯网关层处理无法覆盖微服务内部RPC调用的敏感字段泄露风险，纯微服务单独处理重复代码多、维护成本高，组合方案可以兼顾灵活性和复用性。

1. 可动态刷新的配置项定义 #

配置直接写在application.yml中，对接Nacos/Spring Cloud Config即可实现动态增减字段不需要重启服务，配置示例如下：

sensitive:
  fields:
    # 全局匹配的敏感字段名，所有接口生效
    global:
      - phone
      - email
      - idCard
      - bankCard
      - taxNo
    # 按接口路径定制的敏感字段，优先级高于全局配置
    path-specific:
      /api/user/info: [ 'realName' ]
      /api/account/bank-list: [ 'branchName' ]
    # 各字段掩码规则配置
    mask-rule:
      phone: "3****4" # 前3位、后4位保留，中间掩码
      email: "1****@" # 首字符保留，@前面部分中间掩码
      bankCard: "6****4" # 前6位、后4位保留，中间掩码
  encrypt:
    # SM4加密密钥，建议存在配置中心的加密存储槽，不要明文写配置
    sm4-key: "your-encrypted-sm4-key"
    # 是否返回原始值哈希
    enable-hash: true
    # 哈希盐，建议按用户维度动态生成，安全性更高
    hash-salt: "your-custom-salt"

2. 网关层统一处理逻辑 #

基于Spring Cloud Gateway全局过滤器实现，对业务代码无侵入：

• 响应处理：先匹配当前请求路径对应的敏感字段列表，遍历返回的JSON树，命中敏感字段后直接替换为对应掩码值；如果开启哈希返回，新增${字段名}_hash字段，存储原始值加盐后的SM3哈希值，和掩码值一起返回给前端。
• 解密请求处理：前端需要获取原始值时，单独调用/api/common/decrypt接口，传入字段名和对应哈希值，后端校验请求用户是否有权限获取该字段的原始值、哈希值和原始值匹配通过后，才返回解密后的明文，明文仅存在接口返回的内存中，不做持久化。
• 请求入参解密：前端提交的请求中如果携带加密后的敏感字段，网关层自动识别解密后再透传给后端微服务，业务侧完全感知不到加解密逻辑。

3. 微服务RPC场景兜底处理 #

针对微服务内部调用的敏感字段保护，用Jackson自定义序列化器实现：

• 定义@SensitiveField注解，标注在实体类敏感字段上，可选参数指定该字段的掩码规则，优先级高于全局配置。
• 自定义序列化器实现序列化时自动按规则生成掩码，反序列化时自动解密，配置动态刷新时同步更新序列化器的敏感字段列表，不需要修改业务代码。

4. JS-Redux前端适配逻辑 #

• 在Redux中间件中统一处理后端返回的敏感字段：默认渲染掩码值，把对应字段的哈希值存在Redux的内存store中，禁止存在localStorage/sessionStorage避免泄露。
• 用户触发查看原始值操作时（比如点击「查看完整手机号」按钮），携带对应字段名和哈希值调用后端解密接口，拿到的原始值仅临时存储在当前页面的内存变量中，页面销毁时自动清空。

注意：所有加密、哈希算法必须使用国密SM系列，符合金融行业等保2.0要求；密钥要定期轮换，禁止硬编码在代码中；解密接口要加限流、验证码、用户权限校验规则，避免被暴力遍历泄露数据。

内容的提问来源于stack exchange，提问作者Belf