MongoDB数据库权限精细化管控方案

MongoDB的权限管理在很多生产环境里其实处于一种“粗放”状态。最常见的问题不是没有建用户，而是权限给得太宽：开发、测试、运维、报表、备份等不同角色共用同一个高权限账号，或者干脆用root账号连接业务系统。这种做法在早期开发阶段看不出问题，一旦数据规模上来、合规审计介入、或者发生误操作导致数据丢失，权限失控的代价会立刻显现。精细化管控的核心不是简单地把权限“收紧”，而是按照最小权限原则，把数据库操作权限拆解到库级别、集合级别，甚至配合集群分片和审计策略，让每个访问者只能做被明确允许的事情。

MongoDB的授权模型和传统关系型数据库有本质区别。它没有库级用户的概念，用户定义在全局，通过角色（Role）把权限授予用户。角色内部包含一组资源（Resource）和一组动作（Action）。资源可以细到集群、数据库、集合，动作则对应find、insert、update、remove、createCollection、dropDatabase等具体操作。理解这一点非常重要，因为很多管理员习惯性地认为“给某个库建个用户”就够了，但实际上MongoDB用户是全局的，权限范围由角色里的资源定义决定。

内置角色虽然方便，但粒度有限。比如readWrite角色允许对目标数据库中的所有集合执行读写操作，这在业务上往往过宽。一个订单服务的账号如果拥有整个订单库的readWrite权限，那么它不仅能读写订单表，还能读写支付流水表、日志表甚至误删整个集合。精细化管控的第一步，就是放弃对内置角色的过度依赖，改用自定义角色，把权限精确到集合级别。

权限设计不能凭空想象，必须从实际访问场景倒推。以一个典型的电商后端为例，至少存在这样几类访问者：订单服务、库存服务、报表任务、备份脚本、DBA人工排查、审计系统。每一类访问者需要访问的库和集合不同，操作类型也不同。

订单服务需要读写订单集合，可能还需要读取商品快照集合，但绝不应该有权限删除订单集合或修改商品主数据。库存服务需要原子性地扣减库存，通常只需要对库存集合执行findAndModify或者事务内的update操作，不需要insert或remove。报表任务只需要读，而且可能只读某个时间范围内的数据，虽然MongoDB权限模型不支持行级控制，但可以通过单独的只读视图或者只读账号限制其影响面。备份脚本需要读取所有数据，但绝对不能写入。DBA人工排查可能需要临时授权，但必须有时效性。

把这些场景列成表格，每一行是一个角色，每一列是具体的库和集合，交叉点填写允许的动作。这个权限矩阵是后续创建角色的依据，也是审计和变更管理的基础。没有矩阵就直接在数据库上操作，很容易出现权限蔓延。

假设现在有一个数据库叫shop，里面有三个集合：orders、inventory、product_snapshot。订单服务只需要操作orders集合和读取product_snapshot集合。可以这样创建一个自定义角色：

use admin
db.createRole({
  role: "orderServiceRole",
  privileges: [
    {
      resource: { db: "shop", collection: "orders" },
      actions: ["find", "insert", "update", "remove"]
    },
    {
      resource: { db: "shop", collection: "product_snapshot" },
      actions: ["find"]
    }
  ],
  roles: []
})

这个角色创建在admin库下，但权限资源指向shop库的具体集合。接着创建用户并只授予这个角色：

use admin
db.createUser({
  user: "order_svc",
  pwd: "强密码",
  roles: [ { role: "orderServiceRole", db: "admin" } ]
})

注意roles数组里引用自定义角色时要指定角色所在的数据库，这里角色建在admin库，所以db字段填admin。这样order_svc用户登录后，只能对shop.orders执行增删改查，对shop.product_snapshot只能查询，对其他任何集合都没有权限。这种集合级控制在生产环境中非常关键，能有效防止一个业务模块的漏洞波及其他数据。

有些场景下，即使集合级权限也不够细。比如报表系统只需要orders集合中状态为已完成且创建时间在最近90天的数据。直接给报表账号授予orders集合的find权限，意味着它能读取所有订单，包括未支付、已取消以及历史敏感数据。MongoDB没有原生的行级权限，但可以通过创建只读视图来间接实现。

先由高权限管理员创建一个视图：

use shop
db.createView(
  "orders_report_view",
  "orders",
  [
    { $match: { status: "completed", createdAt: { $gte: new Date(Date.now() - 90*24*60*60*1000) } } }
  ]
)

然后给报表角色授予这个视图的find权限，而不是底层orders集合的权限。报表账号查询orders_report_view时，只能看到过滤后的数据。这种方式把权限控制从“能看哪个集合”推进到“能看集合里的哪部分数据”，虽然需要额外维护视图定义，但在合规要求较高的场景下非常值得。

