2. TDE核心概念

说实话,刚接触 TDE 的人,最容易懵的就是密钥体系。

有人问:「不就是加密吗?一把密钥搞定不就行了?」

我刚开始也这么想。直到在一个银行项目中,看到他们因为密钥轮换,整个库停了 6 个小时……嗯,从那以后我才明白,密钥层次设计,才是 TDE 真正的灵魂。

2.1 为什么需要三层密钥?

你想想看,如果只用一把密钥加密整个数据库,会有什么问题?

  • 轮换成本高 —— 换密钥就得重加密所有数据,TB 级的库根本玩不转。
  • 风险集中 —— 密钥一旦泄露,所有数据裸奔。
  • 权限难拆分 —— DBA 和安全管理员共用密钥,审计形同虚设。

TDE 用「分层」的思路解决了这些问题。说白了,就是「分工明确,各管一摊」。

核心原则: 上层密钥保护下层密钥,下层密钥保护实际数据。每一层各司其职,互不干扰。
TDE 三层密钥架构 TDE 三层密钥架构 主密钥(Master Key) 加密保护 表空间密钥(Tablespace Key) 加密保护 数据加密密钥(DEK) 加密/解密 加密数据文件 AES / SM4 对称算法 密钥存储 HSM / KMS / 密码卡 每个表空间 独立生成 直接加密 数据块级别

2.2 三层密钥,各自扮演什么角色?

2.2.1 主密钥(Master Key)

这是整个体系的「根密钥」。它不直接碰数据,只用来加密和解密表空间密钥。

我个人习惯把主密钥放在 HSM 或专用的 KMS 里,绝不让它出现在数据库服务器的文件系统中。之前在给一家支付公司做方案时,他们就是把主密钥明文丢在配置目录里……我查出来后当场要求整改,这可不是小事。

  • 存储位置: HSM、KMS、密码卡、安全令牌。
  • 轮换频率: 建议 1-2 年一次,或者按合规要求执行。
  • 权限控制: 仅限安全管理员持有,DBA 无权访问。
经验之谈: 主密钥的生成一定要用硬件真随机数发生器(TRNG),别用伪随机库。我在项目中见过用 rand() 生成密钥的……那跟没加密差不多。

2.2.2 表空间密钥(Tablespace Key)

每个表空间独立拥有一把。它保护的是下面的数据加密密钥。

为什么非要多这一层?说白了,是为了「隔离」。

  • 独立管理: 不同的表空间可以用不同的密钥,敏感等级高的单独加锁。
  • 快速轮换: 只需要重加密 DEK,不用动数据块。
  • 细粒度授权: 可以给不同表空间分配不同的访问策略。

2.2.3 数据加密密钥(Data Encryption Key,DEK)

它是真正干活的那一位。数据块级别的加解密,全由它负责。

DEK 的数量可能非常多——每个表空间、甚至每个分区都可以独立生成。但别担心,这些 DEK 本身是加密存储的,只有被表空间密钥解开后才能使用。

  • 工作负载: 所有读写 IO 都会触及 DEK,性能影响最大。
  • 生命周期: 随表空间创建而生成,随表空间删除而销毁。
  • 内存驻留: 解密后的 DEK 会缓存在数据库缓冲区,但明文不会落盘。
⚠ 特别注意: 我曾经遇到过开发团队为了调优,把 DEK 缓存时间设得特别长。结果密钥轮换后,旧 DEK 还在内存里待了好几分钟……新数据用新密钥写,读旧数据时缓存命中还是旧密钥,导致部分页面无法解密。这个坑,千万别踩。

2.3 加密算法的选择

算法选型,说白了就是两个维度:安全性 和 合规性。

2.3.1 AES(高级加密标准)

国际通用标准,硬件加速支持最好。在 x86 平台上有 AES-NI 指令集,加解密几乎无感。

  • 密钥长度: 128 / 192 / 256 位,TDE 里通常用 256。
  • 工作模式: CKM_CBC / XTS,XTS 对数据块加密更友好。
  • 优势: 生态成熟,性能极佳,大多数数据库原生支持。

2.3.2 SM4(国密算法)

国内合规场景的标配。现在很多国产数据库和加密硬件都原生支持 SM4。

  • 密钥长度: 128 位固定长度。
  • 工作模式: CBC / ECB / XTS,推荐 XTS 模式用于存储加密。
  • 优势: 符合国密标准,等保 2.0 / 密评必备。
选型建议: 如果只做国际化业务,AES-256 + XTS 是最稳妥的组合。如果涉及到国内合规(金融、政务、医疗),必须同时支持 SM4,并且在密码模块中使用国密认证的硬件。

2.3.3 算法对比一览表

维度 AES-256 SM4
密钥长度 128 / 192 / 256 位 128 位
分组长度 128 位 128 位
硬件加速 AES-NI(x86)、ARMv8 国密芯片、部分 ARM
合规认证 FIPS 140-2 / 140-3 GM/T 0002-2012
典型场景 跨国企业、云原生 国内合规、政务、金融
性能损耗(无硬件加速) 约 3%-8% 约 5%-12%

我记得有个政府客户,一开始坚持只用 SM4,但他们的 Oracle 数据库跑在老款 Xeon 上,没有国密指令集。结果一开 TDE,性能掉了 15%。后来我们加了块国密加速卡,才把损耗压到 3% 以内。所以我的建议是:算法选型一定结合硬件能力一起评估,别光看纸面参数。

2.4 密钥生命周期管理要点

三层架构不只是画个图就完了。真正落地时,有几个绕不开的实操点:

  1. 密钥生成: 底层的 DEK 由数据库自动生成,但主密钥和表空间密钥建议在 KMS 或 HSM 中创建,保证随机源质量。
  2. 密钥存储: 主密钥不出 HSM,表空间密钥加密存放于数据库的数据字典中,DEK 加密存放于表空间头部。
  3. 密钥轮换: 表空间密钥轮换时,只需用新主密钥重新加密表空间密钥;DEK 轮换则需要逐块重加密数据。所以 DEK 轮换要安排在维护窗口。
  4. 密钥销毁: 删除表空间时,对应的 DEK 和表空间密钥必须从内存和存储中彻底擦除。别只删文件,要调用安全擦除接口。
一个小技巧: 在测试环境里,我会先拿一个非生产表空间跑一遍「全生命周期演练」——生成、使用、轮换、归档、销毁。所有密钥的版本号和生效时间都记录下来,方便出了问题回溯。这套文档,等保评审时也能用上。

2.5 我对密钥层次的理解

总结起来其实就一句话:分层的目的,是把「管理风险」和「计算风险」拆开。

主密钥负责「管」,它不碰数据,只保护下层密钥。表空间密钥负责「隔离」,让不同敏感等级的数据各用各的锁。DEK 负责「干」,它承受最多的 IO 压力,但即使被攻击者拿到,也只是一堆加密后的密文。

你想想看,如果没有这三层架构,轮换一次密钥就要全库重加密——TB 级的数据,哪个业务等得起?

好了,密钥层次和算法选型就聊到这儿。理解了这个骨架,后面讲接口集成时,你就能明白每一步在保护谁、为什么这么设计。