公司要求用户敏感数据加密存储，大伙有什么建议吗？

对称加密

这不是应该限制查询吗？ 在查询的时候脱敏

@sun522198558 #2 这边的等保测试要求落地到数据库里面的时候就要加密

要发短信就选能解密的，要验证你把参数也加密一次然后去数据库搜不就好了

每个字符做一个映射，比如 1->a 2->b ，查询 12 时候转换为查询 ab
要加密的数据一共就那么多，自己做一套映射词典就好了

同态加密

@Pythondr #1 对称加密后如何模糊搜索手机号？

@cccssss #5 这样的加密力度好像很低，不过好像可行，本来就是应付上级检查的

如果只是为了过等保，我是说『如果』，那简单，预配置一个 key 做对称加密，这样系统改动最小，历史数据迁移也最简单。如果是为了从系统设计层面做的更优雅，那就需要一个权限系统，读写的时候从系统取 key ，取 key 的时候做用户验证等等。

严格来说，开发系统的人拿到数据库应该是没办法解密的，数据库管理员拿到数据也是没办法解密的，权限系统管理员拿到 key 是没办法读取到数据库的，等等，这些都是系统设计的时候就要规划好的。

等保就是笑话，不用完全遵守的，查的时候他们基本不看，随随便便就过了

如果因为业务需要做不到字段级加密就只需要做到数据库和其访问程序的相对安全就可以了，或者你看看有没有支持字段级加密查询的数据库系统。

之前做过缺点是支持加密模糊搜索的字段会很长

如果就是为了应付检查，做个脱敏库吧。
开发和线上用还是正常数据，给检查的是某个表敏感数据处理的库。

@xuelu520 #14 哈哈，很机智

@liyunyang #7 手机号模糊查询，是在什么应用场景呢。一般手机号都是作为唯一约束存在，不太可能需要模糊查询。

@liyunyang 如果觉着这种方案没有对称加密力度低，那就每个字符都对称加密呗。这样力度大

搜索下，前几个月内有讨论

4 级等保吗？ 3 级的也不用做数据库加密

无需做查询条件的敏感字段，直接找知名的加密算法加密就行了。
需要做查询条件的敏感字段（如手机号、身份证），建议采用映射的方法，自己写一个简单的方法，做一些简单逻辑设计、字符映射，不要想太多安不安全！不要想太多安不安全！不要想太多安不安全！我们没做这个之前，你手机号还是明文存进去的呢，你说是不是呢？何必想那么多为难自己呢

@liyunyang 把 100W 手机号读取出来，放到一个 hashmap 中，占用多少内存？答案是 13MB-15MB 。

等保感觉不是给钱就行吗（手动狗头）

模糊搜索手机号？我觉得你应该想下怎么去说服产品经理

信封加密

比脱了裤子放屁还恶心的：

等保
软著

题外话，欢迎补充

MySQL8 内置 AES 加密解密方法，性能不错，硬件支持，处理速度大约 100M/s

参考 mongodb queryable encryption https://www.mongodb.com/docs/upcoming/core/queryable-encryption/

@Chad0000 场所码

这贴里好几个奇怪言论...当用户敏感数据被脱裤明文售卖的时候, 你们这些人没一个是无辜的. 希望你们家的数据也中奖.

你可以数据库加一个哈希字段啊，比如查询的时候就用 hash 字段去比较

如果是为了过等保，直接不加随机数，搞对称加密，不做模糊查询。

参考抖音的抖店接口文档的方案，感觉满足你的要求

权限系统服务，分配权限 key ，业务按照生成对应业务的加密 key 存储，解密需要申请权限获取

手机号都要加密?

数据库存储加密就行

@wu67 数据库有密码怎么会被脱裤呢？而且数据库的密码不就相当于加密了？？？

@kwh 电脑有防火墙为什么还会中毒呢? 而且 Windows Defender 不就相当于杀毒软件了???

@Seulgi 手机号当然要加密。。。

@wu67 所以得加两个 Windows Defender ？？？

