編輯導語：對于業務較多的公司來說，組織結構相對複雜，這時候平台的權限架構就顯得尤為重要，本篇文章作者分享了有關SaaS平台的權限架構的内容，詳細介紹了不同運營場景下的數據權限問題，感興趣的一起來學習一下，希望對你有幫助。

對于SaaS系統的權限，就是登錄賬号的功能權限和數據權限的合集。

功能權限是賬号在平台上能看到哪些頁面，能操作頁面裡面的哪些功能或按鈕。

數據權限就是這個賬号能在系統中看到哪些數據，能對哪些數據做功能級的操作。

功能權限一般靠角色和功能集進行關聯，即RBAC模型。數據權限一般靠靠租戶的組織架構來實現數據的隔離。

然後賬号和角色關聯，獲得功能權限，和組織架構關聯，獲得可管理的數據。下面對相應内容做詳細介紹。

一、組織架構解決數據權限

在實際運營場景中，稍微大點的公司，組織架構相對比較複雜，層級比較多，每個層級節點要看到的數據要求是不一樣的，所以要對不同層級節點的數據做隔離。

例如，某餐飲公司組織架構如下，則總部的CEO要看到下屬分公司的所有數據，分公司的總經理要看到所有下屬區域的數據，朝陽區區域經理要看到下屬所有門店的數據，門店店長要看到店裡的所有數據。

所以要在平台賬号權限中引入組織架構，賬号直接跟組織架構關聯，在哪個層級看到哪個層級的數據，通過組織架構對多層級數據進行隔離。

總體來說，賬号關聯組織架構時，需要确定下來方位的數據精确到哪一節點，是本節點及下級節點數據，或隻有本節點數據，或指定的某個下級節點數據，或是隻能管理屬于自己創建的數據。

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

1）場景1：賬号可看到本層級及下級數據。

在創建賬号時，要選擇這個賬号屬于哪個層級，則就能看到當前層級及以下層級的所有數據。

如賬号1可看到北京分公司及其下屬節點的所有數據。

這種是比較常用的數據權限，同時賬号不能看到上級組織結構節點的數據，如賬号2屬于朝陽區這個節點，則不能看到屬于北京分公司的數據。

2）場景2：賬号隻能看到本層級的數據。

數據權限更深層的需要細化出來這個賬号能看到具體哪個級别的數據，如賬号3是屬于朝陽區，但他有可能隻能看到屬于朝陽區這一層的數據，下級節點的門店數據是看不到的。

3）場景3：賬号隻能看到下級某一節點的數據。

如售後人員的賬号2，雖然是屬于北京分公司，但隻能負責朝陽區下面門店1和門店2的數據。

基于這種情況，需要在創建賬号時，在關聯組織架構，還要指定當前賬号能看到這個節點下的哪些數據。

4）場景4，賬号隻能看到指定層級的指定數據。

每個組織架構的層級上會有一些屬于當前級别某些賬号特有的數據。

如商務合作的客戶數據，屬于當前組織架構的節點，同樣屬于某個商務人員獨有，不會共享給其他招商人員。

如招商部的A員工的賬号3，管理的客戶信息是屬于朝陽區的，同樣也隻屬于賬号3所屬的A員工管理。

其他同級别的賬号4所屬的員工，則沒有權限看到這些客戶信息。但招商部的部門經理是要看到本部門的所有數據。

所以在創建賬号時，還要指定這個賬号是能看到本部門的數據還隻能看到自己創建的數據。

5）場景5：存在管理不同級别其他節點數據。

例如賬号5原本屬于組織架構裡的門店1，理論上隻能管理門店1的數據，但如果門店4這種不在同一個上級節點的門店，希望幫忙分析售後問題，那賬号5如何跨節點管理門店4的售後問題。

答案是門店4的管理者可以指定某些數據或節點的所有數據共享給門店1的賬号5管理。

數據共享不限制組織結構的上下級和同級關系。

二、角色解決功能權限（RBAC模型）

1. 基礎角色權限模型（RBAC0）

為什麼要靠角色來解決功能權限，而不是使用賬号跟功能直接關聯？是因為平台頁面多，頁面内的功能也非常多的情況下，如果靠賬号直接跟頁面和功能關聯，所有賬号都操作起來比較繁瑣。

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

同一個賬号，可以有多個角色，則可獲得多個角色的并集的權限。如賬号4關聯員工和助理兩個角色，則賬号4可獲得員工角色對應的頁面3、頁面4和助理角色對應的頁面5的功能權限。

2. 角色搭建組織架構（RBAC1）

對于組織架構沒有那麼複雜的，則會有使用角色來實現組織架構的，角色設計成帶有上下級的樹形結構。

這種實現方式靈活性會比較差，如果組織架構複雜，則角色量比較多，同樣一個店長角色，需要在每個組織架構的節點上都進行單獨創建。一般不會采用這種實現方式。

3. 角色互斥場景（RBAC2）

實際業務場景中，存在同一個賬号不能同時獲得兩個角色，兩個角色互斥，有這個角色就不能獲得另外一個角色。

财務中的會計和出納兩個角色，一個人是不能同時負責，做到财權分離。

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

4. 角色同時有組織架構和角色互斥（RBAC3）

複合型的RBAC1 RBAC2的一種合成形式，角色上既有組織架構，又有角色互斥的實現形式。

三、賬号關聯角色或組織内的崗位

1）賬号隻綁定角色來同時獲得功能權限和數據權限。

如上圖所示，把角色當成崗位，可将角色直接與組織架構關聯，賬号隻需與角色關聯，不用單獨關聯組織架構，則賬号直接獲取當前角色下的功能權限和角色對應的組織架構下的數據權限。

這樣如果賬号需要調整崗位時，直接調整賬号對應的角色就可以，方便操作。

但這種需要在每個節點上創建好崗位和對應節點的角色，角色的數據量會比較多，每個角色都要配置對應的功能權限。

2）賬号隻綁定組織架構内的崗位來同時獲得功能權限和數據權限。

在組織架構上創建崗位，崗位和對應的角色關聯，賬号直接跟組織架構上的角色進行關聯，同時獲得角色權限，無需再關聯角色。

賬号在調崗時直接更換組織架構中的崗位就可以。

這種和上面的場景一樣，都需要頻繁重複創建一樣的内容。

四、審批流程業務場景。

上面介紹的賬号與角色和組織架構關聯來解決功能權限和數據權限的問題，但涉及到審批流程的，如在門店1内部，服務員請假，需要店長審批，但兩個人都屬于同一組織架構的門店1上，沒有上下級關系，隻能在流程上指定人去審批。

但這樣每個部門内部都需要自己創建審批流程，操作起來比較繁瑣。

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

• 例如請假，可在審批流程中設定門店的員工角色請假都要讓門店的店長或管理者角色審批，這樣所有的門店都遵照這個流程。
• 例如報銷流程需要走門店店長和區級财務經理這兩個審批。如果報銷一定金額，需要走分公司的财務副總這個人審批，則需要在流程中支持指定人來審批的功能。但一般不建議指定人審批，後續人員調整，審批流程也要做相應調整。

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

如财務報銷走到了朝陽區的财務角色，下面有賬号3和賬号4，則賬号3和4都可以審批，本着誰審批，誰負責的原則。

如果賬号3審批了某個報銷單，後續打款也應當走到賬号3上來進行審批。

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

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

六、總結

目前基于SaaS平台的現有業務和未來管理類的業務特點，一般會采用标題1、标題2和标題6三種結合的形式，來分别解決功能權限，數據權限，和審批流程的權限。

本文由 @阿白 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部