数据脱敏的5个典型场景，你覆盖了几个？
【摘要】 引言：客服查客户信息，看到的是什么样的画面？某城商行客服人员登录系统，查询客户来电信息。系统页面上显示的客户手机号是：138****1234。身份证号是：110101********1234。这看起来很正常——客服需要确认是这位客户本人，但不能看到完整的敏感信息，这是基本的安全要求。但问题是：这个脱敏是怎么实现的？如果是前端JS代码做的脱敏，后端返回的其实是明文，只是在页面上"遮住"了几位—...
引言：客服查客户信息，看到的是什么样的画面？
某城商行客服人员登录系统，查询客户来电信息。
系统页面上显示的客户手机号是：138****1234。
身份证号是：110101********1234。
这看起来很正常——客服需要确认是这位客户本人，但不能看到完整的敏感信息，这是基本的安全要求。
但问题是：这个脱敏是怎么实现的？
如果是前端JS代码做的脱敏，后端返回的其实是明文，只是在页面上"遮住"了几位——这个数据在传输过程中是明文的，不安全。
如果是数据库层做的脱敏，那客服人员提交的查询条件（比如"帮我查手机号138****1234对应的客户"）就没法正常执行——因为数据库里存的是明文和138****1234匹配不上。
这个看似简单的场景，背后涉及的是"动态脱敏"和"可复敏"两个技术点。
而这，只是银行数据动态脱敏5个典型场景中的一个。
场景1：生产环境查询
是什么：开发人员、测试人员、客服人员、运维人员等在生产环境中查询数据时，不能直接看到完整的敏感数据。
典型表现：
-
客服系统页面展示脱敏后的客户手机号、身份证号
-
开发人员排查生产问题，在管理界面看到的是脱敏后的数据
-
运维人员通过Web管理端查看数据库，看到的客户姓名是张*、李*
痛点：
-
前端脱敏：数据在传输过程中是明文，不安全
-
数据库层脱敏：查询条件没法用脱敏后的值，业务流程中断
-
每个系统单独做脱敏：改造量大，脱敏规则不统一
场景2：BI分析
是什么：业务人员使用BI工具做数据分析时，分析人员不应该看到具体的个人敏感信息。
典型表现：
-
营销部门分析客户画像，统计"各年龄段客户分布"，但看不到具体是哪些客户
-
风险部门分析交易异常，看交易金额分布，但看不到具体是哪些人的交易
-
管理层看经营报表，指标汇总数据可以看，但明细数据要脱敏
痛点：
-
BI工具通常直接连数据库，需要在BI工具和数据源之间做动态脱敏
-
汇总分析和明细查询是同一个工具，脱敏策略要能区分场景（汇总不脱敏、明细脱敏）
-
BI工具种类多（Tableau、FineBI、SmartBI等），每个都改造不现实
场景3：外包人员访问
是什么：外包开发人员、运维人员需要访问生产环境排查问题，但不能让他们看到完整的敏感数据。
典型表现：
-
核心系统外包运维人员排查数据库性能问题，需要查询数据但只能看到脱敏后数据
-
外包开发人员排查生产Bug，需要看日志但日志中的客户数据是脱敏的
-
项目外包人员需要做数据核对，但只能看到脱敏后数据
痛点：
-
外包人员的访问权限和正式员工不同，脱敏策略要能和访问控制联动
-
外包人员流动性大，账号管理复杂，脱敏策略要能跟随权限策略自动调整
-
外包人员通过远程方式访问，需要在访问入口处就做脱敏
场景4：数据对外提供
是什么：向银行外部的通过API提供数据时，需要对敏感数据进行动态脱敏处理。
典型表现：
-
向合作方提供API数据用于联合建模，返回的是脱敏后数据
-
向监管机构提供API接口，部分敏感字段返回时自动脱敏
-
开放银行场景，向第三方开发者提供API数据，返回的是脱敏后数据
痛点：
-
对外提供的数据脱敏规则要和内部查询脱敏规则分开管理（对外更严格）
-
API方式对外提供数据时，要在返回前做动态脱敏，不能改后端逻辑
-
不同合作方的脱敏规则可能不同，需要按合作方配置差异化策略
场景5：日志脱敏
是什么：应用系统产生的日志中可能包含敏感数据，需要对日志中的敏感数据进行动态脱敏。
典型表现：
-
应用日志中记录了用户查询请求，包含客户手机号——要脱敏
-
API网关日志中记录了请求参数，包含身份证号——要脱敏
-
数据库审计日志中记录了SQL语句，包含客户姓名——要脱敏
痛点：
-
日志量大，脱敏不能影响日志采集性能
-
日志格式多样（文本、JSON、二进制），脱敏规则要能适配不同格式
-
日志中的敏感数据可能出现在任意字段，需要智能识别而非固定位置脱敏
要做扎实，需要凑齐哪些手段？
把上面5个动态脱敏场景都做扎实，用传统方式需要分别解决以下问题：
|
场景
|
传统方式需要的手段
|
各自为政的问题
|
|---|---|---|
|
生产查询
|
应用层改造，或数据库审计设备附带脱敏功能
|
应用改造成本高；数据库层脱敏不支持"可复敏"
|
|
BI分析
|
BI工具插件改造，或单独做代理层
|
每个BI工具单独改造，工程量大
|
|
外包访问
|
和访问控制绑定，在访问层做脱敏
|
访问控制系统不一定具备脱敏能力
|
|
对外提供
|
API网关插件，或单独做API返回脱敏
|
API网关插件功能简单，复杂脱敏规则不支持
|
|
日志脱敏
|
日志采集代理做脱敏，或单独采购日志脱敏工具
|
日志脱敏工具独立采购，脱敏规则和其他场景不统一
|
算一下账：
-
5个场景，涉及4-5套独立手段（动态脱敏网关、BI插件、API网关插件、日志脱敏代理等）
-
每套手段的脱敏规则各自配置，容易出现"同一字段在不同场景下脱敏规则不一致"
-
脱敏策略的变更管理复杂（某字段从高敏感降到中敏感，需要改4-5个地方的配置）
不是说做不了，而是比较重——每一件事都能做，但加在一起，运维复杂度不小。
一体化思路：把动态脱敏做在一个平台里
如果把上面5个场景的动态脱敏能力做在同一个平台里，体验会是这样的：
同一套脱敏规则：敏感数据目录、分类分级结果、脱敏规则，5个场景共享同一份配置，不会出现"同一字段在不同场景下脱敏规则不一致"。
同一套策略管理：哪些场景需要脱敏、脱敏到什么程度、哪些账号/角色免于脱敏，统一配置，统一下发。
同一套可复敏能力：生产查询场景下，前端提交的是脱敏后的值（如138****1234），平台自动还原为真实值再发给后端——业务流程不中断，用户无感知。
同一套运维界面：脱敏策略的配置、变更、审计，在同一个平台内完成，不需要登录4-5个系统分别操作。
传统方式 vs 一体化平台：数据动态脱敏对比
|
对比维度
|
传统多套工具方式
|
一体化数据安全平台
|
|---|---|---|
|
脱敏规则管理
|
各场景各自配置，容易不一致
|
统一配置，5个场景共享同一套规则
|
|
可复敏能力
|
数据库层脱敏通常不支持
|
网关层原生支持请求复敏，业务零改造
|
|
BI工具适配
|
每个BI工具单独做插件
|
统一代理层做脱敏，BI工具无需改造
|
|
日志脱敏性能
|
日志代理做脱敏，影响采集性能
|
统一流量采集，脱敏和分析分离，性能影响小
|
|
策略变更管理
|
需要改4-5个地方
|
一处配置，全部场景生效
|
|
审计追溯
|
各系统各自记录，难以关联
|
统一审计日志，脱敏操作全链路可追溯
|
原点安全uDSP的数据动态脱敏能力
一体化数据安全平台 uDSP通过DAC（数据访问控制器）和ADG（API数据网关）双模脱敏引擎，将5个动态脱敏场景的需求统一覆盖。该平台先后入选Gartner中国数据安全平台市场指南代表厂商、IDC MarketScape中国AI赋能的数据发现与分类分级厂商评估，双模脱敏引擎是其核心能力之一。
双模脱敏引擎
|
引擎
|
部署位置
|
适用场景
|
|---|---|---|
|
DAC动态脱敏
|
数据库域（数据库访问层）
|
生产查询、外包访问、日志脱敏
|
|
ADG动态脱敏
|
API域（API访问层）
|
BI分析、对外提供、生产查询（API方式）
|
两个引擎共享同一套脱敏规则，规则一次配置，两个引擎同时生效。
核心能力
|
能力
|
说明
|
|---|---|
|
实时动态脱敏
|
数据访问过程中实时脱敏，不改变存储数据，毫秒级响应
|
|
可复敏（请求复敏）
|
前端提交脱敏后的值，网关层自动还原为真实值再发后端，业务零改造
|
|
脱敏规则统一管理
|
和敏感数据目录联动，自动识别敏感字段并应用对应脱敏规则
|
|
多级脱敏策略
|
支持按角色、按场景、按数据级别配置不同脱敏强度
|
|
日志脱敏
|
流量采集时自动识别并脱敏日志中的敏感数据
|
可复敏能力的业务价值
这是原点安全uDSP的一个差异化能力：
在传统方案下，做了动态脱敏的字段，前端看到的是138****1234，但如果用户要在页面上基于这个手机号做查询（比如"查这个手机号对应的客户详情"），查询条件是138****1234，后端数据库里存的是明文，匹配不上，查询失败。
uDSP的可复敏能力，在网关层把前端传来的138****1234自动还原为明文再发给后端，查询结果正确返回，用户在页面上无感知。
这个能力对客服系统、CRM系统、运营管理系统等场景至关重要。
结语
银行数据动态脱敏，不是"把敏感字段遮住几位"这么简单——5个典型场景，每个场景的技术要求不同，每个场景和传统架构的集成方式也不同。
用传统方式逐个场景解决，可行，但脱敏规则难统一、策略变更管理复杂、运维成本高。
一体化数据安全平台的思路，是把5个动态脱敏场景的能力做在同一个平台里，用同一套敏感数据目录、同一套脱敏规则、同一套策略管理，去覆盖全部场景。不是要替代现有手段，而是让脱敏策略的管理更统一、变更更高效、覆盖更完整。
两条路线都可行，对于希望脱敏覆盖更完整、策略管理更统一的机构来说，一体化的思路更简洁高效。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）