對權限系統的思考

7 評論 18776 瀏覽 86 收藏 15 分鐘

編輯導語:幾乎所有的管理后臺都會涉及到權限的設計,權限控制是管理后臺的重要功能,可以有效的提高系統的安全性,減少誤操作、數據泄漏等風險的發生;本文作者對權限系統進行了思考,我們一起來看一下。

最近入職了新公司,在申請后臺權限時,發現后臺沒做權限系統,開通賬號、分配權限必須要找運維;領導跟運維同事確定好要開通的權限,半小時之后,運維才完成賬號添加和權限分配。

沒有權限系統,給權限的分配和管理帶來了困難;回想過去從0到1搭建權限系統,和對權限系統進行了改造升級的經歷,我對權限系統有了更多的思考。

一、為什么要做權限控制?

每個企業都有自己的分工協作體系;不同崗位的員工,負責不同的工作內容;不屬于崗位職責范圍內的事情,員工通常不具有參與權和知情權。

  • 垂直電商企業,運營人員的負責維護商品信息、策劃和執行運營活動;客服人員負責處理客戶投訴、售后問題;財務人員負責處理收支款項、查看財務數據。
  • 運營人員不需要處理客戶投訴,也不需要給客戶打款,更不應該查看企業的月度財務報表。

如果每個崗位地員工都可以參與所有的工作、看到所有的信息,就會給企業的分工協作體系造成巨大沖擊,導致內部管理混亂。

  • 如果每一個員工都可以修改商品信息,商品價格可能隨意變化,導致大量的訂單糾紛和訂單流失。
  • 如果每一個員工都可以處理客戶投訴,就會因為與客戶溝通的語氣不好或方法不當,導致客戶產生更大的怨氣。
  • 如果每一個員工,都可以給客戶打款,企業對外打款就會失控,出現嚴重的資金管理問題。

更極端的情況是,員工利用自己“無限制的參與權和知情權”,進行違法的牟利活動,給企業帶來致命的損害。

如員工刪除數據,以掩蓋工作失誤,導致系統癱瘓;員工導出企業重要客戶資料,高價賣給競爭對手;員工向競爭對手泄漏企業關鍵業務數據。

企業通過對員工在系統中擁有的權限進行控制,讓不同崗位、層級的員工,只能使用和看到其職權范圍內的功能和信息,以確保分工協作體系能順暢運作,同時維護企業信息安全。

二、權限系統的適用場景

權限系統,是指對用戶在系統中可操作的功能、可查看數據范圍進行控制的功能模塊。

通俗的解釋是:權限系統通過設定不同的用戶角色,再將權限分配給各個角色,控制不同的用戶,能在系統中使用什么功能、查看什么信息,是企業對員工進行權限控制的工具。

  • 設定運營人員為“電商運營”角色,并分配商品管理、訂單管理、活動管理權限。
  • 權限系統允許了運營人員查看和編輯商品信息、訂單信息、活動信息,禁止了他們對財務等非崗位職責范圍內的功能操作和信息查看。

并非所有的系統都需要做權限控制——只有當系統功能足夠多、使用角色多樣時,才有對用戶進行權限控制的必要。

當更多崗位的工作內容被納入系統時,系統使用的角色也會從單個變成多個;為了避免員工的權限不受限帶來的信息安全問題,就需要分崗位進行權限控制;如上文提到的隨意修改數據、泄漏重要信息等。

而當系統功能單一、或使用角色單一時,意味著系統的用戶必須擁有該功能的權限,或他們的工作職責也相同,需要使用的功能也相同;此時,對用戶權限進行控制沒有太大意義。

三、功能權限

1. 功能權限的定義

根據員工的崗位職責,控制在系統中能使用的功能,是最常見的情況,也是權限控制最基礎、最主要的部分——限制用戶能使用的功能,稱之為功能權限控制。

功能權限取決于用戶在實際工作中,要負責的工作內容。而工作內容取決于用戶所在崗位的崗位職責;因此,功能權限取決于用戶的崗位職責,用戶有什么崗位職責,在系統上就應該對應擁有什么功能權限。

張三、李四是一家垂直電商公司的運營專員:張三負責維護商品信息,李四負責訂單跟進、活動策劃。

張三只擁有商品管理的功能權限,可以添加、修改商品信息;李四則擁有訂單管理、運營活動管理的功能權限,可以查看跟進訂單、配置運營活動。

2. 功能權限設計注意點

1)找出需要做特定權限控制的功能點每個模塊都是由很多個功能點構成的,但并非每一個功能點都需要對用戶做特定的權限控制。

那些依附于主功能,且即使不做控制,也不會帶來風險的基礎功能點,完全就可以使用默認授權,開放給所有用戶使用。

一個列表頁面,通常由數據查詢、數據列表、添加數據、刪除數據、分頁等功能點構成;其中,數據查詢、分頁功能,依附于數據列表。

若用戶擁有數據列表的權限,那么理應也擁有這2個功能的權限;反過來,如果用戶沒有數據列表的權限,即便用戶有這2個功能,也完全不會有任何風險。

我們要遵循“有獨立負責的崗位”和“操作時存在風險隱患”兩個標準,從大量的功能點中,找出少量但必需要做權限控制的功能點。

優惠券通常由運營人員管理;在優惠券列表中,添加優惠券功能,通常由運營崗位的員工來操作;添加優惠券時,一旦配置錯誤,可能會給公司帶來較大損失;優惠券列表中的添加優惠券功能,應該要做特定的權限控制,而不是默認授權給所有用戶。

而查看優惠券列表,沒有特定負責的崗位,也不存在風險隱患;因此,查看優惠券列表功能,可以默認授權給全部用戶,不需要做特定權限控制。

