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

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

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

功能權(quán)限

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

RBAC模型

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

為什么要引入這個模型呢？請看以下的例子：

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

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

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

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

1. 解耦用戶和功能，降低操作錯誤率；
2. 降低功能權(quán)限分配的繁瑣程度。

有些更復(fù)雜的系統(tǒng)可能會涉及RBAC家族的其他成員：RBAC1、RBAC3、RBAC97等，并逐漸看到【用戶組】、【角色繼承】、【受限角色】等概念，但模型的引入只是多了依據(jù)和調(diào)理，復(fù)雜度并不會因為模型的增多而快速降低，模型引入帶來的邊際效用只會越來越低。

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

功能的粒度

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

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

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

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

功能的優(yōu)先級

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

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

跨模塊訪問的問題

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

這個問題有兩種解法：

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

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

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

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

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

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

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

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

數(shù)據(jù)權(quán)限和什么有關(guān)？

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

因為扁平狀組織架構(gòu)較為簡單，需要注意的問題已經(jīng)隱含在樹狀架構(gòu)中，所以以下主要講樹狀架構(gòu)。

層級數(shù)量

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

結(jié)點間的數(shù)據(jù)共享方式

目前結(jié)點間的數(shù)據(jù)共享方式有幾類：

• 父結(jié)點可以管理所有子結(jié)點的數(shù)據(jù)：用戶G可以【管理】部門A、部門B的所有用戶和所有資產(chǎn)。
• 子結(jié)點可以管理父結(jié)點的數(shù)據(jù)：用戶A1可以【管理】部門G的所有用戶和所有資產(chǎn)。
• 兄弟結(jié)點之間可以互相管理：用戶A1可以【管理】部門B的所有用戶和所有資產(chǎn)。
• 結(jié)點只能管理自己所在結(jié)點的數(shù)據(jù)：用戶A1只能【管理】部門A的所有用戶和所有資產(chǎn)。
• 結(jié)點里的用戶只能看到自己的數(shù)據(jù)：用戶A1只能【管理】用戶A1自己創(chuàng)建的用戶和資產(chǎn)。

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

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

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

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

結(jié)點里的用戶存在上下級關(guān)系怎么辦？

圖2-4? 和圖2-3一樣

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

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

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

扁平架構(gòu)

扁平化的組織架構(gòu)比較簡單，只存在樹狀架構(gòu)中的第3個問題。請參考樹狀架構(gòu)的第3個問題。

功能權(quán)限和數(shù)據(jù)權(quán)限的碰撞：跨模塊的數(shù)據(jù)【使用】問題

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

圖2-5

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

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

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

1. 不管哪個層級或者誰創(chuàng)建的型號都在接口中展示（即型號數(shù)據(jù)在別的模塊使用時全局可見）；
2. 只展示當(dāng)前登錄用戶所屬結(jié)點創(chuàng)建的型號；
3. 只展示當(dāng)前登錄用戶所屬結(jié)點及下屬節(jié)點創(chuàng)建的型號（扁平化組織架構(gòu)不適用）；
4. 只展示當(dāng)前登錄用戶所屬結(jié)點的父結(jié)點創(chuàng)建的型號（扁平化組織架構(gòu)不適用）；
5. 只展示當(dāng)前登錄用戶所屬結(jié)點的兄弟結(jié)點創(chuàng)建的型號（扁平化組織架構(gòu)不適用）；
6. 只展示當(dāng)前登錄用戶創(chuàng)建的型號。

總結(jié)

1. 建設(shè)toB的系統(tǒng)時要考慮兩種權(quán)限：功能權(quán)限和數(shù)據(jù)權(quán)限。
2. 功能權(quán)限可以參考RBAC模型，通過引入角色、用戶組等概念降低復(fù)雜度。但系統(tǒng)用戶數(shù)量龐大，功能極度復(fù)雜且粒度足夠細(xì)時，復(fù)雜度已不可避免，只需考慮是把復(fù)雜交給用戶、運維還是代碼。
3. 數(shù)據(jù)權(quán)限主要和組織架構(gòu)有關(guān)，組織架構(gòu)中樹狀架構(gòu)較為復(fù)雜，需要統(tǒng)一或者分模塊的定義層級間數(shù)據(jù)共享問題。數(shù)據(jù)權(quán)限定義過程中如果出現(xiàn)同一結(jié)點下的【用戶間層級問題（上下級）】需要回到功能權(quán)限的【角色定義】去解決。
4. 有一類跨模塊【使用數(shù)據(jù)】的問題也可以看成既定的接口權(quán)限和可選的數(shù)據(jù)權(quán)限問題。

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

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

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