B端產品的安全性設計

12 評論 5832 瀏覽 54 收藏 8 分鐘

在B端產品中,為了確保企業(yè)內部數(shù)據(jù)的安全性,我們應如何設計去滿足其不同業(yè)務情況下的需求。本文將安全性需求分為三類,通過用戶、職責、職位給出其對應的解決方案。

每個企業(yè),由于內部組織架構、職責崗位、業(yè)務等等方面的不同, 安全性的需求也不相同。但是從產品維度來說,安全性的設計是通用的。

安全性需求

首先,可以將安全性需求分為三類:

第一類,登陸安全性,即限制用戶登陸。什么人可以登陸,什么人不可以登陸。

第二類,界面安全性,不同的職責人員所需要查看或編輯的頁面不相同。例如,營銷人員可以查看營銷活動信息,而無法查看銷售信息。

第三類,數(shù)據(jù)安全性,即同樣的頁面看到的數(shù)據(jù)不同,例如,銷售A與銷售B所看到的數(shù)據(jù)不相同,但銷售經(jīng)理可查看A與B的數(shù)據(jù)。

知識點

1. 員工與用戶的區(qū)別

員工不等于用戶,員工可以是用戶,用戶不一定是員工。

員工,是指員工是指單位中各種用工形式的人員,包括固定工、合同工、臨時工,以及代訓工和實習生。

用戶,則是基于產品的,是指使用該產品的人員。

在B端產品中,由于各類業(yè)務需要,會存有企業(yè)內部的基礎員工數(shù)據(jù)等。(例如,某一業(yè)務的業(yè)務單據(jù)或流程中的關系人,為了防止重名以及唯一性,一般都是以HR中的工號作為系統(tǒng)內員工的唯一性。)這個時候,就容易將員工用戶搞混。

員工數(shù)據(jù)與客戶數(shù)據(jù)等均為主數(shù)據(jù),而用戶則是在員工基礎之上,增加的一層身份,但用戶并不都是員工。舉個例子說明一下,某企業(yè)的經(jīng)銷商下單平臺,除了企業(yè)內部員工允許下單外,經(jīng)銷商也可使用該平臺下單。而此時,經(jīng)銷商并不屬于員工,但屬于用戶。

2. 用戶、職責、職位的關系

職位,指機關或團體中執(zhí)行一定任務的位置,即只要是企業(yè)的員工就應有其特定的職位。

職責,職位上必須承擔的工作范圍、工作任務和工作責任。

簡單來說,職位指的就是崗位,職位有上下級。一個職位一個人,但一個人可以有多個職位(身兼數(shù)職)。而職責則指的是該職位所要做的事。

為了更好的區(qū)分職責職位的關系,以***銷售公司為例,如下圖

其中,西南銷售經(jīng)理、西南銷售1、西南銷售2均為職位,且西南銷售經(jīng)理為西南銷售的上級,西北銷售經(jīng)理為西北銷售人員的上級。但西南銷售經(jīng)理與西北銷售經(jīng)理的職責相同,均為銷售經(jīng)理職責;下級的職位很多,但職責也相同,為銷售人員職責。

解決方案

1. 登陸安全性

通過系統(tǒng)內用戶的設置,當且僅當?shù)顷懭宋粸橛脩魰r,即可成功登陸并使用產品。

2. 界面安全性

界面安全性,通過對職責分配不同界面來滿足該需求。

參考上面的***銷售公司的組織架構圖。銷售人員的職責相同,因此系統(tǒng)對于該職責所展示的界面一致。而財務經(jīng)理與銷售的職責不同,所以系統(tǒng)展示的界面也不相同。

例如某個系統(tǒng)內部包括銷售拜訪模塊和應收款模塊,銷售人員需要拜訪模塊來進行日?;顒?,而財務需要應收款模塊進行工作。

因此,將銷售拜訪模塊分配給銷售人員職責;將應收款模塊分配給財務相關職責。這么做,銷售人員也看不到應收款信息,而財務也看不到銷售拜訪信息。

3. 數(shù)據(jù)安全性

