本文為我們介紹了功能權(quán)限和數(shù)據(jù)權(quán)限的不同點(diǎn)、以及不同部分中的要點(diǎn)與注意事項(xiàng)。

做2B的系統(tǒng)總是不可回避的遇上權(quán)限問(wèn)題，他不是核心業(yè)務(wù)卻又必不可少，而且總是牽一發(fā)而動(dòng)全身，更要命的是不同客戶組織架構(gòu)完全不同，功能復(fù)用性很低。有沒(méi)有什么方法論能快速理清權(quán)限問(wèn)題呢？

我們一般說(shuō)【權(quán)限】的時(shí)候是在說(shuō)功能權(quán)限和數(shù)據(jù)權(quán)限。功能權(quán)限指用戶登錄系統(tǒng)后能看到什么模塊，能看到哪些頁(yè)面，而數(shù)據(jù)權(quán)限指的是用戶在某個(gè)模塊里能看到幾條數(shù)據(jù)，能看到哪些數(shù)據(jù)。以下分別描述一下我對(duì)功能權(quán)限和數(shù)據(jù)權(quán)限的理解。

功能權(quán)限

在企業(yè)系統(tǒng)中，通過(guò)配置用戶的功能權(quán)限可以解決不同的人分管不同業(yè)務(wù)的需求，但是如何實(shí)現(xiàn)快速配置？功能的粒度是模塊級(jí)的還是頁(yè)面級(jí)的還是更細(xì)粒度的？跨模塊操作時(shí)沒(méi)權(quán)限怎么辦？

圖1-1

說(shuō)到功能權(quán)限不得不說(shuō)RBAC（Role Based Access Control)模型，它的中文是基于角色的訪問(wèn)控制，主要是將功能組合成角色，再將角色分配給用戶，也就是說(shuō)角色是功能的合集。RBAC有多個(gè)成員，但是基礎(chǔ)的RBAC0就足夠我們涉及的系統(tǒng)使用了。（如果想了解更多，請(qǐng)點(diǎn)擊RBAC權(quán)限管理總結(jié)）

為什么要引入這個(gè)模型呢？請(qǐng)看以下的例子：

企業(yè)A一共有12個(gè)功能，需要?jiǎng)?chuàng)建100個(gè)用戶，這些用戶中有管財(cái)務(wù)的、有管人事的、有管銷(xiāo)售的等等。如果不引入RBAC模型，我們需要每創(chuàng)建一個(gè)用戶就要分配一次功能，至少（每個(gè)用戶只有一個(gè)功能）操作100次，如果人數(shù)增加到1000甚至10000，并且一個(gè)用戶可能會(huì)有多個(gè)功能的時(shí)候，操作會(huì)非常繁瑣，如圖：

圖1-2

經(jīng)過(guò)多次操作發(fā)現(xiàn)：分配給某些人的功能都是相同的，比如分配給A、B等10個(gè)用戶的功能都是客戶管理、訂單管理及供應(yīng)商管理這幾個(gè)模塊，那是不是可以把這幾個(gè)功能模塊打成一個(gè)包整體分給需要的用戶呢？

這個(gè)包就叫做角色。由于角色和功能的對(duì)應(yīng)關(guān)系相對(duì)固定，給用戶分配權(quán)限的時(shí)候只分配角色即可。

圖1-3

所以引入RBAC模型的意義在于：

1. 解耦用戶和功能，降低操作錯(cuò)誤率；

2. 降低功能權(quán)限分配的繁瑣程度。

圖1-4 圖中一個(gè)用戶對(duì)應(yīng)一個(gè)角色，但實(shí)際場(chǎng)景中也可以是一個(gè)用戶對(duì)應(yīng)多個(gè)角色

有些更復(fù)雜的系統(tǒng)可能會(huì)涉及RBAC家族的其他成員：RBAC1、RBAC3、RBAC97等，并逐漸看到【用戶組】、【角色繼承】、【受限角色】等概念，但模型的引入只是多了依據(jù)和調(diào)理，復(fù)雜度并不會(huì)因?yàn)槟Ｐ偷脑龆喽焖俳档?，模型引入帶?lái)的邊際效用只會(huì)越來(lái)越低。

更多角色問(wèn)題請(qǐng)參考：角色權(quán)限設(shè)計(jì)的100種解法

