后台產品設計，用戶角色權限系統（賬戶管理）
上一篇文章《入坑廣告產品經理》中強調了權限設計的重要性，正好遇上朋友請教過相關的問題，今天就寫篇文章展開談談唄~
一、RBAC權限設計模型（就是文章封面圖這個東西）
RBAC（Role-Based Access Control），中文就是基於角色的訪問控制，這是目前最為廣泛接受的權限模型。在RBAC中，權限與角色進行關聯，權限不與用戶之間關聯，用戶通過成為角色中的成員從而獲得該角色所對應的權限。所以，假如一個用戶擁有多個角色，他就擁有多個角色的功能權限。
偷偷從網上扒了一個模型關系圖：
二、產品如何設計
了解完RBAC后，很多都會覺得一個后台的用戶權限系統大致可划分為：用戶管理、角色管理、權限管理這三大模塊，對吧？
但是，現實往往沒那么簡單，用戶管理與公司行政部門或業務線強相關，對應的部門或者業務小組內的用戶又有着極為相似的基本功能需求和權限。所以在這里我會建議加入多一個模塊：部門管理，作為用戶管理的分組。
okay，文章重點來了，一個后台權限系統，應該有四大模塊：部門管理、用戶管理、角色管理、權限管理。為了用戶更好理解角色和權限，實際產品設計中（角色管理和角色賦予權限結合在一起），使用流程如下：（以下內容將依據流程逐步講解）
1.部門管理
顧名思義，就是后台中用戶所在的部門，可以按行政關系（部門架構）、業務部門（業務關系）來划分設計。因為用戶的信息中就會帶上部門的信息，同部門或同業務的用戶就可以授予相同的角色從而獲得權限。
產品設計如下：
部門管理-產品設計
在部門管理中，可以清晰地看到各個部門或業務之間的關系，也便於規划不同部門之間的數據權限。
2.角色管理+角色的權限管理
有了整體的部門架構，那么每一部門對應的角色有哪些呢？同個部門中，是否有多個角色呢？所以就需要角色管理（添加、編輯、刪除角色）來管理每個部門中的角色及角色的數據權限范圍。比如：運營部中，有運營總監（可查看到整個部門所有人的數據）、運營組長（可查看運營A組的本組全部數據）、運營專員（可查看個人數據）。那么一個運營部門至少就有三種角色：運營總監、運營組長、運營專員，三種角色也對應三種不同的權限。
角色是基於業務管理需求而添加的固定標簽，每個角色對應明確的系統權限，其所擁有的系統權限一般不會隨意更改，並且角色也不會隨着用戶的被添加和被移除而進行改變，穩定性強於用戶管理。
通過“關聯權限”來給角色賦權，也就是角色的權限管理。
產品設計如下：
添加角色——產品設計
角色賦權—關聯權限
3.用戶管理
部門設置了，角色和權限也設置了，那么用戶應該要被添加上角色名稱了，從而獲得相對應的權限了。
因而通過“添加用戶”、“編輯用戶”來給予用戶登錄、部門、角色的權限。
這么操作很順利，部門-角色-權限-用戶該有的都有的，可新建可編輯可刪除，看着一切都很自由，但！是！對於權限單獨的管理不見了？往回看，角色賦權-管理權限那個界面，假如“行業”這個功能要取消了？可怎么辦？這個時候我們就需要對權限進行管理，因而會有一個看起來很計算機的權限管理模塊。
4.權限管理
對於功能的權限管理。這兒的權限，你可以理解為這個功能是否存在平台中，這個功能有沒有區分數據范圍的。
產品設計如下：
權限管理這個模塊專業性強，僅適合對超級管理員展示，一般管理人員只需擁有“用戶管理”、“部門管理”、“角色管理”這3個模塊。
若平台中，頁面固定，功能固定，權限管理甚至可以不存在。
好了，羅里吧嗦的講完了。至於有沒看懂我就不理了，啊哈哈哈！
至於角色的權限繼承、角色的互斥、臨時角色、黑白名單等產品設計問題，在這個權限系統中都不存在哦，下次有機會我再來聊聊這一塊的產品設計吧~歡迎有相關設計的產品同學交流。
請勿盜圖，不接受復制粘貼轉載本文的內容。