數(shù)據(jù)安全性,即相同頁面,不同用戶看到的數(shù)據(jù)不相同。常見的數(shù)據(jù)安全性分為以下幾種,個人安全性、職位安全性、團隊安全性、組織安全性、基于某業(yè)務的安全性、所有安全性等。

個人安全性,一般取的是創(chuàng)建人,即誰創(chuàng)建的數(shù)據(jù)誰可以看,其他人無法查看。注意,該安全性一般在企業(yè)的業(yè)務數(shù)據(jù)中很少使用,原因是因為企業(yè)內部人員離職后的數(shù)據(jù)問題。例如客戶數(shù)據(jù),若創(chuàng)建人離職,則該數(shù)據(jù)很難轉移給下一個人(總不能讓技術小哥底層改數(shù)據(jù)吧,技術小哥會打人的)。

職位安全性,即取的是創(chuàng)建人職位。該職位及該職位上級均可查看該條數(shù)據(jù)。除此之外,若有人員離職,可通過更換職位使數(shù)據(jù)轉移到下一個人。

團隊安全性,即對于某一客戶或者某一業(yè)務數(shù)據(jù),是由團隊共同負責。團隊的創(chuàng)建職位可添加其他職位用戶至團隊中,團隊中的成員均可有權限查看該條數(shù)據(jù)。

組織安全性,在集團型的企業(yè)中,各子公司的數(shù)據(jù)是獨立的。例如子公司的銷售總監(jiān)僅可查看該組織內的所有銷售數(shù)據(jù),而無法查看其他組織的數(shù)據(jù)。職位是有組織的,用戶的組織是基于職位。所以,一般的職位安全性可滿足大部分組織安全性的需求。

基于某業(yè)務的安全性,是指某一業(yè)務模塊的數(shù)據(jù)是基于其某一基礎數(shù)據(jù)的安全性。例如,當且僅當客戶負責人才可創(chuàng)建關聯(lián)的單據(jù)。此時,該業(yè)務單據(jù)的安全性是基于客戶負責人的,因此,所有該客戶的單據(jù)均有權限查看。

所有安全性,就是所有的數(shù)據(jù)均可以查看。

常用的安全性就這么多,雖然是B端產品,但在設計的時候,除了滿足業(yè)務需求之外,也要充分考慮到系統(tǒng)的靈活性,在減輕后續(xù)運營的精力之外,可以極大提高企業(yè)內部的業(yè)務效率。

另外,權限除了查看外,還包括新建、編輯、刪除等等,比較詳細的就不做說明啦。希望可以幫到大家!

 

本文由 @小雪球 原創(chuàng)發(fā)布于人人都是產品經(jīng)理,未經(jīng)作者許可,禁止轉載。

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

更多精彩內容,請關注人人都是產品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 如果崗位被裁或者合并,如何更好的保證職位安全性?

    回復
  2. 蜻蜓點水,看的不是很爽!

    回復
  3. 。。。有一說一,權限只能說和安全性沾一點點邊,文章改個名字叫《B端產品的權限設計》更為貼合,然鵝,權限設計人人都是產品經(jīng)理上被大家都寫得差不多了。
    應當從系統(tǒng)安全性、數(shù)據(jù)安全性、部署方式、身份管理(登陸鑒權、網(wǎng)絡驗證)、甚至代碼審查方面都可以說比系統(tǒng)權限更貼合安全性
    而且您這個權限設計……….并不出彩惹

    來自四川 回復
    1. 謝謝您的批評??會繼續(xù)努力的

      回復
  4. 登錄 不是登陸

    來自上海 回復
    1. 打錯,感謝建議

      回復
  5. 一套完成的權限系統(tǒng)沒有講,你在這說安全性設計??銷售crm都被你們玩爛了,還在這講廢話

    來自浙江 回復
    1. 覺得廢話出門右轉謝謝

      回復
  6. 簡單來說就是通過角色來設立權限,另外感覺作者對員工和用戶的解析不太準確。

    來自上海 回復
    1. 探討探討

      回復
  7. 賬號權限+功能權限+數(shù)據(jù)權限

    來自浙江 回復