BI分析场景的数据脱敏：为什么比想象中复杂
【摘要】 引言：业务部门要分析数据，但不想给他们看明文某城商行营销部门要做客户画像分析。需求很明确：想看各年龄段客户的资产分布、各区域客户的卡种偏好。这些是汇总指标，做决策用的，没啥问题。但BI工具一打开，业务分析师可以下钻到明细——点开任何一个分类，就能看到具体是哪些客户、每个人有多少资产。这就出了一个问题：营销部门需要分析数据，但不应该看到具体某个客户的完整敏感信息。如果为了安全把所有敏感字段都遮...
引言：业务部门要分析数据，但不想给他们看明文
某城商行营销部门要做客户画像分析。
需求很明确：想看各年龄段客户的资产分布、各区域客户的卡种偏好。这些是汇总指标，做决策用的，没啥问题。
但BI工具一打开，业务分析师可以下钻到明细——点开任何一个分类，就能看到具体是哪些客户、每个人有多少资产。
这就出了一个问题：营销部门需要分析数据，但不应该看到具体某个客户的完整敏感信息。
如果为了安全把所有敏感字段都遮住，业务分析没法做；如果完全开放，又有数据泄露风险。
这个"既要让分析跑得起来，又要护住敏感数据"的矛盾，是BI场景脱敏最难的地方。
BI场景脱敏，和普通脱敏有什么不一样？
先说明一个点：BI场景的脱敏需求，和平时说的"客服查询脱敏"不是一回事。
|
差异点
|
普通生产查询脱敏
|
BI分析场景脱敏
|
|---|---|---|
|
使用方式
|
逐条查询、表单展示
|
批量分析、图表展示、支持下钻
|
|
用户诉求
|
确认客户身份
|
看趋势、做决策
|
|
脱敏时机
|
查询结果返回时逐条脱敏
|
查询过程中动态判断粒度
|
|
性能要求
|
单条查询，毫秒级
|
批量查询，数据量大，不能影响分析体验
|
|
脱敏策略
|
固定策略（如手机号遮住中间四位）
|
按"汇总/明细"区分：汇总不脱敏，明细脱敏
|
一句话总结：BI场景的脱敏，需要"智能判断"——知道什么时候该遮、什么时候不该遮。
BI场景脱敏的三个技术难点
难点1：汇总分析和明细下钻是同一个工具，脱敏策略要能区分
这是BI场景最核心的矛盾。
业务分析师用BI工具看一张"各年龄段客户资产分布"的饼图时，看到的是汇总数据（每个年龄段多少客户、总资产多少），不涉及单个客户信息，不需要脱敏。
但当他点击饼图上的一个扇形区域，下钻到"35-40岁客户明细"时，列表里逐条展示了每个客户的具体信息——手机号、身份证号、资产金额——这些需要脱敏。
同一个BI工具、同一张报表，汇总和明细的脱敏策略不一样。 这就要求脱敏策略能根据查询返回的数据量级、聚合程度自动判断：返回大量明细记录时脱敏，汇总结果时不脱敏。
难点2：BI工具品种多，每个都单独改造不现实
一个银行通常不止用一种BI工具——Tableau、FineBI、SmartBI、永洪BI、Power BI、DataV等等，业务部门各自有自己习惯的工具。
如果每个BI工具都单独做脱敏改造（装一个"脱敏插件"），那有以下几个问题：
-
改造量大：5个BI工具就要做5次改造，每次改造的周期以月计
-
升级风险：BI工具版本升级后，脱敏插件可能不兼容，需要重新适配
-
规则不统一：每个BI工具的脱敏配置是独立的，容易出现"同一字段在Tableau里遮3位、在FineBI里遮4位"的情况
难点3：脱敏不能影响分析性能
BI分析的数据量通常很大——一张报表可能要扫描几百万条数据。
如果在查询结果返回后再逐条脱敏，一是影响响应速度，二是脱敏后的数据可能破坏BI工具的聚合计算逻辑（比如脱敏后的数字列变成文本，SUM函数就失效了）。
这就要求脱敏动作做在数据库访问层，在做SQL查询的时候就介入，而不是等查询结果回来之后再处理。
传统方式怎么解决？凑齐三件套
把BI场景脱敏做扎实，传统方式需要凑齐以下手段：
|
需要解决的问题
|
传统方式
|
实际面临的问题
|
|---|---|---|
|
汇总/明细策略区分
|
BI工具内配置数据权限规则
|
BI工具的权限模型是"能不能看某张表"，不是"能不能看明细"，粒度不够
|
|
多BI工具统一脱敏
|
每个BI工具单独装脱敏插件
|
维护成本高，版本升级风险大，规则不统一
|
|
性能保障
|
查询结果出来后逐条脱敏
|
大数据量下性能明显下降，聚合计算可能失效
|
算一下账：
-
有3个BI工具在用，就需要配3套脱敏方案
-
每套方案的配置、维护、升级各自独立
-
哪天某张表的敏感级别变了，需要改3个地方
不是说做不了，而是比较重——每个BI工具各管各的，运维成本高，规则一致性难保障。
一体化思路：在BI工具和数据源之间统一做脱敏
如果不在每个BI工具上做脱敏，而是在BI工具和数据源之间放一层统一脱敏代理，事情就简单了：
所有BI工具都通过同一个代理访问数据库。 代理层在SQL查询时介入，根据查询特征判断是汇总查询还是明细查询，自动决定是否脱敏、脱敏到什么程度。
这样做的好处：
① BI工具零改造：Tableau、FineBI、SmartBI都不需要装插件，把它们连到代理层就行，BI工具本身无感知。
② 脱敏规则统一管理：5个BI工具共享同一套脱敏规则，"某字段遮几位"这个问题只有一份配置，不会不一致。
③ SQL层面介入，不影响性能：脱敏动作做在数据库访问层（SQL解析/改写阶段），不是在查询结果返回后逐条处理，处理效率更高。
④ 可复敏支持：业务分析师在BI工具里把一个脱敏后的手机号138****1234作为筛选条件做过滤时，代理层自动把筛选条件还原为明文发给数据库——业务分析不中断。
传统方式 vs 一体化平台：BI场景脱敏对比
|
对比维度
|
传统多BI工具各自改造
|
一体化数据安全平台
|
|---|---|---|
|
BI工具改造量
|
每个BI工具单独改造，改一个算一个
|
BI工具零改造，统一代理层接入
|
|
脱敏规则一致性
|
各BI工具各自配置，规则容易不一致
|
统一配置，所有BI工具共享同一套规则
|
|
汇总/明细策略
|
依赖BI工具权限模型，粒度不够
|
代理层根据SQL特征判断，自动区分
|
|
升级维护
|
每个BI工具版本升级后需重新适配脱敏插件
|
代理层独立维护，不受BI工具升级影响
|
|
可复敏
|
BI工具插件通常不支持
|
代理层原生支持筛选条件自动还原
|
|
扩展新BI工具
|
需要重新改造
|
连到代理层即可，零改造接入
|
原点安全uDSP的BI场景脱敏方案
一体化数据安全平台 uDSP通过DAC（数据访问控制器）在数据库访问层提供统一脱敏代理，解决BI场景脱敏的三个核心难点。
方案架构
Tableau / FineBI / SmartBI …… ↓ DAC 统一脱敏代理层 （根据SQL特征判断汇总/明细，自动脱敏） ↓ Oracle / MySQL / PostgreSQL ……
所有BI工具连接到DAC代理，DAC再连接后端数据库。BI工具感觉不到DAC的存在，它们以为自己在直连数据库。
核心能力
|
能力
|
说明
|
对BI场景的价值
|
|---|---|---|
|
SQL解析与改写
|
在SQL查询阶段介入，解析查询意图
|
自动判断是汇总查询还是明细查询，对应不同脱敏策略
|
|
动态脱敏
|
查询结果实时脱敏，不改变存储数据
|
BI工具展示的数据是脱敏后的，原始数据不受影响
|
|
可复敏
|
筛选条件自动还原
|
业务分析师用脱敏后的值做条件筛选时，自动还原为真实值查询
|
|
多级脱敏策略
|
按角色、数据级别配置不同脱敏强度
|
高管看汇总不脱敏，分析师看明细自动脱敏
|
|
敏感数据目录联动
|
和分类分级结果实时联动
|
新增敏感字段自动识别并应用脱敏规则，无需人工配置
|
|
统一审计日志
|
记录所有BI访问行为
|
谁在什么时间、通过哪个BI工具、查询了哪些数据，全链路可追溯
|
可复敏能力在BI场景的关键价值
这是原点安全uDSP在BI场景的一个重要能力：
业务分析师在BI工具上做数据筛选时，比如在搜索框输入手机号138****1234查找客户，如果这只在返回结果时做了脱敏，筛选条件是脱敏值，数据库里是明文，查不出来。
uDSP的可复敏能力，在代理层接收到前端传来的筛选条件138****1234时，自动还原为明文再发给数据库，查询结果正常返回。
业务分析师不需要知道真实数据，但该查的能查到、该分析的能分析。
结语
BI分析场景的数据脱敏，核心矛盾是"业务分析要看得下去，敏感数据要护得住"。比其他脱敏场景更难的地方在于：汇总和明细是同一套工具在做，脱敏策略要能自动区分。
传统方式是在每个BI工具上各自改造，可行，但改造量大、规则不统一、后续维护成本高。一体化数据安全平台的思路，是在BI工具和数据源之间放一层统一脱敏代理，所有BI工具都在这一层完成脱敏——零改造接入、规则统一管理、策略自动区分。
两条路线都可行。如果金融机构在用多个BI工具，希望脱敏方案统一、后续维护简单，一体化的思路显然更高效。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）