这是一个创建于 772 天前的主题，其中的信息可能已经有所发展或是发生改变。
已知问题：
1 、加密后如何查询才能击中索引；
2 、用户身份如何验证（手机号、身份证）；
3 、短信怎么发；
1 、加密后如何查询才能击中索引；
2 、用户身份如何验证（手机号、身份证）；
3 、短信怎么发；
 |
1
Pythondr 2022-10-17 17:18:52 +08:00
对称加密
|
 |
2
sun522198558 2022-10-17 17:19:23 +08:00
这不是应该限制查询吗？ 在查询的时候脱敏
|
 |
3
liyunyang OP @sun522198558 #2 这边的等保测试要求落地到数据库里面的时候就要加密
|
 |
4
xiao109 2022-10-17 17:25:09 +08:00
要发短信就选能解密的，要验证你把参数也加密一次然后去数据库搜不就好了
|
 |
5
cccssss 2022-10-17 17:32:38 +08:00  1
每个字符做一个映射，比如 1->a 2->b ，查询 12 时候转换为查询 ab
要加密的数据一共就那么多，自己做一套映射词典就好了 |
 |
6
wolfie 2022-10-17 17:36:35 +08:00 1
同态加密
|
 |
9
jstony 2022-10-17 17:39:06 +08:00 2
如果只是为了过等保，我是说『如果』，那简单，预配置一个 key 做对称加密，这样系统改动最小，历史数据迁移也最简单。如果是为了从系统设计层面做的更优雅，那就需要一个权限系统，读写的时候从系统取 key ，取 key 的时候做用户验证等等。
|
|
10
jstony 2022-10-17 17:40:51 +08:00 6
严格来说，开发系统的人拿到数据库应该是没办法解密的，数据库管理员拿到数据也是没办法解密的，权限系统管理员拿到 key 是没办法读取到数据库的，等等，这些都是系统设计的时候就要规划好的。
|
 |
11
guaguaguaxia1 2022-10-17 17:42:33 +08:00 2
等保就是笑话，不用完全遵守的，查的时候他们基本不看，随随便便就过了
|
 |
12
libook 2022-10-17 17:44:41 +08:00
如果因为业务需要做不到字段级加密就只需要做到数据库和其访问程序的相对安全就可以了，或者你看看有没有支持字段级加密查询的数据库系统。
|
 |
13
zhady009 2022-10-17 17:46:05 +08:00
之前做过缺点是支持加密模糊搜索的字段会很长
|
 |
14
xuelu520 2022-10-17 17:47:55 +08:00 1
如果就是为了应付检查，做个脱敏库吧。
开发和线上用还是正常数据，给检查的是某个表敏感数据处理的库。 |
 |
18
oneisall8955 2022-10-17 18:11:03 +08:00 via Android
搜索下，前几个月内有讨论
|
 |
19
wolfmei 2022-10-17 18:20:06 +08:00
4 级等保吗？ 3 级的也不用做数据库加密
|
 |
20
brader 2022-10-17 18:26:05 +08:00
无需做查询条件的敏感字段，直接找知名的加密算法加密就行了。
需要做查询条件的敏感字段（如手机号、身份证），建议采用映射的方法，自己写一个简单的方法，做一些简单逻辑设计、字符映射，不要想太多安不安全！不要想太多安不安全！不要想太多安不安全！我们没做这个之前，你手机号还是明文存进去的呢，你说是不是呢？何必想那么多为难自己呢 |
 |
21
yuchting 2022-10-17 18:30:17 +08:00
@liyunyang 把 100W 手机号读取出来，放到一个 hashmap 中，占用多少内存？答案是 13MB-15MB 。
|
 |
22
buruoyanyang 2022-10-17 18:34:09 +08:00
等保感觉不是给钱就行吗（手动狗头）
|
 |
23
sxeuosme 2022-10-17 18:40:37 +08:00
模糊搜索手机号？我觉得你应该想下怎么去说服产品经理
|
 |
24
retanoj 2022-10-17 18:47:27 +08:00
信封加密
|
 |
25
Chad0000 2022-10-17 18:48:29 +08:00 2
比脱了裤子放屁还恶心的：
等保 软著 题外话，欢迎补充 |
 |
