最新MongoDB 3.4和Elastic 5.2数据安全实战分享

2017年1月份互联网界发生了一场大规模的数据安全黑客攻击问题，主要涉及当前比较火热的NoSQL：MongoDB和Elastic，前期大部分人使用时都没有充分考虑数据安全问题。经过这次事故，相信很多人都已经更佳意识到数据安全的严重性。本文将围绕该主题与大家讨论MongoDB 3.4和Elastic 5.2的数据安全防患，介绍内容如下：

一、最新MongoDB 3.4集群认证安全

MongoDB 3.4集群搭建
replica集群搭建
超级系统用户及数据库用户创建 MongoDB 3.4安全认证
密钥文件 keyFile 创建
权限控制起效

二、最新ElasticSearch 5.2.1集群认证安全

ES 5.2.1集群搭建流程及常遇问题 管理插件x-pack认证 插件Head认证 ES认证license更新

三、客户端驱动使用问题

MongoDB 3.4.1认证安全时Java Driver使用及问题 ES 5.2.1认证机制下Java Client使用 一、最新MongoDB3.4集群认证

本主题主要是围绕MongoDB 3.4集群安全认证方面，限于实验机器数量，此部分以两个虚拟机给大家演示MongoDB replica集群及安全认证。

集群搭建准备，两台虚拟机：

192.168.1.101 端口：17305 192.168.1.102 端口：17305 1. MongoDB3.4集群搭建

1）下载最新mongodb-linux-x86_64-rhel70-3.4.1.tgz并解压，将目录更名为mongodb341。

2）分别进入两虚拟机mongodb主目录，设置启动脚本start.sh：

bin/mongod --dbpath "/data/mongo" --logpath "./logs/running.log" --replSet "wcg" --port "17305" --logappend --fork &

3）执行脚本start.sh，启动MongoDB服务，如下所示：

[root@izgw846obc7a3277hquzkgz mongodb341]# ./start.sh [root@izgw846obc7a3277hquzkgz mongodb341]# about to fork child process, waiting until server is ready for connections. forked process: 8283 child process started successfully, parent exiting

4）设置replica副本集，使上述两个独立Mongodb成为一个replica集群。利用MongoDB客户端脚本，执行如下：

[root@izgw846obc7a3277hquzkgz mongodb341]# bin/mongo --port 17305 MongoDB shell version v3.4.1 connecting to: mongodb://127.0.0.1:17305/ MongoDB server version: 3.4.1 cfg = { ... "_id":"wcg", ... "members":[ ... {_id: 0, host: "192.168.1.101:17305"}, ... {_id: 1, host: "192.168.1.102:17305"} ... ] ... } { "_id" : "wcg", "members" : [ { "_id" : 0, "host" : "192.168.1.101:17305" }, { "_id" : 1, "host" : "192.168.1.102:17305" } ] } rs.initiate(cfg) { "ok" : 1 }

这样设置后，当前命令行提示进入replica模式，如下所示：

wcg:PRIMARY>

5）创建超级系统用户、数据库权限的DB用户。

wcg:PRIMARY> use admin switched to db admin //下属命令为超级用户权限，认证成功后，对所有DB有效。 wcg:PRIMARY> db.createUser({user:"light",pwd:"mgAdmin", roles:["root"]}) Successfully added user: { "user" : "light", "roles" : [ "root" ] } //下属命令为数据库DB用户权限，认证成功后，仅对test数据库有效。 wcg:PRIMARY> db.createUser({user: 'guang', pwd: '2017305', roles: [{role: 'dbOwner', db: 'test'}]}) Successfully added user: { "user" : "guang", "roles" : [ { "role" : "dbOwner", "db" : "test" } ] }

上述用户创建好，这时用户认证仍然没有起效，因为现在MongoDB服务还是无认证状态启动的。

2. MongoDB3.4安全认证

1）生成keyFile密钥文件。

在服务器192.168.1.101的MongoDB目录生成密钥，如下所示：

