国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

本文將從什么是RBAC模型、RBAC模型的分類、什么是權限、用戶組的使用、實例分析這幾個方面來整理說明。

目前這份工作做的大部分系統(tǒng)都是ToB性質(zhì)，幾乎每個都涉及到了權限管理。經(jīng)過多個系統(tǒng)的設計，知識的豐富，慢慢的發(fā)現(xiàn)主流的權限管理系統(tǒng)都是RBAC模型（Role-Based Access Control 基于角色的訪問控制）的變形和運用，只是根據(jù)不同的業(yè)務和設計方案，呈現(xiàn)不同的顯示效果。于是在前人的基礎上，加上自己的理解，認真總結(jié)一下RBAC模型的相關知識。

在正式討論RBAC模型之前，我們先思考一個問題，為什么我們要做角色權限系統(tǒng)？

大家先給自己1分鐘時間思考（產(chǎn)品經(jīng)理要學會隨時思考哦）。

…思考10s

…思考30s

…思考50s

好的，1分鐘到了，下面揭曉答案：

一個很明顯的答案就是系統(tǒng)存在不同權限的用戶，而根據(jù)業(yè)務要求的不同，每個用戶能使用的功能、查看的內(nèi)容是不同的。舉個最簡單的例子：釘釘后臺，普通員工和行政能看到的菜單、使用的功能是不同的，行政可以查看所有員工的出勤記錄而普通員工則不行。

接下來，本文將從以下幾個方面進行整理說明：什么是RBAC模型、RBAC模型的分類、什么是權限、用戶組的使用、實例分析。

一、什么是RBAC模型

RBAC（Role-Based Access Control）即：基于角色的權限控制。通過角色關聯(lián)用戶，角色關聯(lián)權限的方式間接賦予用戶權限。

如下圖：

有人會問為什么不直接給用戶分配權限，還多此一舉的增加角色這一環(huán)節(jié)呢？

其實是可以直接給用戶分配權限，只是直接給用戶分配權限，少了一層關系，擴展性弱了許多，適合那些用戶數(shù)量、角色類型少的平臺。

對于通常的系統(tǒng)，比如：存在多個用戶擁有相同的權限，在分配的時候就要分別為這幾個用戶指定相同的權限，修改時也要為這幾個用戶的權限進行一一修改。有了角色后，我們只需要為該角色制定好權限后，將相同權限的用戶都指定為同一個角色即可，便于權限管理。

對于批量的用戶權限調(diào)整，只需調(diào)整用戶關聯(lián)的角色權限，無需對每一個用戶都進行權限調(diào)整，既大幅提升權限調(diào)整的效率，又降低了漏調(diào)權限的概率。

二、RBAC模型的分類

RBAC模型可以分為：RBAC0、RBAC1、RBAC2、RBAC3 四種。其中RBAC0是基礎，也是最簡單的，相當于底層邏輯，RBAC1、RBAC2、RBAC3都是以RBAC0為基礎的升級。

一般情況下，使用RBAC0模型就可以滿足常規(guī)的權限管理系統(tǒng)設計了。

2.1 RBAC0模型

最簡單的用戶、角色、權限模型。這里面又包含了2種：

1. 用戶和角色是多對一關系，即：一個用戶只充當一種角色，一種角色可以有多個用戶擔當。
2. 用戶和角色是多對多關系，即：一個用戶可同時充當多種角色，一種角色可以有多個用戶擔當。

那么，什么時候該使用多對一的權限體系，什么時候又該使用多對多的權限體系呢？

如果系統(tǒng)功能比較單一，使用人員較少，崗位權限相對清晰且確保不會出現(xiàn)兼崗的情況，此時可以考慮用多對一的權限體系。其余情況盡量使用多對多的權限體系，保證系統(tǒng)的可擴展性。如：張三既是行政，也負責財務工作，那張三就同時擁有行政和財務兩個角色的權限。

2.2 RBAC1模型

相對于RBAC0模型，增加了子角色，引入了繼承概念，即子角色可以繼承父角色的所有權限。

