◆李晔锋

MongoDB的RBAC访问控制技术研究

◆李晔锋1,2

（1.北京工业大学计算机学院 北京 100124；2.宁波工程学院电信学院 浙江 315211）

作为一种开源的NoSQL数据库，MongoDB被广泛应用于大数据处理与分析中，因此它的安全性显得至关重要。MongoDB使用基于角色的访问控制（RBAC）方式来控制属于不同角色的用户对数据库资源的访问。本文针对MongoDB以文档形式存储数据和非SQL形式访问数据的特点，分析了该访问控制模型中的各组成部分以及它们之间的关系，从而总结出这种访问控制方式的优缺点。

NoSQL；MongoDB；RBAC

0 前言

MongoDB是开源的文档型NoSQL数据库，它摆脱了关系模型的限制，具有灵活的存储结构，并且支持分布式部署，使得它的查询性能远高于关系数据库[1]，因此被广泛应用于云计算和大数据环境[2]。但是NoSQL的安全性普遍相对薄弱，Zahid在他的学术论文[3]中对各种分片式的NoSQL数据库进行了比较，其中对MongoDB的评论如下:“数据库的安全配置等级非常低，完全依赖于数据库管理员”。因此，在学术界和企业界有不少提高MongoDB安全性的研究，例如Sathyadevan等人提出了一种提升MongoDB数据级别安全的解决方案[4]，Hou等人对MongoDB的注入情况进行了检测和分析[5]，师德清把MongoDB应用到CRP系统中，并对它的安全认证机制进行分析[6]，宋志毅等人实现了基于MongoDB的数据加密技术[7]。本文从访问控制的角度分析MongoDB的安全性，首先在第一章介绍MongoDB的存储和访问特性，然后在第二章阐述现有的一些访问控制技术，接着在第三章重点分析MongoDB中RBAC模型的各组成部分以及它们之间的关系，最后在第四章总结全文。

1 MongoDB概述

1.1 MongoDB的数据存储方式

MongoDB只有三种存储对象:数据库（Database）、集合（Collection）和文档（Document），它们被统称为资源（Resource）。数据库是最高级存储对象，由多个集合组成；集合相当于关系数据库的表,每个集合包含多个文档；文档是MongoDB的最小存储单元,它采用了BSON结构,每个文档包含多个“字段”和“取值”对。

BSON是一种类似json的二进制存储格式，它的优点在于支持内嵌的文档对象和数据对象，与关系数据库相比存储结构更加灵活，能够更好地描述数据之间的联系。例如，某个学生李明的语文和数学两门课成绩可以表示如下:

如果使用关系数据库存储这些信息，则需要把学生信息和课程信息分别存储在两张表中，而MongoDB通过这种文档内嵌的方式，能够有效减少集合的数目，规避了连接操作，从而提高了查询性能。此外，MongoDB还会为每个文档对象生成全局唯一的ObjectID作为主键，它不但能够用于区分不同的文档，而且能够用于排序、引用和创建索引，以达到更快的查询速度。

1.2 MongoDB的数据访问方式

作为一种NoSQL的数据库，MongoDB使用了一种交互式的命令对数据库进行操作访问。绝大多数的数据库命令使用函数的方式实现，例如，假设需要在1.1节定义的student集合中需要查找学生“李明”的语文课成绩，则可用如下的find命令实现

db.student.find（{“姓名”:”李明”}，

{“课程”:{$elemMatch:”语文”}，”_id”:0，”课程.成绩”:1}）

命令返回的查询结果也是BSON格式的文档类型，它能够作为中间结果保存在某一个变量中，为下一个查询命令所使用。这种数据访问方式虽然更加灵活，但是对数据库管理员有更高的技术要求。

2 访问控制技术

在20世纪60年代末，科研工作者提出了访问控制技术，其主要目的是防止信息和资源被非常用户访问使用，或被合法用户进行非授权的使用。经过40多年的发展，一些访问控制模型已被广泛应用到各种应用中，包括自主访问控制（DAC）、强制访问控制（MAC）和基于角色的访问控制（RBAC）等。

