後臺產品基本功：RBAC權限後臺角色與權限設計

原創： Kevin改變世界的點滴 Kevin改變世界的點滴

昨天

後臺產品經理在設計系統中，隨着業務與用戶量起來後。都會考慮系統的角色與權限設計。藉此經典的角色 與權限設計：RBAC，基於角色的權限訪問控制（Role-Based Access Control）分享近期落地的系統設計案例。

基於這套角色與權限設計會分有：RBAC 0\RBAC 1\RBAC 2這樣的角色與權限設計分類。雖然會有一、二、3的係數區分，但仍是會圍繞基本的理論模型落地，基本上RBAC 0模型就足夠使用，只是相對一、2的效率會低一些。

以前有分享過一個具體的原型設計，是利用這樣的模型搭建起來的。這篇文章的地址在這裏

後臺產品設計|角色與權限

除了原型設計，角色與權限設計的模型也是至關重要的，爲此今天就角色與權限的RBAC模型給你們分享。文中參考來公衆號：倔牛的人生基於RBAC模型的分析。

什麼是RBAC模型

前面有說過，RBAC模型的全名稱。其實核心就是將帳號、角色、權限連接起來的設計方式。

基於上訴，咱們能夠很快的將用戶訪問B/S結構的後臺系統經過不一樣的帳號判斷出背後的角色，到底這個角色包含那些權限去訪問模塊一、資源2.....

在該帳戶所在的角色下，若是沒有該模塊的權限，用戶將沒法使用。相反，便可使用。上訴的流程就保證了用戶操做權限。

這也是基於角色與權限的rbac模型。但要提的是操做權限不一樣外，權限與角色設計還須要考慮數據權限，至於數據權限咱們需要定義清楚它究竟是什麼？

是基於數據庫的增刪改查？仍是數據的擁有權？好比銷售管理平臺的客戶，銷售專員的客戶是能夠被部門銷售經理查看的。但其餘部門的銷售經理是不能查看的。但添加用戶的權限是銷售專員和銷售經理均可以的。

多角色與多用戶

上訴解釋了RBAC模型後，相信你們對角色的定義是很是清楚的。那多角色對多用戶是什麼場景？

簡單來講，一個用戶使用系統要基於一個帳號，用戶以用帳號來登陸使用系統。RBAC模型中，正是基於多帳戶與多角色來創建權限管理。

好比在門店系統中，系統中可能涵蓋的角色有多少呢？咱們簡單舉例下

上訴不一樣的角色就致使了他們在工做中所須要的權限和功能模塊是不一樣的，爲此咱們角色的映射是須要生活中確實存在的職位或角色，在系統中是能夠被建立的。

但也有這樣的狀況，好比咱們的超級管理員、管理員，這樣的角色實際上是沒有實際的職位映射的，爲此咱們須要給予設置系統中默認的「超級帳戶」。他們是擁有這樣的權限與角色，不須要添加或建立。

數據權限

上面說了RBAC的模型設計後，咱們如何考慮數據權限？是否有一個帳戶能夠在超級管理員下，有默認的最大數據權限？

答案是確定的，針對最高階的角色，系統應該給予一個默認的全局權限與數據。雖然不一樣的權限建立了角色，但在系統全局中的超級管理員是不該該被建立的。

試想，除了系統開發者外，誰能建立超級管理員？

爲此，站在數據權限頂部的「超級用戶」是咱們在系統搭建的時候須要給予的默認。其餘角色就可用經過配置建立，固然你也能夠給予他最高的操做權限。

將全部頁面與button，都歸屬於某一個角色，其實這個角色也是超級管理員。但他的數據權限卻不是，數據權限卻只會跟着系統默認的超級管理員走。在系統中所建立的角色仍是會依照角色建立的數據邏輯。（這個邏輯須要產品經理給予設計）

這個角色歸屬於那個帳戶，這個帳戶有多少數據只有在這個帳戶中可查。

好，今天的分享就在這裏，我會堅持每週更新兩篇～

-End-

近期專題

產品落地的細緻活，標準文案

後臺產品，1個case|專欄正式上架

學會「引導」，讓需求快速落地

降價處理的另外一種方式，產品人PK需求方

生活到處，離不開產品經理

產品助理（專員）、產品經理、高級產品經理、產品總監是什麼樣子？

10年前的產品經理是誰？

另外我我的發起的第二期《Kevin帶新人|產品經理30天訓練營》正式上線這本我概括社區產品、後臺產品、產品經理基本功，目前報名限制30人。若是你掃碼報名後參加。我會在28號拉你入羣，開啓訓練營。若是你須要參加，請報名前填寫一份簡單問卷。問卷連接下方

Kevin帶新人|產品經理新人訓練營第二期招募