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

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

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

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

2、明文映射查詢方案

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

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

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

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

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

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

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

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

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

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

4、分片加密方案

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

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

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

0eJ1hEs6U3l=01qwers6U4l=0eJ1hEpoiu1=

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

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

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

一般來講，分片加密方案中需要一定的限制:

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

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

總結(jié)：

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

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

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