編輯導(dǎo)語：對于業(yè)務(wù)較多的公司來說，組織結(jié)構(gòu)相對復(fù)雜，這時候平臺的權(quán)限架構(gòu)就顯得尤為重要，本篇文章作者分享了有關(guān)SaaS平臺的權(quán)限架構(gòu)的內(nèi)容，詳細介紹了不同運營場景下的數(shù)據(jù)權(quán)限問題，感興趣的一起來學(xué)習(xí)一下，希望對你有幫助。

對于SaaS系統(tǒng)的權(quán)限，就是登錄賬號的功能權(quán)限和數(shù)據(jù)權(quán)限的合集。

功能權(quán)限是賬號在平臺上能看到哪些頁面，能操作頁面里面的哪些功能或按鈕。

數(shù)據(jù)權(quán)限就是這個賬號能在系統(tǒng)中看到哪些數(shù)據(jù)，能對哪些數(shù)據(jù)做功能級的操作。

功能權(quán)限一般靠角色和功能集進行關(guān)聯(lián)，即RBAC模型。數(shù)據(jù)權(quán)限一般靠靠租戶的組織架構(gòu)來實現(xiàn)數(shù)據(jù)的隔離。

然后賬號和角色關(guān)聯(lián)，獲得功能權(quán)限，和組織架構(gòu)關(guān)聯(lián)，獲得可管理的數(shù)據(jù)。下面對相應(yīng)內(nèi)容做詳細介紹。

一、組織架構(gòu)解決數(shù)據(jù)權(quán)限

在實際運營場景中，稍微大點的公司，組織架構(gòu)相對比較復(fù)雜，層級比較多，每個層級節(jié)點要看到的數(shù)據(jù)要求是不一樣的，所以要對不同層級節(jié)點的數(shù)據(jù)做隔離。

例如，某餐飲公司組織架構(gòu)如下，則總部的CEO要看到下屬分公司的所有數(shù)據(jù)，分公司的總經(jīng)理要看到所有下屬區(qū)域的數(shù)據(jù)，朝陽區(qū)區(qū)域經(jīng)理要看到下屬所有門店的數(shù)據(jù)，門店店長要看到店里的所有數(shù)據(jù)。

所以要在平臺賬號權(quán)限中引入組織架構(gòu)，賬號直接跟組織架構(gòu)關(guān)聯(lián)，在哪個層級看到哪個層級的數(shù)據(jù)，通過組織架構(gòu)對多層級數(shù)據(jù)進行隔離。

總體來說，賬號關(guān)聯(lián)組織架構(gòu)時，需要確定下來方位的數(shù)據(jù)精確到哪一節(jié)點，是本節(jié)點及下級節(jié)點數(shù)據(jù)，或只有本節(jié)點數(shù)據(jù)，或指定的某個下級節(jié)點數(shù)據(jù)，或是只能管理屬于自己創(chuàng)建的數(shù)據(jù)。

特殊的也會存在跨層級查看數(shù)據(jù)的情況。有以下五種場景：

1）場景1：賬號可看到本層級及下級數(shù)據(jù)。

在創(chuàng)建賬號時，要選擇這個賬號屬于哪個層級，則就能看到當(dāng)前層級及以下層級的所有數(shù)據(jù)。

如賬號1可看到北京分公司及其下屬節(jié)點的所有數(shù)據(jù)。

這種是比較常用的數(shù)據(jù)權(quán)限，同時賬號不能看到上級組織結(jié)構(gòu)節(jié)點的數(shù)據(jù)，如賬號2屬于朝陽區(qū)這個節(jié)點，則不能看到屬于北京分公司的數(shù)據(jù)。

2）場景2：賬號只能看到本層級的數(shù)據(jù)。

數(shù)據(jù)權(quán)限更深層的需要細化出來這個賬號能看到具體哪個級別的數(shù)據(jù)，如賬號3是屬于朝陽區(qū)，但他有可能只能看到屬于朝陽區(qū)這一層的數(shù)據(jù)，下級節(jié)點的門店數(shù)據(jù)是看不到的。

3）場景3：賬號只能看到下級某一節(jié)點的數(shù)據(jù)。

