設計實例:如何以“用戶”為單位的進行權限設計(一)

19 評論 35560 瀏覽 142 收藏 10 分鐘

權限設計可以很好地對保證公司信息系統(tǒng)的安全。權限設計的方式主要有:以“用戶”為單位、以“權限”為單位和以“用戶”與“權限”結合的權限設計方式。這篇文章針對以“用戶”為單位的權限設計方式進行展開解讀。

最近公司發(fā)生一件大事:公司一員工,竊取網(wǎng)站后臺管理功能資源以及網(wǎng)站銷售額等數(shù)據(jù),事后發(fā)現(xiàn)是敵對公司派人有意所為。電視劇場景在現(xiàn)實重演,有些吃驚,為防止此類事情再次發(fā)生,臨危受命,針對權限管理進行重構。

為何有權限設計的需求

禁止非法用戶盜取資源

訪問用戶的權限檢測可以通過客戶端實現(xiàn)或通過客戶端+服務器檢測實現(xiàn),每一臺計算機具備瀏覽器,如果不建立一個完整的權限檢測,那么一個非法用戶可以輕而易舉通過瀏覽器訪問Web應用項目中的所有功能資源。

保證數(shù)據(jù)的保密性

公司內(nèi)部員工的角色不同,自然對于系統(tǒng)使用功能的權限不一樣,關于機密數(shù)據(jù)的列表菜單是不能允許讓所有人進行訪問的。

比如:一個電商網(wǎng)站的銷售額等報表數(shù)據(jù),是不允許公司內(nèi)所有員工都進行查閱的,有針對地進行管理。

權限設計的方式有哪些?

  • 以“用戶”為單位的權限設計
  • 以“權限”為單位的權限設計
  • 以“用戶”與“權限”結合的權限設計

針對以上三種類型,結合業(yè)務場景以及具體設計方式,詳細進行講解。

以“用戶”為單位的權限設計

適用的業(yè)務場景

當使用該系統(tǒng)的人之中,存在很多擁有同一類權限的人,將擁有同一類權限的人定義為“角色”或者“部門”等其他稱號,而這個集合的稱號就是定義權限的集合體。

舉例:在公司內(nèi)部,運營部人員擁有查詢報表的權限,客服部人員擁有審核商品評論的權限,而運營部人員和客服部人員人數(shù)眾多,且權限一致,那么以“用戶”為單位的權限設計更符合業(yè)務需求。

如何進行設計?

1、信息架構圖

用戶:添加用戶過程中,分配至某一個部門,該部門擁有的權限就是該用戶的權限

部門:添加部門時,除填寫部門基本資料外,對該部門定義具體權限

2、業(yè)務流程圖

具體流程:添加部門,給部門設置權限,添加用戶時,設置所屬部門,部門的權限即是該用戶的權限。

3、具體原型圖設計

添加部門:

添加用戶:

由于公司內(nèi)部資料的保密性,我純手打兩分鐘,擼了個最簡單的示意圖進行參照,其設計方式相信一看即懂。

關于此方法的權限設計疑問

1.權限的類型有哪些?

權限分為菜單功能和特殊項區(qū)分權限。

菜單功能權限:為一個用戶設置權限,該用戶所屬部門為運營部,運營部的權限設置中,勾選報表管理,但是未勾選導出報表。

那么該用戶進入該系統(tǒng),能看到菜單頁,但是無法看到導出報表的按鈕,因為沒有改權限。

特殊項區(qū)分權限:有這樣一個業(yè)務場景,該后臺系統(tǒng)管理幾個電商網(wǎng)站,我不希望A網(wǎng)站的運營人員看到B網(wǎng)站的銷售額數(shù)據(jù),同理,B網(wǎng)站的運營人員看不到A網(wǎng)站的銷售額數(shù)據(jù),似乎菜單功能權限不能為我們解決此問題。

那么,我們分兩步走:

1、在給部門設置權限的頁面,加上特殊項區(qū)分權限。

