这两年国家越来越重要集体敏感信息的存储、传输与替换。在获取敏感个人信息时，例如，手机号、身份证，都须要主体的被动受权。

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 的商城零碎，那是不是存在这样的可能呢？保险公司须要收集大量集体的信息，而后大数据分析这些集体的状况看看哪个人的钱比拟多，而后给他正当的推送保险，刚好商城做得好不错，挺多人注册，通过商城就能拿到很多集体的手机号之类的。

第三方公司之间数据交换

对于第三方公司零碎之间，进行数据交换。也有可能存在接口调用时，传输敏感的信息。记得前两年，顺丰物流和菜鸟物流产生过这样的事，就是菜鸟物流要求顺丰物流必须上传所有物流信息，起初顺丰间接断了这两个零碎的交互。

对于这两种状况，我认为都须要在显著的中央，给出相干的用户协定，当主体批准受权时，能力进行数据交换。然而这两种状况，简直还没有任何公司依照这种渠道来做的，都是偷偷的就把数据进行了替换。

《2020 最新 Java 根底精讲视频教程和学习路线！》

链接：https://juejin.cn/post/691723…