Mongodb安全访问控制操作案例

Posted 鬼鬼骑士

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Mongodb安全访问控制操作案例相关的知识,希望对你有一定的参考价值。

文章目录

安全访问控制

新建mongodb用户

  • 在虚拟机中控制mongodb,并在admin数据库中新建用户
db.createUser(user:"taotao",pwd:passwordPrompt(),roles:[role:"userAdminAnyDatabase",db:"admin"])

修改配置文件开启权限访问

vi /opt/servers/mongodb_demo/mongodb/conf/mongod.conf 
security:
  authorization: enabled

重启mongodb服务

这里我们重启服务使用重启虚拟机方式(比较方便)

启动

mongod -f /opt/servers/mongodb_demo/mongodb/conf/mongod.conf 

权限说明(PPT)


尝试直接访问数据库

数据库为空,因为我们设置了用户权限,必须登录才能正常访问数据库

直接切换admin进行控制,登录用户taotao

  • 注意,需要先使用指定库,再进行登录操作
use admin
db.auth("taotao","12345")

创建基于管理员用户的“子用户”

创建一个基于Admin-taotao的用户taotaouser1,该用户只有admin数据库的read权限

db.createUser(user:"taotaouser",pwd:"12345",roles:[role:"read",db:"admin"])

检查是否创建成功

show users

查看指定用户信息

db.getUser("taotaouser")

尝试使用子用户进行数据库操作

向集合中插入数据

向mycollection集合插入数据

db.mycollection.insert("a":1,"b":2)

权限不足

使用admin用户给taotaouser赋予write权限

db.grantRolesToUser("taotaouser",[role:"readWrite",db:"admin"])

再次尝试使用taotaouser用户添加数据

写数据成功

其他权限、功能赋予或删除[图文]



问题(多个role,代表担任多个角色)

表示此用户既可以读,又可以读写

访问控制

访问控制的含义:

在互联网安全领域,尤其是web安全领域中,“权限控制”的问题可以归结为“访问控制”。

访问控制广泛应用于各个系统中。抽象地说,都是某个主体对某个客体需要实施某种操作,而系统对这种操作的限制就是权限控制。

在一个安全系统中,确定主体的身份是“认证”解决的问题;而客体是一种资源,是主体发起的请求的对象。在主体对客体进行操作的过程中,系统控制主体不能“无限制”的对客体进行操作,这个过程就是“访问控制”。

 

访问控制的分类:

在web应用中,根据访问客体的不同,常见的访问控制可以分为“基于URL的访问控制”、“基于方法的访问控制”、“基于数据的访问控制”。

当访问控制存在缺陷时,会如何呢?

一、未授权访问

在正常情况下,这些页面是不会被链接到前台页面上来的,但是把需要保护的页面“藏”起来,并不是解决问题的办法。

攻击者会使用一部包含很多后台路径的字典把这些“藏”起来的页面扫出来。

 

预防措施:只需要加上简单的“基于页面的访问控制”就可以解决此问题。

 

二、垂直权限管理

访问控制实际上是建立用户与权限之间的对应关系,现在应用广泛的是一种“基于角色的访问控制”,简称RBAC。

RBAC事先会在系统中定义出不同的角色,不同的角色拥有不同的权限。一个角色实际上就是一个权限的集合。

系统所有用户都会被分配到不同的角色中,一个用户可能拥有多个角色,角色之间有高低之分。

在系统验证权限时,只需要验证用户所属角色,然后就可以根据该角色所拥有的权限进行授权了。

 

两个框架:Java框架Spring Security、PHP框架Zend Framework

 

预防措施:

1、不同角色的权限有高低之分。高权限角色访问低权限角色的资源往往是被允许的,而低权限角色访问高权限角色的资源往往则被禁止。

如果一个低权限角色的用户通过一些方法能够获得高权限角色的能力,则发生了“越权访问”

2、在配置权限时,应当使用“最小权限原则”,并使用“默认拒绝”的策略,只对有需要的主体单独配置“允许”的策略。

 

三、水平权限管理

用户A和用户B都属于同一个角色,但是用户A和用户B都各自拥有一些私有数据,在正常情况下,应该只有用户自己才能访问自己的私有数据。

在RBAC基于角色访问控制的模型下,系统只会验证用户A和用户B同属于一种角色,而不会判断用户A是否能访问只属于用户B的私有数据。

因此,发生了“越权访问”。称之为“水平权限管理问题”。

 

相对于垂直权限管理来说,水平权限问题出在同一角色上,系统只验证了能访问数据的角色,既没有对角色内的用户做细分,也没有对数据的子集做细分。因此缺乏一个用户到数据之间的对应关系。因此水平权限管理又可以称为“基于数据的访问控制”。

 

今天的互联网中,垂直权限的问题已经得到普遍的重视,并已经有了很多成熟的解决方案。但水平权限的问题还未得到重视。

首先,对于一个大型复杂系统来说,难以通过扫描等自动化测试方法将问题全部找出来。

其次,对于数据的访问控制,与业务结合十分紧密。有的业务有数据访问控制的需要,有的业务没有。

最后,如果在系统上线后再来处理数据级访问控制的问题,可能会涉及到跨表,跨库查询,对系统的改动较大,同时也可能会影响到性能。

 

预防措施:

1、一个简单的数据级访问控制,可以考虑使用“用户组”的概念。比如一个用户组的数据只属于该组内的成员,只有同一用户组内的成员才能实现对这些数据的操作。

2、可以考虑实现一个规则引擎。将访问控制的规则写在配置文件中,通过规则引擎对数据访问进行控制。

以上是关于Mongodb安全访问控制操作案例的主要内容,如果未能解决你的问题,请参考以下文章

MongoDB 3.0+安全权限访问控制

MongoDB 3.0+安全权限访问控制

MongoDB 访问权限控制

mongodb权限管理(转)

MongoDB Security

MongoDB权限管理之用户名和密码的操作