2、找出與此特殊項區(qū)分權限所有相關的頁面,進行展示并進行標記。

以上為報表詳情頁,如果該用戶所在部門的權限中,勾選了A站、B站以及C站的權限,那么在報表詳情頁中的搜索選項,出現(xiàn)的站點為權限勾選的網(wǎng)站,如果未勾選任何網(wǎng)站,那么相應地,報表詳情頁中查看不到任何網(wǎng)站的數(shù)據(jù)。

需要記住一點的是,涉及到特殊項區(qū)分權限的頁面很多,產(chǎn)品經(jīng)理需要全部找出,并進行合理的設計展示,完善方案后給到開發(fā),進行代碼的實現(xiàn)。

3.當遇到一個部門內(nèi)部,必須針對不同的人設置不一樣的權限,如何處理?

業(yè)務場景:一個后臺管理系統(tǒng)管理眾多電商網(wǎng)站的評論,客服部人員內(nèi)部進行分工,1號客服負責A網(wǎng)站的評論審核,2號客服負責B網(wǎng)站的評論審核,3號客服負責C網(wǎng)站的評論審核,那么問題來了。

1號、2號、3號客服同屬于一個部門,他們所擁有的權限不一樣,你如何進行處理?

大部分人會想到一個解決方案:那就幫2號、3號客服再次新建一個部門,一個部門一個權限可以解決。

但是,這是有弊端的:

  • 試想這種業(yè)務場景足夠多的話,那么會造成的結果是:你的部門列表會有一堆重復的部門,部門之間也無法進行區(qū)分,顯得頁面非常亂。
  • 有些重復的部門下只有一兩個人,非常不利于進行管理

此路不通,怎么解決?

方法是制造一個二級部門的概念,部門太大需要在小組內(nèi)再區(qū)分,就增加三級部門的概念。

三級部門屬于二級部門,二級部門屬于一級部門,針對現(xiàn)實的狀況進行區(qū)分。

在添加部門時,選擇一級部門時,如圖所示:

選擇二級部門時,如果所示:

選擇不一樣的部門類型,進行添加,針對部門進行權限設置,也更方便解決會有重復部門以及頁面會很亂的情況。

一個部門內(nèi)部,必須針對不同的人設置不一樣的權限,此類場景根據(jù)頻次進行處理,有以下類型:

  • 此類場景頻次極少,直接添加新部門,設置權限
  • 此類場景頻次較多,增加二級部門或三級部門的方式,設置權限
  • 此類場景頻次特別多,走個極端,一個團隊一個人擁有一種權限,怎么辦???

第三種業(yè)務場景中在現(xiàn)實中是大量存在的,特別是國家機關的工作系統(tǒng),保密性是非常有必要的,如果我們使用以“用戶”為單位的權限設計,其中涉及的部門根本毫無作用,一個人一個部門,這是非常可笑的,那么我們應該如何進行處理此種情況?

在下一篇文章中,將詳細介紹以“權限”為單位的權限設計,歡迎閱讀~

#專欄作家#

