一句话答案：别再只给数据库上锁，却把 AI 模型、日志、配置文件晾在明文里 —— 真正的存储安全，要用 TDE 透明加密，从文件系统层统一覆盖所有数据类型，应用零改造，性能无感知。

---

一、“我们以为数据安全了，其实只保了一半”

上个月，朋友老赵 —— 智能驾驶公司的安全负责人 —— 在行业沙龙上苦笑：“我们给 MySQL 上了 TDE，审计过了；结果黑客通过一个调试接口，直接下载了训练好的感知模型（.pt 文件），连带标注数据一起打包走了。”

我问：“模型没加密？”

他说：“模型存在 NAS 里，NAS 开了‘传输加密’，但落盘是明文…… 更糟的是，训练日志里还打印了内部 IP 和账号，全被翻出来了。”

这不是孤例。

在数据爆炸时代，企业数据早已不止 “数据库表”：

• 结构化数据：MySQL、Oracle、PostgreSQL 中的业务记录；
• 非结构化数据：AI 模型（.pt/.onnx）、日志（.log）、配置文件（.yaml）、文档（.pdf）、视频（.mp4）、备份包（.tar.gz）……

但现实是：

• 安全投入集中在数据库加密；
• 文件、模型、日志等 “非结构化资产” 长期裸奔；
• 一旦服务器被控，攻击者直接scp /data/model.pt，毫无阻力。

问题本质：存储加密不能只盯 “表”，而要管住 “盘”—— 无论数据长什么样，只要落在存储上，就该自动加密。

---

二、第一阶段：“只加密数据库”—— 安全的 “选择性失明”

三年前，老赵的团队刚做等保，安全策略很简单：“只要数据库加密了，就算数据安全落地。”

典型做法：

• 给 MySQL 开启 TDE（如 InnoDB Tablespace Encryption）；
• Oracle 用 Wallet 管理密钥；
• PostgreSQL 用 pgcrypto（但仅字段级，非透明）。

效果：

• 数据库文件（.ibd、.dbf）落盘为密文；
• 即使硬盘被盗，无法直接读取表内容。

但盲区巨大：

• AI 训练产出的模型文件（/models/resnet50.pt）—— 明文；
• 应用日志（/logs/app.log）含用户手机号、token—— 明文；
• K8s 配置（/config/deploy.yaml）含数据库密码 —— 明文；
• 数据湖中的 Parquet/CSV 文件 —— 明文。

讽刺的是：我们花大价钱保护 “结构化数据”，却把 “非结构化数据” 当作 “不重要资产”—— 直到它们被偷走，才发现价值更高。

---

三、第二阶段：“文件系统层 TDE”—— 真正的 “全盘加密”

要同时保护结构化与非结构化数据，必须下沉到存储层。

这就是 TDE 透明加密（Transparent Data Encryption）的真正价值：在文件系统或块设备层自动加解密，对上层应用完全透明，无论数据是 SQL 表还是 AI 模型，一视同仁加密。

TDE 如何工作？（架构图）

[应用] → 读写 /data/user.db 或 /models/vision.pt
     ↓
[Linux文件系统] → ext4 / xfs / ZFS
     ↓
【TDE加密模块】 ←─ 关键！在此自动加解密
     ↓
[本地磁盘 / 云盘 / NAS] ←─ 存储的全是密文

全程无感

• 应用代码一行不改；
• GPU 照样加载加密模型（解密在内存）；
• 备份、快照自动继承加密状态；
• 性能损耗 < 3%（AES-NI 硬件加速）。

为什么文件系统层 TDE 能覆盖所有数据？

因为所有数据最终都以 “文件” 形式落盘：

• 数据库：.ibd、.mdf、.db 文件；
• AI 模型：.pt、.onnx、.pb 文件；
• 日志：.log、.jsonl 文件；
• 配置：.yaml、.properties 文件；
• 文档：.pdf、.docx 文件。

只要 TDE 作用于整个挂载点（如/data），所有写入该目录的文件，自动加密。

这才是 “全量存储加密” 的正确姿势。

---

四、真实挑战：TDE 落地的三大难题

难题 1：如何兼顾性能与安全？

• AI 训练需高频读写大模型文件；
• 日志系统每秒写入 GB 级数据；
• 加密会不会拖慢 IO？

解法：

• 启用 CPU 的 AES-NI 指令集，硬件加速加解密；
• 采用国密 SM4（性能优于 AES-256）；
• 实测：在 Intel Ice Lake CPU 上，SM4 加密吞吐达 8 GB/s，远超 NVMe SSD 速度。

难题 2：密钥如何安全管理？

• 密钥不能写在配置文件里；
• 不能由运维手动输入；
• 需支持自动轮换、审计、灾备。

解法：三层密钥体系 + 客户自持

[客户主密钥 MK] ←─ 存于HSM或客户KMS（如安当KMS）
     │
     ▼
[数据加密密钥 DEK] ←─ 用于加密文件，由MK加密后存储
     │
     ▼
[所有文件数据] ←─ 用DEK加密，落盘为密文

• 云平台 / 运维人员无法接触 MK；
• 即使服务器被控，也无法解密数据；
• 满足等保 2.0 “密钥客户自管” 要求。

