1、场景需求
普通的加密模式下,整段内容会被整体加密,密文就不再具备被模糊查询的功能。考虑到某些字段存在模糊查询的求,我们可以提供一种高级的加密模式,加密后的密文仍然可以支持模糊查询功能。
在普通加密方式下,我们在数据库检索该加密数据的时候必须用全文匹配。如姓名:“张大铁”,用普通方式加密后成为“DQ21aTz/oe9qT2Xje1tTcddQ”,在数据库查询时,如果希望获取关于”张大铁”的记录,则对应筛选条件就是筛选出加密姓名为”“DQ21aTz/oe9qT2Xje1tTcddQ”的记录。然而,如果我们想检索姓名中含有“大铁”的人的记录,原本可以用数据库模糊查询(如SQL的like 语句)方式获取,现在加密后就无法满足这样的要求了。
2、数据检索存储方案
完整加密串和检索串要分离,可从完整字符串中提取检索串。
完整加密串和检索串分别存储数据表两个字段。因为加密后的数据长度会扩大 10-20 倍,应该减少索引字段的长度,提高检索效率低。加密原串用于开展业务,检索串用于数据查询使用。
3、模糊查询方案
3.1、不分词方案
手机号模糊查询
然后计算成密文= $ 7AnwZJ1e6BZc$
根据$ 7AnwZJ1e6BZc$ 到数据库表order_info中做一次查询即可,SQL 如下:Select * from order_info where 手机检索串 = ‘$ 7AnwZJ1e6BZc$’
3.2、分词组合方案
对密文数据进行分词组合,将分词组合的结果集分别进行加密,然后存储到扩展列,查询时通过key like '%partial%',这是一个比较划算的实现方法,我们先来分析一下它的实现思路。
先对字符进行固定长度的分组,将一个字段拆分为多个,比如说根据4位英文字符(半角),2个中文字符(全角)为一个检索条件,举个例子:
ningyu1使用4个字符为一组的加密方式,第一组ning ,第二组ingy ,第三组ngyu ,第四组gyu1 … 依次类推。
如果需要检索所有包含检索条件4个字符的数据比如:ingy ,加密字符后通过 key like “%partial%” 查库。
但是使用这种方式也有一定代价:
• 支持模糊查询加密方式,产出的密文比较长;
• 支持的模糊查询子句长度必须大于等于4个英文/数字,或者2个汉字。不支持过短的查询(出于安全考虑);
• 返回的结果列表中有可能有多余的结果,需要增加筛选的逻辑:对记录先解密,再筛选;
领取专属 10元无门槛券
私享最新 技术干货