起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識最好的權限設計，是先區分功能權限和數據權限
本文為我們介紹了功能權限和數據權限的不同點、以及不同部分中的要點與注意事項。
做2B的系統總是不可回避的遇上權限問題，他不是核心業務卻又必不可少，而且總是牽一發而動全身，更要命的是不同客戶組織架構完全不同，功能復用性很低。有沒有什么方法論能快速理清權限問題呢？
我們一般說【權限】的時候是在說功能權限和數據權限。功能權限指用戶登錄系統后能看到什么模塊，能看到哪些頁面，而數據權限指的是用戶在某個模塊里能看到幾條數據，能看到哪些數據。以下分別描述一下我對功能權限和數據權限的理解。
功能權限
在企業系統中，通過配置用戶的功能權限可以解決不同的人分管不同業務的需求，但是如何實現快速配置？功能的粒度是模塊級的還是頁面級的還是更細粒度的？跨模塊操作時沒權限怎么辦？
RBAC模型
說到功能權限不得不說RBAC（Role Based Access Control)模型，它的中文是基于角色的訪問控制，主要是將功能組合成角色，再將角色分配給用戶，也就是說角色是功能的合集。RBAC有多個成員，但是基礎的RBAC0就足夠我們涉及的系統使用了。（如果想了解更多，請點擊RBAC權限管理總結）
為什么要引入這個模型呢？請看以下的例子：
企業A一共有12個功能，需要創建100個用戶，這些用戶中有管財務的、有管人事的、有管銷售的等等。如果不引入RBAC模型，我們需要每創建一個用戶就要分配一次功能，至少（每個用戶只有一個功能）操作100次，如果人數增加到1000甚至10000，并且一個用戶可能會有多個功能的時候，操作會非常繁瑣，如圖：
經過多次操作發現：分配給某些人的功能都是相同的，比如分配給A、B等10個用戶的功能都是客戶管理、訂單管理及供應商管理這幾個模塊，那是不是可以把這幾個功能模塊打成一個包整體分給需要的用戶呢？
這個包就叫做角色。由于角色和功能的對應關系相對固定，給用戶分配權限的時候只分配角色即可。
所以引入RBAC模型的意義在于：
- 解耦用戶和功能，降低操作錯誤率；
- 降低功能權限分配的繁瑣程度。
有些更復雜的系統可能會涉及RBAC家族的其他成員：RBAC1、RBAC3、RBAC97等，并逐漸看到【用戶組】、【角色繼承】、【受限角色】等概念，但模型的引入只是多了依據和調理，復雜度并不會因為模型的增多而快速降低，模型引入帶來的邊際效用只會越來越低。
更多角色問題請參考：角色權限設計的100種解法
功能的粒度
功能越多，操作越繁瑣，復雜度越高，所以選擇合適的功能粒度才能快速理清權限問題，也能幫助用戶提升工作效率。
功能的粒度從粗到細一般分為：模塊級->頁面級->接口級（接口級的功能權限指的是哪個角色能調用哪些接口）。
從后臺角度：為了系統安全，代碼肯定都會實現到接口級。那我們做粒度選擇的意義是什么？當然是為用戶降本增效。只是粒度越粗，用戶操作越簡單，靈活性卻越低。
非技術類的網站做到模塊級就夠了，否則用戶體驗會讓人欲哭無淚。對比以下兩張圖感受一下：
功能的優先級
如果權限必須細化到頁面甚至接口級別應該要遵循一個優先級規律，即只要分配低優先級的功能必須先分配高優先級的功能，否則會出現有刪除權限卻找不到操作位置的尷尬情況（刪除按鈕在列表頁面，卻沒有分配查看列表頁面的權限）。具體做法可以通過交互的方式解決，比如檢測到勾選低優先級的功能就自動幫助勾選高優先級的，或者通過提示性的文字幫助用戶組合勾選。
需要說明的是不同的交互設計會導致優先級不一樣，因為有的按鈕會放在列表，有的按鈕只放在詳情頁。我們常用的優先級順序是查看詳情>查看列表>增加、刪除、編輯、其他操作按鈕。
跨模塊訪問的問題
有一個功能權限是模塊級的系統，其中模塊A的頁面有訪問模塊B某個頁面的鏈接，那么只有模塊A權限的用戶可以點擊鏈接進入模塊B嗎？
這個問題有兩種解法：
1. 允許只有模塊A權限的人通過鏈接訪問模塊B
這說明系統有一條隱含的規則：能看到鏈接就表示用戶由模塊A和模塊B的某些頁面的功能權限。后臺需要給所有【有模塊A權限】的用戶【自動分配】訪問模塊B某個頁面的權限。
2. 只有既有模塊A權限也有模塊B權限的用戶才可以通過鏈接進行訪問
這說明這個鏈接就是給同時擁有兩個模塊權限的用戶設計的。即只有模塊A權限的用戶不能通過鏈接訪問模塊B。
這兒就需要根據真實業務替用戶選擇一種方式，但不管那種方式都可以通過交互和預定義的方式讓操作更簡便，比如如果選擇第1種解法，那么初始化一個有A模塊權限和B模塊某個頁面的角色，讓用戶隨時可以選擇。
數據權限
如果所有信息都是公開透明的，也就不需要做數據權限的控制?？涩F實世界如此復雜，每個人需要看到的、應該看到的數據永遠不同，數據權限便應這些需要和規則而生。
數據權限解決的是用戶能看到多少數據量和什么數據的問題，例如A和B兩個用戶都能看到銷售模塊，但A能看到320條數據，B只能看到100條數據，且A能看到的320條數據中包含著B能看到的100條數據，這些都是由數據權限決定的。
數據權限和什么有關？
數據權限一般和企業的組織架構相關，而組織架構分為樹狀和扁平狀的（還有更復雜組織架構，此處暫不做說明）
因為扁平狀組織架構較為簡單，需要注意的問題已經隱含在樹狀架構中，所以以下主要講樹狀架構。
層級數量
不同的企業層級深度不同，如果系統支持無限層級，那好處是通用，壞處是帶來了數據的復雜性和視覺實現的復雜性，所以也要具體問題具體分析。
結點間的數據共享方式
目前結點間的數據共享方式有幾類：
- 父結點可以管理所有子結點的數據：用戶G可以【管理】部門A、部門B的所有用戶和所有資產。
- 子結點可以管理父結點的數據：用戶A1可以【管理】部門G的所有用戶和所有資產。
- 兄弟結點之間可以互相管理：用戶A1可以【管理】部門B的所有用戶和所有資產。
- 結點只能管理自己所在結點的數據：用戶A1只能【管理】部門A的所有用戶和所有資產。
- 結點里的用戶只能看到自己的數據：用戶A1只能【管理】用戶A1自己創建的用戶和資產。
實際業務系統進行數據權限的定義時：
a. 選擇以上一種或幾種規則；
b. 根據業務而定定義以上的【管理】：增、刪、改、查及各種小功能的組合。
比如如果選擇父結點只能【查看而不能編輯、刪除、新增】子結點的所有數據，那么圖中用戶G只能查看部門A的所有數據而不能對其進行編輯、刪除和新增。
結點里的用戶存在上下級關系怎么辦？
圖2-4? 和圖2-3一樣
如果實際業務中用戶A1是用戶A2的上級，并要求用戶A1能看用戶A2的數據，而用戶A2不能看用戶A1的數據怎么辦？
如果數據權限只規定到結點級（組織級），那么用戶A1和用戶A2看到的數據都是一樣的。所以需要再次引入功能權限的【角色】解決人員上下級問題。
例如，如圖2-4，系統選擇的結點間的數據共享方式是：結點只能增刪改查自己所在結點的數據，另外引入角色規則：管理員可以增刪改查所在結點所有數據，非管理員只能刪改查自己創建的數據。那么如果用戶A1的角色是管理員，A2是非管理員，A1就能增刪改查A部門所有資產，A2只能增刪改查自己創建的資產。
扁平架構
扁平化的組織架構比較簡單，只存在樹狀架構中的第3個問題。請參考樹狀架構的第3個問題。
功能權限和數據權限的碰撞：跨模塊的數據【使用】問題
假設某系統一共有兩個模塊：型號管理和設備管理，操作系統的流程是先創建型號再創建設備，如果一個用戶只有設備管理而沒有型號管理的權限，在創建設備時是否可以選型號？
圖2-5
這其實是一個功能權限（接口級）和數據權限融合的問題，即用戶創建設備的時候是否有請求型號列表接口的權限？列表中要展示哪些數據？
從功能權限講：用戶肯定有請求接口列表的權限，否則流程就無法走通了。
從數據權限講：有幾種規則作為參考，具體根據實際業務進行選擇：
- 不管哪個層級或者誰創建的型號都在接口中展示（即型號數據在別的模塊使用時全局可見）；
- 只展示當前登錄用戶所屬結點創建的型號；
- 只展示當前登錄用戶所屬結點及下屬節點創建的型號（扁平化組織架構不適用）；
- 只展示當前登錄用戶所屬結點的父結點創建的型號（扁平化組織架構不適用）；
- 只展示當前登錄用戶所屬結點的兄弟結點創建的型號（扁平化組織架構不適用）；
- 只展示當前登錄用戶創建的型號。
總結
- 建設toB的系統時要考慮兩種權限：功能權限和數據權限。
- 功能權限可以參考RBAC模型，通過引入角色、用戶組等概念降低復雜度。但系統用戶數量龐大，功能極度復雜且粒度足夠細時，復雜度已不可避免，只需考慮是把復雜交給用戶、運維還是代碼。
- 數據權限主要和組織架構有關，組織架構中樹狀架構較為復雜，需要統一或者分模塊的定義層級間數據共享問題。數據權限定義過程中如果出現同一結點下的【用戶間層級問題（上下級）】需要回到功能權限的【角色定義】去解決。
- 有一類跨模塊【使用數據】的問題也可以看成既定的接口權限和可選的數據權限問題。
總之揚帆在角色權限的海洋里繞啊繞啊繞，總會繞出幾個原則，走出幾個理論讓我們繞的更快，徜徉的更有成就感。
本文由 @娜娜 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
除了組織架構劃分出的權限之外，建議補充業務數據的訪問權限，比如當分配新建/查看/編輯 權限的時候，可以新建/查看/編輯 哪些數據
您好！請問跨模塊的數據【使用】問題中，我理解的是該有用具有型號管理的數據權限，但沒有型號管理的功能權限對嗎？
是的
數據權限和操作權限混一起，最終能把自己搞暈。一看就是紙上談兵的理想主義。
??
操作權限就是按鈕，數據權限很好理解，比如常見的上級可以看到下級的數據，那么你登錄的時候，將下級的權限+自己的權限都查詢出來即可，這樣就能實現數據權限，數據權限是偽命題，一定會結合具體業務。
功能優先級那塊，為什么查看詳情要大于查看列表，不是先到列表才能看各種數據和功能嗎，查看詳情的按鈕是掛著列表的操作列的
有道理
作者說的意思是：比如你配置好了一個低優先級的“添加”按鈕，此時更高優先級的“列表查看”和“詳情頁”就必須默認勾選上。
自己創建的自己能看到，如果僅有查看權限，沒有新增，是查看全部還是部分
一個部門下有多個人, 多個子部門 ;
一個領導管理多個部門 ;
這個領導需要看到的數據為所管理部門下的數據 ;
語言描述很簡單, 如何實現呢, 這種 SQL 查詢邏輯 數據量一多 效率一定非常低
統一數據權限和功能權限獨立的說法，如果是簡單的數據權限的確可以和功能權限一起合到角色中，但更多的業務場景需要單獨維護，這里就要看是落到人，崗位還是組織上去管理是最合適的問題了，最終都是落到人。
是的
請問一下，數據權限是在功能權限的基礎上建立的嗎？就是用戶A擁有【員工管理】整個功能模塊權限，用戶A的數據權限設置為可查看本部門數據，那么用戶A的部門數據權限是不是【員工管理】模塊的所有數據？
數據權限是在功能權限的基礎上的，員工A可以在員工管理中看到本部門的所有員工信息，其他部門的就看不到了哦～
同一組織節點下的上下級數據顯示問題用崗位去區分就好了
還有一個，我如何把這些功能權限的劃分還有數據權限的劃分體現到我的一個說明里，可以讓別人看到，并知道。還有一個我是否可以把他們理解為一種是你有哪些功能權限，一種是你再哪個定義域使用的概念，但感覺這樣說也不對，他們呢并不是一個東西的兩層約束，而是兩個不同的范疇。你總結的第三點我覺得很好，之前也做可見范圍這樣的單獨管理，可是弄的弄的就又回到了角色權限的匹配上，
我覺得最好的方式是在文檔上就區分開兩種權限去說明，各說各的。但在最后需要聲明，數據權限是建立在功能權限上說的。比如一個人沒有某個模塊的功能權限卻討論他的數據權限是沒有意義的。
了解
在功能顆粒度這里，頁面級的顆粒度是什么意思呢？
哪個角色能看到那個頁面，不能看到哪個頁面，從前端的視角看，系統是由一個個頁面組成的。
你好娜娜，舉手提問下哈。
文中提到了在權限管理的設計中，會碰到功能權限和數據權限融合的情況，比如我管理作為超管對一個設備管理員的權限進行管理，我把新增設備的功能權限配給他，此時他要看到設備來新增，此時我的需求是只想讓他看到部分設備，這樣的話，是不是我在數據權限點這里要進行范圍的控制，等于我把設備作為數據權限點，進行按需授權？
可以考慮將顆粒度細化，將設備型號作為數據權限點，進行增刪改查控制
sorry，現在才回復。
問題里的功能權限是比較明確的：新增設備、查看設備
數據權限的問題首先明確2點：
1、系統中設計的組織架構是怎樣的。
2、用戶和設備都是每個結點的資產，即一個結點中包括用戶和設備還有其他未提及的實體。
針對以上思考和用戶體驗，如果是我做的話我會這么設計：
1、自己創建的自己能看到（就是文中結點間的數據共享方式中的：結點里的用戶只能看到自己的數據）。這個很好理解，自己創建完查看不到很奇怪，無法驗證自己創建的是否正確。
2、企業域場景的數據權限一般是上層結點高于下層結點，為了不至于創建設備的用戶可以看到上層結點的設備，應該在用戶創建設備的時候就進行權限的控制，比如問題中的用戶只能創建所屬結點或下層結點的設備。
具體到問題，我認為創建設備的時候通過分配設備所屬結點就決定了設備可以被哪些用戶看到。
我理解你的問題是單純的把設備作為數據項分配給用戶（不知道理解的對不對），這種方式在理論上可行，但是操作成本太高，設計時考慮不全面也會導致權限的混亂和漏洞。
點個贊
現在遇到數據權限也需要用戶設定。權限這塊靈活度超高，什么都是用戶去設定。界面設計很頭疼
是不是將數據權限分組，或者將數據權限、功能權限糅合到角色里，再行分配給用戶。不過本身這個需求的復雜度已經很高了 ??
在糾結一個點，賬號管理，角色管理，需要做數據權限嗎？例如公司總負責人給各部門負責人分一個賬號和一個部門權限，那么部門負責人就只負責管理自己部門的人 的賬號和權限，他要去建賬號 這個賬號的權限
“公司總負責人給各部門負責人分一個賬號和一個部門權限，那么部門負責人就只負責管理自己部門的人 的賬號和權限，他要去建賬號 這個賬號的權限”是否需要把“用戶管理” 其實這是功能權限的問題：這個功能是否需要分給其他層級的用戶去做，需要考慮：系統用戶量級是否非常大，不分出去系統管理人員的工作量無法估量的話那就分出去。
而哪個層級的哪些用戶能看到哪些用戶列表才是數據權限的問題，這個要考慮公司的組織架構，數據安全、機密等問題了。
希望回答幫助到了你～
親 有權限管理的原型參考下嗎？要做功能權限和數據權限，有點頭疼
同求
權限管理的過程是分開完成還是一起完成？只管理操作權限或數據權限還是在管理操作權限的同時完成數據權限的設置？
從用戶操作層面看，選擇角色的過程中完成了功能權限的配置，數據權限早已隨著他的所屬結點確定。
從架構設計層面看，一開始是分開設計的，一般先做功能權限，最后會數據和功能結合看。但沒有既定的規則，想清楚就好。
有原型可以分享嗎？
原型中只會體現功能權限，不會有數據權限，數據權限需通過文檔描述。不過我做過的都是企業的，涉密。我找找有沒有可用的哈～
超級管理員可以管理操作權限和數據權限，數據權限不應程序寫死，當然，簡單的業務和簡單的組織寫死就可以了，復雜的業務、組織要求更加靈活，應實現可視化配置
確實寫死對于開發周期來說很舒服，但是自定義配置的話開發周期相對要長很多
同問數據權限如何可視化管理
求原型，最近也是在做數據權限和功能權限，頭疼
意思是數據權限其實是可以通過代碼層去寫規則實現，無需放到操作層面上，可配置的最多是父子結點的共享數據關系，在TO G項目中，數據權限確實頭疼
很受益
好頂贊！
挺好的
您將權限分成功能權限和數據權限，看看是否可以將功能權限細分成菜頁面權限和操作權限
頁面權限：就是用戶能看到什么頁面
數據權限：同一個頁面下，不同用戶可以看到什么數據
操作權限：相同數據不能用戶能對其進行什么操作（一般分為：查看、編輯和完全控制）
哈哈，我是把頁面權限當成功能權限的一種，不過你這個思路也很好玩兒，我沿著這么分想想～