动态脱敏现状分析及如何识别真正的动态脱敏产品

目前市面上的动态脱敏产品基本采用的是协议解析代理技术：

缺点：

1. 很多数据库协议往往是不公开的，厂家只能通过逆向工程来分析协议，这种野蛮强力破解的方式，往往不能做到100%解析正确，存在错误解析和遗漏解析的可能。若数据库厂家推出新的版本，协议有可能有变动，就不一定能支持。
2. 当前为了安全，很多数据库，尤其是大数据平台都使用了数字证书等的加密认证传输方式，通讯过程是加密的，根本无法解析协议和分析协议，此类产品就不能用了。
3. 天然的公开暴露实体数据库的帐号、密码，若攻击者知道实体数据库的IP、端口信息，就轻易的绕开代理层，敏感信息全部泄露。

 

另外，建立在协议解析代理基础上的sql语句改写方式：

缺点：

1. 在原生产库中需要植入很多脱敏处理的函数脚本，在当今往往偏向于瘦数据库应用模式（数据库只是用于存储数据，而抛弃以往的很多业务处理逻辑的存储过程、触发器、函数等），这样的植入插件对客户是不可接受的。若生产库发生故障，也很难排除不是这些植入插件引起的原因。
2. 脱敏处理在生产库进行，对原生产库性能造成影响。从而不可避免的对原有的应用系统产生影响。
3. 简单的函数脱敏处理方式，往往不能支持复杂的脱敏规则。

 

 

协议解析代理类产品的最大的问题：

部署落地的问题：此类产品是公开实体数据库的帐号、密码信息的。同样的一个schema级的数据库帐号，在业务系统中配置的该schema帐号时，需要所有操作是不需要脱敏的；而在开发运维环境，该schema帐号访问数据库时，需要对敏感信息进行脱敏处理。如何区别对待？目前此类产品往往采用的方法是：在schema帐号上加一层IP地址或应用系统作为多维身份来区别。而应用系统作为身份这个理论体系是错误的，站不住脚的，很多应用都虚拟化和微服务化，根本没有应用身份特征信息，应用系统信息也可以被仿冒。而仅凭IP地址作为特征，也不可靠，容易仿冒。

所以，落地部署是一大难题，很难根据应用场景分别对待，往往结果是部署此产品没起到任何保护作用，最终是废弃状态。

 

如何识别真正的动态脱敏产品？

 

真正的动态脱敏，必须支持复杂SQL语句的脱敏处理，能识别其中的敏感信息并脱敏处理，做到无遗漏，无泄漏，复杂SQL例如：嵌套语句select * from (select * from (select * from table1))； union语句 select name from table1 union select name from table2； intersect语句 select name from table1 intersect select name from table2。拒绝带敏感字段函数处理语句的执行，如：select substr(name,1,3) from table1。

 

数据中心的痛点：

目前的痛点是，在各行业各领域的数据中心，由于数据库系统不能对外部用户、运维人员、开发人员等做到个人机构级的细分帐号权限等级管理的权限控制，而且授权管理复杂，因而管理者、使用者基本使用统一的高权限的帐号、密码，帐号共享严重，数据库基本处于高度危险不可控的状态，数据也处于完全裸奔的状态，导致数据库勒索病毒、误删误改数据、数据泄密等事件时有发生，严重影响业务的正常可靠运行。

 

完整的数据安全保护和防泄密解决方案：

杭州深普科技的DMStar数据资产保护和动态脱敏系统，采用全新的技术架构及理念，从数据库虚拟化、安全准入、访问控制、数据脱敏四个层面多维度全方位保护数据安全，能很好的满足动态脱敏的要求，实现真正的100%动态脱敏，防止敏感信息的泄露。系统能提供 DDL、DML 细粒度的权限控制；表级别的访问权限（insert、update、delete、select）控制，设置返回行数限制，防止批量信息泄露；虚拟化数据库，使用者无需知道真实数据库的帐号和密码，IP 和端口等信息，提供精细到个人、机构的帐号权限管理；提供语意内容级的 SQL 验证分析和阻断功能，有效的保护实体数据库的安全。

能满足数据中心复杂的网络环境下的数据安全保护和防泄密需求，真正解决当前的痛点。