为首次部署 MongoDB 做好准备：备份和安全

在该系列的第一篇文章中，我们讨论了部署关系型数据库时使用的哪些概念、操作和过程可以直接应用到MongoDB 上，同时还介绍了硬件选择以及部署和监控的最佳实践。

在该系列的第二篇文章中，我们将会介绍如何使用备份工具和安全策略保护你的部署。

MongoDB 备份和恢复

备份 MongoDB 数据库常见的方式有三种：

• 使用 MongoDB 管理服务（MMS）进行云备份
• 使用文件系统快照
• 使用 MongoDB 自身的mongodump工具

使用 MongoDB 管理服务 (MMS) 备份

除了上一篇文章提到的监控方法之外，MMS 提供了一个管理全面的云备份解决方案，它托管在可靠、有冗余且安全的数据中心上。用户需要将MMS 备份代理本地安装到MongoDB 集群上并执行初始同步，在那之后加密和压缩的oplog 数据（用于MongoDB 复制集）会从备份代理流到MMS 上。快照每6 小时创建一次。

MMS 备份是唯一一个支持复制集时间点恢复和分片集群整体快照的解决方案。过去 24 小时之内的 oplog 数据会被存储起来，你可以使用这些数据为一个复制集创建定制快照。对于分片集群，负载均衡每 6 小时会暂停一次，同时一个无操作令牌会被插入到所有分片、Mongos 和配置服务器上。oplog 能够被应用到集群中的所有复制集上（直到令牌插入的那个点），为整个集群提供了一个一致的快照。

恢复数据的时候，你可以通过 SCP 直接将数据发送到你的服务器上，或者可以通过生成的自定义 URL 下载它们。MMS 需要对所有恢复进行双重认证。如果你想了解与 MMS 备份服务相关的更多信息，那么可以查看 MongoDB 网站上的文档页面。

文件系统备份

文件系统备份，例如Linux LVM 提供的方式，我们可以快速有效地创建一个文件系统的一致性快照，然后复制该快照用于数据的备份或者恢复。如果你想了解如何使用文件系统快照创建MongoDB 备份，那么可以参考文档：使用文件系统快照进行备份和恢复。

mongodump

mongodump 是与 MongoDB 捆绑在一起的一个工具，它能对 MongoDB 中的数据进行实时备份。我们可以使用mongodump dump 整个数据库、集合或者一个查询的结果。mongodump 可以通过 dump oplog 创建能够反映某个时间点数据的 dump 文件，然后通过 mongorestore （一个能够从 mongodump 产生的 BSON 数据库 dump 文件中导入数据的工具）重放。mongodump 还能处理不活动的数据库文件集。

在备份和恢复策略的 MongoDB 文档页面上可以找到更多与备份创建相关的信息。

安全

与其他所有的软件一样，MongoDB 管理员也必须考虑与 MongoDB 部署相关的安全和风险问题。减轻风险没有魔幻的解决方案，维持一个安全的 MongoDB 部署环境需要持续不间断的努力。

纵深防护（Defense in Depth）

纵深防护是安全的 MongoDB 部署推荐使用的方法，它有很多不同的方法可用于管理并降低风险。纵深防护的目的是把环境分层，确保系统中没有可以让侵入者或者不受信任的团体利用的错误点，从而使其无法获取到存储在 MongoDB 数据库中的数据。降低暴露风险最有效的方法就是让 MongoDB 运行在受信任的环境中，通过访问限制、遵循最小权限系统、遵循安全的部署生命周期、遵循最佳部署实践等方法实现良好的风险管控。

所有处理敏感信息的数据库都需要提供全面的安全防护机制，包括：

• 通过用户权限管理限制对敏感数据的访问，通过认证和授权控制实现。
• 记录数据库操作日志并对其进行审计。
• 对需要通过网络传输的数据和存储在数据库中的数据进行加密保护。
• 环境和流程控制。

MongoDB 2.4 引入的很多功能可以处理上面的需求，同时 MongoDB 2.6 将会继续提供这些功能。点击这里获取MongoDB Enterprise 2.6 开发者预览版。

认证

对访问MongoDB 的实体进行认证的方式包括使用数据库本身的认证机制和集成外部的安全机制（包括MongoDB Enterprise 2.4 的 Kerberos 服务、 LDAP 以及 Windows 活动目录和 MongoDB 2.6 中新增的 x.509 证书认证）。

授权

MongoDB 允许管理员定义一个应用程序或者用户应该拥有哪些权限，在执行查询的时候能够看到哪些数据。MongoDB 拥有大量的内置角色，同时在MongoDB 2.6 中用户能够配置细粒度的自定义角色。例如，某些用户可能有权查看某一条记录，但是永远不能更新或者删除这条记录。MongoDB 2.6 提供了域级别的安全机制让用户能够对敏感数据进行细粒度的安全授权控制，同时能够定义在运行时实现的声明式安全策略。通过域级别的管理控制，描述某个资源的单个文档可以包含使用多个安全级别的数据，避免了需要将使用不同安全级别的单个信息分离到多个数据库中的复杂性。

审计

MongoDB 2.6 通过维护审计日志增加了对记录数据库管理操作的支持。为了便于使用，分布在一个MongoDB 集群中的审计日志可以被合并到一个单独的log 文件中，从而能够将由某个单独的操作产生且影响多个节点的事件关联起来。

加密

MongoDB 能够对需要在网络间进行传输的数据和位于持久存储中的数据进行加密。

对SSL 的支持允许客户端通过加密通道连接到MongoDB。如果使用FIPS 验证的Cryptographic 模块在FIPS 模式下运行，那么MongoDB 还能支持 FIPS 140-2 加密。

有多种方式能对 MongoDB 中的数据进行加密。一种方式是在应用程序层使用合适且必要的加密类型对域级别的数据进行加密。

另一种方式是使用像 NcryptFS 和 LUKS 这样的第三方类库，它们作为操作系统内核的一部分为 Linux 提供了磁盘级别的加密，它们所提供的高级管理功能可以确保只有得到授权的进程才能访问这些数据。对于 Windows 平台而言，可以使用像 IBM Guardium 数据加密、BitLocker 驱动盘加密和 TrueCrypt 这样的技术。

下面是一个创建安全部署所需关键步骤的检查列表：

查询注入

对于 MongoDB 客户端程序而言，它生成的查询为 BSON 对象，而不是字符串，所以传统的 SQL 注入攻击对将查询作为 BSON 对象提交的系统不会造成危险。

但是，有一些 MongoDB 操作允许对任意 JavaScript 表达式求值，这时候应该注意避免恶意表达式。幸运的是大部分查询能够被表示为 BSON，同时在必须使用 JavaScript 的情况下用户能够混合 JavaScript 和 BSON，所以用户特定的值会被评估为值而不是代码。

结论

MongoDB 用户能够通过本文以及前一篇文章所讨论的最佳实践满足当今业务系统对维护高可用、安全和可扩展运营的需要。

这些介绍以及其他的最佳实践在 MongoDB 运营指南（PDF 文档）中有非常详细的介绍。

关于作者

Mat Keep (@matkeep) 是 MongoDB 产品营销团队的一员，负责为 MongoDB 的产品和服务构建愿景、定位和内容，同时也负责对市场趋势和客户需求进行分析。在就职于 MongoDB 之前，Mat 是 Oracle 公司的产品管理总监，负责 MySQL 数据库在 Web、电信行业、云和大数据方面的应用。在这之后他还在技术供应商和面向最终用户的公司中从事过一系列的工作，包括销售、商业开发与分析、程序员。

查看英文原文： Preparing for Your First MongoDB Deployment: Backup and Security