使用場景：如某個業(yè)務部門，有經(jīng)理、主管、專員。主管的權限不能大于經(jīng)理，專員的權限不能大于主管，如果采用RBAC0模型做權限系統(tǒng)，極可能出現(xiàn)分配權限失誤，最終出現(xiàn)主管擁有經(jīng)理都沒有的權限的情況。

而RBAC1模型就很好解決了這個問題，創(chuàng)建完經(jīng)理角色并配置好權限后，主管角色的權限繼承經(jīng)理角色的權限，并且支持在經(jīng)理權限上刪減主管權限。

2.3 RBAC2模型

基于RBAC0模型，增加了對角色的一些限制：角色互斥、基數(shù)約束、先決條件角色等。

• 角色互斥：同一用戶不能分配到一組互斥角色集合中的多個角色，互斥角色是指權限互相制約的兩個角色。案例：財務系統(tǒng)中一個用戶不能同時被指派給會計角色和審計員角色。
• 基數(shù)約束：一個角色被分配的用戶數(shù)量受限，它指的是有多少用戶能擁有這個角色。例如：一個角色專門為公司CEO創(chuàng)建的，那這個角色的數(shù)量是有限的。
• 先決條件角色：指要想獲得較高的權限，要首先擁有低一級的權限。例如：先有副總經(jīng)理權限，才能有總經(jīng)理權限。
• 運行時互斥：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。

2.4 RBAC3模型

稱為統(tǒng)一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內(nèi)，綜合了RBAC0、RBAC1和RBAC2的所有特點，這里就不在多描述了。

三、什么是權限

說了這么久用戶-角色-權限，可能小伙伴們都了解了什么是用戶、什么是角色。但是有的小伙伴會好奇，那權限又是個什么玩意呢？

權限是資源的集合，這里的資源指的是軟件中所有的內(nèi)容，包括模塊、菜單、頁面、字段、操作功能（增刪改查）等等。具體的權限配置上，目前形式多種多樣，按照我個人的理解，可以將權限分為：頁面權限、操作權限和數(shù)據(jù)權限（這種分類法，主要是結(jié)合自己在工作中的實際情況理解總結(jié)而來，若有不足之處，也請大家指出）。

頁面權限：所有系統(tǒng)都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱為頁面權限。

如下圖：

客戶列表、客戶黑名單、客戶審批頁面組成了客戶管理這個模塊。對于普通用戶，不能進行審批操作，即無客戶審批頁面權限，在他的賬號登錄后側(cè)邊導航欄只顯示客戶列表、客戶黑名單兩個菜單。

操作權限：用戶凡是在操作系統(tǒng)中的任何動作、交互都是操作權限，如增刪改查等。

數(shù)據(jù)權限：一般業(yè)務管理系統(tǒng)，都有數(shù)據(jù)私密性的要求：哪些人可以看到哪些數(shù)據(jù)，不可以看到哪些數(shù)據(jù)。

簡單舉個例子：某系統(tǒng)中有銷售部門，銷售專員負責推銷商品，銷售主管負責管理銷售專員日常工作，經(jīng)理負責組織管理銷售主管作業(yè)。

如下圖：

按照實際理解，‘銷售專員張三’登錄時，只能看到自己負責的數(shù)據(jù)；銷售主管2登錄時，能看到他所領導的所有業(yè)務員負責的數(shù)據(jù)，但看不到其他團隊業(yè)務員負責的數(shù)據(jù)。

換另外一句話就是：我的客戶只有我和我的直屬上級以及直屬上級的領導能看到，這就是我理解的數(shù)據(jù)權限。

要實現(xiàn)數(shù)據(jù)權限有多種方式：

1. 可以利用RBAC1模型，通過角色分級來實現(xiàn)。
2. 在‘用戶-角色-權限’的基礎上，增加用戶與組織的關聯(lián)關系，用組織決定用戶的數(shù)據(jù)權限。

具體如何做呢？

①組織層級劃分：

②數(shù)據(jù)可視權限規(guī)則制定：上級組織只能看到下級組織員工負責的數(shù)據(jù)，而不能看到其他平級組織及其下級組織的員工數(shù)據(jù)等。

