權限管理是B端中常見的話題，它規定了用戶各自的角色和可使用的職能，也對數據的安全提供了保障。本篇文章中作者結合自身經驗，從四部分講述關于權限管理的設計經驗與設計方法。

權限管理是B端產品繞不開的話題，本文總結了我對權限管理的設計經驗與設計方法，共分為4個部分：

1. 權限管理的概念梳理
2. RBAC權限設計的一般步驟
3. 設計功能權限的三板斧：基礎版（權限、角色、用戶管理）、進階版（部門、職位、菜單管理）、拓展（版本管理）
4. 如何設計數據權限

所有內容均根據自身思考實踐及經驗借鑒而來，如有錯誤歡迎指正。

第一章：權限管理的概念梳理

一、權限是什么

權限包括了功能權限和數據權限：

• 功能權限是系統執行權限控制的基本單元，包括頁面權限、菜單權限、按鈕權限等
• 數據權限包括基礎數據、業務數據、資源數據等

針對功能模塊劃分用戶權限是一種粗顆粒度的劃分方式，表現在不同用戶可以查看相同的數據，但可執行的操作不同，如線上數據庫的數據只有超管可以刪除，其他人只能查看；針對數據劃分用戶權限是一種細顆粒度的劃分方式，表現在不同用戶進入同一頁面/菜單時，可見的數據有差異，如運營經理可以看到部門所有數據，運營人員只能看到自己創建的數據。做權限設計時，首先要分清功能權限和數據權限的界限，不要為了圖方便將二者揉起來。

二、為什么需要權限管理

• 崗位職責的需要
• 數據安全的需要

三、權限設計的核心思想

權限管理是用來控制用戶可以訪問而且只能訪問某些資源的系統，根據該定義，我們可以繪制出如下示意圖：

可以看出，用戶和資源形成了錯綜復雜的映射關系，很難管理。要解決這一問題，有兩種方法：一是減少用戶/資源數，顯然不切實際，這樣就只剩下了一種方法——減少映射關系。

在詳細介紹該方法前，我們先來看看數據庫中是如何解決查詢慢的問題的。大家可以思考一個問題，在【35、27、48、12、29、38、55】這組數列中如何快速找到數字55？

大部分人的第一反應就是一個個遍歷，這樣一共需要查詢7次。而對數據庫工程師來說，首先會找到一個媒介來構建這組數列的表示關系（見下圖-平衡二叉樹），然后再通過簡單的判斷只用3次就可以找到55了。這個媒介就是數據庫中的索引，在數據量巨大的時候，利用索引進行查詢的優勢十分明顯。

如果這個例子不好理解，大家還可以聯想下字典中的索引、書籍中的目錄或是圖書館中的書架標簽，核心思想都是抽象出對象的公共屬性，再進行分類管理。

利用這一思想，我們再來回看如何減少用戶和資源的映射關系。

1. 判斷用戶與用戶之間是否有公共屬性？
2. 找到對權限有影響的公共屬性，比如部門、職位等
3. 不斷抽象出中間媒介

對于資源也是同理。

經過以上步驟，原本雜亂無章的映射關系就變得既簡約又有層次（見下圖），我們只要把權限賦予到抽象出來的虛擬媒介上，就能夠大大降低管理的復雜程度。

四、權限管理模型的演進

了解了權限設計的核心思想后，我們以CMS系統的更新為例來闡述權限管理模型的演進。

1. ACL：基于用戶的權限管理模型

小王是一家創業公司的產品經理，負責一款CMS系統的設計。起初，網站的所有內容都由公司唯一的運營小紅負責，所以小王就對小紅的賬號開啟了所有權限。

這種直接將權限綁定在用戶賬號上的方式就叫做基于用戶的權限管理（ACL）。

2. RBAC：基于角色的權限管理模型

隨著運營部門不斷發展壯大，每次有新員工入職，小王都要為其單獨配置權限，而且無法批量修改，十分繁瑣。同時小王發現運營部門分工明確，部分人員負責內容審核，需要為他們開啟審核管理的權限；部分人員負責產出內容，需要為他們開啟內容管理的權限……這就導致小王經常會做一些重復性的工作。于是小王就想在現有的用戶層上再抽象出一層——角色層，只要對角色設置權限，屬于該角色的人員就自動擁有這些權限。

