关于数据库加解密平台讨论及如何保证临时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周