ToB產品設計:用戶權限系統解析

文章以產品經理的角度思考，對權限系統的核心進行剖析，抽象出權限系統中的核心要素，並結合釘釘的一些做法對權限系統進行介紹。

一、什麼是用戶權限系統

權限管理系統是任何一個企業管理系統內都必備也是非常重要的模塊，對權限系統的分析和規劃也是一個B端產品經理必備的能力。

現有的權限系統通常基於RBAC（Role-Based Access Control）的思想設計，角色和權限綁定、角色和用戶之間的鬆耦合、多對多的關係來實現授權和授權的快速變更，從而控制用戶對系統的功能使用和數據訪問權限，以達到企業或機構安全管控的目的。

和用戶權限系統密切相關的還有兩個模塊：帳號體系和組織架構。

帳號體系，會負責用戶帳號註冊、登錄驗證、密碼找回等功能，其中登錄驗證（即準入權限）和權限系統有著密切的關係。

組織架構，即公司的行政組織架構。對於大型企業，可能會有總公司、大區、分公司、辦事處、部門等各個不同級別的機構，機構之間可能縱橫交錯，彼此有業務往來，較為複雜；對於小微企業或流程相對簡單的業務，通常只有公司，部門兩個級別，較為簡單。面對複雜的大型企業組織架構，權限系統的設計和實現複雜性會成倍的增加。

阿里釘釘是很多人都在使用，並且也是複雜型的後臺管理系統，本文會結合釘釘的一些做法對權限系統進行介紹。

二、規劃一個權限系統的核心2.1 核心問題

權限系統要實現的核心目標是對企業業務的安全管控，企業業務對安全性要求的級別，實現安全管控的粒度，是產品經理需要解決的核心問題，依賴產品經理擁有一定的行業經驗和對用戶實際業務流程、操作有較深的認識。我們使用產品經理通用的思考模型「角色→場景→任務」來梳理這一問題。

2.2 角色

B端產品的用戶畫像和C端產品不同。

C端產品的用戶畫像有梁寧提出的小閒、小明、小笨這種具備明顯性格特徵、行為特徵的用戶畫像。

而B端產品是強業務、崗位職責驅動，企業組織架構下，具備不同級別不同職責的崗位，就是B端產品的用戶畫像。

因此產品經理弄清楚其行業客戶的組織架構下的職位設置、職級設置、職責設置之間的共性即可。B端產品經理對職位、職級、職責的理解，還有很多值的探討的地方，在此不做詳述。

釘釘的角色按照職務、崗位進行設置

2.3 場景

場景即用戶使用產品的時間和空間。不同時間不同空間下，意味著用戶可能會使用不同的終端設備，不同的網絡情況，執行不同的任務，有著不一樣的行為習慣等等。

C端產品會非常重視用戶場景不同而後殘生的不同需求，比如一款音樂APP：晨間地鐵上，伏案工作中，孤枕難眠時都會有不同的用戶情緒和需求。

作為B端產品，只需重考慮以下兩點：一是PC端和移動端上不同場景下的不同權限；二是如果業務操作中涉及工作地點的變更，需要考慮一些數據安全性。

2.4 任務

在B端組織架構下，每個角色要執行的任務是由職責完全決定的，因此理解角色職責，就可以掌握用戶需要在產品上完成的任務。

比如企業某部門leader的職責是負責某項業務銷售數據的增長，那麼經常統計信息，查看報表任務會由他們完成，按照角色梳理即可。

在做角色任務梳理的時候可以從可以做什麼、不可以做什麼、可以向系統提交哪些數據、可以向系統查詢哪些數據、可操作的數據範圍幾個緯度進行入手。

2.5 結論

通過對角色、場景、任務的梳理後，根據共性抽象出權限系統中的核心要素，角色類型、準入權限、使用權限、數據權限。

同時，在大型組織架構以及大型平臺下，還需抽象出組織權限，應用權限方便進行細粒度的授權控制。

三、角色3.1 角色類型

角色從使用的角度劃分，一種是管理角色，一種是業務角色。管理角色是針對平臺的管理用戶，用來劃分管理的範圍。業務角色是員工在系統中執行各種實際工作流時的角色。

從創建方式的角度劃分，一種是內置角色，一種是自定義角色。通常管理角色通過自定義的方式創建，業務角色通過內置的方式創建。

至於系統應該選擇用什麼樣的方式定義權限，根據產品的組織架構，和性質來劃分：

簡單類型產品，沒有工作流：管理角色和業務角色重合，根據需求做到菜單級別自定義授權，或功能級別自定義授權即可；有工作流，但是組織架構較為簡單：管理角色自定義到菜單或功能級別，業務角色根據業務流梳理業務角色內置即可；複雜組織架構，複雜業務流：管理角色做到應用級別授權，管理員由IT運維人員擔任，他們通常不了解業務，因此菜單或功能級別的權限劃分給業務角色，業務角色根據工作流引擎內置。由於複雜業務流情況下，系統一定會有一套自定義工作流的引擎，用來隨時創建和變更工作流程，因此業務角色通常是各個崗位的崗位名稱即可。除此之外，可能還要處理上下級權限繼承的關係。

創建變更流程都會用到的業務角色

3.2 管理角色

超級管理員

