MongoDB最佳安全实践

Posted 老王Plus的全栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MongoDB最佳安全实践相关的知识,希望对你有一定的参考价值。

在前文[15分钟从零开始搭建支持10w+用户的生产环境(二)]中提了一句MongoDB的安全,有小伙伴留心了,在公众号后台问。所以今天专门开个文,写一下关于MongoDB的安全。

一、我的一次MongoDB被黑经历

近几年,MongoDB应用越来越多,MongoDB也越来越火。

从2015年开始,MongoDB被一些「非法组织/黑客」盯上了。他们的做法也很简单,连到你的数据库上,把你的数据拿走,然后把你的库清空,留一个消息给你,索要比特币。

跟最近流行的勒赎病毒一个套路。

我在某个云上有一台服务器,主要用来做各种研究和测试,随时可以格了重装的那种。上面跑着一个MongoDB,是用默认的参数简单启动的一个单实例。

早上起来,跑程序测试时,程序直接报错。

跟踪代码,发现是头天写进去的数据不见了。

进到数据库,发现数据库都在,但里面的表全被清空了,多了一个Readme的表。查看这个表的内容:

> db.Readme.find().pretty()
{
        "_id" : "5c18d077fd42b92d8f6271c3",
        "BitCoin" : "3639hBBC8M7bwqWKj297Jc61pk9cUSKH5N",
        "eMail" : "mongodb@tfwno.gf",
        "Exchange" : "https://localbitcoins.com",
        "Solution" : "Your database is downloaded and backed up on our secured servers. To recover your lost data: Send 0.2 BTC to our BitCoin address and Contact us by eMail with your server IP address and a proof of Payment. Any eMail without your IP address and a proof of Payment will be ignored. Your are welcome!"
}

简单来说,这是一个通知:你的数据被我们绑架了,想要赎回去,需要0.2个比特币。

一身冷汗。如果这是一个生产环境,如果这是一个系统的运营数据,后果不堪设想。

究其原因,这个数据库在启动时,用了默认的参数,未加任何防护。

所以,

一定不要用默认的设置运行MongoDB数据库!

一定不要用默认的设置运行MongoDB数据库!

一定不要用默认的设置运行MongoDB数据库!

二、安全实践

1. 修改端口

MongoDB启动时,使用了几个默认的端口:

27017: 用于一般的单实例(mongod),或者集群中路由服务器(mongos)

27018: 用于集群中的分片服务器

27019: 用于集群中的配置服务器

实际布署时可以把默认端口换成别的端口。

命令行:

$ ./mongod --port port_number

配置文件:

port=port_number

2. 绑定IP

这个要区分一下MongoDB的版本。

查询MongoDB版本的命令:

$ ./mongod --version

在MongoDB Version 3.6之前,MongoDB启动时默认绑定到服务器的所有IP上。换句话说,通过所有的IP都可以访问数据库,这儿的安全隐患在于外网IP。

在3.6之后,MongoDB启动默认绑定127.0.0.1,从外网无法访问,去掉了这个隐患。

设置绑定IP,命令行:

$ ./mongod --bind_ip your_ip #单IP绑定

$ ./mongod --bind_ip your_ip1,your_ip2 #多IP绑定

配置文件:

bind_ip=your_ip #单IP绑定

bind_ip=your_ip1,your_ip2 #多IP绑定

MongoDB还提供了一个一次绑定所有IP的参数。命令行:

$ ./mongod --bind_ip_all

配置文件:

bind_ip_all=true

另外,绑定时,your_ip也可以换成域名your_host,效果是一样的。

在生产环境中,出于安全的需要,通常可以设置数据库绑定到服务器的内网IP,供数据层操作数据库就好。如果有特殊需要,可以临时绑定到外网IP,操作完成后再去掉。

数据库切换绑定IP和端口,对数据库本身没有任何影响。

3. 数据库服务器内部身份认证

