在項目開發(fā)中都會要求保護用戶的敏感信息（如用戶的手機號碼、身份證號），一般不可以直接將敏感信息的明文數(shù)據(jù)存儲在數(shù)據(jù)庫中。但是在業(yè)務(wù)中又需要對一些敏感信息實現(xiàn)模糊查詢的功能，此時我們應(yīng)該怎么解決這個問題呢？下面我們介紹敏感信息加密后實現(xiàn)模糊查詢的功能的幾種常見的解決方案。
1、內(nèi)存解密方案
如果在數(shù)據(jù)庫里面的數(shù)據(jù)已經(jīng)加密了，此時我們將這些數(shù)據(jù)查詢到內(nèi)存中，然后進行解密操作，最后在解密后的數(shù)據(jù)中進行模糊查詢來篩選出符合條件的數(shù)據(jù)。
內(nèi)存解密方案的優(yōu)點是簡單方便，缺點是每次將加密后的數(shù)據(jù)整表加載到內(nèi)存中然后解密再匹配，隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)數(shù)據(jù)量會越來越大，那么很容易造成OOM。
2、明文映射查詢方案
如果要查詢186手機號開頭的用戶信息，首先通過186手機號在明文表中查詢對應(yīng)的用戶id，然后通過用戶id去用戶表中查詢對應(yīng)的用戶數(shù)據(jù)。
明文映射查詢方案使用明文映射表來存儲敏感字段，實際上相當(dāng)于敏感字段沒有加密存儲，看似解決了實際上并沒有解決。
3、加密函數(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ù)來進行查詢，如：
select * from user where AES_DECRYPT(phone,'key') like '%186';
加密函數(shù)方案實現(xiàn)成本比較低、開發(fā)成本上也簡單，但是這種方式存在如下的弊端：
（1）敏感數(shù)據(jù)的字段無法使用數(shù)據(jù)庫的索引來進行優(yōu)化。
（2）在一些數(shù)據(jù)庫中可能無法保證加密函數(shù)與業(yè)務(wù)代碼中的加密方式一樣。
4、分片加密方案
分片加密的方案是在明文映射查詢方案的基礎(chǔ)上進行延伸優(yōu)化，核心的思想是將敏感數(shù)據(jù)分詞，然后對這些分詞分別加密后再拼接組合在一起得到一串最終的密文，將這個最終的密文保存到數(shù)據(jù)庫中，如下是將手機號分段之后的密文的保存和查詢的流程圖：
假設(shè)有用戶手機號碼18168018974，我們按照前前3位、中間4位和尾號4位進行分詞之后，對這幾段分別的加密，如下所示：
| 181 | 6801 | 8974 |
| 0eJ1hEs6U3l= | 01qwers6U4l= | 0eJ1hEpoiu1= |
然后將這些分詞加密后密文組合拼接起來，如下：
0eJ1hEs6U3l=01qwers6U4l=0eJ1hEpoiu1=
將這個拼接后的密文保存到數(shù)據(jù)庫就是18168018974手機號的加密最終保存結(jié)果。
查詢的時候，假設(shè)業(yè)務(wù)人員通過手機號碼的前3位置查詢，那么我們將前3位加密后得到密文A1，通過密文A1去模糊匹配得到結(jié)果。
那么針對普通的字符如何分詞呢？假設(shè)有普通字符long1234，如果要讓其支持模糊查詢，此時我們按照4位一組進行分詞如下所示：
一般來講，分片加密方案中需要一定的限制:
（1）業(yè)界常用的分詞方案是4個英文數(shù)字或者2個漢字一組，再短的長度不建議支持，因為分詞組合越多就會導(dǎo)致存儲的成本增加，反而安全性降低。
（2）如果支持敏感字段的模糊檢索，那么加密的密文隨原文長度增長而增加。
總結(jié)：
（1）當(dāng)前主流的解決方案是分片加密方案，這種方案是以空間成本換取的，相比于存儲原文，密文比原文增長了好幾倍。
（2）內(nèi)存解密方案和明文映射查詢方案一般是不推薦使用。
（3）數(shù)據(jù)庫加密函數(shù)方案，存在無法使用數(shù)據(jù)庫索引和加密方式無法與業(yè)務(wù)代碼中保持一致等弊端。
該文章在 2024/12/9 14:55:32 編輯過
400 186 1886
