發(fā)現(xiàn)每次設計權限體系都很痛苦，歸根結底就是沒有沉淀出一套方法論?？戳讼戮W上的文章大多是講RBAC權限管理模型RBAC0介紹到RBAC3，看的吐血了，還是自己總結點實際點的東西。

設計B端產品，無可避免會涉及權限管理的問題。

為什么呢？

因為B端產品生來就是帶著組織結構屬性的，它輔助我們分工、協(xié)調和合作。所以我們的產品必須緊緊切合職、責、權這三個主題。

簡介

權限管理，一般指根據(jù)系統(tǒng)設置的安全規(guī)則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源，不多不少。

原因

為什么要做權限管理呢？

• 權利不同可以了解的數(shù)據(jù)內容不同，保證數(shù)據(jù)隱私，避免數(shù)據(jù)泄密；
• 職責不同所需要頁面不同，保證操作效率，避免頁面干擾；
• 技術水平不同可以操作的功能不同，保證系統(tǒng)安全，避免操作風險。

還有其他要素，都注定了要獨立出一個權限管理模塊來規(guī)范操作和數(shù)據(jù)權限。

原則

權責明晰：

• 權：專人做專事，既可以防止誤操作，又避免干擾。比如自身才可以編輯和刪除。
• 責：能將錯誤行為定位到人，落實責任。比如操作作業(yè)和表都帶上責任人的信息。

界限分明：

• 功能：將功能按不同層級或者屬性進行劃分；
• 數(shù)據(jù)：將數(shù)據(jù)按業(yè)務類型或者組織架構特性進行劃分。

流程規(guī)范：

• 依賴：允許用戶依賴別人作業(yè)和查看作業(yè)信息，保證組織的流暢性；
• 繼承：根據(jù)實際情況要考慮流程的容錯性，比如是否可以跨節(jié)點確認。

原理

所以每個用戶都需要權限限定，但是直接給用戶賦上權限，會有很多問題：

• 工作量大，需要給每個用戶依次賦上權限；
• 靈活度低，如果某個操作權限關掉了，需要一個個找出用戶依次修改權限。

所以基于傳統(tǒng)的權限模型進行改建，RBAC模型是一個成熟的權限模型，雖然被講爛了，但是還是假裝不知道重新介紹下。

RBAC（Role-Based Access Control）基于角色的訪問控制，不同于傳統(tǒng)的權限模型直接賦予使用者權限，而是將權限賦予角色。

• 用戶與角色相關聯(lián)，是多對多關系；
• 角色與權限相關聯(lián)，是多對多關系。

項目管理

項目是用來隔離數(shù)據(jù)和用戶的，用戶加入當前項目才可以享受該項目下的資源。你可以把項目當做部門就明白了，A部門的用戶不可以查看B部門的數(shù)據(jù)。

注意：刪除項目，需要提示是否刪除項目下的數(shù)據(jù)，如果刪除有很多風險，那就禁用刪除吧。還有一種折中的方法，就是刪除時允許將項目下的資源遷移到其他項目。

用戶管理

管理用戶信息，以及對用戶進行增刪改查，包括用戶名稱、所屬部門、聯(lián)系電話等信息，至于密碼，一般只能重置密碼，而不是顯示密碼允許修改。

注意：

• 源：一般我們可以和OA關聯(lián)拿取賬號，而不需要在產品里添加，保證內部系統(tǒng)信息一致性。
• 目標：在產品中一些頁面需要讀取用戶管理的用戶信息。
• 交接：如果用戶的信息被產品某些功能所引用，必須考慮用戶離職后，其創(chuàng)建的資源管理的問題，這時候被賦予所有權限的管理員是個很好的接盤俠。

用戶組管理

用戶組其實就是批量給用戶賦予角色，將多個用戶綁定為一個小組，再給這個小組賦予一個角色。

注意：如果內部組織架構不復雜的話，最好不要加入用戶組，不然增加了權限體系的復雜性，畢竟殺雞焉用牛刀。

角色管理

管理角色信息，對角色進行增刪改查，包括角色名稱、角色描述和角色狀態(tài)等。

可以將角色理解為將權限打包成一個小組，那個小組就是一個角色。

注意：角色停用后，用戶被賦予這個權限就不生效。

權限

• 頁面權限：頁面權限指用戶可以看到的頁面。如果你的產品比較復雜，可能你需要從模塊權限到菜單權限最后到頁面權限。
• 操作權限：操作權限指用戶可以操作的內容，即按鈕權限，是否有增刪改查的權限。

思考

• 銜接自然：比如根據(jù)項目區(qū)分數(shù)據(jù)權限，根據(jù)崗位區(qū)分角色，將現(xiàn)實的角色與產品角色相關聯(lián)，顯得更自然。
• 輕裝上陣：很多人一講到權限管理，就希望把它設計的非常全面嚴謹，但是邏輯上的全面嚴謹和功能上的全面嚴謹完全是兩回事。如果前期不需要，完全沒必要多抽象出幾個概念，需要考慮的反而越多。所以在能滿足權限的需求下，就不要多設概念，比如抽象出用戶組這種，很可能基本用不到，而且還增加了系統(tǒng)復雜度。
• 隨機應變難道一定要遵從RBAC模型嗎？等你真正參與項目，就會發(fā)現(xiàn)，RBAC模型僅僅只是個開始，它只是幫你打好基礎，之后還會有各種各樣個性化的需求，絕對不僅僅現(xiàn)在說的這么簡單······

參考

大數(shù)據(jù)開發(fā)平臺權限管理

后臺經驗分享：如何做權限管理系統(tǒng)設計

后臺系統(tǒng)：賬號權限系統(tǒng)設計

以RBAC模型為基礎，分析B端權限系統(tǒng)的設計思路（業(yè)務技能）

一個案例，三個角色，簡單說下B端產品的權限設計

本文由 @?安琪Angela 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖作者提供