功能越多，操作越繁瑣，復(fù)雜度越高，所以選擇合適的功能粒度才能快速理清權(quán)限問(wèn)題，也能幫助用戶提升工作效率。

功能的粒度從粗到細(xì)一般分為：模塊級(jí)->頁(yè)面級(jí)->接口級(jí)（接口級(jí)的功能權(quán)限指的是哪個(gè)角色能調(diào)用哪些接口）。

從后臺(tái)角度：為了系統(tǒng)安全，代碼肯定都會(huì)實(shí)現(xiàn)到級(jí)口級(jí)。那我們做粒度選擇的意義是什么？當(dāng)然是為用戶降本增效。只是粒度越粗，用戶操作越簡(jiǎn)單，靈活性卻越低。

非技術(shù)類(lèi)的網(wǎng)站做到模塊級(jí)就夠了，否則用戶體驗(yàn)會(huì)讓人欲哭無(wú)淚。對(duì)比以下兩張圖感受一下：

圖1-5

如果權(quán)限必須細(xì)化到頁(yè)面甚至接口級(jí)別應(yīng)該要遵循一個(gè)優(yōu)先級(jí)規(guī)律，即只要分配低優(yōu)先級(jí)的功能必須先分配高優(yōu)先級(jí)的功能，否則會(huì)出現(xiàn)有刪除權(quán)限卻找不到操作位置的尷尬情況（刪除按鈕在列表頁(yè)面，卻沒(méi)有分配查看列表頁(yè)面的權(quán)限）。具體做法可以通過(guò)交互的方式解決，比如檢測(cè)到勾選低優(yōu)先級(jí)的功能就自動(dòng)幫助勾選高優(yōu)先級(jí)的，或者通過(guò)提示性的文字幫助用戶組合勾選。

需要說(shuō)明的是不同的交互設(shè)計(jì)會(huì)導(dǎo)致優(yōu)先級(jí)不一樣，因?yàn)橛械陌粹o會(huì)放在列表，有的按鈕只放在詳情頁(yè)。我們常用的優(yōu)先級(jí)順序是查看詳情>查看列表>增加、刪除、編輯、其他操作按鈕。

有一個(gè)功能權(quán)限是模塊級(jí)的系統(tǒng)，其中模塊A的頁(yè)面有訪問(wèn)模塊B某個(gè)頁(yè)面的鏈接，那么只有模塊A權(quán)限的用戶可以點(diǎn)擊鏈接進(jìn)入模塊B嗎？

這個(gè)問(wèn)題有兩種解法：

1. 允許只有模塊A權(quán)限的人通過(guò)鏈接訪問(wèn)模塊B

這說(shuō)明系統(tǒng)有一條隱含的規(guī)則：能看到鏈接就表示用戶由模塊A和模塊B的某些頁(yè)面的功能權(quán)限。后臺(tái)需要給所有【有模塊A權(quán)限】的用戶【自動(dòng)分配】訪問(wèn)模塊B某個(gè)頁(yè)面的權(quán)限。

2. 只有既有模塊A權(quán)限也有模塊B權(quán)限的用戶才可以通過(guò)鏈接進(jìn)行訪問(wèn)

這說(shuō)明這個(gè)鏈接就是給同時(shí)擁有兩個(gè)模塊權(quán)限的用戶設(shè)計(jì)的。即只有模塊A權(quán)限的用戶不能通過(guò)鏈接訪問(wèn)模塊B。

這兒就需要根據(jù)真實(shí)業(yè)務(wù)替用戶選擇一種方式，但不管那種方式都可以通過(guò)交互和預(yù)定義的方式讓操作更簡(jiǎn)便，比如如果選擇第1種解法，那么初始化一個(gè)有A模塊權(quán)限和B模塊某個(gè)頁(yè)面的角色，讓用戶隨時(shí)可以選擇。

數(shù)據(jù)權(quán)限

如果所有信息都是公開(kāi)透明的，也就不需要做數(shù)據(jù)權(quán)限的控制?？涩F(xiàn)實(shí)世界如此復(fù)雜，每個(gè)人需要看到的、應(yīng)該看到的數(shù)據(jù)永遠(yuǎn)不同，數(shù)據(jù)權(quán)限便應(yīng)這些需要和規(guī)則而生。