自主访问控制使用关联表实现主体对客体的访问。关联表可以基于主体或者基于客体，前者以主体为核心，为每个主体创建一个可被它访问的客体以及访问权限的明细表，后者以客体为核心，存储可以对它访问的主体以及访问权限的明细表。这种访问控制技术的优点在于灵活性较好，实现简单，缺点在于关联表占用大量的存储空间，并且对权限的传递以及客体的副本管理相当困难。

强制访问控制为每个主体和客体分配安全标签，每种标签以不同的取值来表示安全等级，这样主体对客体的访问权限取决于安全标签的等级组合。这处访问控制技术同样实现简单，并且数据只能根据标签等级从一级流向一级，具有较强的机密性，缺点在于灵活性不够，而且牺牲了数据的完整性。

基于角色的访问控制模型由乔治梅森大学的Sandhu等人于1996年首次提出，经过不断的完善形成了RBAC96模型簇[8]，它的核心思想是在用户和权限之间引入了角色（Role）的概念，如图1所示，通过用户分配（UA）和权限分配（PA）为用户（主体）和权限之间的关联。相比DAC和MAC，它更具灵活性和安全性，但是缺乏操作顺序的控制机制。

图1 RBAC模型核心结构

2004年，Sandhu等人又提出了一种使用控制模型（UCON）[9]，被学术界命名为“下一代访问控制模型”。该模型对传统的存取控制进行了一定的扩展，定义了授权（Authorization）、义务（Obligation）和条件（Condition）三个新的因素，以及存取控制的连续性（Continuity）和可变性（Mutability）两个新的属性，具有更高的安全性、灵活性和有效性，但是模型的定义也更加抽象，不利于具体实现，因此并没有在信息安全领域得到广泛应用。

3 MongoDB的RBAC模型分析

MongoDB使用RBAC管理用户的访问控制，它的核心结构与图1类似，只不过它把具体的操作行为（Action）与被操作的对象放在一起统称为权限（Previlege）。

3.1 MongoDB的用户

MongoDB在安装完成后没有任何用户，不用登录即可任意创建数据库和集合，也可以对元数据库admin中的部分集合进行操作，因此不具有任何安全性，必须手动创建用户才能激活验证功能。

MongoDB使用db.createUser命令创建用户，所有的用户信息被存储在admin数据库下的system.users集合中。默认情况下，用户属于创建时所在的数据库，并只能对该数据库进行操作。但是在admin数据库下创建的用户可以被赋予相应的角色访问多个数据库。例如，使用下面的命令即可创建一个超级用户sa，它被赋予root角色，可以对整个数据库执行任何操作。

use admin

db.createUser（{user:”sa”，pwd:”123456”，roles:[“root”]}）

此后，重新启动Mongd服务并加上--auth参数，然后再启动Mongo控制台，需要先切换到admin数据库下，再使用db.auth命令进行登录验证才可以进一步的操作。

3.2 MongoDB的权限

MongoDB的权限由操作行为和被操作的对象组成，用BSON结构可以表示如下:

其中resource字段表示被操作的对象，可以是数据库或集合，也可以是分布式模式下的集群。另一个字段actions表示行为，它们可以是操作性的，例如1.2节所述的数据查找find命令，以及数据插入insert操作等，也可以是控制性的，例如3.1节所述的createUser命令，以及修改密码changePassword等等。

每个权限定义中只能指定一个资源，但是可以有多个访问行为，表示可以对某个资源进行哪些操作。因此，MongoDB中的权限不再拘泥于传统的“读”、“写”和“执行”等操作，更加灵活机动以适应用户的各种需要。

3.3 MongoDB的角色