难题 3：如何与现有架构集成？

• 是否支持云环境（阿里云 ECS、AWS EC2）？
• 是否兼容 NAS、SAN、本地盘？
• 是否影响 K8s、Docker？

解法：

• TDE 以内核模块或 eBPF 程序形式部署，与存储介质解耦；
• 支持挂载任意目录（/data、/models、/logs）；
• K8s 中通过 CSI Driver 或 Init Container 注入 TDE 策略。

---

五、某 AI 制药公司实践：从 “数据库加密” 到 “全盘可信”

背景

• 核心资产：基因数据库（结构化） + 药物分子模型（非结构化）；
• 原方案：仅 MySQL 开启 TDE；
• 风险：模型文件、训练日志、实验报告均为明文。

他们的 TDE 升级路径

阶段 1（2022）：数据库 TDE

• MySQL InnoDB Tablespace Encryption；
• 通过等保基础项。

阶段 2（2023）：文件系统 TDE 试点

• 在 GPU 训练服务器部署 TDE 代理；
• 加密目录：/models、/datasets、/logs；
• 使用国密 SM4 算法，性能无感。

阶段 3（2024）：全盘统一治理

• 部署 TDE 透明加密平台，实现：
  • 统一策略：所有 ECS、NAS 挂载点自动加密；
  • 密钥自管：MK 存于本地 HSM，云平台不可见；
  • 自动轮换：DEK 每 90 天轮换，MK 每年轮换；
  • 审计对接：记录所有加解密操作，满足 GDPR。

成果

• 结构化与非结构化数据 100% 落盘加密；
• 一次拦截内部人员尝试拷贝模型文件（因无法解密失败）；
• 顺利通过 FDA 数据安全审计；
• 为跨境数据传输提供 “技术不可见” 证明。

老赵后来总结：“以前我们只给‘金库’上锁，现在连‘仓库’‘办公室’‘垃圾桶’都加密了 —— 因为贼不知道哪里藏着宝贝。”

---

六、TDE vs 其他加密方案：一张表说清区别

方案	适用数据	应用改造	性能影响	覆盖范围	密钥可控
数据库 TDE（如 MySQL）	仅结构化	无需	低	仅数据库文件	部分（依赖云 KMS）
应用层加密（如 Jasypt）	任意	需大量改造	高	仅指定字段	客户可控
磁盘全盘加密（如 LUKS）	全盘	无需	低	整个磁盘	客户可控
文件系统 TDE	结构化 + 非结构化	无需	极低	按目录灵活	客户完全可控

结论：

• 如果只需保护数据库 → 用数据库 TDE；
• 如果需保护所有落盘数据 → 用文件系统层 TDE。

---

七、自研 TDE？还是用成熟方案？

很多技术团队想：“不就是个加密文件系统？我们用 eCryptfs 或 fscrypt 就行。”

但现实很骨感：

• eCryptfs 性能差，不支持大文件；
• fscrypt 需 Linux 4.1+，且密钥管理复杂；
• 无国密支持，过不了等保；
• 无审计、轮换、灾备能力；
• 一旦内核升级，模块崩溃，数据无法访问。

建议：

• 如果是 POC 或测试环境，可用 fscrypt；
• 如果是生产环境、强监管行业 —— 采用成熟 TDE 平台。

在上海，推出的TDE 透明加密系统，已支持：

• 国密 SM4/AES-256 双算法；
• 无缝兼容本地盘、云盘、NAS；
• 支持 K8s、Docker、VM 全场景；
• 提供客户自管密钥（BYOK）、自动轮换、等保合规模板；
• 已在 AI、制药、金融、政务落地。

不是所有 “加密” 都叫 “透明”—— 关键看应用是否无感、运维是否可控。

---

八、未来：存储加密，是数据主权的基石

随着《数据安全法》《个人信息保护法》落地，“数据落盘即加密” 将成为企业标配。

未来的 TDE 将不止于 “加密”，而是演进为：

• 动态数据保护：敏感文件自动加密，普通文件可选；
• 与 DLP 联动：检测到身份证号写入日志，自动触发加密；
• 云边端统一：无论数据在云、在边、在端，策略一致。

而这一切的起点，是把加密从 “数据库专属” 变成 “存储通用能力”。

---

九、写在最后：安全不能 “挑着保”

回到开头的问题：“数据库加密了，但 AI 模型还在裸奔”—— 为什么？

因为我们误以为 “重要数据 = 结构化数据”，却忽略了：

• 一个 AI 模型 = 数千小时训练 + 百万级标注数据；
• 一份日志 = 内部架构 + 用户行为 + 访问凭证；
• 一个配置文件 = 数据库密码 + API 密钥 + 网络拓扑。

真正的存储安全，不在于加密算法多强，而在于：

• 是否覆盖所有数据类型？
• 是否对应用透明？
• 密钥是否客户自持？
• 是否可审计可治理？

如果这些没做到，那么 “数据加密”，不过是给金库上锁，却把钥匙放在门口。

而聪明的企业已经行动：用 TDE 透明加密，让每一块落盘的数据，都穿上 “隐形盔甲”。

毕竟，在数字时代，你的数据，无论长什么样，都值得被认真保护。

文章作者：五台