安全合规 /用户隐私保护是 时代发展的需求，越来越重要，国际化的大厂早就大量投入来做这件事情，不要应付了事，你要提高大局观，认真考虑里面的逻辑和实现细节，这是对你职业化的要求，也蕴含了机遇

查询用 hash ，使用用加密。
cellphone_enc, cellphone_hash, id_enc,id_hash. 如果还要查询归属地的，再加一个 phone_meta 里面只存前 7 位即可。

bitwarden 好像是数据库加密的？

@tylerdurden 你的方案是对的，其他别人的别瞎扯，等保是很容易过，但是现在软件漏洞很多，被拖库不稀奇，网 xin 办还会不定期做攻防，这种 2 个数据库的傻事别做，查到了吃不了兜着走。至于 key 对称加密稍微好点，必须得分析源码才知道。

检索加密数据?完全同态加密?好像 INTEL 还是 IBM 有算法了,就不知道有没有成品方案

数据库存密文，发短信验证码时 可以让用户输入手机号的一部分 提示用户 如果您输入的手机号正确 会发送验证码

1 、加密后如何查询才能击中索引；
使用 hash 查询。
加密字段只允许精准查询，不允许模糊。
如果一定要模糊，那也是有限制的模糊，提前定好模糊规则，根据模糊规则提前预留相关数据，再进行加密。
2 、用户身份如何验证（手机号、身份证）；
验证后再加密，或者允许解密。
3 、短信怎么发
允许解密。

所以你需要
1. 一个专用于加密解密的服务。
所有加密解密都访问该服务。
可访问数据库的人， 秘钥管理人，加密服务管理人，这三方不能有任何一方有办法获取到所有要素。
2. 调用解密必须有日志。

注意：
1. 不同业务场景对脱敏的要求是不一样的。我们公司的要求是，任何人任何时候都不能看到明文，明文只出现在内存中。
有时候，脱敏并不是要求看不到明文，而是要求 不要让人在看到 1 条明文时，再看到与之相关的其他明文，进而推测出业务信息，例如同时看到姓名与手机号。当然，这与你们公司的具体场景有关。
2. 解密后，明文在内存中，如果被 log ，一直面临风险，所以需要对日志进行审核。
3. 现在有些数据库或者数据库中间件支持字段脱敏。你可以参考他们的方案。

目前没有可直接使用的密文搜索技术，只能先启用数据库本身的透明加密，虽然这样在内存中数据还是明文，但密码学可帮不了你做访问控制，做好肾透测试防止被脱库吧。

建议参考 gb/t 39786 做好密码建设，有合规需求的可以来找我

@kwh 数据库的数据落盘是明文，所以敏感数据需要加密。
当然数据库也是支持多种层次的落盘加密。数据库的密码防的是数据库连接，不是防拷磁盘数据的。

emmm..我是用用户自己输的密码加密的，但是没有索引的需求（用户名可以暴露）
索引的话可以用用户输入的数据加一个公共字符串 hash 后取一些做 key ，然后命中后用每个用户单独的盐加这个输入的字符串解密，如果解密成功输入就是对的。

@liyunyang 数据加密前生成 hash 值，查询的时候用输入条件的 hash 值作为条件查询就行。

@xuanbg 模糊查询不行吧 你这个只能完整输入参数的时候才查得到，如果是完整查询都不用 hash 直接对称加密比密文也是一样

@Daiwf 模糊当然不行。即使数据库透明加密，模糊查询加密字段的效率也是无法接受的。所以加密数据就没法模糊查询，这几乎就是常识。

当然，变通的模糊查询也是有办法的。譬如姓名前两个字和后两个字这种，无非就是多存两个 hash 值罢了。看上去是模糊查询，其实还是精确查询。但如果是包含 1234 的手机号这种，就真的没招，把产品杀了祭天吧。

