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