這種將權限綁定在角色上，再給用戶賬號賦予角色的方式就叫做基于角色的權限管理（RBAC），該模型于1992年由美國國家標準與技術研究院組織開發，是目前最通用的權限管理模型，節省了很大的權限維護成本。

GerorgeMason大學的教授Ravi Sandhu于1996年對RBAC模型進行改進，提出了RBAC96模型族，包括RBAC0、RBAC1、RBAC2和RBAC3四個模型。上圖代表RBAC0模型，也是其他3個模型的基礎。

a. RBAC1：角色繼承的RBAC模型

在CMS系統使用了一段時間后，小王發現了一個新問題——系統中存在的角色太多了，因為只要有權限不一樣的用戶加入系統，就需要新建一個角色，當用戶權限分得很細的時候，甚至比ACL還繁瑣，于是小王就想著手解決這一問題。

點他發現角色之間存在著類似組織架構一樣的上下級關系，比如COO>運營經理>運營主管>運營組長>運營人員>運營實習生，并且上級擁有下級的所有權限，同時可以額外擁有其他權限，于是他在現有的角色基礎上又抽象出一層角色等級。

這種在角色中引入上下級關系的RBAC模型就叫做角色繼承的RBAC模型（RBAC1），通過給角色分級，高級別的角色可繼承低級別角色的權限，一定程度上簡化了權限管理工作。

另外角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系要求角色繼承關系是一個絕對偏序關系，允許角色間的多向繼承，即下級角色可以擁有多個上級角色，上級角色也可以擁有多個下級角色。而受限繼承關系則要求角色繼承關系是一個樹狀結構，角色間只能單向繼承，即下級角色只能擁有一個上級角色，但是上級角色可以擁有多個下級角色。

b. RBAC2：角色限制的RBAC模型

過了一段時間，運營經理小紅向小王反饋，她的賬號竟然可以看到公司的財務賬單，經過核查，是小王由于粗心導致給小紅的賬號多綁了一個財務經理的角色。為了徹底規避這種風險，小王就讓開發加了一條判斷：當角色是運營經理時不能同時是財務經理。

這種針對角色進行限制的模型就叫做角色限制的RBAC模型（RBAC2），可以把限制具體地分為靜態職責分離（SSD）和動態職責分離（DSD）：

SSD：

• 互斥角色：同一用戶只能分配到一組互斥角色集合中至多一個角色，比如用戶不能同時擁有會計和審計兩個角色
• 基數約束：一個用戶可擁有的角色數目受限；一個角色可被分配的用戶數量受限；一個角色對應的權限數目受限
• 先決條件角色：用戶想要成為上級角色，必須先成為下一級角色，比如游戲中的轉職

DSD：允許一個用戶具有多個角色，但在運行時只能激活其中某些角色，比如BOSS直聘，一個用戶既可以是招聘者也可以是應聘者，但同時只能選擇一種身份進行操作

c. RBAC3：統一的RBAC模型

RBAC3=RBAC1+RBAC2，既引入了角色間的繼承關系，又引入了角色限制關系。

d. 組：完善的RBAC模型

現有的權限管理模型雖然已經對“角色”進行了層級優化，但并沒有優化“用戶”方，這就意味著每入職一個新員工，小王得單獨為其設置權限，還是很麻煩，于是他利用抽象的思想將相同屬性的用戶進行歸類。在公司里，最簡單的相同屬性就是“部門”了，如果給部門賦予了角色和權限，那么這個部門中的所有用戶都有了部門權限，而不需要為每一個用戶再單獨指定角色。

用戶可以分組，權限同樣也可以分組。在權限特別多的情況下，可以把同一層級的權限合并為一個權限組，如二級菜單下面有十幾個按鈕，如果對按鈕的操作沒有角色限制，可以把這些按鈕權限與二級菜單權限合并為一個權限組，然后再把權限組賦予角色就可以了。

“組”概念的引入完善了RBAC模型，在簡化操作的同時更貼近了實際業務，便于理解。

3. ABAC：基于屬性的權限管理模型

