一文讀懂圖資料庫 Nebula Graph 通路控制實作原理

摘要：資料庫權限管理對大家都很熟悉，然而怎麼做好資料庫權限管理呢？在本文中将詳細介紹 Nebula Graph 的使用者管理和權限管理。

本文首發 Nebula Graph 部落格： https://nebula-graph.com.cn/posts/access-control-design-code-nebula-graph/

資料庫權限管理對大家來說都已經很熟悉了。Nebula Graph 本身是一個高性能的海量圖資料庫，資料庫的安全問題更是資料庫設計的重中之重。目前 Nebula Graph 已支援基于角色的權限控制功能。在這篇文章中将詳細介紹 Nebula Graph 的使用者管理和權限管理。

Nebula Graph 架構體系

由上圖可知，Nebula Graph的主體架構分為三部分：Computation Layer、Storage Layer 和 Meta Service。Console 、API 和 Web Service 被統稱為 Client API。賬戶資料和權限資料将被存儲在 Meta Engine中，當Query Engine 啟動後，将會初始 Meta Client，Query Engine 将通過 Meta Client 與 Meta Service 進行通信。

當使用者通過 Client API 連接配接 Query Engine 時，Query Engine 會通過 Meta Client 查詢 Meta Engine 的使用者資料，并判斷連接配接賬戶是否存在，以及密碼是否正确。當驗證通過後，連接配接建立成功，使用者可以通過這個連接配接執行資料操作。當使用者通過 Client API 發送操作指令後，Query Engine 首先對此指令做文法解析，識别操作類型，通過操作類型、使用者角色等資訊進行權限判斷，如果權限無效，則直接在 Query Engine 阻擋操作，并傳回錯誤資訊至 Client API。在整個權限檢查的過程中，Nebula Graph 對 Meta data 進行了緩存，将在以下章節中介紹。

功能描述

在介紹功能之前，需要先描述一下 Nebula Graph 的邏輯結構：Nebula Graph 是一個支援多圖空間（Space) 的圖資料庫，Space 中獨立管理 Schema 和 Data，Space 和 Space 之間互相獨立。另外，Nebula Graph 還提供了一系列進階指令用于全局管理 Cluster，Cluster 的操作指令和 Space 的操作指令将在下文中較長的描述。

是以 Nebula Graph 的權限管理将會基于圖空間（Space）、角色（Role）、操作（Operation）三個次元進行。較長的描述請看下列子章節。

角色劃分

Nebula Graph 提供了五種操作角色，分别是 GOD、ADMIN、DBA、USER、GUEST，這五種操作角色基本覆寫了所有的資料安全控制的場景。一個登陸賬戶（Account）可以在不同的 Space 中擁有不同角色，但一個 Account 在同一個 Space 中隻能擁有一種角色。角色講解：

GOD：相當于 Linux 作業系統中的 root 使用者，擁有最高的管理權限。Nebula Graph Cluster 在初始化時會預設建立一個 GOD 角色的 Account，名為 root。
ADMIN：基于 Space 的進階管理者，擁有此 Space 之内的所有管理權限，但對整個叢集則沒有管理權限。
DBA：資料庫管理者，可以對權限内的 Space 進行管理，例如對 Schema / Data 進行修改和查詢。和 ADMIN 的差別是 DBA 不能對某個 Account 進行授權操作，但 ADMIN 可以。
USER：普通的資料庫使用角色。可讀寫 Data，可讀 Schema 但沒有寫權限。
GUEST：通路者角色，對權限内 Space 的 Schema 和 Data 有隻讀權限。

詳細權限清單如下圖所示：

OPERATION	GOD	ADMIN	DBA	USER	GUEST
Read Space	Y
Write Space
Read Schema
Write Schema
Write User
Write Role
Read Data
Write Data
Special operation

注 : Special Operation 為特殊操作，例如 SHOW SPACE，每個角色都可以執行，但其執行結果隻顯示 Account 權限内的結果。

