如何实现MongoDB的透明数据加密(TDE)?使用本地Key文件管理主密钥

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，而不是启用它。