為了內容的安全，運營經理小紅向小王提了一個需求：負責內容管理的人員不可以在公司以外的地點發布內容。這可難倒了小王，因為現有的RBAC權限模型僅能對頁面/功能/數據賦予權限，沒法執行如此精細的權限控制。在查閱相關資料后，小王找到了該問題的解決方法——基于屬性的權限管理模型（ABAC）。

ABAC是通過動態計算一個或一組屬性是否滿足某種條件來進行授權判斷的，包括用戶屬性（如性別年齡）、環境屬性（如時間地點）、操作屬性（如編輯刪除）和對象屬性（如一篇文章）。

跟RBAC相比，ABAC能夠實現非常靈活的權限控制，可擴延展性也很高，幾乎能滿足所有類型的需求。但是設計起來比較復雜，而且對于單一屬性可以通過編寫簡單的判斷邏輯代替，所以還沒有被廣泛應用。

五、權限管理與權限體系

權限管理是指為解決某一具體的權限分配問題而采用的方法，比如解決文件的權限分配問題可以采用ACL模型，解決不同年齡段的用戶可訪問不同類型的電影問題可以采用RBAC+ABAC。

而權限體系是指整個系統內采用的權限管理方法的集合。

本系列文章聚焦于單系統內的RBAC權限管理。

六、權限設計的誤區

1. 唯RBAC論

盡管RBAC已經被廣泛應用，但還是要避免一上來就這么做。權限的設計需要評估數據量和業務復雜度，如果預估的數據量特別少，業務又很簡單，那完全可以用其他方式。

2. 唯自由配置論

不要認為把權限設置得靈活可配用戶就滿意了，實際上用戶沒有那么聰明，他會為角色名稱而糾結，看到一系列的權限配置也會不知所措。如果你的業務能夠抽象出一些固定角色和統一權限，那就把他們內置起來。

3. 權限越多/越細越好

權限不是功能列表，一味地細化而不注重實際業務，只會增加開發工作量，也不利于用戶配置?？梢詢H選擇常用的功能點作為權限配置，也可以將多個功能點抽象為一個權限點，如將“增刪改”三個功能抽象為一個“管理”權限點。

第二章：RBAC權限設計的一般步驟

一、梳理角色

1. 羅列所有角色

角色是一種抽象的身份，RBAC離不開角色，因此第一步就是從業務中找到所有可能涉及到的角色。

如果你做的是企業內部管理系統（如ERP、OA），可以參考組織架構找到所有角色（如產品經理、產品助理、項目負責人）；其他系統可以通過業務流程找到相關角色，如開展一次線上筆試按流程需要出題老師、題目審查老師、考場管理員、助理、監考老師、巡考老師、考生、閱卷老師。

2. 找到各角色之間的關系

找到所有角色后，第二步就是找出各角色之間的聯系。常見的有繼承、互斥和共享關系，還可根據實際業務找到角色之間的其他關系：

• 等級/繼承：產品總監、產品經理、產品助理、產品實習生
• 互斥：財務和審計不能是一個人
• 共享：閱卷老師和監考老師可以是同一個人
• 串行：先由產品經理進行設計再由開發人員開發
• 并行：前端后端一起開發
• ……

3. 分析角色是否需要內置以及是否需要隱藏

分析哪些角色我們可以事先定好，哪些角色可由用戶自定義。內置角色適用于角色通用且固定、使用頻率高的情況，目的是為了簡化用戶的操作步驟。常把“管理員”角色進行內置，也可根據實際業務選擇，比如線上考試系統，“考生管理”菜單就屬于內置角色，添加到該列表中的賬號只能是“考生”。

同樣還要考慮角色是否需要展示給用戶，比如一些系統的“超級管理員”就不需要展示給用戶。

二、梳理權限

1. 梳理功能權限

權限分為功能權限和數據權限，其中功能權限又可分為菜單權限和按鈕權限。

梳理功能權限一個最簡單最實用的辦法就是用“功能列表”（下圖以“有贊”為例）。

2. 梳理數據權限

數據權限就是系統中存在的數據、資源能夠被誰查看和管理。說到數據權限，就不能不提數據庫。

1）表/對象

