金融行业数据实时共享场景下的动态脱敏技术

简介: 在信息化大潮愈演愈烈的当下,数据和信息不啻为一种“新型资本”,尤其对于数据资产量巨大,操作复杂程度高、系统性能要求高的金融领域来说,数据资产发挥着越来越突出的价值,和传统资本具有的特性相似,数据资产的价值在流转、共享、整合利用中逐渐显现并越发放大。

“资本只有在流动中才带来价值,单纯存放起来只会贬值”。


在信息化大潮愈演愈烈的当下,数据和信息不啻为一种“新型资本”,尤其对于数据资产量巨大,操作复杂程度高、系统性能要求高的金融领域来说,数据资产发挥着越来越突出的价值,和传统资本具有的特性相似,数据资产的价值在流转、共享、整合利用中逐渐显现并越发放大。


举例来说:银行数据部门掌握的用户储蓄和消费信息,对内共享可以完善业务部门的信息化系统开发;对外则可为政府部门、征信机构等提供有效参考;甚至可以成为零售或制造业制定战略目标的有效参考依据。


然而数据的共享和流转带来的红利,远远无法冲散遮盖在数据保管者和拥有者心头的乌云。这种担忧来自对敏感信息在共享环节可能发生的泄密风险,更是来自敏感数据“合理使用”并且“安全防护”两者之间的矛盾。于是,数据脱敏技术和专业脱敏产品应需而生,这类专业产品可以按照不同数据使用场合,对敏感数据进行变形处理,在脱敏处理的同时,不改变数据的类型、格式、含义、分布等使用特征,让用户不再因为深陷对安全的顾虑,而不得不割舍掉数据分享和流转带来的价值。


目前,脱敏技术中的静态脱敏技术常见于银行等金融领域。静态脱敏技术的应用,其价值在于打造一份全新的、“高度仿真”的数据库,供非安全环境下使用。凭借着低门槛、易部署等特性,静态脱敏技术率先被用户所接受。在近两年,这种数据处理方式先后被银行、证券、保险、社保等行业所采纳,成为数据共享中的重要工具。


但当面对不同身份的访问者,如何实时提供不同的脱敏数据?


某银行搭建的数据集中管理平台中,客户信息、账务信息、银行卡信息等全部集中在大数据分析环境中,面向内部提供数据查询分析服务,面向外部应用端、征信机构、政府部门等则提供数据检索接口。由于不同访问者的身份、权限差异,同样的数据对不同访问者的脱敏策略各不相同。为了实时、安全地向各方提供数据,依靠静态脱敏技术已经不再合适。此时,动态脱敏服务器便成了连接数据中心和外界使用者之间的通道,对不同身份、不同权限的用户配置实时数据脱敏规则,让其可以恰如其“份”的访问数据。


数据的动态脱敏遵循着一套与静态脱敏完全不同的技术路线,今天,我们重点了解一下数据动态脱敏技术,为金融行业未来的技术应用提供一些借鉴思路。


数据动态脱敏,需要满足一个重要的能力:针对目前各种主流的数据库中的敏感数据,在用户使用各种第三方客户端工具或应用程序实时访问数据过程中,能够依据用户角色、职责和其他 IT 定义规则,对敏感数据进行屏蔽、遮盖、变形处理,来“隐藏”对敏感数据的访问,从而有效的防止敏感数据的泄漏。 


国内动态脱敏技术的演进路线


长期以来,提起动态脱敏技术,能力称霸者始终逃不过Informatica,国内外其他厂商在动态脱敏技术领域都难以望其项背,由此可见这一技术的复杂度和成熟产品的研发难度非同一般。2014年,Informatica凭借其DDM产品位居Gartner数据脱敏的领导者象限。


对于国内数据库安全厂商而言,有了其他安全产品的深厚研发积累,朝着数据动态脱敏技术进发也变成一种发展惯性。2016年,国内已经有厂商开始基于长期的数据库防火墙产品所积累下来的数据库协议分析、协议改写、语法分析、SQL语句改写等技术,成功推出数据库动态脱敏产品,并在真实的用户现场,通过与Informatica DDM产品的多次比拼,积累下丰富的“填坑”经验,产品也在不断“填坑”的过程中逐步走向成熟。


那么,面对金融行业的数据共享场景,合格的数据动态脱敏产品要跨越的技术障碍和必须要填的“坑”都有哪些呢?下面我们将站在技术角度抛砖引玉,希望对业内的厂商、专家、用户有所帮助,同时也欢迎“拍砖”,共同进步。


