需求
数据库里的订单表的用户手机号不能以明文存储,现在是明文 希望以后数据库的密码都要密文存储
真要在业务代码里改,量有点大,bug 也会出现, 不知道有什么好办法
1
zengxs 2020-05-15 15:31:54 +08:00
数据库里面加密,不就是骗一下自己吗,建议 base64 就行
|
2
TypeError 2020-05-15 15:37:58 +08:00
aes,然后单独服务加解密,
查询时加一列 hash 来加索引查 |
3
xuanbg 2020-05-15 15:38:57 +08:00
2 楼方案可行。
|
5
Jrue0011 2020-05-15 15:39:38 +08:00
之前刚好看到 ShardingSphere 有这种场景的解决方案
参考这个 https://shardingsphere.apache.org/document/legacy/4.x/document/cn/features/orchestration/encrypt/#%E5%B7%B2%E4%B8%8A%E7%BA%BF%E4%B8%9A%E5%8A%A1%E6%94%B9%E9%80%A0 缺点是又要引入新的中间件 |
8
leoleoleo 2020-05-15 15:50:33 +08:00 4
数据库加密,是为了应对数据库泄露的情况下,攻击者如果无法获取到解密的算法和密钥,就无法利用泄露的数据。那么多金融机构用加密机,就是为了做这些事。。。。。安全本身就是递进的,跟前几楼说的骗自己有啥关系,用 base64 编码才是真的骗自己。。。。
|
9
stevenkang 2020-05-15 15:50:41 +08:00
订单表存用户 ID 就行了吧,干嘛存手机号呢。
用户敏感信息单独一个表,甚至单独一个系统来维护。日常需求从独立的系统中取出来就是脱敏了的手机号,合规又方便。 |
10
jaylee4869 2020-05-15 18:06:18 +08:00
我现在就在用 Apache Sharding Sphere 做脱敏。还是比较靠谱的,缺点是有 SQL 不能连表查询了。大多数 ORM 和连接池都支持。
|
11
huihuilang 2020-05-15 18:15:46 +08:00 via Android
我有个想法,把其中固定的一位去掉,比如把手机号第三位去掉,变成 10 位数手机号。。。然后去掉的那一位另外保存😂😂
|
12
luozic 2020-05-15 22:42:01 +08:00
gpdr or 国标? 不是有推荐得实践么?
|
13
jwenjian 2020-05-16 08:32:27 +08:00
敏感数据不落盘 落盘要脱敏,这很正常的安全要求。不只是包括数据库,甚至日志文件都不应该有敏感数据原文出现。
密码明文存储 怎么着也说不过去,至少得存 hash 值 另外再加个盐。 业务代码肯定是要改的,安全这事儿 不出问题觉得是累赘 出了问题就麻烦了。 |
14
mostkia 2020-05-16 09:14:30 +08:00
手机号必须与用户数据关联起来才有价值,因为是 13 位的纯数字,乱按也是可以的。如果没有任何用户信息绑定到手机号上一起被盗,其实和打开拨号盘乱按的效果差不多。所以,加密用户敏感信息即可,手机号反倒不是重点,B64 处理一下就可以了,重点是让手机号和用户信息无法对应起来就可以了。
|
15
mostkia 2020-05-16 09:15:20 +08:00
11 位数字,更正
|
16
rqxiao OP @stevenkang 额 这个系统有关用户信息只有手机号存储了,用户基本信息不做存储
|