MongoDB TDE 必须使用外部 KMS 托管主密钥，keyFile 仅用于节点认证，不支持 TDE；生产环境需对接云 KMS 或 HashiCorp Vault；本地测试可用 Atlas 或 mock 服务，但不可导出密钥到文件。
MongoDB 官方不支持使用本地 keyFile 管理 TDE 主密钥 —— 这是常见误解的源头。TDE 要求密钥由可信外部服务（如 KMS）托管，keyFile 仅用于副本集/分片集群节点间认证，与数据加密无关。
为什么不能用 keyFile 配置 TDE
MongoDB 的 TDE 实现强制依赖密钥管理服务（KMS），其设计逻辑是：主密钥（Master Key）必须由 KMS 生成、存储和轮换，数据库仅持有加密后的 DEK（Data Encryption Key）。keyFile 是纯文本或简单 base64 编码的共享密钥，无生命周期管理、无审计能力、无 HSM 支持，完全不满足 TDE 对密钥安全等级的要求。
尝试在配置中混用会导致启动失败，典型错误是：Failed to initialize encryption provider: key management service not configured。
常见误操作包括：
- 把
keyFile路径填进security.encryption.keyVault配置项 - 在
mongod.conf中同时启用authorization: true和自定义encryption块但未配 KMS - 期望通过
openssl rand -base64 32生成密钥后手动写入文件并“挂载”为 TDE 密钥
真正可用的 TDE 密钥管理路径
生产环境唯一受支持的方式是对接云厂商 KMS 或自建兼容 KMS API 的服务（如 HashiCorp Vault + MongoDB 插件）。以阿里云为例，需确保：
- 实例版本 ≥
4.4（云盘版）或 ≥4.0（本地盘版），且为副本集/分片集群架构 - 账号已开通阿里云 KMS，并完成
MongoDB_QCSLinkedRoleInKMS角色授权 - 在控制台开启 TDE 时，选择「使用 KMS 托管密钥」而非「自动创建」——后者虽省事，但密钥所有权归属云厂商，不满足等保三级或金融合规中「密钥自主可控」要求
配置片段示意（mongod.conf）：
security:
encryption:
keyVaultNamespace: "admin.datakeys"
kmsProviders:
kms:
endpoint: "https://kms.cn-shanghai.aliyuncs.com"
accessKeyId: "your-access-key-id"
secretAccessKey: "your-secret-access-key"
注意：accessKeyId 和 secretAccessKey 必须具备 KMS Decrypt 和 GenerateDataKey 权限，且不能硬编码在配置中，应通过环境变量或 IAM Role 注入。
本地开发测试的折中方案
若仅需验证应用兼容性（非生产），可使用 MongoDB Atlas 或本地 Docker 模拟 KMS 接口：
- Atlas 用户无需任何配置，TDE 默认启用，密钥由 Atlas 自动托管
- 本地部署可运行
mongocryptd+ Mock KMS 服务（如mongodb/mongocryptd-test-server镜像），但该方式不产生真实加密效果，仅用于驱动层握手测试 - 绝对禁止在测试中把 KMS 密钥导出为文件再读取 —— 这直接破坏密钥隔离原则，且 MongoDB 驱动会拒绝加载非 KMS 签名的密钥文档
一个容易被忽略的细节：keyVaultNamespace 必须存在于目标数据库中，且集合需启用加密（通过 createCollection 指定 encryptedFields），否则首次写入加密数据时会报 KeyNotFound 错误。
TDE 的密钥不在数据库内、不在配置里、也不在磁盘文件中 —— 它只活在 KMS 的安全边界里。任何试图绕过 KMS、用本地文件替代的方案，本质都是在关闭 TDE，而不是启用它。
