概要

在不同的系統(tǒng)中，其實關(guān)于權(quán)限設計是沒有標準方案的。一般地，依據(jù)項目需求進行系統(tǒng)的功能規(guī)劃設計、組織結(jié)構(gòu)設計以及對應的權(quán)限設計等即可。權(quán)限管理是所有后臺系統(tǒng)的都會涉及的一個重要組成部分，主要目的是對不同的人訪問資源進行權(quán)限的控制，避免因權(quán)限控制缺失或操作不當引發(fā)的系統(tǒng)風險問題。從而有效的保證人、角色、資源的有效控制，避免數(shù)據(jù)不當?shù)牟僮鳌㈦[私數(shù)據(jù)的泄露等問題。

RBAC模型

概念

其實，關(guān)于權(quán)限設計最常見的就是基于RBAC模型。而RBAC模型又有RBAC0、RBAC1、RBAC2、RBAC3等幾種常見的模式。RBAC（Role-Based Access Control) 基于角色的訪問控制的設計思想。作為傳統(tǒng)訪問控制（自主訪問，強制訪問）的有前景的代替受到廣泛的關(guān)注。在RBAC中，權(quán)限與角色相關(guān)聯(lián)，用戶通過成為適當角色的成員而得到這些角色的權(quán)限。

RBAC中有4個比較關(guān)鍵的元素：用戶 – 角色 – 權(quán)限 – 資源。

RBAC支持的安全原則

RBAC支持三個著名的安全原則：最小權(quán)限原則、責任分離原則和數(shù)據(jù)抽象原則。

最小權(quán)限原則：RBAC可以將角色配置成其完成任務所需的最小權(quán)限集合。

責任分離原則：可以通過調(diào)用相互獨立互斥的角色來共同完成敏感的任務，例如要求一個計賬員和財務管理員共同參與統(tǒng)一過賬操作。

數(shù)據(jù)抽象原則：可以通過權(quán)限的抽象來體現(xiàn)，例如財務操作用借款、存款等抽象權(quán)限，而不是使用典型的讀、寫、執(zhí)行權(quán)限。

RBAC優(yōu)缺點

（1）優(yōu)點：

簡化了用戶和權(quán)限的關(guān)系。

易擴展、易維護。

（2）缺點：

RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難適應哪些對操作次序有嚴格要求的系統(tǒng)。

這里補充一下術(shù)語解釋：

（1）、資源

被安全管理的對象（Resources頁面、菜單、按鈕、訂單等）。

