海绵宝宝的烦恼
海绵宝宝非常喜欢网上购物,这让他感觉到被资本腐朽的快乐。
但是有一件事他一直觉得很麻烦,快速上的收件单写满了他的个人信息,撕起来还很麻烦。
快递单号: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 平台,研发无登录生产机器的权限。
生产功能,研发没有使用权限。
这一套组合拳下来,就是让研发作为一个纯纯的工具人,只能做事,像防贼一样防着研发。
一名研发离职,完全知道系统的秘钥+算法+系统弱点,想获取用户隐私信息也不是不可能。
但是如果引入加密机之后呢?
加密机会让公司的架构编写,技术水平没的说,技术安全有保证,相对也比较稳定。
研发作为使用者,不知道秘钥,不知道算法,攻击也就无从谈起。
这又何尝不是一种技术者的悲哀。
小结
每一家公司都有保护用户隐私安全的义务,只可惜现实中很多用户的隐私安全依然无法保证。
对于一个国家,需要推行相应的法律合规。
对于一家公司,需要架构,安全部门,产研测的共同努力。
对于一位用户,我们也要有保护自己信息安全的意识。
希望本文对你有所帮助,如果喜欢,欢迎点赞收藏转发一波。
我是老马,期待与你的下次重逢。