在信息化大潮愈演愈烈的当下，数据和信息不啻为一种“新型资本”，尤其对于数据资产量巨大，操作复杂程度高、系统性能要求高的金融领域来说，数据资产发挥着越来越突出的价值，和传统资本具有的特性相似，数据资产的价值在流转、共享、整合利用中逐渐显现并越发放大。
作者 | 杨海峰
官网 | www.datayuan.cn
微信公众号ID | datayuancn
本文为数据猿推出的
“金融科技价值—数据驱动金融商业裂变”
大型主题策划活动第一部分的
文章/案例/产品征集
部分；感谢
安华金和技术副总裁杨海峰
先生的投稿
“资本只有在流动中才带来价值，单纯存放起来只会贬值”。
在信息化大潮愈演愈烈的当下，数据和信息不啻为一种“新型资本”，尤其对于数据资产量巨大，操作复杂程度高、系统性能要求高的金融领域来说，数据资产发挥着越来越突出的价值，和传统资本具有的特性相似，数据资产的价值在流转、共享、整合利用中逐渐显现并越发放大。
举例来说：银行数据部门掌握的用户储蓄和消费信息，对内共享可以完善业务部门的信息化系统开发；对外则可为政府部门、征信机构等提供有效参考；甚至可以成为零售或制造业制定战略目标的有效参考依据。
然而数据的共享和流转带来的红利，远远无法冲散遮盖在数据保管者和拥有者心头的乌云。这种担忧来自对敏感信息在共享环节可能发生的泄密风险，更是来自敏感数据“合理使用”并且“安全防护”两者之间的矛盾。于是，数据脱敏技术和专业脱敏产品应需而生，这类专业产品可以按照不同数据使用场合，对敏感数据进行变形处理，在脱敏处理的同时，不改变数据的类型、格式、含义、分布等使用特征，让用户不再因为深陷对安全的顾虑，而不得不割舍掉数据分享和流转带来的价值。
目前，脱敏技术中的静态脱敏技术常见于银行等金融领域。静态脱敏技术的应用，其价值在于打造一份全新的、“高度仿真”的数据库，供非安全环境下使用。凭借着低门槛、易部署等特性，静态脱敏技术率先被用户所接受。在近两年，这种数据处理方式先后被银行、证券、保险、社保等行业所采纳，成为数据共享中的重要工具。
但当面对不同身份的访问者，如何实时提供不同的脱敏数据？
某银行搭建的数据集中管理平台中，客户信息、账务信息、银行卡信息等全部集中在大数据分析环境中，面向内部提供数据查询分析服务，面向外部应用端、征信机构、政府部门等则提供数据检索接口。由于不同访问者的身份、权限差异，同样的数据对不同访问者的脱敏策略各不相同。为了实时、安全地向各方提供数据，依靠静态脱敏技术已经不再合适。此时，动态脱敏服务器便成了连接数据中心和外界使用者之间的通道，对不同身份、不同权限的用户配置实时数据脱敏规则，让其可以恰如其“份”的访问数据。
数据的动态脱敏遵循着一套与静态脱敏完全不同的技术路线，今天，我们重点了解一下数据动态脱敏技术，为金融行业未来的技术应用提供一些借鉴思路。
数据动态脱敏，需要满足一个重要的能力：针对目前各种主流的数据库中的敏感数据，在用户使用各种第三方客户端工具或应用程序实时访问数据过程中，能够依据用户角色、职责和其他 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，该操作中敏感字段的数据被“拆开”来使用，能够成功脱敏吗？
