在項(xiàng)目開發(fā)中都會(huì)要求保護(hù)用戶的敏感信息（如用戶的手機(jī)號(hào)碼、身份證號(hào)），一般不可以直接將敏感信息的明文數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)中。但是在業(yè)務(wù)中又需要對(duì)一些敏感信息實(shí)現(xiàn)模糊查詢的功能，此時(shí)我們應(yīng)該怎么解決這個(gè)問(wèn)題呢？下面我們介紹敏感信息加密后實(shí)現(xiàn)模糊查詢的功能的幾種常見的解決方案。

1、內(nèi)存解密方案

    如果在數(shù)據(jù)庫(kù)里面的數(shù)據(jù)已經(jīng)加密了，此時(shí)我們將這些數(shù)據(jù)查詢到內(nèi)存中，然后進(jìn)行解密操作，最后在解密后的數(shù)據(jù)中進(jìn)行模糊查詢來(lái)篩選出符合條件的數(shù)據(jù)。

    內(nèi)存解密方案的優(yōu)點(diǎn)是簡(jiǎn)單方便，缺點(diǎn)是每次將加密后的數(shù)據(jù)整表加載到內(nèi)存中然后解密再匹配，隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)數(shù)據(jù)量會(huì)越來(lái)越大，那么很容易造成OOM。

2、明文映射查詢方案

    如果要查詢186手機(jī)號(hào)開頭的用戶信息，首先通過(guò)186手機(jī)號(hào)在明文表中查詢對(duì)應(yīng)的用戶id，然后通過(guò)用戶id去用戶表中查詢對(duì)應(yīng)的用戶數(shù)據(jù)。

    明文映射查詢方案使用明文映射表來(lái)存儲(chǔ)敏感字段，實(shí)際上相當(dāng)于敏感字段沒有加密存儲(chǔ)，看似解決了實(shí)際上并沒有解決。

3、加密函數(shù)方案

    加密函數(shù)方案其實(shí)就是借助Mysql的加密函數(shù)，我們?cè)跀?shù)據(jù)庫(kù)中使用和業(yè)務(wù)代碼中一樣的加密算法，對(duì)添加到數(shù)據(jù)庫(kù)的敏感信息先加密保存，如下所示的加密插入：

SET @sensitive_text = "18698746523';
SET @encryption_key = "longxiabiancheng";
INSERT into user(name, phone) VALUES
("longxiabiancheng", AES_ENCRYPT(@sensitive_text, @encryption_key));

    然后每次去查詢的時(shí)候都會(huì)在where條件上對(duì)敏感數(shù)據(jù)字段使用加密函數(shù)來(lái)進(jìn)行查詢，如：

select * from user where AES_DECRYPT(phone,'key') like '%186';

    加密函數(shù)方案實(shí)現(xiàn)成本比較低、開發(fā)成本上也簡(jiǎn)單，但是這種方式存在如下的弊端：

（1）敏感數(shù)據(jù)的字段無(wú)法使用數(shù)據(jù)庫(kù)的索引來(lái)進(jìn)行優(yōu)化。

（2）在一些數(shù)據(jù)庫(kù)中可能無(wú)法保證加密函數(shù)與業(yè)務(wù)代碼中的加密方式一樣。

4、分片加密方案

    分片加密的方案是在明文映射查詢方案的基礎(chǔ)上進(jìn)行延伸優(yōu)化，核心的思想是將敏感數(shù)據(jù)分詞，然后對(duì)這些分詞分別加密后再拼接組合在一起得到一串最終的密文，將這個(gè)最終的密文保存到數(shù)據(jù)庫(kù)中，如下是將手機(jī)號(hào)分段之后的密文的保存和查詢的流程圖：

    假設(shè)有用戶手機(jī)號(hào)碼18168018974，我們按照前前3位、中間4位和尾號(hào)4位進(jìn)行分詞之后，對(duì)這幾段分別的加密，如下所示：

    然后將這些分詞加密后密文組合拼接起來(lái)，如下：

0eJ1hEs6U3l=01qwers6U4l=0eJ1hEpoiu1=

將這個(gè)拼接后的密文保存到數(shù)據(jù)庫(kù)就是18168018974手機(jī)號(hào)的加密最終保存結(jié)果。

    查詢的時(shí)候，假設(shè)業(yè)務(wù)人員通過(guò)手機(jī)號(hào)碼的前3位置查詢，那么我們將前3位加密后得到密文A1，通過(guò)密文A1去模糊匹配得到結(jié)果。

    那么針對(duì)普通的字符如何分詞呢？假設(shè)有普通字符long1234，如果要讓其支持模糊查詢，此時(shí)我們按照4位一組進(jìn)行分詞如下所示：

一般來(lái)講，分片加密方案中需要一定的限制:

（1）業(yè)界常用的分詞方案是4個(gè)英文數(shù)字或者2個(gè)漢字一組，再短的長(zhǎng)度不建議支持，因?yàn)榉衷~組合越多就會(huì)導(dǎo)致存儲(chǔ)的成本增加，反而安全性降低。

（2）如果支持敏感字段的模糊檢索，那么加密的密文隨原文長(zhǎng)度增長(zhǎng)而增加。

總結(jié)：

（1）當(dāng)前主流的解決方案是分片加密方案，這種方案是以空間成本換取的，相比于存儲(chǔ)原文，密文比原文增長(zhǎng)了好幾倍。

（2）內(nèi)存解密方案和明文映射查詢方案一般是不推薦使用。

（3）數(shù)據(jù)庫(kù)加密函數(shù)方案，存在無(wú)法使用數(shù)據(jù)庫(kù)索引和加密方式無(wú)法與業(yè)務(wù)代碼中保持一致等弊端。