随着应用系统以及数据库的迭代更新，新旧系统之间往往需要进行大量的数据迁移。与此同时，在数据库中，越来越多的敏感数据是以加密的方式进行存储的。市场上不同的数据库产品之间关于数据加解密的接口实现以及使用上存在差异，导致在应用系统迁移的时候需要考虑更多的兼容性问题。
本文以KingbaseES数据库为例，谈谈如何规避或解决用户在加密数据迁移过程中可能出现的一些问题。
1、若用户选择了透明加密，迁移是否会遇到问题？
数据库透明加密是指对库内数据的加密和解密，对数据库的访问程序是完全无感知的。特别是应用系统，不需要做任何修改和编译，就能够直接应用到加密库上。因此，使用透明加密的应用通常不用关心加密处理，包括加密算法。
透明加密的数据如何迁移呢?
通常需要关注在算法的选择上。比如源数据库中数据是透明加密的，这类数据迁移到KingbaseES时，需要选择和源数据库的加密算法强度类似的加密算法，KingbaseES支持SM4和RC4算法，密钥由数据库内部随机生成，需要参照KingbaseES的《安全管理手册》文档设置透明加密。
透明加密使用的密钥都是数据库服务器负责生成和维护的，不用用户和应用指定，所以迁移时，不需要处理密钥。
2、若用户使用加密函数对数据进行加密，可能会遇到哪些问题？
2.1应该选择什么样的加解密函数？
与透明加密相对应的，是在应用系统中对数据进行加密，然后再存储到数据库中。需要真实数据的时候，从数据库中读取密文，应用程序再对数据进行解密得到明文。
这时候，用户对数据的加解密操作既可以使用外部自定义的函数，也可以采用数据库内置的加解密模块中函数来实现。
KingbaseES提供了一系列函数接口供用户使用，包括常规散列函数Digest用于MD5，SHA系列算法，HMAC等哈希运算，encrypt/decrypt函数支持AES算法对称加解密，gen_random_bytes()函数生成随机数等。
用户可根据当前业务的使用情况，将对应的接口使用迁移替换成KingbaseES的对应接口。比如，如果当前使用的是其他数据库的加解密接口，迁移到KingbaseES的话，用户需要将当前使用到的相关函数替换为KingbaseES的函数接口。此时，需要注意不同数据库的接口间存在差异，以常见的MD5哈希计算函数和AES数据加解密函数为例，比较如下：
通过以上的比较可以看到
另外，对于AES加解密函数的具体实现，各数据库也存在着差异。参照MySQL文档可验证，MySQL对数据进行加密时是强制填充的，而KingbaseES和Oracle函数需要指定加密填充方式。所以，在使用时，用户应特别注意需要当前业务使用哪种算法和加密模式，对相关函数做必要的数据验证，以确认算法的一致性，并在使用接口时传递正确的参数。
同时，也要注意使用函数的返回类型，如KingbaseES的digest()和encrypt()等函数返回的是bytea类型的数据，如要转换为十六进制，需要借助其他函数进行转换如：encode(digest($1, 'sha1'), 'hex')。
2.2数据加解密时如何保证一致性？
应用数据中数据的加解密不一定都在数据库服务端进行，有的情况下，加密在应用程序中进行，在数据库中进行解密，或者反之。
这时，如何保证加密和解密的结果是一致的？
首先，需要保证加密和解密时采用的算法、加密模式、填充方式等一致，对数据加密前或解密后的处理方式要保持一致。关于这点，通常在往数据库加密存储时，应用程序本身也需要做一个解密校验，保证存入数据库的值是正确加密的。
其次，加密和解密时客户端和服务端选择的字符编码应该保持一致。
以KingbaseES数据库为例，它支持客户端和服务端编码方式设置，可以通过以下方式去查询或更改当前接收的字符集。
test=# show client_encoding; -- 客户端使用字符集
client_encoding
-----------------
UTF8
(1 row)
test=# show server_encoding; -- 服务端使用字符集
server_encoding
-----------------
UTF8
(1 row)
-- 更改数据库客户端字符集
test=# set client_encoding to 'GBK'; --也可\encoding GBK指定
SET
test=# show client_encoding;
client_encoding
-----------------
GBK
(1 row)
下面以KingbaseES中的encode函数为例说明字符集编码对数据的影响。
test=# create table t (id int, name varchar(32));
CREATE TABLE
设置客户端环境编码。以LINUX环境来说，LANG环境变量设置客户端编码。
如果是使用SecureCRT之类的终端软件连接，终端软件的字符集要与LANG保持一致。
[daoke@localhost bin]$ echo $LANG
en_US.UTF8
test=# select encode('汉字','hex');
encode
--------------
e6b189e5ad97
(1 row)
输出结果为'汉字'的UTF-8编码
test=# \encoding GBK
test=# select encode('汉字','hex');
encode
--------------------
e5a7b9e5a48ae793a7
(1 row)
此时客户端编码为UTF8，数据库设置的客户端编码为GBK，数据库服务端编码为UTF8，不一致，输出结果会转换，表示将’e6b189e5ad97’作为GBK编码转换为UTF-8后的编码。
如果将客户端环境或客户端使用终端的编码设置为GBK
[daoke@localhost bin]$ export.GBK
[daoke@localhost bin]$ echo $LANG
zh_CN.GBK
test=# show client_encoding;
client_encoding
-----------------
GBK
(1 row)
test=# select encode('汉字','hex');
encode
--------------
e6b189e5ad97
(1 row)
test=# select encode('姹夊瓧','hex');
encode
--------------------
e5a7b9e5a48ae793a7
(1 row)
我们可以看到，数据库客户端编码设置为GBK和用户客户端环境一致时，encode的结果不发生转换。
同样地，如果这时修改数据库客户端编码为UTF8
test=# set client_encoding to 'UTF8';
SET
test=# show client_encoding;
client_encoding
-----------------
UTF8
(1 row)
test=# select encode('汉字','hex');
2020-10-10 16:01:55.113 CST [28203] ERROR: invalid byte sequence for encoding "UTF8": 0xba
ERROR: invalid byte sequence for encoding "UTF8": 0xba
test=# select encode('姹夊瓧','hex');
encode
--------------
e6b189e5ad97
(1 row)
会出现字符解码错误的问题。
通过上面关于encode()函数的例子，我们可以发现字符集的一致性对于最终的结果有着很大的影响，在使用到加解密类函数的时候也会存在着类似的问题。对于KingbaseES来说，客户端编码和服务端编码如果一致，则插入的数据之间不经过转码，直接存入服务器；当客户端编码和服务器编码不一致的时候，插入的数据会自动转码。
所以，在使用相关函数的时候，需要保证字符编码使用上的统一。即用户客户端环境的字符编码应该和数据库中设置的客户端编码保持一致。
2.3JAVA程序与数据库加解密相结合
对于一些JAVA的应用系统，会采用JAVA自带的程序进行加密，使用数据库函数完成解密，这时需要注意哪些问题呢？
对于该问题，参照2.2部分的内容：
1）java程序需要保证对数据的加解密算法及处理过程与数据库端一致。
2）java程序使用的编码与数据库端设置编码应一致。
2.4是否可以直接迁移密文？
理论上来说，只要保证密钥一致，加解密方法及过程一致，是可以直接迁移密文的。但在实际迁移中，仍需要考虑实际场景。
不同数据库的加解密接口实现存在差异，如果直接迁移密文就必须确认清楚当前使用的算法以及相关参数，以保证在迁移之后能顺利地完成数据解密操作以及后续的数据存储业务。但由于有些数据库内部如何实现的并不透明，对其加密结果的分析造成一定难度，需要根据实际需要具体分析。
3、总结
在对加密数据做迁移时，和普通的数据迁移思路应该是一致的，最终是要将对应的业务逻辑正确地兼容过来。加解密接口的使用过程中，用户需要关注待迁移的功能在新数据库系统下的API接口，保证算法和加解密过程一致，并进行正确的传参，根据函数返回类型正确使用输出结果。同时，在迁移数据时，客户端和数据库端需要使用统一的字符集，从而保障数据的一致性。Kingbase默认采用的是UTF8字符，建议统一使用UTF8字符集进行处理。