之前在什么地方看到过一篇文章写的就是如何对加密字段进行模糊查询，挺复杂，需要分段进行 hash 存储进行组合，十分耗人力、物力、财力。
如果单存应对的简单方式，建议是分三个字段进行存储：
一个 hash 值，主要进行全匹配查询；
一个半显示值，比如：138****1234
一个全加密值，进行常规的一些简单加密方式，比如移位或者加盐等

还有一种不差钱的，市面上有一种叫做加密机的东西，就是一台服务器，专门用作数据的加密解密操作，价格不菲

看来是金融类产品了，不然不会加密手机号、身份证之类的信息。

@wu67 问题是等保就是瞎几把查一下啊。

楼里某些人是一点法律不学啊，不知道现在对个人敏感数据的存储要求么，不过等保你也得加密存储。

@kwh 你意思被脱库的数据库都是没有设置密码的？

@Corua #48
@xuanbg #51
@wanggh1021 #55
@cp19890714 #46
@tylerdurden #41
@victorc #40
感谢大佬们的回复（也非常感谢其它回复的大佬，这里就不一一艾特了），感觉学到了很多东西，泪目

@xuanbg 直接暴力拼接 1,12,123,1234 手机号这种还行，收件人地址这种会特别长

精确查询，一般就是匹配密文差不多了。如果需要模糊查询，比如在明文入库之前先进行词法分析，语义分析，提取明文里面的几个关键词，加密，然后查询的时候对比命中关键词密文。

op 可以考虑加字段加密保存，同时原文保存在有密码的 sqlite 中，查询先查 sqlite ，也是一种折中方案。

翻了这么多评论，也就 26 楼有价值。
我觉得还是要从数据库本身的特性支持下手

查询用 hash 是什么意思。。

将手机号本身以 binary(11)存储，读取再做转换

@rqxiao 存的时候，存密文+密文的 hash 值，查询的时候，把 [原文加密再从密文计算 hash] 作为查询条件，去数据库查。

如果还想保留搜索能力，那就只能在落盘保存的那一层做手脚了

对称加密 aes 这类算法，保存好密钥

我司是用 aws 的 rds ，kms 加密，然后 key 是每年 rotate

@Chad0000 密评。

@cp19890714 本帖子目前看到最靠谱的解决方案。

@Rache1 感谢回复，查了下 where cellphone_hash=？ and cellphone_enc=？如果这样精确查的话，可以用哈希列索引体积小的优势，更快的找到记录。虽然 cellphone_hash 有可能会重复，但是利用其索引值较短的优势提高查询效率？

@Chad0000 备案，尤其是要求备案号要固定链接到 miit 首页……实在搞不懂

看了评论 惊呆了，敏感数据加密存储不是最基本的操作么，怪不得国内互联网就是个笑话

公安部的数据库都泄露了好几次了，个人网站加密做的再好有个鬼用啊…

我们是在 MyCat 上做拦截器进行数据加解密，使用 MySQL 查询出来的数据是加密的 使用 MyCat 查出来的是解密后的数据

应该是 queryable encryption 问题
不过什么都不懂的小白的话也许会这样干

手机号最后或随机两位加密，只存储前 X 位，最后两位或完整号在加密表
身份证生日最后两位加密，在加密表，根据校验位无法反推身份证号
姓名只储存拼音甚至除了姓氏之外的只有韵母（声母重复率超高），真实姓名在加密表...

总之就是各种自己能用但是脱库之后的数据没法用的恶心人……

我猜是为了隐私合规要求，如果是那 26 楼的建议是符合隐私规范要求的

最后就是恶心人的每人数据用不同密钥加密，登陆后个人密钥写 cookie 里，靠个人 app 的后台刷新 rotate 服务器缓存里的密钥，OLTP 只针对活跃用户和缓存，OLAP 机器高度隔离……官方专门备一台高防服务器专门用来登录时零知识证明……什么的各种恶心人

其实都没用的，一直隐私法隐私法就是为了推一个东西，防脱库最操蛋的办法就是数据只入不出，就是所有大数据量查询都要 token ，责任到每一个实名的刑事责任人。
等官方开始推相应的国标产品，又慢又贵还自带执法部门在线监管的时候，就等着哭吧。