(2）、 權(quán)限

問和操作資源的許可（Permit刪除、編輯、審批等）。

（3）、角色

用戶通過業(yè)務需求確定一個角色（Role），并按照實際的業(yè)務場景，賦予角色對應的權(quán)限的過程，角色也可以理解是權(quán)限的集合，是眾多權(quán)限顆粒組成。

（4）、 用戶

系統(tǒng)實際的操作員（User）

（5）、操作權(quán)限

頁面權(quán)限：即用戶登錄系統(tǒng)可以看到的頁面，由菜單來控制，菜單包括一級菜單或多級菜單。當系統(tǒng)賦予用戶對應菜單的權(quán)限，那么用戶就可以訪問對應的菜單頁面。

操作權(quán)限：即頁面的功能按鈕，包括：查看、新增、修改、刪除、審核等。當用戶點擊按鈕時，系統(tǒng)將會校驗用戶的是否包含次操作權(quán)限，如果有，就可以進行下一步操作。

數(shù)據(jù)權(quán)限 ：數(shù)據(jù)權(quán)限就是用戶在同一頁面看到的數(shù)據(jù)是不同的。比如項目管理員，就能看到當前團隊正在進行中的項目，以及項目的進度情況。而團隊成員，就只能看到本人具體參與的項目，已經(jīng)項目信息。相對于復雜一項的權(quán)限也可以基于組織結(jié)構(gòu)來拓展。

總的來說，一般我們會這樣來用一句話更好的理解它：【用戶(user：誰)】被賦予【角色(role：具有1-n個權(quán)限)】，通過角色關(guān)聯(lián)的【權(quán)限(permit：許可)】去訪問/操作【資源(resource)】。如下圖：

RBAC0模式

這是權(quán)限最基礎也是最核心的模型，基本上絕大多數(shù)就是基于它來建設，包括用戶、角色、權(quán)限。其中用戶和角色可以是多對多的關(guān)系；角色和權(quán)限也是多對多的關(guān)系。

用戶是發(fā)起操作的主體，可以是業(yè)務性的訪問者、可以是后臺管理系統(tǒng)的用戶。角色起到了橋梁的作用，連接了用戶和權(quán)限的關(guān)系。由于角色和權(quán)限的關(guān)系是多對多，而用戶與角色也是多對多的關(guān)系，所以一個用戶就有一個或多個角色一個或多個系統(tǒng)權(quán)限（這里關(guān)于針對比較簡單的系統(tǒng)，例如用戶量很小，項目級別也很小的系統(tǒng)，可以采用用戶直接和權(quán)限關(guān)聯(lián)。也就是添加一個用戶，就直接針對用戶去添加對應的權(quán)限，可以沒有角色的概念。針對這種情況，在此不展開討論）。

一般的系統(tǒng)中，引入角色（Role）就是為了提升了系統(tǒng)操作的效率和拓展性。權(quán)限是用戶可以訪問的資源，包括：頁面權(quán)限、作權(quán)限、數(shù)據(jù)權(quán)限等（具體解釋看上面的術(shù)語部分）。下面用具體的圖例來展示：

RBAC1模式

RBAC1模式是RBAC0的拓展。主要是在角色上引入了角色繼承（Hierarchical Role）的概念。即角色具有上下級的關(guān)系，角色間的繼承關(guān)系可分為一般繼承（General）和受限繼承（Limited）關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個絕對偏序關(guān)系，允許角色間的多繼承。而受限繼承關(guān)系則進一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)，實現(xiàn)角色間的單繼承，受限繼承則增強了職責關(guān)系的分離。這種設計可以給角色分組和分層，一定程度簡化了權(quán)限管理工作。

這里舉一個場景例子，比如銷售團隊，銷售主管或經(jīng)理一般會需要了解并匯總下面銷售專員的數(shù)據(jù)。而銷售專員能夠管理各自的銷售數(shù)據(jù)。此時，銷售主管就需要向下繼承銷售專員的角色，進而也就擁有了他們的基本權(quán)限。

RBAC2模式

RBAC2同樣建立在RBAC0基礎之上，僅是對用戶、角色和權(quán)限三者之間增加了一些限制，實現(xiàn)了責任分離。RBAC2中的一個基本限制是互斥角色的限制，互斥角色是指各自權(quán)限可以互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權(quán)。該模型有以下幾種約束：

（1）互斥角色

同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則?；コ饨巧侵父髯詸?quán)限互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權(quán)。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。

（2）基數(shù)約束

一個角色被分配的用戶數(shù)量受限；

一個用戶可擁有的角色數(shù)目受限；

同樣一個角色對應的訪問權(quán)限數(shù)目也應受限，以控制高級權(quán)限在系統(tǒng)中的分配。例如公司的領導人有限的。

（3）先決條件角色

可以分配角色給用戶僅當該用戶已經(jīng)是另一角色的成員；對應的可以分配訪問權(quán)限給角色，僅當該角色已經(jīng)擁有另一種訪問權(quán)限。指要想獲得較高的權(quán)限，要首先擁有低一級的權(quán)限。

（4）運行時互斥

允許一個用戶同時擁有多個角色，但在系統(tǒng)運行中或部分特殊場景不可同時使用這兩個角色，只能使用其中一種角色。

這些限制可以分成兩類，即靜態(tài)職責分離SSD（Static Separation of Duty）和動態(tài)職責分離DSD（Dynamic Separation of Duty）。