資料庫操作權限細分

基于上邊的角色清單，不同的角色擁有不同的操作許可，詳細如下：

	STATEMENTS
	1. USE 2. DESCRIBE SPACE
	CREATE SPACE DROP SPACE 3. CREATE SNAPSHOT 4. DROP SNAPSHOT 5. BALANCE
	DESCRIBE TAG DESCRIBE EDGE DESCRIBE TAG INDEX DESCRIBE EDGE INDEX
	CREATE TAG ALTER TAG CREATE EDGE ALTER EDGE DROP TAG 6. DROP EDGE 7. CREATE TAG INDEX 8. CREATE EDGE INDEX 9. DROP TAG INDEX 10. DROP EDGE INDEX
	CREATE USER DROP USER ALTER USER
	GRANT REVOKE
	GO PIPE LOOKUP YIELD ORDER BY FETCH VERTEX FETCH EDGE FIND PATH LIMIT GROUP BY 11. RETURN
	REBUILD TAG INDEX REBUILD EDGE INDEX INSERT VERTEX UPDATE VERTEX INSERT EDGE UPDATE DEGE DELETE VERTEX DELETE EDGE
Special Operation	1. SHOW，eg: SHOW SPACE 、 SHOW ROLES CHANGE PASSWORD

控制邏輯

Nebula Graph 的使用者管理和權限管理和大多數資料庫的控制相似，基于 meta server，對圖空間（Space）、角色（Role）、操作（Operation）三個層面進行權限管理，當 Client 連接配接 Nebula Graph Server 的時候，Nebula Graph Server 首先會驗證登陸賬戶（Account）是否存在，并驗證密碼是否有效。

登入成功後，Nebula Graph Server 會為此連接配接初始 Session ID，并将 Session ID、使用者資訊、權限資訊和 Space 資訊一起加載到 Session 結構中。後續的每次操作将基于 Session 結構中的資訊進行權限判斷。直到使用者主動退出連接配接或 session timeout，Session 銷毀。另外，Meta Client 對權限資訊進行了緩存，并根據設定的時間頻率進行緩存同步，有效降低了使用者連接配接的過程的時間耗費。

控制邏輯代碼片段

Permission Check

