安策数据加密保护-如何对加密数据进行模糊查询？

加密数据对模糊查询不是很友好。本文将讨论加密数据模糊查询的实现思路。

      为了数据安全，我们经常在开发过程中对重要数据进行加密和存储。常见的有密码、手机号码、电话号码、详细地址、银行卡号码、信用卡验证码等信息。这些信息对加密和解密有不同的要求。例如，我们需要加密和存储密码，这通常是不可逆转的hash算法，慢hash算法可以避免暴力破解（典型的时间安全），我们不需要解密或模糊搜索，直接使用密文完全匹配，但手机号码不能这样做，因为手机号码我们想查看原始信息，手机号码也需要支持模糊搜索，所以今天我们将支持模糊查询的可逆加解密数据支持。

我在网上搜索了很多关于加密后模糊查询的帖子。顺便说一下，我整理了实现方法。不得不说，很多都是不靠谱的做法，甚至还有一些沙雕做法。接下来，我们将实现这些做法的思路和优缺点。

如何模糊加密数据查询？

我整理了三种加密数据模糊查询方法，如下：

沙雕练习(不动脑思考直男的法，只要实现功能从不深入思考问题）

常规做法(思考查询性能问题，也会使用一些存储空间换性能等)

超神实践(从算法层面思考高端实践)

       让我们逐一谈谈这三种实现方法的思路和优缺点。

首先，让我们来看看沙雕的做法。

沙雕做法:将所有数据加载到内存中进行解密，然后通过程序算法模糊匹配。

将密文数据映射为明文映射表，俗称明文映射表，tag表，然后模糊查询tag关联密文数据，面试宝典：https://www.yoodb.com

沙雕一

让我们来看看第一种方法，把所有的数据加载到内存中解密。如果数据量小，可以用这种方法来做。这既简单又实惠。如果数据量大，那就是灾难。让我们粗略计算一下。

一个英文字母(不分大小写)占用一个字节的空间，一个汉字占用两个字节的空间，使用英文字母(不分大小写)DES例如，13800138000加密串HE9T75xNx6c5yLmS5l4r6Q==占24个字节。

轻则上百兆，重则上千兆，这样每分钟都能完成应用程序Outofmemory，这样做，如果数据少了几百、几千、几万条，就完全可以这样做，但是数据量大的时候强烈不推荐。

沙雕二

让我们来看看第二种方法，将密文数据映射到一个明文映射表中，然后模糊查询映射表关联密文数据，what！！！那我们为什么要加密数据呢，直接不加密不是更好！

既然我们必须对数据加密有安全要求，那么添加一个明确的映射表就违反了安全要求。这既不安全也不方便。我们脱下裤子放在上面x，多余，强而不推荐。

常规做法

接下来我们来看看常规的做法，也是最广泛使用的方法些方法和满足的数据安全性，以及友好的查询。

在数据库中实现加密算法函数，在模糊查询中使用decode(key)like'%partial%'

对密文数据进行分词组合，分词组合的结果集分别加密，然后存储到扩展列中，查询时通过查询进行分词组合，keylike'%partial%'

常规一

在数据库中实现与程序一致的加解密算法，修改模糊查询条件，在模糊查找前使用数据库加解密函数。这样做的优点是实现成本低，开发使用成本低。只需稍微修改一下以前的模糊查找即可实现，但缺点也很明显。这不能用数据库的索引来优化查询，甚至有些数据库可能无法保证与程序一致的加解密算法。

如果查询性能要求不是特别高，数据安全要求一般，可以使用常见的加解密算法，如AES，DES这也是一个不错的选择。

如果公司有自己的算法实现，没有提供多终端算法实现，要么找一个算法好的人研究多终端实现，要么放弃使用这种方法。

常规二

对密文数据进行分词组合，分词组合的结果集分别加密，然后存储到扩展列中，查询时通过查询进行分词组合，keylike'%partial这是一种更划算的实现方法，我们先来分析一下它的实现思路。

首先，对字符的固定长度进行分组，将一个字段分成多个字段。例如，根据四个英文字符（半角）和两个中文字符（全角），例如：

ningyu1使用四个字符作为一组加密，第一组ning，第二组ingy，第三组ngyu，第四组gyu1…依次类推。

需要检索包含检索条件的四个字符的所有数据，如：ingy，加密字符后通过keylike“%partial%”查库。

我们都知道加密后长度会增加。增长的长度存储是我们需要花费的额外成本。典型的使用成本换取速度。密文的增长范围因算法而异DES例如，13800138000加密前占11个字节，加密后的串串HE9T75xNx6c5yLmS5l4r6Q==占24字节，增长2.18倍，所以一个好的算法是多么重要，可以为公司节省很多成本，但算法工程师的工资不低，所以我不知道是节省成本还是增加成本，哈哈哈…自己算吧。

      回到主题，虽然这种方法可以实现加密数据的模糊查询，但对模糊查询的字符长度有要求。以我上面的例子为例，模糊查询字符的原始长度必须大于或等于4个英文/数字或2个汉字。不建议支持短长度，因为分词组合会增加，导致存储成本增加，但安全性降低。

版权声明: SafePloy安策利用网络资源获取的信息安全资料加上公司技术人员的理解整理产出的技术交 流文档，如有版权意见，请及时告知安策公司，我们将及时查证纠正错误，谢谢支持。有问题请及时电邮 market@ SafePloy.com

来源：安策信息、SafePloy安策数据治理 | 关键词：数据加密  敏感数据加密  数据治理  数据安全框架   | 受欢迎指数（）