數(shù)據(jù)權(quán)限解決的是用戶能看到多少數(shù)據(jù)量和什么數(shù)據(jù)的問(wèn)題，例如A和B兩個(gè)用戶都能看到銷(xiāo)售模塊，但A能看到320條數(shù)據(jù)，B只能看到100條數(shù)據(jù)，且A能看到的320條數(shù)據(jù)中包含著B(niǎo)能看到的100條數(shù)據(jù)，這些都是由數(shù)據(jù)權(quán)限決定的。

數(shù)據(jù)權(quán)限一般和企業(yè)的組織架構(gòu)相關(guān)，而組織架構(gòu)分為樹(shù)狀和扁平狀的（還有更復(fù)雜組織架構(gòu)，此處暫不做說(shuō)明）

圖2-1 樹(shù)狀組織架構(gòu)，每個(gè)部門(mén)都是一個(gè)結(jié)點(diǎn)

圖2-2 扁平狀組織架構(gòu)

因?yàn)楸馄綘罱M織架構(gòu)較為簡(jiǎn)單，需要注意的問(wèn)題已經(jīng)隱含在樹(shù)狀架構(gòu)中，所以以下主要講樹(shù)狀架構(gòu)。

不同的企業(yè)層級(jí)深度不同，如果系統(tǒng)支持無(wú)限層級(jí)，那好處是通用，壞處是帶來(lái)了數(shù)據(jù)的復(fù)雜性和視覺(jué)實(shí)現(xiàn)的復(fù)雜性，所以也要具體問(wèn)題具體分析。

圖2-3

因?yàn)橛脩艟哂械臋?quán)限是功能權(quán)限和數(shù)據(jù)權(quán)限交叉定義的，所以此處假設(shè)G、A、B部門(mén)的用戶都被賦予了用戶管理和資產(chǎn)管理的功能權(quán)限

目前結(jié)點(diǎn)間的數(shù)據(jù)共享方式有幾類(lèi)：

• 父結(jié)點(diǎn)可以管理所有子結(jié)點(diǎn)的數(shù)據(jù)：用戶G可以【管理】部門(mén)A、部門(mén)B的所有用戶和所有資產(chǎn)。

• 子結(jié)點(diǎn)可以管理父結(jié)點(diǎn)的數(shù)據(jù)：用戶A1可以【管理】部門(mén)G的所有用戶和所有資產(chǎn)。

• 兄弟結(jié)點(diǎn)之間可以互相管理：用戶A1可以【管理】部門(mén)B的所有用戶和所有資產(chǎn)。

• 結(jié)點(diǎn)只能管理自己所在結(jié)點(diǎn)的數(shù)據(jù)：用戶A1只能【管理】部門(mén)A的所有用戶和所有資產(chǎn)。

• 結(jié)點(diǎn)里的用戶只能看到自己的數(shù)據(jù)：用戶A1只能【管理】用戶A1自己創(chuàng)建的用戶和資產(chǎn)。

實(shí)際業(yè)務(wù)系統(tǒng)進(jìn)行數(shù)據(jù)權(quán)限的定義時(shí)：

a. 選擇以上一種或幾種規(guī)則；

b. 根據(jù)業(yè)務(wù)而定定義以上的【管理】：增、刪、改、查及各種小功能的組合。

比如如果選擇父結(jié)點(diǎn)只能【查看而不能編輯、刪除、新增】子結(jié)點(diǎn)的所有數(shù)據(jù)，那么圖中用戶G只能查看部門(mén)A的所有數(shù)據(jù)而不能對(duì)其進(jìn)行編輯、刪除和新增。

圖2-4 和圖2-3一樣

如果實(shí)際業(yè)務(wù)中用戶A1是用戶A2的上級(jí)，并要求用戶A1能看用戶A2的數(shù)據(jù)，而用戶A2不能看用戶A1的數(shù)據(jù)怎么辦？

如果數(shù)據(jù)權(quán)限只規(guī)定到結(jié)點(diǎn)級(jí)（組織級(jí)），那么用戶A1和用戶A2看到的數(shù)據(jù)都是一樣的。所有需要再次引入功能權(quán)限的【角色】解決這個(gè)人員上下級(jí)問(wèn)題。

