前言

有一個(gè)問(wèn)題不知道大家想過(guò)沒(méi)？敏感字段數(shù)據(jù)是加密存儲(chǔ)在數(shù)據(jù)庫(kù)的表中，如果需要對(duì)這些敏感字段進(jìn)行模模糊查詢，還用原來(lái)的通過(guò)sql的where從句的like來(lái)模糊查詢的方式肯定是不行的，那么應(yīng)該怎么實(shí)現(xiàn)呢？這篇文章就來(lái)解決這個(gè)問(wèn)題。

場(chǎng)景分析

假如有類似這樣的一個(gè)場(chǎng)景：有一個(gè)人員管理的功能，人員信息列表的主要字段有姓名、性別、用戶賬號(hào)、手機(jī)號(hào)碼、身份證號(hào)碼、家庭住址、注冊(cè)日期等，可以對(duì)任意一條數(shù)據(jù)進(jìn)行增、刪、改、查，其中姓名、身份證號(hào)碼、手機(jī)號(hào)碼字段要支持模糊查詢。

簡(jiǎn)單分析一個(gè)場(chǎng)景，可以知道：手機(jī)號(hào)碼、身份證號(hào)碼、家庭人址字段數(shù)據(jù)是敏感數(shù)據(jù)，這些字段的數(shù)據(jù)是要加密存儲(chǔ)在數(shù)據(jù)庫(kù)里，在頁(yè)面上展示的時(shí)候需要進(jìn)行脫敏處理的。

如果用戶想要查詢真實(shí)姓名是包含有“張三”的所有人員信息，可以在頁(yè)面上輸入一個(gè)關(guān)鍵字，如“張三”，點(diǎn)擊開(kāi)始查詢后，這個(gè)參數(shù)會(huì)傳遞到后臺(tái)，后臺(tái)會(huì)執(zhí)行一條sql，如“select * from sys_person where real_name like ‘%張三%’”，執(zhí)行結(jié)果中包含了所有用戶真實(shí)姓名包含有“張三”的所有數(shù)據(jù)記錄，如“張三”，“張三豐”等。

如果用戶要查詢手機(jī)號(hào)碼尾號(hào)是“0537”的用戶，后臺(tái)執(zhí)行類似與姓名模糊查詢的sql，"select * from sys_person where phone like '%0537'"，肯定是得不到正確的結(jié)果的，因?yàn)槭謾C(jī)號(hào)碼字段在數(shù)據(jù)庫(kù)中的數(shù)據(jù)是加密后的結(jié)果，而‘0537’是明文。身份證號(hào)碼、家庭住址等其他敏感字段在模糊查詢的時(shí)候也都有類似這樣的問(wèn)題，這也是敏感字段模糊查詢的痛點(diǎn)，即模糊查詢關(guān)鍵字與實(shí)際存儲(chǔ)的數(shù)據(jù)不一致。

實(shí)現(xiàn)方案

下面分享幾種解決方案：

第一種，先解密再查詢

查詢出目標(biāo)表內(nèi)所有的數(shù)據(jù)，在內(nèi)存中對(duì)要模糊查詢的敏感字段的加密數(shù)據(jù)進(jìn)行解密，然后再遍歷解密后的數(shù)據(jù)，與模糊查詢關(guān)鍵字進(jìn)行比較，篩選出包含有模糊查詢關(guān)鍵字的數(shù)據(jù)行。

這種方法是最容易想到的，但有一個(gè)比較明顯的問(wèn)題是，模糊查詢的過(guò)程是在內(nèi)存中進(jìn)行的，如果數(shù)據(jù)量特別大，很容易導(dǎo)致內(nèi)存溢出，因此不推薦在生產(chǎn)中使用這種方法；

第二種，明文映射表

新建一張映射表，存儲(chǔ)敏感字段解密后的數(shù)據(jù)與目標(biāo)表主鍵的映射表，需要模糊查詢的時(shí)候，先對(duì)明文映射表進(jìn)行模糊查詢，得到符合條件的目標(biāo)數(shù)據(jù)的主鍵，再返回來(lái)根據(jù)主鍵查詢目標(biāo)表；

