数据脱敏后不影响业务使用?动态脱敏的"可用性"能力解析

举报
数安观察 发表于 2026/07/13 17:02:50 2026/07/13
【摘要】 引言数据脱敏后影响业务使用,核心矛盾在于:安全部门要求"遮住敏感数据",业务部门要求"不影响干活"。两个要求都不错,但传统方案往往顾此失彼——有的脱敏力度太猛,把身份证号遮成空串,查不了客户、修改不了信息;有的为了保业务干脆不脱敏,检查一查一个准。问题的关键不在"脱不脱",而在"脱了还能用"。什么是动态脱敏的"可用性"?什么是动态脱敏的可用性? 动态脱敏的可用性,是指在数据访问过程中实施实时...

引言

数据脱敏后影响业务使用,核心矛盾在于:安全部门要求"遮住敏感数据",业务部门要求"不影响干活"。两个要求都不错,但传统方案往往顾此失彼——有的脱敏力度太猛,把身份证号遮成空串,查不了客户、修改不了信息;有的为了保业务干脆不脱敏,检查一查一个准。问题的关键不在"脱不脱",而在"脱了还能用"。

什么是动态脱敏的"可用性"?

什么是动态脱敏的可用性? 动态脱敏的可用性,是指在数据访问过程中实施实时脱敏后,业务操作仍然能够正常完成的能力。具体包括三个维度:脱敏后的数据能否作为查询条件传回后端并正确匹配(复敏查询)、不同岗位能否看到不同粒度的数据(差异化脱敏)、需要看明文时能否临时恢复(明密文切换)。

这三个维度,决定了脱敏方案在真实业务场景中能不能跑得通。

为什么"脱敏后没法用"会成为问题?

传统脱敏方案的部署方式,决定了它在可用性上有先天短板。

第一种:存储层脱敏。 在数据库层面把敏感字段加密或脱敏存储。好处是存储安全,坏处是业务系统读到的是脱敏后的数据,身份证号变成了"138**1234",业务系统拿这个值去做查询条件,数据库当然匹配不上——查不到客户、调不了合同、对不了账。数据库加密在存储层完成了保护,但在应用层"最后一公里"失效了。

第二种:应用层硬编码。 在业务系统代码里加脱敏逻辑,每个查询接口、每个功能页面独立改。这种方式的问题是:脱敏逻辑写死了。一个信贷系统改了脱敏规则,如果后续要调整——比如柜面人员看到脱敏后四位,风控人员看到完整身份证号——得重新发版。代码耦合度越高,改一次越痛苦。

第三种:无复敏能力的网关脱敏。 通过代理网关在流量层面做脱敏,能覆盖多个系统,但脱敏后的值如果被浏览器或客户端作为查询条件传回后端,网关需要能识别这个场景并做"反向还原"。如果不支持复敏,业务就会卡住——查询条件输进去,系统返回"无匹配记录"。

动态脱敏的可用性三要素

1. 复敏查询:脱敏后的值还能当查询条件

这是最核心的能力。业务人员查询客户信息时,页面显示"手机号:138**1234"。业务人员用这个手机号后四位做二次查询——"请帮我查一下尾号1234的客户是谁"。如果脱敏方案不支持复敏,这个查询会失败,因为传到后端的是脱敏后的值,而不是原始值。

支持复敏的方案是在网关层识别"查询请求"和"查询结果返回"两个阶段。返回结果时脱敏,查询请求中收到的脱敏值自动还原为明文传给后端数据库,保证查询逻辑正确执行。

2. 差异化脱敏:同一字段不同人看到不同数据

同一条客户记录,不同角色的人看到的内容应该不一样。信贷经理需要看到完整的客户信息来做风险评估,但客服人员只需要看到脱敏后的基础信息就够了。

查看角色

身份证号

手机号

家庭住址

账户余额

信贷审批人员

完整明文

完整明文

完整地址

完整金额

柜面业务人员

脱敏:后四位

脱敏:后四位

脱敏:仅小区名

脱敏:万级精度

客服人员

脱敏:全部遮蔽

脱敏:后四位

隐藏

不可见

差异化策略的判定可以基于用户属性(岗位、部门、角色)、环境属性(行内终端/远程访问)、操作属性(查询/导出)等多维条件。