26
netnr 2022-10-17 18:53:36 +08:00 via Android
MySQL8 内置 AES 加密解密方法，性能不错，硬件支持，处理速度大约 100M/s
|
 |
27
jwenjian 2022-10-17 19:05:41 +08:00 2
参考 mongodb queryable encryption https://www.mongodb.com/docs/upcoming/core/queryable-encryption/
|
 |
29
wu67 2022-10-17 19:11:57 +08:00 46
这贴里好几个奇怪言论...当用户敏感数据被脱裤明文售卖的时候, 你们这些人没一个是无辜的. 希望你们家的数据也中奖.
|
 |
30
Twnysta 2022-10-17 19:11:57 +08:00
你可以数据库加一个哈希字段啊，比如查询的时候就用 hash 字段去比较
|
 |
31
IvanLi127 2022-10-17 19:12:38 +08:00 via Android
如果是为了过等保，直接不加随机数，搞对称加密，不做模糊查询。
|
 |
32
loveyu 2022-10-17 19:20:03 +08:00 via Android
参考抖音的抖店接口文档的方案，感觉满足你的要求
|
 |
33
reducm 2022-10-17 19:59:51 +08:00
权限系统服务，分配权限 key ，业务按照生成对应业务的加密 key 存储，解密需要申请权限获取
|
 |
34
Seulgi 2022-10-17 20:28:27 +08:00
手机号都要加密?
|
 |
35
liprais 2022-10-17 20:51:40 +08:00 via iPhone
数据库存储加密就行
|
 |
38
securityCoding 2022-10-17 21:21:16 +08:00
@Seulgi 手机号当然要加密。。。
|
 |
40
victorc 2022-10-17 21:47:02 +08:00 14
安全合规 /用户隐私保护是 时代发展的需求，越来越重要，国际化的大厂早就大量投入来做这件事情，不要应付了事，你要提高大局观，认真考虑里面的逻辑和实现细节，这是对你职业化的要求，也蕴含了机遇
|
 |
41
tylerdurden 2022-10-17 21:53:02 +08:00 5
查询用 hash ，使用用加密。
cellphone_enc, cellphone_hash, id_enc,id_hash. 如果还要查询归属地的，再加一个 phone_meta 里面只存前 7 位即可。 |
 |
42
wizardyhnr 2022-10-17 21:58:28 +08:00
bitwarden 好像是数据库加密的？
|
 |
43
godall 2022-10-17 22:20:17 +08:00
@tylerdurden 你的方案是对的，其他别人的别瞎扯，等保是很容易过，但是现在软件漏洞很多，被拖库不稀奇，网 xin 办还会不定期做攻防，这种 2 个数据库的傻事别做，查到了吃不了兜着走。至于 key 对称加密稍微好点，必须得分析源码才知道。
|
 |
44
7RTDKSAK 2022-10-17 23:24:37 +08:00
检索加密数据?完全同态加密?好像 INTEL 还是 IBM 有算法了,就不知道有没有成品方案
|
 |
45
lllyglh 2022-10-18 00:08:13 +08:00 via Android
数据库存密文，发短信验证码时 可以让用户输入手机号的一部分 提示用户 如果您输入的手机号正确 会发送验证码
|
 |
46
cp19890714 2022-10-18 00:16:27 +08:00 14
1 、加密后如何查询才能击中索引；
使用 hash 查询。 加密字段只允许精准查询，不允许模糊。 如果一定要模糊，那也是有限制的模糊，提前定好模糊规则，根据模糊规则提前预留相关数据，再进行加密。 2 、用户身份如何验证（手机号、身份证）； 验证后再加密，或者允许解密。 3 、短信怎么发 允许解密。 所以你需要 1. 一个专用于加密解密的服务。 所有加密解密都访问该服务。 可访问数据库的人， 秘钥管理人，加密服务管理人，这三方不能有任何一方有办法获取到所有要素。 2. 调用解密必须有日志。 注意： 1. 不同业务场景对脱敏的要求是不一样的。我们公司的要求是，任何人任何时候都不能看到明文，明文只出现在内存中。 有时候，脱敏并不是要求看不到明文，而是要求 不要让人在看到 1 条明文时，再看到与之相关的其他明文，进而推测出业务信息，例如同时看到姓名与手机号。当然，这与你们公司的具体场景有关。 2. 解密后，明文在内存中，如果被 log ，一直面临风险，所以需要对日志进行审核。 3. 现在有些数据库或者数据库中间件支持字段脱敏。你可以参考他们的方案。 |
 |
