上一篇文章中说道数据加密分两种场景 ShardingSphere 实现数据加密（脱敏）第一篇
分别是：
- 新上线业务
- 已上线业务
这篇我们对已上线业务进行模拟实验。
已上线业务改造
系统迁移前
建表语句和配置文件
CREATE TABLE `t_cipher_old` (
`id` bigint(20) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
`pwd` varchar(100) DEFAULT NULL,
`mobile` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
复制代码为了模拟已经上线的业务，我们为表中造一些测试数据，并编写业务接口实现 CURD
然而需要在数据库表 t_user 里新增一个字段叫做 pwd_cipher，即 cipherColumn，用于存放密文数据，同时我们把 plainColumn 设置为 pwd，用于存放明文数据，而把 logicColumn 也设置为 pwd。
ALTER TABLE test.t_cipher_old ADD pwd_cipher varchar(100) NULL;
复制代码由于之前的代码 SQL 就是使用 pwd 进行编写，即面向逻辑列进行 SQL 编写，所以业务代码无需改动。 通过 Apache ShardingSphere，针对新增的数据，会把明文写到 pwd 列，并同时把明文进行加密存储到 pwd_cipher 列。 此时，由于 queryWithCipherColumn 设置为 false，对业务应用来说，依旧使用 pwd 这一明文列进行查询存储，却在底层数据库表 pwd_cipher 上额外存储了新增数据的密文数据
配置文件如下（本文只需要关注 encrypt 节点部分）：
spring:
profiles:
include: common-local
shardingsphere:
datasource:
names: write-ds,read-ds-0
write-ds:
jdbcUrl: jdbc:mysql://mysql.local.test.myapp.com:23306/test?allowPublicKeyRetrieval=true&useSSL=false&allowMultiQueries=true&serverTimezone=Asia/Shanghai&useSSL=false&autoReconnect=true&useUnicode=true&characterEncoding=utf-8&zeroDateTimeBehavior=convertToNull
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: nicao
connectionTimeoutMilliseconds: 3000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
maintenanceIntervalMilliseconds: 30000
read-ds-0:
jdbcUrl: jdbc:mysql://mysql.local.test.read1.myapp.com:23306/test?allowPublicKeyRetrieval=true&useSSL=false&allowMultiQueries=true&serverTimezone=Asia/Shanghai&useSSL=false&autoReconnect=true&useUnicode=true&characterEncoding=utf-8&zeroDateTimeBehavior=convertToNull
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
username: root
password: nicai
connectionTimeoutMilliseconds: 3000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
maintenanceIntervalMilliseconds: 30000
rules:
readwrite-splitting:
data-sources:
glapp:
write-data-source-name: write-ds
read-data-source-names:
- read-ds-0
load-balancer-name: roundRobin # 负载均衡算法名称
load-balancers:
roundRobin:
type: ROUND_ROBIN # 一共两种一种是 RANDOM（随机），一种是 ROUND_ROBIN（轮询）
encrypt:
encryptors:
pwd-encryptor:
props:
aes-key-value: 123456abc
type: AES
tables:
t_cipher_old:
columns:
pwd: # pwd 与 pwd_cipher 的转换映射
plain-column: pwd # 原文列名称
cipher-column: pwd_cipher # 加密列名称
encryptor-name: pwd-encryptor # 加密算法名称（名称不能有下划线）
queryWithCipherColumn: false # 是否使用加密列进行查询。在有原文列的情况下，可以使用原文列进行查询
复制代码此时调用业务接口，新插入的数据就会在明文列 pwd 和加密列 pwd_cipher 同时存储数据。
上面整个的处理流程如下图所示：
至此，改造以后时间点进入的数据都是加密的了。
系统迁移中
将旧的数据自行加密处理
具体到我们这个例子来讲，需要手动将 pwd 字段未加密的值全部手动加密后将密文存储到 pwd_cipher.
形象地说，就是将空的位置手动补齐。
首先我们参考 ShardingSphere 的 AES 加解密码算法改造了一个工具类：
/**
* AES 加解密
*
* @author xiaohezi
* @since 2021-09-23 15:49
*/
public class AesUtils {
private static byte[] createSecretKey(String aesKey) {
return Arrays.copyOf(DigestUtils.sha1(aesKey), 16);
}
/**
* AES 加密方法
*
* @param plaintext 加密文本
* @param aesKey 加密 key
* @return
* @throws NoSuchAlgorithmException
* @throws InvalidKeyException
* @throws BadPaddingException
* @throws NoSuchPaddingException
* @throws IllegalBlockSizeException
*/
public static Object encrypt(String plaintext, String aesKey) throws NoSuchAlgorithmException, InvalidKeyException, BadPaddingException, NoSuchPaddingException, IllegalBlockSizeException {
try {
if (null == plaintext) {
return null;
} else {
byte[] result = getCipher(1, aesKey).doFinal(StringUtils.getBytesUtf8(plaintext));
return Base64.encodeBase64String(result);
}
} catch (GeneralSecurityException var3) {
throw var3;
}
}
/**
* AES 解密方法
*
* @param ciphertext 密码
* @param aesKey 加密 Key
* @return
* @throws NoSuchAlgorithmException
* @throws InvalidKeyException
* @throws BadPaddingException
* @throws NoSuchPaddingException
* @throws IllegalBlockSizeException
*/
public static Object decrypt(String ciphertext, String aesKey) throws NoSuchAlgorithmException, InvalidKeyException, BadPaddingException, NoSuchPaddingException, IllegalBlockSizeException {
try {
if (null == ciphertext) {
return null;
} else {
byte[] result = getCipher(2, aesKey).doFinal(Base64.decodeBase64(ciphertext));
return new String(result, StandardCharsets.UTF_8);
}
} catch (GeneralSecurityException var3) {
throw var3;
}
}
private static Cipher getCipher(int decryptMode, String aesKey) throws NoSuchPaddingException, NoSuchAlgorithmException, InvalidKeyException {
Cipher result = Cipher.getInstance(getType());
result.init(decryptMode, new SecretKeySpec(createSecretKey(aesKey), getType()));
return result;
}
public static String getType() {
return "AES";
}
}
复制代码然后为了简单演示，我的思路是用 java 程序将数据查出来以后直接更新，查询简单，更新的话用 mybatisplus 的 mapper 简单写了个自定义 sql 的方法
/**
* 根据 id 将密码的密文更新
*
* @param id
* @param pwdCipher
*/
@Update("update t_cipher_old set pwd_cipher =#{pwdCipher} where id = #{id}")
void updateCipher(@Param("id") Long id, @Param("pwdCipher") String pwdCipher);
复制代码下面是更新方法，注意我这里的 aesKey 和上面的配置文件是保持一致的。
@Override
public void updateOldPwd() {
QueryWrapper<CipherOldDO> wrapper = new QueryWrapper<>();
wrapper.isNull("pwd_cipher");
List<CipherOldDO> list = list(wrapper);
String aesKey = "123456abc";
try {
for (CipherOldDO cipherOldDO : list) {
Object encrypt = AesUtils.encrypt(cipherOldDO.getPwd(), aesKey);
//更新密码的密文
getBaseMapper().updateCipher(cipherOldDO.getId(), encrypt.toString());
}
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (InvalidKeyException e) {
e.printStackTrace();
} catch (BadPaddingException e) {
e.printStackTrace();
} catch (NoSuchPaddingException e) {
e.printStackTrace();
} catch (IllegalBlockSizeException e) {
e.printStackTrace();
}
}
复制代码程序执行完，加密列 pwd_cipher 就有数据了。
由于配置项中的 queryWithCipherColumn = false，所以密文一直没有被使用过。如果我们为了让系统能切到密文数据进行查询，需要将加密配置中的 queryWithCipherColumn 设置为 true。
虽然现在业务系统通过将密文列的数据取出，解密后返回；但是，在存储的时候仍旧会存一份原文数据到明文列，这是为什么呢？ 答案是：为了能够进行系统回滚。 因为只要密文和明文永远同时存在，我们就可以通过开关项配置自由将业务查询切换到 cipherColumn 或 plainColumn。 也就是说，如果将系统切到密文列进行查询时，发现系统报错，需要回滚。那么只需将 queryWithCipherColumn = false，Apache ShardingSphere 将会还原，即又重新开始使用 plainColumn 进行查询。 处理流程如下图所示：
系统迁移后
业务系统一般不可能让数据库的明文列和密文列永久同步保留，我们需要在系统稳定后将明文列数据删除。
但是删除列对于业务代码来说是不需要发动的，因为有 logicColumn 存在，用户的编写 SQL 都面向这个虚拟列，Apache ShardingSphere 就可以把这个逻辑列和底层数据表中的密文列进行映射转换。于是迁移后的加密配置即为：
encrypt:
encryptors:
pwd-encryptor:
props:
aes-key-value: 123456abc
type: AES
tables:
t_cipher_old:
columns:
pwd: # pwd 与 pwd_cipher 的转换映射
cipher-column: pwd_cipher # 加密列名称
encryptor-name: pwd-encryptor # 加密算法名称（名称不能有下划线）
queryWithCipherColumn: true # 是否使用加密列进行查询。在有原文列的情况下，可以使用原文列进行查询
复制代码在数据库中直接将 pwd 列删除
可以看到已经没有 pwd 列的，只剩下加过密的 pwd_cipher , 从数据库这里我们已经看不出密码是什么了。然后我们调用查询接口，看到数据：
{
"code": 100000,
"msg": "",
"data": [
{
"id": 1,
"name": "Tara",
"pwd": "dogT",
"mobile": "+425(864)267-129",
"createTime": "1994-12-02 18:39:01",
"updateTime": "2021-09-23 16:45:08"
},
{
"id": 2,
"name": "Earl",
"pwd": "ju",
"mobile": "+17(252)465-481",
"createTime": "2016-10-05 15:15:43",
"updateTime": "2021-09-23 16:45:08"
},
{
"id": 3,
"name": "Roberta",
"pwd": "fo",
"mobile": "+44(296)354-787",
"createTime": "2008-10-09 17:21:36",
"updateTime": "2021-09-23 16:45:08"
},
{
"id": 4,
"name": "Travis",
"pwd": "brow",
"mobile": "+77(975)452-214",
"createTime": "2005-02-17 07:14:24",
"updateTime": "2021-09-23 16:45:08"
}
]
}
复制代码可以看到，数据是解密以后的样子。
其处理流程如下：
近期评论