前面讲了性能、高可用、分片，这些都是「让系统好用」。但还有一块同样重要——安全。一个没有鉴权的 MongoDB 暴露在公网上，可能几小时内就被拖库，这类事故屡见不鲜。安全不是可选的附加项，而是生产部署的底线。
这一篇讲 MongoDB 的安全四道防线：认证、授权、传输加密、字段级加密，从外到内逐层防护。
先把机制边界说清楚
MongoDB 的安全防护分四层，每层防不同的威胁：
- 认证（Authentication）：验证「谁能连进来」，防未授权访问。
- 授权（Authorization）：控制「能做什么操作」，防越权。
- 传输加密（TLS）：加密网络传输，防窃听和中间人。
- 字段级加密：加密数据本身，即使库被拖也是密文。
这四层是叠加的，缺一层都留下对应漏洞。比如开了认证但没 TLS，密码可能在传输中被截获；开了 TLS 但应用用 root 权限，一个 SQL 注入就能删库。
安全：四道防线
① 认证。验证连接者的身份。MongoDB 默认支持 SCRAM（基于用户名密码的挑战-响应机制），也支持 x.509 证书、LDAP、Kerberos。生产必须开启认证（--auth），绝不能用默认的无密码模式。认证回答「你是谁」，是第一道门。
最常见的坑是上线时为了方便关掉认证，后来忘记开。或者用弱密码。认证是安全的地基，必须从第一天就配置好。
② 授权。控制认证通过的用户能做什么。MongoDB 用基于角色的访问控制（RBAC）：给用户分配角色，角色定义了能对哪些资源做哪些操作。内置角色如 read（只读）、readWrite（读写）、dbAdmin（库管理），也可以自定义细粒度角色。
授权的核心原则是最小权限：应用用专属账号，只给业务需要的最小权限（通常 readWrite 某个库），绝不用 root 或 dbOwner。一个只需要读的应用，给它 readWrite 就是多余权限，一旦应用被攻破，攻击者能改数据。
③ 传输加密（TLS）。加密客户端到 mongod、节点间的网络通信。没有 TLS，密码和数据在传输中是明文，可被窃听或中间人篡改。生产环境必须全链路 TLS：客户端到服务端、复制集节点间、分片集群组件间都要加密。证书要定期轮换。
④ 字段级加密。这是最深层防护——加密数据本身。MongoDB 支持 CSFLE（Client-Side Field Level Encryption），在客户端把敏感字段（身份证号、手机号）加密后存入数据库，数据库里存的是密文，连 DBA 都看不到明文。应用读取时在客户端解密。
7.x 引入的 Queryable Encryption 更进一步——加密的字段还能查询（之前加密后无法查询）。这让敏感数据可以既加密又可查，适合强合规场景。
字段级加密的价值是「纵深防御」：即使数据库被拖库，敏感字段也是密文，攻击者拿不到明文。它不能替代前三道防线，但作为最后一层，能极大降低数据泄漏的损失。
安全实践要点
把四道防线落地成具体实践：
认证：生产 --auth 必开，用强密码或证书认证，别用默认 admin/admin。复制集成员间也要认证（keyFile 或 x.509）。
授权：每个应用一个专属账号，最小权限角色（业务库 readWrite 够了）。管理操作用单独的管理员账号，平时不用。定期审计用户和角色，清理多余权限。
TLS：全链路加密，证书定期轮换。内网通信也要加密（不要觉得内网就安全）。
字段级加密：身份证、手机号、银行卡等强敏感字段用 CSFLE 加密。密钥管理用专门的 KMS，不要把密钥和应用放一起。
审计日志：开启 auditLog，记录关键操作（谁在什么时候做了什么），合规场景必备。审计日志要安全存储，防止被篡改。
网络隔离：MongoDB 不直接暴露公网，放在内网/VPC，只让应用访问。防火墙/安全组限制访问来源。
判断框架
- 四道防线叠加：认证 + 授权 + TLS + 字段加密，缺一不可。
- 生产必须开认证，绝不用无密码默认模式。
- 最小权限：应用专属账号，不给多余权限。
- 全链路 TLS，内网也要加密。
- 敏感字段用 CSFLE 加密，库泄漏也是密文。
- 审计日志 + 网络隔离是补充手段。
- 安全从第一天就配好，别「先跑起来再说」。
下一篇讲数据中台架构，看 MongoDB 在系统里的位置。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会按运维和架构选型这条线更新。
