對權限系統的思考

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

對權限系統的思考

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

沒有權限系統,給權限的分配和管理帶來了困難;回想過去從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協議。

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 3618 字。

轉載請註明: 對權限系統的思考 - 楠木軒