B端平臺權限體系設計:RBAC模型的技術實現邏輯

9 評論 13141 瀏覽 72 收藏 9 分鐘

編輯導語:這篇文章基于B端平臺的權限體系設計,細致地闡述了作者對于RBAC模型的理解,并向我們展示了RBAC模型的具體應用和邏輯實現過程。感興趣的話就一起看一下吧。

在以往多個0~1大型數字中臺項目中,底層權限體系是我最關心的,也要求產品經理和開發同學、尤其是后端開發必須熟悉后方可進入產品開發項目。

RBAC模型給了B端產品非常容易理解的權限方法,平臺中也有很多RBAC相關的文章介紹。本篇重點介紹實際的技術實現過程,供大家參考,方便B端產品經理與開發同學的溝通,避免走彎路(曾經3個項目在此處折損頗多)。

一、權限體系的基礎介紹

權限體系的要素有:業務組織、角色、用戶和權限、頁面、視圖。

  • 組織、角色、用戶是基于業務變化可即時調整的。
  • 權限是最底層屬性,由開發人員基于業務需求開發實現。權限約束的對象是后臺的具體實例。根據數據接口安全需要,可設計專用的接口權限。權限分功能權限(含菜單權限)、組織權限、數據權限。
  • 頁面、視圖是系統按照業務配置、給對應用戶呈現的內容。

詳細的權限體系說明,可參考 《成熟CRM系統的權限體系解析》 一文。

二、對RBAC模型的深度理解

RBAC(基于角色的權限控制)模型的核心是在用戶和權限之間引入了角色的概念。取消了用戶和權限的直接關聯,改為通過用戶關聯角色、角色關聯權限的方法來間接地賦予用戶權限(如下圖),從而達到用戶和權限解耦的目的。

RBAC模型強調了用戶、角色、權限間的關系,但在B端業務應用中是不能脫離業務部門存在的,因此4者必須建立關系。除了以上4張表外,后臺還需記錄用戶、業務部門、角色的關系表,如下圖:

1. 成熟業務平臺中對業務記錄的基礎要求

成熟ERP、CRM平臺中權限體系非常嚴密,對業務記錄有嚴格的要求:即單條業務記錄中必須有業務記錄的Owner和Owner所屬的業務部門。因此,業務記錄必須有7個基本字段:創建人、創建時間、最后修改人、最后修改時間、Owner、Owner所在的業務部門+狀態(啟用/停用),當Owner發生變化時,Owner所在的業務部門同步更新。

只有如此,才能保障組織權限的嚴格控制,其實現邏輯:按照當前用戶所在的組織和角色的數據范圍來從數據記錄中的Owner所在的業務組織來獲取的。加載可見數據后,再根據當前用戶的編輯等權限進行前端的功能按鈕控制。

舉例:張三是銷售經理,查詢權限是看見部門所有銷售顧問的客戶數據,修改權限是個人的。在獲取客戶列表時,部分客戶的修改按鈕是高亮的(他個人的客戶)、部分客戶的修改按鈕是置灰的(不是他的客戶,是其他銷售顧問的)。上圖中,客戶數據在線索中心中,其他業務中心的業務數據類似處理。

2. 權限體系如何配置和邏輯實現的呢?

權限配置屬于基礎設置部分,一般由超管用戶設定不同角色的權限,示例:

這樣的權限配置實際上需要前后端約定的,采用統一的權限碼來協同控制,使用excel表等其他方式約定菜單/功能權限、數據權限和對應的權限代碼。示例:

留3個需要大家思考的問題:

  1. 組織權限是個人級、全部和本部、本部及以下的處理方式一樣嗎?
  2. 如果一個人擁有多個角色、且不同角色的組織權限的級別不同,怎么處理?
  3. 有功能權限就一定可以處理業務記錄嗎?

三、更復雜應用:房產銷售中的業務組織+項目組織

