共计 2794 个字符，预计需要花费 7 分钟才能阅读完成。
海绵宝宝的懊恼
海绵宝宝十分喜爱网上购物，这让他感觉到被资本腐烂的高兴。
然而有一件事他始终感觉很麻烦，疾速上的收件单写满了他的个人信息，撕起来还很麻烦。
快递单号：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() 方然，而后用工具类脱敏敏感信息。
不过他的共事老马给他举荐了一个基于注解的脱敏工具包，用起来还算不便：
https://github.com/houbb/sensitive
- 基于注解的日志脱敏。
- 能够自定义策略实现，策略失效条件。
- 常见的脱敏内置计划。
- 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 平台，研发无登录生产机器的权限。
生产性能，研发没有应用权限。
这一套组合拳下来，就是让研发作为一个纯纯的工具人，只能做事，像防贼一样防着研发。
一名研发到职，齐全晓得零碎的秘钥 + 算法 + 零碎弱点，想获取用户隐衷信息也不是不可能。
然而如果引入加密机之后呢？
加密机会让公司的架构编写，技术水平没的说，技术平安有保障，绝对也比较稳定。
研发作为使用者，不晓得秘钥，不晓得算法，攻打也就无从谈起。
这又何尝不是一种技术者的悲痛。
小结
每一家公司都有爱护用户隐衷平安的任务，只惋惜事实中很多用户的隐衷平安仍然无奈保障。
对于一个国家，须要推广相应的法律合规。
对于一家公司，须要架构，安全部门，产研测的共同努力。
对于一位用户，咱们也要有爱护本人信息安全的意识。
心愿本文对你有所帮忙，如果喜爱，欢送点赞珍藏转发一波。
我是老马，期待与你的下次重逢。
