前言

前幾天，知識(shí)星球中有位小伙伴，問了我一個(gè)問題：加密的手機(jī)號(hào)如何模糊查詢？

我們都知道，在做系統(tǒng)設(shè)計(jì)時(shí)，考慮到系統(tǒng)的安全性，需要對(duì)用戶的一些個(gè)人隱私信息，比如：登錄密碼、身份證號(hào)、銀行卡號(hào)、手機(jī)號(hào)等，做加密處理，防止用戶的個(gè)人信息被泄露。

很早之前，CSDN遭遇了SQL注入，導(dǎo)致了600多萬條明文保存的用戶信息被泄。

因此，我們?cè)谧鱿到y(tǒng)設(shè)計(jì)的時(shí)候，要考慮要把用戶的隱私信息加密保存。

常見的對(duì)稱加密算法有 AES、SM4、ChaCha20、3DES、DES、Blowfish、IDEA、RC5、RC6、Camellia等。

目前國際主流的對(duì)稱加密算法是AES，國內(nèi)主推的則是SM4。

無論是用哪種算法，加密前的字符串，和加密后的字符串，差別還是比較大的。

比如加密前的字符串：蘇三說技術(shù)，使用密鑰：123，生成加密后的字符串為：U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=。

如何對(duì)加密后的字符串做模糊查詢呢？

比如：假設(shè)查詢蘇三關(guān)鍵字，加密后的字符串是：U2FsdGVkX19eCv+xt2WkQb5auYo0ckyw。

上面生成的兩個(gè)加密字符串差異看起來比較大，根本沒辦法直接通過SQL語句中的like關(guān)鍵字模糊查詢。

那我們?cè)撛趺磳?shí)現(xiàn)加密的手機(jī)號(hào)的模糊查詢功能呢？

1 一次加載到內(nèi)存

實(shí)現(xiàn)這個(gè)功能，我們第一個(gè)想到的辦法可能是：把個(gè)人隱私數(shù)據(jù)一次性加載到內(nèi)存中緩存起來，然后在內(nèi)存中先解密，然后在代碼中實(shí)現(xiàn)模糊搜索的功能。

圖片

這樣做的好處是：實(shí)現(xiàn)起來比較簡(jiǎn)單，成本非常低。

但帶來的問題是：如果個(gè)人隱私數(shù)據(jù)非常多的話，應(yīng)用服務(wù)器的內(nèi)存不一定夠用，可能會(huì)出現(xiàn)OOM問題。

還有另外一個(gè)問題是：數(shù)據(jù)一致性問題。

如果用戶修改了手機(jī)號(hào)，數(shù)據(jù)庫更新成功了，需要同步更新內(nèi)存中的緩存，否則用戶查詢的結(jié)果可能會(huì)跟實(shí)際情況不一致。

比如：數(shù)據(jù)庫更新成功了，內(nèi)存中的緩存更新失敗了。

或者你的應(yīng)用，部署了多個(gè)服務(wù)器節(jié)點(diǎn)，有一部分內(nèi)存緩存更新成功了，另外一部分剛好在重啟，導(dǎo)致更新失敗了。

該方案不僅可能會(huì)導(dǎo)致應(yīng)用服務(wù)器出現(xiàn)OOM問題，也可能會(huì)導(dǎo)致系統(tǒng)的復(fù)雜度提升許多，總體來說，有點(diǎn)得不償失。

2 使用數(shù)據(jù)庫函數(shù)

既然數(shù)據(jù)庫中保存的是加密后的字符串，還有一種方案是使用數(shù)據(jù)庫的函數(shù)解密。

我們可以使用MySQL的DES_ENCRYPT函數(shù)加密，使用DES_DECRYPT函數(shù)解密：

SELECT 
DES_DECRYPT('U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=', '123');

應(yīng)用系統(tǒng)重所有的用戶隱私信息的加解密都在MySQL層實(shí)現(xiàn)，不存在加解密不一致的情況。

該方案中保存數(shù)據(jù)時(shí)，只對(duì)單個(gè)用戶的數(shù)據(jù)進(jìn)行操作，數(shù)據(jù)量比較小，性能還好。

但模糊查詢數(shù)據(jù)時(shí)，每一次都需要通過DES_DECRYPT函數(shù)，把數(shù)據(jù)庫中用戶某個(gè)隱私信息字段的所有數(shù)據(jù)都解密了，然后再通過解密后的數(shù)據(jù)，做模糊查詢。

如果該字段的數(shù)據(jù)量非常大，這樣每次查詢的性能會(huì)非常差。

3 分段保存

我們可以將一個(gè)完整的字符串，拆分成多個(gè)小的字符串。

以手機(jī)號(hào)為例：18200256007，按每3位為一組，進(jìn)行拆分，拆分后的字符串為：182,820,200,002,025,256,560,600,007，這9組數(shù)據(jù)。

然后建一張表：

CREATE TABLE `encrypt_value_mapping` (
  `id` bigint NOT NULL COMMENT '系統(tǒng)編號(hào)',
  `ref_id` bigint NOT NULL COMMENT '關(guān)聯(lián)系統(tǒng)編號(hào)',
  `encrypt_value` varchar(255) NOT NULL COMMENT '加密后的字符串'
) ENGINE=InnoDB  CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='分段加密映射表'

這張表有三個(gè)字段：

• id：系統(tǒng)編號(hào)。
• ref_id：主業(yè)務(wù)表的系統(tǒng)編號(hào)，比如用戶表的系統(tǒng)編號(hào)。
• encrypt_value：拆分后的加密字符串。

