干货丨加密数据迁移二三事

随着应用系统以及数据库的迭代更新，新旧系统之间往往需要进行大量的数据迁移。与此同时，在数据库中，越来越多的敏感数据是以加密的方式进行存储的。市场上不同的数据库产品之间关于数据加解密的接口实现以及使用上存在差异，导致在应用系统迁移的时候需要考虑更多的兼容性问题。

本文以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数据加解密函数为例，比较如下：

1）MD5比较

AES加解密函数比较

通过以上的比较可以看到

不同数据库的算法接口在函数名、参数传递上都存在着差异。往KingbaseES数据库迁移时，需要将其他数据库支持的特有的数据类型转换为KingbaseES支持的类型进行输入。

另外，对于AES加解密函数的具体实现，各数据库也存在着差异。参照MySQL文档可验证，MySQL对数据进行加密时是强制填充的，而KingbaseES和Oracle函数需要指定加密填充方式。所以，在使用时，用户应特别注意需要当前业务使用哪种算法和加密模式，对相关函数做必要的数据验证，以确认算法的一致性，并在使用接口时传递正确的参数。

同时，也要注意使用函数的返回类型，如KingbaseES的digest()和encrypt()等函数返回的是bytea类型的数据，如要转换为十六进制，需要借助其他函数进行转换如：encode(digest($1, ‘sha1’), ‘hex’)。

上面仅以哈希计算和AES算法为例说明应用系统在迁移时选择加解密函数的注意事项，更多的API和细节可查阅对应产品官网。
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字符集进行处理。

干货丨加密数据迁移二三事相关推荐

干货丨AI语音二三事：你需要了解这些AI 语音对话技术
机器学习以及自然语言处理技术的进步,开启了人与人工智能进行语音交互的可能,人们透过对话的方式获取信息.与机器进行交互,将不再只是存在科幻情结当中.语音交互是未来的方向,而智能音箱则是语音交互落地的第一 ...
干货丨深度迁移学习方法的基本思路（文末送书）
百度前首席科学家.斯坦福大学副教授吴恩达(Andrew Ng)曾经说过:迁移学习将是继监督学习之后的下一个促使机器学习成功商业化的驱动力. 本文选自<深度学习500问:AI工程师面试宝典> ...
干货丨简述迁移学习在深度学习中的应用
文章来源:机器之心迁移学习是一种机器学习方法,就是把为任务 A 开发的模型作为初始点,重新使用在为任务 B 开发模型的过程中. 深度学习中在计算机视觉任务和自然语言处理任务中将预训练的模型作为新模型 ...
干货丨【看图识算法】这是你见过最简单的 “算法说明书”
文章来源:新智元 [导读]像阅读宜家的安装说明书一样学习算法,是怎样的体验?不伦瑞克工业大学的三名研究者制作了这份"算法说明书",简明传神地解释了一些基本算法,一起来看图说话. Q ...
AFC中央计算机系统图,干货丨城市地铁AFC系统由哪些部分组成的？如何运作？
原标题:干货丨城市地铁AFC系统由哪些部分组成的?如何运作? AFC系统的全称是Automatic Fare Collection System(城市轨道交通自动售检票系统),是基于计算机.通信.网络 ...
微信公众号迁移丨如何迁移微信公众号最详细公众号迁移流程和方法
微信公众号迁移丨如何迁移微信公众号最详细微信公众号迁移流程和方法微信公众号如何迁移?微信公众号迁移公证书需要准备哪些资料? 怎么迁移微信公众号! 教你迁移微信公众号_迁移完成后,原账号就注销了,无 ...
干货丨渗透测试常用方法总结，大神之笔！
干货丨渗透测试常用方法总结,大神之笔! 一.渗透流程信息收集漏洞验证/漏洞攻击提权,权限维持日志清理信息收集一般先运行端口扫描和漏洞扫描获取可以利用的漏洞.多利用搜索引擎端口扫描有授权 ...
干货丨先搞懂这八大基础概念，再谈机器学习入门
翻译 | AI科技大本营参与 | 林椿眄准备好开始AI了吗?可能你已经开始了在机器学习领域的实践学习,但是依然想要扩展你的知识并进一步了解那些你听过却没有时间了解的话题. 这些机器学习的专业术语能 ...
cocos2d Labels and Fonts 标签和字体(附：关于Hiero的二三事)
Labels and Fonts 标签和字体 Introduction 介绍 cocos2d 支持 TTF (True Type Fonts) 标签和纹理 atlas 标签. Pros and Con ...

干货丨加密数据迁移二三事

干货丨加密数据迁移二三事相关推荐

最新文章

热门文章