MongoDB的RBAC訪問控制技術研究

◆李曄鋒

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.