表是包含數據庫中所有數據的數據庫對象，不同的業務數據存在于不同的表中，如下圖從上到下依次為考生表、考場表和考官表。

2）數據

表中存放著二維數據，由行和列組成，如下圖的考生表，每一行代表一個考生，每一列代表考生的一個屬性。

通過表和數據之間的關系，可以把數據權限分為以下四種情況：

（1）基于系統的數據權限

即系統中的所有表都能被大家看到并管理，也可理解為沒有數據權限，比如管理員A、B都能看到并管理所有考生、考官、考場數據。

（2）基于對象的數據權限

即按表劃分數據權限，比如管理員A只負責管理考生，管理員B只負責管理考場。

（3）基于行的數據權限

即按表中的數據行劃分數據權限，比如管理員A只能管理B學校的考生，但不能管理C學校的考生；或者A部門的經理只能看到A部門職員的周報。

（4）基于列的數據權限

即按表中的數據列劃分數據權限，比如管理員A只能看到考生的姓名，而管理員B可以看到考生的姓名、手機號和身份證號。

在梳理數據權限時，可根據實際業務對對象、行和列的數據權限自由組合，比如針對學校A的管理員只能查看學校A的考生及考官的姓名和電話號碼，無法查看身份證號這個需求，就使用到了基于行和列的數據權限。

三、連接角色與權限

1. 連接角色和功能權限

得到功能列表后，需要跟角色關聯在一起，可直接在表后添加角色列，再根據業務對角色是否擁有該功能權限做判斷。

2. 連接角色和數據權限

數據權限一般是一系列的規則，可通過文字描述附在上表后。

3. 分析與整理

所有的權限都需要進行分配，但不是每個權限都值得讓用戶來配置。

在上一步完成后，我們就建立起了所有角色和權限的聯系，但上表還不能直接使用，在詳細設計之前，還要分析出哪些權限需要用戶手動分配，哪些不需要？哪些功能權限可以合并，以便減少用戶操作次數？什么場景下數據權限需要可配置？等等這些必須得根據具體的業務進行判斷。

仍以“有贊”為例，上圖是配置“線索管理”功能權限的實際頁面，可以看到它只為用戶提供“查看、編輯、轉讓、放棄、添加資料項、辦理試聽”這幾個功能，其他的功能權限要么都歸屬于“查看”（添加、辦理報名等），要么合并到一個功能里（“批量轉讓”合并到“轉讓”）。

理論上是可以把所有的功能權限拿出來讓用戶配置，但是考慮到用戶體驗，對權限進行分析和整理是非常有必要的。

第三章：設計功能權限的三板斧

通過上述分析，我們得到了最終的角色與權限的關系，接下來就進入到如何設計界面的環節。

設計功能權限離不開最基本的三要素：用戶管理、角色管理、權限管理；根據業務的不同，可能還會涉及更復雜的三要素：部門管理、職位管理、菜單管理，在這些之上還會配置不同的版本滿足不同的客戶需求，這就需要版本管理，下文將會對如何設計這些管理功能進行詳細的介紹。

一、三板斧-基礎版

1. 權限管理

權限管理是為角色賦予權限，權限可以內置，也支持用戶自定義，權限的配置需要跟角色綁在一起，當權限較簡單且相對固定時，可由后端人員寫死在代碼里或者寫死在配置文件里。

2. 角色管理

在“梳理角色”步驟中，我們列出了系統中涉及到的所有角色，“角色管理”就是對這些角色進行線上化的鏡像和管理。

按角色的來源可分為用戶自定義角色和系統內置角色：

自定義角色：角色的名稱和權限都可由用戶自由配置，并可任意修改。

內置角色：角色的名稱和權限由系統內置好，用戶僅可查看無法修改。

設計“角色管理”主要有三個頁面：

• 角色列表頁：展示系統中的所有角色，至少應顯示角色名稱以及查詢、刪除（自定義角色）、查看（內置角色）、新增、編輯等操作。

• 添加角色頁：必須輸入不可重復的角色名稱，可選填狀態、備注、排序等信息。交互方式上可根據頁面內容的豐富程度選擇彈窗或抽屜的形式。