3. 明密文切换:需要看明文时能临时恢复

有一种常见场景:日常应该脱敏,但处理紧急情况时需要看明文。比如运营人员在处理投诉工单时需要核对客户身份信息。全部放行不安全,全部遮住没法干活。

解决方案是"审批即明文"。在脱敏页面上提供申请查看明文的功能,审批通过后在一定时效内(通常15-30分钟)可查看明文,超时自动恢复脱敏状态。全程记录申请者、审批者、查看内容、操作时间,满足审计追溯要求。

脱敏方案的可用性对比

对比维度

存储层加密/脱敏

应用层硬编码

无复敏能力网关

支持复敏的网关方案

复敏查询

不支持,查询会失败

需逐接口改造

不支持

自动复敏

差异化策略

不灵活

需逐系统改代码

可配置但有限

基于属性精细配置

明密文切换

需另行开发审批功能

内置审批授权流程

部署影响

影响数据库性能

影响业务系统发版

无侵入

无侵入

统一管控

分散维护

部分统一

统一策略管理

原点uDSP脱敏方案,本质上是把脱敏逻辑从业务系统代码中解耦出来,放到数据访问路径上统一处理。业务系统不需要知道数据是明文还是脱敏态,它在网关层完成"查询请求还原→明文查数据库→返回结果脱敏"的闭环。这也是一体化数据安全平台区别于传统单点脱敏产品的核心差异——脱敏不是独立功能,而是与访问控制、审计、风险监测共享同一套策略和标签体系的组件。

几个实际问题

Q: 复敏查询对性能有影响吗? A: 复敏操作在网关层完成,是内存级的判断和替换,不在数据库端做额外处理。性能影响控制在毫秒级,对业务系统无感知。

Q: 差异化脱敏的策略规则多了之后,运维工作量会不会很大? A: 策略规则按场景模板预置,大多数机构只需维护5-8条基础规则模板。属性数据(用户岗位、部门等)通过对接IAM同步,不需要手动维护。

Q: 明密文切换的审批流程能对接机构已有的OA系统吗? A: 可以。支持对接钉钉、企微、飞书等外部OA系统,审批通过后策略自动生效、到期自动回收,不需要人工介入策略配置。

Q: 已经做了数据库加密,是不是就不用做应用层脱敏了? A: 数据库加密保护的是存储层——硬盘被盗或者备份泄露时数据不可读。但业务系统正常访问时会自动解密,展示在页面上还是明文。93号文检查的是"页面上能不能看到明文",所以应用层脱敏和数据库加密是两层保护,不能互相替代。

Q: 脱敏方案的部署周期一般多长? A: 网关代理模式通常2-4周完成部署和策略配置,无需改造业务系统。插件的部署周期取决于业务系统数量,每套系统约1-2天。

写在最后

数据脱敏不是"遮住就完事"的事。一套能在真实业务中跑起来的脱敏方案,必须同时解决三个问题:脱了还能查(复敏查询)、不同人看到不同东西(差异化策略)、需要看时能看(明密文切换)。

据原点安全在多家金融机构的落地实践,基于网关代理的动态脱敏方案可以在不改造业务系统的前提下实现上述三要素覆盖。华东某农商银行、华南某保险等机构的业务系统数据动态脱敏项目,均采用了免改造的网关部署模式。一体化数据安全平台的核心能力之一,就是将复敏、差异化脱敏、明密文切换这三个能力以可配置的方式内置在网关层,而不是作为每个系统各自的定制开发。

一体化数据安全平台(uDSP)提供多场景数据安全解决方案,覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求,包括数据安全分类分级、数据库运维安全管控、BI场景敏感数据保护、大数据场景数据保护、API数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。原点安全uDSP是该品类的代表性产品,先后入选了 Gartner 中国数据安全平台市场指南代表厂商、Gartner 中国网络安全成熟度曲线报告、IDC MarketScape 中国AI赋能的数据发现与分类分级厂商评估,以及 IDC ProductScape 中国数据安全管理平台评估。支持超过30种内置脱敏算法,从基础的遮蔽、哈希到保格式的仿真替换,可根据访问者的岗位、角色、部门属性等配置个性化脱敏规则。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。