起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識復盤 | B端產品中，如何構建權限體系？
不管是C端還是B端產品，“權限體系”幾乎存在于所有產品中。那么在B端，如何構建一套“權限體系”以滿足業務需求？以下，筆者將詳細講述。
前段時間，筆者在一款B端數據產品中，基于RBAC模型構建了一套重用性極佳的“權限體系”，上線后得到一致好評。不僅降低了運維成本，更是對產品的傳播擴散有極大的催化作用，并且這套“權限體系”被借鑒應用在內部數個項目當中。
一、什么是“權限體系”
在C端，一般會通過會員類型（等級）來區分不同的用戶權限。
例如：在“蘇寧易購”，如果你是Super會員，那么就會得到2%的返利、運費券、PP體育會員等普通用戶無法享受的權益，這就是通過會員體系（V1、V2、V3、V4、Super）構建了一套權限體系。
與C端不同，B端產品的“權限體系”一般不采用會員類型（等級）的概念來構建，而是使用“普通用戶、管理員”這種角色概念。
這就是RBAC模型：基于角色的權限訪問控制（Role-Based Access Control）。
RBAC的特點就是：通過創建不同的角色（每種角色關聯不同的權限），通過賦予用戶不同的角色，從而使得用戶獲得對應角色的權限，建立用戶和權限的關聯。
這種模型的優點就是：可以通過動態調整角色的權限，便捷地對用戶進行批量的權限變更、遷移、回收。
二、構建“權限體系”的目的
有“數據”的地方就有江湖。
作為互聯網企業中的核心資產，“數據”經過采集、清洗、存儲，就是為了最終孵化出經營性的數據產品，為業務的發展提供引擎。
筆者本次參與的是就是一款B端的數據產品，用戶群體是內部的員工。根據員工在公司內部的身份，區分出查看對應數據的權限，也就是哪些數據能看、哪些數據不能看。
因此，構建“權限體系”的目的主要有：
- 隨著商業競爭的升級，要避免給無關的員工有使用本數據產品的權限，防止數據泄漏；
- 雖然對員工有保密意識培訓，但需防患于未然，盡量保持每個員工的最小權限，讓權限與工作職責掛鉤；
- 作為平臺性的數據產品，需要把一部分權限下放，以保證用戶能參與產品的內容建設、運維及傳播。
三、建立“權限體系”模型
根據RBAC模型，將權限體系的建模對象分為三種：用戶、角色、權限。
一般的產品針對以上三種對象進行建模也就可以了，但如果是平臺性的數據產品，還需要在“用戶”和“角色”之間引入一個對象：數據集合。
“數據集合”就是將數據根據一定規律劃分成若干個集合，同種規則下每個數據集合之間相互獨立。引入“數據集合”的好處在于：
- 用戶在一個“數據集合”中選擇一種“角色”，那么在不同“數據集合”中就可以擁有不同的角色，同時用戶所擁有這個“角色”的權限也被圈定在特定的“數據集合”內；
- 權限體系的本質是對用戶身份做控制，引入“數據集合”后就可以將數據來源也作為一種對象進行控制，在管理層面更加細致、靈活；
用戶：每個員工就是一名用戶，可以與工號進行掛鉤，從而建立最小粒度的“用戶”對象，并且可以確保具有唯一性。
數據集合：本次B端數據產品作為一個平臺，每個接入的產品（例如：蘇寧易購、蘇寧金融等等）就是“數據集合”。由于每個產品互相獨立，因此可以按照產品進行數據集合的劃分，即一個產品就是一個數據集合。
角色：根據對用群體調研和產品目前所處的階段，設定了四種角色：普通用戶、產品管理員、平臺管理員、超級管理員。
權限：根據MECE分析法（Mutually Exclusive Collectively Exhaustive），將權限劃分為“相互獨立”的元素，這些權限元素可以按照角色的劃分組成不同的集合，這些集合就是對應角色的權限。
Q：如何將權限劃分成“相互獨立”的元素？
A：首先將產品內每個功能模塊都一一列舉出來，然后針對每個功能模塊分為三種權限：可讀、不可讀、可寫。如果需要繼續細化，針對“可寫”又可細分為“增、刪、改、查”四種。
可以制作一個Excel表格，角色、功能分別是其中的X、Y軸。針對每個功能，將每個角色擁有的權限進行標記，這樣就可以形成一份清晰的“角色-權限”對照表。
四、總結
筆者所構建的權限體系是在RBAC模型的基礎上引入“數據集合”作為用戶和角色之間的對象，因此可以將其定義為：基于數據集合及角色的權限訪問控制模型。
相比于RBAC，該模型的優勢在于：能夠讓同一用戶在多場景中無感知的切換角色。
原因如下：
- 一個“數據集合”就是一個場景，多個“數據集合”就是多個場景；
- 在單一場景下用戶的角色是固定、唯一的，但在多場景下用戶的角色會隨著場景的變化而變化；
- 在“用戶”和“角色”之間引入“數據集合”，就是為了將用戶的角色與場景進行綁定，這樣在多場景環境中用戶的角色就會隨著場景變化而自動切換，用戶能更為通暢的使用產品。
作者：胡欣欣，公眾號：吹拉彈唱大師（ID：cltcds）
本文由@吹拉彈唱大師 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash, 基于CC0協議
岳不群和金庸沒看懂，他們沒有對應的數據集合么？
這個意思應該是這倆角色的數據集合是全部，最大
那我是不是可以理解我，如果我被賦予了某個“數據集合”的權限，那么對應數據集合下的“角色”和“權限”我都有了，并且我可以不用進行角色的切換？
應該是a數據集合的b角色，那么a數據集合中b角色以下的權限都有了，好像說了個寂寞??
請教一下，組織機構是否可以理解為數據集合
不可以吧，這個是用戶自身的標簽
我理解是可以的，相當于一個虛擬的組織架構，每一個虛擬的組織架構都代表一個數據集合，對應的角色關聯了這個組織架構就類似這個角色（實際為角色下的功能權限）賦予了這個組織架構下的所有數據權限
理論上是可以的，組織機構也是一種場景，管理的人員的范圍，完全是可以作為數據集合理解
針對“可寫”又可細分為“增、刪、改、查”四種。
“查”算是可寫嗎？一直因為查是可讀。
你的理解沒問題，在真實場景內，查這個功能也可以算作是“可讀”。我這里只是籠統的將操作類功能都歸為“可寫”。
可讀和不可讀應該是2選1吧，要么可讀，要么不可讀，不能兩項都不選吧？
還有第三種“可寫”，里面包括了可讀。
用戶：角色組-角色，權限組-權限，用戶組-用戶（產品組-產品），笛卡爾積模型
可以映射過去