1. 为什么 MongoDB 常常成为数据泄露的主角1.1 MongoDB 的默认配置思路与安全盲区很多人第一次接触 MongoDB第一反应是“这数据库用起来真爽”不用建表、不用写 SQL、字段随便加、开发迭代快。但正是这种“快”埋下了一个非常大的隐患MongoDB 默认安装完之后几乎是不设防的。我第一次在生产环境排查 MongoDB 安全问题是在一个朋友的创业公司。他们用 MongoDB 存用户订单和手机号开发的时候图省事一直用默认配置跑结果某天早上起来发现数据库里的数据被删光了留下一张勒索提示表。原因很简单MongoDB 默认监听 0.0.0.0默认不开启认证默认端口 27017 直接暴露在公网。这三个“默认”叠加起来就等于把自己的数据裸奔在互联网上任何一个扫描器扫到 27017 端口连上来就是管理员权限。这里要理解 MongoDB 的设计初衷它诞生于开发者本地环境默认配置优先服务“快速上手”而不是“安全上线”。它不像 MySQL 在安装过程中会强制你设置 root 密码MongoDB 早期版本甚至允许你在完全没有认证的情况下创建数据库。虽然 3.0 之后逐渐改进了安全机制但只要你不主动开启 authorization它依然默认信任所有连接。所以MongoDB 的安全问题本质上不是这个数据库本身有多脆弱而是它的默认配置和大部分使用者的安全意识之间存在巨大的落差。如果你只是本地开发无所谓但一旦涉及公网、生产环境、敏感数据第一件要做的事情就是彻底扭转这套“默认配置思维”。1.2 真实案例里的常见攻击路径我梳理过不少 MongoDB 被攻破的案例攻击路径惊人地一致基本就是下面这几步第一步扫描公网 IP 的 27017 端口。这一步完全自动化攻击者使用 Masscan、Zmap 这类工具可以在几小时内扫遍全网 IPv4 地址段。第二步尝试直接连接。如果目标 MongoDB 没开认证攻击者用 MongoDB Compass 或者命令行客户端连上去输入show dbs看到什么拿什么。第三步拖库或擦库。有的攻击者是为了窃取数据把用户表、订单表全部导出有的更狠直接db.dropDatabase()然后留下一封勒索信要求支付比特币赎回数据。第四步如果是开了认证但密码很弱攻击者会用常见密码字典暴力破解。admin、123456、root 这类密码在暴力破解面前基本撑不过几秒。这里面有一个容易被忽略的细节很多人以为“只要服务器在防火墙后面就没事”但真实环境里云服务器的安全组、IDC 的防火墙规则常常配置错误。比如安全组里为了图省事把 0.0.0.0/0 加入了入站规则再比如 MongoDB 的bindIp配置写成了 0.0.0.0以为防火墙能挡住结果运维调整网络策略时把端口放开了数据库直接暴露。还有一类路径是通过应用层打进来的。比如你的 Web 应用存在 NoSQL 注入攻击者不需要直接连数据库而是通过应用接口间接操作 MongoDB。这种情况即使数据库本身不对外暴露同样会出问题。理解了这些攻击路径你就明白 MongoDB 安全加固不是单点操作而是从网络、认证、授权、加密、运维五个维度同时下手。下面我一个个拆开讲。2. 搭建 MongoDB 的第一道防线访问控制与身份认证2.1 启用认证前必须做的事情很多人一上来就改配置文件把authorization: enabled加上觉得这样就安全了。这是一个非常危险的误区如果你在没有任何用户的情况下直接开启认证MongoDB 会拒绝所有连接包括你自己。因为 MongoDB 开启认证后需要有一个存在于admin库中的用户才能登录。正确顺序是这样的第一步先以不带认证的方式启动 MongoDB或者通过本地 Unix Socket 连接如果配置允许。第二步连接到admin库创建第一个管理员用户。这个用户需要拥有root角色或者userAdminAnyDatabase角色。第三步关闭 MongoDB修改配置文件加入security.authorization: enabled。第四步重启 MongoDB用刚才创建的管理员账号登录验证。我在实际操作中发现很多人卡在第二步创建管理员的命令写错了。下面这个命令是标准的创建方式use admin db.createUser({ user: admin, pwd: 这里用一个足够复杂的高强度密码, roles: [ { role: root, db: admin } ] })2.2 创建管理员账号和普通业务账号的正确姿势管理员账号和业务账号必须分开这是 MongoDB 权限设计的核心原则。管理员账号负责日常维护、用户管理、备份恢复业务账号只给应用连接使用权限精确到某个库的读写。千万不要让业务代码直接使用 root 账号连接数据库这是我在审计中见过最多的问题。一旦业务代码被注入或者配置泄露攻击者拿到的就是整个数据库的最高权限。比较合理的账号规划是这样的adminroot 角色仅限 DBA 使用backupbackup 角色负责 mongodump 和 mongorestoreapp_userreadWrite 角色限定在业务库比如mydbmonitorclusterMonitor 角色用于监控工具创建业务账号的命令示例use mydb db.createUser({ user: app_user, pwd: 独立的复杂密码, roles: [ { role: readWrite, db: mydb } ] })这里有个细节MongoDB 的角色作用域是“库级”的。如果你给app_user授予的是mydb的readWrite那它只能操作mydb里的集合连别的库的find都执行不了。这种最小权限原则能在应用被入侵后把数据泄露范围限制在一个库里。2.3 配置文件里容易踩的坑MongoDB 的配置文件是 YAML 格式缩进非常敏感。很多人改完配置后 MongoDB 启动失败多半是缩进问题。security和authorization的层级关系是security: authorization: enabled注意authorization前面必须有两个空格而且security顶格写。如果写在net或storage下面配置不生效或者直接报错。还有一个坑是如果你用的是 MongoDB 4.0 之前的版本部分配置项名称不一样。老的配置文件里用auth true这种参数新版本里要用security.authorization: enabled。升级版本后配置文件不更新安全配置就悄悄失效了。开启认证后验证是否生效的方法很简单不带用户名密码连接一次如果返回Unauthorized说明认证已经生效如果还能自由操作说明配置没加载或者顺序错了。这个验证动作我建议每台新部署的服务器都做一遍。3. 网络层与权限层让数据库彻底“隐身”3.1 绑定 IP 与端口暴露评估MongoDB 默认监听0.0.0.0这意味着所有网卡上的请求都会响应。正确的做法是在配置文件中把bindIp改成实际需要的地址。如果是单机部署业务应用和数据库在同一台服务器上直接绑定127.0.0.1就足够了net: port: 27017 bindIp: 127.0.0.1如果是分离部署应用服务器和数据库服务器在不同的机器上绑定的 IP 应该是应用服务器的内网 IP而不是0.0.0.0net: port: 27017 bindIp: 192.168.1.10这里 192.168.1.10 是 MongoDB 服务器自己的内网 IP。还有一个容易被忽略的点修改bindIp后必须重启 MongoDB 才能生效。我在实践中见过有人改完配置不重启然后奇怪“为什么外面还能连”其实配置根本没加载。建议你在部署完 MongoDB 后用ss -lntp | grep 27017检查一下端口监听地址。如果显示0.0.0.0:27017说明还在裸奔如果显示127.0.0.1:27017或具体内网 IP说明绑定成功了。3.2 RBAC 授权模型的最小权限实践MongoDB 内置了一套基于角色的访问控制模型内置角色大致分为几类数据库用户角色read、readWrite、数据库管理角色dbAdmin、dbOwner、userAdmin、集群管理角色clusterAdmin、clusterMonitor、备份恢复角色backup、restore、超级角色root。最小权限实践的核心就一句话每个账号只给它完成任务所必需的最小权限。比如一个只负责查询报表的账号给read就够了不要顺手给readWrite一个只做备份的账号给backup角色就够了不要给root。我见过一个反面案例某公司的数据分析师账号因为图省事直接复制了 DBA 的配置带着root角色。后来这个分析师误执行了db.dropDatabase()直接把一个月的业务数据清空了。要是当初只给read这个悲剧根本不会发生。MongoDB 还支持自定义角色你可以把一组精确的权限组合起来。比如创建一个“只允许读写指定集合”的角色use mydb db.createRole({ role: app_readwrite_orders, privileges: [ { resource: { db: mydb, collection: orders }, actions: [find, insert, update, remove] } ], roles: [] })这种自定义角色特别适合微服务架构每个服务一个专用账号一个账号只能操作自己的集合彼此隔离。3.3 云安全组与本地防火墙的协同配置光靠 MongoDB 自身的 bindIp 还不够云服务器的安全组和操作系统防火墙也要同步收紧。很多人以为两者是一回事其实它们分别工作在虚拟网络层和主机网络层任何一个环节漏了都有可能出问题。建议的配置顺序是在云控制台的安全组中删掉所有来源为0.0.0.0/0的 27017 入站规则只允许来自特定内网 IP 或安全组的流量访问 27017在 MongoDB 服务器上配置 ufw 或 firewalld同样只放行指定来源比如使用 ufw 时的配置sudo ufw default deny incoming sudo ufw allow from 192.168.1.20 to any port 27017 proto tcp sudo ufw enable实际业务中我更推荐通过云安全组控制跨服务器的访问用操作系统防火墙做兜底。两者配置保持一致能有效避免“安全组规则被人误改后数据库直接暴露”的情况。这里分享一个检查方法找一台不在白名单里的机器尝试用nc -vz MongoDB服务器IP 27017或telnet测试端口连通性。如果连不通说明网络层过滤生效了如果还能连通说明规则还没生效需要立即排查。4. 数据加密静态加密与传输加密的落地细节4.1 TLS 传输加密的配置流程默认情况下MongoDB 客户端和服务器之间的数据传输是明文。这意味着只要有人能在网络链路上抓包就能看到你的查询语句和返回的数据。对于合规要求严格的业务传输加密是必须的。MongoDB 官方推荐使用 TLS/SSL 加密传输。配置 TLS 需要一套证书体系最简单的方案是使用自签名证书但客户端连接时要做证书校验麻烦一点生产环境我建议使用内部 CA 签发的证书。服务端配置在 mongod.conf 里加net: tls: mode: requireTLS certificateKeyFile: /etc/mongodb/server.pem CAFile: /etc/mongodb/ca.crt这里certificateKeyFile是 PEM 格式的证书和私钥合并文件CAFile是 CA 证书。证书和私钥的合并命令cat server.crt server.key server.pem chmod 644 /etc/mongodb/server.pem客户端连接时需要指定 CA 文件mongosh --host 192.168.1.10 --port 27017 --tls --tlsCAFile /etc/mongodb/ca.crt一个常见的坑开启 TLS 后MongoDB Compass、mongosh、备份工具、监控代理都需要同步配置 TLS 参数否则全部连不上。如果某个工具不支持 TLS你就需要做额外的反向代理或者升级工具版本。4.2 静态加密的两种实施路径静态加密指的是数据落到磁盘后是加密状态的即使有人把数据库文件拷走也无法直接读取。MongoDB 的静态加密没有像 MySQL 的 TDE 那么普及但依然有两条主要路径。路径一使用 MongoDB Enterprise 版的 Encrypted Storage Engine。这个功能基于 AES-256-CBC 或 AES-256-GCM 算法加密密钥存放在独立的密钥管理服务中。配置好后数据文件、日志、索引都会被加密。缺点是Enterprise 版是商业授权开源自部署用户用不了。路径二使用操作系统层面的全盘加密或文件系统加密。Linux 下可以用 LUKS 对磁盘做加密或者在 MongoDB 数据目录上挂载加密文件系统比如 eCryptfs。这种方式对 MongoDB 本身透明无论你用的是 Community 版还是 Enterprise 版都能享受静态加密的好处。从实际落地来看中小团队用 LUKS 加密整个数据盘性价比最高。你只需要在创建数据盘时设置 LUKS 密码然后挂载到/data/mongodb目录MongoDB 写文件时系统会自动加密读文件时自动解密业务无感知。但是要记住静态加密只能防“物理偷盘”防不了“逻辑攻击”。如果攻击者通过认证漏洞直接发了删除命令加密盘也一样会被删。所以静态加密是安全体系的一部分不能替代访问控制和备份。4.3 密钥管理与备份恢复的注意事项做加密最怕的不是加密本身而是密钥管理。密钥丢了数据就永远解不开了密钥泄露加密形同虚设。如果你是自建环境我建议把密钥和数据库服务器分开存放比如放在独立的密钥服务器或硬件密码机上。密钥的轮换周期至少每半年一次数据库服务器的磁盘故障后如果密钥是存在本地磁盘上的换盘后要确保密钥还在否则数据无法恢复。再说备份恢复。很多团队做了备份但没做“加密的备份”。mongodump 导出的文件是明文 BSON 数据如果备份文件存储位置不安全泄露风险和数据库直接泄露是一样的。更合理的做法是mongodump 导出后用 gpg 或者 openssl 对备份文件做加密再传到异地存储。恢复的时候先解密再 mongorestore。我把这个加密命令放在这里参考mongodump --urimongodb://backup:密码127.0.0.1:27017/mydb --out/backup/mongodb-$(date %F) tar czf /backup/mongodb-$(date %F).tar.gz -C /backup mongodb-$(date %F) gpg --output /backup/mongodb-$(date %F).tar.gz.gpg --symmetric --cipher-algo AES256 /backup/mongodb-$(date %F).tar.gz rm -rf /backup/mongodb-$(date %F) /backup/mongodb-$(date %F).tar.gz备份文件的恢复演练也很关键。我见过不止一次备份脚本跑了半年真到要恢复的时候才发现 mongodump 的版本和 MongoDB 服务端版本不一致导致恢复失败。所以建议每季度做一次“备份恢复演练”把备份文件恢复到一台测试机上验证数据完整性和可用性。5. 日常运维中的安全监控与漏洞管理5.1 安全相关的日志审计MongoDB 的日志默认输出到 stdout 或者指定的 logpath。对于安全审计我们需要的是“可查询的操作日志”而不仅仅是运行日志。如果你开启了审计功能MongoDB 可以记录谁在什么时间执行了什么命令。审计日志非常有用能帮你追溯异常操作。配置文件里加auditLog: destination: file format: JSON path: /var/log/mongodb/audit.log在生产环境我建议把审计日志单独存放在独立的日志盘避免和数据盘混淆。同时配置 logrotate 做日志轮转否则审计日志会越来越大最终把磁盘撑爆。查看审计日志时重点关注几类操作dropDatabase、dropCollection、remove、update、用户创建和权限变更。这些操作都属于高敏感操作正常情况下应该非常少见。如果审计日志里出现大量drop或remove多半是有问题发生了。另外MongoDB 4.4 之后审计日志的filter功能更强大可以只记录特定用户或特定操作的日志减少日志量和噪声。这对高并发环境的性能开销控制很有帮助。5.2 常见的 MongoDB 安全扫描检查项我每隔一段时间就会对 MongoDB 服务器做一次“自扫描”类似给数据库做一次体检。分享几个我觉得最实用的检查项。第一个是认证状态检查。直接尝试通过mongosh不带账号密码连接如果连接成功且可以执行show dbs说明认证未启用或配置错误。第二个是空密码和弱密码检查。列出所有用户看看有没有空密码或明显弱密码的用户。MongoDB 本身不会强制检查密码强度只能通过自己排查。第三个是权限过大检查。逐个查看账号的角色分配情况标记出拥有root、dbOwner、userAdminAnyDatabase的账号确认这些账号确实是管理员在用的而不是业务账号。第四个是网络暴露检查。用ss -lntp检查 27017 的监听地址用外部工具扫描公网端口确认是否暴露。这一步建议定期做因为云安全组规则经常会被团队成员“顺手”修改。第五个是版本漏洞检查。到 MongoDB 官网查看当前版本是否存在安全公告并对照补丁情况。长期不升级的 MongoDB 3.x、4.x 版本往往是已知漏洞的重灾区。5.3 版本升级与补丁更新的节奏MongoDB 的版本升级是一个需要慎重操作的事因为大版本升级往往伴随着行为和 API 的变化。但如果你因为害怕升级就一直停留在老版本安全风险会随着时间越积越大。我的建议是不要追求最新版本但不要落后超过两个大版本。比如当前最新稳定版到了 6.x那么至少要把生产环境升级到 4.4 或 5.0还在跑 3.x 的话应该尽快安排升级计划。升级前的准备工作至少包含三步翻看官方 Release Notes确认新增的特性和破坏性变更在测试环境完整跑一遍业务回归测试做好升级前的全量备份升级的具体操作不建议直接替换二进制文件而是使用 MongoDB 官方的滚动升级或停机升级流程。如果是单机环境最简单的做法是# 备份数据 mongodump --urimongodb://admin:密码127.0.0.1:27017 --out/backup/mongodb-before-upgrade # 停止服务 sudo systemctl stop mongod # 备份旧版本配置文件 sudo cp /etc/mongod.conf /etc/mongod.conf.bak # 更新软件包 # Debian/Ubuntu sudo apt update sudo apt install -y mongodb-org # RPM/CentOS sudo yum install -y mongodb-org升级完成后先检查日志有没有报错再跑一遍核心业务功能。如果一切正常再逐步放开流量。这里要特别提醒跨大版本升级时不要跳版本。比如 4.0 直接升 6.0 可能会出现兼容性问题正确的路线是 4.0 → 4.2 → 4.4 → 5.0 → 6.0每个大版本都验证一次。6. 从一次“数据被删”模拟看 MongoDB 安全加固全流程6.1 模拟场景复盘假设你有一台云服务器上面跑着 MongoDB业务方反馈连不上数据库。你登录服务器发现 MongoDB 还在运行但执行show dbs时提示没有权限用管理员账号登录后发现原来的业务库不见了只剩一个名为READ_ME_TO_RECOVER的数据库里面有一封勒索信。这个场景在安全圈已经屡见不鲜。下面复盘一下真实发生过的处理过程以及每一步的正确应对方式。第一步断开外网访问。立即在云安全组中把所有入站规则设为拒绝防止攻击者继续操作或数据被二次拖走。第二步保留现场。不要马上重启 MongoDB也不要急着删掉勒索数据库。先把 mongod 进程的数据目录完整复制一份作为后续应急分析和溯源的基础。第三步排查入口。查看 MongoDB 的日志和审计日志确认攻击者是从哪个 IP、什么时间、用什么方式进来的。如果日志还在通常能看到Unauthorized和大量失败尝试如果日志显示直接连接成功且没有认证失败记录大概率是认证没开。第四步恢复数据。从备份中恢复数据前提是你之前做了备份且备份是完整的。没有备份的话找专业数据恢复团队尝试用工具扫描磁盘但能够恢复的概率不高。第五步安全加固。按照我前面说的方式把所有配置重新加固一遍启用认证、绑定内网 IP、收紧防火墙、开启审核日志、做备份加密。6.2 加固前后对比清单下面是我在完成加固后整理的一个检查清单你完全可以照着去验证自己的 MongoDB 环境。检查项目加固前加固后认证机制未启用连接即管理员security.authorization: enabled端口监听0.0.0.0:27017127.0.0.1 或内网 IP账号权限root 账号通用于业务业务账号精确到库级角色网络策略安全组放行 0.0.0.0/0仅白名单来源可访问数据传输明文传输TLS/SSL 加密静态存储数据文件明文落盘磁盘加密或文件系统加密备份文件明文 mongodump 文件加密后存储定期恢复演练审计日志未开启记录高危操作日志轮转这个清单不是一次性做完就结束了我建议至少每个季度复查一遍。尤其是云安全组规则和账号权限因为它们在生产环境的变动频率最高。6.3 几点亲身经验与后续扩展方向最后分享几个实操层面的体会。第一安全加固一定要在项目初期做不要等出事了再补。很多人觉得“项目还没上线不用着急”但 MongoDB 从开发环境搬到公网服务器的那一刻起就可能被扫描器盯上。我见过太多开发环境直接复用生产配置的例子这种“省事”最后都付出了代价。第二不要把密码写在代码里或者配置文件里明文保存。代码仓库一旦泄露数据库密码也跟着泄露。建议使用环境变量、密钥管理服务或者配置中心来管理连接字符串。第三备份不能只做一次要形成习惯。每周全量、每日增量是我比较推荐的节奏。备份文件放在和数据库不同的存储位置最好跨机房或跨云存储。第四关注 MongoDB 官方安全公告。很多已知漏洞都有公开的利用方式不及时修补等于给别人递刀子。第五团队内部要约定好安全操作的流程规范。比如谁有 root 权限、谁有权限修改安全组规则、操作前要不要走审批。这些流程虽然看起来麻烦但能防止“人为误操作”这类最普遍的安全问题。MongoDB 本身是一个优秀的数据库它的安全性很大程度取决于使用者怎么配置、怎么运维。先把基础的安全配置做好把认证、授权、网络、加密、备份这几道防线搭起来数据库被攻破的概率会大幅下降。这也是我在处理了多次安全事件后想对所有 MongoDB 使用者说的最核心的一句话。