Trap1:select * ,一个简单但是难填的坑。


对于动态脱敏策略,常用做法是指定需要脱敏的字段,或字段通配符,如此一来,必然会面临以下问题:


场景1:配置了字段ABC需要进行脱敏处理,而用户执行的操作是select *,并没有在操作中写明字段名,这种情况还能针对字段ABC成功脱敏吗?


场景2:配置了字段ABC需要进行脱敏处理,但用户的应用系统存在一个功能是“每天自动产生一个包含这个字段的表,并且表中的这个字段的数据也需要脱敏”,应对每天增量产生的表执行select *操作,可以做到及时成功脱敏吗?


技术应对:动态脱敏产品自动的根据用户发起的SQL命令进行分析,并且实时的检查select *这一命令操作的表有哪些字段,并根据实时检查的结果自动的对数据进行脱敏。


Trap2:用户执行的SQL命令中对敏感字段执行了函数转换,是否会造成绕过脱敏的结果?


场景:配置了字段ABC需要进行脱敏处理,用户执行的操作是select substr(ABC,1,2),field1,field3,substr(ABC,2,5) from table,该操作中敏感字段的数据被“拆开”来使用,能够成功脱敏吗?


技术应对:合格的动态脱敏产品,是作用在请求的SQL操作的字段上,而不是对返回的结果集进行变形处理,因为如果这样做会造成无法适应各种复杂的SQL命令而产生结果集数据。


Trap3:词法分析还是语法分析,这是个准确度问题。


目前,动态脱敏主流的实现方式是采用网关或代理的方式(Informatica DDM和安华金和DDM正是采用这种实现方式),在客户端和服务器之间按照策略进行SQL操作的改写,来实现对数据脱敏的效果。这个SQL改写的过程必然需要对SQL语句进行拆包和分析,可供选择的技术路线包括正则匹配、词法分析、语法分析;因为正则匹配非常不准确,所以首先被淘汰掉;接下来就面临到底是选择词法分析还是语法分析的问题了。


众所周知,语法分析是非常复杂的,词法分析则相对简单很多,二者能够达到的脱敏准确度也会不同,见典型场景:


场景:配置表TA的字段ABC需要脱敏,表TB的ABC字段不脱敏;用户执行的SQL操作为select a.ABC,b.ABC from TA a,TB b where a.id=b.id;这个语句需要正确的识别出脱敏对象。


技术应对:通过语法分析,正确的识别a.ABC字段为需要脱敏的字段,b.abc字段不能进行脱敏。


Trap4:执行begin...end语句块,语句块中包含动态SQL语句,如何处理?


场景:配置persionid为需要脱敏的字段,用户在PLSQL客户端工具中执行下面的语句块:



这个语句块中,关键是查询操作是采用拼接的SQL命令并动态执行SQL操作,其结果是通过语法分析无法准确地对需要脱敏的字段进行处理。


技术应对:即使采用了语法分析,这种动态SQL语句也无法被处理;建议采用的策略是禁止这样的操作被执行。


Trap5:WHERE子句中包含敏感字段作为条件字段,脱敏还是不脱敏?


场景:用户配置了persionid字段为敏感字段,执行SQL命令select persionid,datefield from performance_c_1000000 where persionid like '1204581978%';


在这个操作中,会面临一个问题:是否需要对where条件中的persionid字段(红色字体)进行脱敏处理?


如果选择脱敏处理,好处是不会造成通过精确查询进行数据的“猜测”引起的数据泄露;缺点是恐怕很难再通过脱敏字段作为条件进行查询,因为说不清查询的结果会如何,很大可能是查不到结果。


如果不进行脱敏处理,好处是不影响查询操作,该查询到的数据依然能够查到;缺点是数据很可能通过频繁查询可以猜测到真实数据,导致数据仍然存在泄漏风险。


技术应对:无论如何选择,都无法实现最佳效果,相对合理的解决方案是两种都提供,然后根据实际的需求来配置合理的策略。


此外,金融行业对于业务系统的运行稳定性有着严格的要求,而动态脱敏作用于网络层,脱敏系统串接在访问者和敏感数据之间,因此产品需要兼顾高性能与稳定性,不会因脱敏处理导致性能的明显下降,同时兼容全系列数据库协议;另一方面,需要具备高并发条件下的抗压能力,拥有完善的容灾机制;这些都将成为衡量动态脱敏产品成熟度的标准。