例如，如圖2-4，系統(tǒng)選擇的結(jié)點(diǎn)間的數(shù)據(jù)共享方式是：結(jié)點(diǎn)只能增刪改查自己所在結(jié)點(diǎn)的數(shù)據(jù)，另外引入角色規(guī)則：管理員可以增刪改查所在結(jié)點(diǎn)所有數(shù)據(jù)，非管理員只能刪改查自己創(chuàng)建的數(shù)據(jù)。那么如果用戶A1的角色是管理員，A2是非管理員，A1就能增刪改查A部門(mén)所有資產(chǎn)，A2只能查看、編輯、刪除自己創(chuàng)建的資產(chǎn)。

扁平化的組織架構(gòu)比較簡(jiǎn)單，只存在樹(shù)狀架構(gòu)中的第3個(gè)問(wèn)題。請(qǐng)參考樹(shù)狀架構(gòu)的第3個(gè)問(wèn)題。

假設(shè)某系統(tǒng)一共有兩個(gè)模塊：型號(hào)管理和設(shè)備管理，操作系統(tǒng)的流程是先創(chuàng)建型號(hào)再創(chuàng)建設(shè)備，如果一個(gè)用戶只有設(shè)備管理而沒(méi)有型號(hào)管理的權(quán)限，在創(chuàng)建設(shè)備時(shí)是否可以選型號(hào)？

圖2-5

這其實(shí)是一個(gè)功能權(quán)限（接口級(jí)）和數(shù)據(jù)權(quán)限融合的問(wèn)題，即用戶創(chuàng)建設(shè)備的時(shí)候是否有請(qǐng)求型號(hào)列表接口的權(quán)限？列表中要展示哪些數(shù)據(jù)？

從功能權(quán)限講：用戶肯定有請(qǐng)求接口列表的權(quán)限，否則流程就無(wú)法走通了。

從數(shù)據(jù)權(quán)限講：有幾種規(guī)則作為參考，具體根據(jù)實(shí)際業(yè)務(wù)進(jìn)行選擇：

1. 不管哪個(gè)層級(jí)或者誰(shuí)創(chuàng)建的型號(hào)都在接口中展示（即型號(hào)數(shù)據(jù)在別的模塊使用時(shí)全局可見(jiàn)）；

2. 只展示當(dāng)前登錄用戶所屬結(jié)點(diǎn)創(chuàng)建的型號(hào)；

3. 只展示當(dāng)前登錄用戶所屬結(jié)點(diǎn)及下屬節(jié)點(diǎn)創(chuàng)建的型號(hào)（扁平化組織架構(gòu)不適用）；

4. 只展示當(dāng)前登錄用戶所屬結(jié)點(diǎn)的父結(jié)點(diǎn)創(chuàng)建的型號(hào)（扁平化組織架構(gòu)不適用）；

5. 只展示當(dāng)前登錄用戶所屬結(jié)點(diǎn)的兄弟結(jié)點(diǎn)創(chuàng)建的型號(hào)（扁平化組織架構(gòu)不適用）；

6. 只展示當(dāng)前登錄用戶創(chuàng)建的型號(hào)。

總結(jié)

1. 建設(shè)toB的系統(tǒng)時(shí)要考慮兩種權(quán)限：功能權(quán)限和數(shù)據(jù)權(quán)限。

2. 功能權(quán)限可以參考RBAC模型，通過(guò)引入角色、用戶組等概念降低復(fù)雜度。但系統(tǒng)用戶數(shù)量龐大，功能極度復(fù)雜且粒度足夠細(xì)時(shí)，復(fù)雜度已不可避免，只需考慮是把復(fù)雜交給用戶、運(yùn)維還是代碼。

3. 數(shù)據(jù)權(quán)限主要和組織架構(gòu)有關(guān)，組織腳骨中樹(shù)狀架構(gòu)較為復(fù)雜，需要統(tǒng)一或者分模塊的定義層級(jí)間數(shù)據(jù)共享問(wèn)題。數(shù)據(jù)權(quán)限定義過(guò)程中如果出現(xiàn)同一結(jié)點(diǎn)下的【用戶間層級(jí)問(wèn)題（上下級(jí)）】需要回到功能權(quán)限的【角色定義】去解決。

4. 有一類(lèi)跨模塊【使用數(shù)據(jù)】的問(wèn)題也可以看成既定的接口權(quán)限和可選的數(shù)據(jù)權(quán)限問(wèn)題。

總之揚(yáng)帆在角色權(quán)限的海洋里繞啊繞啊繞，總會(huì)繞出幾個(gè)原則，走出幾個(gè)理論讓我們繞的更快，徜徉的更有成就感。