本篇是繼上次的《關于SaaS平臺中應對多租戶模式的設計》發文的一個補充，是關于權限模塊的設計。同時，在本篇也會引用一些專業術語、產品規劃和方向以及經驗的分享。
1、背景
? ? 上次寫的關于《SaaS平臺中應對多租戶模式的設計》之后，在微信上繼續收到了朋友的一些提問。在溝通的過程中，我們針對權限設計這塊有了較多篇幅的討論。
? ? 最開始時，我把我當前的一個saas項目的權限設計方案給他講了一遍，但是對方的結果是，“可能太復雜了，不太適合”。其中也提出了各自不同的觀點和建議。在后來下班回家的路上，我把白天所探討的內容作了一下梳理和回顧。也找到了所謂分歧的根源原因。其實根本原因，是我們都只站在了各自的業務上或平臺上來進行討論，忽略了問題的根本性的本質問題。所以就有了各自的不同建設方案和質疑。
2、概要
? ? 在不同的系統中，其實關于權限設計是沒有標準方案的。一般地，依據項目需求進行系統的功能規劃設計、組織結構設計以及對應的權限設計等即可。權限管理是所有后臺系統的都會涉及的一個重要組成部分，主要目的是對不同的人訪問資源進行權限的控制，避免因權限控制缺失或操作不當引發的系統風險問題。從而有效的保證人、角色、資源的有效控制，避免數據不當的操作、隱私數據的泄露等問題。
3、RBAC模型
? ? 3.1、? 概念
? ? 其實，關于權限設計最常見的就是基于RBAC模型。而RBAC模型又有RBAC0、RBAC1、RBAC2、RBAC3等幾種常見的模式。RBAC（Role-Based Access Control) 基于角色的訪問控制的設計思想。作為傳統訪問控制（自主訪問，強制訪問）的有前景的代替受到廣泛的關注。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。RBAC中有4個比較關鍵的元素：用戶 – 角色 – 權限 – 資源。
? ? 3.2、? RBAC支持的安全原則
? ? RBAC支持三個著名的安全原則：最小權限原則、責任分離原則和數據抽象原則。
? ? ? ? 最小權限原則：RBAC可以將角色配置成其完成任務所需的最小權限集合。
? ? ? ? 責任分離原則：可以通過調用相互獨立互斥的角色來共同完成敏感的任務，例如要求一個計賬員和財務管理員共同參與統一過賬操作。
? ? ? ? 數據抽象原則：可以通過權限的抽象來體現，例如財務操作用借款、存款等抽象權限，而不是使用典型的讀、寫、執行權限。
? ? 3.3、 RBAC優缺點
? ? （1）優點：
? ? ? ? 簡化了用戶和權限的關系。
? ? ? ? 易擴展、易維護。
? ? （2）缺點：
? ? ? ? RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難適應哪些對操作次序有嚴格要求的系統。
? ? 3.4、? 這里補充一下術語解釋：
? ? （1）、資源
? ? ? ? 被安全管理的對象（Resources頁面、菜單、按鈕、訂單等）。
? ? （2）、 權限
? ? ? ? 訪問和操作資源的許可（Permit刪除、編輯、審批等）。
? ? （3）、角色
? ? ? ? 用戶通過業務需求確定一個角色（Role），并按照實際的業務場景，賦予角色對應的權限的過程，角色也可以理解是權限的集合，是眾多權限顆粒組成。
? ? （4）、 用戶
? ? ? ? 系統實際的操作員（User）
? ? （5）、操作權限
? ? ? ? 頁面權限：即用戶登錄系統可以看到的頁面，由菜單來控制，菜單包括一級菜單或多級菜單。當系統賦予用戶對應菜單的權限，那么用戶就可以訪問對應的菜單頁面。
? ? ? ? 操作權限：即頁面的功能按鈕，包括：查看、新增、修改、刪除、審核等。當用戶點擊按鈕時，系統將會校驗用戶的是否包含次操作權限，如果有，就可以進行下一步操作。
? ? ? ? 數據權限 ：數據權限就是用戶在同一頁面看到的數據是不同的。比如項目管理員，就能看到當前團隊正在進行中的項目，以及項目的進度情況。而團隊成員，就只能看到本人具體參與的項目，已經項目信息。相對于復雜一項的權限也可以基于組織結構來拓展。
? ? 總的來說，一般我們會這樣來用一句話更好的理解它：【用戶(user：誰)】被賦予【角色(role：具有1-n個權限)】，通過角色關聯的【權限(permit：許可)】去訪問/操作【資源(resource)】。如下圖：
? ? ? 3.5、? RBAC0模式
? ? ? ? 這是權限最基礎也是最核心的模型，基本上絕大多數就是基于它來建設，包括用戶、角色、權限。其中用戶和角色可以是多對多的關系；角色和權限也是多對多的關系。
? ? ? ? 用戶是發起操作的主體，可以是業務性的訪問者、可以是后臺管理系統的用戶。角色起到了橋梁的作用，連接了用戶和權限的關系。由于角色和權限的關系是多對多，而用戶與角色也是多對多的關系，所以一個用戶就有一個或多個角色一個或多個系統權限（這里關于針對比較簡單的系統，例如用戶量很小，項目級別也很小的系統，可以采用用戶直接和權限關聯。也就是添加一個用戶，就直接針對用戶去添加對應的權限，可以沒有角色的概念。針對這種情況，在此不展開討論）。
? ? ? ? 一般的系統中，引入角色（Role）就是為了提升了系統操作的效率和拓展性。權限是用戶可以訪問的資源，包括：頁面權限、作權限、數據權限等（具體解釋看上面的術語部分）。下面用具體的圖例來展示：
? ? ? ? 3.6、? RBAC1模式
? ? ? ? ? RBAC1模式是RBAC0的拓展。主要是在角色上引入了角色繼承（Hierarchical Role）的概念。即角色具有上下級的關系，角色間的繼承關系可分為一般繼承（General）和受限繼承（Limited）關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現角色間的單繼承，受限繼承則增強了職責關系的分離。這種設計可以給角色分組和分層，一定程度簡化了權限管理工作。
? ? ? ? ? ? ? 這里舉一個場景例子，比如銷售團隊，銷售主管或經理一般會需要了解并匯總下面銷售專員的數據。而銷售專員能夠管理各自的銷售數據。此時，銷售主管就需要向下繼承銷售專員的角色，進而也就擁有了他們的基本權限。
? ? ? ? 3.7、? RBAC2模式
? ? ? ? ? ? RBAC2同樣建立在RBAC0基礎之上，僅是對用戶、角色和權限三者之間增加了一些限制，實現了責任分離。RBAC2中的一個基本限制是互斥角色的限制，互斥角色是指各自權限可以互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。該模型有以下幾種約束：
? ? ? ? ? ? ? ? （1）互斥角色
? ? ? ? ? ? ? ? ? ? ? 同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。互斥角色是指各自權限互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
? ? ? ? ? ? ? ? （2）基數約束
? ? ? ? ? ? ? ? ? ? ? 一個角色被分配的用戶數量受限；
? ? ? ? ? ? ? ? ? ? ? 一個用戶可擁有的角色數目受限；
? ? ? ? ? ? ? ? ? ? ? 同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配。例如公司的領導人有限的。
? ? ? ? ? ? ? ? （3）先決條件角色
? ? ? ? ? ? ? ? ? ? ? 可以分配角色給用戶僅當該用戶已經是另一角色的成員；對應的可以分配訪問權限給角色，僅當該角色已經擁有另一種訪問權限。指要想獲得較高的權限，要首先擁有低一級的權限。
? ? ? ? ? ? ? ? （4）運行時互斥
? ? ? ? ? ? ? ? ? ? ? 允許一個用戶同時擁有多個角色，但在系統運行中或部分特殊場景不可同時使用這兩個角色，只能使用其中一種角色。
? ? ? ? ? ? 這些限制可以分成兩類，即靜態職責分離SSD（Static Separation of Duty）和動態職責分離DSD（Dynamic Separation of Duty）。
? ? ? ? ? ? ? ? （1）靜態職責分離（SSD）
? ? ? ? ? ? ? ? ? ? ? 當角色授權給用戶時，需要判斷當前用戶是否被賦予了一個與新角色沖突的角色，沖突的角色位一個二元關系，任何一個用戶在此場景下只能擁有其中一個角色。
? ? ? ? ? ? ? ? （2）動態職責分離（DSD）
? ? ? ? ? ? ? ? ? ? ? 在角色分配時可以將沖突的角色賦予給同一個用戶，但是在用戶使用系統時，一次會話中不能同時激活兩個角色。
? ? ? ? ? 3.8、? RBAC3模型
? ? ? ? ? ? ? ? 即最全面的權限管理，它是基于RBAC0，將RBAC1和RBAC2進行了整合。這種模式即要維護好角色間的繼承關系處理好分層，又要處理角色間的責任分離。模型公式：RBAC3 = RBAC1 + RBAC2 。
4、場景實戰
? ? 4.1 需求場景
? ? ? ? 我們目前在做一款toB的產品，采用SaaS的模式對外B端客戶提供服務。目標就是如何規劃好平臺的管理、租戶的管理、租戶應用的管理以及租戶業務流程等內容的管理。我們將SaaS平臺基本角色分為平臺管理員、平臺運維、平臺開發、租戶管理員、租戶子管理員、租戶其他角色組成。在這里，我將我們SaaS服務的權限部分設計分享出來。
? ? ? ? 4.2 設計說明
? ? ? ? ? ? ? ? 我們這套設計，涉及兩部分，即完整的企業組織結構和角色組。所以這里針對部分概念進行說明。
? ? ? ? ? ? ? ? 4.2.1 組織（部門）
? ? ? ? ? ? ? ? 針對toB的產品，往往要考慮如何支撐起企業的組織結構，比如企業的部門層級。同時組織結構也可以與角色進行關聯，用戶加入組織后，就會自動獲得該組織的默認角色。同時用戶在調崗時，只需調整組織、角色即可批量調整。組織的另外一個作用是控制數據權限，把角色關聯到組織，那么該角色只能看到該組織下的數據權限。
? ? ? ? ? ? ? ? 4.2.2 用戶組（角色組）
? ? ? ? ? ? ? ? ? 在系統中，存在相同屬性或操作功能的用戶存在。隨著使用的用戶基數增大、角色類型增多時，分配的工作就會越發的繁瑣。這里可以增加用戶組的概念來統一規劃這一部分用戶的權限管理。在上面的設計中，角色組中的崗位、職位就充當了這部分的作用。以后其他用戶加入對應的用戶組（角色組）后，即可自動獲取用戶組的所有角色。退出用戶組，同時也撤銷了用戶組下的角色，無須管理員手動管理角色。
? ? ? ? ? ? ? ? 4.2.3? 職位 / 崗位
? ? ? ? ? ? ? ? ? 每個組織部門下都會有多個職位或崗位，比如IT技術部會有技術總監、技術經理、研發組長、開發等職位。雖然都在同一部門，但是每個職位的權限是不同的，職位高的擁有更多的權限。研發總監擁有所有權限，研發組長和開發擁有部分權限。有些特殊情況下，一個人可能身兼多職。
? ? ? ? ? ? ? ? 4.2.4? 角色
? ? ? ? ? ? ? ? ? ? 角色是權限控制的最小單位（不是權限的最小單位），通過角色來進行權限資源的分配。在上面的設計中，就是遵循RBAC模式進行的設計。例如管理角色組，就涉及到了RBAC1，主管理員同時擁有子管理員的權限；同時也涉及到了RBAC2，一個組織只能有一個主管理員（基數約束 ），但是可以有多個子管理員。
? ? ? ? ? ? ? ? 4.2.5 含有組織、職位、用戶組、角色模型
? ? ? ? ? ? ? ? ? ? 通過根據以上場景，平臺的權限模型設計如下圖:
? ? ? ? ? ? ? ? 以上基本就是關于我們一個項目的權限設計部分。
5、回歸討論點
? ? ? 關于溝通的問題，總的來說有以下幾點：
? ? ? ? ? 1、對權限專業知識的學習和理解。
? ? ? ? ? ? ? ? 我記得在《致2019年的自己》總結中，也重點提到就是建立相應專業知識體系。為什么這個比較重要呢。在這里插入一個笑話。有次一小伙和我討論關于SaaS。剛開始我給他介紹了我的一些SaaS的理解。而后讓我比較頭疼的是，對方聊的并非SaaS，而是“sass”。這區別可大了去。前者是服務設計模式或方法，后者是前端的一種CSS的技術。
? ? ? ? ? ? ? ? 回歸正題，我們應該要建立起相對專業的知識體系，這個可能直接影響到我們對知識的認知、業務架構的設計等方面。同時在溝通過程中是否能在同一個點開展討論，而不造成尷尬的局面。在溝通過程中，采用相對專業的術語，大家一聽就懂并很快能領會。如果采用自己的語言可能造成對方無法理解（之前工作中也出現過笑話，這里就不展開了）。
? ? ? ? ? 2、需求設計者應了解相關的知識，而并非標榜“我是做需求的”。
? ? ? ? ? ? ? ? 其實，關于系統的設計、技術的選型是由需求來驅動的。畢竟項目管理最后要落眼到成本、進度上。我見過一些需求設計，需求點可能是不錯的，但是缺乏相應的知識了解，導致在傳達上或原型設計上出現的偏差甚至是錯誤。就以權限為例，我們在這個項目上其實走了一些彎路，核心的問題就在于需求，由于對于權限一些知識不了解，造成設計稿只能按照意思設計出來，研發卻實現出現問題。這里就體現的專業知識的重要性。需求設計者不一定要深層次的研究技術，而是要了解并理解它們的一些基本原理和設計思想。尤其是在和技術研發溝通過程中，如果采用的是專業性的知識溝通，那么既能節約溝通成本，也能縮小理解上的誤差，更重要的是系統架構結構設計趨向更加穩定。
? ? ? ? ? 3、靈活的運用對應知識
? ? ? ? ? ? ? ? 一個技術的學習和理解，并不代表照抄照搬。比如，我在同朋友針對權限這塊的交流中，真正的價值是對于權限的設計思路和方法，而并非某個項目上的具體實現。畢竟項目的“獨特性”不能忽略。因為每個項目的業務不同，面對的用戶群體不同，所以權限的具體細節自然不同。所以我們應該更加側重于權限體系的知識，可以拓展對于不同場景，應該如何來設計。所以，我們應該先對一個知識有一定的學習和理解，接著就是靈活的應用和整合。
最后，知識無盡頭，請保持好持續學習！? ? ?