在数据安全领域,“禁止”和“防护”固然重要,但是如果背离了数据共享和合理使用的前提,那么数据的价值将大幅度下降。数据脱敏技术,正是兼顾数据“用”、“护”之道的有效手段。无论动态脱敏还是静态脱敏,在金融行业数据安全领域,将越发不可替代,真正为金融用户铸造安全、可靠、高效的数据使用环境。我们看到基于网络层的动态脱敏技术为金融行业的实时数据共享开辟了新的前景。

相关文章
|
机器学习/深度学习 人工智能 自动驾驶
「AIGC」Agent AI智能体的未来:技术、伦理与经济的交汇点
Agent AI智能体融合机器学习与深度学习,推动社会效率与创新,但也引发伦理、法律及就业挑战。技术上,它们能自我优化、积累知识,如自动驾驶汽车通过学习改善驾驶。伦理上,需建立AI准则,确保透明度和责任归属,如医疗AI遵循道德原则。经济上,AI改变就业市场结构,创造新职业,如AI顾问,同时要求教育体系更新。未来,平衡技术进步与社会影响至关重要。
826 0
|
11月前
|
Java 编译器
Java“精度可能丢失”错误解决
在处理Java编程语言中“精度可能丢失”的警告或错误信息时,通常涉及到数据类型之间的转换,特别是从高精度类型(如long、double)转换到低精度类型(如int、short)时。本指南将帮助你理解这一问题的根源,并提供有效策略来避免或解决此类错误,确保程序正确无误地运行。我们将会探讨如何使用显式类型转换(cast),以及如何优化代码逻辑来规避潜在的数据丢失风险。
524 0
|
8月前
|
Kubernetes 容灾 Cloud Native
服务网格容灾系列场景(三):使用服务网格应对服务级故障容灾
文章介绍了使用服务网格应对服务级故障容灾的实践:服务网格ASM通过多集群、多地域部署和基于地理位置的故障转移机制,实现服务级故障的自动检测与秒级流量切换,能够确保业务在复杂故障场景下的高可用性。
|
10月前
|
芯片
如何根据设备文档和开发板标识来确定 GPIO 引脚的编号
要确定GPIO引脚编号,首先查阅设备的官方文档,了解引脚布局和功能。接着,查看开发板上的标识,如数字或字母标记,对照文档确认具体编号。此过程确保正确连接硬件,避免损坏设备。
|
监控 网络安全
zookeeper的日志报will be dropped if server is in r-o mode如何解决
【6月更文挑战第26天】zookeeper的日志报will be dropped if server is in r-o mode如何解决
515 2
|
11月前
|
数据采集 数据可视化 数据挖掘
阿里云 Quick BI使用介绍
阿里云 Quick BI使用介绍
2936 3
|
10月前
|
SQL 缓存 测试技术
构建高性能RESTful API:最佳实践与避坑指南###
—— 本文深入探讨了构建高性能RESTful API的关键技术要点,从设计原则、状态码使用、版本控制到安全性考虑,旨在为开发者提供一套全面的最佳实践框架。通过避免常见的设计陷阱,本文将指导你如何优化API性能,提升用户体验,确保系统的稳定性和可扩展性。 ###
264 12
|
人工智能 数据管理 API
精铸智刃·“百炼”成钢——深度探索阿里云百炼大模型开发平台
阿里云百炼平台是一个一站式的大型语言模型开发和应用平台,旨在帮助企业与开发者高效构建和部署定制化的大模型。平台集成了通义大模型、行业模型和第三方模型,提供模型微调、模型调优、模型部署、模型评测等工具链。用户可以轻松创建和管理模型,通过模型广场选择合适的模型,进行模型体验和调优,然后部署模型以供应用调用。
73951 14
精铸智刃·“百炼”成钢——深度探索阿里云百炼大模型开发平台
|
人工智能 Kubernetes 持续交付
Kubernetes环境下基于微服务架构的容器化AI应用部署与管理最佳实践
【8月更文第19天】随着AI技术的快速发展,越来越多的企业开始将AI应用部署到生产环境。然而,AI应用往往包含大量的组件和服务,这使得其部署和管理变得非常复杂。微服务架构和容器化技术(如Docker)结合Kubernetes集群管理,为解决这些问题提供了强大的工具。本文将介绍如何在Kubernetes环境中部署和管理基于微服务架构的容器化AI应用。
803 0
|
存储 JSON NoSQL
【redis数据同步】redis-shake数据同步全量+增量
【redis数据同步】redis-shake数据同步全量+增量