bool PermissionCheck::permissionCheck(session::Session *session, Sentence* sentence) {
    auto kind = sentence->kind();
    switch (kind) {
        case Sentence::Kind::kUnknown : {
            return false;
        }
        case Sentence::Kind::kUse :
        case Sentence::Kind::kDescribeSpace : {
            /**
             * Use space and Describe space are special operations.
             * Permission checking needs to be done in their executor.
             * skip the check at here.
             */
            return true;
        }
        ...

Permission Check Entry

Status SequentialExecutor::prepare() {
    for (auto i = 0U; i < sentences_->sentences_.size(); i++) {
        auto *sentence = sentences_->sentences_[i].get();
        auto executor = makeExecutor(sentence);
        if (FLAGS_enable_authorize) {
            auto *session = executor->ectx()->rctx()->session();
            /**
             * Skip special operations check at here. they are :
             * kUse, kDescribeSpace, kRevoke and kGrant.
             */
            if (!PermissionCheck::permissionCheck(session, sentence)) {
                return Status::PermissionError("Permission denied");
            }
        }
   ...
}

示例

檢視現有使用者角色

([email protected]:6999) [(none)]> SHOW USERS;
===========
| Account |
===========
| root    |
-----------
Got 1 rows (Time spent: 426.351/433.756 ms)

建立使用者

([email protected]:6999) [(none)]> CREATE USER user1 WITH PASSWORD "pwd1"
Execution succeeded (Time spent: 194.471/201.007 ms)

([email protected]:6999) [(none)]> CREATE USER user2 WITH PASSWORD "pwd2"
Execution succeeded (Time spent: 33.627/40.084 ms)

# 檢視現有使用者角色

([email protected]:6999) [(none)]> SHOW USERS;
===========
| Account |
===========
| root    |
-----------
| user1   |
-----------
| user2   |
-----------
Got 3 rows (Time spent: 24.415/32.173 ms)

為 Space 中的不同 Account 指定角色

# 建立圖空間

([email protected]:6999) [(none)]> CREATE SPACE user_space(partition_num=1, replica_factor=1)
Execution succeeded (Time spent: 218.846/225.075 ms)

([email protected]:6999) [(none)]> GRANT DBA ON user_space TO user1
Execution succeeded (Time spent: 203.922/210.957 ms)

([email protected]:6999) [(none)]> GRANT ADMIN ON user_space TO user2
Execution succeeded (Time spent: 36.384/49.296 ms)

檢視特定 Space 的已有角色

([email protected]:6999) [(none)]> SHOW ROLES IN user_space
=======================
| Account | Role Type |
=======================
| user1   | DBA       |
-----------------------
| user2   | ADMIN     |
-----------------------
Got 2 rows (Time spent: 18.637/29.91 ms)

取消特定 Space 的角色授權

([email protected]:6999) [(none)]> REVOKE ROLE DBA ON user_space FROM user1
Execution succeeded (Time spent: 201.924/216.232 ms)

# 檢視取消之後，user_space 現有角色

([email protected]:6999) [(none)]> SHOW ROLES IN user_space
=======================
| Account | Role Type |
=======================
| user2   | ADMIN     |
-----------------------
Got 1 rows (Time spent: 16.645/32.784 ms)

删除某個 Account 角色

([email protected]:6999) [(none)]> DROP USER user2
Execution succeeded (Time spent: 203.396/216.346 ms)

# 檢視 user2 在 user_space 的角色

([email protected]:6999) [(none)]> SHOW ROLES IN user_space
Empty set (Time spent: 20.614/34.905 ms)

# 檢視資料庫現有 account

([email protected]:6999) [(none)]> SHOW USERS;
===========
| Account |
===========
| root    |
-----------
| user1   |
-----------
Got 2 rows (Time spent: 22.692/38.138 ms)

本文到此結束，如果你喜歡本文，可以給我們點個 star 喲 😊 GitHub 傳送門：

https://github.com/vesoft-inc/nebula

；

想了解、交流圖資料庫技術的小夥伴，可以聯系 Nebula Graph 官方小助手微信号：

NebulaGraphbot

來群裡和業内大牛聊聊喲~~

Hi，我是 bright-starry-sky，是圖資料 Nebula Graph 研發工程師，對資料庫存儲有濃厚的興趣，希望本次的經驗分享能給大家帶來幫助，如有不當之處希望你能在本文【評論】區留言，謝謝~

一文讀懂圖資料庫 Nebula Graph 通路控制實作原理

Nebula Graph 架構體系

功能描述

角色劃分

資料庫操作權限細分

控制邏輯

控制邏輯代碼片段

Permission Check

Permission Check Entry

示例

檢視現有使用者角色

建立使用者

為 Space 中的不同 Account 指定角色

檢視特定 Space 的已有角色

取消特定 Space 的角色授權

删除某個 Account 角色

繼續閱讀

《Linux指令行與Shell腳本程式設計大全第2版.布盧姆》pdf

禁止ubuntu系統彈出報錯界面

MySQL的4種隔離級别？出現問題

Ubuntu Linux下Apache的配置檔案

XX系統實施過程問題總結

無元件上傳圖檔到資料庫中，最完整解決方案

【MySQL資料庫】資料庫索引事務1.索引2.事務

neo4j之cypher使用文檔

NOSQL安全攻擊

mybatis_入門程式Mybatis入門

samba伺服器的功能

登入plsql 報錯 the account is locked --使用者被鎖

【Linux】UDP廣播封包接收速率問題

SequoiaDB巨杉資料庫C++驅動概述

Linux裝置模型（中）之上層容器

PowerPC平台 Linux移植三