如售后人員的賬號2，雖然是屬于北京分公司，但只能負責(zé)朝陽區(qū)下面門店1和門店2的數(shù)據(jù)。

基于這種情況，需要在創(chuàng)建賬號時，在關(guān)聯(lián)組織架構(gòu)，還要指定當(dāng)前賬號能看到這個節(jié)點下的哪些數(shù)據(jù)。

4）場景4，賬號只能看到指定層級的指定數(shù)據(jù)。

每個組織架構(gòu)的層級上會有一些屬于當(dāng)前級別某些賬號特有的數(shù)據(jù)。

如商務(wù)合作的客戶數(shù)據(jù)，屬于當(dāng)前組織架構(gòu)的節(jié)點，同樣屬于某個商務(wù)人員獨有，不會共享給其他招商人員。

如招商部的A員工的賬號3，管理的客戶信息是屬于朝陽區(qū)的，同樣也只屬于賬號3所屬的A員工管理。

其他同級別的賬號4所屬的員工，則沒有權(quán)限看到這些客戶信息。但招商部的部門經(jīng)理是要看到本部門的所有數(shù)據(jù)。

所以在創(chuàng)建賬號時，還要指定這個賬號是能看到本部門的數(shù)據(jù)還只能看到自己創(chuàng)建的數(shù)據(jù)。

5）場景5：存在管理不同級別其他節(jié)點數(shù)據(jù)。

例如賬號5原本屬于組織架構(gòu)里的門店1，理論上只能管理門店1的數(shù)據(jù)，但如果門店4這種不在同一個上級節(jié)點的門店，希望幫忙分析售后問題，那賬號5如何跨節(jié)點管理門店4的售后問題。

答案是門店4的管理者可以指定某些數(shù)據(jù)或節(jié)點的所有數(shù)據(jù)共享給門店1的賬號5管理。

數(shù)據(jù)共享不限制組織結(jié)構(gòu)的上下級和同級關(guān)系。

二、角色解決功能權(quán)限（RBAC模型）

1. 基礎(chǔ)角色權(quán)限模型（RBAC0）

為什么要靠角色來解決功能權(quán)限，而不是使用賬號跟功能直接關(guān)聯(lián)？是因為平臺頁面多，頁面內(nèi)的功能也非常多的情況下，如果靠賬號直接跟頁面和功能關(guān)聯(lián)，所有賬號都操作起來比較繁瑣。

引入角色，把角色和權(quán)限關(guān)聯(lián)，這樣有相同權(quán)限的人直接跟角色關(guān)聯(lián)，進而獲得角色所對應(yīng)的功能權(quán)限。提高的操作的便利性。角色本身就是功能的合集。

同一個賬號，可以有多個角色，則可獲得多個角色的并集的權(quán)限。如賬號4關(guān)聯(lián)員工和助理兩個角色，則賬號4可獲得員工角色對應(yīng)的頁面3、頁面4和助理角色對應(yīng)的頁面5的功能權(quán)限。

2. 角色搭建組織架構(gòu)（RBAC1）

對于組織架構(gòu)沒有那么復(fù)雜的，則會有使用角色來實現(xiàn)組織架構(gòu)的，角色設(shè)計成帶有上下級的樹形結(jié)構(gòu)。

這種實現(xiàn)方式靈活性會比較差，如果組織架構(gòu)復(fù)雜，則角色量比較多，同樣一個店長角色，需要在每個組織架構(gòu)的節(jié)點上都進行單獨創(chuàng)建。一般不會采用這種實現(xiàn)方式。

3. 角色互斥場景（RBAC2）

實際業(yè)務(wù)場景中，存在同一個賬號不能同時獲得兩個角色，兩個角色互斥，有這個角色就不能獲得另外一個角色。

財務(wù)中的會計和出納兩個角色，一個人是不能同時負責(zé)，做到財權(quán)分離。

這種需要在創(chuàng)建角色定義中專門去定義互斥情況。

4. 角色同時有組織架構(gòu)和角色互斥（RBAC3）

