2. 加密方案选型：透明加密 vs 应用层加密，选择依据与潜在问题
做数据库加密，第一个要拍板的事就是：到底选透明加密，还是应用层加密？
很多团队一上来就纠结性能，其实选型没那么玄乎。说白了，就是看你想让谁来管密钥、谁来改代码。我这些年被问过无数次“哪个方案好”，每次我都反问一句：你的业务代码还能动吗？
2.1 透明加密（TDE）—— 对应用无感，但对运维有要求
透明加密，全称 Transparent Data Encryption。数据库自己把数据加密后落盘，读的时候自动解密。应用层完全不用改 SQL，甚至都不知道加密这回事。
我的经验： 透明加密最适合“历史包袱重”的系统。我接过一个金融项目，几百张表、上千个存储过程，要是逐条改 SQL 得改到吐血。最后上了 TDE，一周就搞定了。
优点很明显：
- 无侵入： 应用代码零改动，接入成本极低。
- 统一管控： 密钥由 DBA 或数据库内置 keystore 管理，策略集中。
- 性能损耗相对可控： 主流数据库（Oracle TDE、MySQL InnoDB 表空间加密、SQL Server TDE）都做了硬件加速或页级加密。
但坑也不少，我先列几个：
| 潜在问题 | 详细说明 |
|---|---|
| 密钥轮转困难 | 很多 TDE 实现不支持在线重加密，轮转主密钥可能要锁表或者做全量导出再导入。我见过一次事故：轮转密钥时没预估数据量，库直接挂了 6 小时。 |
| 备份文件同样加密 | 备份恢复时如果密钥丢失或损坏，整个备份就废了。记得分开备份密钥。 |
| 内存泄漏风险 | TDE 会缓存解密后的页或行，内存压力大时可能抖动。我在 MySQL 8.0 社区版遇到过加密页缓存不释放的 bug。 |
| 不支持部分列加密 | 透明加密通常是表空间级或整个表级，无法细粒度选择只加密某几列。 |
注意： TDE 只保护“静止数据”。数据在内存里是明文的，如果内存被 dump 或者被 side-channel 攻击，照样泄露。所以别指望 TDE 搞定一切。
2.2 应用层加密 —— 灵活但麻烦，适合对安全颗粒度要求高的场景
应用层加密，就是在业务代码里自己调用加密 API（比如 AES-256-GCM），把字段值加密后再写入数据库。读的时候先查出来，再在应用层解密。
这种方案我通常推荐给“数据主权敏感”的项目。举个例子，我有一次做社保平台，要求每个人的身份证号在数据库里必须加密，但其他字段可以开放给统计查询。TDE 搞不定，只能上应用层。
优点：
- 细粒度控制： 可以精确到某个字段、甚至某行。
- 端到端加密： 数据从应用发出就是密文，传输和存储都不暴露明文。
- 与数据库解耦： 换库、迁移、分库分表都不影响加密逻辑。
潜在问题？老多了：
| 潜在问题 | 详细说明 |
|---|---|
| 性能损耗大 | 加密解密都在应用服务器上，CPU 负载飙升。我测过一个 Java 项目，全字段 AES-256 加密，QPS 从 2000 掉到 400。 |
| 查询能力受限 | 加密后数据库无法做 LIKE、排序、范围查询。要么放弃这些查询，要么用可搜索加密（但实现极其复杂）。 |
| 密钥管理复杂 | 每个应用节点都需要访问密钥，还得做密钥轮转、过期、审计。很多团队直接用 KMS（密钥管理服务），但调用 KMS 的延迟也是个坑。 |
| 代码侵入强 | 所有涉及加密字段的 CRUD 都要显式加解密逻辑。我见过有人用 MyBatis 拦截器自动加解密，但一旦 SQL 里写了函数或子查询，拦截器就会漏处理。 |
2.3 选型依据 —— 你的场景是什么？
别在会议室里空谈理论。我一般拿几个问题来拍板：
- 现有代码能改吗？ 如果全是屎山，别硬碰，直接 TDE。
- 需要按字段粒度加密吗？ 是 ⇨ 应用层；否 ⇨ TDE。
- 对查询功能有强依赖吗？ 需要 LIKE、排序、范围查询 ⇨ 只能 TDE（或另用可搜索加密但代价很大）。
- 团队有密钥管理经验吗？ 没有 ⇨ 用 TDE 自带的 keystore 省心。
- 合规要求是什么？ PCI-DSS、HIPAA 一般接受 TDE 作为“加密静止数据”的手段，但 SOC2 可能要求端到端审计，应用层更合适。
下面这张图总结了两种方案的对比和选择逻辑：
2.4 两者混搭 —— 我踩过的坑
你可能会想：能不能一部分用 TDE，一部分用应用层？理论上可以，实际风险很大。我曾经在一个项目中试过混合方案：核心账户表用应用层 AES 加密，其余表用 TDE。结果呢？
- 运维脚本混乱：备份恢复时，TDE 密钥由数据库管理，应用层密钥由 KMS 管理，两套体系经常对接不上。
- 故障定位困难：某次慢查询，先怀疑 TDE 解密慢，排查半天发现是应用层加密字段没做索引。
- 权限审计失控：DBA 能看到 TDE 表的明文，但看不到应用层加密字段；安全团队要求统一审计，我们只能自建日志桥。
所以除非团队架构非常成熟，否则我建议优先统一方案。如果非混搭不可，务必把密钥管理、恢复流程、权限模型提前画清楚。
避坑指南： 我曾经遇到一个团队，为了“灵活”同时上了两种加密，结果上线第三天就因为密钥轮转脚本写错了，导致 TDE 表和应用层加密表的解密顺序不一致，应用启动时一直报解密失败。后来花了整整一周才恢复。我的教训是：要么全盘 TDE，要么全盘应用层，别在中间地带打转。
2.5 小结与选型清单
| 对比维度 | 透明加密（TDE） | 应用层加密 |
|---|---|---|
| 代码改动 | 无 | 大，每个字段都要改 |
| 性能开销 | 10%~20%（页级/硬件加速） | 20%~50%（取决于加密次数） |
| 字段粒度 | 整表或表空间 | 精确到字段 |
| 查询能力 | 完全保留 | 基本丧失（除非可搜索加密） |
| 密钥管理 | 内置，简单 | 需外部 KMS 或自建 |
| 恢复复杂度 | 中（需备份密钥） | 高（需保证所有节点密钥同步） |
| 合规适配 | 满足多数静止加密要求 | 满足端到端加密要求 |
最后说一句：没有银弹。选型时多花一天讨论，上线后能少花一周排障。你自己根据实际情况来，拿不准的时候优先选 TDE 起步——毕竟代码不改，万一不行回退也容易。应用层加密一进去，再想拔出来就难了。