产品咨询：4000 258 365
|
申请产品演示
|
产品咨询：4000 258 365
|
申请产品演示
|
“资本只有在流动中才带来价值，单纯存放起来只会贬值”。
在信息化大潮愈演愈烈的当下，数据资产发挥着越来越突出的价值，数据资产的价值在流转、共享、整合利用中逐渐显现并越发放大。当数据被分享给不同使用者，如何保障数据的安全？动态脱敏技术让数据中心和外界使用者之间的安全交互成为可能。
长期以来，提起技术，能力称霸者非informatica莫属，国内外其他厂商在动态脱敏技术领域都难以望其项背，由此可见这一技术的复杂度和成熟产品的研发难度非同一般。2014年，informatica凭借其ddm产品位居gartner数据脱敏的领导者象限。
对于国内数据库安全厂商而言，有了其他安全产品的深厚研发积累，朝着数据技术进发也变成一种发展惯性。
2016年，国内已有厂商开始基于长期的数据库防火墙产品所积累下来的数据库协议分析、协议改写、语法分析、sql语句改写等技术，成功推出数据库动态脱敏产品，并在真实的用户现场，通过与informatica ddm产品的多次比拼，积累下丰富的“填坑”经验，产品也在不断“填坑”的过程中逐步走向成熟。
那么，面对数据共享场景，合格的数据动态脱敏产品要跨越的技术障碍都有哪些呢？
对于策略，常用做法是指定需要脱敏的字段或字段通配符，如此一来，必然会面临以下问题：
场景1：配置了字段abc需要进行脱敏处理，而用户执行的操作是select *，并没有在操作中写明字段名，这种情况还能针对字段abc成功脱敏吗？
场景2：配置了字段abc需要进行脱敏处理，但用户应用系统“每天自动产生一个包含这个字段的表，并且表中的这个字段的数据也需要脱敏”，应对每天增量产生的表执行select *操作，可以做到及时成功脱敏吗？
技术应对：动态脱敏产品自动根据用户发起的sql命令进行分析，实时检查select *这一命令操作的表有哪些字段，并根据实时检查的结果自动对数据进行脱敏。
场景：配置了字段abc需要进行脱敏处理，用户执行的操作是select substr(abc,1,2),field1,field3,substr(abc,2,5) from table，该操作中敏感字段的数据被“拆开”来使用，能够成功脱敏吗？
技术应对：合格的动态脱敏产品，是作用在请求的sql操作的字段上，而不是对返回的结果集进行变形处理，否则会造成无法适应各种复杂的sql命令而产生结果集数据。
目前，动态脱敏主流的实现方式是采用网关或代理的方式（informatica ddm和安华金和ddm正是采用这种实现方式），在客户端和服务器之间按照策略进行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字段不能进行脱敏。
场景：配置persionid为需要脱敏的字段，用户在plsql客户端工具中执行下面的语句块：
declare |
这个语句块中，关键是查询操作是采用拼接的sql命令并动态执行sql操作，其结果是通过语法分析无法准确地对需要脱敏的字段进行处理。
技术应对：即使采用了语法分析，这种动态sql语句也无法被处理；建议采用的策略是禁止这样的操作被执行。
场景：用户配置了persionid字段为敏感字段，执行sql命令select persionid,datefield from performance_c_1000000 where persionid like '1204581978%';
该操作会面临一个问题：是否需要对where条件中的persionid字段（红色字体）进行脱敏处理？
如果脱敏处理，好处是不会造成通过准确查询进行数据的“猜测”引起的数据泄露；缺点是恐怕很难再通过脱敏字段作为条件进行查询。
如果不进行脱敏处理，好处是不影响查询操作，该查询到的数据依然能够查到；缺点是频繁查询很可能猜测到真实数据，导致数据存在泄漏风险。
技术应对：无论如何选择，都无法实现最佳效果，相对合理的k8凯发天生赢家的解决方案是两种都提供，然后根据实际的需求来配置合理的策略。
技术真正为用户铸造安全、可靠、高效的数据使用环境，基于网络层的动态脱敏技术为实时数据共享开辟了新的前景。
试用申请
