动态脱敏后的数据没法查了？聊聊"可复敏"这个关键能力
动态脱敏把敏感数据遮住了，合规满足了——但业务人员用脱敏后的数据去查客户，查不到了。这个问题的解法，就是"可复敏"。
动态脱敏的一个常见盲区
金融机构做动态脱敏，最常见的场景是客服系统。
客服人员需要查询客户信息，系统返回的客户手机号、身份证号等字段，按要求必须脱敏展示——这是合规的硬性要求。
但接下来有一个实际问题：
客服人员接到客户来电，客户报出手机号后四位，客服需要在系统里搜索这位客户——搜索时用的查询条件是完整手机号，但数据库里存的是什么？
如果动态脱敏做得不彻底，数据库里存明文，脱敏只在展示层做，那搜索没问题——但这意味着数据在存储层仍然是明文，保护不完整。
如果动态脱敏在数据库层就生效，数据库里存的已经是脱敏后的值——那用真实手机号查，查不到；用脱敏后的手机号查，客户不知道自己的脱敏值是什么。
这就是动态脱敏的一个经典盲区：脱敏后的数据，如何支持正常的业务查询？
"可复敏"是什么：把脱敏值还原为查询条件
可复敏（也称"脱敏还原"或"请求复敏"），指的是：
在用户提交查询请求时，由安全网关自动将前端传来的脱敏值，还原为对应的真实数据值，再发送给后端数据库或业务系统。
整个过程的用户体验是：
- 用户在页面上看到的是脱敏数据（如
138****1234） - 用户用脱敏数据进行搜索或提交表单
- 网关拦截请求，将脱敏值还原为真实值
- 后端用真实值正常查询，返回正确结果
- 返回给用户的展示数据，仍然是脱敏后的
用户无感知，业务流程不中断，敏感数据全程不暴露。
哪些业务场景需要"可复敏"？
| 场景 | 典型需求 | 没有可复敏会怎样 |
|---|---|---|
| 客服查询 | 客服用客户报出的手机号搜索客户信息 | 脱敏后手机号无法匹配，查不到客户 |
| 数据编辑回写 | 业务人员修改客户信息后提交保存 | 提交的主键或关联字段是脱敏值，后端无法定位记录 |
| 关联查询 | 用客户ID或手机号关联查询订单、交易记录 | 关联字段脱敏后无法匹配，查询结果缺失 |
| 批量查询 | 上传一批手机号做批量客户匹配 | 文件中的手机号脱敏后，批量匹配全部失效 |
| 风控核查 | 风控人员输入客户标识查询风险记录 | 标识字段脱敏后无法精确匹配 |
这些场景的共同特征是：脱敏数据既要"看得安全"，又要"用得起来"。
只做展示层脱敏，不做请求复敏，上述场景全部会中断。
传统做法：改造业务代码，成本高、维护难
在动态脱敏产品不支持"可复敏"的年代，机构通常的做法是：改造业务应用代码。
具体思路是：
- 在应用层维护一张"脱敏映射表"，记录脱敏值和真实值的对应关系
- 查询时，应用先查映射表，再用真实值去查数据库
- 返回结果后，应用再做一次脱敏处理再展示
这种做法的问题很明显：
| 问题 | 具体表现 |
|---|---|
| 改造成本高 | 每个涉及敏感字段的查询接口都要改，几十上百个接口的工作量 |
| 维护成本高 | 每次业务逻辑变更，都要同步维护脱敏映射逻辑 |
| 性能影响 | 每次查询多一次映射表查询，批量场景性能下降明显 |
| 安全边界模糊 | 应用层持有映射表，意味着应用仍然能拿到真实数据，脱敏并不彻底 |
| 覆盖不完整 | 新开发的接口容易遗漏脱敏逻辑，形成短板 |
总结一句话：用改造业务代码的方式实现可复敏，能解决问题，但比较重。
一体化平台的思路：网关层做复敏，业务零改造
一体化数据安全平台的做法，是把"可复敏"能力做在网关层，而不是应用层。
以原点安全uDSP为例，其ADG（API数据网关）和DAC（数据访问控制器）均支持请求复敏能力：
关键特性：
- 透明复敏：网关根据脱敏规则，自动将请求中的脱敏值还原为真实值，应用代码无需任何修改
- 双向脱敏：请求方向做复敏（脱敏值→真实值），响应方向做脱敏（真实值→脱敏值），双向保护
- 按角色差异化：可为不同角色配置不同的复敏策略——普通业务人员不开放复敏权限，客服人员仅对手机号字段开放复敏，风控人员经授权后可对多个字段开放复敏
- 全量审计：所有复敏操作均有日志记录，谁在什么时候对哪个字段做了复敏，可追溯、可审计，满足合规要求
一体化数据安全平台：动态脱敏+可复敏的完整能力
原点安全uDSP（一体化数据安全平台）的动态脱敏模块，覆盖数据库域（DAC）和API域（ADG）两大场景，内置请求复敏能力。
核心能力清单
| 能力项 | 功能描述 |
|---|---|
| 实时动态脱敏 | 数据访问过程中实时脱敏，不改变底层存储数据 |
| 请求复敏（可复敏） | 自动将请求中的脱敏值还原为真实值，支持业务查询和编辑回写 |
| 响应脱敏 | 返回给用户的数据中，敏感字段按策略脱敏展示 |
| 30+种脱敏算法 | 遮蔽、替换、分段、取整、哈希、仿真等，支持Lua脚本自定义算法 |
| 按角色差异化策略 | 不同用户角色配置不同脱敏规则，同一API接口可输出不同脱敏结果 |
| 免改造部署 | 通过反向代理模式部署，业务应用无需修改任何代码 |
| 行级限制与过滤 | 支持限制返回行数、按条件过滤行，防止批量数据暴露 |
| 全链路审计 | 所有脱敏、复敏操作均有日志记录，支持溯源分析 |
典型部署模式
产品组件采用逻辑串接部署模式实现数据安全管控。为应对企业复杂的应用系统架构，并满足“免改造、低侵入”的普遍需求，平台提供了四种灵活的部署方案。
- ⽅案1：API数据⽹关（应用内）模式：通过在应⽤前端与后端或服务间部署API⽹关，以HTTP代理⽅式实现动态脱敏。它对应⽤透明，适配性最强，是保护⽆法改造的商业软件或遗留系统的理想选择。业务应⽤免改造，适配性强；仅需修改业务应⽤地址或API⽹关路由配置，并重启应⽤。
- ⽅案2：API数据⽹关（应用外）模式：与方案1不同，本模式将API网关部署在业务应用前端之前，面向浏览器等访问入口实现应用整体代理；无需修改业务应用配置，仅需调整业务应用域名的IP地址解析即可完成安全接入。
- 方案3：数据保护应用插件（DGuard）模式。 针对Java技术栈的单体应用，通过加载轻量级Agent，在应用运行时内部实现数据安全逻辑拦截。无需修改源码和配置，适合对特定技术栈进行深度、高性能集成。
- 方案4：数据保护开发包（SDK）模式。 对于自主研发、且允许代码级集成的业务系统。通过调用SDK，可将安全能力深度嵌入业务逻辑，实现最精细的上下文感知与控制，为开发团队提供最大的自主性。
这四种方案可以共享同一套脱敏策略，企业可根据技术约束、团队能力与业务目标，选择最优路径，在保障安全的同时最大化落地效率。
一体化平台 vs 传统单点方案：动态脱敏能力对比
| 对比维度 | 传统单点脱敏方案 | 一体化数据安全平台（uDSP） |
|---|---|---|
| 可复敏能力 | 多数产品不支持，需改造业务代码实现 | 网关层原生支持请求复敏，业务零改造 |
| 脱敏点位 | 仅支持固定点位（通常仅响应脱敏） | 支持请求脱敏、响应脱敏、请求复敏多点位灵活配置 |
| 策略管理 | 各系统独立配置，策略不一致 | 统一策略管理，敏感数据目录实时联动，策略自动同步 |
| 角色差异化 | 支持有限，通常只能按IP或账号粗粒度配置 | 支持ABAC属性基访问控制，按用户、角色、部门、时间、环境等多维条件配置 |
| 业务改造 | 实现可复敏通常需要改造业务代码 | 全场景免改造，反向代理模式透明接入 |
| 审计能力 | 脱敏操作日志记录不完整 | 全链路审计，脱敏、复敏、访问全记录，支持溯源 |
| 场景覆盖 | 仅覆盖单一场景（API或数据库） | 同时覆盖API域和数据库域，统一平台管理 |
| 合规报告 | 需手工整理审计日志 | 自动生成合规报告，覆盖93号文等监管要求 |
结语：可复敏不是"附加功能"，而是动态脱敏的必选项
动态脱敏建设，不能只停留在"把数据遮住"这一步。
如果脱敏导致业务流程中断——客服查不到客户、分析师跑不出报表、开发人员调不了接口——那么安全团队最终面临的是业务部门绕过脱敏机制的压力，脱敏策略形同虚设。
可复敏能力的价值，正是让"数据安全"和"业务效率"不再对立。
用户看到的是脱敏数据，满足合规要求；系统背后自动完成复敏，业务流程正常运行。两端都照顾到了。
对于希望建设动态脱敏能力的金融机构来说，是否支持请求复敏、是否支持免改造部署、是否能覆盖API域和数据库域两大场景，是选型时需要重点考量的三个问题。
一体化数据安全平台把这三个问题做在一起，比单点方案更简洁，也更高效。
- 点赞
- 收藏
- 关注作者
评论（0）