干货 | B端产品如何设计权限系统？
本文由作者 七牛?發布于社區
現代經濟學理論認為，企業本質上是“一種資源配置的機制”，其能夠實現整個社會經濟資源的優化配置，降低整個社會的“交易成本”。 權限管理系統的本質是企業內部或企業之間的資源在B端產品上以特定機制配置的映射；所以權限管理系統的貼身情況也是衡量產品商業模式好壞、用戶價值高低的一桿標尺。 權限管理系統的設計中常遇到的問題有：配置不規范，系統基礎不穩，拓展性差；
配置不靈活，用戶需求難滿足，體驗差；
配置太靈活，邏輯會復雜，實施成本高；
那么，如何設計一款貼身并能隨著產品一起生長的權限管理系統呢？
在古代，沒有互聯網、沒有軟件時，泱泱中華在中央集權的帝制制度、“君君臣臣、父父子子”的角色說明書等管理系統中正常運轉；皇帝把資源下發給特定的人、崗位角色、宦官集團等以促進農業生產、稅收、戶籍管理、治安維護等；資源包括權力、辦事流程等抽象資源，也包括錢財、糧食、鹽、礦等實物資源，同時包括印章、信紙、官服、轎子、馬等承載資源、象征權力、代表等級的工具。而管理機制除了帝制和角色說明書，還有子承父業的繼承機制、藩王行為規范、文官武官的互斥監督、官職逐級遞升約束、虎符口令雙向驗證等等；在盛世時期百姓人口增加、戰爭時期軍隊數量增加要在基礎機制上做適應性的調整。
權限管理的本質也大致如此，管理的是主體對客體遵循特定機制做出的行為。
權限管理系統的組成要素有哪些？
常見的權限模型有哪些？
Oracle和Salesforce的權限模型是啥樣的？
實操案例中如何應用的？
有哪些經驗及建議？
01
4個基本要素
權限是主體對客體遵循特定機制做出的行為。所以，權限的4個基本要素就是主體、客體、行為、機制。
1.1、主體
指行為的行使者，是操作的發起者。主體的類型有很多種，常見的有：
用戶及用戶組。更準確地術語應是“系統使用者”，其與系統的賬號體系相對應，一個用戶對應一個唯一賬號；多個用戶組成一個用戶組；
角色及角色組。角色是權限分配的單位與載體，通常與組織架構體系相對應。Oracle產品中分為工作角色、職責角色、數據角色和抽象角色四類，后面我們會說到；
用戶標簽及用戶標簽組；
設備及設備組。HarmonyOS系統首期給Mate40系列開放使用；
IP地址。限制對IP地址的訪問；
地理位置。如O2O生活平臺在不同位置展示的店鋪不同；
局域網。如公司電腦在內網和外網所訪問的資源不同。
1.2、客體
指行為的承受者，是操作所針對的對象。主要有三大類：
資源
基本屬性的數據
行數據
個別的列數據（俗稱“某些字段”）
資源的容器
頁面
目錄或菜單
Tab
按鈕
操作資源所必須的條件
任務流，也稱工作流。某一資源在任務流中的狀態不同，不同狀態的資源可以分配給不同角色操作；
所屬權。所屬權包括個人、個人及下屬、部門、部門及下屬、全部，通常與組織架構體系的組織范圍相對應。
1.3、行為
指主體對客體的活動，包括主體在產品中對客體的一些操作，而我們常說的“權限”一詞則指代了這一操作，例如“查看朋友圈的權限”。常見的行為有：
登入、登出
增
刪
改，包括讀寫
查，包括不可見、只讀
上傳、下載
共享
......
1.4、機制
系統機制包括對主體、客體和主客體關系的認證，對主體行為及行為運行方式的授權。常見的機制有：
繼承。父級可以擁有子級的權限，依托于組織架構或角色層級結構；例如銷售部門負責人有所有下屬的權限；
互斥。是對主體之間責任的強制性規定，防止同一主體擁有足夠權限進行欺騙行為，防止即當運動員又當裁判的行為。責任分離有靜態和動態之分：
靜態互斥。一個用戶不能同時擁有兩個互斥的角色。例如銀行內部的貸款申請者和貸款審批者不能讓同一個人承擔；
動態互斥。一個用戶可以擁有兩個角色，但在運行時只能激活一個角色，也成為運行互斥機制。例如銀行內部為了靈活放貸，職員張三可以同時有貸款申請者角色和貸款審批者角色，但對于同一筆貸款，不能即申請又審批。
先決條件。A想成為C，就必須先成為B，C只能從B中產生；
基數限制。是主體與主體、主體與客體、主體與行為間數量關系的限制。例如一個用戶可擁有的角色數目受限；一個角色被分配的用戶數量受限；一個角色的權限數目受限；
授予機制。是主體將自己的權限授予給其他主體的權限；
雙向驗證。系統即驗證主體，也驗證客體，雙方都通過驗證時才能允許主體對客體的行為；
共享機制。
訪問范圍限定機制。一般有三類依托：
組織架構
角色層級結構
組織范圍?/?抽象關系
環境限制。分為三類：
空間限制。例如針對地理位置、IP地址、局域網的限制；
時間限制。例如考試時間到了之后，操作權限有所限制；
頻度限制。例如對輸入密碼的頻率的限制；
02
5種常見的權限模型
2.1、ACL模型：訪問控制列表
Access Control List，ACL是最早的、最基本的一種訪問控制機制，是基于客體進行控制的模型，在其他模型中也有ACL的身影。為了解決相同權限的用戶挨個配置的問題，后來也采用了用戶組的方式。
原理：每一個客體都有一個列表，列表中記錄的是哪些主體可以對這個客體做哪些行為，非常簡單。
例如：當用戶A要對一篇文章進行編輯時，ACL會先檢查一下文章編輯功能的控制列表中有沒有用戶A，有就可以編輯，無則不能編輯。再例如：不同等級的會員在產品中可使用的功能范圍不同。
缺點：當主體的數量較多時，配置和維護工作就會成本大、易出錯。
（該圖片來自網絡）
2.2、DAC模型：自主訪問控制
Discretionary Access Control，DAC是ACL的一種拓展。
原理：在ACL模型的基礎上，允許主體可以將自己擁有的權限自主地授予其他主體，所以權限可以任意傳遞。
例如：常見于文件系統，LINUX，UNIX、WindowsNT版本的操作系統都提供DAC的支持。
缺點：對權限控制比較分散，例如無法簡單地將一組文件設置統一的權限開放給指定的一群用戶。主體的權限太大，無意間就可能泄露信息。
2.3、MAC模型：強制訪問控制
Mandatory Access Control，MAC模型中主要的是雙向驗證機制。常見于機密機構或者其他等級觀念強烈的行業，如軍用和市政安全領域的軟件。
原理：主體有一個權限標識，客體也有一個權限標識，而主體能否對該客體進行操作取決于雙方的權限標識的關系。
例如：將軍分為上將>中將>少將，軍事文件保密等級分為絕密>機密>秘密，規定不同軍銜僅能訪問不同保密等級的文件，如少將只能訪問秘密文件；當某一賬號訪問某一文件時，系統會驗證賬號的軍銜，也驗證文件的保密等級，當軍銜和保密等級相對應時才可以訪問。
缺點：控制太嚴格，實現工作量大，缺乏靈活性。
2.4、RBAC模型：基于角色的訪問控制
(Role-Based Access Control)，RBAC模型在目前使用的最廣泛、最普遍。
原理：在主體和權限之間引入了“角色（Role）”的概念，角色解耦了主體和權限之間的關系。，有四個不同的層次：
RBAC0：基本模型，相當于ACL+角色。權限被賦予角色，而不是用戶，當一個角色被制定給一個用戶時，該用戶就擁有了該角色所包含的權限。所有的角色都是平級的，沒有制定角色層級關系；所有對象都沒有附加約束，沒有制定限制；
RBAC1：角色分級模型，相當于RBAC0+繼承機制；
RBAC2：角色限制模型，相當于RBAC0+互斥機制+先決條件機制+基數限制機制；
RBAC3：統一模型，相當于RBAC1+RBAC2。
缺點：需要將某個權限單獨設置給用戶時，如果用戶已有的角色中不包含該權限，就需要重新設置角色的權限或者重新創建一個新的角色，在業務和需求變更時需要維護大量的角色。
（該圖片來自網絡）
（該圖片來自網絡）
2.5、ABAC模型：基于屬性的訪問控制
(Attribute-Based Access Control)，能很好地解決RBAC的缺點，在新增資源時容易維護。
原理：通過動態計算一個或一組屬性是否滿足某種機制來授權，是一種很靈活的權限模型，可以按需實現不同顆粒度的權限控制。屬性通常有四類：一是主體屬性，如用戶年齡、性別等；二是客體屬性，如一篇文章等；三是環境屬性，即空間限制、時間限制、頻度限制；四是操作屬性，即行為類型，如讀寫、只讀等。
例如：早上9:00~11:00期間A、B兩個部門一起以考生的身份考試，下午14:00~17:00期間A、B兩個部門相互閱卷。
缺點：規則復雜，不易看出主體與客體之間的關系，實現非常難，現在應用的很少。
03
Oracle和Salesforce的權限模型是啥樣的？
3.1、Oracle
其權限管理系統基于RBAC模型的基礎發展，角色分為四類：
工作角色：反映了工作頭銜并描述了責任職位。例如采購員；
抽象角色：代表個人與企業或組織的一般關聯，與該人的工作（職位）無關。例如臨時工、員工、直屬經理等；
職責角色：將必須在抽象角色或工作角色中執行的任務分組，代表一項工作職責的一組功能和數據權限。例如文章的審核職責；
數據角色：是訪問特定數據的權利。例如HR中的薪資管理員可以看員工薪資，其他HR不能看。
這四種角色之間有什么樣的聯系呢？
抽象角色和工作角色必須繼承職責角色。工作角色可以繼承抽象角色和其他工作角色。數據角色可以繼承抽象、作業和其他數據角色。職責角色可以繼承其他職責角色。該圖顯示了角色類型之間的這些繼承關系。
不同角色之間如何訪問功能和數據呢？
這四類角色是如何配置在一個賬號上的呢？
注意的是數據角色、數據權限一般直接配置在用戶身上。
3.2、Salesforce
是通用型CRM系統中權限管理靈活配置的先進案例。使用簡檔、權限集、權限集組，控制用戶可以訪問的對象和字段。使用組織范圍的共享設置、用戶角色和共享規則，以指定用戶可以查看并編輯的單個記錄。
簡檔定義了用戶訪問對象和數據的方式，以及在應用程序內部執行的操作。簡檔是每個用戶指定的標準配置文件，在創建用戶時指定。一個用戶只能有一個簡檔，同一個簡檔可以配置給多個用戶。例如某公司的銷售人員的簡檔是一樣的。
權限集是授予用戶對各種工具和功能的訪問權限的設置和權限集合。無需更改用戶簡檔，權限集即可擴展用戶的功能訪問權限。多個權限集可以構成一個權限集組。一個用戶可以有多個權限集及多個權限集組，同一個權限集或權限集組可以配置給多個用戶。
角色旨在提高數據可見性，控制著用戶可以看到的內容。角色并非對每個用戶都是強制性的。角色/角色層次結構的主要功能是允許層次結構中的較高級別的用戶訪問層次結構中較低級別的用戶擁有的記錄。例如：上級見下級，平級之間不可見。
角色層級衍生于組織架構，定義了角色之間的層級結構，例如銷售副總裁在角色層次結構中，分管不同地區的銷售經理。而組織范圍定義了數據的讀寫等操作所屬范圍，例如閱讀范圍有全部數據、本部全部數據、本部及子部全部數據、本人全部數據、本人及下屬全部數據等，操作范圍有個人操作、公共操作。
簡檔和角色之間的區別與聯系是什么？
簡檔和權限集之間的區別與聯系是什么？一般使用簡檔分配給用戶最低的權限集合，然后使用權限集補充配置的其他權限。兩個聯合使用，提供了訪問的靈活性。兩者對權限點的控制范圍與設置方式是相同的，包括：
用戶可以看到哪些對象；
用戶可以看到哪些對象的哪些字段；
用戶可以對哪些對象有什么行為；
用戶可以看到哪些應用；
用戶可以看到對象在不同的應用中的形態；
簡檔、權限集是如何配置在一個賬號上的呢？
對字段權限的設置如下：
數據共享規則的設置如下：
04
實操案例中如何應用的？
將上文已講的所有機制及權限對應的場景放入一個公司的管理系統中如下展示：
除此之外，也可以有一個賬號對應多個企業角色，但在使用時需要選擇其中一個企業角色使用；例如我是浙江省銷售經理，同時兼任門店一的店長，一般來說銷售經理只需要查看三個門店的數據即可，而店長要管理門店的所有操作及數據輸入；那么為了減少工作混亂及權限的耦合程度，可以給我配置兩個企業角色，一個浙江省銷售經理，一個門店一的店長，登錄后必須選擇一個企業角色再進入相應產品界面，兩個企業角色可以隨時切換。
05
經驗及建議
1、從產品開發商?to?企業客戶，再從企業客戶?to 使用者的角度來看
一般產品開發商要根據客戶畫像、業務模式和行業標準將權限劃分，求同存異，相同部分默認配置，不同部分根據業務粒度抽象為可配置項；而企業內部給使用者配置是也需要根據用戶習慣及標準化的操作進行求同存異，因為線下的靈活性難以把控，所以盡可能將能在線上化的部分標準化，但保證使用者只能用到自己需要的功能和數據。抽象程度越高，配置項越少，開發成本和實施成本越低，用戶體驗越好，使用起來越貼身。否則隨著產品的生長會衍生出更多權限點、更多角色，維護性變差，也極易出錯，這也是筆者所親身經歷的教訓。
2、從常說的功能權限、數據權限的角度來看
常說的功能權限也就是資源的容器（即頁面、目錄或菜單、Tab、按鈕）與行為（增刪改查等）的權限之和；數據權限及資源本身、行數據或個別列數據（字段）。
從各種權限模型及Oracle和Salesforce的經驗來看，更多情況下，功能權限配置在角色上，數據配置在用戶上。在Oracle中有專門的數據角色，但數據角色是直接配置給用戶的；在Salesforce的簡檔將一個用戶更基礎的對象及數據權限預先設置給用戶。
功能權限和數據權限一般設置盡量不要太細，能到菜單權限就不到頁面權限，能到頁面權限就不到按鈕權限；能到行數據權限就不到列數據權限；盡量避免不同用戶對相同字段有不同計算規則的情況。
↘好文推薦：
張小龍和他的人文產品主義 一篇看懂促銷系統的底層邏輯 深度 | SHEIN：長期主義的勝利點個“在看”吧
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的干货 | B端产品如何设计权限系统？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 工作七年后，我梳理了自己的产品工作流程
- 下一篇： 系统解读：权限设计指南