因为某种原因，需要去考虑数据脱敏的问题，但是既不想因为脱敏而影响数据的操作性，又需要对一些敏感信息进行可靠的保护。因此，正好解决了手头问题的我就开始研究各种脱敏手段、寻求最适合目前现状的脱敏解决方案。
对于已经上线的业务，如何在不修改业务逻辑、业务SQL的情况下，透明化、安全低风险地实现无缝进行脱敏改造呢？
Apache的ShardingSphere进入了我的视野，Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立，却又能够混合部署配合使用的产品组成。它们均能够提供标准化的数据分片、分布式事务和分布式治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
目前已上线业务，之前一直将明文存储在数据库中。因为某些原因需要对已上线业务进行脱敏整改。为了解决这个问题，有三个问题需要考虑：
-
1、 如何对大量的历史数据需要脱敏处理。
-
2、 如何能在不改动业务SQL和逻辑情况下，将新增数据进行脱敏处理，并存储到数据库。
-
3 、如何较为安全地实现业务系统在明文与密文数据间的迁移。
对静态业务脱敏有专业的脱敏手段，包括一些脱敏工具、亦或是使用SPL脚本或者存储过程对存量数据进行脱敏。所以，我们这次主要研究如何不影响业务逻辑进行增量数据脱敏。
一、数据脱敏的原理
ShardingSphere提供的Encrypt-JDBC和业务代码部署在一起。业务方需面向Encrypt-JDBC进行JDBC编程。由于Encrypt-JDBC实现所有JDBC标准接口，业务代码无需做额外改造即可兼容使用。此时，业务代码所有与数据库的交互行为交由Encrypt-JDBC负责。业务只需提供脱敏规则即可。作为业务代码与底层数据库中间的桥梁，Encrypt-JDBC便可拦截用户行为，并在改造行为后与数据库交互。
Encrypt-JDBC将用户发起的SQL进行拦截，并通过SQL语法解析器进行解析、理解SQL行为，再依据用户传入的脱敏规则，找出需要脱敏的字段和所使用的加解密器对目标字段进行加解密处理后，再与底层数据库进行交互。ShardingSphere会将用户请求的明文进行加密后存储到底层数据库；并在用户查询时，将密文从数据库中取出进行解密后返回给终端用户。ShardingSphere通过屏蔽对数据的脱敏处理，使用户无需感知解析SQL、数据加密、数据解密的处理过程，就像在使用普通数据一样使用脱敏数据。
二、脱敏的配置
我们这边可以直接用yaml配置来解释脱敏规则的配置。
1、数据源配置
是指DataSource的配置
spring:
application:
name: sharding-jdbc-examples
main:
allow-bean-definition-overriding: true
shardingsphere:
datasource: #数据源配置
names: ds
ds:
url: jdbc:mysql://127.0.0.1:3306/test1?useSSL=false&useUnicode=true&serverTimezone=UTC
type: com.alibaba.druid.pool.DruidDataSource
username: root
password: root
driver-class-name: com.mysql.cj.jdbc.Driver
2、加密器配置
是指使用什么加密策略进行加解密。目前ShardingSphere内置了两种加解密策略：AES/MD5。用户还可以通过实现ShardingSphere提供的接口，自行实现一套加解密算法。
encrypt:
encryptors:
encryptor_aes:
type: aes #加解密器类型，可自定义或选择内置类型：MD5/AES
props:
aes.key.value: 123456* #属性配置, 注意：使用AES加密器，需要配置AES加密器的KEY属性：aes.key.value
qualifiedColumns: t_user.password
3、脱敏表配置
用于告诉ShardingSphere数据表里哪个列用于存储密文数据（cipherColumn）、哪个列用于存储明文数据（plainColumn）以及用户想使用哪个列进行SQL编写（logicColumn）。
tables:
t_user:
columns:
passowrd: #logicColumn
plainColumn: passowrd #plainColumn
cipherColumn: newpassowrd #cipherColumn
encryptor: encryptor_aes #加密器配置
4、查询属性的配置
当底层数据库表里同时存储了明文数据、密文数据后，该属性开关用于决定是直接查询数据库表里的明文数据进行返回，还是查询密文数据通过Encrypt-JDBC解密后返回。
props:
# 打印SQL
sql.show: true
check:
table:
metadata: true
# 是否在启动时检查分表元数据一致性
enabled: true
query:
with:
cipher:
# 选择使用明文或者密文字段进行查询，true为密文
column: true
当配置好了这些信息后，就可以完成对数据的加密。
5、脱敏处理过程
现在我们利用之前做好的配置来进行一次简单的测试
测试完毕，我们可以看出，通过用户提供的脱敏配置，数据找到了logicColumn，于是对逻辑列及其对应的明文数据进行脱敏处理。可以看出ShardingSphere将面向用户的逻辑列与面向底层数据库的明文列和密文列进行了列名以及数据的脱敏映射转换。
了解了数据新增的逻辑，那么数据查询、修改也是相似的原理。同时，查询的时候也可以选择使用明文还是密文字段进行查询。
三、新业务与旧业务
1、新业务
如果不涉及到旧业务改造，就可以免去plainColumn字段，直接使用cipherColumn即可。
2、旧业务
已上线的任务，由于数据库存在大量的明文数据，如何对存量数据进行清洗，同时对新数据进行加密，在两套系统中无缝衔接，才是我们要解决的问题。
1、任务迁移前
数据清洗之前，我们使用我之前的配置的内容，增删改查继续使用明文，在数据库只是新增字段存储密文数据，在对存量数据进行清洗之前不要擅自行动。
2、任务迁移中
新增的数据已被Encrypt-JDBC将密文存储到密文列，明文存储到明文列；历史数据被业务方自行加密清洗后，将密文也存储到密文列。也就是说现在的数据库里即存放着明文也存放着密文。同时我们随时可以通过配置来更换查询出的数据是明文还是密文。
在校验完系统的可靠性和数据的正确性之前，不要直接删掉明文数据，以防万一。
2、任务迁移后
由于安全审计部门要求，业务系统一般不可能让数据库的明文列和密文列永久同步保留，我们需要在系统稳定后将明文列数据删除。 之后，我们的脱敏表配置也可以进行改动了。（当然，特殊情况也可以留下明文数据进行备份，这个就要考虑到实际情况了）
tables:
t_user:
columns:
passowrd: #logicColumn
cipherColumn: newpassowrd #cipherColumn
encryptor: encryptor_aes #加密器配置
四、选择ShardingSphere进行脱敏处理的理由
- 1、ShardingSphere提供了自动化和透明化数据脱敏过程，我们无需关注脱敏中间实现细节。
- 2 提供多种内置、第三方(AKS)的脱敏策略，仅需简单配置即可使用。
- 3、提供脱敏策略API接口，用户可实现接口，从而使用自定义脱敏策略进行数据脱敏。
- 4、支持切换不同的脱敏策略。
- 5、针对已上线业务，可实现明文数据与密文数据同步存储，并通过配置决定使用明文列还是密文列进行查询。可实现在不改变业务查询SQL前提下，已上线系统对加密前后数据进行安全、透明化迁移。
当然，使用脱敏功能+分库分表功能，部分特殊SQL不支持，官方也提供了SQL规范供以查询规范地址
大家好，我是练习java两年半时间的南橘，下面是我的微信，需要之前的导图或者想互相交流经验的小伙伴可以一起互相交流哦。 有需要的同学可以加我的公众号，以后的最新的文章第一时间都在里面，也可以找我要思维导图
