一、MongoDB介绍
MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。
本次安装环境为Windows10专业版操作系统，数据库版本为5.0.8，单机部署过程比较简单就不在此进行讲解。本文针对MongoDB等保测评进行实际操作，不妥之处还恳请留言指正，共同学习。
二、等保测评
身份鉴别
a)应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换；
1）MongoDB服务在安装后默认未开启权限验证，默认是空账户、空口令，这就导致了任何人无需进行账号认证就可以登陆到数据服务器（同时身份标识的唯一性就得不到满足），未启用身份验证时执行命令“mongo"即刻对数据库进行任意操作:
2）检查mongod.cfg配置文件中修改auth=true，启用身份认证，执行命令：“mongo"后输入其他命令结果显示权限不足或不显示：
2）MongoDB自身不具备设置登录账户的口令复杂度和定期更换口令的策略，仅通过管理员自行设置口令复杂度：
b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；
据了解，mongoDB好像不具备登录失败处理功能。
c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；
1)是否采用加密等安全方式对系统进行远程管理是否用户都是localhost，全为localhost则为本地管理，可判定为不适用。
2）远程管理根据实际管理情况进行判定（如了解数据库管理工具采用什么措施防止鉴别信息在传输过程中被窃听）
d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
访谈管理员并进行验证，是否采用双因子身份鉴别技术，鉴别技术是什么。实际实现双因素认证比较困难，一般情况判定为不符合。
访问控制
a)应对登录的用户分配账户和权限；
执行命令“showusers”查看mongoDB中的账户的管理权限。
b)应重命名或删除默认账户，修改默认账户的默认口令
mongoDB不存在默认账户，可根据需要建立不同权限的账户，所有账户都是用户自行建立，账户权限列表如下：
c)应及时删除或停用多余的、过期的账户，避免共享账户的存在
1）询问管理员数据库中的账户使用情况，是否存在无人使用的账户，如果存在建议删除。
2)检查网络管理员，安全管理员、系统管理员不同用户是否采用不同账户登录数据库。
d)应授予管理用户所需的最小权限，实现管理用户的权限分离
执行命令“showusers”查看mongoDB中的账户的管理权限是否不同，是否建立三员。
e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则
1）访谈和查看管理员是否制定了访问控制策略
2）查看管理员权限；（此测评点如果mongoDB已经启用身份鉴别，且具备权限分离可判定为符合）
f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级
结合a）、b）、c）、d）、e）项，并访谈管理员并核查访问控制粒度主体是否为用户级，客体是否为数据库表级。
（此测评点多数测评机构默认判定为符合）
g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问
通过访谈管理员是否对重要主体和客体设置安全标记。mongoDB自身应该不具备这个功能，可能需要依赖操作系统或者第三方来实现。该项一般默认都不符合。
安全审计
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计
1）确保日志记录捕获尽可能多的信息安全审计，检查mongod.cfg配置文件中是否添加quiet:false
2）可检查mongod.log的日志文件记录是否正常：
3）访谈管理员是否通过第三方工具（数据库审计系统）收集审计数据进行分析。
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息
1）检查mongod.log的日志文件:
2)核查是否部署第三方工具（数据库审计系统）增强MySQL日志功能。记录第三方审计工具的审计内容，查看是否包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息。
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等
应保证各个管理员尽可以访问与自身相关的日志文件，如关键日志仅允许特权账户访问
1)访谈管理员对审计记录如何保护，对审计记录是否定期备份，备份策略。
是否采取了备份、转存等手段对审计记录进行保护，避免未预期的删除、修改或覆盖，数据库本地日志保存时间超过6个月。采用第三方数据库审计产品，审计记录保存时间超过6个月。
2)是否严格限制用户访问审计记录的权限，可以通过普通用户登录然后是否能够访问修改删除日志。
d)应对审计进程进行保护，防止未经授权的中断
根据mongoDB可以根据权限建立各类型的账户，可以防止审计进程未经授权的终端：
入侵防范
a)应遵循最小安装的原则，仅安装需要的组件和应用程序
数据库系统此测评项可判定为不适用。
b)应关闭不需要的系统服务、默认共享和高危端口
数据库系统此测评项不适用。
c)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制
修改bindIp的地址.0.0.1表示本地管理，如果修改为0.0.0.0表示任意地址连接，需要指定连接可在.0.0.1后添加具体IP地址，IP地址之间用“,”隔开。
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求
数据库系统此测评项不适用。
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞
1、访谈管理员是否定期或不定期进行漏洞扫描或渗透测试，周期按照天/月/季度/半年/年等方式（建议漏洞扫描周期最长半年一次）。2、通过本次漏洞扫描是否发现与数据库相关的高危漏洞，若存在，是否及时进行漏洞修补。
f)应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警
数据库系统此测评项不适用。
恶意代码防范
应采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入侵和病毒行为，并将其有效阻断
数据库系统此测评项不适用。
可信验证
可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心
通过访谈管理员，是否采取了可信技术，可信技术主要是基于可信芯片、可信根，目前实现此技术的可能性不大，一般判定为不符合。
数据完整性
a)应采用密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；
传输过程中的完整性一般是通过通信协议来实现的，常见的包括TLS、SSH等协议，对数据库而言，查看是否启用了安全协议进行数据通信，同时询问管理员，确认是否还有其他保证数据传输过程中的完整性措施。
（本地管理判定为不适用，远程管理根据实际情况判定）
b)应采用密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。
对数据库配置文件进行一个完整性检测，需要配置文件初始可信状态时的哈希值，然后再根据目前的文件生成一个哈希值，对比前后的一致性，确认数据是否被篡改过，根据了解一般数据库自身不带这种机制，询问管理人员是否使用了第三方软件对数据库重要数据进行了完整性校验。
根据网上部分技术人员的说法，总结一种数据完整性校验方法（可能不对）：mongoDB通过journaling保证意外故障下的数据完整性，MongoEvent来实现对于数据的校验（具体怎么实现还望留言指导）。
实际操作中可核查数据库表中的业务数据、审计数据有无存在哈希字段，据了解数据在前端一般通过json或xml格式进行传输，相关数据库表字段中具有完整性校验字段。目前一般做不到，判定为不符合。
数据保密性
a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；
此处主要针对鉴别信息（其他像业务数据、审计数据和配置数据一般情况未加密）传输相关的参数大致有下类三个：
SCRAM-SHA-属于挑战-响应架构，可防止密码在不可信连接上嗅探，并支持以密码散列的形式将密码存储在服务器上，这种形式被认为是安全的。
MD5使用自定义安全性较低的质询-响应机制。它可以防止密码嗅探，并避免以纯文本形式将密码存储在服务器上，但如果攻击者设法从服务器窃取密码哈希，则不提供保护。（MD5哈希算法现在不再被认为是安全的算法）
若password是以明文密码传送给数据库，建议不在生产环境中使用。若数据库未开启SSL时，我通过Wireshare对数据库认证过程的数据包进行抓取，可能发现传输的密码字段信息。
总结，最直接验证的办法就是抓包验证重要的加密数据（鉴别数据、需要加密的业务数据、个人信息等）是否明文传输。
b)应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。
检查数据库表中的重要数据是否明文存储，根据经验除鉴别数据外，业务数据、审计数据实际很少加密存储，所以一般不符合或者部分符合。如果使用数据库加密功能，就可以符合符合，数据库加密主要分库内加密和库外加密，库内加密主要是调用的数据库本身的加密功能，库外加密主要通过第三方厂家的数据库加密功能。
据了解，MongoDB数据库自身提供了加密机制，在数据库内核实现了存储的加密。这种加密方式能防止磁盘丢失和文件被复制导致的敏感数据泄漏。但是，对于控制了数据库系统的攻击者来说却是开放的，并没有防护能力。而且其密钥管理通常不会对数据库用户开放，安全性得不到保证。
数据备份恢复
a)应提供重要数据的本地数据备份与恢复功能；
1）访问管理员配置数据、审计数据、业务数据的备份策略，检查备份策略的备份情况与管理员所说是否一致，是否具有恢复测试记录。
（1）、MongoDB数据库备份:mongodump-hdbhost-ddbname-odbdirectory
参数说明：
-h：MongDB所在服务器地址，例如：.0.0.1，当然也可以指定端口号：.0.0.1:
-d：需要备份的数据库实例，例如：test
-o：备份的数据存放位置，当然该目录需要提前建立，这个目录里面存放该数据库实例的备份数据。
（2）、MongoDB数据库恢复:mongorestore-hdbhost-ddbname--dirdbdirectory
参数或名：
-h：MongoDB所在服务器地址
-d：需要恢复的数据库实例，例如：test，当然这个名称也可以和备份时候的不一样，比如test2
--dir：备份数据所在位置，例如：/home/mongodump/itcast/
--drop：恢复的时候，先删除当前数据，然后恢复备份的数据。
2）可以通过数据库管理工具进行备份，如navicat等工具，工具具备mongoDB自带的逻辑备份。它的备份原理是通过协议连接到mongoDB数据库，将需要备份的数据查询出来。
b)应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地；
部署异地备份机房，并符合备份策略通过网络定期进行异地备份。
c)应提供重要数据处理系统的热冗余，保证系统的高可用性；
集群部署、双机热备均可判定为符合。
剩余信息保护
a)应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除；
一般情况下数据库系统内核层默认无法实现剩余信息保护功能，需要第三方工具才能实现。
b)应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。
一般情况下数据库系统内核层默认无法实现剩余信息保护功能，需要第三方工具才能实现。
个人信息保护
a)应仅采集和保存业务必需的用户个人信息；
检查数据库中是否存储个人信息，若有，检查个人信息保护机制和个人信息保护管理制度
b)应禁止未授权访问和非法使用用户个人信息。
检查个人信息保护机制和个人信息保护管理制度，验证非授权人员是否可以访问个人信息存储的相关组件内容。
总结
在等保测评检查中会发现mongoDB很多都不满足等保的一些控制点的要求，它的功能和MySQL、Oracle相比单一不少，等保测评机构提出整改问题后，数据库使用单位加固也是一件比较困难的事，可能需要第三方工具协助才能完整加固整改工作，还是比较麻烦的一件事。