📚 课程目录第3章数据库加密原理

数据库加密原理：透明加密与字段级加密

各位好，这一章我们来聊聊数据库加密里两个最核心的路线——透明加密和字段级加密。说白了，就是一个管全库，一个盯字段。选择哪一种，直接决定了你的SDK该怎么设计、密钥放哪儿、性能影响多大。

我记得有一次，客户要求“等保三级达标，数据必须加密”，但业务系统是老旧的ERP，改代码几乎不可能。那时候我选了透明加密，全库一锁，省心。但另一个场景呢？金融交易系统里只需要加密身份证号，如果用全库加密，索引全废，查询慢到飞起。字段级加密就正合适。你想想看，没有一种万能银弹，理解原理才是关键。

透明加密（TDE）—— 让加密隐形

透明加密，全称 Transparent Data Encryption。它的核心理念是：存储加密、查询解密，应用完全无感。我在一个政务云项目里就部署过 Oracle TDE，数据库管理员甚至都不知道哪些表被加密了——当然，这是合规要求。

原理：数据库引擎在数据写入磁盘前自动加密，读取时自动解密。密钥由数据库内部管理或外部HSM托管。
优点：不改应用、不影响SQL功能（索引、查询都能用）、运维简单。
缺点：粒度粗（要么全库要么表空间）、性能开销集中在I/O上、密钥泄露风险较大。
等保2.0定位：满足“数据存储加密”要求，但在“数据脱敏显示”和“细粒度访问控制”上力不从心。

我的经验：做TDE实施时，一定要先测AWR报告里的“log file sync”和“buffer busy waits”。我曾经踩过坑——加密打开后，硬盘I/O暴增导致TPCC下降40%。后来换成企业级SSD才解决。所以性能评估别跳过。

字段级加密—— 精准打击

字段级加密就灵活多了。它只加密指定的敏感字段，比如身份证号、手机号、银行卡号。应用在写入前把明文加密成密文，查询时要么解密，要么保持不变形（保留格式加密）。

实现方式有两种：一种是应用层自己调加密函数（比如Java调用AES库），另一种是用数据库自带的加密函数（比如MySQL的AES_ENCRYPT）。我个人偏向用独立SDK包，因为密钥管理更方便。

// 示例：Java字段级加密解密（AES-256-GCM）
public class FieldEncryptor {
    private static final String ALGORITHM = "AES/GCM/NoPadding";
    private SecretKey key;
    
    public String encrypt(String plaintext) {
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        cipher.init(Cipher.ENCRYPT_MODE, key);
        byte[] iv = cipher.getIV();
        byte[] ciphertext = cipher.doFinal(plaintext.getBytes(StandardCharsets.UTF_8));
        // 返回 Base64(iv + ciphertext)
        return Base64.getEncoder().encodeToString(
            ByteBuffer.allocate(iv.length + ciphertext.length).put(iv).put(ciphertext).array());
    }
    
    public String decrypt(String encrypted) {
        ByteBuffer buffer = ByteBuffer.wrap(Base64.getDecoder().decode(encrypted));
        byte[] iv = new byte[12]; // GCM 标准 IV 长度为12字节
        buffer.get(iv);
        byte[] ciphertext = new byte[buffer.remaining()];
        buffer.get(ciphertext);
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        cipher.init(Cipher.DECRYPT_MODE, key, new GCMParameterSpec(128, iv));
        return new String(cipher.doFinal(ciphertext), StandardCharsets.UTF_8);
    }
}

优点：粒度极细、可以按字段设置不同密钥、支持部分脱敏、对不加密字段完全无性能影响。
缺点：应用要改代码（或配置ORM映射）、破坏索引（无法高效查询密文）、密钥管理复杂度上升。
等保2.0定位：满足“重要数据加密存储”和“数据脱敏”要求，尤其适合包含个人敏感信息（PII）的列。

两种方案对比

对比维度	透明加密（TDE）	字段级加密
加密粒度	数据库 / 表空间	单个字段
对应用影响	无（透明）	需修改SQL / ORM
性能开销	集中式I/O开销	分散式CPU开销
密钥管理	简单（一个主密钥）	复杂（多字段多密钥）
索引支持	完全支持	基本不支持（除非保留格式加密）
脱敏能力	无，返回原始密文	可控，可返回部分明文
典型场景	历史库、归档库、全量脱敏	生产库中的敏感字段（身份证、手机号）

注意：字段级加密后，数据库本身无法对密文做排序、模糊查询。如果你需要根据手机号模糊搜索（比如where phone like '138%'），那这条路就走不通。解决办法是额外存一个保留格式加密（FF1）的副本，或者考虑用加密后的哈希值做相等匹配。

如何二选一？—— 实际决策建议

别急着拍脑袋。我一般会列一个检查清单：

应用是否允许修改代码？能就字段级，不能就TDE。
敏感字段占比高还是低？超过30%建议TDE，否则字段级。
是否有等保2.0的“数据脱敏显示”考核？有则必须字段级（配合脱敏SDK）。
密钥安全要求多高？TDE的密钥在DB内存中，字段级的密钥可以做到HSM独立管理。
团队运维能力如何？字段级加密需要更细致的密钥生命周期管理。

举个真实例子：某银行客户数据仓库改造，他们既有全库加密要求（满足等保存储加密），又需要对柜面展示的身份证做脱敏。最终方案是：底层用Oracle TDE加密整个表空间，上层业务对身份证字段再做一层字段级加密（保留格式FF1），这样存储和展示都合规。虽然多了一层开销，但两条路并不互斥，可以组合。

一个常见的坑：

我曾经在一个电商项目里，想当然用了字段级加密加密手机号，结果忘了预留查询接口。后来运营需要按手机号查订单，只能遍历全表解密——慢到天荒地老。最后不得不加了一列手机号哈希值来支持精准匹配。嗯，所有设计都要先考虑“怎么用”，而不仅仅是“怎么存”。