2)給權限準確命名在給用戶授權時,我們需要通過權限名稱理解該權限控制的內容;給權限命名的準確度,直接影響后期給用戶授權的效率;命名準確,能避免不必要的錯誤授權。

“分配權限”的權限,可能會授權給部門領導,他們不一定理解專業詞匯;可以很輕松地理解“添加優惠券”權限的含義,但無法理解什么是“獲取緩存”,即便知道“緩存”的含義,也無法確定是什么功能的緩存。

在給權限命名時,要注意以下3點:

  1. 避免研發視角的專用詞匯。如:緩存、隊列等;
  2. 使用動賓結構,描述完整。活動的詳細信息,應該命名為“查看活動詳情”,而不是簡寫為“查看”或“活動詳情”;
  3. 同一個功能模塊或頁面中的權限,不要重名;如推文列表中,查看推文在前端的展示效果和查看推文內容,不要都可以命名為“查看推文”。

3)對權限進行分組管理在對用戶進行功能權限分配時,需要從權限清單中找出需要授權的權限;若對權限進行合理的分組管理,就能使權限清單的管理和權限分配變得非常方便。

功能點歸屬于各個模塊、頁面,而功能權限是對功能點進行權限控制;與此同時,在給用戶授權時,我們很清楚地知道,這個功能點屬于某個模塊、某個頁面;因此,按其所屬模塊和頁面對其進行分組,是最自然的分組方式。

將“添加優惠券”權限,分組到“會員營銷-優惠券列表”中;在給運營人員分配“添加優惠券”權限時,可以直接通過該功能的路徑,在權限清單中快速找出,完成授權。

如果沒有分組,就只能從無數個功能權限中搜尋,效率極其低下。

四、數據權限

多個不同或相同崗位的員工都擁有同一個功能的權限,但該功能產生的數據,每個員工并不需要看到所有數據,而只能看到一部分。

限制用戶在查看某類數據時,能查看到的數據范圍,稱之為數據權限控制。

1. 為什么要做數據權限?

員工擁有數據查看權限的同時,也有對該數據保密的義務。如果數據不做數權限控制,會導致對應業務的核心數據,被有該功能權限的所有員工查看到。

1)同級別的普通員工互相看到對方的數據,引發員工之間的惡意競爭,增加內耗。

市場專員A搜集的潛在客戶信息,被B看到,并被B搶先開發為真實客戶,原本屬于A的收入,被計入了B的業績。

這嚴重打擊了A的工作積極性,還誘發了內部的惡意競爭。

2)下級員工越過自己的可見范圍,看到上級領導權限范圍內的數據,帶來不穩定因素。

下級員工看到了部門同事被審批通過的調薪申請,可能就會因此而心里不平衡,進而要求同等額度的調薪。

看到其他同事的績效評分,可能就會產生不公平感,進而導致對領導的不滿。

3)員工看到高管才有權限的關鍵數據,并泄露給外部。

普通員工看到企業各個收入源的具體營收數據,可能就會泄露到外部,給公司帶來不必要的損失。

數據權限控制,最重要的就是確保數據的私密性,避免因員工的數據權限超出權限范圍,給企業帶來不穩定因素和損失。

2. 根據崗位級別進行數據權限控制

數據權限主要取決于用戶的崗位級別。崗位級別越高,數據權限越大。

一般可以分為以下3種:

  1. 僅自己的數據:基層員工通常只能看到自己產生、或與自己相關的數據;
  2. 所在部門的數據:部門管理者可以看到本部門所有人的數據。根據組織架構的層級,還可以分為所在一級部門的數據、所在二級部門的數據等;
  3. 所有數據:更高級別的領導,能看到更大范圍的數據。

當月用戶一共下了1000個訂單,分屬于不同業務部門的員工。

運營專員李四只能看到屬于自己的100個訂單,李四的直屬領導能看到屬于本部門的600個訂單,公司領導能看到全部的1000個訂單。

五、總結

后臺系統的權限系統已經有成熟的解決方案,我們在參考成熟解決方案的同時,一定要先想清楚為什么要這么設計,做到知其然且知其所以然,才能設計出更好的產品方案。

#專欄作家#

誓博,微信公眾號:產品慎思錄。人人都是產品經理專欄作家。5年產品經驗,電商售后平臺后端產品負責人。

本文原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

專欄作家

誓博,微信公眾號:產品慎思錄。人人都是產品經理專欄作家。7年產品經驗,專注電商交易系統方向。

本文原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 有個問題想請教下,一個關于RBAC模型的問題 RBAC模型是根據“角色”去判斷權限的 但實際業務場景有不同用戶是同一“角色” 但是不同權限點的情況 如果用創建多個“角色”來解決的話 覺得不太靈活 想到了改變這個模型 把權限直接和“用戶”掛鉤 而不是“角色” 但這個模型就變了 會不會用戶更難理解

    來自北京 回復
    1. 我第一次評審方案的時候被開發帶偏,讓權限也可以跟角色直接關聯,但是上線后發現幾乎用不著,而且增加了代碼邏輯,最后我下決心砍掉了這個邏輯。結論就是,如果角色之外的個性化權限分配啥常態,你可以這么做,否則就不要浪費開發資源了。

      來自廣東 回復
  2. 我也需要一份可以嗎

    回復
  3. 是否可以轉載學習

    來自廣東 回復
    1. 可以。

      來自廣東 回復
  4. 可以提供一份數據權限的需求文檔學習一下嗎。。。

    來自北京 回復
    1. 可以通過訂閱號聯系我

      來自廣東 回復