編輯導(dǎo)語：我們常常在數(shù)據(jù)權(quán)限中找不到合適的門路，中后臺的數(shù)據(jù)權(quán)限該怎么設(shè)計才能夠滿足我們所需業(yè)務(wù)的數(shù)據(jù)權(quán)限架構(gòu)體系？作者給我們從三個方面講解了有關(guān)數(shù)據(jù)權(quán)限的知識，我們一起來看下吧。

曾經(jīng)看到過這樣一個需求：他想知道，我“為什么”能夠看到這條數(shù)據(jù)? 如果這條數(shù)據(jù)是我自己創(chuàng)建的，那么其他能看到這條數(shù)據(jù)的人，都由于什么原因呢?

我的第一反應(yīng)是：數(shù)據(jù)權(quán)限設(shè)計的太復(fù)雜了。

隨后又想到: “為什么數(shù)據(jù)權(quán)限要設(shè)計的這么復(fù)雜呢，有沒有更好的實現(xiàn)方案?”

但在回答這個問題之前，可能要先完成另一件事情，分析清楚到底什么是數(shù)據(jù)權(quán)限? 都有哪些業(yè)務(wù)場景，需要數(shù)據(jù)權(quán)限的支持?

簡單來講，數(shù)據(jù)權(quán)限就是“用戶是否能夠查看數(shù)據(jù)”，主要是為了業(yè)務(wù)系統(tǒng)的信息安全考慮，不同的人，在不同的場景下，所能看到的數(shù)據(jù)范圍也不一樣。

為了行文方便，后續(xù)統(tǒng)一使用“查看數(shù)據(jù)”進行描述，實際上像增/刪/改/查/鎖定/解鎖/分享等的數(shù)據(jù)權(quán)限類型有很多，就不在本文中介紹了。

本文將結(jié)合在工作中遇見的一些業(yè)務(wù)場景，跟大家分享一些常見的數(shù)據(jù)權(quán)限設(shè)計，也希望能夠總結(jié)出一套，最符合本公司業(yè)務(wù)的數(shù)據(jù)權(quán)限架構(gòu)體系。

一、基礎(chǔ)數(shù)據(jù)權(quán)限

1. 對象級權(quán)限

基礎(chǔ)數(shù)據(jù)權(quán)限通常會承載到一個權(quán)限媒介上，比如說權(quán)限集，職能等。他通常包括兩部分，對象級權(quán)限與字段級權(quán)限。

簡單來講，對象級權(quán)限可以控制到一個用戶是否能夠看到某一個業(yè)務(wù)菜單或者業(yè)務(wù)Tab，也就是說用戶甚至可以不知道系統(tǒng)中有這一類的數(shù)據(jù)。對象級權(quán)限的設(shè)計會包含下面幾部分。

當(dāng)然，對于不同的企業(yè)，可能還會有更精細(xì)的管理，比如針對數(shù)據(jù)的轉(zhuǎn)移，鎖定/解鎖等基本功能可以也需要做控制。

關(guān)于“查詢所有關(guān)聯(lián)”和 “修改所有關(guān)聯(lián)”，他的權(quán)限優(yōu)先級是要高于其他權(quán)限規(guī)則。比如商機、訂單、報價單等業(yè)務(wù)對象都關(guān)聯(lián)了客戶，那么如果在客戶上設(shè)置了“查詢所有關(guān)聯(lián)”的話，就會覆蓋掉具體關(guān)聯(lián)業(yè)務(wù)實體設(shè)置的對象級權(quán)限。

2. 字段級權(quán)限

根據(jù)業(yè)務(wù)需要，即使可以看到某個業(yè)務(wù)對象，但也需要對某些隱私字段做數(shù)據(jù)權(quán)限處理。 例如：聯(lián)系人電話、薪水等信息，不會對所有人開放。

如果企業(yè)的系統(tǒng)中，有包含頁面布局的相關(guān)設(shè)置，那么字段級權(quán)限設(shè)置，要覆蓋掉布局的設(shè)置。

二、記錄級數(shù)據(jù)權(quán)限

其實對于很多業(yè)務(wù)系統(tǒng)來說，可能上面的基礎(chǔ)數(shù)據(jù)權(quán)限設(shè)計已經(jīng)能夠滿足大部分?jǐn)?shù)據(jù)權(quán)限場景了，但問題是有一類“特殊場景”解決不了。

某“一部分”數(shù)據(jù)，只允許“一部分”人查看。