[root@izgw846obc7a3277hquzkgz mongodb341]# **openssl rand -base64 756 > mgKeyFile** [root@izgw846obc7a3277hquzkgz mongodb341]# **cat mgKeyFile** oDKgh9WjRoNoesf8EsutFzLHEfztbYox1bWM0OS8mbdkZ9ybZA4bVwQJRAdsZx5h xRTkYfBYQ4ZOjLKf+BEtKRDSdaWfrK9Ktjj+wPMS3sNz4Nlp81ByeyfEK4Ey8SCH Z2mkII9o2rUQhxv+zoZG67ihQo1kMQAvtpv9+eni9gUD49X/TdhMuB8iNuRz51Ir StpqAyiz5CgX9/nhoItxjusMCMtmgfJKefVs9Vgawk06o7eWsjnsySUx8URTwsFc sIe7zen4iDk1SFCD58n9QowE5NBF8DLWGLy+FKkgfwuxvELw4cntFdcjoG3/XeHV 8KF/8gsQ4HbLXjwfvV/r7jKKYjr0s3CT5gXmqslzhp36/lIZgzbnfc2yarToHzIQ 4eGp0SdSAtGlkITdKWzBSpiy4Z++Zx+p71aUHlOZ7nURzmzBiWVbqCGJRi76QGAi V6/w2N7kE3tHGP2ktC+AxsD0bh0r12KHW2U/YPBqQoPpeLXrMDUrpc6pIEfKpTER EyZ+JS8zBZPurKgK4a2Y8FmQ/Ve5AW2DAtMVRasb5tu9rhrOEuw5rPW5onJBZxKL 25lpxfSZHwTYco63X0aQSgxoyPLI4gFDSg7ZMOj+AwYw/nntglJrzl5pMuokMl0T Ohgk1CWcI3Rb1Tq5JcXz2vJs3jBbzXwOd8lY7roZJy4hpxYKeGmUhxm4hHd5GR1k aiyGsUwssxaE5gIZlu6Uwq3sWGjaViK8wFu5aoojKe6fIj9UurIDwGBvd5g5EU4c iDkEueT3Y925Om6Q8IxYlsxYpRaf36lss7CRLtDXN3zuEl9f+1+oVqvMx7s9f0PC aeGB3oZDXuF9DhGwHf4uTWFDIA8xQO7JL1nOmUurcQAouWdU8pj90AnFKykNawdG 5NRVKdKLS0nt+Efxdv5avUbrcPw0z+hfU6o0WHEsASUiSgU68MOZrNPOePI5KvhY UXrWBZM4+5nyrpz4GfY5Xf0pugxxFQPIYlu+AoiBvrxVUQi0

2）使用密钥认证模式启动MongoDB服务。

更改启动脚本文件start.sh，内容如下：

bin/mongod --dbpath "/data/mongo" --logpath "./logs/running.log" **--keyFile** "./**mgKeyFile**" --replSet "wcg" --port "17120" --logappend --fork &

此时需要注意一点，集群内需要共享同一个密钥文件。

3）验证用户权限。

重启MongoDB服务，此时进入Mongo客户端，切换到任意一个DB，执行查看其下所有表，则结果如下：

wcg:PRIMARY> use admin switched to db admin wcg:PRIMARY> show collections 2017-01-20T21:01:37.788+0800 E QUERY [main] Error: listCollections failed: { "ok" : 0, "errmsg" : "not authorized on admin to execute command { listCollections: 1.0, filter: {} }", "code" : 13, "codeName" : "Unauthorized" } : _getErrorWithCode@src/mongo/shell/utils.js:25:13 DB.prototype._getCollectionInfosCommand@src/mongo/shell/db.js:805:1 DB.prototype.getCollectionInfos@src/mongo/shell/db.js:817:19 DB.prototype.getCollectionNames@src/mongo/shell/db.js:828:16 shellHelper.show@src/mongo/shell/utils.js:748:9 shellHelper@src/mongo/shell/utils.js:645:15 @(shellhelp2):1:1

只有在安全认证后，在所使用当前用户权限下，上述执行才可以正常。认证如下：

wcg:PRIMARY> db.auth('light', 'mgAdmin') 1 >wcg:PRIMARY> show collections system.users system.version

读者朋友可以自行验证，超级用户和数据库用户权限的不同，一般应用设置这两类即可满足。这种认证模式下，不会再像之前认证前那样，任意用户都可以进入MongoDB系统内，从而可以有效防止一些恶意操作。

二、最新ElasticSearch 5.2集群认证

本主题围绕最新Elastic 5.2集群安全认证方面，限于实验机器问题，该集群在一个服务器上启动3个ES节点，如下所示：

esNd1 127.0.0.1 http端口: 9200 tcp端口: 9300 esNd2 127.0.0.1 http端口: 9202 tcp端口: 9302 esNd3 127.0.0.1 http端口: 9203 tcp端口: 9303 1. ES 5.2.1集群搭建流程及常遇问题

1）下载最新版elasticsearch-5.2.1.tar.gz，并解压，目录名更改为es521。

2）调整JVM堆内存及服务端口：

jvm内存：ES主目录下的config/jvm.options，根据官网介绍，一般不超过32G，不超过物理内存的一半，做相应调整。

ES基本配置：ES主目录下的config/elasticsearch.yml，基本配置：

es521/config/elasticsearch.yml:

http.port: 9200 http.enabled: true transport.tcp.port: 9300 transport.tcp.compress: true

es521_2/config/elasticsearch.yml:

http.port: 9202 http.enabled: true transport.tcp.port: 9302 transport.tcp.compress: true

es521_3/config/elasticsearch.yml:

http.port: 9203 http.enabled: true transport.tcp.port: 9303 transport.tcp.compress: true