（1）靜態(tài)職責分離（SSD）

當角色授權(quán)給用戶時，需要判斷當前用戶是否被賦予了一個與新角色沖突的角色，沖突的角色位一個二元關(guān)系，任何一個用戶在此場景下只能擁有其中一個角色。

（2）動態(tài)職責分離（DSD）

在角色分配時可以將沖突的角色賦予給同一個用戶，但是在用戶使用系統(tǒng)時，一次會話中不能同時激活兩個角色。

RBAC3模型

即最全面的權(quán)限管理，它是基于RBAC0，將RBAC1和RBAC2進行了整合。這種模式即要維護好角色間的繼承關(guān)系處理好分層，又要處理角色間的責任分離。模型公式：RBAC3 = RBAC1 + RBAC2 。

場景實戰(zhàn)

需求場景

我們目前在做一款toB的產(chǎn)品，采用SaaS的模式對外B端客戶提供服務。目標就是如何規(guī)劃好平臺的管理、租戶的管理、租戶應用的管理以及租戶業(yè)務流程等內(nèi)容的管理。我們將SaaS平臺基本角色分為平臺管理員、平臺運維、平臺開發(fā)、租戶管理員、租戶子管理員、租戶其他角色組成。在這里，我將我們SaaS服務的權(quán)限部分設計分享出來。

設計說明

我們這套設計，涉及兩部分，即完整的企業(yè)組織結(jié)構(gòu)和角色組。所以這里針對部分概念進行說明。

組織（部門）

針對toB的產(chǎn)品，往往要考慮如何支撐起企業(yè)的組織結(jié)構(gòu)，比如企業(yè)的部門層級。同時組織結(jié)構(gòu)也可以與角色進行關(guān)聯(lián)，用戶加入組織后，就會自動獲得該組織的默認角色。同時用戶在調(diào)崗時，只需調(diào)整組織、角色即可批量調(diào)整。組織的另外一個作用是控制數(shù)據(jù)權(quán)限，把角色關(guān)聯(lián)到組織，那么該角色只能看到該組織下的數(shù)據(jù)權(quán)限。

用戶組（角色組）

在系統(tǒng)中，存在相同屬性或操作功能的用戶存在。隨著使用的用戶基數(shù)增大、角色類型增多時，分配的工作就會越發(fā)的繁瑣。這里可以增加用戶組的概念來統(tǒng)一規(guī)劃這一部分用戶的權(quán)限管理。在上面的設計中，角色組中的崗位、職位就充當了這部分的作用。以后其他用戶加入對應的用戶組（角色組）后，即可自動獲取用戶組的所有角色。退出用戶組，同時也撤銷了用戶組下的角色，無須管理員手動管理角色。

職位 / 崗位

每個組織部門下都會有多個職位或崗位，比如IT技術(shù)部會有技術(shù)總監(jiān)、技術(shù)經(jīng)理、研發(fā)組長、開發(fā)等職位。雖然都在同一部門，但是每個職位的權(quán)限是不同的，職位高的擁有更多的權(quán)限。研發(fā)總監(jiān)擁有所有權(quán)限，研發(fā)組長和開發(fā)擁有部分權(quán)限。有些特殊情況下，一個人可能身兼多職。

角色

角色是權(quán)限控制的最小單位（不是權(quán)限的最小單位），通過角色來進行權(quán)限資源的分配。在上面的設計中，就是遵循RBAC模式進行的設計。例如管理角色組，就涉及到了RBAC1，主管理員同時擁有子管理員的權(quán)限；同時也涉及到了RBAC2，一個組織只能有一個主管理員（基數(shù)約束 ），但是可以有多個子管理員。

含有組織、職位、用戶組、角色模型

通過根據(jù)以上場景，平臺的權(quán)限模型設計如下圖：

以上基本就是關(guān)于我們一個項目的權(quán)限設計部分。

