微服务必须用独立数据库和用户实现数据隔离，mongodb需按库创建用户并限制权限，禁用跨库操作；凭证须环境注入、加密管理、定期轮换；网络层强制tls和ip白名单；监控连接与权限使用，杜绝硬编码和日志泄露。
每个服务用独立数据库 + 独立用户，别共用 admin
微服务间数据隔离是底线，共用数据库或账号等于把所有钥匙塞进一个铁盒——丢一个，全军覆没。MongoDB 没有 schema-level 权限，只有 database-level，所以 service-a 的数据必须存在 service_a_db 里，且只给 service_a_user 对该库的 readWrite 权限（绝不给 admin 或跨库权限）。
常见错误现象：MongoServerError: not authorized on config to execute command { listCollections: 1 }——这是服务尝试读其他库元数据，说明权限收得太松或应用误用了全局连接。
- 创建用户时显式指定
db：用db.createUser()在目标库（如service_a_db）下执行，不是在admin - 连接字符串里写死数据库名：
mongodb://service_a_user:pwd@host:27017/service_a_db，避免应用连上后手动use切库 - 禁用
listDatabases权限：默认角色不包含它，但自定义角色时务必确认没加上
凭证不硬编码、不进 Git，走环境注入 + 短期轮换
把 MONGODB_URI 写进 .env 提交到仓库？等于把保险柜密码贴在门上。Kubernetes 用 Secret，Docker Compose 用 env_file 配合 .gitignore，本地开发用 dotenv 加密加载——核心是凭证生命周期与代码解耦。
使用场景：CI/CD 流水线部署新服务时，自动调用 MongoDB Ops Manager 或脚本生成临时用户（TTL 24h），凭据只存入 K8s Secret，Pod 启动时挂载为环境变量。
- 禁止在代码里拼接 URI：
process.env.MONGODB_USER + ':' + process.env.MONGODB_PASS—— 容易泄露、难审计 - URI 中密码需
encodeURIComponent()：特殊字符（如/、@）不转义会导致解析失败，错误信息是MongoParseError: Invalid connection string - 轮换时别只改密码：同步更新
userRoles，旧用户删掉，避免残留权限
网络层加固比账号密码更重要
再强的密码也防不住端口暴露在公网。几十个服务如果都直连 MongoDB，攻击面指数级扩大。必须收口：只允许内部服务网段（如 10.10.0.0/16）访问 MongoDB 节点，且强制 TLS 1.2+（ssl=true&tlsCAFile=ca.pem）。
性能影响：TLS 握手增加约 5–10ms 延迟，但比一次凭证泄露代价小得多；兼容性上，Node.js 驱动 v4+ 默认启用 TLS，老版本需显式设 sslValidate: true。
- 防火墙规则优先于 MongoDB 授权：先封外网 IP，再配用户权限，顺序反了等于裸奔
- 别信“内网就安全”：容器网络、云 VPC 默认互通，必须用 NetworkPolicy 或安全组最小化放行
- 连接字符串加
replicaSet和directConnection=false：防止客户端绕过副本集发现机制，直连非主节点导致写失败
监控谁在用哪个账号，异常行为秒级告警
没人查日志，直到凌晨三点收到 collection dropped 的 Slack 报警。MongoDB 企业版有审计日志，社区版靠 system.profile + db.setProfilingLevel(2) 抓慢查询和高危操作，但更关键的是在应用层埋点：所有服务初始化时上报 service_name 和 mongo_user 到统一指标系统（如 Prometheus）。
容易踩的坑：profile 开太大会拖慢性能，建议只对 admin 库开 level 1（慢查询），业务库不开；审计日志路径配置错（auditLog.destination: file 但目录无写权限）会导致 mongod 启动失败，报错 Failed to open audit log file。
- 定期查
db.runCommand({connectionStatus: 1})中的authInfo.authenticatedUsers，确认没多出陌生用户 - 用
mongostat --host rs0/mongo1:27017,mongo2:27017看实时连接数突增，可能是某个服务疯狂重连 - 凭证轮换后，旧连接不会自动断开，得配合应用健康检查主动 kill idle connection
最麻烦的从来不是建用户，而是确认每个服务真的只用自己那个账号、真的只连自己那个库、真的没在日志里打出来 URI——这些地方没有银弹，只能靠自动化扫描 + 上线前 checklist 交叉核对。
