對權(quán)限系統(tǒng)的思考

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

編輯導(dǎo)語:幾乎所有的管理后臺都會涉及到權(quán)限的設(shè)計,權(quán)限控制是管理后臺的重要功能,可以有效的提高系統(tǒng)的安全性,減少誤操作、數(shù)據(jù)泄漏等風(fēng)險的發(fā)生;本文作者對權(quán)限系統(tǒng)進(jìn)行了思考,我們一起來看一下。

最近入職了新公司,在申請后臺權(quán)限時,發(fā)現(xiàn)后臺沒做權(quán)限系統(tǒng),開通賬號、分配權(quán)限必須要找運維;領(lǐng)導(dǎo)跟運維同事確定好要開通的權(quán)限,半小時之后,運維才完成賬號添加和權(quán)限分配。

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

一、為什么要做權(quán)限控制?

每個企業(yè)都有自己的分工協(xié)作體系;不同崗位的員工,負(fù)責(zé)不同的工作內(nèi)容;不屬于崗位職責(zé)范圍內(nèi)的事情,員工通常不具有參與權(quán)和知情權(quán)。

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

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

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

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

如員工刪除數(shù)據(jù),以掩蓋工作失誤,導(dǎo)致系統(tǒng)癱瘓;員工導(dǎo)出企業(yè)重要客戶資料,高價賣給競爭對手;員工向競爭對手泄漏企業(yè)關(guān)鍵業(yè)務(wù)數(shù)據(jù)。

企業(yè)通過對員工在系統(tǒng)中擁有的權(quán)限進(jìn)行控制,讓不同崗位、層級的員工,只能使用和看到其職權(quán)范圍內(nèi)的功能和信息,以確保分工協(xié)作體系能順暢運作,同時維護(hù)企業(yè)信息安全。

二、權(quán)限系統(tǒng)的適用場景

權(quán)限系統(tǒng),是指對用戶在系統(tǒng)中可操作的功能、可查看數(shù)據(jù)范圍進(jìn)行控制的功能模塊。

通俗的解釋是:權(quán)限系統(tǒng)通過設(shè)定不同的用戶角色,再將權(quán)限分配給各個角色,控制不同的用戶,能在系統(tǒng)中使用什么功能、查看什么信息,是企業(yè)對員工進(jìn)行權(quán)限控制的工具。

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

并非所有的系統(tǒng)都需要做權(quán)限控制——只有當(dāng)系統(tǒng)功能足夠多、使用角色多樣時,才有對用戶進(jìn)行權(quán)限控制的必要。

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

而當(dāng)系統(tǒng)功能單一、或使用角色單一時,意味著系統(tǒng)的用戶必須擁有該功能的權(quán)限,或他們的工作職責(zé)也相同,需要使用的功能也相同;此時,對用戶權(quán)限進(jìn)行控制沒有太大意義。

三、功能權(quán)限

1. 功能權(quán)限的定義

根據(jù)員工的崗位職責(zé),控制在系統(tǒng)中能使用的功能,是最常見的情況,也是權(quán)限控制最基礎(chǔ)、最主要的部分——限制用戶能使用的功能,稱之為功能權(quán)限控制。

功能權(quán)限取決于用戶在實際工作中,要負(fù)責(zé)的工作內(nèi)容。而工作內(nèi)容取決于用戶所在崗位的崗位職責(zé);因此,功能權(quán)限取決于用戶的崗位職責(zé),用戶有什么崗位職責(zé),在系統(tǒng)上就應(yīng)該對應(yīng)擁有什么功能權(quán)限。

張三、李四是一家垂直電商公司的運營專員:張三負(fù)責(zé)維護(hù)商品信息,李四負(fù)責(zé)訂單跟進(jìn)、活動策劃。

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

2. 功能權(quán)限設(shè)計注意點

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

那些依附于主功能,且即使不做控制,也不會帶來風(fēng)險的基礎(chǔ)功能點,完全就可以使用默認(rèn)授權(quán),開放給所有用戶使用。

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

若用戶擁有數(shù)據(jù)列表的權(quán)限,那么理應(yīng)也擁有這2個功能的權(quán)限;反過來,如果用戶沒有數(shù)據(jù)列表的權(quán)限,即便用戶有這2個功能,也完全不會有任何風(fēng)險。

我們要遵循“有獨立負(fù)責(zé)的崗位”和“操作時存在風(fēng)險隱患”兩個標(biāo)準(zhǔn),從大量的功能點中,找出少量但必需要做權(quán)限控制的功能點。

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

而查看優(yōu)惠券列表,沒有特定負(fù)責(zé)的崗位,也不存在風(fēng)險隱患;因此,查看優(yōu)惠券列表功能,可以默認(rèn)授權(quán)給全部用戶,不需要做特定權(quán)限控制。

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

