数据安全之数据库字段加解密检索和前端返回脱敏？看看我这个最强解决方案
前言
数据安全一直是我们老生常谈的话题了,随着国产化的日渐推进和数字化信息改革,数据安全越来越被人们所重视。数据库作为存储、管理和检索数据的核心基础设施，其中可能包含着大量的敏感信息，如个人手机号、身份证号码、银行账户、家庭地址等信息。为了保障这些敏感信息在部分情况下被明文泄露和未授权访问等恶意行为的侵害，数据库字段敏感信息加密变得至关重要。但是数据库列一旦加密那么就牵扯到很多问题。如何对数据库字段进行加密变得非常重要,目前主要有两个解决方案:
- 数据库自带加密函数或者使用数据库自定义函数方法进行加密解密
- 使用应用代码比如java、c#等语言自带的加密解密函数库
为了助力国产化的推进下面我将用solon + easy-query对其进行实践演练和原理进行解析。
当前项目地址demo https://gitee.com/xuejm/solon-encrypt
| 方法 | 优点 | 缺点 |
|---|---|---|
| 数据库函数对 | 实现简单,占用磁盘空间少,由数据库自行实现 | 模糊搜索效率低,与数据库函数绑定,兼容性差,仅可以使用数据库提供的函数或者自行编程数据库支持的加密解密 |
| java代码 | 模糊搜索效率高,不与数据库函数绑定,兼容性好,可以自行扩展实现国密等对称非对称加密 | 实现复杂,占用磁盘空间多 |
solon
文档地址 https://xuejm.gitee.io/easy-query-doc/
GITHUB地址 https://github.com/noear/solon
GITEE地址 https://gitee.com/noear/solon
easy-qeury
文档地址 https://xuejm.gitee.io/easy-query-doc/
GITHUB地址 https://github.com/xuejmnet/easy-query
GITEE地址 https://gitee.com/xuejm/easy-query
数据库处理
这边我们以mysql为例实现数据库函数的加密解密,对数据库列进行数据保护处理。
| 方法 | 默认值 |
|---|---|
| to_base64(AES_ENCRYPT('手机号值'),'秘钥') | 将数据进行aes加密,然后进行base64编码 |
| AES_DECRYPT(from_base64('手机号列'),'秘钥') | 将数据进行base64解码,然后进行aes进行解密 |
这两个方法其实很好理解,就是通过调用数据库函数让其在数据库层面就实现了加密和解密,应用程序获取到的数据本身就是解密好了的,但是缺点就是如果需要支持列的like搜索性能会变得非常低下,因为需要对加密列进行AES_DECRYPT(from_base64('手机号列'),'秘钥')的解密处理
select id,name,AES_DECRYPT(from_base64('phone'),'秘钥') as `phone` from user where AES_DECRYPT(from_base64('phone'),'秘钥') like '%567%'
当数据量少的时候那么数据库是比较轻松并且相对性能是可以接受的,但是随着数据量的越来越大,这种sql会慢慢变成瓶颈,那么是否有一种方案可以兼顾两者呢,其实是有的.
应用代码处理
分段加密,采用分段加密可以实现like语句的模糊搜索,并且支持数据的加密,但是这种方案也有缺点就是会比较占用空间,具体原理可以看下《阿里巴巴密文字段检索方案》 https://jaq-doc.alibaba.com/docs/doc.htm?treeId=1&articleId=106213&docType=1 文章给出了具体的实现方式,约定最少4位数字或者2位中文字符4位英文字符（半角），2个中文字符（全角）,比如12345678901这么一串
分别对其进行分段[1234,2345,3456,4567,5678,6789,7890,8901]分成8份,并且对每一份进行等长数据加密,也就是加密后的结果需要等长,比如都是16位或者都是8位
| 算法/模式/填充 | 16 字节加密后数据长度 | 不满 16 字节加密后长度 | 本次采用 |
|---|---|---|---|
| AES/CBC/NoPadding | 16 | 不支持 | ? |
| AES/CBC/PKCS5Padding | 32 | 16 | ? |
| AES/CBC/ISO10126Padding | 32 | 16 | ? |
| AES/CFB/NoPadding | 16 | 原始数据长度 | ? |
| AES/CFB/PKCS5Padding | 32 | 16 | ? |
| AES/CFB/ISO10126Padding | 32 | 16 | ? |
| AES/ECB/NoPadding | 16 | 不支持 | ? |
| AES/ECB/PKCS5Padding | 32 | 16 | ? |
| AES/ECB/ISO10126Padding | 32 | 16 | ? |
| AES/OFB/NoPadding | 16 | 原始数据长度 | ? |
| AES/OFB/PKCS5Padding | 32 | 16 | ? |
| AES/OFB/ISO10126Padding | 32 | 16 | ? |
| AES/PCBC/NoPadding | 16 | 不支持 | ? |
| AES/PCBC/PKCS5Padding | 32 | 16 | ? |
| AES/PCBC/ISO10126Padding | 32 | 16 | ? |
加密
我们可以选择任意一种这次选择AES/CBC/PKCS5Padding 因为我们的数据原因最终肯定不满16字节,所以加密后肯定都是16字节长度,然后可以对其进行base64编码,编码后会变成24字节在对其进行合并存储
base64(aes('1234')) + base64(aes('2345')) + base64(aes('3456')) +......+ base64(aes('7890')) + base64(aes('8901'))
,然后存入数据库,之后需要对其like的话限制最小like的数据应该满足最少4位数字或者2位中文字符4位英文字符（半角），2个中文字符（全角），比如我要查询包含45678的手机号只需要现对其进行分段[4567,5678]然后对其进行加密base64(aes('4567')) + base64(aes('5678'))
解密
因为我们采用aes加密后用base64编码拼接存入数据库,所以我们只需要对数据库的数据进行获取,之后判断其长度%24是否余数为0，如果是的话那么就将其进行以每24个长度为一组进行base64解码,然后通过aes解密.解密后在对其进行拼接还原出最初的明文数据
限制或缺点
- 通过上述可以知晓解密片段必须小于16字节长度base64后的加密信息必须是定长
- 字段会扩大,原本的n位明文如果需要支持加密那么将会让字段变得非常长,但是好处是支持非常高性能的like搜索
- 建议使用到定长的数据信息中,譬如手机号,身份证号码等
- 数据库函数加密解密不支持like操作符需要注意
- 不同的数据库需要适配不同的函数
优点
- 数据库函数实现简单
- 支持任意存储对象比如es
select * from user where phone like '%xxxxx%' -- 其中xxxx