• 配置權限頁：可在創建角色的同時配置權限（見上圖），也可在創建角色后配置權限（見下圖），兩種方式沒有本質區別。

另外在一些系統里，綁定權限的這個載體不叫“角色”，而是其他的名字，比如在釘釘中叫“管理組”，這里我們要清楚它其實就是“角色”。

3. 用戶管理

“用戶管理”是用于管理用戶信息的，如更改用戶角色、創建或刪除用戶、更改密碼和用戶信息。

設計“用戶管理”主要有兩個頁面：

• 用戶列表頁：展示系統中所有的用戶。應支持新增、編輯、刪除、導出、導入及批量操作。

• 添加用戶頁：根據業務選擇創建時需要的字段。添加用戶時，必須為用戶設置角色，可選角色為“角色列表”中存在的自定義角色和內置角色。

同“權限分配”一樣，“角色分配”也可以單獨放在用戶列表中的操作里，這樣的交互更專一，但實際沒有什么不同。

4. 注意事項

1）用戶與角色

需要根據實際業務確定一個用戶可以綁定多少個角色。如果可以綁定多個角色，角色之間有沒有繼承、互斥等關系，功能權限如何劃分，這些情況都要提前考慮到。

另外，如果有內置角色，別忘了在內部的“運營管理平臺”上設計專門針對“內置角色”的管理功能。

2）角色間的關系

上文中我們列出了角色之間的關系（等級/繼承、互斥、共享等），現有的“角色管理”僅能通過一個用戶綁定多個角色的方式實現“角色共享”，但沒法實現角色間的繼承和互斥。

角色間如果有繼承關系，可通過下文的“角色組（職位）管理”實現；如果有互斥關系（如會計和審計），對于內置角色可以在代碼中寫死判斷，對于自定義角色，可以讓用戶另外設置互斥規則。

3）權限組

上文說的分析與整理，其實就是建立權限組，將不必要的權限進行合并，可以簡化用戶操作。

經過以上步驟，一個基本的權限系統就設計完成了，足夠應付80%的場景。

二、三板斧-進階版

如果是做OA系統的權限管理，或者對靈活度有較高的要求，那么可以了解下進階版的權限管理三板斧。

1. 部門管理

“部門管理”有三種使用場景。第一種是為了構建企業的組織架構，在這種情況下，部門管理與功能權限沒有關系，僅用于歸類用戶以及分配數據權限。

與功能權限有關系的是下面兩種場景：

第二種場景是為了承擔“用戶組”的作用。在上文介紹RBAC中，如果用戶量很多時，將每個用戶與角色權限匹配會十分麻煩，這時就需要將用戶的共有屬性做抽象，在企業中，用戶的共有屬性可以用部門來表示。

第三種場景是為了承擔“角色”的作用，可以為部門直接賦予功能權限，部門中的用戶繼承該部門的功能權限。若用戶也擁有其他角色的權限（如下圖的用戶2），則實際的功能權限為二者的并集。

另外在分配部門權限時，還需要考慮子部門與父部門的權限關系：可以選擇同父部門的權限保持一致，也可以選擇子部門繼承父部門的權限，并可在其范圍內進行編輯，還可以設置完全區別于父部門的權限，這取決于業務的復雜程度。

2. 職位管理

“職位管理”有兩種使用場景。第一種是為了完善員工信息，屬于一種屬性，與功能權限沒有關系。

第二種場景與功能權限相關，是為了承擔“角色組”的作用?！敖巧M”是為了滿足上下級關系而衍生出的概念，比如“產品經理”應該擁有“產品助理”的所有權限，有了上下級后，再來一個“產品總監”的角色，就不用單獨為其設置所有的功能權限，只需將它設為“產品經理”角色的父級，再添加一些特殊的權限即可。

3. 菜單管理

不管是“部門”還是“職位”，解決的都是“用戶”和“角色”怎樣配置更靈活的問題。在RBAC中還有一個“權限”，目前對權限的管理只介紹了可以通過后端人員寫死在代碼里或者寫死在配置文件里，如果功能權限經常變動，并且自由配置的需求極高，有沒有更靈活的辦法來管理權限呢？有！就是“菜單管理”。

