Rails7非确定性加密ActiveRecord字段where查询无结果问题

你没有配置错误，非确定性加密下直接用where做字段等值查询返回空，是Rails ActiveRecord加密机制的默认设计特性，不是配置疏漏。

• 默认的非确定性加密模式，核心设计目标是最高级别的数据保密性：同一个明文值每次加密都会生成完全不同的密文，攻击者即使拖库，也无法通过密文的重复规律推断明文内容。这种模式下不存在和明文一一对应的固定密文，所以你写SomeModel.where(name: 'blah')时，ORM无法生成正确的密文查询条件，自然匹配不到数据库里的记录。你调用SomeModel.all能看到正确的name值，是因为记录从数据库取出后，Rails会逐条自动解密字段内容，和查询阶段的逻辑完全不同。
• 加上deterministic: true的确定性加密模式，会让同一个明文每次生成相同的密文，ORM可以在查询时自动把明文条件转成对应密文做等值匹配，所以查询能正常返回结果，但这种模式的安全性更低，攻击者可以通过密文出现的频率做统计分析，反推明文内容。

如果要保留非确定性加密的高安全性，不能直接对加密字段做数据库层面的等值查询，可选方案如下：

• 小数据量场景：全表拉取后在内存中过滤匹配

# 注意：数据量超过千条级别不要用，会产生大量内存和CPU开销
SomeModel.all.select { |record| record.name == 'blah' }

• 生产环境推荐方案：新增独立的确定性哈希字段做查询索引
  1. 给对应数据表新增一个带索引的字符串字段，比如命名为name_hash
  2. 在模型中补充配置，自动维护哈希字段值：

  class SomeModel < ApplicationRecord
    # 原始字段保留非确定性加密
    encrypts :name
    # 哈希字段用确定性加密，仅用于查询匹配
    encrypts :name_hash, deterministic: true
  
    before_save :sync_name_hash, if: :name_changed?
  
    private
    def sync_name_hash
      self.name_hash = name
    end
  end
  

  3. 做等值查询时，统一使用哈希字段作为条件：

  SomeModel.where(name_hash: 'blah')
  

  这种方案既保证了原始name字段的加密安全性，又能走数据库索引实现高性能查询，是Rails官方文档推荐的标准做法。

如果业务需要对加密字段做模糊匹配、前缀匹配等复杂查询，Rails内置的加密机制无法支持，需要引入专门的可搜索加密方案，不要强行用全表内存过滤的方式处理大表数据，会引发严重的性能问题。

内容的提问来源于stack exchange，提问作者udit