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

32 評論 38885 瀏覽 384 收藏 15 分鐘

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

一、什么是用戶權限系統

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

現有的權限系統通?;赗BAC(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 角色類型

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

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

至于系統應該選擇用什么樣的方式定義權限,根據產品的組織架構,和性質來劃分:

  1. 簡單類型產品,沒有工作流:管理角色和業務角色重合,根據需求做到菜單級別自定義授權,或功能級別自定義授權即可;
  2. 有工作流,但是組織架構較為簡單:管理角色自定義到菜單或功能級別,業務角色根據業務流梳理業務角色內置即可;
  3. 復雜組織架構,復雜業務流:管理角色做到應用級別授權,管理員由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協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的不錯,看的很爽!點贊了!

    回復
  2. 您好,我恰好在找具有saas 產品經驗及對權限系統產品設計有一定經驗的個人或團隊合作一些需求,看了您的文章很有啟發,可以進一步聊聊嗎?

    來自美國 回復
  3. 作者對于數據權限的控制有什么心得嚒

    來自江蘇 回復
  4. 怎么能聯系到作者 有事情咨詢

    來自北京 回復
  5. 有個問題想討論一下,我們做assa產品,目前面臨一個問題,就是針對不同企業的定制,產品就是不斷的加功能,那導致系統越來越繁雜,怎么樣解決這個問題呢?大神能不能給點幫助!

    回復
    1. 不同企業的需求有通用的有不同的,做通用版+專版,若還有特殊需求做定制版加錢就行。

      來自廣東 回復
    2. 跟老板說做paas+saas吧!我們目前也遇到同樣的問題,可是老板拒絕了我的想法??

      回復
  6. 感謝分享

    來自陜西 回復
  7. 寫的比較清楚,希望下次舉例多些,移動指數3顆星,感覺每個小結想講清楚都要一篇文章。

    回復
  8. 好文章,轉成腦圖了

    來自湖南 回復
    1. 可以分享一下嗎?

      來自馬來西亞 回復
  9. 請問微信號正確嗎?顯示用戶不存在

    回復
  10. 這是我見過的,從整體層面上把權限講的比較透徹的文章了。希望有更多權限的細節方面可以分享,大家交流下

    來自北京 回復
    1. 謝謝,共同學習,細節上就要根據具體的業務和優先級來呢

      回復
  11. 請問saas產品有哪些形態,或者說市面上有哪些saas產品呢

    回復
    1. SaaS是軟件即服務的意思,可以簡單的理解成以公有云方式提供的軟件服務

      回復
  12. 一個權限就可以寫出如此細致的文稿,佩服

    來自浙江 回復
    1. 謝謝,相互學習

      來自湖北 回復
  13. B端產品,角色與權限相輔相成。能舉例一下通用的角色與權限配置么,讓我們更直觀點

    回復
    1. 文中有用釘釘的實際案例進行舉例,具體是哪里還有疑問呢

      回復
  14. 從創建方式的角度劃分,一種是內置角色,一種是自定義角色。通常管理角色通過自定義的方式創建,業務角色通過內置的方式創建。
    是不是說反了? 內置角色通常是系統自帶的,應該是屬于管理角色,自定義角色通常是后期增改刪查的業務角色吧?
    PS:干貨文,制成導圖了,期待更多分享。

    來自福建 回復
    1. 并沒有說反哦,后文中有說到管理角色和業務角色的定義

      回復
  15. 作為一名交互設計,除了會畫圖之外,更重要是能在需求層面和產品經理保持同步。希望能看到更多產品經理在前四個層級中與交互的合作點的文章!

    回復
    1. 嗯,謝謝

      回復
  16. 總結的很好??

    回復
    1. 嗯,謝謝,相互學習,共同進步

      回復
  17. 可以把這種權限配置講的更深一些;如,怎么搭配設計更靈活;

    回復
    1. 具體是什么呢,如果想了解的更清楚的話,建議直接看一下釘釘后臺會有更深的體會

      來自湖北 回復
  18. 云計算沒多少人

    回復
    1. 嗯 公有云都是大廠,私有云倒是有些小廠家

      來自湖北 回復
  19. 涉及B端產品的知識體系還有介紹的嗎?謝謝!

    來自浙江 回復
    1. 想了解什么呢

      來自湖北 回復