這種方法，實(shí)際上是有點(diǎn)掩耳盜鈴的感覺(jué)，敏感字段加密存儲(chǔ)的字段主要是考慮到安全性，使用明文映射表來(lái)存儲(chǔ)解密后的敏感字段，實(shí)際上相當(dāng)于敏感字段沒(méi)有加密存儲(chǔ)，與最被要對(duì)敏感字段加密的初衷相違背，因此不推薦在生產(chǎn)中使用這種方法；

第三種，數(shù)據(jù)庫(kù)層面進(jìn)行解密查詢

后臺(tái)在執(zhí)行查詢sql時(shí)對(duì)敏感字段先解密，然后再執(zhí)行l(wèi)ike，以上面的人員管理列表模糊查詢?yōu)槔磳?duì)sql的改造為：“select * from sys_person where AES_DECRYPT(phone,'key') like '%0537'”;

這種方法的優(yōu)點(diǎn)是，成本比較小，容易實(shí)現(xiàn)，但是缺點(diǎn)很明顯，該字段無(wú)法通過(guò)數(shù)據(jù)庫(kù)索引來(lái)優(yōu)化查詢，另外有一些數(shù)據(jù)庫(kù)無(wú)法保證數(shù)據(jù)庫(kù)的加解密算法與程序的加解密算法一致，可能會(huì)導(dǎo)致可以程序中加密，但是無(wú)法在數(shù)據(jù)庫(kù)中解密的或者可以在數(shù)據(jù)庫(kù)加密無(wú)法在程序中解密的問(wèn)題，因此不推薦在生產(chǎn)中使用這種方法；

第四種，分詞密文映射表

這種方法是對(duì)第二種思路的基礎(chǔ)上進(jìn)行延伸優(yōu)化，也是主流的方法。新建一張分詞密文映射表，在敏感字段數(shù)據(jù)新增、修改的后，對(duì)敏感字段進(jìn)行分詞組合，如“15503770537”的分詞組合有“155”、“0377”、“0537”等，再對(duì)每個(gè)分詞進(jìn)行加密，建立起敏感字段的分詞密文與目標(biāo)數(shù)據(jù)行主鍵的關(guān)聯(lián)關(guān)系；在處理模糊查詢的時(shí)候，對(duì)模糊查詢關(guān)鍵字進(jìn)行加密，用加密后的模糊查詢關(guān)鍵字，對(duì)分詞密文映射表進(jìn)行l(wèi)ike查詢，得到目標(biāo)數(shù)據(jù)行的主鍵，再以目標(biāo)數(shù)據(jù)行的主鍵為條件返回目標(biāo)表進(jìn)行精確查詢。

圖片一：分組組合加密前



圖片二：分組組合加密后

這種方法的優(yōu)點(diǎn)就是原理簡(jiǎn)單，實(shí)現(xiàn)起來(lái)也不復(fù)雜，但是有一定的局限性，算是一個(gè)對(duì)性能、業(yè)務(wù)相折中的一個(gè)方案，相比較之下，在能想的方法中，比較推薦這種方法，但是要特別注意的是，對(duì)模糊查詢的關(guān)鍵字的長(zhǎng)度，要在業(yè)務(wù)層面進(jìn)行限制；以手機(jī)號(hào)為例，可以要求對(duì)模糊查詢的關(guān)鍵字是四位或者是五位，具體可以再根據(jù)具體的場(chǎng)景進(jìn)行詳細(xì)劃分。

為什么要增加這樣的限制呢？因?yàn)槊魑募用芎箝L(zhǎng)度為變長(zhǎng)，有額外的存儲(chǔ)成本和查詢性能成本，分詞組合越多，需要的存儲(chǔ)空間以及所消耗的查詢性能成本也就更大，并且分詞越短，被硬破解的可能性也就越大，也會(huì)在一定程度上導(dǎo)致安全性降低；