幾乎所有復(fù)雜的數(shù)據(jù)權(quán)限設(shè)計，都是為了解決這個問題，而且因為使用場景差異太大，很難找到一個一攬子解決方案。所以需要多種方案結(jié)合，才能在便捷性、安全性上，滿足中大企業(yè)復(fù)雜的數(shù)據(jù)權(quán)限要求。

1. 系統(tǒng)默認(rèn)權(quán)限

要想解決 某“一部分”數(shù)據(jù)，只允許“一部分”人操作，理論上那就意味著每一條數(shù)據(jù)都應(yīng)該可以被控制。

那么 每一個用戶與每一條數(shù)據(jù)之間到底是什么關(guān)系，是業(yè)務(wù)系統(tǒng)需要回答的第一個問題。

通常來講，系統(tǒng)默認(rèn)權(quán)限應(yīng)該是“最嚴(yán)格的”，“唯一”的“限制”數(shù)據(jù)權(quán)限的方式，其他的記錄級數(shù)據(jù)權(quán)限，應(yīng)該是在系統(tǒng)默認(rèn)權(quán)限的基礎(chǔ)上，增加額外的數(shù)據(jù)權(quán)限。

比如最極端的限制條件，所有的業(yè)務(wù)數(shù)據(jù)都是不可見的。 當(dāng)然對于某些公司來講，一些數(shù)據(jù)是全員可見的，比如像公告、通訊錄、社區(qū)帖子等類型的數(shù)據(jù)。

系統(tǒng)默認(rèn)權(quán)限如果需要修改，應(yīng)該要受到嚴(yán)格的控制流程管理，畢竟這是整個數(shù)據(jù)權(quán)限架構(gòu)中，唯一的限制。

2. 記錄所屬人

通常來說，如果一個用戶擁有某個業(yè)務(wù)實體創(chuàng)建對象的權(quán)限，那么針對這條特定的記錄，用戶創(chuàng)建完成記錄后，會自動變?yōu)檫@條記錄的所屬人(owner)。

在系統(tǒng)默認(rèn)權(quán)限的基礎(chǔ)上，記錄的所屬人就屬于一種新增的數(shù)據(jù)權(quán)限，可以對這個用戶進行查看操作(可進行的操作應(yīng)該基于基礎(chǔ)數(shù)據(jù)權(quán)限)。

由于業(yè)務(wù)的需要，記錄會在不同的用戶之間進行數(shù)據(jù)轉(zhuǎn)移的操作(transfer ownership)，所以記錄所屬人，不一定是記錄的創(chuàng)建人。

還有一種例外情況，一條記錄不屬于某個特定的用戶。

在有些公司的業(yè)務(wù)中，會有類似公海池、隊列等記錄分配器功能。

那么在分配記錄之前，這些記錄也是可以屬于這些分配器的。

相關(guān)功能的成員可以在列表視圖中看到這些分配器中的記錄數(shù)據(jù)，并進行所屬人認(rèn)領(lǐng)的操作（更多詳細(xì)內(nèi)容，我會更新在后續(xù)的公海池設(shè)計當(dāng)中）。

3. 部門/相關(guān)部門

每個企業(yè)的組織架構(gòu)都會區(qū)分部門，那么就有一個非常自然的需求場景：看到本部門以及下級部門相關(guān)的所有數(shù)據(jù)。

一種比較簡單的做法，就是在創(chuàng)建數(shù)據(jù)的時候，自動將數(shù)據(jù)關(guān)聯(lián)到創(chuàng)建用戶的所屬部門上。

還有一些情況，有些公司的數(shù)據(jù)是由專門的團隊負(fù)責(zé)創(chuàng)建的，那么針對于這些數(shù)據(jù)，就需要可以變更數(shù)據(jù)的所屬部門的能力。

隨著業(yè)務(wù)的不斷發(fā)展，可能會遇到跨部門數(shù)據(jù)查看的需求，也就是說，一個用戶有主要的所屬部門，以及根據(jù)數(shù)據(jù)權(quán)限需要而設(shè)置的多個相關(guān)部門。

4. 直屬負(fù)責(zé)人/助理

在傳統(tǒng)的組織架構(gòu)中，除了部門層級之間的數(shù)據(jù)共享需求之外，還有人員匯報關(guān)系線。

通常的做法，就是在為每一個用戶，指定一個直屬上級負(fù)責(zé)人，直屬上級負(fù)責(zé)人會被賦予所有下屬層級的相同數(shù)據(jù)權(quán)限。

