海绵宝宝的烦恼

海绵宝宝非常喜欢网上购物,这让他感觉到被资本腐朽的快乐。

海绵宝宝

但是有一件事他一直觉得很麻烦,快速上的收件单写满了他的个人信息,撕起来还很麻烦。

快递单号: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 哈希,可以获取对应的手机号明文吗?

hacker

答案是可以的,所以我们在选择哈希算法实现的时候要考虑这些问题

如何获取明文,又如何避免这个问题呢?

欢迎小伙伴在评论区留言。

页面的功能设计

产品在敏感信息方面,如果是一个新手,可能会要求明文展示,或者明文导出。

如果你作为安全部门,或者项目经理,一定要把相关的需求给直接的明文的需求砍掉。

产品经理:砍我可以,砍需求不行。

安全部门:数据必须保证安全。

项目经理:我们加一个明文查看的按钮功能,添加权限控制,记录查看日志。不影响业务,又保证数据安全。

前后端开发:……

架构层面

当然,上面的情况,可能只是小明作为一名开发的日常。

那如果是一家公司呢?

如果你作为已加电商/金融公司的技术架构,你会如何保护用户信息的安全隐私呢?

加密机服务

当公司的业务规模达到一定程度时,我们的应用往往就不再是单体,目前主流的是微服务架构。

每一家金融公司,都会有一个加密机服务,用于统一提供上面小明遇到的业务问题。

为不同类型的敏感数据,提供相应的脱敏、可逆加密、哈希服务。

为什么需要

我们把这些实现,写成一个工具类放在代码里不就行了吗?为什么还要搞一个加密机服务呢。

先说比较常见的原因:

(1)提高工作效率

有统一的加密服务和对应的 SDK 之后,可以缩短迭代周期。

研发的技术水平良莠不齐,节约了他们学习+编写的时间。

测试的水平也是类似,同样也可以节约测试验证的时间。

而这,也正是公共服务最大的魅力。

(2)架构之美

如果没有统一的加密服务,每个开发来一套,会导致每个系统的差异比较大。

整体的数据信息就会乱七八糟,当需要数据整合,或者统一的加密升级时,代价会非常高。

(3)家贼难防

如今的公司,都在不断的削弱研发的生产权限

一家正规的公司,严格按照流程,是不会出现删库跑路的事情的。

删库跑路

代码编写,需要功能测试+代码覆盖率+code review,避免研发植入业务无关代码。

脚本执行,需要业务端发起+项目经理审核+DBA 审核,避免恶意操作。

生产发布变更,需要上线计划+审核,避免恶意操作。

日志查看,主流的都是 ELK 平台,研发无登录生产机器的权限。

生产功能,研发没有使用权限。

这一套组合拳下来,就是让研发作为一个纯纯的工具人,只能做事,像防贼一样防着研发。

一名研发离职,完全知道系统的秘钥+算法+系统弱点,想获取用户隐私信息也不是不可能。

但是如果引入加密机之后呢?

加密机会让公司的架构编写,技术水平没的说,技术安全有保证,相对也比较稳定。

研发作为使用者,不知道秘钥,不知道算法,攻击也就无从谈起。

这又何尝不是一种技术者的悲哀。

悲哀

小结

每一家公司都有保护用户隐私安全的义务,只可惜现实中很多用户的隐私安全依然无法保证。

对于一个国家,需要推行相应的法律合规。

对于一家公司,需要架构,安全部门,产研测的共同努力。

对于一位用户,我们也要有保护自己信息安全的意识。

希望本文对你有所帮助,如果喜欢,欢迎点赞收藏转发一波。

我是老马,期待与你的下次重逢。

参考资料