用戶在寫入手機(jī)號(hào)的時(shí)候，同步把拆分之后的手機(jī)號(hào)分組數(shù)據(jù)，也一起寫入，可以保證在同一個(gè)事務(wù)當(dāng)中，保證數(shù)據(jù)的一致性。

如果要模糊查詢手機(jī)號(hào)，可以直接通過encrypt_value_mapping的encrypt_value模糊查詢出用戶表的ref_id，再通過ref_id查詢用戶信息。

具體sql如下：

select s2.id,s2.name,s2.phone 
from encrypt_value_mapping s1
inner join `user` s2 on s1.ref_id=s2.id
where s1.encrypt_value = 'U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB'
limit 0,20;

這樣就能輕松的通過模糊查詢，搜索出我們想要的手機(jī)號(hào)了。

注意這里的encrypt_value用的等于號(hào)，由于是等值查詢，效率比較高。

注意：這里通過sql語句查詢出來的手機(jī)號(hào)是加密的，在接口返回給前端之前，需要在代碼中統(tǒng)一做解密處理。

為了安全性，還可以將加密后的明文密碼，用*號(hào)增加一些干擾項(xiàng)，防止手機(jī)號(hào)被泄露，最后展示給用戶的內(nèi)容，可以顯示成這樣的：182***07。

4 其他的模糊查詢

如果除了用戶手機(jī)號(hào)，還有其他的用戶隱私字段需要模糊查詢的場(chǎng)景，該怎么辦？

我們可以將encrypt_value_mapping表擴(kuò)展一下，增加一個(gè)type字段。

該字段表示數(shù)據(jù)的類型，比如：1.手機(jī)號(hào) 2.身份證 3.銀行卡號(hào)等。

這樣如果有身份證和銀行卡號(hào)模塊查詢的業(yè)務(wù)場(chǎng)景，我們可以通過type字段做區(qū)分，也可以使用這套方案，將數(shù)據(jù)寫入到encrypt_value_mapping表，最后根據(jù)不同的type查詢出不同的分組數(shù)據(jù)。

如果業(yè)務(wù)表中的數(shù)據(jù)量少，這套方案是可以滿足需求的。

但如果業(yè)務(wù)表中的數(shù)據(jù)量很大，一個(gè)手機(jī)號(hào)就需要保存9條數(shù)據(jù)，一個(gè)身份證或者銀行卡號(hào)也需要保存很多條數(shù)據(jù)，這樣會(huì)導(dǎo)致encrypt_value_mapping表的數(shù)據(jù)急劇增加，可能會(huì)導(dǎo)致這張表非常大。

最后的后果是非常影響查詢性能。

那么，這種情況該怎么辦呢？

5 增加模糊查詢字段

如果數(shù)據(jù)量多的情況下，將所有用戶隱私信息字段，分組之后，都集中到一張表中，確實(shí)非常影響查詢的性能。

那么，該如何優(yōu)化呢？

答：我們可以增加模糊查詢字段。

還是以手機(jī)模糊查詢?yōu)槔?/p>

我們可以在用戶表中，在手機(jī)號(hào)旁邊，增加一個(gè)encrypt_phone字段。

CREATE TABLE `user` (
  `id` int NOT NULL,
  `code` varchar(20)  NOT NULL,
  `age` int NOT NULL DEFAULT '0',
  `name` varchar(30) NOT NULL,
  `height` int NOT NULL DEFAULT '0',
  `address` varchar(30)  DEFAULT NULL,
  `phone` varchar(11) DEFAULT NULL,
  `encrypt_phone` varchar(255)  DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='用戶表'

然后我們?cè)诒４鏀?shù)據(jù)的時(shí)候，將分組之后的數(shù)據(jù)拼接起來。

還是以手機(jī)號(hào)為例：

18200256007，按每3位為一組，進(jìn)行拆分，拆分后的字符串為：182,820,200,002,025,256,560,600,007，這9組數(shù)據(jù)。

分組之后，加密之后，用逗號(hào)分割之后拼接成這樣的數(shù)據(jù)：,U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB,U2FsdGVkX1+qysCDyVMm/aYXMRpCEmBD,U2FsdGVkX19oXuv8m4ZAjz+AGhfXlsQk,U2FsdGVkX19VFs60R26BLFzv5nDZX40U,U2FsdGVkX19XPO0by9pVw4GKnGI3Z5Zs,U2FsdGVkX1/FIIaYpHlIlrngIYEnuwlM,U2FsdGVkX19s6WTtqngdAM9sgo5xKvld,U2FsdGVkX19PmLyjtuOpsMYKe2pmf+XW,U2FsdGVkX1+cJ/qussMgdPQq3WGdp16Q。

以后可以直接通過sql模糊查詢字段encrypt_phone了：

select id,name,phone
from user where encrypt_phone like '%U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB%'
limit 0,20;

注意這里的encrypt_value用的like。

這里為什么要用逗號(hào)分割呢？

答：是為了防止直接字符串拼接，在極端情況下，兩個(gè)分組的數(shù)據(jù)，原本都不滿足模糊搜索條件，但拼接在一起，卻有一部分滿足條件的情況發(fā)生。

當(dāng)然你也可以根據(jù)實(shí)際情況，將逗號(hào)改成其他的特殊字符。

此外，其他的用戶隱私字段，如果要實(shí)現(xiàn)模糊查詢功能，也可以使用類似的方案。

最后說一句，雖說本文介紹了多種加密手機(jī)號(hào)實(shí)現(xiàn)模糊查詢功能的方案，但我們要根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景來選擇，沒有最好的方案，只有最合適的。