為了管理方便，也可以為直屬負(fù)責(zé)人設(shè)置助理，助理與直屬負(fù)責(zé)人具備相同的數(shù)據(jù)權(quán)限，這樣更靈活的讓不同的用戶能夠跳脫出公司組織架構(gòu)的束縛。

5. 崗位層級

使用部門權(quán)限體系會帶來一個問題，企業(yè)的組織架構(gòu)往往與業(yè)務(wù)的架構(gòu)是不一致的。而且業(yè)務(wù)架構(gòu)會經(jīng)常變化，而結(jié)構(gòu)變化對于數(shù)據(jù)權(quán)限控制來講，是一個挑戰(zhàn)。

崗位層級，可以根據(jù)數(shù)據(jù)權(quán)限需要，將一個用戶或者一組用戶放在同樣的崗位下。

這樣的話，在創(chuàng)建崗位的同時，也可以很好的了解公司架構(gòu)到底應(yīng)該以什么樣的形式組織在一起更高效。

可以從上至下的設(shè)置崗位層級，比如說最高層崗位叫CEO，可以查看整個組織的數(shù)據(jù)。然后以事業(yè)部總經(jīng)理或者地區(qū)負(fù)責(zé)人的崗位，繼續(xù)向下細(xì)分，查看各自崗位下的數(shù)據(jù)。

崗位層級權(quán)限還有一個更加強大的能力，就是崗位與數(shù)據(jù)之間可以是 m:n 關(guān)系，也就是說同一條數(shù)據(jù)可以同時共享給多個崗位，滿足更加復(fù)雜的數(shù)據(jù)共享場景。

崗位層級的設(shè)計，可以將數(shù)據(jù)與用戶解綁，這在人員變動，業(yè)務(wù)調(diào)整時，可以很方便的做數(shù)據(jù)共享的變更。

6. 共享規(guī)則

對于數(shù)據(jù)權(quán)限還有一類更加接近直覺的設(shè)計方式，也就是別搞那些花里胡哨的概念，我就是要把“這一部分”數(shù)據(jù)，共享給“那一部分”人，簡單直接一點，怎么做？

換句話來講，如果上面的權(quán)限設(shè)計體系統(tǒng)統(tǒng)不能滿足業(yè)務(wù)場景，可不可以提供一種直接的數(shù)據(jù)共享方式。

“共享規(guī)則”的設(shè)計方案可能是一種解決思路。通常來講，共享規(guī)則解決了兩類場景：

1. 把特定用戶的數(shù)據(jù)，共享給特定用戶。
2. 把符合特定條件的數(shù)據(jù)，共享給特定用戶。

當(dāng)然這里面的“特定用戶”，不僅僅只用戶本身，所有包含用戶的容器概念元素(部門、群組、角色等)，應(yīng)該都包含在內(nèi)。

7. 手工共享

共享規(guī)則雖然方便，但解決不了一類更要命的數(shù)據(jù)權(quán)限場景，有些共享場景是沒有辦法提前可以預(yù)想的，是隨機的，是隨時隨地的，怎么辦?

其實這種場景的前提條件就決定了權(quán)限設(shè)計的方式，既然規(guī)則不行，那就手工來指定好了。

手工共享的數(shù)據(jù)權(quán)限設(shè)計，完全是基于記錄所屬人的自由意志，記錄所屬人認(rèn)為數(shù)據(jù)應(yīng)該共享給誰，就共享給誰好了。

需要注意的是，當(dāng)記錄的所屬關(guān)系發(fā)生變更時，那么手工共享關(guān)系應(yīng)該直接解除。記錄所屬人也需要可以隨時查看和修改，當(dāng)前這條數(shù)據(jù)的手工共享情況。

8. 團隊成員

手工共享的確可以解決非常態(tài)化規(guī)則的數(shù)據(jù)權(quán)限場景，但麻煩的是，共享關(guān)系會隨著記錄所屬人的所屬關(guān)系轉(zhuǎn)移，而全部丟失。

對于一條記錄來講，如果大部分需要共享的用戶不會經(jīng)常發(fā)生變動，可以嘗試使用團隊成員的方式來進行手工共享。

記錄所屬人或者有記錄編輯權(quán)限的團隊成員，可以同時添加其他用戶作為這條記錄的團隊成員，記錄會對所有團隊成員共享。

這樣即使記錄所屬人發(fā)生變化，其他的團隊成員會仍然保留與此條記錄的數(shù)據(jù)共享關(guān)系。