角色是MongoDB访问控制模型中的核心组件，也是连接用户和权限的纽带。MongoDB中已经自带了一些系统定义的角色，此外用户还可以通过组合权限自定义角色。MongoDB中角色的BSON描述形式如下:

其中的privileges字段中以数组的形式包含了该角色拥有的权限，每个权限的构造如3.2节所述；roles字段中包含了该角色继承的其它角色，每个被继承的角色表现形式为:{role:“<角色名>”，db:“<数据库名>”}。角色继承是MongoDB的重大特点，例如3.1节中定义超级用户sa时用到的root角色就是由多个基本角色中继承而来。

在系统自带的角色中，包含同一类型行为的权限被放在了一起，例如read角色拥有一些只读行为如find、listCollections、 listIndex等的权限，而userAdmin角色中包含了一些管理级的行为如createRole、createUser、changePassword等。行为跟角色之间是多对多关系，即一个角色可以有多个行为，而某个行为可以出现在不同的角色中。类似，用户跟角色之间也是多对多关系，即一个用户可以拥有多个角色，而某个角色可以属于不同的用户（比如有多名系统管理员角色）。

用户的自定义角色通过createRole命令创建，并存放在admin数据库的system.roles集合中。对于在admin数据库中创建的角色，它可以拥有操作任意数据库的权限，并且能够继承在任意数据库中创建的其它角色；对于在普通数据库中创建的角色，只能拥有操作本数据库的权限，并且只能继承在本数据库中创建的其它角色。

3.4 MongoDB的RBAC模型安全隐患

尽管MongoDB的RBAC的模型具有较强的灵活性，但由于它的角色并没有等级划分，导致一些低端角色可以分配高端角色。在3.3节中提到的userAdmin角色无法对数据库进行find、update等访问行为，但它可以执行createRole、createUser等数据库管理行为，从而能够创建具有root角色的用户来获取数据库中的具体内容。由于MongoDB的角色具有继承的特性，因此一旦与该角色相关的账户信息被遗失，对数据库的安全将造成极大的威胁。

解决这个问题的关键在于制订角色的安全等级划分机制，即低等级的角色无法创建或为用户分配高等级的角色，保证角色中的权限不被滥用。

4 结束语

本文通过对比传统的访问控制技术，研究了MongoDB的RBAC模型。总体而言，MongoDB的这种访问控制机制具有较高的灵活性和安全性，但由于角色没有被划分安全等级，一些低端角色能够分配高端角色，从而获取更高的访问权限。因此，在MongoDB数据库的使用过程中，必须确保一些关键角色的信息不被丢失，以免造成严重的安全事故。

[1]Plugge E，Hawkins T，Membrey P.The Definitive Guide to MongoDB:The NoSQL Database for Cloud and Desktop Computing[J].Springer Ebooks，2010.

[2]杜卫华.浅析基于MongoDB的云数据管理技术的研究与应用[J].网络安全技术与应用，2014.

[3] Zahid A，Masood R，Shibli M A.Security of sharded NoSQL databases:A comparative analysis[C]// Information Assurance and Cyber Security.IEEE，2014.

[4]Sathyadevan S，Muraleedharan N，Rajan S P.Enhancement of Data Level Security in MongoDB[M]// Intelligent Distributed Computing.Springer International Publishing，2015.

[5] Hou B，Qian K，Li L，et al.MongoDB NoSQL Injection Analysis and Detection[C]// IEEE，International Conference on Cyber Security and Cloud Computing.IEEE，2016.

[6]师德清.浅析MongoDB数据库在CRP系统中的安全认证机制[J].科协论坛，2011.

[7]宋志毅，马兆丰，黄勤龙.基于保序加密的MongoDB数据加密技术研究与实现[C].中国通信学会学术年会，2014.

[8]Sandhu R.Rationale for the RBAC96 family of access control models[C]// ACM Workshop on Role-Based Access Control.ACM，1996.

[9]Park J，Sandhu R.The UCON ABC，usage control model[J].Acm Transactions on Information & System Security，2004.