分片集群的权限管理比单机副本集复杂。用户和角色信息存储在配置服务器的admin库中，mongos负责转发权限校验。在分片集群里创建用户和角色必须通过mongos执行，不能直接连到分片节点操作。另外，分片集群中的某些操作需要集群级权限，比如splitVector、moveChunk、enableSharding等。如果业务账号不需要做分片管理，绝对不要授予clusterManager或clusterAdmin角色。

还有一个容易被忽略的点：分片集群中，如果对某个分片集合做查询，mongos会先检查用户对该集合的权限，再路由到具体分片。权限校验发生在mongos层，所以只要mongos配置正确，分片节点本身不需要单独建用户。但如果有人绕过mongos直连分片节点，权限控制就会失效。因此生产环境必须启用访问控制，并且关闭分片节点的外部直连端口，或者通过防火墙限制只能由mongos访问分片。

精细化管控不仅是“设好权限”，还包括“权限变更可追踪”和“临时权限可回收”。MongoDB企业版提供审计功能，可以记录所有认证和授权事件。社区版虽然没有原生审计，但可以通过日志级别和第三方工具实现基本追踪。至少要做到：每次创建、修改、删除用户或角色时，记录操作人、时间、变更内容。权限变更不应该直接在命令行随意执行，而应该纳入变更管理流程。

临时授权是另一个常见痛点。DBA排查问题可能需要临时读取某个敏感集合，或者开发人员需要临时执行一次数据修复脚本。如果直接给高权限角色，用完忘记回收，就会留下长期风险。建议的做法是创建带有过期时间的临时用户，MongoDB支持在createUser时指定authenticationRestrictions和自定义的过期机制。虽然原生不支持用户自动过期，但可以通过在用户文档中设置自定义字段，配合定时任务清理。更简单的方式是使用临时角色，用完立即撤销，并在变更记录中标注临时授权的原因和期限。

数据库权限不是孤立存在的，必须和网络访问控制、传输加密配合。即使权限设计得再精细，如果数据库端口暴露在公网，或者内网中任何机器都能直连数据库端口，攻击面依然很大。生产环境至少要做到：MongoDB只监听内网地址，通过安全组或防火墙限制只有应用服务器和运维跳板机可以访问数据库端口。同时启用TLS/SSL加密客户端与数据库之间的通信，防止认证信息在传输中被窃取。

对于跨机房或跨云部署的场景，还可以使用MongoDB的认证机制扩展，比如LDAP集成或Kerberos认证。这样数据库账号可以与企业统一身份认证打通，员工离职时在LDAP侧禁用账号，数据库访问权限自动失效，避免出现“人走了数据库账号还在”的情况。

在实际运维中，权限配置错误往往表现为“明明给了权限却报未授权”或者“权限给多了没发现”。前者通常是因为角色定义中的资源范围写错，比如把db字段写成了admin，而实际要授权的库是shop；或者自定义角色创建在非admin库，但用户引用时db字段填错。排查时可以用db.getUser()和db.getRole()查看用户和角色的详细定义，确认资源路径和动作列表。

权限给多了的问题更隐蔽。一个快速检查的方法是定期用db.runCommand({ usersInfo: 1 })导出所有用户及其角色，然后人工或脚本比对权限矩阵，找出超出矩阵范围的授权。对于内置角色，尤其要关注readAnyDatabase、userAdminAnyDatabase、clusterAdmin这类全局性角色，它们应该只授予极少数运维人员，而且最好配合审计。

另外，MongoDB的权限继承机制也容易造成误解。如果给一个用户同时授予了多个角色，最终权限是所有角色权限的并集。所以在设计角色时，不要让角色之间出现重叠过多的情况，否则时间长了很难理清一个用户到底能做什么。保持角色职责单一，用户按需组合角色，比创建一堆大而全的角色更清晰。

对于已经上线的系统，权限收紧不能一蹴而就，否则可能影响业务。建议分阶段推进：第一阶段，梳理现有账号和角色，形成权限清单，识别出使用root或高权限内置角色的业务连接。第二阶段，为每个业务连接创建最小权限的自定义角色，在测试环境验证通过后，再在生产环境切换。第三阶段，回收不再需要的高权限角色，启用审计和定期权限复查机制。整个过程需要开发、运维、DBA协作，尤其是业务方要明确自己的数据访问需求，否则DBA无法准确设计权限矩阵。

MongoDB的权限精细化管控不是一次性的配置工作，而是一个持续的过程。随着业务迭代、新集合上线、人员变动，权限矩阵需要不断更新。把权限管理纳入代码发布和运维变更流程中，才能真正避免权限失控带来的数据安全风险。