共计 1594 个字符,预计需要花费 4 分钟才能阅读完成。
这两年国家越来越重要集体敏感信息的存储、传输与替换。在获取敏感个人信息时,例如,手机号、身份证,都须要主体的被动受权。
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 的商城零碎,那是不是存在这样的可能呢?保险公司须要收集大量集体的信息,而后大数据分析这些集体的状况看看哪个人的钱比拟多,而后给他正当的推送保险,刚好商城做得好不错,挺多人注册,通过商城就能拿到很多集体的手机号之类的。
第三方公司之间数据交换
对于第三方公司零碎之间,进行数据交换。也有可能存在接口调用时,传输敏感的信息。记得前两年,顺丰物流和菜鸟物流产生过这样的事,就是菜鸟物流要求顺丰物流必须上传所有物流信息,起初顺丰间接断了这两个零碎的交互。
对于这两种状况,我认为都须要在显著的中央,给出相干的用户协定,当主体批准受权时,能力进行数据交换。然而这两种状况,简直还没有任何公司依照这种渠道来做的,都是偷偷的就把数据进行了替换。