当前位置：首页 > news >正文

数据库安全网关体系中，对Long、Date类型列加密的方法

news 2025/10/29 10:59:09

数据库安全网关体系中，对Long、Date类型列加密的方法

引言：加密与业务兼容性的平衡

在数据库安全网关体系设计中，对Long、Date类型列的加密面临核心矛盾：安全性需求与业务查询需求的平衡。

传统加密方案会破坏数据类型特性，导致查询功能丧失。

本文将深度解析如何在保证安全性的前提下，通过特定加密技术维持数据格式不变，确保业务连续性。

核心认知：加密的类型转换必然性

技术现实

经过标准的对称加密算法（如 AES、SM4）加密后，输出都是一个二进制数据块。

在数据库中，这个二进制数据块通常用以下类型来存储： BLOB / BINARY / VARBINARY。这是最直接、最自然的存储方式。

加密库（如 Java 的 JCE）输出的字节数组可以直接存入这些类型的字段中。
优点：存储效率高，没有不必要的转换。
缺点：不可读，无法直接用于加密以外的操作。

接受两个事实

1、加密列无法直接用于数据库查询（除非实现密文索引或者其他特殊算法）。
2、如果不进行格式和范围保持的特有算法，加密就会破坏了原始数据的类型特性。
- 明文 Long：是一个8字节的整数
- 明文 Date：是一个日期格式或时间戳数字
- 加密后：都变成了一个二进制数据块

探讨：Long 值的加密

Long 是一个 64 位的整数。

加密方案: 确定性加密

例如 AES 在 ECB 模式或使用相同的 IV或者SM4等。相同的 Long 值总是产生相同的密文。这允许进行等值查询（WHERE user_id = ?），但会泄露数据的频率信息，安全性较低。

支持等值查询。

加密方案: 随机性加密

例如 AES 在 GCM 或 CBC 模式或者SM4等。每次加密相同的 Long 值都会产生不同的密文。这非常安全，但你无法基于密文进行查询（如 WHERE encrypted_salary > ?）。

不支持任何查询。

加密方案: 格式保留加密（FPE）

这是一种特殊的加密算法，其核心特点是加密后的密文与明文具有完全相同的格式和长度。

一个可用的算法实现： LongFPE加解密实现 claude-stars

实现该算法加密后的值，可以将密文保持在与明文相同的格式和长度。对于一个 Long 值，加密后仍然是一个 看起来像 Long 的值。

工作原理

它使用一个密钥，将一个有限集合中的值（如所有可能的Long值或Date值）映射到同一个集合中的另一个值，这个过程是可逆的。

优点

完美兼容现有数据库模式和查询，无需修改列类型。可以对加密后的数据进行范围查询和等值查询（虽然实现复杂）。

缺点

实现复杂，通常需要专门的FPE库（如 ff1 模式），性能可能不如 AES，且密码学界对其某些实现的审查不如 AES 那样广泛。

存储：Long值加密后，返回的 byte[] 可以直接存入 BLOB

探讨：Date 值的加密

Date 在 Java 中通常表示为自 1970-01-01 00:00:00 GMT 以来的毫秒数（一个 Long）。在数据库中，它可能是 DATE、DATETIME 或 TIMESTAMP 类型。

加密方案: 转换为 Epoch Millis 再加密

这是最通用的方法。将 Date 对象转换为其底层的长整型值（毫秒数），然后使用上面 Long 值的加密方法进行加密。

优点：简单，统一了 Long 和 Date 的处理逻辑。

缺点：失去了所有原生的日期查询能力。

加密方案: 转格式保留加密（FPE）

如果数据库中的日期是 YYYY-MM-DD 格式，FPE 可以将其加密为另一个看起来像 YYYY-MM-DD 的字符串。
原理：加密后的输出在格式和长度上与明文相同。
- Long值加密：加密后仍然是一个看起来合法的 BIGINT 值。
- Date值加密：加密后仍然是一个格式为 YYYY-MM-DD 的字符串。
优点：可以执行等值查询（WHERE birth_date = ‘2023-10-27’）。
缺点：同样存在安全性和实现复杂性的问题。