【进阶之路】基于ShardingSphere的线上业务数据脱敏解决方案

因为某种原因，需要去考虑数据脱敏的问题，但是既不想因为脱敏而影响数据的操作性，又需要对一些敏感信息进行可靠的保护。因此，正好解决了手头问题的我就开始研究各种脱敏手段、寻求最适合目前现状的脱敏解决方案。

对于已经上线的业务，如何在不修改业务逻辑、业务SQL的情况下，透明化、安全低风险地实现无缝进行脱敏改造呢？

Apache的ShardingSphere进入了我的视野，Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立，却又能够混合部署配合使用的产品组成。它们均能够提供标准化的数据分片、分布式事务和分布式治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

目前已上线业务，之前一直将明文存储在数据库中。因为某些原因需要对已上线业务进行脱敏整改。为了解决这个问题，有三个问题需要考虑：

• 1、 如何对大量的历史数据需要脱敏处理。

• 2、 如何能在不改动业务SQL和逻辑情况下，将新增数据进行脱敏处理，并存储到数据库。

• 3 、如何较为安全地实现业务系统在明文与密文数据间的迁移。

对静态业务脱敏有专业的脱敏手段，包括一些脱敏工具、亦或是使用SPL脚本或者存储过程对存量数据进行脱敏。所以，我们这次主要研究如何不影响业务逻辑进行增量数据脱敏。

一、数据脱敏的原理

shardingsphere关于脱敏的官方文档

ShardingSphere提供的Encrypt-JDBC和业务代码部署在一起。业务方需面向Encrypt-JDBC进行JDBC编程。由于Encrypt-JDBC实现所有JDBC标准接口，业务代码无需做额外改造即可兼容使用。此时，业务代码所有与数据库的交互行为交由Encrypt-JDBC负责。业务只需提供脱敏规则即可。作为业务代码与底层数据库中间的桥梁，Encrypt-JDBC便可拦截用户行为，并在改造行为后与数据库交互。