閱讀2166
標籤：
產品經理許可權管理系統
對於許可權管理系統的個人理解， 希望對你有所幫助
有沒有發現，
今天我要介紹的就是基於RBAC的許可權管理模型， 來搭建個性化的許可權管理系統。
首先我來介紹一下用戶、角色、許可權
用戶：其實就是相當於帳號，
角色：角色有點類似於職位， 每一個職位都有一定範圍內的工作內容， 就像你是前臺接待員， 那你的工作就是接待， 不可能讓你去做財務的工作， 除非說你是前臺接待員又是財務部門的人員。
許可權：第一層面是控制我們網站、平臺、應用需要控制的頁面的顯示或者說是功能表是否顯示；第二個層面是控制頁面按鈕的顯示， 即操作的許可權控制， 第三個層面是更為精准化資料控制， 比如一些人可以看到頁面清單的所有資料， 而一些人只能看到部分資料。
現在開始步入正題， 先介紹一下傳統的許可權管理系統， 在傳統的許可權管理系統中，
RBAC0是基礎模型， 可以滿足大多數的許可權管理系統， 在這個模型中， 我們把許可權賦值給角色， 再把角色賦值給用戶， 其中使用者與角色的分配方式有兩種，
一般而言我們用的都是用戶與角色是多對多的關係， 一個用戶被賦值為多個角色， 同時一個角色可以賦值給多個用戶。
這個模型是在RBAC0的升級， 在角色中引入了子角色的概念， 就相當於給一個角色分了多個擁有不同許可權的子角色， 從而實現更細細微性的許可權控制。
這種情況我用部門來舉例吧， 比如銷售部門， 部門有負責人：銷售總監， 管理整個部門， 也就是銷售部門所有的許可權都有， 像分配任務，統計部門KPI，有時候遇到非常重要的客戶需要自己來跟進，招聘部門人員等等；銷售部門還有銷售經理：主要是負責銷售總監分配的任務，統計部分銷售的KPI；還有普通的銷售人員，主要就是負責接待客戶。那這樣就是銷售總監擁有整個部門所有的許可權，而銷售經理，普通銷售則擁有銷售總監的部分許可權，但是銷售總監、銷售經理、普通銷售其實都是銷售角色。所以就產生了角色分組模型。
三、RBAC2——角色限制模型該模型也是在RBAC0的基礎上演變而來的，但是新增了對用戶、角色以及許可權的限制控制。
這些限制可以分成兩類，即靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。具體限制如下圖：
角色限制模型更為嚴謹，對邏輯性要求更高，同時對業務也需要有深入的瞭解。
靜態職責分離，我就拿互斥角色的限制來說，比如財務部，負責提交財務報銷的人員不能同時擁有報銷審核的許可權，如果報銷的人同時擁有審核的許可權，那會產生非常大的風險；再比如編輯人員不能同時具有發稿的許可權，一篇文章最終呈現在我們用戶面前其實經過了編輯、美編、責編、統稿等多個步驟，如果編輯擁有發稿的許可權，那編輯寫完稿直接發出去了，一方面沒有美編的排版、樣式等的優化，也沒有責編的複查，最終很有可能就會產生出品質不高的內容。
動態職責分離：如用戶擁有多個角色，當用戶登錄時，是採用啟動其中一個角色？還是說採用所有角色擁有的許可權中和？一般而言是採用啟動其中一個角色，分工更為清晰。但具體採用哪種方案，那需要根據系統複雜性以及產品的思維來確定。
三、RBAC3——統一模型統一模型是RBAC1以及RBAC2的結合
四、實戰案例案例一：我設計的第一個許可權管理系統用的就是RBAC0基礎模型，因為這個系統是對公司內部部門使用的，使用人數在50-100人，相應的功能也不算很複雜，許可權的控制在頁面+操作及按鈕的層面上，因為這是一個針對我們編輯部門以及運營部門使用，而且功能結構不複雜，所以不需要對角色進行分組，因為當時是第一次做許可權系統，考慮不周，沒有加角色互斥的限制，但因為使用人數不多，人工維護所需花的時間也不多。
案例二：不久公司另一個系統由於功能隨著反覆運算越來越複雜，之前的許可權管理都是後臺自己控制，沒有視覺化管理，發現人工運營維護需要耗費大量的時間，由此許可權管理系統提上日程，也由於我之前有搭建許可權管理系統的經驗，這個任務自然安排給了我。首先簡要說一個要設計的大概吧，因為這個許可權系統涉及了兩個後臺平臺簡稱後臺A、後臺B。使用後臺A的主要是部門負責人，使用後臺B的主要是部門員工；所以你也看出來了，這裡就需要對角色進行分組，對於使用後臺A的是部門負責人擁有該部門所有的許可權，而使用後臺B的是部門人員，所擁有的許可權是負責人許可權的子集。而且部門負責人可以創建新的角色用於管理部門許可權，並把相應角色賦值給部門的員工。所以這就是許可權系統中又有一個子許可權系統。這樣許可權管理系統就搭建起來了。
其次就要進行角色的限制了，這個我主要的針對的是在資料層面上的控制，就拿銷售線索來舉例吧，銷售總監可查看並分配銷售線索給銷售，也就是銷售總監可以查看所有的銷售線索；而對於普通銷售就只能查看並根據自己負責的銷售線索，這就是根據角色來控制資料的下發顯示。
五、總結基於兩次的許可權系統的搭建，積累了一下有關許可權管理的知識，還記得第一次做許可權管理系統時，有很多都不知道，對於用戶管理，角色管理入手很快，但對於許可權管理，對於具體要控制到什麼程度，其中的邏輯關係，限制條件的制定，這些涉及邊緣化的東西想得越清楚，會更好的推進產品開發實現。所以在做產品前，需要瞭解產品背後的業務邏輯，熟悉使用場景，瞭解這些對於任何一個產品經理，都是必修的課程。而我自知現在能力尚弱，仍需不斷努力。路漫漫其修遠兮，吾將上下而求索。
文/Sunny_小柒 一個年輕的產品經理，目前就職於全國第一的汽車垂直新媒體--有車以後.
轉載請聯繫，學習交流請加微信（sunnyoneleaf）
像分配任務，統計部門KPI，有時候遇到非常重要的客戶需要自己來跟進，招聘部門人員等等；銷售部門還有銷售經理：主要是負責銷售總監分配的任務，統計部分銷售的KPI；還有普通的銷售人員，主要就是負責接待客戶。那這樣就是銷售總監擁有整個部門所有的許可權，而銷售經理，普通銷售則擁有銷售總監的部分許可權，但是銷售總監、銷售經理、普通銷售其實都是銷售角色。所以就產生了角色分組模型。 三、RBAC2——角色限制模型該模型也是在RBAC0的基礎上演變而來的，但是新增了對用戶、角色以及許可權的限制控制。
這些限制可以分成兩類，即靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。具體限制如下圖：
角色限制模型更為嚴謹，對邏輯性要求更高，同時對業務也需要有深入的瞭解。
靜態職責分離，我就拿互斥角色的限制來說，比如財務部，負責提交財務報銷的人員不能同時擁有報銷審核的許可權，如果報銷的人同時擁有審核的許可權，那會產生非常大的風險；再比如編輯人員不能同時具有發稿的許可權，一篇文章最終呈現在我們用戶面前其實經過了編輯、美編、責編、統稿等多個步驟，如果編輯擁有發稿的許可權，那編輯寫完稿直接發出去了，一方面沒有美編的排版、樣式等的優化，也沒有責編的複查，最終很有可能就會產生出品質不高的內容。
動態職責分離：如用戶擁有多個角色，當用戶登錄時，是採用啟動其中一個角色？還是說採用所有角色擁有的許可權中和？一般而言是採用啟動其中一個角色，分工更為清晰。但具體採用哪種方案，那需要根據系統複雜性以及產品的思維來確定。
三、RBAC3——統一模型統一模型是RBAC1以及RBAC2的結合
四、實戰案例案例一：我設計的第一個許可權管理系統用的就是RBAC0基礎模型，因為這個系統是對公司內部部門使用的，使用人數在50-100人，相應的功能也不算很複雜，許可權的控制在頁面+操作及按鈕的層面上，因為這是一個針對我們編輯部門以及運營部門使用，而且功能結構不複雜，所以不需要對角色進行分組，因為當時是第一次做許可權系統，考慮不周，沒有加角色互斥的限制，但因為使用人數不多，人工維護所需花的時間也不多。
案例二：不久公司另一個系統由於功能隨著反覆運算越來越複雜，之前的許可權管理都是後臺自己控制，沒有視覺化管理，發現人工運營維護需要耗費大量的時間，由此許可權管理系統提上日程，也由於我之前有搭建許可權管理系統的經驗，這個任務自然安排給了我。首先簡要說一個要設計的大概吧，因為這個許可權系統涉及了兩個後臺平臺簡稱後臺A、後臺B。使用後臺A的主要是部門負責人，使用後臺B的主要是部門員工；所以你也看出來了，這裡就需要對角色進行分組，對於使用後臺A的是部門負責人擁有該部門所有的許可權，而使用後臺B的是部門人員，所擁有的許可權是負責人許可權的子集。而且部門負責人可以創建新的角色用於管理部門許可權，並把相應角色賦值給部門的員工。所以這就是許可權系統中又有一個子許可權系統。這樣許可權管理系統就搭建起來了。
其次就要進行角色的限制了，這個我主要的針對的是在資料層面上的控制，就拿銷售線索來舉例吧，銷售總監可查看並分配銷售線索給銷售，也就是銷售總監可以查看所有的銷售線索；而對於普通銷售就只能查看並根據自己負責的銷售線索，這就是根據角色來控制資料的下發顯示。
五、總結基於兩次的許可權系統的搭建，積累了一下有關許可權管理的知識，還記得第一次做許可權管理系統時，有很多都不知道，對於用戶管理，角色管理入手很快，但對於許可權管理，對於具體要控制到什麼程度，其中的邏輯關係，限制條件的制定，這些涉及邊緣化的東西想得越清楚，會更好的推進產品開發實現。所以在做產品前，需要瞭解產品背後的業務邏輯，熟悉使用場景，瞭解這些對於任何一個產品經理，都是必修的課程。而我自知現在能力尚弱，仍需不斷努力。路漫漫其修遠兮，吾將上下而求索。
文/Sunny_小柒 一個年輕的產品經理，目前就職於全國第一的汽車垂直新媒體--有車以後.
轉載請聯繫，學習交流請加微信（sunnyoneleaf）