在不少在线实验环境里MongoDB 这套数据库安全实验是很多人的第一道坎前面增删改查跑得挺顺一到“开启认证”“建用户”“配角色”就开始卡壳报错信息还特别吝啬只有一句 Authentication failed让人摸不着头脑。这篇就把 MongoDB 数据库安全这件事从头到尾拆开讲一遍从认证开关的原理、SCRAM 密码存储机制、内置角色的选型逻辑到配置文件逐行拆解、最小权限落地、TLS 与内部认证、备份交接最后再给一份我自己踩坑攒出来的报错速查表。不管你是刚接触 MongoDB 的新手还是带过几届实验、想把这套东西讲透的老手下面这些内容都能直接拿去用。1. 这门实验在练什么先把“安全”拆成能动手的三件事1.1 为什么一上来就讲认证而不是继续讲增删改查很多人第一次做数据库安全实验时会有个疑问语法还没学全怎么就讲起权限了。这个顺序其实是对的。MongoDB 装完之后默认是完全开放的——监听本地回环、不开认证、任何人都能连上去建库删库。你在本地折腾当然无所谓但只要这台机器暴露在局域网里几分钟内就可能被扫到数据被清空、留下勒索信息的案例在圈内流传过不止一次。所以实验的第一课不是“怎么用”而是“怎么不让别人用”。从这个角度看安全实验的核心其实是三件事证明你是谁认证 Authentication、规定你能干什么授权 Authorization、限制你从哪儿来、路上安不安全网络与传输。这三件事在 MongoDB 里对应着完全不同的配置位置和命令混在一起学很容易乱。我建议在动手之前先在纸上把这三层画出来后面每配一个参数都知道自己落在哪一层上。还有一点值得说清楚MongoDB 的认证和授权是分开的两个开关security.authorization: enabled打开的是授权而认证是它的前置条件。这个概念混淆是新手最常见的误区之一——很多人以为开了这个开关就等于“加了密码”结果连上去发现还是能操作只是报错变成了“not authorized”一脸茫然。1.2 实验环境里真正要验收的三个结果抛开实验指导书上那些步骤编号一套 MongoDB 安全配置做完能用三个结果来验收自己到底有没有做对。第一个结果是未认证的连接不能执行任何数据操作随便敲一条db.users.find()应该被拒绝而不是返回空数组。第二个结果是不同账号看到的边界不一样业务账号只能碰自己那个库碰别的库应该直接报权限错误。第三个结果是管理员账号能管用户但读不到业务数据这一点最容易被忽略也是最能体现“最小权限”思想的地方。第三个结果值得多说两句。很多人的做法是建一个root角色的大号然后用这个号干所有事情。在实验环境里这样最省事但在真实项目里这是标准的反面教材——一旦这个账号的密码泄露攻击者拿到的是整个实例的控制权。合理的做法是至少拆成两个号一个只管用户和角色userAdminAnyDatabase一个管集群运维clusterAdmin业务库各自有独立的读写账号。这个拆分在实验里可能只值两分但在工程上能救命。至于操作系统的防火墙、云上的安全组、数据库前面的网关这些属于环境层面的东西实验里通常不会涉及但心里要有数MongoDB 自身的认证是最后一道门不是唯一一道门。1.3 动手前需要准备的环境清单实验环境一般会预装好 MongoDB但如果你打算在本地复现一遍需要准备的东西不多一个 Linux 或者 macOS 环境Windows 也能做路径写法略有差异、MongoDB 6.0 以上的版本、一个能改配置文件的权限、以及mongosh这个新版 shell。我强烈建议用mongosh而不是老的mongo因为 5.0 之后老 shell 已经被移除很多老教程里的命令在新版本上直接跑不通这也是新手最容易踩的第一个坑。配置文件的位置各家发行版不太一样常见的三个路径是/etc/mongod.conf、/etc/mongodb.conf、以及自己编译安装时的自定义路径。启动方式也分 systemd 管理的服务和手动mongod --config启动两种。我个人的习惯是手动启动参数看得见、日志打得直、出问题好排查实验阶段强烈推荐这种方式。还有一件事提前说改配置文件之前先备份一份。这不是客套话YAML 对缩进极其敏感一个 Tab 用错位置服务直接起不来而且报错信息往往指向别处能让人折腾半小时。备份一下两秒钟的事。2. 认证开关与配置文件从“谁都能连”到“凭证入场”2.1authorization: enabled到底改变了什么把这一行配置加进去、重启服务之后MongoDB 的内部行为会发生一个根本性变化每一条命令在执行前都会先检查当前连接的认证状态和角色权限。没认证的连接只能执行极少数命令比如ping、hello、buildInfo这类无害的握手命令任何涉及数据的操作都会被拦下来。这里有个非常关键的机制叫localhost exception本地回环例外当实例里一个用户都没有的时候从本机回环地址连进来的连接被允许创建第一个用户。这个设计的用意很实际——你不可能在没有用户的情况下先认证再建用户那是个死循环。但这个例外只在“零用户”状态下生效一旦你建了第一个用户它就永久关闭了。我在带人做实验时见过太多人栽在这一步配置里开了authorization: enabled重启然后发现自己连不上了也不知道怎么建第一个用户。原因往往是他们之前已经建过用户或者数据目录里残留了旧的admin.system.users。遇到这种情况最直接的办法是先把authorization改回disabled重启建好管理员再改回来。别硬扛。authorization的可选值其实有三个enabled、disabled以及 MongoDB 早期版本的enabled之外还有authentication之类的历史写法新版本统一用enabled就好。切值之后必须重启mongod不能热加载这一点和某些关系型数据库不一样。2.2mongod.conf逐段拆解与参数取舍配置文件不长但每一段都有它的道理。下面这份是我在实验和测试环境里用得最多的一份模板注释我写在旁边systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo journal: enabled: true net: port: 27017 bindIp: 127.0.0.1 security: authorization: enabledsystemLog这一段看着不起眼但它决定了你出问题时能不能看到线索。destination: file配上logAppend: true保证日志追加而不是覆盖排查认证失败时日志里会明确写出“Authentication failed”以及是哪个用户、哪个库、哪条命令触发的比客户端那句干巴巴的报错有用得多。storage.dbPath是数据目录注意权限——mongod进程的运行用户必须对这个目录有读写权限否则启动直接失败。很多人从别处拷贝了一份数据目录过来权限不对服务起不来还以为是配置写错了。net.port默认 27017实验里用默认值最省事。net.bindIp是重中之重默认只绑127.0.0.1意味着只有本机能连。如果你需要别的机器连进来得改成0.0.0.0或者具体的网卡 IP但这一步要格外谨慎——在开认证之前改 bindIp等于把大门敞开。正确顺序永远是先开认证、建好账号再放开监听地址。这个顺序搞反是安全事故的经典成因。security.authorization前面讲过了。这里补一句如果你还要做副本集security段里还得加keyFile或者clusterAuthMode这属于进阶内容第 4 节会展开。2.3 密码在库里长什么样SCRAM 机制拆解这部分很多人做实验时是跳过的但它恰恰是理解“为什么改了密码老连接还通”这类问题的钥匙。MongoDB 从 3.0 开始默认用 SCRAM 做认证4.0 之后同时支持 SCRAM-SHA-1 和 SCRAM-SHA-256 两种摘要算法。SCRAM 的核心思想是服务端不存明文密码也不存密码的简单哈希而是存一组可以验证客户端但无法反推密码的凭证。以 SCRAM-SHA-256 为例用户文档里存的是salt盐、iterationCount迭代次数MongoDB 默认 15000、storedKey和serverKey四个字段。认证时客户端和服务器通过一串挑战-响应的交互各自算出结果比对全程密码本身不落地、不传输。你可以用下面这个命令亲眼看看存的是什么use admin db.system.users.find({ user: dbAdmin }, { credentials: 1, roles: 1 })你会看到credentials里是一堆 base64 字符串看不到任何明文。这个认知很实用如果你在两台机器之间迁移用户直接拷贝system.users文档是可行的凭证可以复用但如果换了认证机制就得重新设密码。还有一个坑值得提前说同一个用户可以同时拥有 SCRAM-SHA-1 和 SCRAM-SHA-256 两套凭证这取决于创建用户时是否指定了mechanisms参数。老客户端只支持 SHA-1新客户端优先走 SHA-256混用环境里如果只保留了 SHA-256 凭证老驱动就会认证失败。排查“同样的密码一个工具能连一个不能连”时先往这个方向想。3. 用户与角色最小权限原则怎么落成具体命令3.1 内置角色速查与选型思路MongoDB 的内置角色有几十个全部背下来没必要但常用的那十来个必须心里有数。我把实验和日常运维里最常打交道的列在下面按“能干什么”而不是“叫什么”来记会更牢角色名作用域实际能干什么典型用途read单库只读该库所有集合报表、审计读取readWrite单库读写该库所有集合业务应用账号dbAdmin单库建索引、看统计、改集合选项库级运维userAdmin单库管理该库的用户与角色库级账号管理userAdminAnyDatabase全局管理所有库的用户管理员账号readAnyDatabase全局读所有库跨库分析clusterAdmin全局副本集、分片、节点管理集群运维root全局所有权限仅在完全可控环境使用选角色的第一个原则是能落到单库就不给全局。业务账号一律用readWrite绑在具体库上不要图省事给readWriteAnyDatabase。第二个原则是读写分离很多业务其实只需要读给个read就够了写权限应该是有明确需求才授予。第三个原则是管理权和数据权分离管用户的号不应该有读数据的权限这个分离在实验评分里不一定体现但在真实审计里是硬要求。还有两个容易被忽略的角色值得提一句backup和restore。做备份的账号只要这两个就够了不需要给它root。很多人配备份脚本时图省事直接用管理员账号脚本一旦泄露风险成倍放大。3.2 建管理员、建业务账号的完整实操创建一个具备用户管理能力的管理员命令本身很短但参数背后有讲究use admin db.createUser({ user: accountAdmin, pwd: Str0ng_Passw0rd#2024, roles: [ { role: userAdminAnyDatabase, db: admin }, { role: clusterMonitor, db: admin } ], mechanisms: [SCRAM-SHA-256] })几个细节。use admin必须写因为用户信息是跟着库走的admin库下的用户是全局可见的其他库的用户只在该库内有效。roles数组里的db字段也必须写虽然看着冗余但它是角色作用域的一部分。mechanisms指定只用 SHA-256 更安全前提是你的客户端都支持。业务账号的创建方式略有不同use appdb db.createUser({ user: app_rw, pwd: Another_Str0ng#2024, roles: [ { role: readWrite, db: appdb } ] })注意这里是先use appdb用户就建在appdb库里。这就引出一个必须记住的规则连接时要用--authenticationDatabase指定用户所在的库。如果app_rw建在appdb里你却在连接时指定authSourceadmin那必然认证失败而且报错信息不会告诉你原因。这是新手报错率最高的一条我在第 6 节会单独展开。改密码和删用户也很常用db.changeUserPassword(app_rw, New_Str0ng#2025) db.dropUser(app_rw)改完密码后已有的连接不会立刻失效这点和某些数据库不同要留意。3.3 自定义角色把权限切到集合级内置角色的粒度是“库”遇到更细的需求就得上自定义角色。比如某个服务只需要读orders这一个集合的find操作其他一概不给use appdb db.createRole({ role: readOrdersOnly, privileges: [ { resource: { db: appdb, collection: orders }, actions: [find] } ], roles: [] })privileges里的resource可以是具体的db collection也可以是{ db: appdb, collection: }表示整个库或者{ cluster: true }表示集群级资源。actions是最细的操作粒度常见的有find、insert、update、remove、createIndex、listCollections等。这里有个坑只给find是不够的客户端在查询前往往会先调listCollections或者listIndexes不给的话行为会显得很怪。我一般的做法是find加上listCollections一起给。角色建完之后挂到用户上db.grantRolesToUser(app_rw, [{ role: readOrdersOnly, db: appdb }])想撤销用db.revokeRolesFromUser()想查当前用户有啥用db.getUser(app_rw)。自定义角色的一个好处是可复用同一个角色可以挂到多个用户上权限调整时改角色就行不用一个个改用户这在账号多的环境里能省很多事。4. 网络与传输层加固连接从哪来、路上安不安全4.1bindIp与端口先把入口收窄认证解决的是“你是谁”但一个只监听内网地址的实例被攻击面本身就小了一大截。bindIp支持多个地址用逗号分隔net: bindIp: 127.0.0.1,10.0.0.21 port: 27017这样本机连得上内网某台固定机器也连得上其他来源一律连不进来。这比开0.0.0.0再靠防火墙兜底要稳妥因为防火墙规则可能被人手一抖改掉bindIp写在配置文件里更不容易误改。端口这块改默认 27017 到别的值能减少被自动化扫描命中的概率但这属于降低噪音不属于安全保障别把它当成主要手段。真正有效的还是认证加网络隔离。如果你的运维流程允许我建议把端口改成一个高位端口并且写进配置管理运维侧统一口径避免不同环境不一致带来的沟通成本。还有一个容易被忘的点MongoDB 除了主端口副本集和分片还会用到额外的通信端口。如果你只放开了 27017集群模式下的节点间通信会莫名其妙地失败排查起来很费时间。做实验时通常是单节点感受不到这个坑但心里要有数。4.2 传输加密与keyFile内部认证数据在网络上传的时候是明文还是密文由 TLS 决定。MongoDB 的 TLS 配置集中在net.tls段net: tls: mode: requireTLS certificateKeyFile: /etc/ssl/mongodb/server.pem CAFile: /etc/ssl/mongodb/ca.pem allowConnectionsWithoutCertificates: falsemode有三个值disabled、allowTLS、preferTLS、requireTLS生产环境直接用requireTLS逼着所有连接都走加密。certificateKeyFile是服务端证书加私钥的合并文件CAFile是签发证书的根证书。allowConnectionsWithoutCertificates设成false表示强制客户端也带证书这叫双向 TLS安全性最高但客户端配置成本也最高。实验环境里通常只做单向 TLS 就够了。证书的自签流程大致是先生成 CA 私钥和自签 CA 证书再用 CA 给服务端证书签名最后把服务端证书和私钥合并成一个 pem 文件。整个过程十几条命令细节容易出错的地方是证书的 CN 或 SAN 必须和客户端连接时用的主机名匹配不匹配的话会报证书校验失败而这个报错的字面意思往往看不出是名字对不上。keyFile是另一个层面的东西它是副本集成员之间互相认证用的共享密钥文件不是给客户端用的。生成方式很简单openssl rand -base64 756 /etc/mongodb/keyfile chmod 400 /etc/mongodb/keyfile权限必须是 400 或者 600宽了mongod会拒绝启动。然后配置里加security.keyFile: /etc/mongodb/keyfile。注意开了keyFile之后authorization会自动被启用不需要再单独写这一点很多人不知道会重复配置。4.3 副本集场景下的额外注意点单机实验很少涉及副本集但一旦涉及安全的复杂度是翻倍的。除了上面说的keyFile还要注意几件事成员的bindIp必须能让其他成员访问到每个成员的配置里replSetName必须一致初始化副本集时用的那个连接必须是已认证的以及rs.initiate()之后要等状态变成PRIMARY才能建库。有个很典型的实验场景三节点副本集keyFile配好了但某个节点一直起不来日志里报 “Bad key file”。原因几乎总是权限不对或者文件内容被编辑器加了换行。用openssl rand生成的是单行 base64如果手动拷贝时不小心折行了解析就失败。我一般的做法是生成后cat一遍确认是单行再chmod 400。另外副本集里创建用户只需要在主节点操作会自动同步到从节点。但如果主从切换了你用原来的连接串可能会连到新的主节点认证信息是一致的不影响使用只是要注意应用侧的连接串要写成副本集形式别写死单节点地址。5. 一次完整演练从裸库到带权限的可用环境5.1 环境准备与配置落地假设手上是一台干净的环境目标是搭一个“本地可连、开了认证、有独立业务账号”的实例。第一步先确认mongod的版本和配置文件路径mongod --version ls -l /etc/mongod.conf确认之后把配置文件改成下面这个样子以手动启动为例systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo net: port: 27017 bindIp: 127.0.0.1先不要加security.authorization先用无认证模式启动把管理员建出来。启动命令mongod --config /etc/mongod.conf --fork--fork让进程后台运行实验环境里方便。启动后用mongosh连上去验证一下确实是通的mongosh --host 127.0.0.1 --port 27017能进去说明基础配置没问题接下来才是安全部分。5.2 建库建用户与连接验证在无认证状态下用 localhost exception 建第一个管理员use admin db.createUser({ user: accountAdmin, pwd: Str0ng_Passw0rd#2024, roles: [{ role: userAdminAnyDatabase, db: admin }] })建完立刻验证一下能不能认证db.auth(accountAdmin, Str0ng_Passw0rd#2024)返回{ ok: 1 }就对了。这时候退出 shell改配置文件加上security.authorization: enabled重启mongod --config /etc/mongod.conf --shutdown mongod --config /etc/mongod.conf --fork重启后再连先试一个未认证的操作确认被拒绝mongosh --host 127.0.0.1 --port 27017进去后敲show dbs如果报 “command listDatabases requires authentication”说明认证开关生效了。然后带上账号连mongosh --host 127.0.0.1 --port 27017 \ -u accountAdmin -p Str0ng_Passw0rd#2024 \ --authenticationDatabase admin进去之后建业务库和业务账号use appdb db.createUser({ user: app_rw, pwd: Another_Str0ng#2024, roles: [{ role: readWrite, db: appdb }] })再单独测业务账号mongosh mongodb://app_rw:Another_Str0ng%232024127.0.0.1:27017/appdb?authSourceappdb注意密码里的#在 URI 里要转义成%23这是个非常常见的坑很多人复制粘贴后连接失败排查半天以为是账号问题其实是 URI 编码没处理。用-p参数传密码就没这个烦恼。最后做边界验证用app_rw去读admin库应该报 “not authorized on admin to execute command”。这一步过了说明最小权限真的生效了。5.3 备份恢复与账号交接安全做完了还得考虑数据怎么搬。带认证的实例做备份连接串里必须带上认证信息mongodump \ --urimongodb://backup_user:Backup_Pass%232024127.0.0.1:27017/?authSourceadmin \ --out/backup/20240601backup_user应该有backup角色restore用来恢复。恢复命令同理mongorestore \ --urimongodb://restore_user:Restore_Pass%232024127.0.0.1:27017/?authSourceadmin \ /backup/20240601这里有个细节mongodump默认只导数据不导用户要导用户得加--dumpDbUsersAndRoles。很多人在迁移时发现用户没了就是因为漏了这个参数。但反过来说不带用户导出反而是更安全的做法账号应该在新环境里重新创建避免把旧的凭证带过去。账号交接这件事在实验里体现不出来但工程上很重要。我一般的做法是给每个账号建一个“归属说明”写清楚谁申请的、给哪个服务用、什么时候该删。没有这个清单半年后账号就成了无人认领的僵尸账号权限还留在那儿这是审计里最常见的扣分项。6. 报错实录认证、权限、连接三类问题的排查路径6.1 认证类Authentication failed的六种成因这条报错是 MongoDB 安全实验里出现频率最高的但它本身不告诉你是哪儿错了得按可能性从高到低排查。我整理了一下自己的排查顺序可能原因判断方法解决方式authSource指错了库确认用户建在哪个库连接参数改成用户所在的库密码里的特殊字符没转义用-p手动输入试试URI 里做百分号编码用户根本不存在db.getUser(xxx)重新创建认证机制不匹配检查mechanisms字段补上对应的 SCRAM 凭证连到了别的实例db.runCommand({ping:1})看版本确认端口和主机密码确实错了换管理员账号改一次密码db.changeUserPassword排在第一位的永远是authSource。原因前面说过用户信息是跟着库走的admin库的用户全局可见业务库的用户只在业务库内有效。连接时不写authSource驱动默认会去连的那个库找用户找不到就报认证失败。这个错在新手身上能占到七成。对应地我建议在实验里养成一个习惯建完用户立刻写一条完整的连接串记录在旁边包括用户名、库、端口。等后面报错时对照着看比凭记忆靠谱得多。6.2 权限类not authorized的定位方法认证过了但操作被拒报错一般是 “not authorized on xxx to execute command yyy”。这条信息其实挺友好它明确告诉你是哪个库、哪条命令。定位方法就一步查当前用户的角色。db.runCommand({ connectionStatus: 1 })这个命令会返回当前连接用的是什么账号、认证在哪个库、拥有哪些角色。看着角色列表对照第 3 节那张表就知道缺什么了。缺读给read缺写给readWrite缺建索引用dbAdmin。有一种情况特别隐蔽用户有两个角色但一个是read、一个是自定义的find角色你以为权限叠加了实际上只要有一个角色覆盖就够问题是某些命令需要特定角色组合比如listCollections在某些版本里需要dbAdmin或者显式授予。遇到明明有权限却报错的情况可以临时用管理员账号执行同一条命令验证一下确认是权限问题而非命令本身语法问题。顺带说一句MongoDB 的权限检查是按命令粒度的不是按集合粒度。有些命令比如aggregate带$lookup跨集合查询权限判定会比较复杂遇到怪问题不要硬猜去日志里看具体是哪条命令被拒日志里写得比客户端清楚。6.3 连接类连不上的排查顺序连接被拒的报错通常是ECONNREFUSED这个反而好排查因为它说明 TCP 层就没通跟认证无关。排查顺序固定先看进程在不在再看端口通不通最后看监听地址对不对。ps -ef | grep mongod ss -lntp | grep 27017如果进程在但端口没监听看日志八成是配置文件语法错误或者数据目录权限问题。如果端口在监听但连不上看bindIp是不是只绑了127.0.0.1而你在从另一台机器连。如果这些都正常还是连不上考虑防火墙和安全组。还有一类是“能连上但很快断开”这通常是 TLS 配置不当导致的握手失败。日志里会有 TLS 相关的报错关键词是ssl handshake或者certificate。这种情况优先检查证书有效期、CN 是否匹配、CA 是否正确加载。按这个顺序走绝大多数连接问题五分钟内能定位。最怕的是一上来就改配置把原本能用的环境改坏了问题反而更复杂。7. 实验做完之后把这些习惯带出去一套实验跑完真正的收获不是那几条命令而是几个能迁移到任何环境里的习惯。第一个习惯是改配置前先备份、改完先看日志这个动作在任何数据库、任何中间件上都成立养成之后能省掉大量“改坏了回不去”的窘境。第二个习惯是先开认证再放开监听这个顺序一旦颠倒暴露窗口期就是真实的风险。第三个习惯是账号按用途拆、按最小权限给宁可多建两个账号也别图省事给root。最后分享一个我自己一直在用的小技巧每配完一套环境写一份十行以内的“环境说明”记录版本、端口、配置文件路径、管理员账号所在库、业务账号清单。这份东西在实验里用不上但在真实运维里它能让你在半年后重新接手时五分钟内进入状态也能让同事在你休假时接得住。安全这件事一半靠配置一半靠可交接的文档。 
长河君 · 2026/10/26 11:47:50 · 阅读 1.2k MongoDB数据库安全实验：认证授权、角色权限与报错排查
在不少在线实验环境里MongoDB 这套数据库安全实验是很多人的第一道坎前面增删改查跑得挺顺一到“开启认证”“建用户”“配角色”就开始卡壳报错信息还特别吝啬只有一句 Authentication failed让人摸不着头脑。这篇就把 MongoDB 数据库安全这件事从头到尾拆开讲一遍从认证开关的原理、SCRAM 密码存储机制、内置角色的选型逻辑到配置文件逐行拆解、最小权限落地、TLS 与内部认证、备份交接最后再给一份我自己踩坑攒出来的报错速查表。不管你是刚接触 MongoDB 的新手还是带过几届实验、想把这套东西讲透的老手下面这些内容都能直接拿去用。1. 这门实验在练什么先把“安全”拆成能动手的三件事1.1 为什么一上来就讲认证而不是继续讲增删改查很多人第一次做数据库安全实验时会有个疑问语法还没学全怎么就讲起权限了。这个顺序其实是对的。MongoDB 装完之后默认是完全开放的——监听本地回环、不开认证、任何人都能连上去建库删库。你在本地折腾当然无所谓但只要这台机器暴露在局域网里几分钟内就可能被扫到数据被清空、留下勒索信息的案例在圈内流传过不止一次。所以实验的第一课不是“怎么用”而是“怎么不让别人用”。从这个角度看安全实验的核心其实是三件事证明你是谁认证 Authentication、规定你能干什么授权 Authorization、限制你从哪儿来、路上安不安全网络与传输。这三件事在 MongoDB 里对应着完全不同的配置位置和命令混在一起学很容易乱。我建议在动手之前先在纸上把这三层画出来后面每配一个参数都知道自己落在哪一层上。还有一点值得说清楚MongoDB 的认证和授权是分开的两个开关security.authorization: enabled打开的是授权而认证是它的前置条件。这个概念混淆是新手最常见的误区之一——很多人以为开了这个开关就等于“加了密码”结果连上去发现还是能操作只是报错变成了“not authorized”一脸茫然。1.2 实验环境里真正要验收的三个结果抛开实验指导书上那些步骤编号一套 MongoDB 安全配置做完能用三个结果来验收自己到底有没有做对。第一个结果是未认证的连接不能执行任何数据操作随便敲一条db.users.find()应该被拒绝而不是返回空数组。第二个结果是不同账号看到的边界不一样业务账号只能碰自己那个库碰别的库应该直接报权限错误。第三个结果是管理员账号能管用户但读不到业务数据这一点最容易被忽略也是最能体现“最小权限”思想的地方。第三个结果值得多说两句。很多人的做法是建一个root角色的大号然后用这个号干所有事情。在实验环境里这样最省事但在真实项目里这是标准的反面教材——一旦这个账号的密码泄露攻击者拿到的是整个实例的控制权。合理的做法是至少拆成两个号一个只管用户和角色userAdminAnyDatabase一个管集群运维clusterAdmin业务库各自有独立的读写账号。这个拆分在实验里可能只值两分但在工程上能救命。至于操作系统的防火墙、云上的安全组、数据库前面的网关这些属于环境层面的东西实验里通常不会涉及但心里要有数MongoDB 自身的认证是最后一道门不是唯一一道门。1.3 动手前需要准备的环境清单实验环境一般会预装好 MongoDB但如果你打算在本地复现一遍需要准备的东西不多一个 Linux 或者 macOS 环境Windows 也能做路径写法略有差异、MongoDB 6.0 以上的版本、一个能改配置文件的权限、以及mongosh这个新版 shell。我强烈建议用mongosh而不是老的mongo因为 5.0 之后老 shell 已经被移除很多老教程里的命令在新版本上直接跑不通这也是新手最容易踩的第一个坑。配置文件的位置各家发行版不太一样常见的三个路径是/etc/mongod.conf、/etc/mongodb.conf、以及自己编译安装时的自定义路径。启动方式也分 systemd 管理的服务和手动mongod --config启动两种。我个人的习惯是手动启动参数看得见、日志打得直、出问题好排查实验阶段强烈推荐这种方式。还有一件事提前说改配置文件之前先备份一份。这不是客套话YAML 对缩进极其敏感一个 Tab 用错位置服务直接起不来而且报错信息往往指向别处能让人折腾半小时。备份一下两秒钟的事。2. 认证开关与配置文件从“谁都能连”到“凭证入场”2.1authorization: enabled到底改变了什么把这一行配置加进去、重启服务之后MongoDB 的内部行为会发生一个根本性变化每一条命令在执行前都会先检查当前连接的认证状态和角色权限。没认证的连接只能执行极少数命令比如ping、hello、buildInfo这类无害的握手命令任何涉及数据的操作都会被拦下来。这里有个非常关键的机制叫localhost exception本地回环例外当实例里一个用户都没有的时候从本机回环地址连进来的连接被允许创建第一个用户。这个设计的用意很实际——你不可能在没有用户的情况下先认证再建用户那是个死循环。但这个例外只在“零用户”状态下生效一旦你建了第一个用户它就永久关闭了。我在带人做实验时见过太多人栽在这一步配置里开了authorization: enabled重启然后发现自己连不上了也不知道怎么建第一个用户。原因往往是他们之前已经建过用户或者数据目录里残留了旧的admin.system.users。遇到这种情况最直接的办法是先把authorization改回disabled重启建好管理员再改回来。别硬扛。authorization的可选值其实有三个enabled、disabled以及 MongoDB 早期版本的enabled之外还有authentication之类的历史写法新版本统一用enabled就好。切值之后必须重启mongod不能热加载这一点和某些关系型数据库不一样。2.2mongod.conf逐段拆解与参数取舍配置文件不长但每一段都有它的道理。下面这份是我在实验和测试环境里用得最多的一份模板注释我写在旁边systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo journal: enabled: true net: port: 27017 bindIp: 127.0.0.1 security: authorization: enabledsystemLog这一段看着不起眼但它决定了你出问题时能不能看到线索。destination: file配上logAppend: true保证日志追加而不是覆盖排查认证失败时日志里会明确写出“Authentication failed”以及是哪个用户、哪个库、哪条命令触发的比客户端那句干巴巴的报错有用得多。storage.dbPath是数据目录注意权限——mongod进程的运行用户必须对这个目录有读写权限否则启动直接失败。很多人从别处拷贝了一份数据目录过来权限不对服务起不来还以为是配置写错了。net.port默认 27017实验里用默认值最省事。net.bindIp是重中之重默认只绑127.0.0.1意味着只有本机能连。如果你需要别的机器连进来得改成0.0.0.0或者具体的网卡 IP但这一步要格外谨慎——在开认证之前改 bindIp等于把大门敞开。正确顺序永远是先开认证、建好账号再放开监听地址。这个顺序搞反是安全事故的经典成因。security.authorization前面讲过了。这里补一句如果你还要做副本集security段里还得加keyFile或者clusterAuthMode这属于进阶内容第 4 节会展开。2.3 密码在库里长什么样SCRAM 机制拆解这部分很多人做实验时是跳过的但它恰恰是理解“为什么改了密码老连接还通”这类问题的钥匙。MongoDB 从 3.0 开始默认用 SCRAM 做认证4.0 之后同时支持 SCRAM-SHA-1 和 SCRAM-SHA-256 两种摘要算法。SCRAM 的核心思想是服务端不存明文密码也不存密码的简单哈希而是存一组可以验证客户端但无法反推密码的凭证。以 SCRAM-SHA-256 为例用户文档里存的是salt盐、iterationCount迭代次数MongoDB 默认 15000、storedKey和serverKey四个字段。认证时客户端和服务器通过一串挑战-响应的交互各自算出结果比对全程密码本身不落地、不传输。你可以用下面这个命令亲眼看看存的是什么use admin db.system.users.find({ user: dbAdmin }, { credentials: 1, roles: 1 })你会看到credentials里是一堆 base64 字符串看不到任何明文。这个认知很实用如果你在两台机器之间迁移用户直接拷贝system.users文档是可行的凭证可以复用但如果换了认证机制就得重新设密码。还有一个坑值得提前说同一个用户可以同时拥有 SCRAM-SHA-1 和 SCRAM-SHA-256 两套凭证这取决于创建用户时是否指定了mechanisms参数。老客户端只支持 SHA-1新客户端优先走 SHA-256混用环境里如果只保留了 SHA-256 凭证老驱动就会认证失败。排查“同样的密码一个工具能连一个不能连”时先往这个方向想。3. 用户与角色最小权限原则怎么落成具体命令3.1 内置角色速查与选型思路MongoDB 的内置角色有几十个全部背下来没必要但常用的那十来个必须心里有数。我把实验和日常运维里最常打交道的列在下面按“能干什么”而不是“叫什么”来记会更牢角色名作用域实际能干什么典型用途read单库只读该库所有集合报表、审计读取readWrite单库读写该库所有集合业务应用账号dbAdmin单库建索引、看统计、改集合选项库级运维userAdmin单库管理该库的用户与角色库级账号管理userAdminAnyDatabase全局管理所有库的用户管理员账号readAnyDatabase全局读所有库跨库分析clusterAdmin全局副本集、分片、节点管理集群运维root全局所有权限仅在完全可控环境使用选角色的第一个原则是能落到单库就不给全局。业务账号一律用readWrite绑在具体库上不要图省事给readWriteAnyDatabase。第二个原则是读写分离很多业务其实只需要读给个read就够了写权限应该是有明确需求才授予。第三个原则是管理权和数据权分离管用户的号不应该有读数据的权限这个分离在实验评分里不一定体现但在真实审计里是硬要求。还有两个容易被忽略的角色值得提一句backup和restore。做备份的账号只要这两个就够了不需要给它root。很多人配备份脚本时图省事直接用管理员账号脚本一旦泄露风险成倍放大。3.2 建管理员、建业务账号的完整实操创建一个具备用户管理能力的管理员命令本身很短但参数背后有讲究use admin db.createUser({ user: accountAdmin, pwd: Str0ng_Passw0rd#2024, roles: [ { role: userAdminAnyDatabase, db: admin }, { role: clusterMonitor, db: admin } ], mechanisms: [SCRAM-SHA-256] })几个细节。use admin必须写因为用户信息是跟着库走的admin库下的用户是全局可见的其他库的用户只在该库内有效。roles数组里的db字段也必须写虽然看着冗余但它是角色作用域的一部分。mechanisms指定只用 SHA-256 更安全前提是你的客户端都支持。业务账号的创建方式略有不同use appdb db.createUser({ user: app_rw, pwd: Another_Str0ng#2024, roles: [ { role: readWrite, db: appdb } ] })注意这里是先use appdb用户就建在appdb库里。这就引出一个必须记住的规则连接时要用--authenticationDatabase指定用户所在的库。如果app_rw建在appdb里你却在连接时指定authSourceadmin那必然认证失败而且报错信息不会告诉你原因。这是新手报错率最高的一条我在第 6 节会单独展开。改密码和删用户也很常用db.changeUserPassword(app_rw, New_Str0ng#2025) db.dropUser(app_rw)改完密码后已有的连接不会立刻失效这点和某些数据库不同要留意。3.3 自定义角色把权限切到集合级内置角色的粒度是“库”遇到更细的需求就得上自定义角色。比如某个服务只需要读orders这一个集合的find操作其他一概不给use appdb db.createRole({ role: readOrdersOnly, privileges: [ { resource: { db: appdb, collection: orders }, actions: [find] } ], roles: [] })privileges里的resource可以是具体的db collection也可以是{ db: appdb, collection: }表示整个库或者{ cluster: true }表示集群级资源。actions是最细的操作粒度常见的有find、insert、update、remove、createIndex、listCollections等。这里有个坑只给find是不够的客户端在查询前往往会先调listCollections或者listIndexes不给的话行为会显得很怪。我一般的做法是find加上listCollections一起给。角色建完之后挂到用户上db.grantRolesToUser(app_rw, [{ role: readOrdersOnly, db: appdb }])想撤销用db.revokeRolesFromUser()想查当前用户有啥用db.getUser(app_rw)。自定义角色的一个好处是可复用同一个角色可以挂到多个用户上权限调整时改角色就行不用一个个改用户这在账号多的环境里能省很多事。4. 网络与传输层加固连接从哪来、路上安不安全4.1bindIp与端口先把入口收窄认证解决的是“你是谁”但一个只监听内网地址的实例被攻击面本身就小了一大截。bindIp支持多个地址用逗号分隔net: bindIp: 127.0.0.1,10.0.0.21 port: 27017这样本机连得上内网某台固定机器也连得上其他来源一律连不进来。这比开0.0.0.0再靠防火墙兜底要稳妥因为防火墙规则可能被人手一抖改掉bindIp写在配置文件里更不容易误改。端口这块改默认 27017 到别的值能减少被自动化扫描命中的概率但这属于降低噪音不属于安全保障别把它当成主要手段。真正有效的还是认证加网络隔离。如果你的运维流程允许我建议把端口改成一个高位端口并且写进配置管理运维侧统一口径避免不同环境不一致带来的沟通成本。还有一个容易被忘的点MongoDB 除了主端口副本集和分片还会用到额外的通信端口。如果你只放开了 27017集群模式下的节点间通信会莫名其妙地失败排查起来很费时间。做实验时通常是单节点感受不到这个坑但心里要有数。4.2 传输加密与keyFile内部认证数据在网络上传的时候是明文还是密文由 TLS 决定。MongoDB 的 TLS 配置集中在net.tls段net: tls: mode: requireTLS certificateKeyFile: /etc/ssl/mongodb/server.pem CAFile: /etc/ssl/mongodb/ca.pem allowConnectionsWithoutCertificates: falsemode有三个值disabled、allowTLS、preferTLS、requireTLS生产环境直接用requireTLS逼着所有连接都走加密。certificateKeyFile是服务端证书加私钥的合并文件CAFile是签发证书的根证书。allowConnectionsWithoutCertificates设成false表示强制客户端也带证书这叫双向 TLS安全性最高但客户端配置成本也最高。实验环境里通常只做单向 TLS 就够了。证书的自签流程大致是先生成 CA 私钥和自签 CA 证书再用 CA 给服务端证书签名最后把服务端证书和私钥合并成一个 pem 文件。整个过程十几条命令细节容易出错的地方是证书的 CN 或 SAN 必须和客户端连接时用的主机名匹配不匹配的话会报证书校验失败而这个报错的字面意思往往看不出是名字对不上。keyFile是另一个层面的东西它是副本集成员之间互相认证用的共享密钥文件不是给客户端用的。生成方式很简单openssl rand -base64 756 /etc/mongodb/keyfile chmod 400 /etc/mongodb/keyfile权限必须是 400 或者 600宽了mongod会拒绝启动。然后配置里加security.keyFile: /etc/mongodb/keyfile。注意开了keyFile之后authorization会自动被启用不需要再单独写这一点很多人不知道会重复配置。4.3 副本集场景下的额外注意点单机实验很少涉及副本集但一旦涉及安全的复杂度是翻倍的。除了上面说的keyFile还要注意几件事成员的bindIp必须能让其他成员访问到每个成员的配置里replSetName必须一致初始化副本集时用的那个连接必须是已认证的以及rs.initiate()之后要等状态变成PRIMARY才能建库。有个很典型的实验场景三节点副本集keyFile配好了但某个节点一直起不来日志里报 “Bad key file”。原因几乎总是权限不对或者文件内容被编辑器加了换行。用openssl rand生成的是单行 base64如果手动拷贝时不小心折行了解析就失败。我一般的做法是生成后cat一遍确认是单行再chmod 400。另外副本集里创建用户只需要在主节点操作会自动同步到从节点。但如果主从切换了你用原来的连接串可能会连到新的主节点认证信息是一致的不影响使用只是要注意应用侧的连接串要写成副本集形式别写死单节点地址。5. 一次完整演练从裸库到带权限的可用环境5.1 环境准备与配置落地假设手上是一台干净的环境目标是搭一个“本地可连、开了认证、有独立业务账号”的实例。第一步先确认mongod的版本和配置文件路径mongod --version ls -l /etc/mongod.conf确认之后把配置文件改成下面这个样子以手动启动为例systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo net: port: 27017 bindIp: 127.0.0.1先不要加security.authorization先用无认证模式启动把管理员建出来。启动命令mongod --config /etc/mongod.conf --fork--fork让进程后台运行实验环境里方便。启动后用mongosh连上去验证一下确实是通的mongosh --host 127.0.0.1 --port 27017能进去说明基础配置没问题接下来才是安全部分。5.2 建库建用户与连接验证在无认证状态下用 localhost exception 建第一个管理员use admin db.createUser({ user: accountAdmin, pwd: Str0ng_Passw0rd#2024, roles: [{ role: userAdminAnyDatabase, db: admin }] })建完立刻验证一下能不能认证db.auth(accountAdmin, Str0ng_Passw0rd#2024)返回{ ok: 1 }就对了。这时候退出 shell改配置文件加上security.authorization: enabled重启mongod --config /etc/mongod.conf --shutdown mongod --config /etc/mongod.conf --fork重启后再连先试一个未认证的操作确认被拒绝mongosh --host 127.0.0.1 --port 27017进去后敲show dbs如果报 “command listDatabases requires authentication”说明认证开关生效了。然后带上账号连mongosh --host 127.0.0.1 --port 27017 \ -u accountAdmin -p Str0ng_Passw0rd#2024 \ --authenticationDatabase admin进去之后建业务库和业务账号use appdb db.createUser({ user: app_rw, pwd: Another_Str0ng#2024, roles: [{ role: readWrite, db: appdb }] })再单独测业务账号mongosh mongodb://app_rw:Another_Str0ng%232024127.0.0.1:27017/appdb?authSourceappdb注意密码里的#在 URI 里要转义成%23这是个非常常见的坑很多人复制粘贴后连接失败排查半天以为是账号问题其实是 URI 编码没处理。用-p参数传密码就没这个烦恼。最后做边界验证用app_rw去读admin库应该报 “not authorized on admin to execute command”。这一步过了说明最小权限真的生效了。5.3 备份恢复与账号交接安全做完了还得考虑数据怎么搬。带认证的实例做备份连接串里必须带上认证信息mongodump \ --urimongodb://backup_user:Backup_Pass%232024127.0.0.1:27017/?authSourceadmin \ --out/backup/20240601backup_user应该有backup角色restore用来恢复。恢复命令同理mongorestore \ --urimongodb://restore_user:Restore_Pass%232024127.0.0.1:27017/?authSourceadmin \ /backup/20240601这里有个细节mongodump默认只导数据不导用户要导用户得加--dumpDbUsersAndRoles。很多人在迁移时发现用户没了就是因为漏了这个参数。但反过来说不带用户导出反而是更安全的做法账号应该在新环境里重新创建避免把旧的凭证带过去。账号交接这件事在实验里体现不出来但工程上很重要。我一般的做法是给每个账号建一个“归属说明”写清楚谁申请的、给哪个服务用、什么时候该删。没有这个清单半年后账号就成了无人认领的僵尸账号权限还留在那儿这是审计里最常见的扣分项。6. 报错实录认证、权限、连接三类问题的排查路径6.1 认证类Authentication failed的六种成因这条报错是 MongoDB 安全实验里出现频率最高的但它本身不告诉你是哪儿错了得按可能性从高到低排查。我整理了一下自己的排查顺序可能原因判断方法解决方式authSource指错了库确认用户建在哪个库连接参数改成用户所在的库密码里的特殊字符没转义用-p手动输入试试URI 里做百分号编码用户根本不存在db.getUser(xxx)重新创建认证机制不匹配检查mechanisms字段补上对应的 SCRAM 凭证连到了别的实例db.runCommand({ping:1})看版本确认端口和主机密码确实错了换管理员账号改一次密码db.changeUserPassword排在第一位的永远是authSource。原因前面说过用户信息是跟着库走的admin库的用户全局可见业务库的用户只在业务库内有效。连接时不写authSource驱动默认会去连的那个库找用户找不到就报认证失败。这个错在新手身上能占到七成。对应地我建议在实验里养成一个习惯建完用户立刻写一条完整的连接串记录在旁边包括用户名、库、端口。等后面报错时对照着看比凭记忆靠谱得多。6.2 权限类not authorized的定位方法认证过了但操作被拒报错一般是 “not authorized on xxx to execute command yyy”。这条信息其实挺友好它明确告诉你是哪个库、哪条命令。定位方法就一步查当前用户的角色。db.runCommand({ connectionStatus: 1 })这个命令会返回当前连接用的是什么账号、认证在哪个库、拥有哪些角色。看着角色列表对照第 3 节那张表就知道缺什么了。缺读给read缺写给readWrite缺建索引用dbAdmin。有一种情况特别隐蔽用户有两个角色但一个是read、一个是自定义的find角色你以为权限叠加了实际上只要有一个角色覆盖就够问题是某些命令需要特定角色组合比如listCollections在某些版本里需要dbAdmin或者显式授予。遇到明明有权限却报错的情况可以临时用管理员账号执行同一条命令验证一下确认是权限问题而非命令本身语法问题。顺带说一句MongoDB 的权限检查是按命令粒度的不是按集合粒度。有些命令比如aggregate带$lookup跨集合查询权限判定会比较复杂遇到怪问题不要硬猜去日志里看具体是哪条命令被拒日志里写得比客户端清楚。6.3 连接类连不上的排查顺序连接被拒的报错通常是ECONNREFUSED这个反而好排查因为它说明 TCP 层就没通跟认证无关。排查顺序固定先看进程在不在再看端口通不通最后看监听地址对不对。ps -ef | grep mongod ss -lntp | grep 27017如果进程在但端口没监听看日志八成是配置文件语法错误或者数据目录权限问题。如果端口在监听但连不上看bindIp是不是只绑了127.0.0.1而你在从另一台机器连。如果这些都正常还是连不上考虑防火墙和安全组。还有一类是“能连上但很快断开”这通常是 TLS 配置不当导致的握手失败。日志里会有 TLS 相关的报错关键词是ssl handshake或者certificate。这种情况优先检查证书有效期、CN 是否匹配、CA 是否正确加载。按这个顺序走绝大多数连接问题五分钟内能定位。最怕的是一上来就改配置把原本能用的环境改坏了问题反而更复杂。7. 实验做完之后把这些习惯带出去一套实验跑完真正的收获不是那几条命令而是几个能迁移到任何环境里的习惯。第一个习惯是改配置前先备份、改完先看日志这个动作在任何数据库、任何中间件上都成立养成之后能省掉大量“改坏了回不去”的窘境。第二个习惯是先开认证再放开监听这个顺序一旦颠倒暴露窗口期就是真实的风险。第三个习惯是账号按用途拆、按最小权限给宁可多建两个账号也别图省事给root。最后分享一个我自己一直在用的小技巧每配完一套环境写一份十行以内的“环境说明”记录版本、端口、配置文件路径、管理员账号所在库、业务账号清单。这份东西在实验里用不上但在真实运维里它能让你在半年后重新接手时五分钟内进入状态也能让同事在你休假时接得住。安全这件事一半靠配置一半靠可交接的文档。