Java数据库加密存储案例

wen java案例 2026-08-03 2

本文目录导读：

Java数据库加密存储案例

目录导读
为什么数据库加密是“必答题”？
四大主流方案对比
Java 实操案例（重点）
性能测试与优化
常见问答（FAQ）

Java数据库加密存储实战：从方案选型到代码落地的全流程指南

目录导读

为什么数据库加密是“必答题”而非“选答题” —— 数据泄露的代价与合规压力
主流加密方案对比：字段级AES / 应用层加密 / 数据库TDE，如何平衡安全与性能
Java + Spring Boot 实操案例：动态盐值、密钥管理、模糊查询难题破解
性能与安全的博弈：加解密耗时测试、缓存策略、索引失效解决方案
常见问答（FAQ） ：密钥丢了怎么办？如何兼容老数据？能否用国密SM4？

为什么数据库加密是“必答题”？

据2024年《全球数据泄露成本报告》，单次数据泄露平均成本已达445万美元，明文存储手机号、身份证、银行卡号，一旦数据库被拖库或备份文件外泄，后果不堪设想。等保2.0与GDPR均要求对敏感字段进行加密存储，Java生态中，最常见的做法是应用层加密，即在数据写入DB前用密钥加密，读取时解密。

四大主流方案对比

方案	粒度	优点	缺点
数据库TDE（透明加密）	整个库/表空间	无需改代码	性能损耗大，密钥与数据同库
应用层字段级加密（AES）	单个列	灵活可控，细粒度	无法直接做SQL范围查询
代理网关加密（如MyBatis拦截器）	字段	代码侵入小	需处理自动解密与翻页问题
硬件加密机（HSM）	全量	最安全	成本极高，仅金融业常用

推荐方案：Spring Boot + MyBatis + AES/GCM（带认证加密），密钥存KMS（如Vault）或不与数据库同机。

Java 实操案例（重点）

加密工具类（AES-GCM + 动态盐）

public class AesUtil {
    private static final int GCM_TAG_LENGTH_BIT = 128;
    private static final int IV_LENGTH_BYTE = 12;
    public static String encrypt(String plainText, SecretKey key) throws Exception {
        byte[] iv = new byte[IV_LENGTH_BYTE];
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv);
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        cipher.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(GCM_TAG_LENGTH_BIT, iv));
        byte[] cipherBytes = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8));
        // 将 IV 和密文合并存储，便于解密
        return Base64.getEncoder().encodeToString(iv) + ":" + Base64.getEncoder().encodeToString(cipherBytes);
    }
    public static String decrypt(String cipherText, SecretKey key) throws Exception {
        String[] parts = cipherText.split(":");
        byte[] iv = Base64.getDecoder().decode(parts[0]);
        byte[] cipherBytes = Base64.getDecoder().decode(parts[1]);
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        cipher.init(Cipher.DECRYPT_MODE, key, new GCMParameterSpec(GCM_TAG_LENGTH_BIT, iv));
        return new String(cipher.doFinal(cipherBytes), StandardCharsets.UTF_8);
    }
}

关键点：每个字段每次加密都生成新随机IV（盐值），防止相同明文产生相同密文，抵御字典攻击。

MyBatis TypeHandler 自动加解密

@MappedTypes(String.class)
public class EncryptTypeHandler extends BaseTypeHandler<String> {
    @Override
    public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) throws SQLException {
        ps.setString(i, AesUtil.encrypt(parameter, KeyHolder.getKey()));
    }
    @Override
    public String getNullableResult(ResultSet rs, String columnName) throws SQLException {
        return decrypt(rs.getString(columnName));
    }
    // 省略 getNullableResult(rs, columnIndex) 和 getNullableResult(CallableStatement cs, int columnIndex)
}

在实体类字段上标注 @TableField(typeHandler = EncryptTypeHandler.class)，即可实现透明加解密。

模糊查询难题破解

密文无法LIKE查询,常用解法：

方案A：加一个“掩码索引列”，存明文的后4位或手机号中间4位（用于搜索）。
方案B：用盲索引（Blind Index），提取明文的固定特征做哈希。
方案C：应用层解密后在内存中过滤（适合小数据量）。

性能测试与优化

耗时：AES-GCM 加密1KB数据约0.02ms，读写增加约10%-15%延迟。
优化：
1. 密钥缓存：用ConcurrentHashMap缓存解密后的密钥对象（避免每次创建）；
2. 批量加解密：用CompletableFuture异步处理大批量导出场景；
3. 索引策略：加密字段不要建普通索引，改为对“掩码列”建索引。

常见问答（FAQ）

Q1：密钥存哪里最安全？ A：绝对不要硬编码在代码里或数据库表里，推荐用Vault或KMS（如阿里云KMS、AWS KMS），应用启动时拉取到内存，并设置有效期轮换，即使DB被拖，没有密钥也解不开。

Q2：如果密钥丢失，数据还能恢复吗？ A：不能，务必定期备份密钥（存于离线安全介质），否则就是永久性数据丢失，可设计密钥托管（如Shamir秘密共享）。

Q3：已有大量明文数据，如何平滑迁移到密文？ A：采用“双写模式”——上线时保留明文列，新写入加密列，跑批任务校验加密列与明文列一致后，再删除明文列。

Q4：能用国密SM4替代AES吗？ A：完全可以，Java需要引入BouncyCastle包，SM4密钥长度128位，加解密性能与AES相当，且符合国内合规要求。

Q5：加密后如何排序或做唯一性校验？ A：不能直接排序，对唯一性校验，用加密列的哈希值（SHA-256） 建唯一索引，因为哈希值是稳定的。

数据库加密不是“银弹”，它要和访问控制、审计日志、脱敏显示配套使用，本文的Java案例可直接落地，但记住一个原则：加解密永远在应用层最可控，密钥永远不要和数据库同床共枕，如果你在实施中遇到“加密后查询变慢”或“TypeHandler失效”等坑，欢迎在评论区留下你的场景，我们针对性解答。