“分配權(quán)限”的權(quán)限,可能會授權(quán)給部門領(lǐng)導(dǎo),他們不一定理解專業(yè)詞匯;可以很輕松地理解“添加優(yōu)惠券”權(quán)限的含義,但無法理解什么是“獲取緩存”,即便知道“緩存”的含義,也無法確定是什么功能的緩存。

在給權(quán)限命名時,要注意以下3點:

  1. 避免研發(fā)視角的專用詞匯。如:緩存、隊列等;
  2. 使用動賓結(jié)構(gòu),描述完整?;顒拥脑敿?xì)信息,應(yīng)該命名為“查看活動詳情”,而不是簡寫為“查看”或“活動詳情”;
  3. 同一個功能模塊或頁面中的權(quán)限,不要重名;如推文列表中,查看推文在前端的展示效果和查看推文內(nèi)容,不要都可以命名為“查看推文”。

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

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

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

如果沒有分組,就只能從無數(shù)個功能權(quán)限中搜尋,效率極其低下。

四、數(shù)據(jù)權(quán)限

多個不同或相同崗位的員工都擁有同一個功能的權(quán)限,但該功能產(chǎn)生的數(shù)據(jù),每個員工并不需要看到所有數(shù)據(jù),而只能看到一部分。

限制用戶在查看某類數(shù)據(jù)時,能查看到的數(shù)據(jù)范圍,稱之為數(shù)據(jù)權(quán)限控制。

1. 為什么要做數(shù)據(jù)權(quán)限?

員工擁有數(shù)據(jù)查看權(quán)限的同時,也有對該數(shù)據(jù)保密的義務(wù)。如果數(shù)據(jù)不做數(shù)權(quán)限控制,會導(dǎo)致對應(yīng)業(yè)務(wù)的核心數(shù)據(jù),被有該功能權(quán)限的所有員工查看到。

1)同級別的普通員工互相看到對方的數(shù)據(jù),引發(fā)員工之間的惡意競爭,增加內(nèi)耗。

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

這嚴(yán)重打擊了A的工作積極性,還誘發(fā)了內(nèi)部的惡意競爭。

2)下級員工越過自己的可見范圍,看到上級領(lǐng)導(dǎo)權(quán)限范圍內(nèi)的數(shù)據(jù),帶來不穩(wěn)定因素。

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

看到其他同事的績效評分,可能就會產(chǎn)生不公平感,進(jìn)而導(dǎo)致對領(lǐng)導(dǎo)的不滿。

3)員工看到高管才有權(quán)限的關(guān)鍵數(shù)據(jù),并泄露給外部。

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

數(shù)據(jù)權(quán)限控制,最重要的就是確保數(shù)據(jù)的私密性,避免因員工的數(shù)據(jù)權(quán)限超出權(quán)限范圍,給企業(yè)帶來不穩(wěn)定因素和損失。

2. 根據(jù)崗位級別進(jìn)行數(shù)據(jù)權(quán)限控制

數(shù)據(jù)權(quán)限主要取決于用戶的崗位級別。崗位級別越高,數(shù)據(jù)權(quán)限越大。

一般可以分為以下3種:

  1. 僅自己的數(shù)據(jù):基層員工通常只能看到自己產(chǎn)生、或與自己相關(guān)的數(shù)據(jù);
  2. 所在部門的數(shù)據(jù):部門管理者可以看到本部門所有人的數(shù)據(jù)。根據(jù)組織架構(gòu)的層級,還可以分為所在一級部門的數(shù)據(jù)、所在二級部門的數(shù)據(jù)等;
  3. 所有數(shù)據(jù):更高級別的領(lǐng)導(dǎo),能看到更大范圍的數(shù)據(jù)。

當(dāng)月用戶一共下了1000個訂單,分屬于不同業(yè)務(wù)部門的員工。

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

五、總結(jié)

后臺系統(tǒng)的權(quán)限系統(tǒng)已經(jīng)有成熟的解決方案,我們在參考成熟解決方案的同時,一定要先想清楚為什么要這么設(shè)計,做到知其然且知其所以然,才能設(shè)計出更好的產(chǎn)品方案。

#專欄作家#

誓博,微信公眾號:產(chǎn)品慎思錄。人人都是產(chǎn)品經(jīng)理專欄作家。5年產(chǎn)品經(jīng)驗,電商售后平臺后端產(chǎn)品負(fù)責(zé)人。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

專欄作家

誓博,微信公眾號:產(chǎn)品慎思錄。人人都是產(chǎn)品經(jīng)理專欄作家。7年產(chǎn)品經(jīng)驗,專注電商交易系統(tǒng)方向。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自 Unsplash,基于 CC0 協(xié)議。

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

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

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

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

    回復(fù)
  3. 是否可以轉(zhuǎn)載學(xué)習(xí)

    來自廣東 回復(fù)
    1. 可以。

      來自廣東 回復(fù)
  4. 可以提供一份數(shù)據(jù)權(quán)限的需求文檔學(xué)習(xí)一下嗎。。。

    來自北京 回復(fù)
    1. 可以通過訂閱號聯(lián)系我

      來自廣東 回復(fù)