環(huán)境配置

jdk版本:1.8開(kāi)發(fā)工具：Intellij iDEA 2020.1

springboot:2.3.9.RELEASE

mybatis-spring-boot-starter：2.1.4

依賴配置

示例主要用到了SpringAop，加密是對(duì)稱加密，用到了hutool工具包里的加密解密工具類，也可以使用自己封裝的加密解密工具類。

org.springframework.boot
spring-boot-starter-aop


cn.hutool
hutool-all
5.3.3

代碼實(shí)現(xiàn)

1、新建分詞密文映射表；

如果是多個(gè)模糊查詢的字段，可以共用在一張分詞密文映射表中擴(kuò)展多個(gè)字段，以示例中的人員管理功能為例，新建sys_person_phone_encrypt表（人員的手機(jī)號(hào)碼分詞密文映射表），用于存儲(chǔ)人員id與分詞組合密文的映射關(guān)系

createtableifnotexistssys_person_phone_encrypt
(
idbigintauto_incrementcomment'主鍵'primarykey,
person_idintnotnullcomment'關(guān)聯(lián)人員信息表主鍵',
phone_keyvarchar(500)notnullcomment'手機(jī)號(hào)碼分詞密文'
)
comment'人員的手機(jī)號(hào)碼分詞密文映射表';

2、敏感字段數(shù)據(jù)在保存入庫(kù)的時(shí)候，對(duì)敏感字段進(jìn)行分詞組合并加密碼，存儲(chǔ)在分詞密文映射表；

在注冊(cè)人員信息的時(shí)候，先取出通過(guò)AOP進(jìn)行加密過(guò)的手機(jī)號(hào)碼進(jìn)行解密；手機(jī)號(hào)碼解密之后，對(duì)手機(jī)號(hào)碼按照連續(xù)四位進(jìn)行分詞組合，并對(duì)每一個(gè)手機(jī)號(hào)碼的分詞進(jìn)行加密，最后把所有的加密后手機(jī)號(hào)碼分詞拼接成一個(gè)字符串，與人員id一起保存到人員的手機(jī)號(hào)碼分詞密文映射表；

publicPersonregiste(Personperson){
this.personDao.insert(person);
Stringphone=this.decrypt(person.getPhoneNumber());
StringphoneKeywords=this.phoneKeywords(phone);
this.personDao.insertPhoneKeyworkds(person.getId(),phoneKeywords);
returnperson;
}
privateStringphoneKeywords(Stringphone){
Stringkeywords=this.keywords(phone,4);
System.out.println(keywords.length());
returnkeywords;
}

//分詞組合加密
privateStringkeywords(Stringword,intlen){
StringBuildersb=newStringBuilder();
for(inti=0;i

	

	3、模糊查詢的時(shí)候，對(duì)模糊查詢關(guān)鍵字進(jìn)行加密，以加密后的關(guān)鍵字密文為查詢條件，查詢密文映射表，得到目標(biāo)數(shù)據(jù)行的id，再以目標(biāo)數(shù)據(jù)行id為查詢條件，查詢目標(biāo)數(shù)據(jù)表；

	根據(jù)手機(jī)號(hào)碼的四位進(jìn)行模糊查詢的時(shí)候，以加密后模糊查詢的關(guān)鍵字為條件，查詢sys_person_phone_encrypt表（人員的手機(jī)號(hào)碼分詞密文映射表），得到人員信息id；再以人員信息id，查詢?nèi)藛T信息表；

	
publicListgetPersonList(StringphoneVal){
if(phoneVal!=null){
returnthis.personDao.queryByPhoneEncrypt(this.encrypt(phoneVal));
}
returnthis.personDao.queryList(phoneVal);
}

select*fromsys_personwhereidin
(selectperson_idfromsys_person_phone_encrypt
wherephone_keylikeconcat('%',#{phoneVal},'%'))





圖片三：模糊查詢“6666”

	

	




	審核編輯：劉清