3）ES服务启动。

进入ES主目录，执行：

bin/elasticsearch -d

至此，一个最基本的ES集群搭建完毕，当然实际情况，需要考虑中文分词等，这里建议使用 elasticsearch-analysis-ik(IKAnalyzer) 。

4）常遇问题。

自ES5.2起，ES启动时会有“Bootstrap Checks”，如果一些系统基本设置不符合要求，会启动失败，常见问题如下：

问题1: Error: max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]

解决方法：在文件/etc/sysctl.conf追加

fs.file-max = 1645037 vm.max_map_count=655360

问题2: bootstrap checks failed

解决方法：在文件/etc/security/limits.conf 增加：

* soft nofile 65536 * hard nofile 131072 * soft nproc 2048 * hard nproc 4096 2. 管理插件x-pack认证

自ES5.0起增加了x-pack插件，该插件可以认为是5.0以前认证组件“shield”和管理插件“marvel”整合后一个功能更加强大的管理组件。其安装流程如下：

1）安装x-pack, 进入ES主目录，安装流程如下：

2）在ES配置config/elastic.xml中增加如下配置：

xpack.security.audit.enabled: true

该配置会使得x-pack认证机制生效。

3）重启ES服务。

4）为ES可视化管理工具Kibana安装x-pack插件, 安装流程如下：

5）启动Kibana服务，使用ES默认超级用户及密码：

elastic/changeme登陆控制台，如下所示：

ES提供的内置角色一般可以满足需要，在控制台中可以根据需要创建出符合自己业务权限要求角色的用户及密码。

此时如果像安装x-pack之前那样访问 http://localhost:9200 则系统提示需要属于用户及密码才可以访问。同样客户端以Java为例，再使用之前模式访问也拒绝连接。这样，大大降低了ES集群管理的安全风险。

3. 插件Head认证

x-pack虽然集成了shield和marvel两个插件的功能，但有时为了更方便集群管理，我们还需要安装操作更为简便的Head插件。自ES5.0起，head插件不再支持作为ES一部分，而是作为独立服务，

具体安装流程如下：

下载node-v7.6.0-linux-x64.tar.xz，并配置好环境变量。 下载head最新代码： https://github.com/mobz/elasticsearch-head/archive/master.zip 并解压

在head主目录执行：

npm install 安装相应组件 grunt server 启动head服务

跨域访问设置。

在ES配置config/elastic.xml中新增：

http.cors.enabled: true http.cors.allow-origin: "*" http.cors.allow-headers: Authorization

并重启ES服务。这时我们访问Head如下：

这里我们看到：head独立服务端口默认9100(可以根据需要调整)，在其管理界面输入欲连接的ES-Node访问地址即可，前提是在地址栏需要携带认证用户名和密码。

4. ES认证license更新

上述X-pack确实很好的解决了大部分情况下我们的数据安全认证问题，但不幸的是，x-pack功能齐全仅仅有一个月期限，过期后，如果不更新license，一些重要功能，比如监控就不再提供。

鉴于上述问题，为保证服务的正常运行而不受影响，建议用户及时更新license,如下所示：

https://register.elastic.co/xpack_register注册。 根据需要选择商业模式还是免费模式，获取最新 license文件，其内容为json格式。

更新license:

curl -XPUT -u elastic:password 'http:// :

/_xpack/license?acknowledge=true' -d @license.json

三、客户端驱动使用问题 1. MongoDB3.4.1认证安全时Java Driver使用

1）获取带有访问权限限制的mongo-client代码参考

2）权限认证的Mongo-Java-driver异常

某些虚拟机下，运行权限认证模式的Mongo_java客户端时会报：

java.security.NoSuchAlgorithmException: PBKDF2WithHmacSHA1 KeyGenerator not available

这个原因，也困扰了我两三天，不管Google还是Baidu，反馈都很晦涩，我这里实验结论是，linux中配置的jdk目录下缺少“sunjce_provider.jar”，该jar需要到JDK windows安装的JRE目录下寻找。

2. ES5.2.1认证机制下Java Client使用

1）添加Maven依赖。

增加elastic依赖库 https://artifacts.elastic.co/maven

<dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>x-pack-transport</artifactId> <version>5.2.1</version> </dependency> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>transport</artifactId> <version>5.2.1</version> </dependency>

2）java 客户端使用代码参考。

如上图所示，分别给出了x-pack在使用和不使用两种情况下分别获取ES transportclient的代码结构。二者不同也仅在于获取客户端连接，以后基本的crud操作都是一样的。

四、小结

不管MongoDB、还是Elastic涉及的知识都非常多，本文仅从数据安全角度和大家探讨，本主题来自作者实践经验，希望对大家有帮助，谢谢！

Chat实录： 《王成光：MongoDB和Elastic数据安全问题实战解析》