本文作者主要總結后臺設計的基石：RBAC和workflow。enjoy~

后臺產品同學在設計后臺時，會發現一般后臺的各個功能模塊總結起來有兩大類型：功能類、流程類。在設計功能或流程前都需要預判不同的使用角色對應不同權限，設計流程前則還得思考最基本的工作流原理。

用戶權限是設計后臺普適的基本管理功能，設計系統時幾乎都需要考慮權限問題。后臺系統在面對不同部門不同崗位的人員時，如何區分授權？在考慮前端不同身份的用戶訪問時（如普通用戶、普通會員、超級會員），如何自動判斷權限？工作流則是設計流程需要具備的基本理論，一個完整的流程會會包含哪些節點動作？節點是否可自主配置？

本文主要總結后臺設計的基石：RBAC和workflow。

RBAC

1、什么是RBAC

RBAC（Role-Based Access Control）基于角色的訪問控制。這是從傳統的權限模型基礎上，改進而來并且相當成熟的權限模型。這里強調三個要素：用戶、角色、權限。用戶與角色是多對多關系，角色與權限是多對多關系。

傳統模型中無角色概念，直接為用戶賦上權限，一是導致配置權限相當麻煩，二來無法快速為多個用戶批量刪除權限。用戶—角色—權限多對多的關系，解決了這些問題。

關鍵元素：

• 用戶：成功認證并登錄系統的操作員（主體：who）
• 權限：訪問資源的許可（how）
• 角色：權限的集合體
• 資源：引入這第四個概念，包括系統菜單、頁面、按鈕等（what）

主體（who）如何通過權限（how）訪問資源(what resource)。

權限是用來訪問資源的，為用戶賦予權限，則可訪問資源；在權限基礎上，將權限打包為一個權限集合—角色，如財務經理角色，則為用戶賦上財務經理角色，用戶可訪問財務經理角色下的資源集合。

2、RBAC模型解讀

根據RBAC的復雜度不同，可分為RBAC0，RBAC1，RBAC2，RBAC3.最常用的為RBAC0.

（1）RBAC0模型

將一個或多個權限掛到角色下，在將一個或多個角色賦予用戶，權限與角色的關系，角色與用戶的關系，均是多對多的關系。

場景。為財務經理崗建立財務經理角色，將對賬、付款審批、回款確認等權限配置在財務經理角色下，則公司再更換財務經理人員，只需每次為新來的財務經理配置財務經理角色。

為客戶經理建立客戶經理角色，客戶管理、客戶查詢、搶單等權限配置在客戶經理角色下，適應于公司流動性高且占比龐大（多的甚至上千人）的客戶經理群體，若某個權限不適宜配置給客戶經理，直接在角色中刪除即可，無需分別對每個人進行權限刪除。

（2）RBAC1模型

引入繼承概念，一個角色可以從另一個角色繼承許可權。角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系允許角色間的多繼承，受限繼承關系則進一步要求角色繼承關系是一個樹結構。

場景。適用于角色之間的層次明確，如總經理與副總經理，業務部門如總經理–團隊經理–業務員。也適用于用戶分級管理，初級用戶只能使用部分功能，中級用戶能夠使用更多功能。

（3）RBAC2模型

加入了角色的訪問控制。規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。

包括靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic DSD(Dynamic Separation of Duty)。

• 互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。案例：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
• 基數約束 ：一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；一個角色的權限數目受限。案例：如VP類角色不可隨意分配給多個用戶。
• 先決條件角色 ：指要想獲得較高的權限，要首先擁有低一級的權限。案例：先有副總經理全下，才能有總經理權限。
• 運行時互斥 ：例如，允許一個用戶具有兩個角色，但不可同時激活這兩個角色。

（4）RBAC3模型

RBAC1+RBAC2的集合體。即支持角色間的繼承關系，又支持角色間的責任分離關系。一般無需如此全面負責的模型。

3、關于一般角色、數據角色、成員角色

角色一般可拆分為一般角色、數據角色、成員角色。

• 一般角色：可見功能菜單頁、功能操作按鈕、數據字段，均可通過顆粒度較細的權限，去組合成一般角色。
• 數據角色：指可查詢的數據范圍。同一個一般角色，如查看客戶數據，大區總監能看到整個大區的數據，上海分公司經理只能看到上?？蛻魯祿?。上級組織職能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。
• 成員角色：新建成員即自動賦予的角色，即普通用戶均有的常規權限，無需再手動配置。

4、常見的常規管理功能

（1）用戶管理

用戶按架構新建在對應的組織上。一般掛到機構→部門（一級部門–二級部門）下。

