前言
權(quán)限設(shè)計及管理是B端中常見的話題，它規(guī)定了用戶各自的角色和可使用的權(quán)限范圍，也對數(shù)據(jù)的安全提供了保障。本篇文章中我主要結(jié)合自身以前做權(quán)限的項目經(jīng)驗以及現(xiàn)階段在不斷學(xué)習(xí)、研究和成長過程中，主要從四部分分享關(guān)于權(quán)限設(shè)計的方案和研究心得。
1. 權(quán)限的概念
2. 權(quán)限設(shè)計的核心思想
3. 常用權(quán)限設(shè)計的模型
4. 權(quán)限設(shè)計的步驟
所有內(nèi)容均根據(jù)自身經(jīng)驗、研究思考及實踐借鑒而來，如有錯誤歡迎指正。文中有些案例或者截圖是我在工作中的真實項目經(jīng)歷。
一、權(quán)限的概念
（1）什么是權(quán)限？
? ? ? a. 權(quán)限是指系統(tǒng)執(zhí)行用戶訪問、操作或修改的權(quán)力（比如查看、編輯、刪除等），權(quán)限包括「功能權(quán)限」和「數(shù)據(jù)權(quán)限」。
? ? ? b. 「功能權(quán)限」包括頁面權(quán)限、菜單權(quán)限、按鈕權(quán)限等，「數(shù)據(jù)權(quán)限」包括基礎(chǔ)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、資源數(shù)據(jù)等。
（2）為什么要權(quán)限管理？
我個人認(rèn)為，權(quán)限管理的目的主要在以下三方面：
? ? ? a. 崗位職責(zé)的需要
? ? ? b. 數(shù)據(jù)安全的需要
? ? ? c. 系統(tǒng)安全的需要
二、權(quán)限設(shè)計的核心思想
根據(jù)權(quán)限的定義，可以畫出用戶與權(quán)限的關(guān)系，用戶與權(quán)限之間可以是一對一，也可以是一對多、甚至可以多對多。
從關(guān)系圖1可以看出，用戶與權(quán)限之間形成了比較復(fù)雜的——映射關(guān)系，也就是說，權(quán)限設(shè)計的最簡單的策略就是“用戶+權(quán)限”，直接將權(quán)限綁定到用戶身上，但是這種策略只適用于簡單業(yè)務(wù)的系統(tǒng)中，在復(fù)雜的業(yè)務(wù)系統(tǒng)顯然不適用，在多用戶和多權(quán)限系統(tǒng)中就非常難管理了。
那么，在復(fù)雜的業(yè)務(wù)系統(tǒng)中，如何去管理用戶與權(quán)限錯綜復(fù)雜的映射關(guān)系呢？從關(guān)系圖1中，可以看出，要解決這一問題，有三種方式：
? a. 要么減少用戶數(shù)
? b. 要么減少權(quán)限數(shù)
? c. 要么減少映射關(guān)系
顯然“減少用戶數(shù)”和“減少權(quán)限數(shù)”的方式不現(xiàn)實，那么只能通過“減少映射關(guān)系”的方式。可以聯(lián)想下現(xiàn)實中的案例，比如，字典中的索引、書籍中的目錄或是圖書館中的書架標(biāo)簽，超市的商品分類，都是找到共公屬性再進(jìn)行分類管理。
利用這一思想，我們來看如何減少用戶和權(quán)限的映射關(guān)系。
? a. 判斷用戶與用戶之間是否有公共屬性
? b. 找到對權(quán)限有影響的公共屬性，比如角色、部門、職位等
? c. 不斷抽象出中間媒介
如上關(guān)系圖2，如果想要用戶1～用戶5配置上對應(yīng)的權(quán)限1～權(quán)限5的權(quán)限，則用戶與權(quán)限之間的關(guān)系只建立了5層，但是再看關(guān)系圖1，用戶與權(quán)限之間足足建立了12種關(guān)系。所以，從這里我們可以知道，設(shè)計權(quán)限的核心思想就是：抽象出對象的公共屬性，再進(jìn)行分類管理。
三、常見權(quán)限設(shè)計的模型
常見的權(quán)限設(shè)計模型有：ACL、DAC、MAC、RBAC、ABAC
a. 訪問控制表ACL（Access Control List）
? ? ? ? ? 定義：目標(biāo)資源擁有訪問權(quán)限列表，指明允許哪些用戶訪問（為資源指定用戶），指定哪些用戶可以訪問對象的資源，以及在對象上的操作也被允許，是基于客體進(jìn)行控制的模型。
如上圖，權(quán)限1指定只允許用戶1訪問，權(quán)限2指定允許用戶1、用戶2訪問，權(quán)限3和權(quán)限4分別指明允許用戶3、用戶4訪問。同樣的，如果用戶1想要訪問沒有被授權(quán)的權(quán)限3、權(quán)限4的時候，便訪問不了。
常見的應(yīng)用場景就是：
郵件的抄送功能，OA審批抄送功能，以及白名單設(shè)置等；添加抄送人的過程其實就是針對當(dāng)前的這個權(quán)限（郵件或?qū)徟鷨危┲该髟试S哪些用戶訪問的過程。
例如：當(dāng)用戶A要對一篇文章進(jìn)行編輯時，ACL會先檢查一下文章編輯功能的控制列表中有沒有用戶A，有就可以編輯，無則不能編輯。再例如：不同等級的會員在產(chǎn)品中可使用的功能范圍不同。
缺點：當(dāng)主體的數(shù)量較多時，配置和維護(hù)工作就會成本大、易出錯。
b. 自主訪問控制DAC（Discretionary Access Control）
? ? ? ? 定義：為用戶指明能夠訪問的目標(biāo)資源（為用戶指定資源），規(guī)定資源可以被哪些主體進(jìn)行哪些操作。同時，主體可以將資源、操作的權(quán)限，授予其他主體。相比于ACL，DAC可以將授權(quán)的權(quán)力下放，允許擁有權(quán)限的用戶，可以直接或間接地將訪問權(quán)限賦予其他主體（除非受到強(qiáng)制訪問控制的限制）。
從定義上來看，DAC授權(quán)方式跟ACL授權(quán)方式本質(zhì)是一樣的，但是授權(quán)的邏輯相反。如上圖，用戶1可以正常訪問權(quán)限1和權(quán)限2，但是如果想訪問權(quán)限3或權(quán)限4，由于自身權(quán)限列表中沒有這兩個權(quán)限，所以不允許訪問；用戶2也是相同道理，可以訪問權(quán)限3，但無法訪問權(quán)限1和權(quán)限2、權(quán)限4。
常見的應(yīng)用場景就是：
文件的分享鏈接，網(wǎng)盤資源分享，授權(quán)；分享鏈接，而這個分享鏈接，其實就是一個“用戶對象”，這個“用戶對象”指定了可以訪問我們所選取的文件，這樣當(dāng)我們把鏈接分享出去的時候，打開鏈接的人就可以看到我們所選取的文件，但對于我們沒有選取的網(wǎng)盤內(nèi)的其他文件，是無法看到的。
缺點：對權(quán)限控制比較分散，主體的權(quán)限太大，無意間就可能泄露信息。
c. 強(qiáng)制訪問控制MAC（Mandatory Access Control, 又叫非自主訪問控制）
? ? ? ? 定義：目標(biāo)資源劃分為等級，訪問者擁有包含等級列表的許可，其中定義了可以訪問哪個級別的資源（用戶-等級），MAC規(guī)定資源可以被哪些類別的主體進(jìn)行哪些操作，同時規(guī)定主體可以對哪些等級的資源進(jìn)行哪些操作。DAC與MAC對比，DAC的數(shù)據(jù)存取權(quán)限由用戶控制，系統(tǒng)無法控制；MAC安全等級由系統(tǒng)控制，用戶不能直接進(jìn)行控制。
常見的應(yīng)用場景就是：系統(tǒng)等保、軍事機(jī)密文件等。比如，將軍分為上將>中將>少將，軍事文件保密等級分為絕密>機(jī)密>秘密，規(guī)定不同軍銜僅能訪問不同保密等級的文件，如少將只能訪問秘密文件；當(dāng)某一賬號訪問某一文件時，系統(tǒng)會驗證賬號的軍銜，也驗證文件的保密等級，當(dāng)軍銜和保密等級相對應(yīng)時才可以訪問。
缺點：控制太嚴(yán)格，實現(xiàn)工作量大，缺乏靈活性。
d. 基于角色訪問控制RBAC（Role-based access control）
? ? ? ? 定義：是一種基于角色的權(quán)限管理模型，通過角色指定目標(biāo)資源，用戶綁定角色（用戶-角色-權(quán)限）這種將權(quán)限綁定在角色上，再給用戶賬號賦予角色的方式就叫做基于角色的權(quán)限管理，RBAC支持三個著名的安全原則：最小權(quán)限原則、責(zé)任分離原則、數(shù)據(jù)抽象原則。
RBAC模型于1992年由美國國家標(biāo)準(zhǔn)與技術(shù)研究院組織開發(fā)，是目前最通用的權(quán)限管理模型，GerorgeMason大學(xué)的教授Ravi Sandhu于1996年對RBAC模型進(jìn)行改進(jìn)，提出了RBAC96模型族，包括RBAC0、RBAC1、RBAC2和RBAC3四個模型，RBAC0作為最基礎(chǔ)的權(quán)限模型，其他三個模型是基于RBAC0的基礎(chǔ)進(jìn)行拓展。
RBAC三要素兩關(guān)系：User用戶、Role角色、Permission權(quán)限。用戶-角色之間的映射關(guān)系、角色-權(quán)限之間的映射關(guān)系。
在RBAC模型中用戶與角色，角色與權(quán)限之間均可以是一對一、一對多、多對多。角色起到了橋梁的作用，連接了用戶和權(quán)限的關(guān)系，每個角色可以關(guān)聯(lián)多個權(quán)限，同時一個用戶關(guān)聯(lián)多個角色，那么這個用戶就有了多個角色的多個權(quán)限。
RBAC0模型：基礎(chǔ)的RBAC模型
優(yōu)點：
? ? a. 只抽象了角色一層，角色之間各自獨(dú)立，沒有上下級和等級限制，針對不同的用戶權(quán)限配置靈活性高，且最小顆粒度授權(quán)。
缺點：
? ? a. 只要有權(quán)限不一樣的用戶加入系統(tǒng)或者當(dāng)用戶權(quán)限分得很細(xì)的時候，就需要新建一個角色，系統(tǒng)中存在的角色會越來越多。
RBAC1模型：在角色中引入繼承關(guān)系
在角色中引入上下級關(guān)系的RBAC模型就叫做角色繼承的RBAC模型（RBAC1），通過給角色分級，高級別的角色可繼承低級別角色的權(quán)限。
角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系允許角色間的多向繼承，即下級角色可以擁有多個上級角色，上級角色也可以擁有多個下級角色。受限繼承關(guān)系則進(jìn)一步要求角色繼承關(guān)系是單向繼承，即下級角色只能擁有一個上級角色，但是上級角色可以擁有多個下級角色，單向繼承是一個樹結(jié)構(gòu)。
如上圖所示，一般繼承關(guān)系圖中，角色3擁有角色2、角色1兩個上級，同時角色3擁有角色5、角色6兩個下級。而在受限繼承關(guān)系中，角色3只擁有角色1一個上級，擁有角色6一個下級。無論哪種繼承方式，上級角色可繼承下級角色的權(quán)限，只不過繼承的范圍有所不同。
一般繼承：
? ? ?角色1：擁有整個系統(tǒng)權(quán)限，相當(dāng)于系統(tǒng)的超級管理員。
? ? ?角色3：擁有自身權(quán)限+角色5的權(quán)限+角色6的權(quán)限。
受限繼承：
? ? ?角色1：擁有整個系統(tǒng)權(quán)限，相當(dāng)于系統(tǒng)的超級管理員。
? ? ?角色3：擁有自身權(quán)限+角色6的權(quán)限。
即，權(quán)限范圍：運(yùn)營主管 > 運(yùn)營組長 > 銷售人員/審核人員/運(yùn)營人員。
RBAC2模型：在用戶授予角色之間加入了限制
對用戶授予角色之間進(jìn)行限制的模型就叫做角色限制的RBAC模型（RBAC2），它是基于業(yè)務(wù)不同的崗位職責(zé)分離擴(kuò)展而來，為了避免用戶擁有過多權(quán)限而產(chǎn)生利益沖突，可以把限制具體地分為靜態(tài)職責(zé)分離（SSD）和動態(tài)職責(zé)分離（DSD）。
靜態(tài)職責(zé)分離（SSD）：
? ? ?a. 互斥角色：同一用戶只能分配到一組互斥角色集合中至多一個角色，比如用戶不能同時擁有會計和審計兩個角色。
? ? ?b. 基數(shù)約束：一個用戶可擁有的角色數(shù)量有限；一個角色可被分配的用戶數(shù)量受限；一個角色對應(yīng)的權(quán)限數(shù)量受限。
? ? ?c. 先決條件角色：用戶想要獲得較高的權(quán)限時首先要擁有低一級的權(quán)限，角色A為角色B的上級，要想為用戶分配角色A，則必須先分配角色B，比如游戲中的轉(zhuǎn)職。
動態(tài)職責(zé)分離（DSD）：
? ? ?a. 允許一個用戶具有多個角色，但在登錄運(yùn)行時只能激活其中某個角色，比如BOSS直聘，一個用戶既可以是招聘者也可以是應(yīng)聘者，但同時只能選擇一種身份進(jìn)行操作，不能以兩種角色同時登錄。
RBAC3模型：既引入角色間的繼承關(guān)系，又引入用戶授予角色限制關(guān)系
RBAC3=RBAC1+RBAC2，既引入了角色間的繼承關(guān)系，又引入了角色限制關(guān)系。RBAC3，最復(fù)雜也是最全面的 RBAC 模型，它在 RBAC0 的基礎(chǔ)上，將 RBAC1 和RBAC2中的優(yōu)化部分進(jìn)行了整合，可以認(rèn)為是 RBAC0、RBAC1、RBAC2的結(jié)合。
特別說明：RBAC進(jìn)階設(shè)計
從上面的RBAC0、RBAC1、RBAC2、RBAC3當(dāng)中，可以知道，現(xiàn)有的權(quán)限管理模型雖然已經(jīng)對“權(quán)限”層進(jìn)行了優(yōu)化，抽象出“角色”，但并沒有很好的去抽象“用戶”方。
所以，我們在實際的權(quán)限設(shè)計中，也可以考慮利用抽象的思想將相同屬性的用戶進(jìn)行歸類。在公司里，最簡單的相同屬性就是“部門”了，如果給部門賦予了角色和權(quán)限，那么這個部門中的所有用戶都有了部門權(quán)限，而不需要為每一個用戶再單獨(dú)指定角色，在擁有部門權(quán)限的同時也還可以單獨(dú)為用戶指定獨(dú)特的權(quán)限。
用戶可以分組，權(quán)限同樣也可以分組。在權(quán)限特別多的情況下，可以把同一層級的權(quán)限合并為一個權(quán)限組，如二級菜單下面有十幾個按鈕，如果對按鈕的操作沒有角色之間的限制，可以把這些按鈕權(quán)限與二級菜單權(quán)限合并為一個權(quán)限組，然后再把權(quán)限組賦予角色就可以了。
“組”概念的引入完善了RBAC模型，在簡化操作的同時更貼近了實際業(yè)務(wù)。
e. 基于屬性訪問控制ABAC（Attribute-Based Access Control）
? ? ? ? 定義：ABAC是通過動態(tài)計算一個或一組屬性是否滿足某種條件來進(jìn)行授權(quán)判斷的，包括用戶屬性（如性別年齡）、環(huán)境屬性（如時間地點）、操作屬性（如編輯刪除）和對象屬性（如一篇文章）。
跟RBAC相比，RBAC僅僅描述了用戶可以做什么操作，但是操作的條件，以及操作的數(shù)據(jù)，模型本身是沒有這些限制的，這也是由于其模型能力的不足所導(dǎo)致的，但這卻恰恰是ABAC的長處，ABAC的思想是基于用戶、以及將要訪問的數(shù)據(jù)的屬性、以及各種環(huán)境因素去動態(tài)計算用戶是否有權(quán)限進(jìn)行操作。這個模型在如今的云系統(tǒng)中使用的比較多，比如AWS，阿里云，騰訊云，京東云等。這個模型設(shè)計過于復(fù)雜，目前在市面上并沒有廣泛應(yīng)用。
如下例子：
? ? ? a. “允許所有班主任在上課時間自由進(jìn)出校門”這條規(guī)則，其中，“班主任”是用戶的角色屬性，“上課時間”是環(huán)境屬性，“進(jìn)出”是操作屬性，而“校門”就是對象屬性了。
? ? ?b. 用戶在晚上不能訪問這個系統(tǒng)，但是白天可以。
? ? ?c. 用戶只能在內(nèi)網(wǎng)對訂單具備修改權(quán)限，而在外網(wǎng)就只有查看權(quán)限。
四、權(quán)限設(shè)計的步驟
（1）第一步：羅列所有角色
我們在接業(yè)務(wù)需求的時候，在進(jìn)行初步權(quán)限方案設(shè)計時，先不要急著去定義采用哪種權(quán)限設(shè)計策略，首先第一步就是從業(yè)務(wù)中找到所有可能涉及到的角色。如果做的是一個企業(yè)內(nèi)部系統(tǒng)，比如ERP、OA、管理后臺，可以根據(jù)企業(yè)組織架構(gòu)找到所有角色。以我所在「互聯(lián)網(wǎng)公司」為例子，則有產(chǎn)品負(fù)責(zé)人、產(chǎn)品經(jīng)理、技術(shù)負(fù)責(zé)人、后端開發(fā)、前端開發(fā)…..等角色。如果是面向B端的其他業(yè)務(wù)系統(tǒng)，那么，我們就要通過業(yè)務(wù)流程去找到相關(guān)角色，每個流程里面有哪些角色，以我負(fù)責(zé)過的「數(shù)智平臺」發(fā)起課程備課-學(xué)習(xí)為例子，則有管理員、創(chuàng)建者、授課教師、協(xié)同教師、學(xué)生。
（2）第二步：找到各角色之間的關(guān)系
列出所有的角色之后，接下來就是找出各角色之間的關(guān)系，而角色之間的關(guān)系是由業(yè)務(wù)決定的。常見的有繼承、互斥和共享關(guān)系，及其他關(guān)系：
? a. 等級/繼承：擁有上下級關(guān)系，比如，產(chǎn)品總監(jiān)>產(chǎn)品經(jīng)理>產(chǎn)品助理>產(chǎn)品實習(xí)生
? b. 互斥：擁有互斥關(guān)系，財務(wù)和審計不能是一個人
? c. 共享：擁有共享關(guān)系，授課老師和協(xié)調(diào)老師可以是同一個人
? d. 串行：擁有先后關(guān)系，如，先由產(chǎn)品經(jīng)理進(jìn)行設(shè)計再由開發(fā)人員開發(fā)
? e. 并行：擁有并行關(guān)系，如，前后端同時進(jìn)行開發(fā)
? ? ? 其他……，比如，還需要考慮，是不是要限制角色的個數(shù)，一個用戶能不能擁有多個角色等等。同時，還要分析某些角色是否需要內(nèi)置，哪些角色我們可以事先定好，哪些角色可由用戶自定義。通常常把“管理員”角色進(jìn)行內(nèi)置，也可根據(jù)實際業(yè)務(wù)去定義，如“教職工”角色，只要進(jìn)入到系統(tǒng)的用戶都默認(rèn)為一個最初始的身份“教師工”。
（3）第三步：梳理權(quán)限
根據(jù)前面權(quán)限的定義，我們可以知道權(quán)限分為：功能權(quán)限和數(shù)據(jù)權(quán)限。
1）. 首先，要列出功能清單：
以下以我在實際工作中的項目做例子，該平臺是一個以項目式教學(xué)為核心的系統(tǒng)，「數(shù)智平臺」部分功能清單如下；
2）. 其次，根據(jù)業(yè)務(wù)并結(jié)合功能清單，找出角色與權(quán)限的關(guān)系，即功能權(quán)限：
以下為「數(shù)智平臺」部分角色權(quán)限關(guān)系，因為當(dāng)時做的是第一個版本，所以角色、權(quán)限并不多，但是梳理角色與權(quán)限關(guān)系可按照這種思路去做；
3）. 根據(jù)業(yè)務(wù)，列出數(shù)據(jù)權(quán)限范圍：
有些業(yè)務(wù)數(shù)據(jù)權(quán)限維度些比較簡單，有些比較復(fù)雜，比如有些不分區(qū)域，有些需要分區(qū)域，有些需要分組織架構(gòu)，有些不需要分組織架構(gòu)。其實數(shù)據(jù)權(quán)限的核心就是：角色+范圍。
比如：
? a. 授課教師（角色）能查看所任教科目+所帶班級（范圍）數(shù)據(jù)，即，數(shù)據(jù)范圍“授課教師+科目+班級”。
? b. 年級主任（角色）能查看所任年級（范圍）的數(shù)據(jù)，即，數(shù)據(jù)范圍“年級主任+年級”。
做完第一步、第二步、第三步之后，我們就可以結(jié)合業(yè)務(wù)需求考慮該怎么去設(shè)計權(quán)限策略，通常一個業(yè)務(wù)系統(tǒng)內(nèi)，會存在有多種中權(quán)限策略，也就是常說的權(quán)限管理，比如會有ACL+RBAC兩種策略一起使用，應(yīng)對不同的場景。多個權(quán)限管理策略就形成了權(quán)限體系。
權(quán)限管理是指為解決某一具體的權(quán)限分配問題而采用的方法或者策略，比如解決文件的權(quán)限分配問題可以采用ACL模型，解決不同年齡段的用戶可訪問不同類型的電影問題可以采用RBAC+ABAC。而權(quán)限體系是指整個系統(tǒng)內(nèi)采用的權(quán)限管理方法的集合。
RBAC設(shè)計思路
這里我主要側(cè)重講一下RBAC權(quán)限策略，因為后面「數(shù)智平臺」會向SaaS領(lǐng)域發(fā)展，在SaaS領(lǐng)域最常用的權(quán)限方案就是RBAC。
設(shè)計功能權(quán)限離不開最基本的三要素：用戶管理、角色管理、權(quán)限管理。根據(jù)業(yè)務(wù)的不同，可能還會涉及更復(fù)雜的要素：部門管理、職位管理；在這些之上還會配置不同的版本滿足不同的客戶需求，這就需要版本管理，版本管理是在系統(tǒng)級別就做了隔離，不同版本之間的功能、權(quán)限設(shè)計會有差異，這是為了滿足個性化需求的場景。
“用戶管理”是用于管理用戶信息的，如更改用戶角色、創(chuàng)建或刪除用戶、和用戶信息。對于業(yè)務(wù)系統(tǒng)來說，用戶管理頁面其實就是給業(yè)務(wù)方使用，以學(xué)校為例子，學(xué)校用戶自己可以管理自己的教師、學(xué)生數(shù)據(jù)，并且通過給不同教師分配角色權(quán)限去管理學(xué)校教育、教學(xué)活動的運(yùn)營及管理。一般的后臺系統(tǒng)也會有相應(yīng)的用戶管理模塊。
設(shè)計“用戶管理”一般有三個頁面：
? a. 用戶列表頁：展示系統(tǒng)中所有的用戶。一般有添加、編輯、刪除、導(dǎo)出、導(dǎo)入及批量操作等。
? b. 添加用戶頁：根據(jù)業(yè)務(wù)選擇創(chuàng)建時需要的字段。（添加用戶與綁定角色動作可以分開或者不分開）
? c. 綁定角色頁：可在創(chuàng)建用戶的時候選擇角色，當(dāng)然也可以在創(chuàng)建用戶后再有單獨(dú)的入口去綁定角色（如上圖）。兩種方式?jīng)]有本質(zhì)區(qū)別。
用戶可以對角色進(jìn)行管理，可以給不同角色分配不同的權(quán)限，自行管理，這就是用戶自定義角色管理，且可任意修改。當(dāng)然這里的角色管理，一般會有一個內(nèi)置的角色，比如“管理員”，這是由系統(tǒng)內(nèi)置提供的，用戶只能查看和使用。
設(shè)計“角色管理”一般有三個頁面：
? a. 角色列表頁：展示系統(tǒng)中的所有角色，一般有查看、添加、編輯、設(shè)置權(quán)限、禁用、刪除等操作。
? b. 添加角色頁：必須輸入不可重復(fù)的角色名稱，可選填狀態(tài)、描述等信息。
? c. 配置權(quán)限頁：可在創(chuàng)建角色的同時配置權(quán)限，當(dāng)然也可在創(chuàng)建角色后再有單獨(dú)入口去配置權(quán)限（如上圖），兩種方式?jīng)]有本質(zhì)區(qū)別。
一般來說，這個權(quán)限管理在用戶方不會出現(xiàn)，主要是軟件提供方的內(nèi)部人員使用，比如開發(fā)人員，系統(tǒng)在更新或者迭代某些功能模塊的時候，可以通過該頁面進(jìn)行管理，因為用戶實際上不用去管理系統(tǒng)功能的增、刪、改等操作，他們無權(quán)操作，業(yè)務(wù)方只作為使用者使用而已。當(dāng)前這個權(quán)限管理頁面也不一定要有，通常很多時候，在業(yè)務(wù)開發(fā)的時候，直接通過代碼層面直接寫進(jìn)入了，就不要有一個頁面單獨(dú)去查看和管理了。這個頁面一般只會出現(xiàn)在后臺管理系統(tǒng)里面。
關(guān)于部門、職位管理、版本的權(quán)限設(shè)計，我就不過多闡述，底層邏輯跟角色是一樣，就是抽象出更高一層擁有公共屬性的分類，在進(jìn)行管理即可。
全文完，內(nèi)容如有錯誤歡迎指正！
