B端產品的安全性設計
在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é)議。
如果崗位被裁或者合并,如何更好的保證職位安全性?
蜻蜓點水,看的不是很爽!
。。。有一說一,權限只能說和安全性沾一點點邊,文章改個名字叫《B端產品的權限設計》更為貼合,然鵝,權限設計人人都是產品經(jīng)理上被大家都寫得差不多了。
應當從系統(tǒng)安全性、數(shù)據(jù)安全性、部署方式、身份管理(登陸鑒權、網(wǎng)絡驗證)、甚至代碼審查方面都可以說比系統(tǒng)權限更貼合安全性
而且您這個權限設計……….并不出彩惹
謝謝您的批評??會繼續(xù)努力的
登錄 不是登陸
打錯,感謝建議
一套完成的權限系統(tǒng)沒有講,你在這說安全性設計??銷售crm都被你們玩爛了,還在這講廢話
覺得廢話出門右轉謝謝
簡單來說就是通過角色來設立權限,另外感覺作者對員工和用戶的解析不太準確。
探討探討
賬號權限+功能權限+數(shù)據(jù)權限