1. 项目缘起当数据安全遇上模糊查询的“两难”在数据库应用开发中数据安全与业务便利性常常像一对难以调和的矛盾。就拿最常见的用户手机号存储来说直接明文存放一旦数据泄露后果不堪设想。因此对敏感字段进行加密存储已经成为合规开发和数据安全的基本要求。然而业务上又常常需要对这类加密字段进行查询尤其是模糊查询比如客服根据用户提供的部分手机号尾数进行检索。这便引出了一个经典难题字段被加密后如何还能支持高效的模糊查询最近在负责一个涉及用户隐私数据管理的项目时就直面了这个挑战。我们选用了国产的达梦数据库DM8它提供了丰富的内置加密函数如ENCRYPT、DECRYPT、HASH等用于实现字段级的加密存储。最初的方案很简单在写入时调用ENCRYPT函数加密查询时先解密再比对。但这只能解决等值查询对于LIKE ‘%138%’这类模糊查询完全无能为力因为加密后的密文是随机的、无规律的与原文的片段毫无对应关系。难道要在应用层把所有数据解密后再过滤这显然不现实性能和数据安全都无法接受。经过一番探索和实战我们找到了一套基于达梦数据库内置函数组合的解决方案不仅实现了字段的加密存储还巧妙地支持了对原文的模糊查询。这套方案的核心思路不是去“破解”加密而是通过设计让加密和查询在特定维度上“并行不悖”。2. 核心思路拆解分而治之的“明文-密文”双轨存储面对加密与模糊查询的矛盾最直接的思路往往是技术对抗比如研究同态加密等高级方案但这类方案通常复杂度高、性能损耗大且对数据库内置函数支持有限。我们回归业务本质采用了一种更务实、也更高效的“分而治之”策略。2.1 为什么“先解密再查询”的路走不通首先我们需要明确一点标准的加密算法如达梦支持的AES、DES是设计用来保证机密性的。其核心特性是“雪崩效应”——明文即使只改变一个比特产生的密文也会截然不同。这意味着原文“13800138000”加密后得到密文C1。原文“13800138001”加密后得到密文C2。C1和C2在二进制层面看起来毫无关联通过C1不可能推导出C2的任何部分。因此在数据库层面对密文字段直接使用LIKE操作符是无效的。而将数据全部拉到应用层解密再过滤等于将安全压力转移到了应用服务器且海量数据解密带来的性能开销是灾难性的。2.2 双轨存储密文保安全明文助查询我们的解决方案是在数据库表中为同一个敏感字段设计两列ciphertext_column(密文列)使用达梦ENCRYPT函数结合安全的密钥存储完整的、高强度的加密密文。这是数据安全的最终防线用于所有需要完整、准确原文的场景如验证、展示给授权用户。plaintext_prefix_column(明文前缀列)存储原始数据经过特定处理后的“可查询片段”。这个处理不是加密而是一种确定的、可逆或可映射的变换目的是为了支持模糊查询。这样设计的关键优势在于安全性无损核心的、完整的敏感信息始终以密文形式存在符合安全审计要求。查询可行模糊查询操作在plaintext_prefix_column列上进行因为该列内容与原文有确定的关联关系。性能高效查询完全在数据库内完成可利用索引优化避免了应用层的数据搬运和解密开销。那么接下来的核心问题就是plaintext_prefix_column里到底应该存什么如何从原文生成它3. 关键实现利用哈希与子串构造可查询指纹这里我们引入了达梦数据库的另一个内置函数HASH。哈希函数如SHA1、MD5能将任意长度的输入映射为固定长度的、看似随机的字符串哈希值。关键特性是确定性——相同的输入必然产生相同的哈希值。但直接存储整个哈希值仍然无法支持模糊查询。因为原文“13800138000”和“13800138001”的哈希值同样毫无相似性。我们的突破口在于不对完整原文哈希而是对原文的连续子串进行哈希。3.1 具体实施步骤假设我们要加密存储用户手机号phone_number并支持对后4位的模糊查询。第一步设计表结构CREATE TABLE user_info ( id INT PRIMARY KEY, -- 其他业务字段... phone_cipher TEXT, -- 存储完整加密密文 phone_prefix_hash CHAR(40), -- 存储用于模糊查询的哈希前缀假设使用SHA140位十六进制 phone_prefix_index VARCHAR(10) -- 可选存储明文前缀本身用于最左前缀LIKE查询 );第二步数据插入加密与指纹生成在应用层或使用达梦的DML触发器在插入或更新数据时进行如下处理-- 假设原始手机号变量为 v_phone DECLARE v_phone VARCHAR(20) : 13800138000; v_key VARCHAR(32) : my-secret-key-1234567890123456; -- 加密密钥 v_cipher TEXT; v_prefix_plain VARCHAR(4); v_prefix_hash CHAR(40); BEGIN -- 1. 生成完整密文 v_cipher : ENCRYPT(v_phone, AES, v_key); -- 2. 提取用于查询的明文片段例如后4位 v_prefix_plain : SUBSTR(v_phone, -4); -- 获取 8000 -- 3. 方案A存储明文片段简单但安全性稍弱 -- 直接插入 v_prefix_plain 到 phone_prefix_index 列。 -- 3. 方案B存储明文片段的哈希值更安全推荐 v_prefix_hash : HASH(SHA1, v_prefix_plain); -- 对8000进行SHA1哈希 -- 插入 v_prefix_hash 到 phone_prefix_hash 列。 -- 将 v_cipher, v_prefix_plain/v_prefix_hash 插入表中 INSERT INTO user_info (..., phone_cipher, phone_prefix_hash, phone_prefix_index) VALUES (..., v_cipher, v_prefix_hash, v_prefix_plain); END;3.2 两种查询模式的对比与选择现在我们支持两种模糊查询方式模式一基于明文前缀列的快速查询如果phone_prefix_index列存储的是明文片段如‘8000’查询极其简单高效-- 查询手机号尾数为‘8000’的用户 SELECT id, DECRYPT(phone_cipher, AES, my-secret-key-...) AS phone FROM user_info WHERE phone_prefix_index LIKE %8000; -- 或者 8000优点查询最简单可以直接利用普通B树索引进行等值或左前缀LIKE查询速度最快。缺点明文片段本身可能泄露部分信息虽然只是片段。如果片段长度很短或熵值低存在被彩虹表反向猜测的风险。模式二基于哈希前缀列的安全查询如果phone_prefix_hash列存储的是哈希值查询时需要先对查询条件做同样的哈希变换-- 查询手机号尾数为‘8000’的用户 SELECT id, DECRYPT(phone_cipher, AES, my-secret-key-...) AS phone FROM user_info WHERE phone_prefix_hash HASH(SHA1, 8000); -- 等值查询优点安全性更高。即使数据库被拖库攻击者看到的是哈希值无法直接得知明文片段是什么反向破解哈希尤其是对短字符虽然可能但增加了难度。对于LIKE ‘%38%’这种中间模糊需要预先计算所有可能片段的哈希如‘1380’ ‘3800’ ‘8000’进行IN查询或多次查询逻辑更复杂但安全。缺点查询逻辑稍复杂且无法利用索引进行真正的LIKE模糊匹配只能进行等值查询。对于复杂的模糊模式需要应用层拆解查询条件。在实际项目中我们采用了折中方案同时存储phone_prefix_index(明文) 和phone_prefix_hash。对于已知的、固定的模糊查询模式如“后4位”、“前3位”使用明文列创建索引保证查询性能。哈希列则作为额外的安全校验手段或在某些对片段信息也需保密的场景下使用。密钥管理至关重要必须使用安全的密钥管理系统绝不能硬编码在SQL或应用中。4. 实战踩坑性能、索引与边界情况处理方案思路清晰了但在真实的大数据量、高并发场景下落地还有一堆“坑”等着。这里分享几个我们趟过来的关键点。4.1 索引设计与查询性能优化双列存储必然带来额外的存储开销和写入性能损耗但这通常是可接受的。真正的挑战在于查询性能。坑点一无效的密文列索引。在phone_cipher上建索引是毫无意义的因为每次加密由于IV初始化向量的存在即使相同明文也可能产生不同密文取决于加密模式且密文本身无序。坑点二LIKE ‘%xxx’ 导致索引失效。即使在phone_prefix_index列上建立了索引使用LIKE ‘%8000’前导通配符查询也会导致达梦以及绝大多数数据库无法使用该索引进行快速定位会退化为全表扫描。我们的优化策略固定模糊查询模式与业务方协商将模糊查询规范为有限的几种模式例如“后4位精确查询”、“前3位精确查询”而不是任意的‘%xxx%’。这样查询条件可以转化为对phone_prefix_index列的等值查询或左前缀LIKE如LIKE ‘138%’从而充分利用索引。-- 优化后查询后4位是‘8000’ WHERE phone_prefix_index 8000; -- 优化后查询前3位是‘138’ WHERE phone_prefix_index LIKE 138%; -- 可以使用索引使用函数索引如果查询模式固定为“后N位”可以在达梦上创建函数索引。CREATE INDEX idx_phone_suffix ON user_info(SUBSTR(phone_prefix_index, -4)); -- 查询时使用相同的函数 WHERE SUBSTR(phone_prefix_index, -4) 8000;但需注意函数索引的使用必须与查询条件中的函数表达式完全一致。分区表考虑对于海量表可以考虑按phone_prefix_index的前几位进行列表分区将数据分散减少单次查询的扫描范围。4.2 加密函数选型与数据格式达梦的ENCRYPT函数支持多种算法和模式。ENCRYPT(src, algorithm, key[, mode[, iv[, padding]]])算法选择我们选择了‘AES’因为它目前是安全性和性能平衡的最佳选择。‘DES’已不安全不推荐。模式与IV默认使用CBC模式且函数会自动生成一个随机的IV。这是好事增强了安全性相同明文加密多次得到不同密文但也意味着直接对密文使用DECRYPT函数时必须使用加密时生成的IV。达梦的ENCRYPT/DECRYPT函数对在单次会话中成对使用没问题但如果你将密文存储后另一次会话来解密就需要将IV也存储下来。一个常见做法是将IV通常是16字节与密文拼接后一起存储解密时再拆分。达梦的ENCRYPT函数返回值是RAW或TEXT类型存储时需注意字段类型兼容。填充确保使用标准的PKCS5/PKCS7填充避免解密时出错。4.3 一个隐蔽的陷阱解密失败与字符集在一次数据迁移后我们遇到了部分历史数据解密失败的情况报错提示“填充错误”。排查后发现是字符集不一致导致的问题。原始数据在ZHS16GBK字符集下加密。迁移后数据库或客户端会话设置在UTF-8字符集下。虽然字符串看起来一样但底层字节表示可能不同尤其是中文导致解密时使用的字节流与加密时不一致。教训所有涉及加密解密操作的环节应用服务器、数据库连接、数据库本身必须统一字符集设置。最好在加密前将字符串明确转换为统一的字节数组如使用UTL_RAW.CAST_TO_RAW函数再进行处理确保字节级别的确定性。5. 方案扩展与高级场景探讨基础方案解决了大部分问题但对于更复杂的查询需求我们还可以做进一步扩展。5.1 支持多模式模糊查询如果业务需要同时支持“前3位”、“中4位”、“后4位”等多种模糊查询难道要存多个前缀列吗理论上可以但这会显著增加存储和写入开销。一个更优雅的方案是使用布隆过滤器Bloom Filter的思想但需要在应用层实现。我们可以设计一个“查询指纹”列存储一个由多个哈希值组合成的位图。例如将手机号按不同长度和位置切片如‘138’,‘380’,‘800’,‘000’,‘1380’,‘3800’,‘8000’。对每个切片计算一个哈希值如CRC32映射到一个很长的位图如1024位中的某一位并将其置为1。将整个位图可以压缩存储存入数据库的一个字段中。查询时将查询条件如‘%380%’也按同样规则生成切片计算哈希并检查位图中对应的位是否都为1。如果都是1则可能存在布隆过滤器的特性是“可能存在假阳性但绝无假阴性”然后再通过精确解密验证。这种方法用一定的误判率换取了强大的多模式模糊查询能力和固定的存储开销。5.2 与数据库审计、脱敏功能结合达梦数据库自身也提供数据脱敏、访问审计等安全功能。我们的字段级加密方案可以与这些功能协同动态脱敏可以配置策略对于无权查看完整手机号的用户即使查询结果中包含phone_cipher列返回的也是脱敏后的值如‘138****8000’而我们的解密逻辑只在有更高权限的服务或模块中执行。审计追踪所有对user_info表的查询尤其是涉及phone_prefix_index列的模糊查询都可以被数据库审计功能记录便于事后追溯和异常行为分析。5.3 密钥生命周期管理本方案的安全基石是加密密钥。密钥绝不能写在代码里。必须集成密钥管理服务KMS实现密钥的轮转、备份和权限控制。达梦数据库可以调用外部扩展或者由应用程序从KMS获取密钥后再执行加密解密操作。当密钥需要轮转时需要有一个数据迁移流程批量解密旧密文再用新密钥加密这个过程需要精心设计以保证服务不间断和数据一致性。这套基于达梦内置函数的“加密存储明文/哈希索引”方案本质上是在安全与业务便利之间寻找一个恰当的平衡点。它没有使用黑科技而是通过精心的数据模型设计将问题分解用可接受的成本解决了实际痛点。在实施过程中深刻体会到安全方案的设计必须紧密贴合具体的业务查询模式过早优化和过度设计都会带来不必要的复杂度。先定义清楚“要模糊查询什么”再设计“如何安全地存储并能查到它”这个顺序至关重要。
