許可權管理：帶著枷鎖跳舞

來自專欄 idatadesign

發現每次設計許可權體系都很痛苦，歸根結底就是沒有沉澱出一套方法論。看了下網上的文章大多是講RBAC許可權管理模型RBAC0介紹到RBAC3，看的吐血了，還是自己總結點實際點的東西。

前言

設計B端產品，無可避免會涉及許可權管理的問題。為什麼呢？因為B端產品生來就是帶著組織結構屬性的，它輔助我們分工、協調和合作。所以我們的產品必須緊緊切合職、責、權這三個主題。

簡介

許可權管理，一般指根據系統設置的安全規則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源，不多不少。

原因

為什麼要做許可權管理呢？

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

還有其他要素都註定了要獨立出一個許可權管理模塊來規範操作和數據許可權。

原則

• 權責明晰

權：專人做專事，既可以防止誤操作，又避免干擾。比如自身才可以編輯和刪除。

責：能將錯誤行為定位到人，落實責任。比如操作作業和表都帶上責任人的信息。

• 界限分明

功能：將功能按不同層級或者屬性進行劃分；

數據：將數據按業務類型或者組織架構特性進行劃分；

• 流程規範

依賴：允許用戶依賴別人作業和查看作業信息，保證組織的流暢性。

繼承：根據實際情況要考慮流程的容錯性，比如是否可以跨節點確認。

原理

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

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

所以基於傳統的許可權模型進行改建，RBAC模型是一個成熟的許可權模型，雖然被講爛了，但是還是假裝不知道重新介紹下。

RBAC（Role-Based Access Control）基於角色的訪問控制。不同於傳統的許可權模型直接賦予使用者許可權，而是將許可權賦予角色。

用戶與角色相關聯，是多對多關係；

項目管理

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

注意

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

用戶管理

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

注意

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

用戶組管理

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

注意

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

角色管理

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

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

注意

• 角色停用後，用戶被賦予這個許可權就不生效。

許可權

頁面許可權

頁面許可權指用戶可以看到的頁面。如果你的產品比較複雜，可能你需要從模塊許可權到菜單許可權最後到頁面許可權。

操作許可權

操作許可權指用戶可以操作的內容，即按鈕許可權，是否有增刪改查的許可權。

思考

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

參考

大數據開發平台許可權管理

後台經驗分享：如何做許可權管理系統設計

後台系統：賬號許可權系統設計

以RBAC模型為基礎，分析B端許可權系統的設計思路（業務技能）

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