2、TDE技术原理:数据加密层次、密钥体系、加密算法归纳总结

透明加密(TDE)说到底,就是在数据库底层做一层“翻译官”。你的应用写 SQL 时,数据在落盘前自动被加密;读的时候再自动解密。对上层业务完全无感。我刚开始接触 TDE 时,总觉得这事很玄乎——数据怎么就能“透明”地加密了呢?后来把它的三层架构摸透了,才明白原理其实很清晰。

2.1 数据加密层次

TDE 不是只在某一层动手脚,而是贯穿了从应用请求到物理存储的完整链条。我个人习惯把它分成三个层次来理解:

  • 应用层:业务 SQL 到这里还是明文,应用完全不知道底层加密的存在。
  • 文件系统层:数据库进程把数据页刷到磁盘时,TDE 模块介入加密。读入时解密。这一层通常由数据库内核或操作系统加密框架完成。
  • 存储层:如果用了硬件加密盘或 HSM,那物理扇区层面的加密是另外一回事,不过 TDE 主要管前两层。

我曾在一次项目中遇到过很头疼的问题:某客户把 TDE 和存储层的硬件加密同时开启了,结果性能陡降。为什么?因为做了两次加密,CPU 和 I/O 都白费了。嗯,这里要注意:TDE 和存储加密选一个就够了,别叠床架屋。

下面这张图把 TDE 的加密层次和密钥流转画清楚了,你可以一眼看明白:

TDE加密层次与密钥体系结构图 TDE 加密层次 & 密钥体系 应用层 明文 SQL · 业务系统无感知 数据库内核 TDE 模块 数据页加密/解密 · 密钥管理 文件系统层 加密文件系统 / 原始磁盘 存储层 硬件加密 / HSM 主密钥 (MK) 表密钥 (TEK) 数据页密钥 (DEK) 保护 → 保护 → 保护 → 说明:主密钥保护表密钥,表密钥保护数据页密钥,数据页密钥实际加密数据。 每次重启后,TDE 模块通过主密钥链逐层解密,恢复对磁盘数据的访问能力。

核心观点:TDE 的加密层次是分层的,越底层性能越好但灵活性越差。实践中我推荐在数据库内核层开启 TDE,既能保持高兼容性,又可以利用数据库自身的缓冲池优化。

2.2 密钥体系

TDE 的密钥体系听起来复杂,其实就三个角色。你想想看,假如只有一个密钥,那密钥泄漏了怎么办?所以 TDE 用了“密钥分层”的思路。

密钥名称 英文缩写 作用 存储位置
主密钥 MK(Master Key) 最顶层的密钥,用于加密表密钥 密钥管理服务(KMS)、HSM 或安全文件
表密钥 TEK(Table Encryption Key) 每个加密表独立一个,用于加密数据页密钥 数据库的数据字典中(加密存储)
数据页密钥 DEK(Data Encryption Key) 实际加密数据页内容的密钥 内存中临时生成,用完销毁

我曾经踩过一个坑:有次部署 TDE,只配了主密钥,没配置定期轮换。结果一年后安全审计说密钥过期了,必须重新生成主密钥。那时数据库里几十 TB 的数据,你以为重新加密就行了?错了——主密钥变了,所有表密钥都得重新加密,整个过程中数据库几乎不可用。

我的建议:生产环境一定要使用 HSM(硬件安全模块)或专业 KMS 存储主密钥。密钥轮换周期不要超过 90 天。另外,主密钥最好异地备份,否则 HSM 一坏,数据全完。

密钥的生命周期可以归纳为四个阶段:

  1. 生成:通常在数据库初始化 TDE 时,或创建加密表时自动生成。
  2. 存储:主密钥放 KMS,表密钥加密后存数据字典,数据页密钥仅存内存。
  3. 使用:数据库启动时,先通过主密钥解密表密钥,再缓存到内存中,后续读写直接使用。
  4. 轮换/销毁:主密钥和表密钥支持轮换(重新加密),数据页密钥每次会话结束即销毁。

2.3 加密算法归纳总结

TDE 中常用的对称加密算法就那么几种。说实话,算法选型不要纠结,因为数据库厂商基本都帮你定好了。不过了解它们的差异有好处,尤其是在性能调优时。

算法 密钥长度 分组模式 常见数据库支持 性能参考(相对)
AES-256 256 bit CBC / XTS Oracle, MySQL, SQL Server, PostgreSQL 中等
SM4(国密) 128 bit CBC / CTR 达梦、人大金仓、OceanBase 略低于 AES-256
3DES 168 bit CBC 部分老旧系统 慢(不推荐)

为什么 AES-256 是主流?说白了,它的硬件加速指令集(AES-NI)在现代 CPU 上是标配,几乎不占额外 CPU 开销。我在项目中测试过,开启 TDE(AES-256 模式)后,OLTP 场景的性能下降普遍在 3%~8% 之间,完全可以接受。但如果你选的是 SM4,在没有国密指令集的 CPU 上,性能可能会掉到 15%~20%。

注意:国密 SM4 的合规性要求很严格。如果你的业务需要过等保三级或相关国标,必须使用经过国密局认证的硬件或软件模块,光换算法是不够的。我在一个政务云项目里就吃过这个亏——软件实现了 SM4 但没认证,最后被审计打回。

另外,分组模式也得留意。CBC 模式需要一个初始化向量(IV),且不能重用;XTS 模式是专门为磁盘加密设计的,能有效防止“重放攻击”。我一般建议首选 XTS,如果数据库不支持,再退而求其次用 CBC 并确保每次写数据生成随机 IV。

好了,TDE 的技术原理就这些。记住三句话:加密分三层,密钥分三级,算法选 AES-256 或 SM4。搞定这些,后续集成 SDK 的时候你心里就有底了。