第9章 安全：从拖库事故倒推防线
第 9 章 · 安全：从拖库事故倒推防线
章节摘要：MongoDB 安全体系包括认证（你是谁）、授权（你能干什么）、加密（传输与静态）、网络隔离与审计。本章从一次公网裸奔实例被拖库的事故与一次勒索删库事故讲五道防线的落地方法。读完本章，你能把一个实例从"裸奔"改造到生产安全基线。
学习目标
- 能启用 SCRAM 认证并按角色最小授权；
- 能开启 TLS 传输加密，说明静态加密的层次；
- 能配置网络层隔离（bindIp、防火墙、VPN）；
- 能用审计日志回答"谁在什么时候动了数据"。
核心概念速览
金句：安全不是一道门，是五道门——每道门降低的是"一次失误就全丢"的概率。
子章节导航
- 9.1 认证与授权：拖库事故，讲 SCRAM、角色体系与最小权限。
- 9.2 加密、网络与审计：勒索删库事故，讲 TLS、静态加密、网络隔离与审计日志。
子章节之间的逻辑关系
9.1 解决"人与权限"，9.2 解决"通道与证据"——先管住身份，再管住管道。
身份权限(9.1) ──► 通道与证据(9.2) │ │ SCRAM·角色 TLS·隔离·审计
子章节导航补记
9.1 的复盘认真还原了拖库的两周时间线——扫描器第 2 天就上门、第 10 天才动手，中间八天是留给防守方的窗口，可惜没有任何监控在看；自定义角色一节把权限压到集合与动作级，配合季度账号评审构成权限的完整生命周期。9.2 的备份拖库复盘揭示了一个普遍盲区：备份链路的安全水位几乎总是低于主库，加密、权限、巡检三件事缺一不可；证书轮换与密钥管理的日常成本，是 TLS 与字段加密真正需要排期投入的部分。
本章知识点核对清单
离开本章前逐条自查：能否按正确顺序为一个裸实例启用 SCRAM 认证并说明顺序反了的后果；能否为应用、报表、DBA、监控四类账号各指定一个角色并说出理由；能否写出 TLS 覆盖节点间通信的配置并描述证书滚动轮换的步骤；能否说清磁盘、引擎、字段三层静态加密各防什么攻击；能否用审计日志回答一次可疑删除的"谁、何时、动了什么"；能否为自己的环境跑一遍六项安全基线自查。答不上的条目，回对应小节把事故时间线重读一遍。
两个高频追问
安全评审上两个问题反复出现。追问一："我们内网部署，还要认证吗？"——要。内网挡住的是外网扫描器，挡不住被攻陷的跳板机、离职员工与配置漂移，认证与授权是内网里的最后一道身份门，成本极低而缺失代价极高。追问二："TLS 会不会明显拖慢性能？"——现代 CPU 的 TLS 握手摊到长连接上开销可以忽略，真正要评估的是证书管理与全链路配置的一次性工程量；拿性能当理由跳过 TLS 的团队，几乎都没有测过实际差值。两个追问的答案共同指向一个态度：安全的反对意见要么来自测量，要么不成立。
一次可执行的基线演练
本章最有效的收尾不是背诵清单，而是对自己的环境跑一次攻防演练：在一台测试机上故意复现裸奔配置，用外部网络的另一台机器模拟扫描器视角，验证网络层确实挡得住；再用错误口令连三次，确认认证层拒绝且审计日志留下记录；然后给报表账号尝试写入，验证授权层按角色拒绝。三次模拟各花十分钟，防线从纸面变成被验证过的事实——与第 6 章的故障转移演练同理，没演练过的安全配置，效果是未知的。
前置知识与后续延伸
前置：第 1 章的 bindIp 与配置文件。延伸：备份是安全的最后一道保险，恢复演练与第 10 章的运维节奏衔接。