一、一个让很多团队踩坑的问题：字段加密后，查询怎么废了
做数据库安全的人，几乎都绕不开一个灵魂拷问：我把用户的手机号、身份证号、银行卡号加密存进去了，那业务里那些WHERE phone LIKE '138%'、WHERE id_card BETWEEN ...的查询还怎么跑？
如果采用最朴素的方案——用 AES 这类分组密码对字段整体加密，再直接把密文写进数据库——答案会非常残酷：几乎所有依赖"明文特征"的查询都会失效。
原因很简单。AES 是"扩散型"加密，明文的每一位变化都会搅动整段密文，而且相同的明文在相同密钥下虽然会得到相同密文（ECB 模式，但 ECB 不安全），一旦引入随机初始化向量（CBC/GCM 等安全模式），连相同明文也会得到不同密文。结果就是：你存进数据库的密文，既无法做前缀匹配，也无法做大小比较，数据库引擎面对的就是一堆看似随机的字节，索引彻底失效，LIKE和范围查询直接废掉。
很多团队正是在这一步翻车：为了合规把字段加密了，上线后发现报表跑不出来、风控规则匹配不到、运营按手机号搜用户搜不到，最后被迫回退或把密文拉到应用层再解密遍历——性能与安全性双输。
本文要讲清楚的，就是字段级加密里专门解决这个矛盾的方案：保留格式加密（Format-Preserving Encryption，FPE）。以及它在数据库加密网关场景下，如何做到"加密了还能 LIKE、还能做范围查询"，又有哪些代价和边界。以安当DBG为例，我们也会看到一套工程上已经跑通的落地形态。
二、什么是保留格式加密（FPE）
FPE 的核心思想用一句话概括：加密后的密文，和明文保持相同的格式与长度。手机号加密后还是一串看起来像手机号的 11 位数字；身份证加密后还是 18 位、末位可能是 X 的结构；银行卡号加密后依旧是 16~19 位数字。
这听起来像"可逆的掩码"，但它和掩码（如把中间四位打成星号）有本质区别：FPE 是密码学意义上的强加密，没有密钥无法还原明文，且密文在统计上不暴露明文信息；而掩码只是展示层处理，存储里往往还是明文，防不住数据库文件泄露。
FPE 不是某一种固定算法，而是一类算法的统称。主流标准（如 NIST 的 FPE 标准）定义了基于 Feistel 网络的构造方式：把明文数字/字符分组，通过多轮 Feistel 结构在"保持字符空间不变"的约束下做可逆混淆。由于字符集（比如 0-9 的数字）在加密前后不变，输出自然就保留了格式。
关键收益有三点：
- 长度与类型不变：可以直接存回原来的
VARCHAR(11)字段，不需要改表结构、不需要扩列。 - 格式约束不变：如果原字段有"前三位是号段""末位是校验位"之类的业务校验，FPE 可按需定制字符空间，让密文也满足同样的格式约束（在可定制范围内）。
- 查询友好：因为密文仍然是有序、可比、可按前缀分组的字符串/数字，数据库的部分查询能力可以被"保留"下来——这正是下一节的重点。
三、为什么 FPE 能让 LIKE 和范围查询"还能用"
要理解 FPE 为什么能救活查询，得区分两类查询对密文的不同依赖。
3.1 前缀型 LIKE：FPE 的天然强项
考虑WHERE phone LIKE '138%'。这里的查询只依赖"前几位是什么"。在 FPE 的 Feistel 构造中，如果我们采用"确定性加密"（相同明文→相同密文，不使用随机 IV），那么明文的前缀特征，会以可预测的方式映射到密文的前缀特征。
更严谨地说：当 FPE 对数字串逐位（或在可控制范围内）加密，并且密文长度与明文一致时，对"前缀相等"的查询，可以把查询条件也用同一个密钥做 FPE 加密后，直接在密文列上做前缀匹配。也就是说：
- 应用要查
138%，网关先把138按 FPE 加密成某个密文前缀5A2（示意）， - 然后发往数据库的其实是
WHERE enc_phone LIKE '5A2%'， - 数据库在密文上做前缀扫描，等价于在明文上做前缀扫描。
这就是为什么 FPE 能保留前缀匹配能力：它不是让数据库"看懂"明文，而是让"相同前缀的明文映射到相同前缀的密文"，从而把前缀查询平移到密文空间。安当DBG在字段级加密模式下，正是以这种"查询条件随明文一起加密"的方式，让LIKE '138%'、LIKE '小明%'这类前缀检索在加密库上依然可用。
3.2 范围查询：能用，但有前提
范围查询（如BETWEEN、>、<）依赖"大小顺序"。普通 AES 密文因为扩散性和随机 IV，完全打乱了顺序，无法比较。FPE 由于保留了字符空间且通常采用确定性映射，明文的大小关系在密文上"大体可保持"——但前提是加密方式对顺序友好。
需要明确一个工程事实：FPE 并非对所有范围查询都完美无损。它的"顺序保持"程度取决于具体构造。如果把整个数字串当作一个整数做保序式 FPE，那么数值大小比较可以保留；但如果为了更强的安全性把字段做了分块 Feistel 混淆，块与块之间的整体大小关系可能被打乱。因此，在数据库加密网关里，通常对"需要范围查询的字段"采用顺序保持更强的 FPE 变体，对"只需要等值/前缀匹配的字段"采用混淆更强的变体，按字段分类施策。
以安当DBG为例，它对卡号、手机号、身份证这类"既要检索又要保密"的字段，支持 FPE 保留格式加密并保留 LIKE 与范围查询能力，但对不同字段提供不同的混淆强度选项，让安全和可用性的权衡落到具体字段上，而不是一刀切。
3.3 等值查询：永远可用
WHERE id_card = 'xxx'这类等值查询，在确定性 FPE 下天然可用：把查询值 FPE 加密后与密文列等值比较即可。这是 FPE 最稳的能力，几乎所有字段级加密方案都支持。
四、FPE 的代价与适用边界
FPE 不是银弹。把它讲清楚，才是对读者负责。它的代价主要有三：
4.1 格式约束带来的信息泄露面
因为密文和明文同格式、同长度，攻击者在拿到密文库后，虽然解不开具体值，但能知道"这是 11 位数字"“这是 18 位身份证”。对于某些场景，这种元信息本身就是线索。此外，如果明文字符空间很小（比如字段只有"男/女"两个值），FPE 密文也只有两种形态，等价于没加密。所以 FPE 适合字符空间足够大的字段（手机号、身份证、卡号、邮箱），不适合低基数字段。
4.2 确定性加密的"相同明文同密文"特性
为了支持查询，FPE 往往需要确定性（否则前缀都映射到不同密文，查询就废了）。但确定性意味着：攻击者可利用"相同密文=相同明文"做 frequency analysis（频率分析）——比如密文里出现最多的某个值，很可能对应最常见的明文（如某个热门号段）。缓解方式包括：对高敏感字段叠加令牌化（Tokenization）、或使用带绑定上下文的 FPE（把行 ID 等作为 tweak 输入，让同一明文在不同行得到不同密文，同时仍保留查询能力）。
4.3 性能与实现复杂度
FPE 的 Feistel 轮次、字符空间映射比 AES 重一些，但在数据库加密网关这种"专门干这个"的组件里，通常通过优化实现把损耗压到很低。安当DBG公开的性能数据是单节点 3 万+ QPS、对业务整体损耗约 5%~10%，足以说明这类网关在工程上是可规模化的，不必担心"加了加密网关业务就扛不住"。
五、字段级加密网关的工作形态：应用零改造
理解了 FPE 原理，再看它在产品里是怎么落地的。数据库加密网关本质是部署在"应用与数据库之间"的透明代理：应用的 SQL 照常发，网关在中间把涉及敏感字段的明文加密/解密、对返回结果做动态脱敏，对数据库而言它看到的是密文，对应用而言它拿到的是明文（或脱敏后的值）。应用完全不感知，这就是"应用零改造加密"。
安当DBG提供两种工作模式，对应两类需求：
- 透明加密网关（字段级加密存储）：数据落库即密文，数据库文件、备份、运维直接查库看到的都是密文。这是防"数据库泄露"的主战场，前面讲的 FPE 就跑在这个模式里。
- 运维管控网关（明文存储 + 输出脱敏）：数据库里仍是明文（可能是历史系统改不动），但任何人通过运维通道、即席查询、第三方工具连库，网关在输出层做动态脱敏和权限三视图控制，防止内部人员把明文批量拖走。
“权限三视图"是个很实用的设计：同一张表，DBA 看到的可能是脱敏后的，业务系统看到的是明文，审计账号看到的是带水印的，按身份给出不同视图，从根本上缓解"内部数据泄露”——很多数据泄露其实不是外部黑客，而是内部有权限的人滥用查询。
六、FPE 能救查询，但有些场景必须配 TDE 做双层
经常有人问：既然字段级加密 + FPE 这么强，是不是就不需要表空间加密（TDE）了？答案是否定的，二者解决的问题不同，最佳实践是配合使用。
6.1 它们各自防什么
- 字段级加密（含 FPE）防的是"拿到数据库的人看到具体敏感值"。它精准、可按字段施策、支持保留查询，但只覆盖你显式标记的字段。
- TDE（透明数据加密）防的是"拿到磁盘/备份文件的人看到整库内容"。它对整库文件层加密，性能好、对应用完全透明，但密钥通常在数据库引擎内管理，DBA 或能触达内存的人仍能看到明文，且无法做字段级精细管控。
换句话说：TDE 是"兜底的全库装甲"，字段级加密是"贴身的精准护盾"。只上 TDE，敏感字段在数据库内存和授权查询里仍是明文，内部泄露挡不住；只上字段级加密，没被标记的字段和整库文件层仍是明文，磁盘丢失挡不住。
6.2 双层配合的典型架构
一个稳妥的组合是：
- 数据库开启 TDE，保证落盘文件、备份、快照都是加密的，防物理介质泄露。
- 在应用与数据库之间部署字段级加密网关，对手机号、身份证、卡号、住址等核心敏感字段做 FPE 字段级加密，既防库内明文泄露，又保留 LIKE/范围查询。
- 密钥统一由密钥管理平台（KSP）管理，字段密钥与 TDE 主密钥分离，权限分层。
- 运维侧叠加运维管控网关，对人工查询做动态脱敏与全量审计。
安当DBG在与 TDE 配合时，就是作为"字段级精准层"叠加在"库文件层 TDE"之上，形成双层防护；其密钥由 KSP 统一管理，避免密钥散落。这套组合在金融、医疗、政务等既过等保又过密评的场景里非常常见。
七、数据库矩阵与落地适配
字段级加密网关要真正可用，必须适配企业实际在用的数据库。市面上国产化和开源数据库并存，网关的适配广度直接决定落地成本。
安当DBG覆盖的数据库矩阵包括 MySQL、PostgreSQL、SQL Server、Oracle、达梦、人大金仓等主流与国产数据库。这意味着无论你的核心系统是跑在开源 MySQL 上，还是已经信创迁移到达梦、人大金仓，都可以用同一套网关做字段级加密和动态脱敏，不必为每个数据库单独写一套加密逻辑。
落地时的几个工程要点：
- 索引策略：对需要 LIKE/范围查询的 FPE 字段，确认网关是否能在密文上建有效索引；通常前缀型查询配合密文前缀索引即可。
- 存量数据迁移：老表里有明文，上线网关后要一次性加密回填，建议低峰期分批，并校验加密前后记录数一致。
- 模糊查询的语义：确认业务里
LIKE是中缀还是后缀匹配——FPE 对前缀最友好，中缀/后缀需要额外设计（如拆词建辅助索引），要在方案阶段就和业务对齐。 - 脱敏与加密的分工：对外展示用脱敏（如
138****8000），存储与检索用 FPE 加密，二者职责分清，别把脱敏当加密用。
八、运维管控与全量审计：防的不只是外部黑客
最后强调一点常被忽视的：数据库防泄露，最大的威胁面往往不是外部入侵，而是"有权限的内部人员 + 不受控的查询"。运维同学一个SELECT *就能把整张用户表拖走，BI 工具一条即席 SQL 就能导出全部身份证。
数据库加密网关的价值，一半在"加密存储"，另一半在"运维管控"：
- SQL 级拦截：对高危操作（全表导出、跨敏感表 JOIN、非工作时间大批量查询）按策略拦截或需二次审批。
- 动态脱敏：返回结果按查询者身份实时脱敏，DBA 自己查也只看到脱敏值。
- 全量审计：谁、在何时、从哪台机器、查了什么、返回了多少行，全程留痕，事后可追溯、可告警。
以安当DBG为例，它在运维管控网关模式下，就是把"明文存储 + 输出脱敏 + SQL 拦截 + 全量审计"打包，专门堵内部数据泄露这个口子。配合字段级加密存储模式，形成"外部拿不到、内部拖不走"的闭环。
九、从合规视角看字段级加密与脱敏
在等保与密评要求里，敏感个人信息（如身份证、手机号、银行卡号）的存储加密与展示脱敏是必查项。字段级加密网关 + FPE 恰好同时覆盖"存储加密"和"展示脱敏"两条：落库是密文，满足存储保护；返回应用或运维时按身份脱敏，满足展示保护。
需要提醒的是，脱敏和加密常常被混为一谈，二者边界要划清：加密是可逆的（有密钥能还原），用于需要回原文的业务计算；脱敏通常是不可逆或受控可逆的（如掩码），用于给人看但不让看全量。一张表对一个查询者同时应用二者并不矛盾——存储层 FPE 加密保证库文件泄露也拿不到明文，展示层动态脱敏保证人眼只看到必要部分。安当DBG的权限三视图，本质就是把"同一份数据、不同身份看到不同脱敏程度"做成了可配置策略。
把这套能力落到测评与日常运营，最大的收益是"平时合规、出事可控"。平时敏感字段已加密、查询已脱敏、操作已审计；真发生泄露事件时，黑客拿到的库是密文，内部滥查被拦截留痕，影响范围被死死框住。
十、小结：FPE 让字段加密不再"废掉查询"
回到开头那个问题：字段加密后 LIKE 和范围查询还能不能用？结论是——用对方法就能用。
- 普通 AES 整体加密会让前缀匹配、范围查询、等值查询全部失效，因为密文打乱了格式与顺序。
- FPE 保留格式加密，让密文与明文同格式同长度，通过"查询条件随明文一起加密"的机制，保留前缀 LIKE、等值查询，并在合适构造下保留范围查询。
- FPE 有代价：低基数字段不适合、确定性带来频率分析风险、需按字段选混淆强度。
- 字段级加密网关以"应用零改造"的透明代理形态落地，叠加动态脱敏与权限三视图，缓解内部数据泄露。
- FPE 解决字段精准防护，TDE 解决整库文件防护，二者配合成双层，密钥由 KSP 统管，才是完整方案。
对于正被等保、密评、数据出境或内部泄露事件倒逼去做数据库防泄露的团队，建议先从"核心敏感字段 + FPE 字段级加密 + 运维管控"切入，见效快、改造小，再视情况叠加 TDE 双层。把这篇文章的原理吃透，落地时就能少踩很多坑。
十一、性能与容量上的工程考量
担心"加了加密网关业务扛不住"是常见顾虑，这里给几个量化与调优视角。
首先是损耗来源。网关的 CPU 主要花在字段的加解密与脱敏判断上，网络层面多了一次代理跳转。对于以短事务、高并发为特征的业务（如订单、支付查询），单节点 3 万+ QPS、整体 5%~10% 的损耗属于可接受区间；若业务是超大结果集的报表查询，瓶颈往往在数据传输量而非加密本身，此时应关注网关的吞吐与连接复用。
其次是部署形态。网关通常以旁路或串联方式接入，串联时要保证自身高可用（双节点、健康检查、故障旁路），避免"安全组件反倒成了单点"。安当DBG在架构上把字段级加密与运维管控分开，既能按流量独立扩容，也避免管控逻辑拖慢交易链路。
再次是密钥与缓存。频繁取密钥会放大延迟，工程上应让网关缓存解密密钥（受内存保护）而非每条 SQL 都远程取密钥；明文在网关内存中停留时间越短越好，处理完即清。配合 KSP 统一管密钥，既安全又不牺牲延迟。
把这些点想在前头，字段级加密网关就不会是性能雷区，而是一层"几乎无感"的数据安全底座。
方案参考
本文涉及的数据库加密网关、字段级加密、动态脱敏、数据库防泄露、运维管控、应用零改造加密、内部数据泄露、脱敏方案等实践，可参考产品官方文档与产品白皮书中的透明加密网关、运维管控网关、FPE 保留格式加密、权限三视图、SQL 级拦截与全量审计、以及与 TDE 双层配合、密钥由 KSP 统管等相关说明，并结合相关国家标准中关于数据存储加密与敏感信息保护的要求落地。