團隊成員除了支持用戶外，也需要支持部門，群組才能更靈活的支撐單條數(shù)據(jù)的共享。

9. 群組共享

團隊成員共享方案，能夠解決大部分需要靈活配置的單條數(shù)據(jù)共享場景，但操作比較繁瑣。

如果需要頻繁共享給一個虛擬組織團隊，就需要在每一條數(shù)據(jù)上添加若干個，相同的團隊成員，效率很低。

群組就會很好地解決這個問題，若幾個用戶之間需要經(jīng)常共享數(shù)據(jù)，那么可以將用戶們用群組圈起來，記錄的所屬人，可以通過將自己創(chuàng)建的、符合條件的數(shù)據(jù)，自動共享到若干群組中，用戶也可以通過手動共享的方式，將某條數(shù)據(jù)共享到群組中。

而只有群組成員才能看到群組中的數(shù)據(jù)，群組一般分為公用群組和私用群組。

• 公用群組是整個公司都能看到的群組，任何人都可以將數(shù)據(jù)共享到公用群組中。
• 私用群組是每個人獨立創(chuàng)建的，只有群組成員可以將數(shù)據(jù)共享到私用群組中。

群組應(yīng)該是可以支持嵌套關(guān)系的，比如：用戶、角色、崗位、群組本身，都是可以是群組的一員。

當(dāng)然處于性能的考慮，最好對類似群組套群組的這種方式，做一個層級上的限制。

群組與數(shù)據(jù)的關(guān)系應(yīng)該是多對多的，也就是說，同樣一條數(shù)據(jù)，可以在不同的群組中做共享。

群組數(shù)據(jù)的共享應(yīng)該是獨立的，通過類似其他崗位層級，直屬上級相關(guān)的其他權(quán)限，是無法突破群組成員限制的。也就是說UserA是群組成員，可以看到群組的數(shù)據(jù)，但UserA的上司由于不是群組成員，所以看不到群組的數(shù)據(jù)。

10. 區(qū)域?qū)蛹?/h3>

對于大型企業(yè)應(yīng)用場景，經(jīng)常會出現(xiàn)銷售、產(chǎn)品、服務(wù)分屬于不同的業(yè)務(wù)單元，但需要根據(jù)不同的規(guī)則共享客戶等相關(guān)資源。那么就可以創(chuàng)建多個區(qū)域?qū)蛹?，讓同一個客戶按照不同的層級結(jié)構(gòu)共享給各個不同的業(yè)務(wù)單元。

與崗位層級類似，區(qū)域?qū)蛹壨ǔ?yīng)用于地盤資源管理的數(shù)據(jù)權(quán)限劃分，通過多個不同的區(qū)域維度規(guī)則，如地區(qū)、客戶等級、行業(yè)、產(chǎn)品線。相應(yīng)的數(shù)據(jù)在創(chuàng)建/編輯后，可以自動進入到符合規(guī)則的區(qū)域。

通過一些級聯(lián)跟隨分配的設(shè)置，數(shù)據(jù)下的相關(guān)數(shù)據(jù)也可以同時進入到相同區(qū)域，比如客戶下的訂單，訂單下的回款單等。

數(shù)據(jù)進入到區(qū)域后，區(qū)域成員就可以看到數(shù)據(jù)了。

一般來講，區(qū)域權(quán)限分為2級，Object、Hirerachy。

• Object 業(yè)務(wù)對象級權(quán)限，說的是一個區(qū)域成員針對于具體的業(yè)務(wù)對象，是什么權(quán)限。比如針對于客戶，是查看還是編輯?
• Hirerachy 層級權(quán)限，是說針對于業(yè)務(wù)實體，除了本級區(qū)域的權(quán)限，是否也具備下級區(qū)域的權(quán)限。

針對于單個區(qū)域，若有業(yè)務(wù)需要，也可以添加 Record 級別的權(quán)限，類似于記錄所屬人。

針對于每一個區(qū)域，也可以設(shè)置這個區(qū)域的記錄負(fù)責(zé)人（Territory Record Owner），這樣對于基于區(qū)域管理的業(yè)務(wù)屬性來講，可以將記錄做到最靈活的配置。

三、如何應(yīng)用數(shù)據(jù)權(quán)限

回到最初提到的問題，他們的深層考慮是什么?

如果這條數(shù)據(jù)是我自己創(chuàng)建的，那么其他能看到這條數(shù)據(jù)的人都有誰?

