1. 为什么数据库认证不是“可选项”而是“必答题”很多刚接触文档型数据库的朋友第一次把服务跑起来的时候往往只关心一件事能不能连上、能不能读写。默认配置下本地起一个实例端口一开客户端一连数据就进去了整个过程顺畅得让人不想去碰任何额外设置。这种“零配置”的体验确实舒服但它背后藏着一个很现实的问题——默认状态下数据库几乎不设防。我见过不少项目开发阶段图省事直接把实例暴露在内网甚至公网上认证机制完全没开。等到上线前做安全检查才发现一堆问题谁都能连、谁都能删库、谁都能把整个集合清空。更麻烦的是有些团队以为“内网就安全”结果一台机器被攻破横向渗透到数据库数据直接被拖走。这类事故的根源往往不是多高深的技术漏洞而是认证这一层根本没做。所谓安全认证说白了就是回答三个问题你是谁、你能干什么、你干了什么。第一个是身份验证第二个是权限控制第三个是审计追溯。这三件事在文档型数据库里都有对应的机制只是很多人没系统地去配过。这篇内容就是围绕这套机制展开的从最基础的账号密码到角色权限的细粒度划分再到内部成员之间的认证最后落到实际排查问题的经验上。适合谁来读如果你是刚接手数据库运维的开发或者正在做上线前的安全加固又或者你只是想让自己的本地环境别那么“裸奔”那这篇内容基本能覆盖你需要的操作路径。我会尽量把每一步为什么这么做讲清楚而不是只丢几条命令让你照抄。毕竟认证这东西配错了比不配还危险——你以为锁上了其实门还开着。2. 认证机制的整体设计与选型思路2.1 从“谁能进”到“能进哪间房”的分层逻辑刚上手的时候很多人会把“认证”和“授权”混为一谈。其实这是两件事而且顺序不能乱。认证解决的是“你是不是你说的那个人”授权解决的是“你进来之后能碰哪些东西”。数据库在这两块是分开设计的配置的时候也要分开考虑。先看认证。文档型数据库支持多种认证方式常见的有这么几类基于用户名密码的挑战应答、基于证书的双向验证、以及面向内部集群成员的密钥文件认证。每种方式适用的场景不一样。用户名密码适合大多数应用连接配置简单客户端支持广证书认证适合对传输安全要求更高的场景但证书的签发和轮换会带来额外运维成本密钥文件则是集群内部节点互相识别用的不对外部客户端开放。再看授权。授权是建立在认证之上的只有先确认了身份才能谈这个身份拥有哪些权限。数据库把权限抽象成“角色”每个角色绑定一组对特定数据库、特定集合的操作许可。你可以把角色理解成一把钥匙钥匙上刻着“只能开A房间的抽屉不能开B房间的门”。给用户分配角色就是给他发钥匙的过程。这里有个设计上的取舍值得说清楚为什么不直接给用户逐个分配权限而要用角色因为用户数量会增长权限需求会变化如果每个用户都单独配一遍维护成本会指数级上升。角色相当于一层中间抽象把“权限集合”和“用户”解耦。你改角色所有绑了这个角色的用户自动生效你加用户直接绑现成的角色就行。这是典型的用一层间接性换可维护性的做法。2.2 认证方式的选择依据与适用边界具体到选哪种认证方式我的经验是按部署形态来分。单机实例、副本集、分片集群这三种形态对认证的要求是不一样的。单机实例最简单开个用户名密码认证就够了。副本集稍微复杂一点因为节点之间要互相通信除了外部客户端的认证还得配内部成员认证否则节点之间没法建立信任关系。分片集群更麻烦除了副本集那套还要考虑路由节点和配置节点之间的认证。内部成员认证通常用密钥文件所有节点共享同一个密钥。这个密钥的作用相当于“内部通行证”节点拿着它互相验证身份。密钥文件的安全等级要求很高权限必须收紧不能让普通用户读到。我见过有人图方便把密钥文件放在共享目录里权限设成所有人可读这等于把内部通行证复印了一份贴在公告栏上。外部客户端认证则要根据实际需求来。如果应用和数据库在同一台机器上或者在内网可信环境里用户名密码基本够用。如果跨网络传输或者合规要求比较高那就得上证书。证书的好处是双向验证客户端要验证服务端服务端也要验证客户端中间人很难插进来。代价是证书管理麻烦过期了要换吊销了要更新这些都得提前规划。提示认证方式一旦启用就不能随便关掉。有些团队在测试环境开了认证上线时嫌麻烦想关掉结果发现关不掉了——因为系统库里的用户数据已经存在关掉认证反而会导致连接异常。所以启用之前要想清楚这是单向操作。2.3 角色权限模型的设计哲学角色权限这块数据库内置了一套角色覆盖了从“只读”到“超级用户”的各种粒度。内置角色的好处是开箱即用坏处是粒度可能不完全贴合你的业务需求。比如你有一个只负责写日志的账号内置的“读写”角色对它来说权限太大了它不需要读其他集合也不需要删数据。这时候就需要自定义角色。自定义角色的思路是先列出这个身份需要做哪些操作再把这些操作映射到具体的权限上最后打包成一个角色。比如一个“日志写入者”角色只需要对日志集合有插入权限不需要查询、更新、删除。这样即使这个账号泄露了攻击者也只能往里塞垃圾数据没法把已有数据读走或删掉。这里有个容易被忽略的点权限是分数据库的。一个用户可以在A数据库有读写权限在B数据库只有只读权限在C数据库完全没有权限。这种设计让多租户场景变得很自然——不同业务共用一套数据库实例但彼此的数据互相隔离。配置的时候要特别注意别一不小心给了某个用户全局权限那就等于把整栋楼的钥匙都给他了。3. 核心细节解析与实操要点3.1 启用认证前的准备工作与顺序启用认证这件事顺序特别重要。如果顺序错了很可能把自己锁在门外。正确的流程是这样的第一步先在不开启认证的状态下连上数据库创建管理员用户。这个管理员用户必须建在admin数据库下因为admin是管理库管理员角色也在这里。创建的时候要指定角色通常是userAdminAnyDatabase加上readWriteAnyDatabase或者直接给root。root角色权限最大能操作所有数据库和所有功能适合做超级管理员。第二步验证管理员用户能正常登录。这一步别跳过我见过有人创建完用户直接就去改配置文件开认证结果重启后发现密码记错了或者角色没给对连都连不上只能删数据目录重来。验证的方法是用管理员账号连一次执行个简单命令比如查看当前用户确认返回正常。第三步修改配置文件启用认证。配置项通常是security.authorization设成enabled。改完重启服务。第四步重启后用管理员账号登录再创建业务用户。业务用户建在对应的业务数据库下分配最小必要权限。这个顺序的核心逻辑是认证开启后没有账号就进不去所以账号必须在开启前就建好。而管理员账号又必须在admin库下建因为只有admin库的管理员才有权限去创建其他库的用户。这是一环扣一环的。注意创建第一个管理员用户时数据库处于“本地host例外”状态也就是允许无认证连接。这个窗口期很短一旦第一个用户创建成功这个例外就关闭了。所以创建动作要一次成功别中途断开。3.2 用户创建与角色分配的具体操作创建用户的命令结构不复杂但参数含义要搞清楚。以创建一个业务读写用户为例db.createUser({ user: app_writer, pwd: ComplexPassw0rd!, roles: [ { role: readWrite, db: business_db } ] })这里user是用户名pwd是密码roles是角色数组。角色可以指定多个每个角色绑定一个数据库。上面这个例子就是给app_writer在business_db上赋予读写权限。如果要创建自定义角色步骤稍微多一点。先定义角色指定它的权限集合db.createRole({ role: log_inserter, privileges: [ { resource: { db: business_db, collection: logs }, actions: [insert] } ], roles: [] })这个自定义角色只允许往business_db的logs集合插入数据其他什么都不行。privileges数组里每个元素描述一个资源加一组动作。resource指定数据库和集合actions指定允许的操作比如insert、find、update、remove等。创建完角色后再把这个角色分配给用户db.grantRolesToUser(app_writer, [ { role: log_inserter, db: business_db } ])这样app_writer就同时拥有了readWrite和log_inserter两个角色的权限。权限是叠加的不是覆盖的。这里有个实操心得密码策略要提前定好。数据库本身对密码复杂度没有强制要求你设个“123456”它也能接受。但从安全角度密码长度至少12位包含大小写字母、数字和特殊符号。更好的做法是结合密钥管理服务定期轮换密码。我见过太多因为密码太简单被撞库的案例真不是危言耸听。3.3 内部成员认证的密钥文件配置副本集和分片集群的内部认证用的是密钥文件。这个文件的生成方式很简单内容就是一串随机字符长度建议在6到1024个字符之间。生成方法可以用系统自带的随机数工具openssl rand -base64 756 /path/to/keyfile chmod 400 /path/to/keyfile chown mongodb:mongodb /path/to/keyfile这里chmod 400是关键意思是只有文件所有者能读其他人连读的权限都没有。chown是把文件所有权给数据库进程的运行用户。这两步不做数据库启动时会报权限错误拒绝加载密钥文件。密钥文件配好之后要在每个节点的配置文件里指定路径security: keyFile: /path/to/keyfile authorization: enabled所有节点的密钥文件内容必须完全一致。如果某个节点的密钥文件和其他节点不一样它就无法加入集群会一直卡在启动阶段。排查这类问题时先比对各节点密钥文件的哈希值确认内容一致。提示密钥文件不要放在版本控制里也不要通过明文渠道传输。部署的时候用配置管理工具分发或者手动拷贝后立即删除中间文件。密钥泄露等于集群内部信任关系被破坏后果比单个用户密码泄露严重得多。3.4 认证与传输加密的配合使用认证解决的是“你是谁”但认证过程本身如果走明文传输密码就可能被截获。所以认证和传输加密通常是配合使用的。传输加密用的是TLS配置项在net.tls下面。启用TLS需要准备证书和私钥。服务端证书用来向客户端证明自己的身份如果开启双向验证还需要客户端证书。配置大概长这样net: tls: mode: requireTLS certificateKeyFile: /path/to/server.pem CAFile: /path/to/ca.pemmode设成requireTLS表示强制所有连接都走TLS不接受明文连接。certificateKeyFile是服务端证书和私钥的合并文件CAFile是证书颁发机构的证书用来验证客户端证书。这里有个细节TLS和认证是独立配置的但建议一起开。只开认证不开TLS密码在网络里裸奔只开TLS不开认证加密通道里谁都能进。两个都开才是完整的防护。证书的轮换是个麻烦事。证书有有效期到期前要更新。更新的时候不能直接替换文件重启那样会导致连接中断。正确的做法是滚动更新先更新一个节点等它恢复正常再更新下一个。副本集环境下只要多数节点在线服务就不会中断。4. 实操过程与核心环节实现4.1 单机环境从零到一的认证配置全流程假设你刚装好数据库服务已经跑起来了现在要加上认证。完整流程如下。先连上实例创建管理员use admin db.createUser({ user: site_admin, pwd: Adm1nSecure2024, roles: [root] })执行成功后会返回一个确认信息表示用户已创建。这时候别急着退出先验证一下db.auth(site_admin, Adm1nSecure2024)返回1表示认证成功。如果返回0或者报错说明用户名密码不对或者角色没给对。确认无误后再进行下一步。然后编辑配置文件找到security部分加上security: authorization: enabled保存后重启服务。重启完成后再连数据库这时候不认证就什么都做不了了。用管理员账号登录mongo --username site_admin --password --authenticationDatabase admin回车后会提示输入密码。登录成功后创建业务用户use business_db db.createUser({ user: app_user, pwd: AppPass2024!, roles: [ { role: readWrite, db: business_db } ] })到这里单机环境的认证就配好了。业务应用用app_user连接管理员用site_admin管理。4.2 副本集环境的认证部署与验证副本集比单机多一层内部认证。假设你有三个节点部署流程是这样的。先在其中一个节点上以不开启认证的方式启动创建管理员用户。注意副本集环境下创建用户要在主节点上操作。怎么判断哪个是主节点连上去执行rs.status()看stateStr字段值是PRIMARY的就是主节点。创建管理员用户的命令和单机一样。创建完成后生成密钥文件分发到三个节点权限都设成400。然后修改三个节点的配置文件都加上security: keyFile: /path/to/keyfile authorization: enabled replication: replSetName: rs0三个节点依次重启。重启后用管理员账号连上主节点执行rs.status()确认三个节点状态正常。如果某个节点状态是STARTUP2或者RECOVERING说明它还没同步完等一会儿再看。验证内部认证是否生效可以尝试用一个没有权限的账号去连从节点。如果连不上或者只能读不能写说明认证起作用了。从节点默认是只读的这是副本集的特性和认证无关。注意副本集环境下如果密钥文件配置错误节点之间会无法通信表现为一直选不出主节点。这时候看日志会有明显的认证失败记录。排查时先确认密钥文件内容一致、权限正确、路径无误。4.3 权限最小化的落地实践与验证权限最小化不是一句口号要落到具体操作上。我通常的做法是先给一个“只读”账号让应用跑起来观察它实际需要哪些写操作再逐步放开。比如一个报表服务理论上只需要读权限。那就先给它read角色db.createUser({ user: report_reader, pwd: ReadOnly2024, roles: [ { role: read, db: business_db } ] })跑一段时间如果发现它需要写一些临时结果再考虑加一个只针对临时集合的写权限而不是直接给readWrite。这样即使账号泄露影响范围也可控。验证权限是否生效可以用这个账号连上去尝试执行超出权限的操作。比如用report_reader尝试插入数据db.logs.insertOne({ test: 1 })如果返回权限错误说明只读角色生效了。如果插入成功那说明角色配错了要回去检查。4.4 认证信息的查看与审计配完认证不是就完了还得能查。查看当前数据库有哪些用户use admin db.system.users.find()这个命令会列出所有用户及其角色。注意用户信息是分库存储的admin库下的system.users只显示admin库的用户。要查其他库的用户得先use到那个库再查。查看某个用户的详细信息db.getUser(app_user)返回结果里会包含这个用户的角色列表和权限继承关系。如果角色是通过自定义角色间接赋予的这里也能看到完整的权限链。审计方面数据库本身有审计日志功能但需要额外配置。如果合规要求高可以开启审计记录所有认证尝试和权限操作。审计日志的量会很大要提前规划存储和轮转策略。5. 常见问题与排查技巧实录5.1 认证失败的高频原因速查认证问题排查我整理了一个速查表覆盖了大部分常见情况现象可能原因排查方法连接被拒绝认证未启用或用户不存在检查配置文件authorization项确认用户已创建认证失败密码错误或认证库不对确认--authenticationDatabase参数指向正确的库权限不足角色未分配或角色粒度不够用db.getUser()查看角色确认权限覆盖操作节点无法加入集群密钥文件不一致或权限错误比对各节点密钥文件哈希检查文件权限重启后无法连接管理员密码遗忘或角色丢失需要进入本地host例外模式重置操作复杂需谨慎这个表里的每一行我都实际遇到过。特别是“认证库不对”这一条新手特别容易踩。用户建在business_db下连接的时候却用admin作为认证库自然认证失败。认证库必须和用户所在的库一致。5.2 被锁在门外的应急处理方案最尴尬的情况是认证开了但管理员密码忘了或者管理员角色被误删了。这时候常规连接已经进不去了需要走应急流程。应急流程的核心是临时关闭认证重置管理员再重新开启认证。具体操作停掉服务修改配置文件把authorization改成disabled重启服务。这时候可以无认证连接重新创建或修改管理员用户。改完之后再把authorization改回enabled重启。这个过程有风险因为关闭认证的窗口期内任何能连上的人都能操作数据。所以操作要快最好在维护窗口内进行并且确保网络层面没有外部访问。提示应急流程只适用于单机或副本集的主节点。分片集群环境下关闭认证会导致路由节点和配置节点之间的通信也失效操作更复杂建议提前做好管理员账号的备份和记录。5.3 权限溢出与越权访问的排查权限溢出是指用户实际拥有的权限超过了预期。这种情况往往是角色分配时手滑给了过大的角色。排查方法是用该用户登录执行db.runCommand({ connectionStatus: 1 })返回结果里会列出当前用户的所有权限。如果发现权限溢出用revokeRolesFromUser收回多余角色db.revokeRolesFromUser(app_user, [ { role: readWrite, db: business_db } ])收回后再验证一次确认权限已经收紧。越权访问的另一种情况是用户通过某个集合的权限间接访问到了其他集合的数据。比如给了readWrite角色这个角色对所有集合都有读写权限包括系统集合。如果业务上不需要访问系统集合就应该用自定义角色只针对业务集合授权。5.4 认证性能影响的实测与调优认证本身对性能的影响很小但在高并发场景下频繁的认证握手会带来额外开销。实测下来开启认证后简单查询的延迟增加在毫秒级别基本可以忽略。但如果应用没有使用连接池每次请求都新建连接并认证开销就会累积。优化方法是使用连接池让连接复用。大多数数据库驱动都支持连接池配置设置合理的池大小和空闲超时可以显著降低认证开销。另外如果用了TLSTLS握手比认证握手更耗资源连接池同样能缓解。还有一个容易被忽略的点认证缓存的配置。某些驱动支持认证结果缓存在一定时间内复用认证状态减少重复认证。这个配置因驱动而异需要查对应驱动的文档。6. 我个人在实际操作中的几点体会配了这么多套认证有几个体会是文档里不会写的。第一认证配置要趁早。很多团队是上线前才想起来配这时候数据已经堆了一堆用户也建了一堆改起来牵一发动全身。最好是在项目初始化阶段就把认证框架搭好后面只是往里加用户和角色不会有大改动。第二密码管理要有工具支撑。靠人记密码迟早出事。我用过的最稳的方案是结合密钥管理服务应用启动时动态获取数据库密码不落盘、不硬编码。这样即使配置文件泄露密码也不会泄露。第三定期审计角色分配。时间长了角色会越加越多有些是临时加的忘了删。我习惯每季度过一遍用户和角色列表把不再使用的账号禁用或删除。这个习惯帮我避免了好几次潜在的风险。第四测试环境也要开认证。很多人觉得测试环境无所谓但测试环境的配置往往会复制到生产如果测试环境没开认证生产环境很可能也忘了开。保持一致减少人为失误。最后分享一个小技巧创建用户的时候在用户名里带上用途和创建日期比如app_writer_202401。这样一看就知道这个账号是干什么的、什么时候建的审计的时候特别方便。角色命名也同理用role_log_insert_202401这种格式比role1、role2清晰得多。
1. 为什么数据库认证不是“可选项”而是“必答题”很多刚接触文档型数据库的朋友第一次把服务跑起来的时候往往只关心一件事能不能连上、能不能读写。默认配置下本地起一个实例端口一开客户端一连数据就进去了整个过程顺畅得让人不想去碰任何额外设置。这种“零配置”的体验确实舒服但它背后藏着一个很现实的问题——默认状态下数据库几乎不设防。我见过不少项目开发阶段图省事直接把实例暴露在内网甚至公网上认证机制完全没开。等到上线前做安全检查才发现一堆问题谁都能连、谁都能删库、谁都能把整个集合清空。更麻烦的是有些团队以为“内网就安全”结果一台机器被攻破横向渗透到数据库数据直接被拖走。这类事故的根源往往不是多高深的技术漏洞而是认证这一层根本没做。所谓安全认证说白了就是回答三个问题你是谁、你能干什么、你干了什么。第一个是身份验证第二个是权限控制第三个是审计追溯。这三件事在文档型数据库里都有对应的机制只是很多人没系统地去配过。这篇内容就是围绕这套机制展开的从最基础的账号密码到角色权限的细粒度划分再到内部成员之间的认证最后落到实际排查问题的经验上。适合谁来读如果你是刚接手数据库运维的开发或者正在做上线前的安全加固又或者你只是想让自己的本地环境别那么“裸奔”那这篇内容基本能覆盖你需要的操作路径。我会尽量把每一步为什么这么做讲清楚而不是只丢几条命令让你照抄。毕竟认证这东西配错了比不配还危险——你以为锁上了其实门还开着。2. 认证机制的整体设计与选型思路2.1 从“谁能进”到“能进哪间房”的分层逻辑刚上手的时候很多人会把“认证”和“授权”混为一谈。其实这是两件事而且顺序不能乱。认证解决的是“你是不是你说的那个人”授权解决的是“你进来之后能碰哪些东西”。数据库在这两块是分开设计的配置的时候也要分开考虑。先看认证。文档型数据库支持多种认证方式常见的有这么几类基于用户名密码的挑战应答、基于证书的双向验证、以及面向内部集群成员的密钥文件认证。每种方式适用的场景不一样。用户名密码适合大多数应用连接配置简单客户端支持广证书认证适合对传输安全要求更高的场景但证书的签发和轮换会带来额外运维成本密钥文件则是集群内部节点互相识别用的不对外部客户端开放。再看授权。授权是建立在认证之上的只有先确认了身份才能谈这个身份拥有哪些权限。数据库把权限抽象成“角色”每个角色绑定一组对特定数据库、特定集合的操作许可。你可以把角色理解成一把钥匙钥匙上刻着“只能开A房间的抽屉不能开B房间的门”。给用户分配角色就是给他发钥匙的过程。这里有个设计上的取舍值得说清楚为什么不直接给用户逐个分配权限而要用角色因为用户数量会增长权限需求会变化如果每个用户都单独配一遍维护成本会指数级上升。角色相当于一层中间抽象把“权限集合”和“用户”解耦。你改角色所有绑了这个角色的用户自动生效你加用户直接绑现成的角色就行。这是典型的用一层间接性换可维护性的做法。2.2 认证方式的选择依据与适用边界具体到选哪种认证方式我的经验是按部署形态来分。单机实例、副本集、分片集群这三种形态对认证的要求是不一样的。单机实例最简单开个用户名密码认证就够了。副本集稍微复杂一点因为节点之间要互相通信除了外部客户端的认证还得配内部成员认证否则节点之间没法建立信任关系。分片集群更麻烦除了副本集那套还要考虑路由节点和配置节点之间的认证。内部成员认证通常用密钥文件所有节点共享同一个密钥。这个密钥的作用相当于“内部通行证”节点拿着它互相验证身份。密钥文件的安全等级要求很高权限必须收紧不能让普通用户读到。我见过有人图方便把密钥文件放在共享目录里权限设成所有人可读这等于把内部通行证复印了一份贴在公告栏上。外部客户端认证则要根据实际需求来。如果应用和数据库在同一台机器上或者在内网可信环境里用户名密码基本够用。如果跨网络传输或者合规要求比较高那就得上证书。证书的好处是双向验证客户端要验证服务端服务端也要验证客户端中间人很难插进来。代价是证书管理麻烦过期了要换吊销了要更新这些都得提前规划。提示认证方式一旦启用就不能随便关掉。有些团队在测试环境开了认证上线时嫌麻烦想关掉结果发现关不掉了——因为系统库里的用户数据已经存在关掉认证反而会导致连接异常。所以启用之前要想清楚这是单向操作。2.3 角色权限模型的设计哲学角色权限这块数据库内置了一套角色覆盖了从“只读”到“超级用户”的各种粒度。内置角色的好处是开箱即用坏处是粒度可能不完全贴合你的业务需求。比如你有一个只负责写日志的账号内置的“读写”角色对它来说权限太大了它不需要读其他集合也不需要删数据。这时候就需要自定义角色。自定义角色的思路是先列出这个身份需要做哪些操作再把这些操作映射到具体的权限上最后打包成一个角色。比如一个“日志写入者”角色只需要对日志集合有插入权限不需要查询、更新、删除。这样即使这个账号泄露了攻击者也只能往里塞垃圾数据没法把已有数据读走或删掉。这里有个容易被忽略的点权限是分数据库的。一个用户可以在A数据库有读写权限在B数据库只有只读权限在C数据库完全没有权限。这种设计让多租户场景变得很自然——不同业务共用一套数据库实例但彼此的数据互相隔离。配置的时候要特别注意别一不小心给了某个用户全局权限那就等于把整栋楼的钥匙都给他了。3. 核心细节解析与实操要点3.1 启用认证前的准备工作与顺序启用认证这件事顺序特别重要。如果顺序错了很可能把自己锁在门外。正确的流程是这样的第一步先在不开启认证的状态下连上数据库创建管理员用户。这个管理员用户必须建在admin数据库下因为admin是管理库管理员角色也在这里。创建的时候要指定角色通常是userAdminAnyDatabase加上readWriteAnyDatabase或者直接给root。root角色权限最大能操作所有数据库和所有功能适合做超级管理员。第二步验证管理员用户能正常登录。这一步别跳过我见过有人创建完用户直接就去改配置文件开认证结果重启后发现密码记错了或者角色没给对连都连不上只能删数据目录重来。验证的方法是用管理员账号连一次执行个简单命令比如查看当前用户确认返回正常。第三步修改配置文件启用认证。配置项通常是security.authorization设成enabled。改完重启服务。第四步重启后用管理员账号登录再创建业务用户。业务用户建在对应的业务数据库下分配最小必要权限。这个顺序的核心逻辑是认证开启后没有账号就进不去所以账号必须在开启前就建好。而管理员账号又必须在admin库下建因为只有admin库的管理员才有权限去创建其他库的用户。这是一环扣一环的。注意创建第一个管理员用户时数据库处于“本地host例外”状态也就是允许无认证连接。这个窗口期很短一旦第一个用户创建成功这个例外就关闭了。所以创建动作要一次成功别中途断开。3.2 用户创建与角色分配的具体操作创建用户的命令结构不复杂但参数含义要搞清楚。以创建一个业务读写用户为例db.createUser({ user: app_writer, pwd: ComplexPassw0rd!, roles: [ { role: readWrite, db: business_db } ] })这里user是用户名pwd是密码roles是角色数组。角色可以指定多个每个角色绑定一个数据库。上面这个例子就是给app_writer在business_db上赋予读写权限。如果要创建自定义角色步骤稍微多一点。先定义角色指定它的权限集合db.createRole({ role: log_inserter, privileges: [ { resource: { db: business_db, collection: logs }, actions: [insert] } ], roles: [] })这个自定义角色只允许往business_db的logs集合插入数据其他什么都不行。privileges数组里每个元素描述一个资源加一组动作。resource指定数据库和集合actions指定允许的操作比如insert、find、update、remove等。创建完角色后再把这个角色分配给用户db.grantRolesToUser(app_writer, [ { role: log_inserter, db: business_db } ])这样app_writer就同时拥有了readWrite和log_inserter两个角色的权限。权限是叠加的不是覆盖的。这里有个实操心得密码策略要提前定好。数据库本身对密码复杂度没有强制要求你设个“123456”它也能接受。但从安全角度密码长度至少12位包含大小写字母、数字和特殊符号。更好的做法是结合密钥管理服务定期轮换密码。我见过太多因为密码太简单被撞库的案例真不是危言耸听。3.3 内部成员认证的密钥文件配置副本集和分片集群的内部认证用的是密钥文件。这个文件的生成方式很简单内容就是一串随机字符长度建议在6到1024个字符之间。生成方法可以用系统自带的随机数工具openssl rand -base64 756 /path/to/keyfile chmod 400 /path/to/keyfile chown mongodb:mongodb /path/to/keyfile这里chmod 400是关键意思是只有文件所有者能读其他人连读的权限都没有。chown是把文件所有权给数据库进程的运行用户。这两步不做数据库启动时会报权限错误拒绝加载密钥文件。密钥文件配好之后要在每个节点的配置文件里指定路径security: keyFile: /path/to/keyfile authorization: enabled所有节点的密钥文件内容必须完全一致。如果某个节点的密钥文件和其他节点不一样它就无法加入集群会一直卡在启动阶段。排查这类问题时先比对各节点密钥文件的哈希值确认内容一致。提示密钥文件不要放在版本控制里也不要通过明文渠道传输。部署的时候用配置管理工具分发或者手动拷贝后立即删除中间文件。密钥泄露等于集群内部信任关系被破坏后果比单个用户密码泄露严重得多。3.4 认证与传输加密的配合使用认证解决的是“你是谁”但认证过程本身如果走明文传输密码就可能被截获。所以认证和传输加密通常是配合使用的。传输加密用的是TLS配置项在net.tls下面。启用TLS需要准备证书和私钥。服务端证书用来向客户端证明自己的身份如果开启双向验证还需要客户端证书。配置大概长这样net: tls: mode: requireTLS certificateKeyFile: /path/to/server.pem CAFile: /path/to/ca.pemmode设成requireTLS表示强制所有连接都走TLS不接受明文连接。certificateKeyFile是服务端证书和私钥的合并文件CAFile是证书颁发机构的证书用来验证客户端证书。这里有个细节TLS和认证是独立配置的但建议一起开。只开认证不开TLS密码在网络里裸奔只开TLS不开认证加密通道里谁都能进。两个都开才是完整的防护。证书的轮换是个麻烦事。证书有有效期到期前要更新。更新的时候不能直接替换文件重启那样会导致连接中断。正确的做法是滚动更新先更新一个节点等它恢复正常再更新下一个。副本集环境下只要多数节点在线服务就不会中断。4. 实操过程与核心环节实现4.1 单机环境从零到一的认证配置全流程假设你刚装好数据库服务已经跑起来了现在要加上认证。完整流程如下。先连上实例创建管理员use admin db.createUser({ user: site_admin, pwd: Adm1nSecure2024, roles: [root] })执行成功后会返回一个确认信息表示用户已创建。这时候别急着退出先验证一下db.auth(site_admin, Adm1nSecure2024)返回1表示认证成功。如果返回0或者报错说明用户名密码不对或者角色没给对。确认无误后再进行下一步。然后编辑配置文件找到security部分加上security: authorization: enabled保存后重启服务。重启完成后再连数据库这时候不认证就什么都做不了了。用管理员账号登录mongo --username site_admin --password --authenticationDatabase admin回车后会提示输入密码。登录成功后创建业务用户use business_db db.createUser({ user: app_user, pwd: AppPass2024!, roles: [ { role: readWrite, db: business_db } ] })到这里单机环境的认证就配好了。业务应用用app_user连接管理员用site_admin管理。4.2 副本集环境的认证部署与验证副本集比单机多一层内部认证。假设你有三个节点部署流程是这样的。先在其中一个节点上以不开启认证的方式启动创建管理员用户。注意副本集环境下创建用户要在主节点上操作。怎么判断哪个是主节点连上去执行rs.status()看stateStr字段值是PRIMARY的就是主节点。创建管理员用户的命令和单机一样。创建完成后生成密钥文件分发到三个节点权限都设成400。然后修改三个节点的配置文件都加上security: keyFile: /path/to/keyfile authorization: enabled replication: replSetName: rs0三个节点依次重启。重启后用管理员账号连上主节点执行rs.status()确认三个节点状态正常。如果某个节点状态是STARTUP2或者RECOVERING说明它还没同步完等一会儿再看。验证内部认证是否生效可以尝试用一个没有权限的账号去连从节点。如果连不上或者只能读不能写说明认证起作用了。从节点默认是只读的这是副本集的特性和认证无关。注意副本集环境下如果密钥文件配置错误节点之间会无法通信表现为一直选不出主节点。这时候看日志会有明显的认证失败记录。排查时先确认密钥文件内容一致、权限正确、路径无误。4.3 权限最小化的落地实践与验证权限最小化不是一句口号要落到具体操作上。我通常的做法是先给一个“只读”账号让应用跑起来观察它实际需要哪些写操作再逐步放开。比如一个报表服务理论上只需要读权限。那就先给它read角色db.createUser({ user: report_reader, pwd: ReadOnly2024, roles: [ { role: read, db: business_db } ] })跑一段时间如果发现它需要写一些临时结果再考虑加一个只针对临时集合的写权限而不是直接给readWrite。这样即使账号泄露影响范围也可控。验证权限是否生效可以用这个账号连上去尝试执行超出权限的操作。比如用report_reader尝试插入数据db.logs.insertOne({ test: 1 })如果返回权限错误说明只读角色生效了。如果插入成功那说明角色配错了要回去检查。4.4 认证信息的查看与审计配完认证不是就完了还得能查。查看当前数据库有哪些用户use admin db.system.users.find()这个命令会列出所有用户及其角色。注意用户信息是分库存储的admin库下的system.users只显示admin库的用户。要查其他库的用户得先use到那个库再查。查看某个用户的详细信息db.getUser(app_user)返回结果里会包含这个用户的角色列表和权限继承关系。如果角色是通过自定义角色间接赋予的这里也能看到完整的权限链。审计方面数据库本身有审计日志功能但需要额外配置。如果合规要求高可以开启审计记录所有认证尝试和权限操作。审计日志的量会很大要提前规划存储和轮转策略。5. 常见问题与排查技巧实录5.1 认证失败的高频原因速查认证问题排查我整理了一个速查表覆盖了大部分常见情况现象可能原因排查方法连接被拒绝认证未启用或用户不存在检查配置文件authorization项确认用户已创建认证失败密码错误或认证库不对确认--authenticationDatabase参数指向正确的库权限不足角色未分配或角色粒度不够用db.getUser()查看角色确认权限覆盖操作节点无法加入集群密钥文件不一致或权限错误比对各节点密钥文件哈希检查文件权限重启后无法连接管理员密码遗忘或角色丢失需要进入本地host例外模式重置操作复杂需谨慎这个表里的每一行我都实际遇到过。特别是“认证库不对”这一条新手特别容易踩。用户建在business_db下连接的时候却用admin作为认证库自然认证失败。认证库必须和用户所在的库一致。5.2 被锁在门外的应急处理方案最尴尬的情况是认证开了但管理员密码忘了或者管理员角色被误删了。这时候常规连接已经进不去了需要走应急流程。应急流程的核心是临时关闭认证重置管理员再重新开启认证。具体操作停掉服务修改配置文件把authorization改成disabled重启服务。这时候可以无认证连接重新创建或修改管理员用户。改完之后再把authorization改回enabled重启。这个过程有风险因为关闭认证的窗口期内任何能连上的人都能操作数据。所以操作要快最好在维护窗口内进行并且确保网络层面没有外部访问。提示应急流程只适用于单机或副本集的主节点。分片集群环境下关闭认证会导致路由节点和配置节点之间的通信也失效操作更复杂建议提前做好管理员账号的备份和记录。5.3 权限溢出与越权访问的排查权限溢出是指用户实际拥有的权限超过了预期。这种情况往往是角色分配时手滑给了过大的角色。排查方法是用该用户登录执行db.runCommand({ connectionStatus: 1 })返回结果里会列出当前用户的所有权限。如果发现权限溢出用revokeRolesFromUser收回多余角色db.revokeRolesFromUser(app_user, [ { role: readWrite, db: business_db } ])收回后再验证一次确认权限已经收紧。越权访问的另一种情况是用户通过某个集合的权限间接访问到了其他集合的数据。比如给了readWrite角色这个角色对所有集合都有读写权限包括系统集合。如果业务上不需要访问系统集合就应该用自定义角色只针对业务集合授权。5.4 认证性能影响的实测与调优认证本身对性能的影响很小但在高并发场景下频繁的认证握手会带来额外开销。实测下来开启认证后简单查询的延迟增加在毫秒级别基本可以忽略。但如果应用没有使用连接池每次请求都新建连接并认证开销就会累积。优化方法是使用连接池让连接复用。大多数数据库驱动都支持连接池配置设置合理的池大小和空闲超时可以显著降低认证开销。另外如果用了TLSTLS握手比认证握手更耗资源连接池同样能缓解。还有一个容易被忽略的点认证缓存的配置。某些驱动支持认证结果缓存在一定时间内复用认证状态减少重复认证。这个配置因驱动而异需要查对应驱动的文档。6. 我个人在实际操作中的几点体会配了这么多套认证有几个体会是文档里不会写的。第一认证配置要趁早。很多团队是上线前才想起来配这时候数据已经堆了一堆用户也建了一堆改起来牵一发动全身。最好是在项目初始化阶段就把认证框架搭好后面只是往里加用户和角色不会有大改动。第二密码管理要有工具支撑。靠人记密码迟早出事。我用过的最稳的方案是结合密钥管理服务应用启动时动态获取数据库密码不落盘、不硬编码。这样即使配置文件泄露密码也不会泄露。第三定期审计角色分配。时间长了角色会越加越多有些是临时加的忘了删。我习惯每季度过一遍用户和角色列表把不再使用的账号禁用或删除。这个习惯帮我避免了好几次潜在的风险。第四测试环境也要开认证。很多人觉得测试环境无所谓但测试环境的配置往往会复制到生产如果测试环境没开认证生产环境很可能也忘了开。保持一致减少人为失误。最后分享一个小技巧创建用户的时候在用户名里带上用途和创建日期比如app_writer_202401。这样一看就知道这个账号是干什么的、什么时候建的审计的时候特别方便。角色命名也同理用role_log_insert_202401这种格式比role1、role2清晰得多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