47
0o0O0o0O0o 2022-10-18 00:34:57 +08:00 via iPhone 1
|
 |
48
Corua 2022-10-18 00:38:11 +08:00 via Android
目前没有可直接使用的密文搜索技术，只能先启用数据库本身的透明加密，虽然这样在内存中数据还是明文，但密码学可帮不了你做访问控制，做好肾透测试防止被脱库吧。
建议参考 gb/t 39786 做好密码建设，有合规需求的可以来找我 |
|
49
IvanLi127 2022-10-18 01:23:44 +08:00 via Android
@kwh 数据库的数据落盘是明文，所以敏感数据需要加密。
当然数据库也是支持多种层次的落盘加密。数据库的密码防的是数据库连接，不是防拷磁盘数据的。 |
 |
50
nuk 2022-10-18 01:35:21 +08:00
emmm..我是用用户自己输的密码加密的，但是没有索引的需求（用户名可以暴露）
索引的话可以用用户输入的数据加一个公共字符串 hash 后取一些做 key ，然后命中后用每个用户单独的盐加这个输入的字符串解密，如果解密成功输入就是对的。 |
 |
52
Daiwf 2022-10-18 08:39:08 +08:00
@xuanbg 模糊查询不行吧 你这个只能完整输入参数的时候才查得到，如果是完整查询都不用 hash 直接对称加密比密文也是一样
|
 |
53
xuanbg 2022-10-18 08:41:49 +08:00
@Daiwf 模糊当然不行。即使数据库透明加密，模糊查询加密字段的效率也是无法接受的。所以加密数据就没法模糊查询，这几乎就是常识。
|
|
54
xuanbg 2022-10-18 08:49:26 +08:00
当然，变通的模糊查询也是有办法的。譬如姓名前两个字和后两个字这种，无非就是多存两个 hash 值罢了。看上去是模糊查询，其实还是精确查询。但如果是包含 1234 的手机号这种，就真的没招，把产品杀了祭天吧。
|
 |
55
wanggh1021 2022-10-18 09:03:51 +08:00 2
之前在什么地方看到过一篇文章写的就是如何对加密字段进行模糊查询，挺复杂，需要分段进行 hash 存储进行组合，十分耗人力、物力、财力。
如果单存应对的简单方式，建议是分三个字段进行存储： 一个 hash 值，主要进行全匹配查询； 一个半显示值，比如：138****1234 一个全加密值，进行常规的一些简单加密方式，比如移位或者加盐等 还有一种不差钱的，市面上有一种叫做加密机的东西，就是一台服务器，专门用作数据的加密解密操作，价格不菲 |
 |
56
sdwgyzyxy 2022-10-18 09:09:29 +08:00
看来是金融类产品了，不然不会加密手机号、身份证之类的信息。
|
 |
58
stoluoyu 2022-10-18 09:18:32 +08:00
楼里某些人是一点法律不学啊，不知道现在对个人敏感数据的存储要求么，不过等保你也得加密存储。
|
|
60
liyunyang OP @Corua #48
@xuanbg #51 @wanggh1021 #55 @cp19890714 #46 @tylerdurden #41 @victorc #40 感谢大佬们的回复（也非常感谢其它回复的大佬，这里就不一一艾特了），感觉学到了很多东西，泪目 |
 |
62
lakehylia 2022-10-18 09:42:57 +08:00
精确查询，一般就是匹配密文差不多了。如果需要模糊查询，比如在明文入库之前先进行词法分析，语义分析，提取明文里面的几个关键词，加密，然后查询的时候对比命中关键词密文。
|
|
63
Chad0000 2022-10-18 10:46:43 +08:00 via iPhone
op 可以考虑加字段加密保存，同时原文保存在有密码的 sqlite 中，查询先查 sqlite ，也是一种折中方案。
|
 |
64
dog82 2022-10-18 10:57:03 +08:00
翻了这么多评论，也就 26 楼有价值。
我觉得还是要从数据库本身的特性支持下手 |
 |
