【MySQL数据库|第二十七篇】数据库信息加密下的模糊查询问题

本文讨论了数据库中如何保护敏感信息的安全性,以及在加密后如何进行模糊查询的问题。提出的方法包括在代码中解密、建立映射表和使用明文分词。作者强调了在保障数据安全和满足查询需求间寻找平衡的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言:

 数据库作为存储用户信息的地方,如何保护好数据库的安全性一直都是开发者所追求的终极目标。

目前最常见的数据库加密方法就是:拒绝明文存储信息。比如我们可以存储加密后的信息,把解密放到代码逻辑中去做。但是这种存储加密信息的方式也会存在问题。

目录

前言:

问题: 

1:在代码中进行解密

2. 建立映射表

3.明文分词

总结:


问题: 

当我们信息加密存储到数据库后,其实就没有办法对这段数据进行模糊查询了。

比如:我们使用MD5加密算法加密字符串“1234567”之后,把加密得到的字符串“FCEA920F7412B5DA7BE0CF42B8C93759”存储在数据库

此时如果我们想进行模糊查询,输入“1234”的时候,加密得到的字符串是:“81DC9BDB52D04DC20036DBD8313ED055”。

这两串毫不相干的加密后字符串肉眼可见的无法进行匹配。

那我们对敏感信息进行加密之后,要如何做用户的模糊查询呢?


 

1:在代码中进行解密

我们把加密信息提取到代码中,在代码中进行解密,然后再做模糊匹配。

虽然他的逻辑很简答,但是他的问题也很明显:

  • 把数据加载到代码中,容易出现OOM异常
  • 数据量过大的时候,及其占用IO资源
  • 加密方式为可逆加密,因此仍然存在安全性问题

2. 建立映射表

这种方式的思想是:建立映射表,查询的时候先根据数据库暴漏的真实信息去做查询,根据映射表中的结果去查询加密信息。

这种方式我都不知道是不是我理解错了,通过暴漏信息的方式来模糊查询。感觉使用的场景太少了

我目前只能想到:比如我们要根据手机模糊查询用户的信息,而用户的信息我们又不能全部暴漏,所以选项暴漏电话来做模糊查询。如下图所示

3.明文分词

既然我们没有办法根据“ABC” 模糊查询“ABCDE”,那么我们为什么提前就存储好拆分字段的加密结果呢?

比如:

那么我们可以冗余一些字段来存储当前字段拆分后的部分字段的加密结果

这样我们就可以进行模糊查询了,如果不想模糊查询,还可以把冗余拆分字段变成字符串合并在一起:

这样的话也可以有效减少冗余字段。

而很多的大公司也在用这种方式来进行加密字段的模糊查询,例如阿里巴巴:

开放平台-文档中心 (taobao.com)icon-default.png?t=N7T8https://open.taobao.com/docV3.htm?docId=106213&docType=1#s0

阿里公开的这篇文章中的其实也就是拆分明文字符串的思想。

总结:

数据库字段加密是保护敏感信息安全的有效手段,然而,它也带来了一些挑战,其中之一就是限制了常规的模糊查询操作。加密后的数据无法直接进行模糊匹配,从而影响了对加密字段的模糊查询功能。在解决这个问题的过程中,我们要尽力确保在保护数据安全的同时,尽可能地满足查询需求,为数据库安全与灵活性之间的平衡找到最佳解决方案。

如果我的内容对你有帮助,请点赞,评论,收藏创作不易,大家的支持就是我坚持下去的动力!

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我是一盘牛肉

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值