對于公司內部管理系統，管理用戶的前提，是需要合理的組織架構，只有支持組織架構的靈活配置，才能進一步支持組織內人員的增刪調整。

（2）角色管理

所有角色的管理功能。新建角色時，可將角色建立在某級機構或機構及以下，代表此角色只能適用此級別或此級別以下級別。

（3）菜單管理（有的后臺叫欄目管理）

支持自主配置菜單一級二級，支持新增菜單、修改菜單、刪除菜單，更改菜單（修改菜單名、菜單順序等），每個菜單對應一個權限。

（4）組管理

用戶所屬組，用于配置統一組同一部門用戶。有了用戶組，在新建角色時，可直接將角色賦予某個組，則進入此組的人員自動獲得對應角色。

workflow

一個業務流程包含多個環節的審批確認關系，按照業務流程，將各個節點串接起來，即時工作流。系統實現各個節點的自動流轉，解決手工處理工作流程的低效和失誤，提高工作效率的同時，還可通過線上直接流程狀況進行實時跟蹤，實現業務流程流轉的自動化。

1、工作流常見的路由方式

（1）串行路由

按順序一個步驟接著一個步驟走流程：

案例：入職流程，人力專員提交——HRBP審批——人力總監審批，順序走完流程。

（2）并行路由

同時可以執行多個不同的節點：

（3）條件路由

滿足條件后導向一個節點，不滿足條件的導向另外一個節點。

案例：流程提交滿足XX模式，則走A節點，不滿足則走B節點。

（4）分支路由

分支路由平行分支出多條線路，多條線路之間是并行的關系。

案例：付款申請，提交后判斷，對公付款走對公審批，對私付款走對私審批。

（5）合并路由

并行的多路分支集結到一個點的路由方式，前序分支節點全部都經過處理，最終才到匯合節點處理

案例：多個申請項目，同一天提交到終審崗審批。

（6）循環路由

下一步返回到原來的任意一個步驟，這之間形成的回路就是一個循環路由。

案例：發起的流程，條到某崗位后，再流轉到自己確認，再提交。

（7）自由跳轉

這種是很特殊的路由方式，在流程實際運行時跳出原來定義的線路，自由跳轉到任意的步驟。

案例：滿足某個條件，則自動跳過某個崗位，無需此崗位再審批。

2、常見節點動作

• 提交：每個節點的人將流程提交至下手崗位。
• 回退：可退回到某個節點繼續流轉，退回到發起崗，或退回到前手崗。
• 撤回：節點執行完后、下一節點執行前，可以收回進行修改然后再提交。
• 取消/撤銷：流程發起人執行取消流程。
• 中止：流程提前結束，當前節點之后的其它節點不再執行。
• 審批：表單中的某個字段，用于填寫審批意見。
• 會簽：通常用于審批后給相關的人簽字確認，需要簽字確認。
• 知會：指定的人知道有這個流程這么回事，并能查看流程，不需要簽字確認。
• 加簽：審批時，可以征求另一人或多人的意見，然后再回到原審批人。
• 跳簽：跳過接下來的一個或連續的多個節點，直接到指定的節點執行。
• ……

3、上報關系

每個節點提交后，下一節點將有誰審批？一般會為對應崗位的人員配置對應的節點。但若涉及到分公司或分地區審批，則需要設計上報關系。

上報關系支持靈活配置前一崗與后一崗的對應關系。如北京分公司的審批，提交到財務審核時，只能提交到北京財務部。合作公司的審批，只能提交到綜合財務部。此時就需要提前配置上報關系，北京分公司——北京財務部；合作公司—-綜合財務部。各個部門均可配置對應上報關系，包括財務，人力，業務等。

最后，為用戶配置某個財務部的權限，則其僅可接收特定對應的上報關系的審批申請。如權限為綜合財務部用戶，僅可收到合作公司提交的申請單。

BRAC和流程節點，在設計過程中，還需考慮其靈活性。

如操作員入職流程完畢后，自動賦予其崗位對應角色權限，當然這可通過對用戶組分配角色實現。當操作員調崗時，根據調崗的跨度大小，自主確定是否更改權限或刪除權限。流程節點在系統中可根據對應業務，后臺預備支撐性較強的節點變量，支持前臺配置，由管理員自主根據對應業務流程，配置相應的流轉節點。

作者：柴小英，先后混跡于大數據及互金領域，負責過資金端理財平臺及資產端信貸后臺，現任銀客集團資產端產品經理

本文由 @柴小英 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pixabay，基于 CC0 協議