數(shù)據(jù)庫(kù)加密字段進(jìn)行模糊查詢?cè)斀?/h1>
更新時(shí)間:2022年09月05日 10:00:46 作者:jiaxwu
這篇文章主要為大家介紹了數(shù)據(jù)庫(kù)加密字段進(jìn)行模糊查詢?cè)斀?,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
需求
對(duì)于一些敏感字段,比如手機(jī)號(hào)碼、身份證、地址、銀行卡號(hào)等,我們?cè)诖娣胚M(jìn)數(shù)據(jù)庫(kù)前,可能需要對(duì)其進(jìn)行加密。
大部分情況下,我們只需要支持等值查詢。但是如果需要支持模糊查詢,那么整段內(nèi)容整體加密就不具備這個(gè)能力。
下面是幾種解決辦法,場(chǎng)景是我們需要根據(jù)手機(jī)號(hào)碼的前綴進(jìn)行匹配。
服務(wù)器端解密
因?yàn)榉?wù)器肯定是具備解密密文的能力的,因此最簡(jiǎn)單的方式就是把整個(gè)表的密文字段數(shù)據(jù)拉下來,在服務(wù)器端進(jìn)行解密,然后再在服務(wù)器端進(jìn)行匹配。
findRecords(prefix) {
records = getAllRecords()
finds = []
for (record : records) {
phone = decrypt(record.phone)
if (phone.hasPrefix(prefix)) {
finds.push(record)
}
}
return finds
}
如果數(shù)據(jù)量很小,那么這種做法也許還能夠接受。但是只要數(shù)據(jù)量上去,那么效率就會(huì)很低,而且還需要通過網(wǎng)絡(luò)IO把整個(gè)表的數(shù)據(jù)傳輸?shù)椒?wù)器端。
數(shù)據(jù)庫(kù)端解密
上面的做法需要把整個(gè)表的數(shù)據(jù)傳輸?shù)椒?wù)器端,那么我們只需要能夠在數(shù)據(jù)庫(kù)進(jìn)行匹配,就不需要傳輸整個(gè)表了。因此我們也可以在數(shù)據(jù)庫(kù)實(shí)現(xiàn)解密算法,在匹配的時(shí)候用解密算法解密密文,就能夠進(jìn)行模糊匹配了。
findRecords(prefix) {
return query("select * from table where decrypt(phone) like '?%'", prefix)
}
這個(gè)做法也是需要遍歷整個(gè)數(shù)據(jù)庫(kù),因此只適合數(shù)據(jù)量比較小的情況下;而且需要把密鑰傳給數(shù)據(jù)庫(kù),增加了密鑰泄露的風(fēng)險(xiǎn)。
字符串分片
上面的做法我們都沒有用到數(shù)據(jù)庫(kù)的索引能力,正常情況下,前綴匹配我們是可以使用到索引的,比如where phone like 'prefix%'。如果加密后的密文,也能夠走索引,那么我們就不需要遍歷整個(gè)數(shù)據(jù)表了。
比如我們可以根據(jù)4位作為一個(gè)檢索條件,將手機(jī)號(hào)碼拆分位多個(gè)分片:比如手機(jī)號(hào)012345678901,我們可以拆分并對(duì)分片進(jìn)行加密:
分片 密文 0123 /egpaR5G9sMQUUWWz+3CLg 1234 eHCMZqxNSLx/B37koArx/w 2345 9w1Pv8ik2H41s1KORLfPHA 3456 vcFFFvi0mwAgIjdSQjcmSw 4567 Tr/WaYfVySyMJhcZ78RFlA 5678 2wFeC6sgdXX7wmo0YcYY/Q 6789 FfO9qD9XPx/lnJJuTfTfaA 7890 Wufth7zOBLEy2LmepG5Taw 8901 1xR5MHRmlqOac5X6Cmn3kA
這些密文拼接起來的串為:
/egpaR5G9sMQUUWWz+3CLgeHCMZqxNSLx/B37koArx/w9w1Pv8ik2H41s1KORLfPHAvcFFFvi0mwAgIjdSQjcmSwTr/WaYfVySyMJhcZ78RFlA2wFeC6sgdXX7wmo0YcYY/QFfO9qD9XPx/lnJJuTfTfaAWufth7zOBLEy2LmepG5Taw1xR5MHRmlqOac5X6Cmn3kA
然后就可以支持前綴查詢了(最少4位),比如前綴01234,我們可以按照上面的分片方式先分片,再拼接為查詢串:
分片 密文 0123 /egpaR5G9sMQUUWWz+3CLg 1234 eHCMZqxNSLx/B37koArx/w
查詢串:
/egpaR5G9sMQUUWWz+3CLgeHCMZqxNSLx/B37koArx/w
可以看到查詢串為上面的前綴,因此可以進(jìn)行前綴查詢!
代價(jià)
這種方式也是會(huì)有一定的代價(jià)的:
密文長(zhǎng)度較長(zhǎng)
比如手機(jī)號(hào)碼是明文長(zhǎng)度是11,但是按照4位分片的密文長(zhǎng)度是198
分片長(zhǎng)度不能太短
分片太短有安全問題,因此沒辦法支持過短的查詢。
主要是因?yàn)榍衅^短,會(huì)很容易被猜出來每一位對(duì)應(yīng)的密文。比如0-9的密文切片長(zhǎng)度1切分:
分片 密文 0 hHjJXA0e+haw/+WZ1mFITA 1 y7qHn2nn3Ne/6wNRiwl/Lg 2 h0dmfkO5SUolFFLp8J2Y5A 3 ma/XrJjPv2MXSXE7Y4xs8w 4 Q9V4PXXPjJgdR7UChUMY1g 5 Wo57z24UXLoBdQ7QzxlOqA 6 fC+zrF4ga5TCb5Zu36KVrQ 7 z+XqHaWmlAsCnIP6NnD3lg 8 olm8cPYmLHCeD1jegauiWw 9 hJS77tLMd2Ol5SU4dIbbpw
只有10種分片類型,如果對(duì)應(yīng)的是手機(jī)號(hào)碼字段,很容易根據(jù)統(tǒng)計(jì)每個(gè)數(shù)字的概率分布猜出每個(gè)數(shù)字對(duì)應(yīng)的密文。
可能有多余結(jié)果
可能有兩個(gè)不同分片對(duì)應(yīng)相同密文,這時(shí)候就需要在服務(wù)器再過濾一遍。
參考
實(shí)現(xiàn)
Golang實(shí)現(xiàn)基于AES+CBC+PKCS5Padding的可模糊查詢加密
以上就是數(shù)據(jù)庫(kù)加密字段進(jìn)行模糊查詢?cè)斀獾脑敿?xì)內(nèi)容,更多關(guān)于數(shù)據(jù)庫(kù)加密字段模糊查詢的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
-
關(guān)于hive表的存儲(chǔ)格式ORC格式的使用詳解
這篇文章主要介紹了關(guān)于hive表的存儲(chǔ)格式ORC格式的使用詳解,Hive?是基于?Hadoop?的一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具,可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張表,并提供類SQL查詢功能,需要的朋友可以參考下 2023-07-07
-
Navicat卡住一直在執(zhí)行中的簡(jiǎn)單解決辦法
眾所周知Navicat是我們常用的連接MYSQL工具,非常方便好用,其實(shí)日常中我們也常常會(huì)遇到運(yùn)行時(shí)間很長(zhǎng)甚至幾乎跑不完卡死的情況,這篇文章主要給大家介紹了關(guān)于Navicat卡住一直在執(zhí)行中的簡(jiǎn)單解決辦法,需要的朋友可以參考下 2023-11-11
-
ACCESS轉(zhuǎn)SQLSERVER數(shù)據(jù)庫(kù)的注意事項(xiàng)
Access承重量太低,當(dāng)你考慮升級(jí)到SQL Server時(shí),并不只是個(gè)連接字符串需要改變,需要改變的還有很多 2007-01-01
-
mongoDB和mysql對(duì)比分析及選擇(詳細(xì)版)
這篇文章主要介紹了mongoDB和mysql對(duì)比分析及選擇(詳細(xì)版),需要的朋友可以參考下 2023-06-06
-
海量數(shù)據(jù)庫(kù)的查詢優(yōu)化及分頁(yè)算法方案 2 之 改良SQL語(yǔ)句
海量數(shù)據(jù)庫(kù)的查詢優(yōu)化及分頁(yè)算法方案 2 之 改良SQL語(yǔ)句... 2007-03-03
-
由拖庫(kù)攻擊談口令字段的加密策略(數(shù)據(jù)庫(kù)加密)
我不得不慘痛地寫在前面的是,這是一個(gè)安全崩盤的時(shí)代。過去一年,已經(jīng)證實(shí)的遭遇入侵、并導(dǎo)致關(guān)鍵數(shù)據(jù)被竊或者被泄露的公司,包括索尼、世嘉這樣的大型游戲設(shè)備廠商;包括花旗銀行這樣的金融機(jī)構(gòu),也包括了RSA這樣的安全廠商 2012-01-01
-
當(dāng)數(shù)據(jù)庫(kù)變慢時(shí)的解決方法
當(dāng)數(shù)據(jù)庫(kù)變慢時(shí),我們應(yīng)如何入手,下面的解決方法。 2009-04-04
最新評(píng)論
需求
對(duì)于一些敏感字段,比如手機(jī)號(hào)碼、身份證、地址、銀行卡號(hào)等,我們?cè)诖娣胚M(jìn)數(shù)據(jù)庫(kù)前,可能需要對(duì)其進(jìn)行加密。
大部分情況下,我們只需要支持等值查詢。但是如果需要支持模糊查詢,那么整段內(nèi)容整體加密就不具備這個(gè)能力。
下面是幾種解決辦法,場(chǎng)景是我們需要根據(jù)手機(jī)號(hào)碼的前綴進(jìn)行匹配。
服務(wù)器端解密
因?yàn)榉?wù)器肯定是具備解密密文的能力的,因此最簡(jiǎn)單的方式就是把整個(gè)表的密文字段數(shù)據(jù)拉下來,在服務(wù)器端進(jìn)行解密,然后再在服務(wù)器端進(jìn)行匹配。
findRecords(prefix) { records = getAllRecords() finds = [] for (record : records) { phone = decrypt(record.phone) if (phone.hasPrefix(prefix)) { finds.push(record) } } return finds }
如果數(shù)據(jù)量很小,那么這種做法也許還能夠接受。但是只要數(shù)據(jù)量上去,那么效率就會(huì)很低,而且還需要通過網(wǎng)絡(luò)IO把整個(gè)表的數(shù)據(jù)傳輸?shù)椒?wù)器端。
數(shù)據(jù)庫(kù)端解密
上面的做法需要把整個(gè)表的數(shù)據(jù)傳輸?shù)椒?wù)器端,那么我們只需要能夠在數(shù)據(jù)庫(kù)進(jìn)行匹配,就不需要傳輸整個(gè)表了。因此我們也可以在數(shù)據(jù)庫(kù)實(shí)現(xiàn)解密算法,在匹配的時(shí)候用解密算法解密密文,就能夠進(jìn)行模糊匹配了。
findRecords(prefix) { return query("select * from table where decrypt(phone) like '?%'", prefix) }
這個(gè)做法也是需要遍歷整個(gè)數(shù)據(jù)庫(kù),因此只適合數(shù)據(jù)量比較小的情況下;而且需要把密鑰傳給數(shù)據(jù)庫(kù),增加了密鑰泄露的風(fēng)險(xiǎn)。
字符串分片
上面的做法我們都沒有用到數(shù)據(jù)庫(kù)的索引能力,正常情況下,前綴匹配我們是可以使用到索引的,比如where phone like 'prefix%'。如果加密后的密文,也能夠走索引,那么我們就不需要遍歷整個(gè)數(shù)據(jù)表了。
比如我們可以根據(jù)4位作為一個(gè)檢索條件,將手機(jī)號(hào)碼拆分位多個(gè)分片:比如手機(jī)號(hào)012345678901,我們可以拆分并對(duì)分片進(jìn)行加密:
分片 | 密文 |
---|---|
0123 | /egpaR5G9sMQUUWWz+3CLg |
1234 | eHCMZqxNSLx/B37koArx/w |
2345 | 9w1Pv8ik2H41s1KORLfPHA |
3456 | vcFFFvi0mwAgIjdSQjcmSw |
4567 | Tr/WaYfVySyMJhcZ78RFlA |
5678 | 2wFeC6sgdXX7wmo0YcYY/Q |
6789 | FfO9qD9XPx/lnJJuTfTfaA |
7890 | Wufth7zOBLEy2LmepG5Taw |
8901 | 1xR5MHRmlqOac5X6Cmn3kA |
這些密文拼接起來的串為:
/egpaR5G9sMQUUWWz+3CLgeHCMZqxNSLx/B37koArx/w9w1Pv8ik2H41s1KORLfPHAvcFFFvi0mwAgIjdSQjcmSwTr/WaYfVySyMJhcZ78RFlA2wFeC6sgdXX7wmo0YcYY/QFfO9qD9XPx/lnJJuTfTfaAWufth7zOBLEy2LmepG5Taw1xR5MHRmlqOac5X6Cmn3kA
然后就可以支持前綴查詢了(最少4位),比如前綴01234,我們可以按照上面的分片方式先分片,再拼接為查詢串:
分片 | 密文 |
---|---|
0123 | /egpaR5G9sMQUUWWz+3CLg |
1234 | eHCMZqxNSLx/B37koArx/w |
查詢串:
/egpaR5G9sMQUUWWz+3CLgeHCMZqxNSLx/B37koArx/w
可以看到查詢串為上面的前綴,因此可以進(jìn)行前綴查詢!
代價(jià)
這種方式也是會(huì)有一定的代價(jià)的:
密文長(zhǎng)度較長(zhǎng)
比如手機(jī)號(hào)碼是明文長(zhǎng)度是11,但是按照4位分片的密文長(zhǎng)度是198
分片長(zhǎng)度不能太短
分片太短有安全問題,因此沒辦法支持過短的查詢。
主要是因?yàn)榍衅^短,會(huì)很容易被猜出來每一位對(duì)應(yīng)的密文。比如0-9的密文切片長(zhǎng)度1切分:
分片 | 密文 |
---|---|
0 | hHjJXA0e+haw/+WZ1mFITA |
1 | y7qHn2nn3Ne/6wNRiwl/Lg |
2 | h0dmfkO5SUolFFLp8J2Y5A |
3 | ma/XrJjPv2MXSXE7Y4xs8w |
4 | Q9V4PXXPjJgdR7UChUMY1g |
5 | Wo57z24UXLoBdQ7QzxlOqA |
6 | fC+zrF4ga5TCb5Zu36KVrQ |
7 | z+XqHaWmlAsCnIP6NnD3lg |
8 | olm8cPYmLHCeD1jegauiWw |
9 | hJS77tLMd2Ol5SU4dIbbpw |
只有10種分片類型,如果對(duì)應(yīng)的是手機(jī)號(hào)碼字段,很容易根據(jù)統(tǒng)計(jì)每個(gè)數(shù)字的概率分布猜出每個(gè)數(shù)字對(duì)應(yīng)的密文。
可能有多余結(jié)果
可能有兩個(gè)不同分片對(duì)應(yīng)相同密文,這時(shí)候就需要在服務(wù)器再過濾一遍。
參考
實(shí)現(xiàn)
Golang實(shí)現(xiàn)基于AES+CBC+PKCS5Padding的可模糊查詢加密
以上就是數(shù)據(jù)庫(kù)加密字段進(jìn)行模糊查詢?cè)斀獾脑敿?xì)內(nèi)容,更多關(guān)于數(shù)據(jù)庫(kù)加密字段模糊查詢的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
關(guān)于hive表的存儲(chǔ)格式ORC格式的使用詳解
這篇文章主要介紹了關(guān)于hive表的存儲(chǔ)格式ORC格式的使用詳解,Hive?是基于?Hadoop?的一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具,可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張表,并提供類SQL查詢功能,需要的朋友可以參考下2023-07-07Navicat卡住一直在執(zhí)行中的簡(jiǎn)單解決辦法
眾所周知Navicat是我們常用的連接MYSQL工具,非常方便好用,其實(shí)日常中我們也常常會(huì)遇到運(yùn)行時(shí)間很長(zhǎng)甚至幾乎跑不完卡死的情況,這篇文章主要給大家介紹了關(guān)于Navicat卡住一直在執(zhí)行中的簡(jiǎn)單解決辦法,需要的朋友可以參考下2023-11-11ACCESS轉(zhuǎn)SQLSERVER數(shù)據(jù)庫(kù)的注意事項(xiàng)
Access承重量太低,當(dāng)你考慮升級(jí)到SQL Server時(shí),并不只是個(gè)連接字符串需要改變,需要改變的還有很多2007-01-01mongoDB和mysql對(duì)比分析及選擇(詳細(xì)版)
這篇文章主要介紹了mongoDB和mysql對(duì)比分析及選擇(詳細(xì)版),需要的朋友可以參考下2023-06-06海量數(shù)據(jù)庫(kù)的查詢優(yōu)化及分頁(yè)算法方案 2 之 改良SQL語(yǔ)句
海量數(shù)據(jù)庫(kù)的查詢優(yōu)化及分頁(yè)算法方案 2 之 改良SQL語(yǔ)句...2007-03-03由拖庫(kù)攻擊談口令字段的加密策略(數(shù)據(jù)庫(kù)加密)
我不得不慘痛地寫在前面的是,這是一個(gè)安全崩盤的時(shí)代。過去一年,已經(jīng)證實(shí)的遭遇入侵、并導(dǎo)致關(guān)鍵數(shù)據(jù)被竊或者被泄露的公司,包括索尼、世嘉這樣的大型游戲設(shè)備廠商;包括花旗銀行這樣的金融機(jī)構(gòu),也包括了RSA這樣的安全廠商2012-01-01當(dāng)數(shù)據(jù)庫(kù)變慢時(shí)的解決方法
當(dāng)數(shù)據(jù)庫(kù)變慢時(shí),我們應(yīng)如何入手,下面的解決方法。2009-04-04