起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識SaaS平臺權限架構
編輯導語：對于業務較多的公司來說，組織結構相對復雜，這時候平臺的權限架構就顯得尤為重要，本篇文章作者分享了有關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個賬號綁定多個角色時方便操作，倒不如直接建個新的角色綁定賬號。
- 用戶組，就是多個賬號的合集，為了在多個賬號綁定同一個角色時方便操作，并沒有解決解決具體權限問題。
六、總結
目前基于SaaS平臺的現有業務和未來管理類的業務特點，一般會采用標題1、標題2和標題4三種結合的形式，來分別解決功能權限，數據權限，和審批流程的權限。
本文由 @阿白 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
可不可以這樣，角色用來管理數據、功能權限；而崗位用來管理審批流，這樣角色和崗位分開是不是更清晰
角色管理數據權限靈活性太差，建議角色管理功能權限，節點和用戶管理數據權限，崗位可以管理審批流。
請問這個節點和用戶管理數據權限，具體是怎么樣呢，數據權限是不是就是默認我管理的組織范圍下的數據
實用干貨，學到了
不錯的文章，點個贊，加你微信，還請通過一下
大佬請教下，我們有這樣的業務場景
用戶A在部門1 是角色a，可以看到1部門1所有數據，在部門2 是角色b，可以看到部門2自己的數據，部門1和部門2是平級部門
用戶B在部門1是角色c，但是他需要負責部門2345產生的數據的下一步處理
請問這種情況怎么處理~~
關于A的問題，系統支持用戶屬于多個組織架構就可以，數據權限跟著組織價格，用戶A掛在1和2兩個部門（組織架構）下面，1部門分配部門所有數據權限，2部門分僅限自己的數據權限。
關于用戶B，可以通過數據權限中的場景5分享數據權限功能，把2345的數據權限分配給用戶B。
大佬能加個微嗎，請教下問題
請問總結中提到的標題6是指哪一點？
勘誤，應當是標題4，抱歉。
請教個問題：租戶的用戶是否需要設計狀態？租戶到期之后再續費，續費賬號數和之前不一致，這種場景怎么處理？
1、租戶下的用戶肯定是要有狀態，租戶自己也可以調整用戶能不能登錄系統。
2、關于續費的賬號數問題，可以設定租戶超級管理員賬號可用，指定角色（系統管理員角色）賬號可用，指定數量老賬號可用，或僅限超級管理員可用，超級管理員再啟用可用的賬號。各有優缺點，根據自己業務需要定一個規則就行。
有個問題想請教下，一個關于RBAC模型的問題 RBAC模型是根據“角色”去判斷權限的 但實際業務場景有不同用戶是同一“角色” 但是不同權限點的情況 如果用創建多個“角色”來解決的話 覺得不太靈活 想到了改變這個模型 把權限直接和“用戶”掛鉤 而不是“角色” 但這個模型就變了 會不會用戶更難理解
確實會存在要建多個角色的情況，你說的這種是最簡單的用戶和權限掛鉤的實現方式，如果用戶不多的情況下可以這么做。但如果同權限的用戶多的話，就要重復配置權限，倒不如用角色來的簡單。
是不是可以在加一個角色的數據權限就可以了
那基本上就是角色同時管理功能權限和數據權限了。
請教一個問題，給到租戶的是一個總賬號，然后通過總賬號去管理一個租戶系統，通過子賬號角色去隔離功能。那開發者公司的管理總后臺發放租戶總賬號，是租戶總賬號的更上一層的賬號嗎（或者說開發者公司的管理后臺和租戶的系統平臺其實也是賬號角色去隔離功能的？）還是租戶系統和開發者公司管理后臺是兩套獨立的，通過接口關聯的呢
你說的這是兩種實現方式，一種是租戶的上層賬號，這種維護的平臺少，相對簡單。另外一種是單獨做一套內部使用的系統，通過接口關聯，可拓展性強。
感謝分享，受益了
相互學習哈。
學到了，看似負責難懂的東西，跟著流程走，用對方法，會提高很多效率
大家相互學習哈。