回歸討論點

關(guān)于溝通的問題，總的來說有以下幾點：

1、對權(quán)限專業(yè)知識的學習和理解。

我記得在《致2019年的自己》總結(jié)中，也重點提到就是建立相應專業(yè)知識體系。為什么這個比較重要呢。在這里插入一個笑話。有次一小伙和我討論關(guān)于SaaS。剛開始我給他介紹了我的一些SaaS的理解。而后讓我比較頭疼的是，對方聊的并非SaaS，而是“sass”。這區(qū)別可大了去。前者是服務設計模式或方法，后者是前端的一種CSS的技術(shù)。

回歸正題，我們應該要建立起相對專業(yè)的知識體系，這個可能直接影響到我們對知識的認知、業(yè)務架構(gòu)的設計等方面。同時在溝通過程中是否能在同一個點開展討論，而不造成尷尬的局面。在溝通過程中，采用相對專業(yè)的術(shù)語，大家一聽就懂并很快能領會。如果采用自己的語言可能造成對方無法理解。

2、需求設計者應了解相關(guān)的知識，而并非標榜“我是做需求的”。

其實，關(guān)于系統(tǒng)的設計、技術(shù)的選型是由需求來驅(qū)動的。畢竟項目管理最后要落眼到成本、進度上。我見過一些需求設計，需求點可能是不錯的，但是缺乏相應的知識了解，導致在傳達上或原型設計上出現(xiàn)的偏差甚至是錯誤。就以權(quán)限為例，我們在這個項目上其實走了一些彎路，核心的問題就在于需求，由于對于權(quán)限一些知識不了解，造成設計稿只能按照意思設計出來，研發(fā)卻實現(xiàn)出現(xiàn)問題。

這里就體現(xiàn)的專業(yè)知識的重要性。需求設計者不一定要深層次的研究技術(shù)，而是要了解并理解它們的一些基本原理和設計思想。尤其是在和技術(shù)研發(fā)溝通過程中，如果采用的是專業(yè)性的知識溝通，那么既能節(jié)約溝通成本，也能縮小理解上的誤差，更重要的是系統(tǒng)架構(gòu)結(jié)構(gòu)設計趨向更加穩(wěn)定。

3、靈活的運用對應知識

一個技術(shù)的學習和理解，并不代表照抄照搬。比如，我在同朋友針對權(quán)限這塊的交流中，真正的價值是對于權(quán)限的設計思路和方法，而并非某個項目上的具體實現(xiàn)。畢竟項目的“獨特性”不能忽略。因為每個項目的業(yè)務不同，面對的用戶群體不同，所以權(quán)限的具體細節(jié)自然不同。所以我們應該更加側(cè)重于權(quán)限體系的知識，可以拓展對于不同場景，應該如何來設計。所以，我們應該先對一個知識有一定的學習和理解，接著就是靈活的應用和整合。

數(shù)商云全鏈數(shù)字化產(chǎn)品解決方案， 實現(xiàn)供應鏈上中下游資源整合管理

--------

SCM供應鏈 / SRM供應商 / B2B電商 / 采購管理 / DMS渠道商 / 經(jīng)銷商管理

SaaS多租戶  / S2B2C電商 / S2B2B電商

0 費 用 系 統(tǒng) 演 示

▼

文章來源：DevOps；

編輯：云朵匠 | 數(shù)商云(微信ID：shushangyun_com)

【數(shù)商云m.zhimaihui.cn】致力于提供企業(yè)級的商城開發(fā)服務，長期為大中型企業(yè)打造數(shù)據(jù)化、商業(yè)化、智能化的saas多租戶商城系統(tǒng)解決方案，同時我們還提供B2B電子商務平臺、B2B2C多用戶商城系統(tǒng)、B2C電子商務系統(tǒng)、跨境進口電商平臺、供應商平臺、新零售電商平臺、直播電商系統(tǒng)等一系列供應鏈平臺定制開發(fā)服務。