復(fù)合型的RBAC1+RBAC2的一種合成形式，角色上既有組織架構(gòu)，又有角色互斥的實現(xiàn)形式。

三、賬號關(guān)聯(lián)角色或組織內(nèi)的崗位

1）賬號只綁定角色來同時獲得功能權(quán)限和數(shù)據(jù)權(quán)限。

如上圖所示，把角色當(dāng)成崗位，可將角色直接與組織架構(gòu)關(guān)聯(lián)，賬號只需與角色關(guān)聯(lián)，不用單獨關(guān)聯(lián)組織架構(gòu)，則賬號直接獲取當(dāng)前角色下的功能權(quán)限和角色對應(yīng)的組織架構(gòu)下的數(shù)據(jù)權(quán)限。

這樣如果賬號需要調(diào)整崗位時，直接調(diào)整賬號對應(yīng)的角色就可以，方便操作。

但這種需要在每個節(jié)點上創(chuàng)建好崗位和對應(yīng)節(jié)點的角色，角色的數(shù)據(jù)量會比較多，每個角色都要配置對應(yīng)的功能權(quán)限。

2）賬號只綁定組織架構(gòu)內(nèi)的崗位來同時獲得功能權(quán)限和數(shù)據(jù)權(quán)限。

在組織架構(gòu)上創(chuàng)建崗位，崗位和對應(yīng)的角色關(guān)聯(lián)，賬號直接跟組織架構(gòu)上的角色進行關(guān)聯(lián)，同時獲得角色權(quán)限，無需再關(guān)聯(lián)角色。

賬號在調(diào)崗時直接更換組織架構(gòu)中的崗位就可以。

這種和上面的場景一樣，都需要頻繁重復(fù)創(chuàng)建一樣的內(nèi)容。

四、審批流程業(yè)務(wù)場景。

上面介紹的賬號與角色和組織架構(gòu)關(guān)聯(lián)來解決功能權(quán)限和數(shù)據(jù)權(quán)限的問題，但涉及到審批流程的，如在門店1內(nèi)部，服務(wù)員請假，需要店長審批，但兩個人都屬于同一組織架構(gòu)的門店1上，沒有上下級關(guān)系，只能在流程上指定人去審批。

但這樣每個部門內(nèi)部都需要自己創(chuàng)建審批流程，操作起來比較繁瑣。

因為角色的作用本身就是崗位職責(zé)，可以在審批流程中引入角色，審批節(jié)點都是角色。

• 例如請假，可在審批流程中設(shè)定門店的員工角色請假都要讓門店的店長或管理者角色審批，這樣所有的門店都遵照這個流程。
• 例如報銷流程需要走門店店長和區(qū)級財務(wù)經(jīng)理這兩個審批。如果報銷一定金額，需要走分公司的財務(wù)副總這個人審批，則需要在流程中支持指定人來審批的功能。但一般不建議指定人審批，后續(xù)人員調(diào)整，審批流程也要做相應(yīng)調(diào)整。

另外如果當(dāng)前審批角色上有多個賬號，則多個賬號都可以審批，除非流程上指定某個賬號審批。

如財務(wù)報銷走到了朝陽區(qū)的財務(wù)角色，下面有賬號3和賬號4，則賬號3和4都可以審批，本著誰審批，誰負責(zé)的原則。

如果賬號3審批了某個報銷單，后續(xù)打款也應(yīng)當(dāng)走到賬號3上來進行審批。

五、角色組和用戶組使用場景。

1. 角色組是多個角色的合集，多個角色下的功能權(quán)限的合集，為了在1個賬號綁定多個角色時方便操作，倒不如直接建個新的角色綁定賬號。
2. 用戶組，就是多個賬號的合集，為了在多個賬號綁定同一個角色時方便操作，并沒有解決解決具體權(quán)限問題。

六、總結(jié)

目前基于SaaS平臺的現(xiàn)有業(yè)務(wù)和未來管理類的業(yè)務(wù)特點，一般會采用標(biāo)題1、標(biāo)題2和標(biāo)題4三種結(jié)合的形式，來分別解決功能權(quán)限，數(shù)據(jù)權(quán)限，和審批流程的權(quán)限。

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

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