不羈,微信號:hujianfeng1234,人人都是產(chǎn)品經(jīng)理專欄作家,對于電商以及社交領域產(chǎn)品有深入了解,重業(yè)務邏輯,喜深入思考,歡迎交流~

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

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 作者只是分享了一下基礎的權限設置,不知道為什么會有這么多噴子,在更早的時候沒有RBAC模型的時候,用的的確是這個模型,只是現(xiàn)在權限設置更偏業(yè)務了,所以這個慢慢變得不再適用。

    來自浙江 回復
  2. 兄弟,你這篇文章把我看糊涂了,按照你的觀點:是在部門上授權,歸屬于這個部門下的所有用戶都具有這個權限,如果同一個部門下的用戶有不同的權限,那就再建下級部門,給下級部門授權。
    【首先】我要對看這篇文章的朋友們說一聲:這種權限設計可能對這個公司的用戶適用,在借鑒的時候,切莫拿來主義。
    【其次】我要對作者說:一個企業(yè)的行政組織(包含部門)都是固定的,這屬于企業(yè)HR管理的一部分,不會因為你權限的設置而變更,部門不會隨便增加改變的,其次,組織是和業(yè)務有很大關系的,不僅僅只是關聯(lián)權限,你這種設計并沒考慮過企業(yè)內(nèi)部審批、業(yè)務匯報關系、人員考勤等和業(yè)務相關事情,組織一旦有變動就會產(chǎn)生很大的影響。
    【建議】如果沒有非常成熟的權限模型,建議使用RBAC或在RBAC基礎上改良優(yōu)化,建立更嚴格的權限體系,不要緊緊地將權限綁定在組織上。

    來自北京 回復
  3. 難道RBAC權限模型不能解決你的問題嗎?

    來自廣東 回復
    1. RBAC模型很不錯,我會深入再研究一下,感謝你的建議~

      來自廣東 回復
  4. 這小伙,有點誤人子弟。。。

    來自北京 回復
    1. 贊同

      來自上海 回復
    2. 不要就知道噴人,寫篇文章來教育我,真的求求你了~

      來自廣東 回復
    3. 分享東西,注定是要有人噴的,但是這套邏輯是解決了我公司遇到的問題,你們看了,認為與你們公司遇到的問題不適用,也是正常,你生搬硬套,就說我誤人子弟,有本事寫篇牛逼文章出來教育我啊,不行就別噴人,好好說話,真TMD受不了這種氛圍。

      來自廣東 回復
    4. 哪里都有噴子,千萬別因為他們而影響你的分享熱情。就像你做的那樣,適當?shù)幕負粼偌由蠠o視,就足夠了。每個瀏覽者的瀏覽目的、需求階段都不一樣,有不一樣的看法也是正常。你的文章對現(xiàn)階段的我就挺有幫助的,謝謝你。

      來自上海 回復
  5. 1、權限和部門沒有關系吧,一個部門不同的人有不同權限,或多項權限疊加情況,一個人一般屬于一個部門或交叉虛擬組。
    2、一般設置角色+個人權限組合,角色自可以定義設置很多種,并賦予對應權限,人員權限分級(比如最大權限主管,系統(tǒng)主管,具有全產(chǎn)品使用權限,一般人員權限。被授予的權限:可以細化到每個模塊,單據(jù),功能,菜單,字段,敏感數(shù)據(jù)上,所以權限維度和組合,架構要考慮清楚)

    來自四川 回復
  6. 對于部門下每個人都擁有不通權限的問題是否可以通過將部門權限維護的權限賦予部門領導這個角色來解決呢?

    來自四川 回復
  7. 我們的系統(tǒng)一般而言部門的存在只是為了方便管理眾多的用戶,真正的權限是放在角色上的。角色是用戶的屬性,去分配不同的功能權限。

    來自陜西 回復
    1. 最簡單的是部門和用戶在一起,直接分配權限比較方便,當然,你要通過角色設置權限,部門管理人員,這都是可行的~

      來自廣東 回復
    2. 部門一般是用來區(qū)分數(shù)據(jù)權限居多吧

      來自上海 回復
  8. 最簡單的權限接解決方案:
    1.一個創(chuàng)建系統(tǒng)用戶,創(chuàng)建時將用戶與業(yè)務人員關聯(lián)
    2.一個創(chuàng)建業(yè)務人員與對應的權限

    :mrgreen: ??

    來自廣東 回復
  9. 權限建立的基礎,是劃分并梳理好“業(yè)務從屬”和“任務權限”;這兩塊不涉及到用戶畫像和需求調(diào)研,相對比較明確,所以還好…
    但是更為復雜的,是在權限分配中,加入績效考核與評定,這個也是必須的步驟,因為權責分明,也就是為了績效權衡。且行且努力吧… ??

    來自廣東 回復
  10. 干貨,學習了。

    來自四川 回復
  11. 說的太好了

    來自四川 回復
    1. 謝謝,歡迎交流~

      來自廣東 回復