在房產銷售業務中,會有業務組織,也會有項目組織及項目相關的業務數據,如:一個樓盤就是一個項目,這個項目上產生的線索歸屬于項目,客戶歸屬于整個體系,發展的渠道公司也是歸屬于整個體系。

業務人員會在充當不同業務角色和項目角色,復雜的如一個人同時在多個業務組織中、多個項目組織中,比如張三在BJ城市小區中任項目助理(擁有整個小區中的線索數據查看權限),同時在A項目任銷售一組經理,B項目(非BJ城市小區)中任銷售二組的案場顧問。此用戶在點擊線索列表時(項目外),看到的是BJ城市組織下的線索+A項目銷售一組的線索數據+B項目中歸屬自己的線索。

這樣的結果,就需要業務記錄中既要有業務組織ID、還要有項目組織ID。

四、擴展知識:各類平臺中的組織

  • 行政組織:HR、OA等使用的行政組織,組織架構清晰。
  • 財務組織:財務預決算使用的組織,比如行政組織中有1~5級,但在財務體系內直到3級,那4、5級組織對應的財務組織就是3級。
  • 業務組織:業務運營的組織架構,與行政、財務組織類似,但會不同。舉例:董事長下CEO、CEO下CMO+CFO,但業務系統中會將董事長、CEO、CMO、CFO均放在公司頂級組織里,甚至財務會計、BP均會放在公司這層。
  • 虛擬組織:常用于區域管理組織或職能組織,比如與華南大區平行的華南虛擬組織中,會有財務、HR等職能共享組織,也會有負責市場物料集中采購的采購專員等。同一個財務會監管2個大區,即在2個大區虛擬組織中,數據范圍是按照平行的華南大區業務組織的權限。

 

作者:王建儒,MBA,科技公司CPO,18年業務運營、運營平臺規劃與建設經驗。微信公眾號:王建儒的B星球

本文由 @王建儒 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

 

專欄作家

王建儒,微信公眾號:王建儒的B星球,人人都是產品經理專欄作家。18年業務運營、運營平臺規劃與建設經驗,熟悉S2B2C業務模式的業務+數字雙中臺規劃和落地,聚焦汽車、房產等行業的營/銷/服/客戶運營與數字轉型。甲方IT負責人、乙方業務專家/產品團隊負責人。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 訂閱了

    回復
  2. 厲害!

    來自上海 回復
  3. 受教

    來自北京 回復
  4. 1.組織權限是個人級、全部和本部、本部及以下的處理方式一樣嗎?
    答:【不確定】處理方式是指?
    2.如果一個人擁有多個角色、且不同角色的組織權限的級別不同,怎么處理?
    答:會擁有所有角色的權限之和。
    3.有功能權限就一定可以處理業務記錄嗎?
    答:不一定,還要判斷是否有組織權限、數據權限。

    來自江蘇 回復
    1. 第二個問題,如果兩個角色互斥,是否需要考慮讓用戶只能選擇一個角色?

      來自浙江 回復
    2. 是的,這是必須的。比如出納和會計就不可以為同一人。

      來自北京 回復
    3. 1-處理方式不同:1)個人級權限,直接找owner;2)全部:直接給所有數據;3)本部:給owner所在組織的ID、用此ID返回記錄中有此ID的數據;4)本部及以下:owner所在組織的ID及以下所有組織的組織ID,用這些ID返回記錄中有這些ID的數據。
      2-從數據查看角度,取最高級別的權限;但部分業務數據敏感,就會取最小級別的權限。避免因角色權限配置錯誤,而造成數據泄露。
      3-一般的有組織和數據權限才會涉及到功能權限,即先看到了數據記錄,才可以修改、刪除。而且功能權限用戶中心都會同步給業務中心的。這里想強調的是業務邏輯控制,如訂單狀態對功能權限的影響,舉例:訂單關閉后,只有查看按鈕、歸檔按鈕,其他按鈕全部置灰。

      來自北京 回復
  5. 超贊,收獲很大

    回復
  6. 來自廣東 回復