起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識淺談權限配置能力設計
編輯導語：權限配置能力，可以為各應用提供權限配置原子能力，幫助應用快速集成權限配置，提高系統權限管理體驗。本文作者分析了如何以RBAC模型設計可配置的權限中心，一起來看一下吧。
權限配置能力作為權限控制器，為各應用提供權限配置原子能力。這里聊聊，如果想要以RBAC模型設計可配置的權限中心，該怎么入手。
筆者根據自己的行業經驗總結了一下思路，歡迎大家批評指正。
所謂權限配置能力，就是以權限、角色為中心，把權限配置單獨作為原子能力服務，高度抽象，為開發者、運營人員提供一整套對菜單、接口和數據資源進行授權，同時提供標準授權界面，幫助應用快速集成權限配置，為業務運營集成權限統一管理，形成標準化流程，提高系統權限管理體驗。
權限配置能力，主要實現的是從用戶角色到功能應用的權限控制器，提供管理功能權限、數據權限的基礎能力，提供權限服務（管理+控制）能力給每一個應用使用，免除重復開發、考慮不全的問題。
一、什么是RBAC模型
首先，我們來說說什么是RBAC模型。
RBAC認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權限問題轉換為What、How的問題，可以說，Who、What、How構成了訪問權限三元組。
1. RBAC的組成
在RBAC模型里面，有3個基礎組成部分，分別是：用戶、角色和權限。
RBAC通過定義角色的權限，并對用戶授予某個角色從而來控制用戶的權限，實現了用戶和權限的邏輯分離（區別于ACL模型），極大地方便了權限的管理。
- 用戶-角色映射：用戶和角色之間的映射關系
- 角色-權限映射：角色和權限之間的映射關系
（注：圖來源于網絡，如侵權可告知刪除）
2. RBAC的原則
RBAC支持三個著名的安全原則：最小權限原則、責任分離原則和數據抽象原則。
- 最小權限原則：RBAC可以將角色配置成其完成任務所需的最小權限集合。
- 責任分離原則：可以通過調用相互獨立互斥的角色來共同完成敏感的任務，例如要求一個計賬員和財務管理員共同參與統一過賬操作。
- 數據抽象原則：可以通過權限的抽象來體現，例如財務操作用借款、存款等抽象權限，而不是使用典型的讀、寫、執行權限。
3. RBAC的優缺點
RBAC模型優點是簡化了用戶和權限的關系易擴展、易維護。
但也存在一定的局限性，比如，RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難適應哪些對操作次序有嚴格要求的系統。
二、權限控制框架
聊完了RBAC模型，我們可以先看看權限控制框架設計。
剛剛提到過，所謂權限，就是對資源、數據等進行配置，不同的人分配不同的權限?？梢哉f，權限控制框架其實就是將不同的資源、數據分配給不同的角色，從而完成授權行為。
1. 權限配置
針對不同的角色配置相應的授控資源（包括菜單、接口、數據資源等）完成授權配置。
具體配置流程需要對應用系統的資源進行錄入（包括菜單資源、接口資源、數據資源）后，對業務應用系統的資源進行重新配置為權限策略，最后對角色進行賦權以及角色綁定用戶。
完成配置后，業務系統通過調用對外服務的SDK標準組件或接入API接口，判斷資源與用戶/角色的關聯關系后進行權限控制即可。
實際上，授權不僅僅可以對角色進行授權，實際上還可以通過將角色與組織機構、行政區劃、標簽等緯度進行關聯授權，甚至是直接將用戶與組織機構、行政區劃、標簽等緯度進行關聯授權。但在本文中，暫時先不考慮這種多維度的授權邏輯，只討論常規授權邏輯。
2. 鑒權服務
針對具體的運行環境，判斷授權對象是否對授控資源具有某種操作或數據范圍的權限。
三、資源管理
權限策略的前提時，需要對應用系統的資源（包括菜單資源、接口資源、數據資源）進行錄入。
在系統初始化時，由超級管理員或開發人員完成碼資源管理的錄入和管理，后續可集成到相應的管理平臺中，為產品運營提供靈活可控的權限控制。
1. 菜單資源
菜單資源，指的是對業務系統的前端功能菜單/頁面資源進行錄入管理，以獨立的URL進行區分，可進行分層級管理。
- 新增菜單資源：需要填寫資源名稱、資源編碼、資源路徑、排序號、打開方式等信息
- 新增子菜單：需要填寫資源名稱、資源編碼、資源路徑、菜單等級和上級菜單、排序號、打開方式等信息
- 查詢：比如可根據菜單名稱、ID等進行搜索
- 編輯：編輯菜單資源的基本信息，這里需要注意的是，要確定資源的唯一性及是否可修改等等
- 刪除：刪除菜單資源，可設置一定的校驗規則，比如需要刪除下級菜單，才可以刪除上級菜單
- 批量導入：可按照標準文檔要求，批量導入菜單信息
2. 接口資源
接口資源，指的是對業務系統的后端接口資源進行錄入、管理，可以錄入URL關鍵字段和接口請求方式。
- 新增接口資源：需要填寫選擇資源名稱、資源編碼、資源路徑、請求方式等
- 查詢：比如根據接口名稱、接口地址進行搜索
- 編輯：編輯接口資源
- 刪除：刪除接口資源
- 批量導入：可按照標準文檔要求，批量導入接口信息
3. 數據資源
數據資源，主要指業務系統中存儲的數據資源，通過字段信息進行區分，可以通過唯一編碼錄入權限管理。
- 新增數據資源：需要填寫選擇數據元素名稱、元素編碼、所屬頁面名稱、所屬菜單路徑等
- 查詢：比如根據字段名稱進行搜索
- 編輯：編輯數據字段資源
- 刪除：刪除數據字段資源
- 批量導入：可按照標準文檔要求，批量導入字段信息
四、權限策略
根據業務應用實際情況，建立權限策略管理功能，對已經納入管理的資源，包括資源管理添加的菜單、接口、數據字段資源進行重新配置權限，管理權限與資源的關聯邏輯。
從控制力度來看，權限管理分為兩大類：功能權限管理和數據權限管理。
在系統初始化時，由超級管理員或開發人員完成碼權限策略的配置和管理，后續可集成到管理平臺中，為產品運營提供靈活可控的權限控制。
1. 功能權限
1）定義
通俗的說，功能權限指用戶登錄系統后能看到哪些模塊，操作哪些按鈕。每個角色有配置固定的功能權限，角色之間權限相互隔離。所有角色的對應功能權限由管理后臺進行配置。
2）分類
功能權限包括：業務功能、授權功能。
- 業務功能：根據業務場景，定義不同的業務功能。結合實際業務場景，進行業務功能與角色關聯配置，完成相關角色的權限配置。
- 授權功能：若該角色具有“授權管理”功能，則需要通過管理后臺配置允許該角色進行授權的子角色。
2. 數據權限
1）定義
如果所有信息都是公開透明的，也就不需要做數據權限的控制?？刹煌臉I務形態多而雜，每個人、每個角色需要看到的、應該看到的數據不同，數據權限便應這些需要和規則而生。
數據權限較比于其他兩個權限較為抽象，指的是用戶是否有針對某些數據的瀏覽權限，用戶在某個模塊里能看到哪些范圍的數據。不同角色在同一個頁面看到的信息是不同的，可以通過組織架構來區分。
2）業務決定
對于數據權限的管理比較復雜，這個主要還是有具體的業務來決定的。數據權限一般和組織架構相關。根據組織機構的層級關系，結合業務實際場景，實現不同角色的數據權限的劃分。
比如A業務經理只能看到自己的客戶數據，但是A的業務總監可以查看到各個區域業務員的客戶數據。
3）數據權限向上兼容原則
數據權限向上兼容，若出現多層級授權場景，上級可以對查看下級信息（包括統計信息、授權信息等）。當用戶獲取數據時，根據自己當前的部門和職位，獲取到所有下屬的職員信息。
例：業務管理員可以查看其管轄范圍內次級管理員或業務員的所有信息。
3. 權限策略
對已經在【資源管理】已經錄入的資源，在【權限策略】進行重新配置為權限策略。
- 新增權限策略：需要填寫功能名稱、功能URL路徑、功能描述、行政區劃、組織機構等，對【權限策略列表】進行勾選
- 查看：對已授權功能進行展示，并可以展開查看所有資源明細
- 編輯：編輯功能權限
- 刪除：刪除功能權限
- 關聯角色：關聯角色，對角色進行賦權
五、角色管理
在系統初始化時，由超級管理員或開發人員完成角色管理的配置和管理，后續可集成到管理平臺中，為產品運營提供靈活可控的權限控制。
1. 角色授權
在功能權限策略管理功能已經完成功能權限配置后，需要對角色進行賦權，賦權后展示角色對已授權功能權限和資源明細全景圖，便于配置維護?？蓪⒔巧c用戶進行綁定，完成角色授權。
- 新增角色：需填寫角色的名稱、角色類型、角色層級（行政區劃、組織機構）
- 編輯角色：編輯角色
- 關聯權限：關聯權限策略，對角色進行賦權
- 關聯用戶：將角色與用戶關聯起來，從而實現對用戶授權
2. 角色的組織屬性
1）行政區劃
行政區劃是行政區域劃分的簡稱，是國家為了進行分級管理而實行的區域劃分。一般來說，我國的行政區劃管理體系顆粒度可到省-市-區-街道-社區村居5級管理。
一個管理員只對應一個行政區劃，管理員下的查驗員都跟著管理員的行政區劃。
注意：很多時候，行政區劃不是必要的組織屬性，一般的to B企業基本不會用到該字段信息。但有時候對于政務行業相關的應用系統，行政區劃信息還是必要的。
2）組織架構
組織機構是行政組織機構管理的簡稱，是為了實現在不同組織機構、部門等層級的分級管理設計。根據組織機構的層級關系，結合業務實際場景，實現不同角色的功能權限、數據權限的劃分。
3. 角色層級
1）定義
角色層級可配置3-5個層級，包括普通用戶、管理端的管理人員和業務角色。所有角色根據不同場景、不同業務需求決定，角色之間的授權限制條件也與業務場景相關。
2）分類
角色可以分為管理角色、業務角色。
- 管理角色：具備數據查看權限、具備授權功能，同時也可以擁有業務角色的功能權限
- 業務角色：具備業務功能，根據實際業務場景判斷是否具備授權功能（一般不具備）
3）角色權限說明
所有角色與用戶的關聯可通過管理后臺進行授權操作。
六、用戶賦權
1. 用戶管理
用戶管理當前提供后臺系統賬號的新增和批量導入功能，添加用戶時需要添加用戶的業務屬性，包括角色和角色權限。
2. 用戶授權
通過管理后臺或小程序，將用戶與角色綁定關聯，實現用戶賦權。一旦用戶被分配了適當的角色后，該用戶就擁有此角色的所有操作權限。
用戶與角色是多對多的關系。一個用戶可以擁有若干角色，一個角色也可以賦予若干用戶。
3. 多角色并存機制
多個角色并存的時候，不同角色的擁有不同功能權限的功能模塊。這里需要分兩種情況進行分析。
1）角色權限向上兼容原則
用戶可以通過角色切換來進行功能模塊的切換，但角色權限也存在向上兼容原則，也就是說，高級權限可以覆蓋低層級權限。
比如，一個用戶可能即是公司員工又是管理人員，那么這時候他既有普通員工的角色權限，也有管理層（比如業務經理）的角色權限，這時候他登錄時無需進行角色切換，而是直接以他所擁有的最高層級角色登陸系統，顯示他最高層級角色的功能頁面即可。
2）角色權限無法兼容
但也會存在另一種情況，就是可能在系統內，某個用戶他既是財務人員，又身兼監管部門要職，而這兩種角色的功能業務可能會存在某種沖突，系統不允許同一用戶同時兼容這兩種身份，但實際上企業內部又出現了這種情況。那么我們就得對這兩種角色的權限進行隔離，讓同一用戶能在系統中身兼多任（注：這里提供的案例可能不是非常準確）。
這里提供一個筆者的解決方案，各位如果有更好的解決思路，歡迎補充~
當面臨這種角色權限無法兼容時，可以通過角色切換實現對角色權限的隔離。比如：
若用戶只有1個角色或同時擁有2哥及以上的角色但角色可向上兼容，登錄時默認使用該用戶最高層級的角色登錄，加載最高層級角色的功能頁面；
若用戶有2個及以上的角色，但角色之間可能存在無法兼容的情況，登錄時彈框加載該用戶所有角色的列表，讓用戶自己選擇角色后，加載該角色的功能頁面。
同時提示可以在【我的】->【角色切換】進行角色的切換，并在本地緩存該角色的記錄，下次登錄時通過讀取緩存，自動加載該角色的功能頁面。
七、其他授權
這里需要說明的是，授權不僅僅可以對角色進行功能授權，實際上還可以通過將角色與組織機構、行政區劃、標簽等緯度進行關聯授權，甚至是直接將用戶與組織機構、行政區劃、標簽等緯度進行關聯授權。
但在本文中，暫時先不考慮這種多維度的授權邏輯，只討論常規的功能授權。
這里筆者只根據自己的經驗整理了一下思路，歡迎大家積極吐槽，期待能與大家一起討論找到更好的解決方案，謝謝各位的賞讀~
本文由 @Elaine 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Pexels，基于 CC0 協議。
感謝分享，受益匪淺
嗯嗯學習到了，作者分享以RBAC模型設計可配置的權限中心的方法感覺很專業哈哈。
作者大大詳細的講解了如何以RBAC模型設計可配置的權限中心，受益匪淺。