第4章 字段级加密 vs 全表加密 vs 数据库透明加密

我经常被问到：“到底该选哪种加密方式？”

答案其实不复杂。关键看你的数据在哪一层受到攻击。

你想想看，数据泄露的入口就那么几个：

• 数据库被拖库
• 备份文件被盗
• 运维人员越权查询
• 应用层注入漏洞

不同的加密方案，其实就是针对不同的攻击面。我习惯把这个选择拆成三个维度来对比。

咱们直接看这三种方案的底层逻辑。

三种加密方案的本质区别

先给个最直白的定义：

方案名称	加密粒度	谁管理密钥	对业务代码影响
字段级加密	单个列/字段	应用层	需要改造SQL
全表加密	整张表	数据库	影响查询性能
数据库透明加密(TDE)	整个数据库文件	操作系统/数据库	对应用透明

字段级加密：精确定位敏感数据

说白了，就是只加密你关心的那几个字段。

比如用户表，我只加密身份证号和手机号。其他字段，像用户名、注册时间，一律明文。

为什么这样做？

• 查询灵活性高：非敏感字段还能走索引，全表扫描压力小
• 密钥隔离：不同字段可以用不同密钥。手机号和身份证号分属不同业务域，密钥分开管理
• 最小化暴露：即使某个字段的密钥泄露，也只是那一列的数据暴露

但有个坑，我在项目中遇到过。字段级加密后，对加密字段做模糊查询基本不可能。你没法写 WHERE phone LIKE '%138%'，因为数据库里存的是密文。

解决办法是什么？

-- 传统做法（不可行）
SELECT * FROM user WHERE phone = encrypt('13800138000');

-- 我的常用方案：保留摘要字段
ALTER TABLE user ADD COLUMN phone_hash VARCHAR(64);
-- 存储手机号后4位或完整Hash，用于索引
-- 再配合应用层做精确匹配

全表加密：简单粗暴但性能硬伤

全表加密就是把整张表的数据块全部加密。数据写入时加密，读出时解密。

听起来很完美，对吧？

但问题来了——任何查询都需要全表扫描。

为什么？

• 索引页也是加密的，数据库没法直接读B+树
• 每次查询，数据库都得把全表数据块加载到内存，解密，再过滤
• 范围查询、排序、分组，这些操作在密文上完全没法做

我曾经在一个项目里试过MySQL的InnoDB全表加密插件。测试环境20万条数据，单条精确查询要2秒多。上生产的话，用户根本受不了。

所以要我说，全表加密更适合什么场景？

• 日志表：只写不读，或者很少读
• 归档表：数据写入后基本不访问
• 配置表：数据量极小，几百条以内

数据库透明加密(TDE)：防物理偷窃不等于防攻击

TDE做的事情是在文件系统层面加密数据文件。数据库启动时，从密钥管理服务读取密钥，解密文件头，然后正常运作。

对应用来说，完全无感知。SQL不用改，代码不用动。

但它的安全边界其实很窄：

• 只防物理窃取：数据库文件被盗、备份介质丢失
• 不防逻辑攻击：SQL注入、DBA越权查询
• 不防内存转储：攻击者拿到系统权限后，可以直接dump数据库进程内存获取明文数据

攻击场景	TDE	字段级加密
磁盘被盗	✅ 安全	✅ 安全
DBA查询敏感列	❌ 不防	✅ 安全
SQL注入获取数据	❌ 不防	✅ 阻止
备份文件泄露	✅ 安全	✅ 安全
内存转储	❌ 不防	❌ 不防

如何做选择？我的决策框架

我在做架构设计时，通常会问团队三个问题：

1. 数据在哪儿最怕丢？——如果是磁盘被盗，TDE够了；如果是内部越权，必须字段级
2. 业务允许改造代码吗？——存量系统改不动，TDE是妥协方案；新系统我建议字段级
3. 查询性能要求多高？——高频查询的敏感字段，必选字段级加密+摘要索引

具体落地时，我会这样组合：

• 核心敏感数据（身份证、银行卡、密码）→ 字段级加密，分离密钥
• 一般敏感数据（手机号、邮箱）→ 字段级加密，统一密钥+摘要索引
• 日志/归档数据 → TDE 或 全表加密
• 所有场景→ 磁盘层面必须启用TDE防物理泄露（双重保险）

避坑指南：我的三个教训

教训一：别把所有鸡蛋放一个篮子

我曾经在一个金融项目里，把所有敏感字段的加密密钥都放在一个KMS里。结果密钥轮转时，一次故障导致所有字段都解不了密。后来我改成按字段敏感级别划分密钥域，身份证用一套，手机号用另一套。这样即使某个密钥出问题，影响面也有限。

教训二：TDE不能替代应用层安全

有个客户问我：“上了TDE是不是就安全了？”我说：“不是。TDE防的是数据库文件被偷走，不防黑客用SQL注入拿数据。”他们后来在应用层加了字段级加密，才堵住这个口子。

教训三：性能测试要提前做

全表加密的性能衰减不是在压力测试时才暴露的。我建议你在POC阶段就用生产规模的数据量跑一遍。字段级加密的索引设计，一定要留出足够的测试时间。