想想看为什么芯片被外国捅刀子……那些性能损失如果轻易就被制程优势掩盖了的话算不算帮人作恶呢?

参考下 shardingSphere encrypt-jdbc

@tylerdurden #41 能详细说说查询用 hash 的这种吗？比如身份证，如何支持加密存储+模糊查询

手机号模糊查询这个事情，建议你去说服产品经理，不要有这样的需求，虽然大部分产品经理都是屁股决定脑袋的人

加密存储和查询脱敏其实是两件事来着，感觉好多人都把这两件事混在一起了，mysql8 支持 TDE ，是完全可以满足等保要求的，脱敏的话，根据前端产品的要求，查询数据做一次拦截处理就好了

TDE 之后，其实你的查询应该是不用做什么太多改变的，顶多就是测试一遍看是否有偶尔的性能影响，做点优化就好了。

当然，这只是很基础的操作，还有很多更深入的内容，可以慢慢探索

@cp19890714 #46

1 加密字段只允许精准查询，比如身份证 1234567890 ，直接对身份证做 hash 存进去，用 hash 替代加密，然后查询的时候把用户参数同样 hash 再去比对？

2 任何时候都不能看到明文，如果是业务需要，比如不看到手机号怎么联系顾客这种情况如何处理？

翻了一下老新闻，国标防泄漏数据库这东西还真有……
然后……牺牲性能换取安全性，TPS 完全不能看，性能差到连制程优势都拯救不了的地步，刚出来被业界一片骂，骂到不敢出下一代产品……
匿了匿了……

@wangxiaoaer
模糊查询目前我的理解是按照地理位置模糊 查询，那么不需要保存后四位。
精切查询的话，其实很简单， 假设你的手机号是 12345678 ， 我们在查询的时候 直接 sha(12345678) 得到的值 与数据库中 hash 的值比较即可。
其他的模糊查询方案我暂时不知道还有啥，欢迎讨论

弄清楚是存储加密还是加密存储。前者让 DB 端实现，不妨碍索引查询，主要防止数据文件或备份被拿走等。
后者需要应用段配合实现，有加密函数存在，也不影响使用索引

@wangxiaoaer
1. hash 不能完全代替加密，只能在有限的场景下代替。
hash 可以用于精准查询。
加密后， 还可以解密，得到明文。

2. 使用呼叫中心
用户在页面上发起呼叫后，由后台解密得到明文电话号码，调用呼叫中心。呼叫中心会连接呼叫双方。呼叫中心可自建，或使用三方。对于营销 /客服类型的系统，肯定已经对接了呼叫中心。
如果不想使用呼叫中心，公司可以统一发放安卓手机给员工。系统进行企业定制，隐藏呼叫时的电话号码，隐藏通话记录。
用户在页面上发起呼叫后，由后台解密得到明文电话号码，推送消息到安卓手机，手机自动发起呼叫。

@cp19890714 #89

1 也就说在为了实现查询不得已暂时用 hash 替代加密吧。

2 呼叫中心是很理想的，这里也仅仅是举个例子。有些情况就是要在前端页面看到原始数据……

等保还查这个？ 我们这边的测评师，linux 命令都不熟。。。。

不考虑等保的糊弄工作，纯技术考虑有方案的。关键词：blind index

自己知道的方法：
一个是查询字段比如手机号分开后加密存放，{field1:xxx,field2:xxxx}模糊查询的时候就只能这样了。对接京东、淘宝的加密数据也是这样。
第二个就是自己搞可逆、有序且长度不会一直递增的算法

Mybatis Plus 有个加解密组件挺好用的，模糊查询可以建 Hash(固定长度的关键字) 列精确匹配，并且重写写操作的接口，就可以解决需求了

应付上级检查的话，随便搞个映射编码就行了。

v2ex 里面的大神真的挺多的，翻了一下回复又学了很多新知识。