“菜單管理”又被稱為資源管理，是系統資源對外的表現形式。有了“菜單管理”，不僅可以讓權限的管理更簡單（不需要后端寫死），還能夠讓系統展示更靈活（能夠改菜單信息）。

“菜單”分為三類：

1. 目錄：在系統內沒有實際頁面
2. 菜單：存在實際頁面
3. 按鈕：菜單中的可操作項

設計“菜單管理”主要有兩個頁面：

1）菜單列表頁：

導航菜單是分上下級的，因此可以用樹狀圖表示，常見的菜單屬性包括菜單名稱、菜單類型（目錄、菜單、按鈕）、圖標、排序、路由地址（瀏覽器訪問菜單的地址）、組件路徑（項目的組件文件的路徑）、權限標識（查看、編輯、添加等）、是否外鏈、啟用狀態和創建時間。除了圖中展示的字段，根據業務需求還可以增加“編號、是否打開新頁面、是否隱藏、是否緩存（切換到其他菜單當前菜單會進行緩存）”等字段。

2）添加菜單頁：

添加目錄：目錄可以是外鏈，即點擊后跳轉到外部地址，必須帶上https://或者http://，如果不是外鏈，則需要填入路由地址，由開發人員給出。

添加菜單：當菜單是外鏈時，規則同目錄，若不是外鏈，則可選填組件名稱、權限標識、組件路徑（具體應跟開發討論系統中是否有涉及）。

添加按鈕：添加按鈕時，輸入權限標識即可。

4. 注意事項

1）誰繼承誰

關于“權限繼承”，細心的讀者會發現我在第一章介紹RBAC時寫過：“高級別的角色可繼承低級別角色的權限”，而在本章中又說：“子部門可以繼承父部門的權限”，是不是沖突了。

其實不然，假設現有AB兩個部門，要在它們之上設立一個部門C，則C部門的權限為AB兩個部門的并集，從這個角度講，部門C繼承了部門AB的權限，且部門C還可單獨設置權限；而如果要給部門A下設一個部門C，部門C會繼承部門A的權限，并可在此范圍內細化權限。兩種說法表達的意思是一樣的，都是子級屬于父級的權限范圍內。

2）功能權限最好不要綁在多個實體上

在上面的介紹中，“部門”、“職位”都可以充當“角色組”直接綁定功能權限，但在實際中卻很少有系統這么設計，根本的原因就是沒有必要——功能權限最好只綁在一個實體上，意思是說，如果系統中已經有了“角色管理”（為角色設置功能權限），就沒有必要再對部門或職位設置功能權限了，同樣如果系統中已經為了部門/職位設置了權限，也就沒有必要再引出“角色”這個概念了。因為在現實工作中，很少有人在部門、職位和角色上有單獨的功能權限，即便是有，也可以通過新建一種“角色”來簡化復雜度。如今大部分的OA系統上，職位和部門更多被用于用戶歸類以及管理數據權限。

3）菜單管理如何實現權限組

需要注意的是，“菜單管理”是精細到系統中最小的操作，可以直接用于分配角色的權限，但如果為了提升用戶體驗，需要給用戶展示出合并后的功能權限時（見下圖），則不可在“菜單管理”中直接設置“查看與操作”的按鈕，而應該在“菜單管理”之上建一層專門用于展示給用戶的功能權限，其中“查看與操作”權限綁定了“新建+編輯+刪除”的按鈕。

5. 拓展：版本管理

對于SAAS軟件，常常會分多個版本來滿足不同層次的客戶需求，不同版本之間的功能權限會有差異。面對這種情況，可以通過“版本管理”來實現靈活管理（此“版本”非產品迭代的版本）。

設計“版本管理”主要有兩個頁面：

• 版本列表頁：列表展示版本的信息。

• 版本功能權限配置頁：類似于為角色分配權限，這里可以理解為為版本分配權限。不同的是這里的功能權限會比“菜單管理”中的權限更細致。以“題目管理”為例，一般在“菜單管理”中，只會設置到一級頁面的“添加、導入、刪除、編輯題目”按鈕，但在版本管理中會細化到題目類型，如免費版不能添加“聽力題”，甚至會對功能的可用次數進行限制。有兩種設計方案可以解決這一需求，如果每個版本之間的權限分得又細又多（見本節第一張圖，考試星的版本功能對比），那么最好在菜單管理中覆蓋掉所有子頁面的按鈕，可用次數以單獨的規則進行限制；如果版本之間只是個別的細小功能有差異，則在現有“菜單管理”的功能基礎上添加限制規則即可。

