業(yè)務后臺系統(tǒng)的產(chǎn)品設計最重要的內(nèi)容有三項：功能設計、權限設計和流程設計堰酿。三項內(nèi)容還可以按下表細分：
| 后臺設計內(nèi)容 | 說明 |
|---|---|
| 功能設計 | 包括UI設計役首、交互設計和功能設計 |
| 權限設計 | 包括組織架構設計绑咱、人員管理設計 |
| 流程設計 | 即工作流或審批流設計 |
本篇總結的是業(yè)務后臺系統(tǒng)的權限設計方面的領悟爵嗅，權限設計同樣可以從關鍵的幾點來總結：權限設計模型、權限的構成疲恢、角色與權限的關系凶朗、權限設計注意點
權限設計模型
RBAC（基于角色的權限訪問控制）是權限設計的經(jīng)典模型，應該是后臺系統(tǒng)應用最多最為成熟的權限管理模型显拳。RBAC其實是一組模型的統(tǒng)稱棚愤，其下根據(jù)權限管理的復雜程度由簡單至復雜又分為RBAC0-RBAC3四個模型。
RBAC0 基礎RBAC模型
RBAC0是RBAC模型的核心基礎思想杂数，即用戶通過被賦予角色和權限進行關聯(lián)宛畦。用戶矛绘、角色和權限之間的兩兩關系均是多對多關系，即一個用戶可以被賦予多個角色刃永，一個角色可以被賦予多個用戶。一個角色可以擁有多項權限羊精，一項權限可以賦予多個角色斯够。
RBAC1 引入繼承關系的RBAC模型
RBAC1是在RBAC0的基礎上引入了角色的繼承關系，從上圖舉例喧锦，角色2繼承自角色1读规，角色1擁有權限1-3，則無須再單獨賦予角色2燃少。角色2自動擁有權限1-3束亏，并且還可以單獨賦予權限4-6。
這種一般應用在組織架構的權限中阵具，例如一個部門中的多個業(yè)務小組碍遍，每個業(yè)務小組只能看到自己小組的數(shù)據(jù)，但部門經(jīng)理可以看到全部小組的數(shù)據(jù)阳液。
RBAC2 增加了限制關系的RBAC模型
RBAC2即在用戶和角色之間怕敬，或角色和權限之間增加的限制。
①互斥角色限制：例如A已經(jīng)被分配發(fā)起流程的角色A帘皿，就不能再分配審批流程的角色B东跪，這樣就會導致業(yè)務流程存在漏洞。但這也會根據(jù)所在公司的實際情況而定鹰溜，并不是必不可少的限制條件虽填。
②角色基數(shù)限制：例如單個用戶最多只能被賦予3個角色，同樣也需要根據(jù)所在公司的實際情況而定曹动。
③先決條件限制：例如角色A為角色B的上級斋日，要想為用戶分配角色A，則必須先分配角色B仁期。同樣也需要根據(jù)所在公司的實際情況而定桑驱。
④擁有多個角色情況下，運行時只能激活一個角色
以上限制并不是使用RABC過程中必不可少的跛蛋，往往在實際業(yè)務場景中熬的，系統(tǒng)是需要非常靈活的，過多的限制反而會阻礙業(yè)務的開展赊级。產(chǎn)品經(jīng)理在設計時押框，需要懂得根據(jù)實際業(yè)務場景，對RBAC模型進行改造利用理逊。如果完全套用橡伞，則只能說是“盡信書盒揉，不如無書”。
RBAC3 兼有RBAC1和RBAC2特性的RBAC3
RBAC3模型就是RBAC1和RBAC2的結合體兑徘，擁有兩者的特性刚盈。
其他 引入用戶組和權限組的RBAC
除了教科書式對RBAC的經(jīng)典定義外，還有不少其他特性未包含在定義內(nèi)的挂脑。例如用戶組和權限組的概念藕漱。
用戶組：當用戶數(shù)少時，管理員可以給用戶單獨賦予權限崭闲。但一旦用戶多之后肋联，再單個賦予權限就不現(xiàn)實了。這時就需要將同類用戶組成一個組刁俭，例如部門橄仍、項目組等等，按照組來賦予權限牍戚。個人理解組的權限是依賴于組而存在的侮繁，但某用戶離開了當前用戶組之后，就自動失去了該組的權限如孝。同時用戶在組中時鼎天，同樣不影響對該用戶單獨賦予權限。
權限組：權限組則是將多個權限直接打包暑竟，在賦予權限時斋射，直接按權限組賦予。
目前比較常用的應該是用戶組的這種特性但荤。
權限的構成
權限的構成很簡單罗岖，可以分為功能權限和數(shù)據(jù)權限兩大類。
| 權限類型 | 權限單元 | 二級權限單元 | 說明 |
|---|---|---|---|
| 功能權限 | 入口/菜單 | 查看 | 后臺最常見到的權限控制方式腹躁，簡單直接桑包。 |
| 頁面權限 | 字段 | 頁面特定字段/文本的可見權限 | |
| 按鈕 | 頁面特定按鈕的可見權限 | ||
| 附件 | 頁面特定附件的可見權限 | ||
| 操作權限 | 按鈕 | 頁面特定按鈕的可操作權限 | |
| 附件 | 頁面特定附件的操作差異化權限，例如A角色點擊圖片附件為預覽附件纺非，而B角色點擊附件為下載附件哑了。 | ||
| 數(shù)據(jù)權限 | 報表權限 | 查看 | 某個報表的查看權限 |
| 導出 | 某個報表的查看權限 | ||
| 字段權限 | 查看 | 某個報表字段的查看權限 |
不同的系統(tǒng)可能權限單元顆粒度不一樣，邏輯簡單角色少的系統(tǒng)或許只需入口級權限就能滿足各角色的隔離需求烧颖。但在條件允許的情況弱左，還是需要將系統(tǒng)的權限單元顆粒度劃分得足夠細，這樣在系統(tǒng)由簡單到復雜的過程中炕淮，系統(tǒng)的權限設計框架就無須重構也能支持系統(tǒng)的拓展拆火。
權限的設計思路
在了解了權限的設計模型和權限的構成之后，就不難總結出一套產(chǎn)品在日常工作中使用的設計思路。
1 梳理系統(tǒng)組織架構及權限描述
系統(tǒng)的組織架構需要真實反映業(yè)務的組織架構们镜，梳理標準化的部門币叹、崗位。根據(jù)標準化的部門和崗位梳理出部門和崗位的基礎權限以及特定權限模狭。
在和業(yè)務方進行需求調研時颈抚，往往能得到的只是某個崗位的碎片化權限描述。所以可以結合部門職責和崗位職責嚼鹉，再加上業(yè)務方的口述資料來梳理出部門和崗位的組織關系以及初略的權限邪意。
2 拆解系統(tǒng)權限單元
根據(jù)第一步的調研之后，就可以根據(jù)業(yè)務需求來對系統(tǒng)的功能和數(shù)據(jù)拆解成一個個權限單元反砌，然后再以權限的維度來分配給崗位（角色）。
如果存在多個部門的情況萌朱，還需要按照部門劃分來進行分配宴树。
如果需要用到用戶組的機制，對部門賦予權限晶疼，則需要以部門為單位來分配權限酒贬。
權限設計注意點
- 需要考慮人員是否存在兼部門和兼崗情況
- 工作流的審批權限可以和功能權限分開配置，更加靈活
