金融互联网公司如何保证用户私人信息安全？（互联网金融信息安全问题）

金融互联网公司如何保证用户私人信息安全？（互联网金融信息安全问题）

海绵宝宝的烦恼

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

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

快递单号：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 平台，研发无登录生产机器的权限。

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

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

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

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

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

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

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

小结

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

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

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

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

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。