65
rqxiao 2022-10-18 11:24:56 +08:00
查询用 hash 是什么意思。。
|
 |
66
ShallowAi 2022-10-18 12:36:37 +08:00
将手机号本身以 binary(11)存储，读取再做转换
|
 |
67
Rache1 2022-10-18 12:45:47 +08:00
@rqxiao 存的时候，存密文+密文的 hash 值，查询的时候，把 [原文加密再从密文计算 hash] 作为查询条件，去数据库查。
|
 |
68
julyclyde 2022-10-18 12:50:04 +08:00
如果还想保留搜索能力，那就只能在落盘保存的那一层做手脚了
|
 |
69
yunweier 2022-10-18 13:44:43 +08:00
对称加密 aes 这类算法，保存好密钥
|
 |
70
ishalla 2022-10-18 13:56:54 +08:00
我司是用 aws 的 rds ，kms 加密，然后 key 是每年 rotate
|
 |
71
ren2881971 2022-10-18 13:59:50 +08:00
@Chad0000 密评。
|
|
72
ren2881971 2022-10-18 14:03:41 +08:00
@cp19890714 本帖子目前看到最靠谱的解决方案。
|
|
73
rqxiao 2022-10-18 14:20:50 +08:00
@Rache1 感谢回复，查了下 where cellphone_hash=？ and cellphone_enc=？如果这样精确查的话，可以用哈希列索引体积小的优势，更快的找到记录。虽然 cellphone_hash 有可能会重复，但是利用其索引值较短的优势提高查询效率？
|
 |
75
ltruntu 2022-10-18 15:19:12 +08:00
看了评论 惊呆了，敏感数据加密存储不是最基本的操作么，怪不得国内互联网就是个笑话
|
 |
76
tairan2006 2022-10-18 15:23:51 +08:00
公安部的数据库都泄露了好几次了，个人网站加密做的再好有个鬼用啊…
|
 |
77
kd9yYw2RyhQwAwzn 2022-10-18 15:35:33 +08:00
我们是在 MyCat 上做拦截器进行数据加解密，使用 MySQL 查询出来的数据是加密的 使用 MyCat 查出来的是解密后的数据
|
 |
78
yankebupt 2022-10-18 16:06:39 +08:00
应该是 queryable encryption 问题
不过什么都不懂的小白的话也许会这样干 手机号最后或随机两位加密，只存储前 X 位，最后两位或完整号在加密表 身份证生日最后两位加密，在加密表，根据校验位无法反推身份证号 姓名只储存拼音甚至除了姓氏之外的只有韵母（声母重复率超高），真实姓名在加密表... 总之就是各种自己能用但是脱库之后的数据没法用的恶心人…… |
 |
79
Courstick 2022-10-18 16:15:15 +08:00
我猜是为了隐私合规要求，如果是那 26 楼的建议是符合隐私规范要求的
|
|
80
yankebupt 2022-10-18 16:16:14 +08:00
最后就是恶心人的每人数据用不同密钥加密，登陆后个人密钥写 cookie 里，靠个人 app 的后台刷新 rotate 服务器缓存里的密钥，OLTP 只针对活跃用户和缓存，OLAP 机器高度隔离……官方专门备一台高防服务器专门用来登录时零知识证明……什么的各种恶心人
|
|
81
yankebupt 2022-10-18 16:27:36 +08:00
其实都没用的，一直隐私法隐私法就是为了推一个东西，防脱库最操蛋的办法就是数据只入不出，就是所有大数据量查询都要 token ，责任到每一个实名的刑事责任人。
等官方开始推相应的国标产品，又慢又贵还自带执法部门在线监管的时候，就等着哭吧。 想想看为什么芯片被外国捅刀子……那些性能损失如果轻易就被制程优势掩盖了的话算不算帮人作恶呢? |
 |
82
lis66951735 2022-10-18 16:28:44 +08:00 via iPhone
参考下 shardingSphere encrypt-jdbc
|
 |
83
wangxiaoaer 2022-10-18 16:29:32 +08:00
@tylerdurden #41 能详细说说查询用 hash 的这种吗？比如身份证，如何支持加密存储+模糊查询
|
 |