對于很多企業(yè)來講，從數(shù)據(jù)隱私安全的角度考慮到數(shù)據(jù)權(quán)限問題，是很重要的命題。

對數(shù)據(jù)權(quán)限因果鏈條的掌握，可以對整個數(shù)據(jù)權(quán)限體系的優(yōu)化，起到至關(guān)重要的指導(dǎo)作用。

• “小王已經(jīng)從A事業(yè)部轉(zhuǎn)崗，還能通過助理權(quán)限看到B事業(yè)部的客戶呢，應(yīng)該馬上取消小王的權(quán)限?！?/li>
• “小張是C事業(yè)部的銷售成員，通過群組權(quán)限看到他本應(yīng)看到的客戶，而不是崗位權(quán)限看到這個客戶，看來客戶的分配邏輯有一些問題?！?/li>

有人想知道，我為什么能夠看到這條數(shù)據(jù)?

當(dāng)用戶看到這條數(shù)據(jù)時，通過看到這條數(shù)據(jù)的原因，可以快速的找準(zhǔn)自己的職責(zé)定位。

因為我是這個客戶的團隊成員，那么我需要對這個客戶的培育投入精力。

這個客戶是我下屬自拓的一名新客戶，那么我需要對其給予幫助。

更重要的是，經(jīng)常的審視數(shù)據(jù)權(quán)限體系的因果關(guān)系，也會對業(yè)務(wù)本身認(rèn)識得更清晰，優(yōu)秀的數(shù)據(jù)權(quán)限體系，甚至可以優(yōu)化公司的業(yè)務(wù)運營體系，讓效率提升自下而上的發(fā)生。

那么問題來了，既然優(yōu)秀的數(shù)據(jù)權(quán)限體系，可以提升管理效率，那有沒有什么設(shè)計原則是可以遵守的？

或者說作為一個公司業(yè)務(wù)運營的管理者，到底應(yīng)該怎么設(shè)計公司的數(shù)據(jù)權(quán)限體系呢?

在我們設(shè)計權(quán)限體系的時候，都是用各種概念將具體的權(quán)限，通過滿足特定業(yè)務(wù)場景的方式包裝起來。

我們把包裝起來的這樣一個個的概念，可以稱之為 “權(quán)限媒介”。

權(quán)限媒介在自身屬性上，分為三種類型：

（1）Owner

獨立媒介，比如記錄所屬人，崗位層級。

• 可以自主的滿足所有的權(quán)限結(jié)構(gòu)；
• 可以包含其他權(quán)限體系。

（2）Child

子媒介，比如群組，區(qū)域。

• 可以自主的滿足所有的權(quán)限結(jié)構(gòu)；
• 可以被特定的Owner媒介包含；
• 可以包含其他權(quán)限體系。

3. Element

原子媒介，比如助理/直屬上級從屬于部門層級。

• 可以理解為內(nèi)部權(quán)限媒介；
• 僅可以包含其他原子媒介。

權(quán)限媒介的自身屬性類型可以幫助我們認(rèn)識到，權(quán)限體系的設(shè)計是整體的，而不是混亂的。

一個媒介已經(jīng)被定為成Element，就不要同時還具備Owner的屬性，不然可能雖然一時解決了問題，但今后的擴展會無比艱難。

權(quán)限媒介在使用場景上，分為兩種類型：

（1）有規(guī)則的

比如共享規(guī)則，崗位層級。

• 根據(jù)公司的業(yè)務(wù)需要，總結(jié)出來的數(shù)據(jù)共享場景；
• 可節(jié)省大量的權(quán)限共享設(shè)置成本。

（2）無規(guī)則的

比如團隊成員，手工共享。

• 人為認(rèn)定的數(shù)據(jù)權(quán)限共享場景，提前無法認(rèn)知；
• 規(guī)則設(shè)置成本，超過了使用成本。

權(quán)限媒介的使用場景類型，可以幫助我們認(rèn)識到，權(quán)限的靈活性，要把“人”的判斷納入到整個體系中來。過高的設(shè)置成本不但會加大業(yè)務(wù)的復(fù)雜度，而且也會讓“人”失去控制感。

相信了解了權(quán)限媒介的自身屬性和使用場景之后，那我們就可以試著總結(jié)出一套適合自己公司數(shù)據(jù)權(quán)限體系架構(gòu)的最佳實踐原則。

讓我們一起創(chuàng)造“有良好擴展性，并讓人有靈活掌控感”的數(shù)據(jù)權(quán)限體系吧。

本文由 @合理膳食與長壽 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

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