身份證、手機(jī)號(hào)加密存儲(chǔ)的一些思路
這兩年國(guó)家越來(lái)越重要個(gè)人敏感信息的存儲(chǔ)、傳輸與交換。在獲取敏感個(gè)人信息時(shí)，例如，手機(jī)號(hào)、身份證，都需要主體的主動(dòng)授權(quán)。
0x01：敏感信息泄露有哪些途徑
明文存儲(chǔ)，比如直接把手機(jī)號(hào)、身份證存儲(chǔ)到數(shù)據(jù)庫(kù)。如果數(shù)據(jù)的用戶和密碼被一些不應(yīng)該的人員看到，獲取；就很容易造成泄漏
明文傳輸，比如沒(méi)有對(duì)敏感信息進(jìn)行RSA或者AES加密，就在網(wǎng)絡(luò)中進(jìn)行傳輸
集團(tuán)子公司或者與第三方系統(tǒng)進(jìn)行系統(tǒng)對(duì)接時(shí)，交換敏感數(shù)據(jù)。就是把我方系統(tǒng)的一些敏感信息，沒(méi)經(jīng)授權(quán)就發(fā)生給了第三方公司
0x02：解決敏感信息泄漏的最佳途徑
明文存儲(chǔ)
對(duì)數(shù)據(jù)敏感信息加密后，再進(jìn)行存儲(chǔ)。有這樣一個(gè)場(chǎng)景：有個(gè)用戶表除了其他字段外，還有手機(jī)號(hào) mobile_no 和身份證 identity_card ，這兩個(gè)敏感信息存儲(chǔ)字段。如果直接儲(chǔ)存mobile_no和identity_card明文，就很容易泄漏。
可以對(duì)這兩個(gè)字段進(jìn)行對(duì)稱(chēng)加密或者非對(duì)稱(chēng)加密存儲(chǔ)，分別定義兩個(gè)加密字段 mobile_no_encrypted?和?identity_card_encrypted。但是進(jìn)行加密存儲(chǔ)到數(shù)據(jù)庫(kù)必然導(dǎo)致以下兩個(gè)問(wèn)題：
如何進(jìn)行精準(zhǔn)查詢(xún)匹配
如何進(jìn)行模糊查詢(xún)匹配
如何進(jìn)行精準(zhǔn)查詢(xún)匹配？
為了解決這個(gè)問(wèn)題，還得多加一個(gè)字段，對(duì)于手機(jī)號(hào)添加 mobile_no_sha 字段，身份證添加 identity_card_sha 字段。這兩個(gè)字段分別存儲(chǔ)手機(jī)號(hào)和身份證的SHA-1的散列碼（也可以使用md5算法）。這樣的話，如果精準(zhǔn)查詢(xún)就直接比對(duì)SHA-1散列碼就行。
select?*?from?t_user?where?mobile_no_sha?=?sha-1(mobile_no)
如何進(jìn)行模糊查詢(xún)匹配？
對(duì)應(yīng)模糊查詢(xún)就有點(diǎn)麻煩了?。?！
通常數(shù)據(jù)庫(kù)自帶有加解密函數(shù)，如MySQL的PASSWORD ，MD5，AES_ENCRYPT等等。對(duì)于密碼等信息可以采用單向加密，驗(yàn)證的時(shí)候用同樣的方式加密匹配即可。而對(duì)于需要比對(duì)原內(nèi)容的模糊查詢(xún)，則需要使用雙向加密，也即可以解密，在MySQL可以使用自帶的AES加密。完成存儲(chǔ)加密，讀取解密后，就可以實(shí)現(xiàn)模糊搜索了：
select?*?
from?t_user?
where?AES_DECRYPT(UNHEX(mobile_no_sha?),'key')?
like?'xxx%';
使用函數(shù)還原原始內(nèi)容然后使用like關(guān)鍵字匹配即可實(shí)現(xiàn)模糊搜索。
MySQL使用AES_ENCRYPT()/AES_DECRYPT()加解密的正確姿勢(shì)
http://blog.itpub.net/29773961/viewspace-2142305/
明文傳輸
對(duì)于明文傳輸，首先的摒棄http傳輸協(xié)議，采用https傳輸協(xié)議。如果還想加強(qiáng)安全級(jí)別的話，就自己在定義一種加密方式，對(duì)敏感信息進(jìn)行額外加密。比如采用對(duì)稱(chēng)加密AES或者非對(duì)稱(chēng)加密RSA進(jìn)行自定義加密。
集團(tuán)子公司或者與第三方系統(tǒng)進(jìn)行系統(tǒng)對(duì)接時(shí)，交換敏感數(shù)據(jù)
這種情況比較比較麻煩，分為集團(tuán)內(nèi)部子公司數(shù)據(jù)交換與第三方公司之間數(shù)據(jù)交換
集團(tuán)內(nèi)部子公司數(shù)據(jù)交換
集團(tuán)公司之間是利益共同體，比如存在這樣的場(chǎng)景，A集團(tuán)公司有一個(gè)保險(xiǎn)公司和一個(gè)To?C的商城系統(tǒng)，那是不是存在這樣的可能呢？保險(xiǎn)公司需要收集大量個(gè)人的信息，然后大數(shù)據(jù)分析這些個(gè)人的情況看看哪個(gè)人的錢(qián)比較多，然后給他合理的推送保險(xiǎn)，剛好商城做得好不錯(cuò)，挺多人注冊(cè)，通過(guò)商城就能拿到很多個(gè)人的手機(jī)號(hào)之類(lèi)的。
第三方公司之間數(shù)據(jù)交換
對(duì)于第三方公司系統(tǒng)之間，進(jìn)行數(shù)據(jù)交換。也有可能存在接口調(diào)用時(shí)，傳輸敏感的信息。記得前兩年，順豐物流和菜鳥(niǎo)物流發(fā)生過(guò)這樣的事，就是菜鳥(niǎo)物流要求順豐物流必須上傳所有物流信息，后來(lái)順豐直接斷了這兩個(gè)系統(tǒng)的交互。
對(duì)于這兩種情況，我認(rèn)為都需要在明顯的地方，給出相關(guān)的用戶協(xié)議，當(dāng)主體同意授權(quán)時(shí)，才能進(jìn)行數(shù)據(jù)交換。但是這兩種情況，幾乎還沒(méi)有任何公司按照這種渠道來(lái)做的，都是偷偷的就把數(shù)據(jù)進(jìn)行了交換。
喜歡，在看