起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識系統權限設計：以SAAS為例
編輯導語：B端產品數據復雜、業務流程繁瑣、用戶角色眾多，要保證使用中的安全，就需要一個合理的權限設計。在這篇文章中，作者以SAAS為例，分享了一些權限設計的經驗，一起看看吧。
B端產品具有數據復雜、業務流程繁瑣、用戶角色眾多的特點，為了保障企業使用過程中系統數據的安全性，一個合理的權限設計是非常重要的，尤其B端SAAS產品具有多租戶的概念，一個產品需要供眾多客戶使用，其對權限控制的要求會更高。
一、什么是權限設計
1. 權限的定義
權限一詞在詞典的解釋是行駛權利的界限與范圍。軟件系統中的權限通常指的是對用戶在系統中可查看什么數據、頁面、可進行什么操作的限定。
2. 權限的分類
從上述權限的定義中可以看出，權限主要可以分為數據權限、頁面權限、操作權限三類。
（1）數據權限
數據權限是指用戶能否查看某些數據的權限，用戶能查看的數據范圍，就是該用戶的數據權限。在系統中不同的用戶在同一個頁面通常查看的數據范圍是不同的，比如診所負責人和診所醫生都具有查看患者信息的權利，但是通常情況下診所醫生只能查看其號源下的患者數據，診所負責人可以查看診所下所有的患者數據。
實現數據權限隔離的方案有如下幾種：
通過組織機構樹控制：該方案根據賬號所在組織機構樹中的節點位置，來判斷能夠查詢的數據范圍。這種方式相對比較復雜，但是最靈活，能夠支持各種復雜的業務數據權限訴求。
通過客戶地區控制：該方案根據賬號所在區域來判斷允許查看的數據范圍。這種方式簡單、容易實現，但是靈活性差，只能滿足非常初級的數據權限管理訴求。
通過將數據權限轉化為頁面權限：該方案是通過將用戶能查看哪些數據通過頁面的方式進行隔離，賦予用戶對應的頁面權限就可以查看相應的數據。這方案下同樣的功能界面會被分割成很多個功能相同數據不同的頁面。
（2）頁面權限
頁面權限指的是用戶登錄系統后可以看到哪些頁面的權限，通常情況下通過導航欄的功能模塊來控制。以門診醫生和收費員兩個角色為例，門診醫生可以進入醫生工作站模塊不能進入收費站；收費員可以進入收費站但是不能進入醫生工作站。
（3）操作權限
操作權限指的是用戶對頁面內功能按鈕的具體操作權限，如：新增,修改,刪除,審核等。這里的功能按鈕指的是該頁面最大的功能按鈕集合，因為現在的設計通常是所見既能操作，如果用戶不具備某個功能的權限，頁面內不會顯示該功能按鈕，以免造成額外的體驗負擔。從大的方面來說頁面權限和操作權限可以統稱為功能權限。
二、權限設計
1. 權限設計的相關步驟
在網上查看大量文章后發現，權限設計主要有角色梳理、權限點梳理、權限模型設計、相關原型設計等幾個步驟。
2. 權限模型
元素名次解釋：
- 用戶：權限的擁有者。
- 角色：用于連接主體（用戶）和權限的橋梁。
- 權限：用戶可以訪問的資源。
（1）ACL訪問控制列表
通過將用戶與權限（資源）直接進行關聯綁定進而實現權限配置。以實現患者列表頁中刪除功能的權限配置為例，將刪除功能的權限直接賦予用戶，被賦予權限的用戶可執行刪除操作。
這種權限模型的優點是可以為用戶提供個性化的權限配置，缺點是這種方式對權限的管理比較分散，同一個權限無法快捷的同時指定給一群用戶，如果需配置的權限很多，或者用戶基數很大的時候會非常的費時費力，人工成本極大。
還是以上訴【刪除】功能為例，只有一個人需要【刪除】權限和有100人需要【刪除】權限，配置的難度是完全不同的。
（2）DAC自主訪問控制
DAC與ACL的權限配置方法是相同的，區別是擁有權限的用戶可以自主地將權限賦予給未擁有權限的用戶。
（3）MAC強制訪問控制
在MAC模型中，用戶與權限（資源）都具有權限標識，用戶是否能訪問或執行權限對象取決于雙方關系的對照。以患者列表頁中【刪除】為例，用戶被規定可以執行刪除操作，但是【刪除】的權限設置中不具有該用戶，則用戶無法執行刪除，只有當【刪除】的權限下同樣具備該用戶時才能執行刪除。通常機密強度較高的會采取這種方法。
（4）RBAC基于角色的訪問控制
RBAC認為權限授權實際上是 Who What How 的問題, 即 “Who 對 What 進行 How 的操作”。是”用戶”對”資源”的操作, 其中Who是權限的擁有者 (用戶) , What 是資源（權限）。
RBAC可以細分為下面四種類型：
- 基本模型 RBAC0 (Core RBAC)
- 角色分層模型 RBAC1 (Hierarchal RBAC)
- 角色限制模型 RBAC2 (Constraint RBAC)
- 統一模型 RBAC3 (Combines RBAC)
RBAC0：
RBAC0是RBAC模型的核心，是支持RBAC模式的任何產品的最低需求，RBAC1、RBAC2、RBAC3都是在其基礎上擴展后得到的。
其主要由用戶、角色、權限三個元素構成，通過將具有權限集合的角色賦予給用戶，從而使用戶獲得該角色下的權限。一個用戶可以關聯多個角色，每個角色可以關聯多個用戶，同時一個角色也可以關聯多個權限，角色通?？梢砸暈橐唤M職能相似的用戶的集合，同時也是一組權限的集合。
RBAC1：
RBAC1是在RBAC0的基礎上引入了角色繼承的概念，通過繼承使角色之間具有了上下級關系。比如一個父級角色下包括多個子級角色，子級角色的權限來自于父級角色的一部份。以診所系統醫師為例，假設將醫師設定為一個父級角色，普通醫師、副高級醫師作為其子級角色，則普通醫師與副高級醫師的權限集合包含于醫師的權限集合。
RBAC2：
RBAC2是在RBAC0的基礎上引入角色約束控制（職責分離）。職責分離指的是用戶之間的責任和權限相互分離，通俗一點說就是同一用戶不能擁有兩種特定的權限，比如運動員不能是裁判一樣。
系統中職責分離主要有靜態職責分離和動態職責分離兩種。
靜態職責分離：
靜態職責分離是在用戶和角色的指派階段加入的，主要的約束形式有以下幾種：
- 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個
- 基數約束：一個用戶擁有的角色是有限的，一個角色擁有的權限也是有限的
- 先決條件約束：用戶心啊更要活的高級角色，首先必須擁有低級角色
動態職責分離：
動態職責分離的表現是一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。
RBAC3：
RBAC3是RBAC1與RBAC2的合集，所以其是既具有角色分層又有約束的模型。
（5）ABAC基于屬性的訪問控制
不同于上面幾種用戶通過某種方式關聯到權限的方式，ABAC是通過動態計算一個或一組屬性是否滿足某種條件而進行授權判斷。（該模型相對比較復雜，相較于RBAC目前的運用也不廣泛，所以這里就不詳細介紹了，不過有的人稱ABAC是權限的未來，因為它能夠適應更加復雜的權限分配場景）
三、SAAS權限設計（案例）
根據業務情況選擇通過RBAC模型與系統的組織架構進行權限設計。
1. 角色關系梳理
權限設計的前提是合理的角色設計，由于考慮到部分數據權限需要通過組織結構來進行控制，所以在梳理角色時也分為了組織架構角色梳理和診所內部角色梳理兩個階段。
（1）組織架構角色梳理
組織架構：
組織架構解釋說明：
整個架構通過賬號、員工、組織部門來完成搭建。客戶指的是SAAS系統的租戶；圖中每一層都設有一個賬號，該賬號可以管理同層的組織；賬號0是SAAS系統根賬號即平臺管理員賬號；賬號1是客戶1的根賬號，是公司負責人擁有，具有新增診所等功能；賬號2代表診所的根賬號，一般被診所負責人擁有；賬號3則是部門科室的負責人賬號；賬號4則是部門其他員工擁有。
角色梳理：
組織架構通常在產品初期就已被確定，權限設計階段只需要抽象角色即可。通過組織架構梳理出的角色大都具有向下管理的權限，即管理員屬性。角色與現實中的職位以及業務有緊密的關系，可以將角色與職位進行關聯，然后通過某個職位的工作職責進而確定對應角色在系統中的核心動作有哪些，最后將信息進行整理。
如下：（表中信息僅用來舉例）
（2）診所內部角色梳理
診所內部的角色即組織架構中的員工層，通常在項目前期中的業務調研階段就已經被確定好，在權限設計階段同樣可以直接使用。相較于組織架構中的角色，診所內部角色和患者業務的關系更加緊密。如下：（表中信息僅用來舉例）
2. 系統權限點梳理
系統權限點梳理主要針對頁面權限和操作權限。頁面權限可以通過導航菜單進行梳理，將所有的菜單都列舉出來（包括一級菜單和二級菜單）；操作權限則是需要梳理出頁面下的所有可操作點，這里要注意有的操作點會應狀態改變發生變化，在列舉時也要加上。這一步會得到初步的權限列表，如下：
3. 權限方案設計
由于不同企業、不同診所中對員工職位內容的界定不一樣，因此在系統中我們需要提供用戶自定義權限配置的功能，并將該功能的權限默認開通給租戶對應的根賬號，通過這個功能用戶可以自定義角色，自定義角色擁有的權限。大多數SAAS產品都提供權限自定義配置的功能。
這里有個問題，既然用戶可以自己進行權限配置，為什么我們還要花大量時間整理角色和權限呢？
這是因為用戶并不像我們對權限非常了解，權限配置相對用戶來說是一個比價復雜的工作，配置成本高，通常情況下SAAS產品提供者需要對用戶進行這方面的培訓，所以為了減輕權限配置負擔，我們可以將一部分通用的角色抽象出來，比如租戶根賬號負責人、診所負責人、醫師、理療師等，為這些角色配置默認權限供用戶直接使用。
組織架構角色通常情況下都可以定義為通用角色。（模型圖省略）
（1）頁面、操作權限
用戶的頁面權限和操作權限通常在權限配置界面進行勾選即可。
數據權限：
通過系統的組織架構我們可以看出不同租戶之間的數據需要進行隔離；同一個租戶下不同診所的數據也需要進行隔離，但是需要滿足租戶查看所有診所的數據的需求。
診所內部的數據權限主要集中在患者病歷信息，患者病歷的權限需要根據病歷的流轉發生變化。比如一個患者掛號后，患者信息流轉至掛號醫生處，該醫生獲得查看該患者所有病歷的權限，醫生開具收費處方后，患者信息流轉至收費處，收費員即獲得查看該患者本次病歷信息的權限。
根據用戶對數據權限的需求，可以從以下幾個方面進行實現：
方案一：自定義配置
可以將數據權限同頁面權限一樣放入自定義權限配置中，比如查看患者病歷信息用戶通過選擇本公司、本診所、本科室、本人幾個選項去進行數據控制。
方案二：借助頁面（功能）隔離數據
通過控制角色對頁面的訪問實現患者病歷數據的隔離。比如將患者病歷數據設計成不同的頁面，如：我的患者、科室患者、診所患者、公司患者，具有“我的患者”頁面權限的即可查看本人下的患者，具有“科室患者”頁面權限的即可查看科室下的患者。
方案三：組織架構
通過角色將賬號與系統組織架構進行關聯，組織架構圖中上級賬號可以查看下級賬號的所有數據。
最終的的方案需要結合實際業務選擇，在這個案例中選擇通過組織架構進行數據權限的控制會更加合適。具體的方案可抽象為：用戶在系統增加一個診所，增加診所的同時系統生成一個診所負責人角色，且該角色不支持修改、刪除，被授予該角色的賬號可以查看診所所有數據；用戶在系統增加一個科室，系統默認生成一個該科室管理員角色，且該角色不支持修改、刪除，被授予該角色的賬號即是該部門中的上級賬號，可以查看該部門中的所有數據。例如用戶在系統中增加了新的科室–“中醫科”，在科室生成的同時系統生成該科室的默認管理員角色–“中醫科主任”。
最后提一點通常平臺管理員賬號的權限僅限于控制客戶的賬號和相關信息，不能夠控制客戶內部的業務。
4. 梳理用戶獲取權限流程
用戶獲取權限主要包括以下場景：
場景一：新員工加入系統配置權限
為新員工配置權限的常規流程是：在員工管理模塊添加員工，填寫基礎信息，選擇部門，然后賦予角色，最后完成權限配置。由于流程較為簡單這里就略過流程圖了。
場景二：老員工需要更改權限
老員工更改權限流程是：在員工管理模塊找到目標員工，更改其系統角色，完成權限更新。
5. 頁面原型設計
由于頁面原型較為簡單這里僅展示角色與權限配置界面。
（本案例中的組織架構角色與診所內角色唯一的差別在于數據權限的不同，其他相關的功能權限兩者都可以通過自定義權限配置進行編輯）
四、總結
B端產品的權限設計主要包括數據權限與功能權限（頁面權限與操作權限）兩個方面，通常情況下采用RBAC模型實現權限設計，整體步驟包括角色梳理、權限點梳理、實際方案設計、原型設計幾個步驟。
B端SAAS產品通常會提供自定義權限配置功能，以滿足各租戶之間的差異化需求，自定義配置可以很靈活的解決功能權限的配置，在這方面不需要我們費太多精力。在設計過程中，我們的重心應該放在角色的抽象和數據權限的實現方案兩方面。
本文由 @醫療PM-大明 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
租戶自定義的角色，跟系統預置的角色，在表后臺表怎么設計呢？