给用户信息加密的问题探讨

 

场景：

     最近公司出了一个信息泄露的故障，用户的电话信息被大量泄露。公司高度重视这次故障，打算给原来的Account信息做加密。那么我们该如何设计这个加密流程呢？

 

YY的流程：

     可以确定原来的表里面存储了phone字段，如果要加密必须要使用phone_enc，然后删除phone字段。

     1.假设做了db表变更，增加了phone_enc注意这个字段可以解密，那么下一步肯定是fix data， 预发上写段代码半夜将phone加密给phone_enc字段。假设这一步数据fix了。

     2. 代码变更，那么用户更换手机号的时候，你的phone_enc肯定要伴随phone字段做同步。update SQL的时候要做变更。

     3. 代码变更，获取手机getPhone()的时候，使用phone_enc字段进行解密。

     4. 上线

   

     这样问题基本已经解决了，问题来了根据电话号码模糊匹配和全电话查询的时候怎么办呢？  模糊匹配的话任何加密应该都做不到吧，主要考虑全电话查询的情况。全文匹配的话，其实很简单，直接把要搜索的电话加密查询就可以了。

 

     可是如果你的加密算法被泄露了，你怎么办呢？

     还是YY一下能够想到的思路，第一想法更改加密算法，那么所有的加密算法的代码都要改，你代码上线的前提是数据已经fix了，如果你还使用原来的字段的话，但是加密的算法变了，所以老的代码就不兼容了。这时候你肯定只能重新做一次db变更了，再重新整一个字段来存储新的加密算法了。这样搜索的逻辑也要随着加密的算法同步修改，因为你搜索的是加密串。

 

正式的加密流程：

     目前主要是分为三个阶段，我认为还是很合理的，很多类似的操作都可以借鉴下。

  第一阶段：

     表变更：

        a) 增加phone_enc字段，phone_md5_hc字段同时建立索引

    代码变更：

        a) 双写，写入phone的时候，同时写入phone_enc

        b) getPhone 判断phone_enc是否为null，不为null的话则直接从phone_enc解密获得

        c) setPhone的时候记得将phone_enc 设置进去

 

  第二阶段：

        fix data 将所有电话的phone_enc和phone_md5_hc 设置进去

 

  第三阶段：

     表变更：

        a) 去掉表里面phone字段

     代码变更：

        a) 对象里面的字段可以保留，但是SQL里面关于phone的字段要去掉

        b) setPhone的时候将phone_md5_hc 字段设置进去，查询的时候用phone_md5_hc 字段查询。

 

总结几点好处：

     1) 兼容性，可以兼容老的程序，平滑升级

     2) 支持加密算法的切换phone_enc = aes+version+ encrypt，升级加密算法的时候，代码基本不用修改

     3) 加密算法的升级不影响phone的搜索功能

 

总结几点：

     1) 所有依赖Account-API的模块必须升级，setPhone的时候设置phone_enc到达双写的目的，getPhone要对phone_enc进行解密。 

    

     2) 如何避免依赖Account-api的应用全部升级？ 可以把setPhone和getPhone对加密的相关的操作都挪到service里面，这样只要接口不变，依赖的应用就不用升级。