第 21 章：安全

这是《MongoDB 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 MongoDB 常保存用户资料、业务订单、日志和敏感行为数据。安全治理要覆盖网络边界、认证授权、TLS、字段级敏感信息、审计和密钥生命周期。

21.1 访问控制

启用认证后，所有客户端必须使用用户连接。

创建管理员：

use admin

db.createUser({
  user: "admin",
  pwd: passwordPrompt(),
  roles: [{ role: "userAdminAnyDatabase", db: "admin" }]
})

创建业务用户：

use shop

db.createUser({
  user: "shop_app",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "shop" }
  ]
})

不要让所有服务共享管理员账号。

21.2 内置角色

原则：

1. 业务应用 readWrite；
2. 报表只读；
3. 运维按操作分段授权；
4. 监控 clusterMonitor；
5. root 仅 break-glass。

21.3 自定义角色

限制集合：

use shop

db.createRole({
  role: "orderReader",
  privileges: [
    {
      resource: { db: "shop", collection: "orders" },
      actions: ["find"]
    }
  ],
  roles: []
})

适用：

1. 只读某集合；
2. 只允许特定操作；
3. 审计查询；
4. 内部平台数据视图。

21.4 网络隔离

生产建议：

1. mongod 只监听内网地址；
2. 不把 27017 暴露公网；
3. 使用防火墙或安全组；
4. 按环境隔离 VPC；
5. mongos 和应用同受控网络；
6. 运维通过堡垒机；
7. 分片组件之间限制来源。

查看监听：

ss -lntp | grep 27017

21.5 TLS

连接串示例：

mongodb://user:pass@mongo1,mongo2,mongo3/shop?replicaSet=rs0&tls=true&authSource=admin

启用前验证：

1. 证书有效期；
2. 证书 SAN；
3. CA 分发；
4. 客户端驱动兼容；
5. 性能影响；
6. 轮转流程；
7. 回滚方式。

21.6 字段级安全

MongoDB 的权限通常到集合或库级别，字段级访问需要应用层或查询视图治理。

示例只读视图：

db.createView("user_public", "users", [
  { $project: {
      _id: 1,
      nickname: 1,
      city: 1
  }}
])

原则：

1. 密码只保存哈希；
2. 手机号和身份证脱敏；
3. token 不明文入库；
4. 大敏感数据加密；
5. 应用日志同步脱敏；
6. 查询导出需审批。

21.7 审计

企业版提供审计能力，具体能力与版本和发行版有关。至少应审计：

1. 登录成功和失败；
2. 用户与角色变更；
3. 权限变更；
4. 集合和索引管理；
5. 备份恢复；
6. 高危运维命令；
7. 敏感集合查询和导出。

应用层也应保存业务操作审计。

21.8 密钥管理

要求：

1. 密码和证书不写入代码仓库；
2. 使用 KMS、Secret 或云托管身份；
3. 定期轮转；
4. 不同环境不同凭据；
5. 副本集 keyfile 权限受控；
6. 泄露后立即吊销；
7. 记录凭据使用。

检查文件权限：

ls -l /etc/mongo-keyfile

21.9 注入与查询安全

驱动使用结构化查询，不拼接字符串。应用层：

1. 不接受用户传入任意操作符；
2. 限制可查询字段；
3. 限制返回条数；
4. 查询超时；
5. 敏感字段过滤；
6. 导出限流。

示例拒绝用户直接提交 $where。

21.10 常见风险

本章小结

MongoDB 安全从网络隔离和认证授权开始，再到 TLS、最小权限、字段脱敏、审计和密钥治理。集合级权限不能完全替代应用层数据安全，两者需要配合。

思考题

1. 为什么业务应用不应使用 root？
2. 自定义角色适合什么场景？
3. 视图能否替代字段级权限？
4. TLS 上线前要验证什么？
5. 哪些操作必须进入审计？