84
seansong 2022-10-18 16:32:40 +08:00
手机号模糊查询这个事情，建议你去说服产品经理，不要有这样的需求，虽然大部分产品经理都是屁股决定脑袋的人
加密存储和查询脱敏其实是两件事来着，感觉好多人都把这两件事混在一起了，mysql8 支持 TDE ，是完全可以满足等保要求的，脱敏的话，根据前端产品的要求，查询数据做一次拦截处理就好了 TDE 之后，其实你的查询应该是不用做什么太多改变的，顶多就是测试一遍看是否有偶尔的性能影响，做点优化就好了。 当然，这只是很基础的操作，还有很多更深入的内容，可以慢慢探索 |
|
85
wangxiaoaer 2022-10-18 16:39:21 +08:00
@cp19890714 #46
1 加密字段只允许精准查询，比如身份证 1234567890 ，直接对身份证做 hash 存进去，用 hash 替代加密，然后查询的时候把用户参数同样 hash 再去比对？ 2 任何时候都不能看到明文，如果是业务需要，比如不看到手机号怎么联系顾客这种情况如何处理？ |
|
86
yankebupt 2022-10-18 17:08:40 +08:00
翻了一下老新闻，国标防泄漏数据库这东西还真有……
然后……牺牲性能换取安全性，TPS 完全不能看，性能差到连制程优势都拯救不了的地步，刚出来被业界一片骂，骂到不敢出下一代产品…… 匿了匿了…… |
|
87
tylerdurden 2022-10-18 19:19:25 +08:00 1
@wangxiaoaer
模糊查询目前我的理解是按照地理位置模糊 查询，那么不需要保存后四位。 精切查询的话，其实很简单， 假设你的手机号是 12345678 ， 我们在查询的时候 直接 sha(12345678) 得到的值 与数据库中 hash 的值比较即可。 其他的模糊查询方案我暂时不知道还有啥，欢迎讨论 |
 |
88
Kbytes 2022-10-18 19:37:58 +08:00
弄清楚是存储加密还是加密存储。前者让 DB 端实现，不妨碍索引查询，主要防止数据文件或备份被拿走等。
后者需要应用段配合实现，有加密函数存在，也不影响使用索引 |
|
89
cp19890714 2022-10-18 20:31:56 +08:00 1
@wangxiaoaer
1. hash 不能完全代替加密，只能在有限的场景下代替。 hash 可以用于精准查询。 加密后， 还可以解密，得到明文。 2. 使用呼叫中心 用户在页面上发起呼叫后，由后台解密得到明文电话号码，调用呼叫中心。呼叫中心会连接呼叫双方。呼叫中心可自建，或使用三方。对于营销 /客服类型的系统，肯定已经对接了呼叫中心。 如果不想使用呼叫中心，公司可以统一发放安卓手机给员工。系统进行企业定制，隐藏呼叫时的电话号码，隐藏通话记录。 用户在页面上发起呼叫后，由后台解密得到明文电话号码，推送消息到安卓手机，手机自动发起呼叫。 |
|
90
wangxiaoaer 2022-10-18 21:05:39 +08:00
|
 |
91
hefish 2022-10-18 22:52:09 +08:00
等保还查这个？ 我们这边的测评师，linux 命令都不熟。。。。
|
 |
92
janxin 2022-10-18 23:15:22 +08:00 1
不考虑等保的糊弄工作，纯技术考虑有方案的。关键词：blind index
|
 |
93
yurman 2022-10-19 10:26:07 +08:00
自己知道的方法：
一个是查询字段比如手机号分开后加密存放，{field1:xxx,field2:xxxx}模糊查询的时候就只能这样了。对接京东、淘宝的加密数据也是这样。 第二个就是自己搞可逆、有序且长度不会一直递增的算法 |
 |
94
wanguorui123 2022-10-19 10:29:03 +08:00
Mybatis Plus 有个加解密组件挺好用的，模糊查询可以建 Hash(固定长度的关键字) 列精确匹配，并且重写写操作的接口，就可以解决需求了
|
 |
95
lincanbin 2022-10-19 14:16:06 +08:00
应付上级检查的话，随便搞个映射编码就行了。
|
|
96
tylerdurden 2022-10-20 11:53:11 +08:00
v2ex 里面的大神真的挺多的，翻了一下回复又学了很多新知识。
|
Select Language