海绵宝宝的烦恼
海绵宝宝非常喜欢网上购物，这让他感觉到被资本腐朽的快乐。
但是有一件事他一直觉得很麻烦，快速上的收件单写满了他的个人信息，撕起来还很麻烦。
快递单号：202202181111
收件人姓名：海绵宝宝
收件人手机：138 8888 8888
收件人地址：太平洋比基尼海滩比奇堡镇贝壳街124号的波萝屋
备注：暗号是天王盖地虎
你有没有遇到过和海绵宝宝一样的烦恼呢？又是怎么解决的呢？
用户信息隐私安全
明天上线的需求
小明今年 26 岁，是一名普普通通的上班族。在某互联网公司做技术开发。
“小明啊，有一个简单的需求。”，产品经理笑着朝小明走来。
“哦，又是简单的需求？”小明看了一下产品，“需求文档写了吗？”
“简单的很，写啥文档呀。”，产品经理接着说，“和上次类似，加一个商品交易记录列表就行。这个需求很急哈，明天能上线吧？”
“类似个锤子，上次的需求不也是做了一周。你把文档写清楚，过一下需求，排期另说。”，小明也不上当。
在详细设计完成之后，小明开始进行开发阶段。
写的还算比较顺利：
public void doTransaction(TransactionDto dto) {
// 输出日志
log.info("进行交易：{}", JSON.toJSON(dto));
// 执行业务处理
// 执行落库
}
TransactionDto 中包含了商品购买者的姓名、手机号、居住地址以及交易的相关信息。
数据库中直接把响应的明文存储，页面直接列表展现。
这个需求很简单，小明想着，就等着测试验证了。
用户信息安全
不过在代码评审的时候，项目经理却提出了一个问题，你的代码保护用户的信息安全了吗？
（1）不应该日志中明文输出用户私人信息
（2）不应该页面中明文展示用户私人信息
（3）不应该在数据库中明文存储用户私人信息
并且以快递单号为例子，他应该如下：
快递单号：202202181111
收件人姓名：海**宝
收件人手机：138 **** 8888
收件人地址：太平洋比基尼海滩比奇堡镇********
备注：暗号是天王盖地虎
这样的好处很明显，就算收件人不去撕掉这张单号，也不会暴露太多用户个人信息。
小明有些不理解，“不让日志输出，那怎么排查问题啊？”
“你可以输出脱敏信息。禁止日志输出，就是避免可以查看日志的人，泄漏用户个人信息。”
“那页面不让明文展示，运营怎么解决日常问题呢？”
“页面可以添加明文显示的按钮，限定对应的权限，并且记录操作日志。”
“数据库不让存储明文，那怎么玩啊？”
“你可以去了解下可逆加密。”，项目经理顿了顿，“重写吧，再给你 2 天时间。”
“好吧”，小明有些失落。
技术实现的调整
日志脱敏脱敏
关于日志脱敏，小明能想到的最直接的方法，就是重载类的 toString() 方然，然后用工具类脱敏敏感信息。
不过他的同事老马给他推荐了一个基于注解的脱敏工具包，用起来还算方便：
-
基于注解的日志脱敏。
-
可以自定义策略实现，策略生效条件。
-
常见的脱敏内置方案。
-
java 深拷贝，且原始对象不用实现任何接口。
-
支持用户自定义注解。
-
支持基于 FastJSON 直接生成脱敏后的 json
数据库可逆加密
为了避免开发者、DBA、恶意攻击者等泄漏数据库信息，数据库中的敏感信息需要进行加密。
比如数据库中的手机号
phone 13066668888
需要调整为如下：
phone_chiper BABABABABABABABBABABABA # 加密之后的密文
phone_mask 130****8888 # 手机号掩码
phone_hash FFFFFFFFFFFFFFFFFFFFFFFF # 手机号哈希
加密算法要求是可逆加密，如 AES/3DES/SM4 等。
掩码可以和上面的脱敏保持一致，主要用户初步的信息确认等。
哈希一般用于精准查询，采用 MD5/SHA 等常见单向哈希即可。
你是一名黑客，你看到了数据库中的掩码+哈希，且知道他们哈希算法是 MD5 哈希，可以获取对应的手机号明文吗？
答案是可以的，所以我们在选择哈希算法实现的时候要考虑这些问题。
如何获取明文，又如何避免这个问题呢？
欢迎小伙伴在评论区留言。
页面的功能设计
产品在敏感信息方面，如果是一个新手，可能会要求明文展示，或者明文导出。
如果你作为安全部门，或者项目经理，一定要把相关的需求给直接的明文的需求砍掉。
产品经理：砍我可以，砍需求不行。
安全部门：数据必须保证安全。
项目经理：我们加一个明文查看的按钮功能，添加权限控制，记录查看日志。不影响业务，又保证数据安全。
前后端开发：……
架构层面
当然，上面的情况，可能只是小明作为一名开发的日常。
那如果是一家公司呢？
如果你作为已加电商/金融公司的技术架构，你会如何保护用户信息的安全隐私呢？
加密机服务
当公司的业务规模达到一定程度时，我们的应用往往就不再是单体，目前主流的是微服务架构。
每一家金融公司，都会有一个加密机服务，用于统一提供上面小明遇到的业务问题。
为不同类型的敏感数据，提供相应的脱敏、可逆加密、哈希服务。
为什么需要
我们把这些实现，写成一个工具类放在代码里不就行了吗？为什么还要搞一个加密机服务呢。
先说比较常见的原因：
（1）提高工作效率
有统一的加密服务和对应的 SDK 之后，可以缩短迭代周期。
研发的技术水平良莠不齐，节约了他们学习+编写的时间。
测试的水平也是类似，同样也可以节约测试验证的时间。
而这，也正是公共服务最大的魅力。
（2）架构之美
如果没有统一的加密服务，每个开发来一套，会导致每个系统的差异比较大。
整体的数据信息就会乱七八糟，当需要数据整合，或者统一的加密升级时，代价会非常高。
（3）家贼难防
如今的公司，都在不断的削弱研发的生产权限。
一家正规的公司，严格按照流程，是不会出现删库跑路的事情的。
代码编写，需要功能测试+代码覆盖率+code review，避免研发植入业务无关代码。
脚本执行，需要业务端发起+项目经理审核+DBA 审核，避免恶意操作。
生产发布变更，需要上线计划+审核，避免恶意操作。
日志查看，主流的都是 ELK 平台，研发无登录生产机器的权限。
生产功能，研发没有使用权限。
这一套组合拳下来，就是让研发作为一个纯纯的工具人，只能做事，像防贼一样防着研发。
一名研发离职，完全知道系统的秘钥+算法+系统弱点，想获取用户隐私信息也不是不可能。
但是如果引入加密机之后呢？
加密机会让公司的架构编写，技术水平没的说，技术安全有保证，相对也比较稳定。
研发作为使用者，不知道秘钥，不知道算法，攻击也就无从谈起。
这又何尝不是一种技术者的悲哀。
小结
每一家公司都有保护用户隐私安全的义务，只可惜现实中很多用户的隐私安全依然无法保证。
对于一个国家，需要推行相应的法律合规。
对于一家公司，需要架构，安全部门，产研测的共同努力。
对于一位用户，我们也要有保护自己信息安全的意识。
希望本文对你有所帮助，如果喜欢，欢迎点赞收藏转发一波。
我是老马，期待与你的下次重逢。