還有一種更復雜的情況，同一版本的不同客戶之間也會有不同的功能權限，那么還需要對每一個客戶配置功能限制。

第四章：如何設計數據權限

上文講過數據權限分為四種情況（劃分依據詳見第二章）：

1. 基于系統的數據權限
2. 基于對象的數據權限
3. 基于行的數據權限
4. 基于列的數據權限

其中”基于系統的數據權限”可以理解為不分數據權限，因為大家看到的和可操作的內容都是一樣的；“基于對象的數據權限”可以通過功能權限來實現，比如為用戶A分配了客戶表的權限，那么A就能夠看到并操作所有客戶，也就相當于為用戶A分配了“客戶管理”的功能權限。因此下文主要討論后兩種情況。

另外，數據權限的分配也可分為內置和用戶自定義兩種。內置數據權限屬于系統中寫死的規則，如本校老師只能看到本校的資源，公共庫中的資源所有學校的老師均可看到，銷售人員創建的線索只有自己能夠管理等等，內置數據權限過于簡單，也不在本文討論范圍內。

一、基于行的數據權限

基于行的數據權限分為兩種情況，一種是為對象（部門/角色）分配數據，如上級部門可以管理下級部門的所有數據；還可以將數據分配給對象，如共享文件。

1. 為對象分配數據

1）無組織架構

對于不涉及組織架構的系統，數據權限的設計比較簡單，在為角色配置權限時，一并展示可分配的數據權限即可。

分配數據權限的前提是分配了對應的功能權限，比如要讓計算機老師只能管理“軟件工程”的所有題目，前提是要給老師開啟“題庫管理”的功能權限，否則老師連“題庫管理”都看不到，何來管理其中的題目數據。當然功能權限不一定非要手動分配，也可以內置，比如藍湖，加入的成員默認開啟了“團隊文件”的菜單，所以在配置時只需要展示數據權限列表。

2）有組織架構

可以通過設置“管理范圍”實現上下級之間的數據權限控制。比如針對上級可以看到下級的題庫這一需求，可以設置一個“部門負責人”角色，并設置管理范圍為“所在部門和下級部門”，然后將公司領導、各部門負責人都添加成這個角色，即可實現該需求。

也可以通過設置“管理范圍”實現跨部門之間的數據權限控制。比如針對研發部負責人可以看到IT部門題目的需求，則可以新建一個角色，管理范圍選擇“特定部門”，并勾選“研發部和IT部”。

還可以通過設置“管理范圍”實現同部門之間的數據權限控制。比如都是產品部，產品組長能看到下屬創建的題目，但看不到產品總監創建的題目，產品助理只能看到自己創建的題目，這時就需要用到職位的層級關系。

2. 為數據分配對象

可以理解為把數據直接共享給某個角色/部門，常用于文件/資源的共享，下圖是釘釘上對文件的權限管理。

二、基于列的數據權限

如果說數據權限是對功能權限在縱向的擴展，那么字段權限就是在橫向的擴展。因為設置數據列權限可以禁止指定角色對某些敏感字段的訪問，如身份證號、交易金額等。

設計“列權限”主要有兩個頁面：

• 入口：可以在創建角色時一同設置，也可以單獨作為角色的一個操作，還可以放在“角色管理”中對所有角色批量設置，更可以在對應的菜單頁面中進行設置。
• 列權限設置頁：下圖展示的是對所有角色批量設置列權限的設計，列出有各功能權限的角色和該菜單中的字段，由用戶勾選即可。

全文完。

最后做個總結，本文第一章講了權限管理的基本概念，第二章講了RBAC權限管理在設計前的分析步驟，第三章和第四章分別講了如何設計功能權限（權限、角色、用戶、部門、職位、菜單、版本）和數據權限（基于行和基于列）。文中部分圖片手機看不清，可用電腦端打開，內容如有錯誤歡迎指正。