超級管理員角色是擁有最高權限的角色，通常內置一個admin用戶，或者是創建某個管理實體的用戶。以釘釘為例，對企業進行註冊和創建的用戶即為超級管理員。超級管理員對應的用戶只有一個，整個系統歸屬於它，允許變更該用戶，不允許刪除角色。

普通管理員

所有的自定義管理員為普通管理員，其管理權限配置需配置組織部門權限和應用管理權限，組織部門權限是其管理的數據範圍，如XX子公司、銷售部，應用權限即各個應用。

在釘釘上創建子管理員

3.3 業務角色

業務角色的權限體現在工作流中，隨著任務在不同崗位之間流轉，不同崗位看到的內容完全一樣，只是處理的表單不一樣。

比如請假審批：一張請假單先通過小組leader到部門leader到人事，數據一致，只是數據的狀態在發生改變。根據職位來配置業務角色即可。

一般來說，系統部署好之後，業務角色會完全初始化好，變更的話需要通過工作流引擎中添加，或者通過添加代碼的方式增加。通常企業的職位、職級設置都相似，變更的情況較少發生。

3.4 組織權限

組織架構創建之後，會天然的體現組織權限，表現為數據的歸屬和訪問範圍，無需創建角色。組織權限是自動賦予在部門級別上的權限。

比如銷售部門擁有銷售數據提交、查看、分析報表查看、下載的權限，那麼一個用戶創建到銷售部門下後，會自動繼承該部門的組織權限，再根據該用戶的具體業務角色在確定其具體可訪問的數據。

比如老王是A部門的，那麼老王只能訪問A部門的數據，不能訪問隔壁B部門的數據。老王的業務角色是普通銷售員，就只能查看自己的數據，而老王的領導老萬是部門經理，就可以查看銷售部所有人員的數據。這便是組織權限的具體體現。

四、權限4.1 準入權限

準入權限是對用戶帳號的登錄限制，原則上屬於用戶帳號體系，和角色關聯不大。通常會有如下功能需求：

進入限制

直接限制帳號是否擁有登入平臺，或登入某個應用的權限，比如普通員工無法進入人事管理應用。

二次驗證

二次驗證是在識別到用戶的登錄地點、登錄設備、登錄客戶端變更之後的二次驗證，做的比較好的如微信的二次登錄驗證，支持驗證碼，邀請好友驗證等多種方式。

時間限制

僅允許在規定時間之前使用帳號，通常用於發放試用帳號之類的臨時帳號。

設備限制

包括特定設備限制，或者設備數量限制。如果是高級別的安全性需求，登錄設備可能需要先進行安全登記，才允許登錄。設備數量限制通常是作為付費增值服務，比如印象筆記，免費用戶最多只允許在兩個設備上同時使用。

客戶端限制

客戶端限制通常使用的較少，BS應用使用任何瀏覽器都可以登錄。筆者僅在企業郵箱中見過類似限制，Google企業郵箱如果需要使用foxmail類的第三方郵件客戶端進行收發郵件，僅知道帳號密碼是不夠的，還需要從Google Mail後臺，生成一個實時動態密碼進行驗證才行。

地理位置限制

登錄的地理位置限制，比如只能在工廠範圍內。

網絡限制

網絡限制通常是企業的內網和外網限制，應用和數據只能通過企業內網訪問。在一些公安、軍工類安全級別高的場景下，設備被人為接入外網後，還會立即發出警報。

4.2 使用權限

用戶的使用權限由其組織權限、業務角色、數據狀態共同決定，通常為增、刪、改、查。不做過多贅述。

另外用戶角色可執行的任務，通常是可以訪問的系統頁面，在做權限系統時，除了要求用戶只能訪問被分配權限的頁面，在用戶通過其他方式，如直接訪問url時，需要能夠進行阻止。

4.3 數據權限

數據權限有兩個重要的識別方式，數據狀態和數據歸屬。

數據狀態

根據工作流引擎或者業務流程確定，一張請假單可能會有草稿、待審批、審批通過、審批不通過的各種數據狀態，不同的數據狀態根據工作流的配置自動在各個業務角色間流轉。不同數據狀態下，不同角色擁有不同的操作。

數據歸屬

數據歸屬即為創建這個數據的人或擁有該數據的部門，通常情況下數據的創建人永遠擁有該數據的可見的權限，比如我提交的請假單，整個流程中，我都可以隨時查看該數據及數據狀態的變更。歷史記錄的查看也依賴創建人擁有數據權限。也有一些特殊情況，比如數據歸檔之後，對於創建人，可能就不可見了。

One more thing

本文筆者以釘釘進行舉例，實際上所有的功能權限都是釘釘租戶權限，租戶權限是什麼意思呢？

釘釘是一個面向企業的SaaS服務系統，那麼所有的客戶（單個獨立註冊的企業）在釘釘系統裡面都屬於釘釘的租戶。

在釘釘內部，還有另外一個租戶管理系統，用以管理所有已註冊租戶，比如對租戶進行授權，租戶行為數據分析等等。租戶管理系統內的用戶權限也可按照本文的模式進行產品設計。

 

作者：一直往北方開（微信號：z445388180），多年SaaS產品、購物中心集團CRM、自主創業、雲計算虛擬化行業產品經驗，文章總結均為落地型實戰型產品經驗，熱愛閱讀，持續學習者、思考者

本文由 @一直往北方開 原創發布於人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基於CC0協議