关于数据库加解密平台讨论及如何保证临时token的安全性?| 总第240周

admin 2024年4月8日10:04:11评论4 views字数 2621阅读8分44秒阅读模式
‍‍

‍‍

关于数据库加解密平台讨论及如何保证临时token的安全性?| 总第240周

0x1本周话题

话题一:大家有用过数据库加解密平台吗?就是为了做数据库中敏感数据加密存储作用的,免了应用系统改造的。感受怎么样?

A1:我们现在想上,但有个问题不好解决就是数据库的下游业务,原始数据加密了,下游的比如大数据平台就玩不转了。

Q:从数据库拿出来到大数据平台的时候不就解密了么?还是说应用数据库和大数据平台合并了呢?

A2:需要单独上一套数据安全平台,做应用访问数据库的代理吧,做数据脱敏。实际情况肯定是通过同步的方式把数据同步过去。

Q:是的,但调研说不是很成熟。不知道有没有群友在深度使用?这个咋解呢?默认同步过去的都是密文。

A3:我了解到的是现在有外资车企已经在用类似系统,应该也有效果吧,应该达不到理想中的状态。用代理的方式还要考虑性能和稳定性,不然到时候业务受影响安全就要背锅了,真的需要大佬们分享一下加密存储都是怎么实现的。

A4:存储加密,各种数据安全评估安全检查都有这一条,每年都要应付。

A5:用过一个厂商方案,实施的时候最大的难点是要梳理数据的流转关系,如果不能一次性做全局加密,只做要保护的库,那就需要在其它环节,库到库,库到应用,ETL工具,数据管道各种流转环节的解密能力也要建设,否则会产生生产事故。因此我们就做了6个库,满足认证要求以后就再也不做了。

Q:全库加密?是部分表中的部分敏感字段吧?加密对业务影响很大,改造成本也很高。

A6:敏感字段加密吧,全部加密也没必要。全库加密的话,访问延迟都要增加不少。部分表中的部分敏感字段加密,业务改造成本也很大。

A7:如果是代理的话其实改造不算大,主要是下游业务比较头疼。

A8:哪种代理方式的加解密可能存在兼容性问题,很多核心业务不太敢用。如果要用代理方式的加解密,用之前要全部业务功能测试一遍,防止SQL兼容性问题带来的业务影响。

A9:同步过去的数据都是加密的,人家没法干活了。

话题二:请教大家一个问题,比如某个系统有较多体验用户需要通过临时token登录系统的场景,如何保证临时token的安全性呢?其实有点像体验用户需要通过临时token访问接口,如何保证token安全性。

Q:token不设置有效期吗?token设置有效期,请求接口的时候,做有效期校验。本来就是临时用户,你的有效期就不应该时间很长吧。

A1:设置啊,但是存在临时token过期那期间会失效的场景。体验用户无法使用。所以如果能让临时token进行校验就好了。

A2:加密和哈希算法: 对于生成的临时token,可以使用加密算法进行加密,或者使用哈希算法进行哈希处理,确保token的安全性。同时,存储在系统中的token也应该进行加密存储,避免明文存储造成的风险。

短期有效性: 设定临时token的有效期,尽量让其有效时间较短,以减少被恶意利用的可能性。一般来说,临时token的有效期应该是较短的,比如15分钟到1小时。 

一次性使用: 设计临时token为一次性使用,即在用户使用后立即失效。这样可以有效减少token被盗用的风险。

限制访问范围: 对于临时token,可以限制其只能访问特定的接口或资源,避免被滥用访问系统中的其他敏感信息。

安全传输: 确保临时token在传输过程中的安全性,可以采用HTTPS等安全传输协议,避免token在传输过程中被窃取或篡改。

安全存储: 如果需要在系统中存储临时token,确保存储在安全的地方,例如数据库中使用加密存储,或者使用专门的安全存储方案。

限制使用次数: 可以限制临时token的使用次数,确保token只能被使用一定次数后自动失效,避免被大量恶意请求滥用。

监控和审计: 对临时token的生成、使用和失效等操作进行监控和审计,及时发现异常行为并进行处理。

A3:临时用户不是一个人,目前是都使用一个token。这不是很好,但是好像也没法区分具体人群。

A4:前段时间遇到一个接口就这样,长期有效的token导致的数据泄露司空见惯。

A5:我理解你的意思是临时token过期了,用户就体验不了了。这就是应该出现的情况呀。

A6:其实感觉有点像硬编码安全了,因为临时token是嵌入在一个体验客户端。体验客户端访问的话是可以正常的。但是存在体验客户端token过期,下载的人员集体不能使用。

Q:为啥不设计个登录换token的功能呢?

A7:首次登录时刷新token 在此基础上给一个有效期。还是得看系统的功能权限和数据的敏感程度。

A8:就因为是体验用户所以不登录。才有临时token,不然就不这么麻烦了。

A9:那就是不用对用户进行验证,你这个token其实是为了防止没有拿到客户端的用户访问API

A10:目前的话 token内置在体验客户端,token过期的话需要重新下客户端。所以时间也不会短。这种的话可以用token和客户端特征进行验证。

Q:还是用硬编码安全的思路去解决?

A11:嗯,但要收集客户端特征,类似微信QQ登录那种环境校验,但是针对你这种场景也只是提高成本,因为你本身业务不具备用户鉴权功能,要不就平衡下体验感和安全,采用邀请码的方式换token。

A12:类似收集客户端特征,在后端加上时间戳类型给他算token,这样能保证每个用户token可以不同,这种有个弊端就是客户换设备了,可能就没法用以前的数据了。

A13:回到原点比较好。不要硬编码在客户端。服务端事先存储好有体验资格的用户手机号。用户通过客户端+手机号短信验证+手机号资格验证+手机信息上传,获得服务端返回的绑定该手机的临时token,10分钟内有效。

A14:就因为是体验用户,才会有这场景。如果有手机号的话就直接登录了。不存在体验客户端了。

Q:那一开始如何确认哪些用户拥有体验资格?比如是不是现场领取体验券,扫上面的二维码?

A15:就存在这么一个场景。比如一个大会上,大家扫描下客户端。当场进行体验。但是这客户端不一定是手机哦。可能是一台AR眼镜。是不方便进行手机号登录的。

A16:可以多维度风控,gps位置不能远离大会2公里,ar眼镜需要连接大会的wifi(绑定名称+mac),token随机且无法暴力猜测,token一次性,token十分钟内有效。稍微复杂的有AR眼镜与手机APP联动,手机扫码获得资格手机连接AR发送资格等,AR眼镜可以前置摄像头的话可以AR自己扫二维码获取资格。

0x2

原文始发于微信公众号(君哥的体历):关于数据库加解密平台讨论及如何保证临时token的安全性?| 总第240周

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年4月8日10:04:11
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   关于数据库加解密平台讨论及如何保证临时token的安全性?| 总第240周http://cn-sec.com/archives/2635963.html

发表评论

匿名网友 填写信息