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