敏感数据处理

  |   24 评论   |   6,511 浏览

背景

大多数应用或多或少都会涉及到敏感数据处理,比如用户的手机号、身份证号,甚至银行卡账号。作为应用的开发者,如何 安全地 维护这些敏感数据呢?

这里讨论的安全不是指服务器如何保护,而是在数据库层面做敏感数据的分离:

  • 业务库中不保存敏感数据,只保存混淆过的数据,比如电话字段保存的是 133**9961,在数据层面就进行脱敏
  • 敏感数据统一保存在另一个库中,有应用调用一个服务来建立原值和混淆值的映射关系
  • 业务库中因为保存的是脱敏过的数据,通过只读复制镜像可以很方便地提供给其他服务使用,比如 OLAP
  • 除了技术开发上方便,运维上也方便了很多,降低了敏感数据被暴露到外部的可能性

技术设计

提供服务接口给应用存取敏感数据,本质上是一个 KV 存取服务。

1462956107181

一些细节:

  • 表 protyle 的 domain 字段用于标识该记录的作用域,在一个作用域上相同的值要保证唯一
  • 表 protyle 的 hash 字段值是 SHA-512(domain/value) 的结果,用于唯一性校验

大家有相关经验么?欢迎讨论~

---- EOF ----
点击加入开源技术 Q 群 242561391,让学习和分享成为一种习惯!

评论

  • bozong 回复»

    @88250 有手机端吗?

  • 88250 回复»

    @zjhch123 那密文你存哪?

  • zjhch123 回复»

    我是直接DES加密存的…每个用户都有独一无二的密文,然后根据这个密文加密

  • pianopaper 回复»

    @88250 这里有几点个人体会分享一下,原公司站点为windows server 2008,所用容器为tomcat,改版的时候,考虑了一下到底是不是要换成linux下的nginx还是用张宴写的集成式的简单容器做部署,考虑来考虑去,全部人对linux这块也就只会敲cd mv等等命令,就不用说find文件等稍微复杂的操作了,公司的培训体系是,文档写完,图文并茂,不管会不会linux,只要按照图文讲的进行操作,即使不知道这一步做的意思是什么,也能正常完成整个操作(所谓的常规运维,也就是点点鼠标),所以最终决定还是用张宴的集成式容器来做了部署,写个VB的UI把所有备份恢复的操作一并处理完,虽然个人觉得不是很对劲,但是这能满足在现状上大部分人的操作,一些东西如果是不得不做的话,需要有人来牵头做(谁做谁负责,做好咱follow),成本,代价,现状等等,不是一个人能考虑得了的

  • 88250 回复»

    @pianopaper 嗯,当然,而且运维上面也要非常细致和小心

  • pianopaper 回复»

    @88250 这些要有人来控开发成本和风险咯,就完全不是一个人的事情咯

  • 88250 回复»

    @pianopaper 为了安全,值得去做,或者说不得不做....

  • pianopaper 回复»

    @88250 运维的难度就在,产品中间组件增多,会有升级,那么,升级要遵循什么规则?部署呢?多机情况呢?

  • pianopaper 回复»

    @88250 这确实会增加运维难度,如果这是一个产品,中间层组件的写作需要遵循某种规则,举个例子,交易系统里的业务逻辑全部都是用存储过程来做的,UI就仅仅做信号传递,比如,UI点查询按钮,那么就传递一个532232到中间件,中间件会根据这个信号,来做到db的连接,同时传递p532232到db去做存储过程的处理,为什么要做532232到p532232的转换呢?因为存储过程里的命名也是有规则的,比如db有一个存储过程叫做p532232用来做查询操作的,处理得到的结果通过某种数据结构,经过中间层,再回传到UI,同时,db,中间层,UI都留下操作日志

  • mymoshou 回复»

    其实..在数据泄露的时候已经..

  • 88250 回复»

    @pianopaper 嗯,该方案就是这个思路

  • pianopaper 回复»

    @88250 其实个人认为安全没有绝对的,只是在被获取的难度是否增加到一定级别,也就是被泄露的可能性是如何的,如若因为这些数据非常敏感,那放内网里进行处理是一个不错的办法(金士达的做法),所有的处理都要通过一个中间层(单独写进程来处理),所有数据均和其进行通讯

  • wgh 回复»

    @88250 我感觉是一样的,只要别人解不了密就算获取到数据也没用!

  • Hassan 回复»

    表太多了。直接加密挺好的

  • 88250 回复»

    @wgh @pianopaper

    • 安全和方便应该是矛盾的
    • 这个方案的出发点是这些数据真的非常敏感,是一个公司最核心的资产
  • wgh 回复»

    个人觉得加密解密这种方式最方便也最简单

  • pianopaper 回复»

    @wgh 咱觉得也是挺麻烦的

  • wgh 回复»

    我感觉文章里说的那种方式更麻烦

  • zonghua 回复»

    @Vanessa 哈,那么邮箱也是不能明文了吧

  • pianopaper 回复»

    @88250 加解密复用也仅仅是加解密function而已呀?遵循使用规则就是拿出function解密一下,放进去function加密一下呀

  • 88250 回复»

    @sweat89 @wgh

    • 把鸡蛋都放一个篮子里
    • 业务来解决这个问题的话不方便复用
  • sweat89 回复»

    弄个算法,加密存DB,业务层解密进行业务处理。有啥问题

  • wgh 回复»

    我们是直接全加密保存

  • Vanessa 回复»

    @yangyujiao 这个是业主电话,泄露出去,公司就垮掉了

  • yangyujiao 回复»

    我们就是明目张胆的保存了电话号码···

发表评论

validate