数据库服务器的内部身份认证,是更高一个层次的安全策略,用于保证主从/复制集/集群中各个数据库服务器的安全合法接入。

内部身份认证,首先需要有一个数字密钥。

数字密钥可以使用机构签发的证书来生成,也可以使用自生成的密钥。

当然在低安全级别的情况下,你也可以随手写一个密钥来使用。

自生成密钥的生成命令:

$ openssl rand -base64 756 > path_to_keyfile

然后设置密钥文件的读写权限:

$ chmod 400 path_to_keyfile

看一下密钥文件:

$ ls -l
-rw-r--r--  1 test  test  1024  5 10 17:51 test.key

下面,为数据库启用密钥文件。命令行:

$ ./mongod --keyFile path_to_keyfile

配置文件:

keyFile=path_to_keyfile

注意:

  • 内部认证用在多于一个服务器的情况,例如:主从/复制集/集群上,做服务器之间的互相认证。单个服务器可做可不做,实际上无效。

  • 内部认证要求认证的服务器使用相同的密钥文件。也就是说,所有的服务器使用同一个密钥文件。

  • 密钥文件有安全要求,文件权限必须是400,否则数据库启动时会有报错。

4. 用户和角色鉴权

MongoDB支持为数据库创建用户和分配角色,用用户和角色来管理和使用数据库。

MongoDB创建用户操作和上面不同。上边的内容,是在数据库运行以前进行,而创建用户,是在数据库运行以后。

$ ./mongo your_ip:your_port
> use admin
switched to db admin
> db.createUser({"user" : "user_name""pwd" : "user_password","roles" : [{"role" : "userAdminAnyDatabase""db" : "admin"}]})
Successfully added user: {
    "user" : "user_name",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}

这样我们就加入了一个用户。

MongoDB内建的角色分以下几类:

  • 超级用户:root
  • 数据库用户角色:read、readWrite
  • 数据库管理角色:dbAdmin、dbOwner、userAdmin
  • 集群管理角色:clusterAdmin、clusterManager、clusterMonitor、hostManager
  • 可操作所有数据库角色:readAnyDatabase、readWriteAnyDatabase、userAdminAnyDatabase、dbAdminAnyDatabase
  • 备份、恢复角色:backup、restore

角色不详细解释了,角色名称的英文写的很明白。

在实际操作中,通常会将用户建在admin中,用roles里的db来指定用户可以使用或管理的数据库名称。

通过这一通操作,我们已经在数据库中创建好了用户。下面需要服务器启用鉴权。

命令行:

./mongod --auth

配置文件:

auth=true

这个用于mongod启动的数据库。对于集群的router,即mongos,会默认启用auth,所以不需要显式启用。

当MongoDB启用鉴权后,再用mongo客户端连接数据库,就需要输入用户帐号信息了。

$ ./mongo -u user_name -p user_password your_ip:your_port/admin

$ ./mongo -u user_name -p your_ip:your_port/admin #提示输入密码

同样,在代码中,数据库连接串也同步变成了:

"MongoConnection""mongodb://user_name:user_password@localhost:27017/admin?wtimeoutMS=2000"

三、总结

一般来说,做完上面的安全处理,就可以完全满足生产环境的安全要求了。

再高的要求,可以通过启用TLS来强化。这会是另一个文章。

 


 

微信公众号:老王Plus

扫描二维码,关注个人公众号,可以第一时间得到最新的个人文章和内容推送

本文版权归作者所有,转载请保留此声明和原文链接

以上是关于MongoDB最佳安全实践的主要内容,如果未能解决你的问题,请参考以下文章

更新片段参数的最佳实践?

在片段和活动之间进行通信 - 最佳实践

android片段-数据传递-最佳实践[重复]

在另一个活动托管的片段之间传递数据的最佳实践

MongoDB开发最佳实践

在android中使用底部导航的最佳实践:活动与片段