通過以上兩點，系統(tǒng)就可以在用戶登錄時，自動判斷要給用戶展示哪些數(shù)據(jù)了。

四、用戶組的使用

當平臺用戶基數(shù)增大，角色類型增多時，如果直接給用戶配角色，管理員的工作量就會很大。這時候我們可以引入一個概念“用戶組”，就是將相同屬性的用戶歸類到一起。

例如：加入用戶組的概念后，可以將部門看做一個用戶組，再給這個部門直接賦予角色（1萬員工部門可能就幾十個），使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限，而不需要為每一個用戶再單獨指定角色，極大的減少了分配權限的工作量。

同時，也可以為特定的用戶指定角色，這樣用戶除了擁有所屬用戶組的所有權限外，還擁有自身特定的權限。

用戶組的優(yōu)點，除了減少工作量，還有更便于理解、增加多級管理關系等。如：我們在進行組織機構(gòu)配置的時候，除了加入部門，還可以加入科室、崗位等層級，來為用戶組內(nèi)部成員的權限進行等級上的區(qū)分。

關于用戶組的詳細疑難解答，請查看https://wen.woshipm.com/question/detail/88fues.html。在這里也十分感謝為我解答疑惑的朋友們！

五、實例分析

5.1 如何設計RBAC權限系統(tǒng)

首先，我們思考一下一個簡單的權限系統(tǒng)應該具備哪些內(nèi)容？

答案顯而易見，RBAC模型：用戶-角色-權限。所以最基本的我們應該具備用戶、角色、權限這三個內(nèi)容。

接下來，我們思考，究竟如何將三者關聯(lián)起來。回顧前文，角色作為樞紐，關聯(lián)用戶、權限。所以在RBAC模型下，我們應該：創(chuàng)建一個角色，并為這個角色賦予相應權限，最后將角色賦予用戶。

將這個問題抽象為流程，如下圖：

現(xiàn)在，基本的流程邏輯已經(jīng)抽象出來了，接下來，分析該如何設計呢？

• 第一步，需要角色管理列表，在角色管理列表能快速創(chuàng)建一個角色，且創(chuàng)建角色的同時能為角色配置權限，并且支持創(chuàng)建成功的角色列表能隨時進行權限配置的的修改；
• 第二步，需要用戶管理列表，在用戶管理列表能快速添加一個用戶，且添加用戶時有讓用戶關聯(lián)角色的功能。

簡單來說權限系統(tǒng)設計就包含以上兩步，接下來為大家進行實例分析。

5.2 實例分析

①創(chuàng)建角色列表

在角色列表快速創(chuàng)建一個角色：點擊創(chuàng)建角色，支持創(chuàng)建角色時配置權限。

②創(chuàng)建用戶列表

在用戶列表快速創(chuàng)建一個用戶：支持用戶關聯(lián)角色的功能。

上述案例是基于最簡單的RBAC0模型創(chuàng)建，適用于大部分常規(guī)的權限管理系統(tǒng)。

下面再分析一下RBAC1中角色分級具體如何設計。

1. 在RBAC0的基礎上，加上角色等級這個字段。
2. 權限分配規(guī)則制定：低等級角色只能在高等級角色權限基礎上進行刪減權限。

具體界面呈現(xiàn)如下圖：

以上就是簡單的RBAC系統(tǒng)設計，若需更復雜的，還請讀者根據(jù)上面的分析自行揣摩思考，盡管樣式不同，但萬變不離其宗，理解清楚RBAC模型后，結(jié)合自己的業(yè)務就可以設計出一套符合自己平臺需求的角色權限系統(tǒng)，具體的就不再多闡述了。

六、小結(jié)

文章的內(nèi)容主要是自己工作中實際的使用場景，抱著他山之石可以攻玉的想法，參考了現(xiàn)有的方法論，結(jié)合自己系統(tǒng)的實際情況，對RBAC模型做了細致的總結(jié)理解。若有不足之處，還請大家多多溝通，共同進步。

本文由 @?珣玗琪 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議