一、一个常见误区：把密钥写进配置文件

很多自研加密方案的翻车点，是把密钥（或密钥的加密口令）明文写在应用配置里。攻击者一旦拿到配置文件，加密形同虚设。正确的做法遵循“数据与密钥分离、密钥与根密钥分离”的分层原则：

• 数据用**数据密钥（DEK）加密，DEK 本身再用主密钥（KEK）**加密后存储；
• 主密钥由 KSP 统一托管，永不落地明文；
• 根密钥锁在 HSM 硬件加密机里，物理层面不可导出。

TDE 的密钥体系正是按这个思路设计的。

二、TDE + KSP + HSM 的分层架构

1. TDE 驱动层：在操作系统 I/O 层做加解密，使用 KSP 下发的密钥；
2. KSP 密钥管理系统：负责密钥的生成、存储、轮换、备份、销毁、审计全生命周期，通过国密二级认证；
3. HSM 硬件加密机：保护根密钥，提供高熵随机数（TRNG）和安全运算环境，根密钥永不外泄；
4. 审计追溯：每一次密钥使用、每一次加解密操作都有日志，满足合规审计。

这种“加密引擎（TDE）+ 密钥中枢（KSP）+ 硬件信任根（HSM）”的分工，让透明加密既无感、又可信。

三、TDE + DBG：双重权限，运维也看不到明文

单靠 TDE 解决的是“操作系统层”的权限——Root/DBA 看到密文。但如果运维人员通过数据库账号正常连库查询，TDE 管不到“查询返回的内容”。这就需要 DBG 数据库加密网关补上第二道防线：

• 业务访问：业务系统直连数据库，TDE 在底层自动加解密，支持高效模糊查询（LIKE、BETWEEN），完全无感；
• 运维访问：运维人员走 DBG 网关，DBG 实时解析 SQL，对 SELECT 结果中的敏感字段（身份证、银行卡、手机号、geometry 坐标）动态脱敏，不可逆导出；
• 纵深防御：操作系统层（TDE）+ 数据库访问层（DBG），业务与运维权限彻底分离。

某地图公司将 TDE 用于 PostgreSQL 整个数据目录透明加密（含 WAL 日志），再叠加 DBG 对运维 SQL 实时脱敏，实现“存储层拿不走、访问层查不出”的双层防护。

四、密钥丢了怎么办？灾难恢复

• KSP 提供密钥自动备份、双机热备、灾难恢复机制；
• 根密钥在 HSM 内受物理保护，并建议按规程做离线备份、在物理安全环境保管；
• 加密迁移时对存量数据做维护窗口处理，新写入数据自动加密，业务透明。

五、落地建议

1. 先梳理“哪些库/目录是核心资产”，圈定 TDE 保护点；
2. 密钥一律上 KSP，根密钥进 HSM，杜绝配置文件写密钥；
3. 凡涉及敏感字段查询的运维场景，叠加 DBG 网关脱敏；
4. 开启全链路审计日志，定期做密评与等保自查。

小结

TDE 是“面”，KSP/HSM 是“根”，DBG 是“第二道防线”。三者协同才能从“文件加密”升级到“全链路不可见”。下一篇我们看云上和跨网场景：当数据跑在别人机房里，TDE 怎么守住数据主权。

本文基于安当 TDE / KSP / HSM / DBG 产品资料整理。KSP 通过国家密码管理局商用密码检测认证二级（GM/T 0028），支持国密 SM1/SM2/SM3/SM4 与 RSA/AES 等算法。