編輯導語：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都是在其基礎上擴展後得到的。

其主要由用戶、角色、權限三個元素構成，通過将具有權限集合的角色賦予給用戶，從而使用戶獲得該角色下的權限。一個用戶可以關聯多個角色，每個角色可以關聯多個用戶，同時一個角色也可以關聯多個權限，角色通常可以視為一組職能相似的用戶的集合，同時也是一組權限的集合。

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協議。

,

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

查看全部