“资本只有在流动中才带来价值，单纯存放起来只会贬值”。
在信息化大潮愈演愈烈的当下，数据和信息不啻为一种“新型资本”，尤其对于数据资产量巨大，操作复杂程度高、系统性能要求高的金融领域来说，数据资产发挥着越来越突出的价值，和传统资本具有的特性相似，数据资产的价值在流转、共享、整合利用中逐渐显现并越发放大。
举例来说：银行数据部门掌握的用户储蓄和消费信息，对内共享可以完善业务部门的信息化系统开发；对外则可为*部门、征信机构等提供有效参考；甚至可以成为零售或制造业制定战略目标的有效参考依据。
然而数据的共享和流转带来的红利，远远无法冲散遮盖在数据保管者和拥有者心头的乌云。这种担忧来自对敏感信息在共享环节可能发生的泄密风险，更是来自敏感数据“合理使用”并且“安全防护”两者之间的矛盾。于是，数据脱敏技术和专业脱敏产品应需而生，这类专业产品可以按照不同数据使用场合，对敏感数据进行变形处理，在脱敏处理的同时，不改变数据的类型、格式、含义、分布等使用特征，让用户不再因为深陷对安全的顾虑，而不得不割舍掉数据分享和流转带来的价值。
目前，脱敏技术中的静态脱敏技术常见于银行等金融领域。静态脱敏技术的应用，其价值在于打造一份全新的、“高度仿真”的数据库，供非安全环境下使用。凭借着低门槛、易部署等特性，静态脱敏技术率先被用户所接受。在近两年，这种数据处理方式先后被银行、证券、保险、社保等行业所采纳，成为数据共享中的重要工具。
但当面对不同身份的访问者，如何实时提供不同的脱敏数据？
某银行搭建的数据集中管理平台中，客户信息、账务信息、银行卡信息等全部集中在大数据分析环境中，面向内部提供数据查询分析服务，面向外部应用端、征信机构、*部门等则提供数据检索接口。由于不同访问者的身份、权限差异，同样的数据对不同访问者的脱敏策略各不相同。为了实时、安全地向各方提供数据，依靠静态脱敏技术已经不再合适。此时，动态脱敏服务器便成了连接数据中心和外界使用者之间的通道，对不同身份、不同权限的用户配置实时数据脱敏规则，让其可以恰如其“份”的访问数据。
数据的动态脱敏遵循着一套与静态脱敏完全不同的技术路线，今天，我们重点了解一下数据动态脱敏技术，为金融行业未来的技术应用提供一些借鉴思路。
数据动态脱敏，需要满足一个重要的能力：针对目前各种主流的数据库中的敏感数据，在用户使用各种第三方客户端工具或应用程序实时访问数据过程中，能够依据用户角色、职责和其他 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字段（红色字体）进行脱敏处理？
如果选择脱敏处理，好处是不会造成通过精确查询进行数据的“猜测”引起的数据泄露；缺点是恐怕很难再通过脱敏字段作为条件进行查询，因为说不清查询的结果会如何，很大可能是查不到结果。
如果不进行脱敏处理，好处是不影响查询操作，该查询到的数据依然能够查到；缺点是数据很可能通过频繁查询可以猜测到真实数据，导致数据仍然存在泄漏风险。
技术应对：无论如何选择，都无法实现最佳效果，相对合理的解决方案是两种都提供，然后根据实际的需求来配置合理的策略。
此外，金融行业对于业务系统的运行稳定性有着严格的要求，而动态脱敏作用于网络层，脱敏系统串接在访问者和敏感数据之间，因此产品需要兼顾高性能与稳定性，不会因脱敏处理导致性能的明显下降，同时兼容全系列数据库协议；另一方面，需要具备高并发条件下的抗压能力，拥有完善的容灾机制；这些都将成为衡量动态脱敏产品成熟度的标准。
在数据安全领域，“禁止”和“防护”固然重要，但是如果背离了数据共享和合理使用的前提，那么数据的价值将大幅度下降。数据脱敏技术，正是兼顾数据“用”、“护”之道的有效手段。无论动态脱敏还是静态脱敏，在金融行业数据安全领域，将越发不可替代，真正为金融用户铸造安全、可靠、高效的数据使用环境。我们看到基于网络层的动态脱敏技术为金融行业的实时数据共享开辟了新的前景。