本文的作者是 360 HULK私有云-DBA团队，360HULK私有云团队是奇虎360公司内部专属私有云平台的缔造者，团队涉及云计算、数据库、大数据、监控等众多技术领域，拥有夯实的技术积累和丰富的一线实战经验。
![]()
我们都知道mongoDB的默认端口为27017，那么说明黑客们也都知道啊。
那么会怎样呢？这意味着黑客想针对mongoDB进行扫描那么可以直接看你的27017是否开放。
而在他进行大范围的端口扫描时一旦发现27017开放就可以粗略的认为他发现了一个mongoDB！
所以不使用默认端口虽然无法杜绝黑客的入侵，但可以相对增加他的入侵难度！
因此我们建议大家维护的任何mongoDB都不要使用27017这个默认端口。
一个暴露在公网的端口可能每天都会经历无数次的恶意扫描，风险巨大。
但一个内网的端口就好太多了，黑客想要侵入你的内网端口难度明显高于外网，起码先得攻破堡垒机对吧？
所以建议大家的mongoDB都只监听内网端口屏蔽公网端口的请求，通过该策略继续增加黑客的入侵难度。
不知道大家是否还记得之前一样闹得沸沸扬扬的Redis漏洞。
当该漏洞被利用时，如果你的进程使用了root用户来进行启动，那么黑客可以通过漏洞并配合这一点对你造成更大的伤害。
这个伤害很可能是爆击效果（不可恢复的严重故障），黑客甚至能够通过该Redis实例继续入侵至服务器环境、内网。
这种问题对DBA、运维、公司带来的伤害都是极大的。但大家又真的很委屈，这种突如其来的bug谁又能提前料到呢？
我们虽然无法确保我们使用的软件没有bug，但我们可以通过类似措施增加第二层防线来降低bug暴漏后的风险，同时给我们更多的喘息时间来修复bug！
不只是mongoDB，我们建议大家维护的所有db都使用禁止登录的非root用户启动。
毫无疑问这是必须必须必须要加的，如果你看到这里但不认同我的观点那么请直接关掉本页。
在报道中，那些被勒索的mongoDB管理者可能都没有为他们自己的mongoDB开启验证。
你想象一下，没有开启验证的mongoDB就好比失去了免疫系统的人类（艾X病），这是多么脆弱的状态？
所以当一个mongoDB上线后，第一件事就是启用验证。
我们建议使用mongoDB官方建议使用的keyFile参数来开启验证功能，他的好用可靠性无需多言，官方文档写的很清楚。
在360内部，其实我们的最大“入侵者”来自于360信息安全部，他们有各种扫描工具24小时不停的对所有服务器的端口进行扫描。
很多年前（2012年前）我们的mongoDB也没有开启验证，于是我们的信息安全部向我们的mongoDB里写入了大量的乱七八糟的但又不会影响业务东西，对DBA造成了极大的困扰。
因此，在信息安全部7*24小时的"鞭策"下，我们维护的mongoDB全部都启用了验证。
回想起当时的被迫调整，无论是DBA还是使用了mongoDB的业务开发都是非常的痛苦。
因为从无验证到有验证，要测试代码的兼容性、性能变化等等一系列连锁问题。
大家最初都是抵触的，甚至会怀疑认为信息安全部真是小题大做。
但现在看来这真是英明的抉择，这些短期痛苦带来的长期安全性的提升是相当划算的！
可能我们通过以上几点已经近乎完美的杜绝了入侵。
但是！万一DBA手潮怎么办？万一运维手潮怎么办？万一开发同学手潮怎么办？
可能误删带来的痛苦远大于被黑，因为这是乌龙啊朋友们！简直痛心疾首是不是？
你心情不好喝多了或是失恋一个简单的drop()只需要1秒即可执行完毕，而我可能需要几天的时间来进行恢复。
所以权限的严格限制是非常有必要的，一套合理严格的权限控制方案可以最大程度的避免手潮误删带来的伤痛。
我们建议大家针对自己维护的mongoDB设置一套适合对应业务的权限控制、分配方案。
我们之前也对自己的权限控制策略进行了分享，标题为：
《MongoDB 权限控制系统简介》
这篇文章讲的非常详细，具体就不在这里详细阐述。
大家如果有兴趣可以直接点击文章末尾的“阅读原文”按钮查看该文章，希望能够给你带来一些帮助！
作为数据库的管理者，不给数据库加验证可以切腹，那么不备份数据库就可以拉去游街了（罪不至死但绝对是职业生涯污点）。
一套可靠的备份逻辑永远是你那钢铁一般坚韧的永远不会被拽断的救命稻草！
无论发生什么，是被黑，还是误删，或是机房漏水，或是服务器报销，甚至机房被核弹炸毁，一套可靠的本地备份逻辑 + 远程备份存储方案都可以在以上场景救到你！
我们对当前维护的mongoDB使用了多套备份策略：
实时增量备份 + 每天定时dump整备 : 该策略适合数据量不大的业务
实时增量备份 + 每天定时cp（拷贝式）整备 : 该策略适合数据量相对较大的业务
实时增量备份 + 按库/按表过滤式备份 : 该策略适合一个大库中只有部分重要数据的场景,例如一个90%数据都是日志的集群
实时增量备份 + 每天定时备份 + 延迟同步节点 : 该策略适合数据重要且对恢复速度要求较高的业务
另外以上策略全部都有异地存储策略，以应对机房的整体不可恢复灾难场景下的数据恢复需求。
有了完善的备份策略，恢复怎么办？
多数场景下我们的恢复都是手忙脚乱的，一个DBA在恢复数据的时候背后很可能站着3个开发2个运维1个产品1个QA，压力大不大？
所以建立一套能够覆盖多数灾难场景的恢复策略来避免我们的手忙脚乱是非常必要的。
我们为极端场景的恢复建立了多套策略，这些策略建立在我们的备份策略基础之上：
通过增量备份进行恢复 : 适合需要恢复的数据条数不多的场景
通过整备 + 增量备份对库/表进行过滤式恢复 : 适合需要恢复的数据仅限某库某表的场景
通过整备 + 增量备份恢复到灾难前1秒 : 适合数据重要希望完美恢复的场景
直接通过备份 + 增量备份导入生成临时服务实例 : 适合db体积巨大，短时间内无法恢复但又无法中断业务太久的场景
直接切换到延迟从库 : 适合有延迟从库的集群且灾难发现较为及时的场景。
这几年总有断断续续的XX公司的db被拖库的消息，无论是真是假，大家的密码都改到吐血。
我们建议大家一定对任何敏感信息加密后再入库，例如：密码、邮箱、地址等等。
被拖库只代表黑客打开了你的第一层保险柜，但第二层保险柜的数据加密会对数据的损失降到最低。
敏感信息加密后入库也是对用户的负责态度！
到这里8招已经全部介绍完毕，看完的你应该已经明白，一个db的安全与db自身的安全配置、网络安全配置、系统安全配置、备份恢复策略密、数据存储策略密不可分。
最大的安全问题很可能来自部分不规范的使用者而不是mongoDB。
所以此时你还认为mongoDB是那么的不堪么？
其实几乎所有的db安全策略都是相通的、类似的、可以互相借鉴的，不是么？
虽然通过以上策略我们仍然不能绝对杜绝黑客对我们的骚扰。
但请你相信，勒索此时已离你很远！
运维帮「运维大咖CLUB」招募会员：如果你是甲方运维总监/运维经理，欢迎加入我们，请联系微信yunweibang555
商务合作，请加微信yunweibang555
