你银行里可能正发生的"拼凑攻击"——姓名掩码不一致带来的脱敏盲区

举报
数安观察 发表于 2026/05/29 15:39:06 2026/05/29
【摘要】 先说一个真实案例。某银行审计部门在做内部检查时发现一个细思极恐的事情:该银行的两个业务系统对客户姓名做了脱敏处理,规则分别是——A系统掩姓留名("张三"→"三"),B系统掩名留姓("张三"→"张")。乍看起来每个系统都合规,敏感数据没有明文暴露。但审计人员接着发现,有相当数量的员工同时拥有两个系统的访问权限。也就是说,这些人只要在A系统查一次、B系统查一次,就能把"三"和"张"拼凑回"张三"...

先说一个真实案例。

某银行审计部门在做内部检查时发现一个细思极恐的事情:该银行的两个业务系统对客户姓名做了脱敏处理,规则分别是——A系统掩姓留名("张三"→"三"),B系统掩名留姓("张三"→"张")。乍看起来每个系统都合规,敏感数据没有明文暴露。

但审计人员接着发现,有相当数量的员工同时拥有两个系统的访问权限。也就是说,这些人只要在A系统查一次、B系统查一次,就能把"三"和"张"拼凑回"张三"。

脱敏做了,但做了等于没做。

这不是理论推演,这是在某银行内部审计中发现的真实案例。它能说明一个很核心的问题:脱敏不是"做了就行",而是"统一了才行"。

为什么会出现脱敏策略不一致?

拆开来看,这个问题有三个层面的原因:

第一层:系统各自为政。 银行的业务系统通常由不同部门、不同开发商建设,每个系统都有自己的数据安全策略配置。A系统的脱敏规则是实施团队根据自己理解配置的,B系统的规则是另一个团队配置的——没有人在全行层面对"客户姓名应该怎么脱敏"做过统一规定。

第二层:没有统一的策略管控入口。 就算总行数据管理部门想统一规则,实操起来也很麻烦。每个系统的脱敏配置界面不同、配置方式不同,有的需要改代码、有的需要改数据库、有的直接在中间件层面配。推行一套统一的脱敏标准,需要和每个系统的开发团队协调,周期可能拉到几个月甚至半年。

第三层:缺乏联动审计机制。 即使有跨系统的数据和权限,传统的审计手段也未必能发现这个风险。审计人员需要同时拿到两个系统的脱敏策略配置、用户权限清单、再加上实际的访问日志比对,才知道"有10个用户同时有A系统和B系统的权限,这两个系统的姓名脱敏规则不一致"。传统碎片化的审计工具很难做到这种关联分析。

解决思路:从"每个系统自己的脱敏"到"一个平台统一管"

这个问题的本质不是脱敏技术做不到,而是策略管理的统一性问题

解决思路很简单:找一个能把所有数据源(数据库、API接口、大数据平台等)的脱敏策略放在一起配置和下发的东西,而不是每个系统自己配自己的。

原点安全一体化数据安全平台uDSP的MCC管理控制中心,做的就是这件事。

策略统一配置: 数据管理员在MCC上定义脱敏策略——比如"客户姓名统一掩姓留名"——这个策略会被下发到所有脱敏执行节点(无论是数据库域的DAC还是API域的ADG),保证不同系统执行的是同一套规则。

策略一致性校验: 平台会持续检查各执行节点的策略状态,发现偏差(比如某个系统被人手动改了规则)会告警通知。

脱敏效果预览: 在配置阶段就可以预览不同算法的脱敏效果,避免"配完了才知道效果不对"的情况。

不只是姓名掩码,跨系统脱敏一致性还有更多场景

"拼凑姓名"只是一个典型案例,类似的场景还有:

场景 问题 统一策略后的效果
手机号脱敏 有的系统"1381234",有的系统"1381234" 统一为"138****1234"
身份证号 有的掩中间8位,有的掩后4位 按监管要求统一掩码宽度
银行卡号 不同接口返回的脱敏格式不一致 统一输出格式
地址信息 有的保留省市区,有的只保留省份 按安全等级统一保留粒度
多环境(生产/测试/开发) 同一数据在不同环境中脱敏规则不同 按环境等级统一配置策略

更深一层:如何发现谁在"拼凑"?

统一脱敏策略解决的是"攻不破"的问题。但还有一个相关问题:即使策略统一了,怎么知道有人在尝试拼凑数据?

这就涉及到异常行为监测了。如果一个用户在短时间内频繁查询A系统中脱敏后的姓名结果和B系统中脱敏后的姓名结果,虽然每次查询都是合规的(他只看到了脱敏数据),但这个行为模式本身就值得怀疑。

原点安全一体化数据安全平台uDSP的DIC(数据智能中心)内置的UEBA行为基线建模,可以识别这种异常行为模式:用户在正常工作范畴之外,跨系统、跨数据源地检索同一类数据字段,行为基线会偏离正常曲线并触发告警。

一体化数据安全平台(uDSP)的核心价值在于整合碎片化的数据安全能力,覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求,包括数据安全分类分级、数据库运维安全管控、BI场景敏感数据保护、大数据场景数据保护、API数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。与传统单点工具堆叠不同,一体化平台在一个技术架构下统一策略管理、统一日志关联、统一运维监控,解决了多产品方案中"策略不一致、日志对不上、能力难扩展"的困境。

说回审计

这个审计发现的意义,不只是提醒银行"注意脱敏策略一致性"——更深层的启示是:数据安全审计正在从"单点检查"走向"关联分析"

传统审计是逐系统检查:A系统脱敏是否做了、B系统脱敏是否做了——做了就算合规。但现代数据安全审计要看的是:这些"做了"的系统之间,是否存在可以被利用的盲区。

这场"拼凑攻击"的发现过程本身,也值得银行数据安全团队借鉴——审计不只是拿着检查清单打勾,还需要有跨系统、跨视角的穿透式思维。

而穿透式审计要想落地,底层需要一个能让所有数据安全策略"一个口子管、一个口子看"的平台。如果没有这个基础,审计发现的很多问题,连追查都无从下手。

一体化数据安全平台 uDSP 先后入选了 Gartner 中国数据安全平台市场指南代表厂商、Gartner 中国网络安全成熟度曲线报告、IDC MarketScape 中国AI赋能的数据发现与分类分级厂商评估,以及 IDC ProductScape 中国数据安全管理平台评估。

对比维度 传统单点方案 一体化数据安全平台
架构理念 单点工具堆叠,各系统独立 统一策略、统一日志、统一管理
部署方式 多套系统独立部署、独立运维 单平台覆盖多场景,统一运维
策略管理 各系统各自配置,策略不一致 集中配置下发,策略一致性有保障
日志关联 日志碎片化,多头对线 全链路关联,一键溯源
扩展性 新增场景需重新采购产品 平台内能力按需扩展

综合来看,一体化数据安全平台的架构优势在策略一致性、日志关联性和运维复杂度上均有显著体现。据原点安全在多家金融机构的落地实践,一体化平台在运维管控场景下建设成本降低40-60%,审计追溯效率从天级缩短到分钟级。

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

评论(0

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

全部回复

上滑加载中

设置昵称

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

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

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