saas平臺由于其本身“按需購買”的特性暇榴，在設(shè)計規(guī)劃權(quán)限時惊橱，需要考慮統(tǒng)一配置權(quán)限如何規(guī)避企業(yè)沒有購買的應(yīng)用最住，以及如有部分應(yīng)用存在數(shù)據(jù)權(quán)限不同的問題。現(xiàn)在愈污，本文簡單總結(jié)一下當(dāng)前saas模式下權(quán)限的幾種設(shè)計方式耀态。

作為一個B端平臺型產(chǎn)品，系統(tǒng)的權(quán)限設(shè)計是其中一個非常重要的組成部分暂雹，沒有權(quán)限管理的系統(tǒng)仿佛一個沒有門的房子首装，任何人都可以隨意查看甚至調(diào)整，對系統(tǒng)的安全性存在非常大的隱患杭跪，而saas模式下由于應(yīng)用基本獨立仙逻，隨時可能被企業(yè)拆分使用。

這里權(quán)限的統(tǒng)一與拆分問題也十分重要揍魂，本文簡單總結(jié)一下當(dāng)前saas模式下權(quán)限的幾種設(shè)計方式桨醋。

一、權(quán)限管理的重要性

權(quán)限管理一般指根據(jù)系統(tǒng)設(shè)置的安全規(guī)則或者安全策略现斋，用戶可以訪問而且只能訪問自己被授權(quán)的資源喜最，權(quán)限管理基本是任何一個系統(tǒng)的標(biāo)配模塊。它的作用不僅在于保護(hù)系統(tǒng)數(shù)據(jù)安全性庄蹋、防止留下系統(tǒng)漏洞瞬内，更能在龐大的系統(tǒng)下進(jìn)行模塊和數(shù)據(jù)配置，讓不同的角色進(jìn)入系統(tǒng)看到不同的模塊和數(shù)據(jù)限书，最大程度地提高系統(tǒng)的易用性虫蝶。

大部分系統(tǒng)中權(quán)限管理是作為一個獨立的管理入口，統(tǒng)一設(shè)置所有的業(yè)務(wù)的權(quán)限倦西。而saas平臺由于其本身“按需購買”的特性能真，在設(shè)計規(guī)劃權(quán)限時，需要考慮統(tǒng)一配置權(quán)限如何規(guī)避企業(yè)沒有購買的應(yīng)用扰柠，以及如有部分應(yīng)用存在數(shù)據(jù)權(quán)限不同的問題粉铐。

二、抽象權(quán)限組成

權(quán)限到底是名詞屬性還是動詞屬性卤档，還是名詞蝙泼、動詞屬性均包含，這對于權(quán)限的含義很重要劝枣。如果是名詞屬性的話汤踏，那么它應(yīng)該是有具體的指代物织鲸；如果是動詞，則應(yīng)該具有行為表示溪胶。

權(quán)限的名詞屬性：api接口搂擦、頁面、功能點载荔。權(quán)限的動詞屬性：可操作盾饮、不可操作。那么我們現(xiàn)在來看懒熙，其實權(quán)限是名詞丘损、動詞屬性，它一定是表達(dá)了兩層含義工扎。即控制的對象徘钥、操作。

向上引申可將權(quán)限劃分為3個組成部分：

頁面權(quán)限：用戶可以看到那些頁面肢娘；操作權(quán)限：用戶可以在頁面內(nèi)進(jìn)行那些操作呈础，增刪改查等；數(shù)據(jù)權(quán)限：用戶可以看到那些數(shù)據(jù)或內(nèi)容橱健；

三而钞、常見的權(quán)限控制模型

（1）自主訪問控制（DAC：Discretionary Access Control）

系統(tǒng)會識別用戶，然后根據(jù)被操作對象（object）的權(quán)限控制列表（ACL：Access Control List）或者權(quán)限控制矩陣（ACL：Access Control Matrix）的信息來決定用戶的是否能對其進(jìn)行哪些操作拘荡，例如讀取或修改臼节。而擁有對象權(quán)限的用戶，又可以將該對象的權(quán)限分配給其他用戶珊皿，所以稱之為“自主（Discretionary）”控制网缝。

DAC最大缺陷就是所有用戶的權(quán)限不能統(tǒng)一管理，用戶和用戶的權(quán)限比較分散蟋定，后期調(diào)整只能單個進(jìn)行調(diào)整粉臊，不易維護(hù)。

（2）強(qiáng)制訪問控制（MAC：Mandatory Access Control）

在MAC的設(shè)計中驶兜，每一個對象都都有一些權(quán)限標(biāo)識扼仲，每個用戶同樣也會有一些權(quán)限標(biāo)識，而用戶能否對該對象進(jìn)行操作取決于雙方的權(quán)限標(biāo)識的關(guān)系抄淑，這個限制判斷通常是由系統(tǒng)硬性限制且無法回避的犀盟。強(qiáng)制訪問控制多應(yīng)用于對安全性要求比較高的系統(tǒng)，如多級安全軍事系統(tǒng)蝇狼；

（3）基于角色的訪問控制（RBAC：Role-Based Access Control)

RBAC是我們當(dāng)前使用范圍最廣的一種權(quán)限設(shè)計模型，模型基礎(chǔ)就是用戶和角色倡怎，角色和權(quán)限做多對多的對應(yīng)迅耘。標(biāo)準(zhǔn)的RBAC模型包括四個部件模型贱枣，分別為基本模型RABC0、角色分級模型RABC1颤专、角色限制模型RABC2纽哥、統(tǒng)一模型RABC3。

RBAC0（基本模型）定義了完全支持RBAC概念的任何系統(tǒng)的最低需求栖秕。RBAC0的模型中包括用戶（U）春塌、角色（R）和許可權(quán)（P）等3類實體集合，RABC0是權(quán)限管理的核心部分簇捍，其他的版本都是建立在0的基礎(chǔ)上只壳。RBAC1（角色分級模型）基于RBAC0模型，引入角色間的繼承關(guān)系暑塑，即角色上有了上下級的區(qū)別吼句，角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個絕對偏序關(guān)系事格，允許角色間的多繼承惕艳。而受限繼承關(guān)系則進(jìn)一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)，實現(xiàn)角色間的單繼承驹愚。這種模型合適于角色之間的層次明確远搪，包含明確。RBAC2（角色限制模型）引入了角色間的約束關(guān)系逢捺，主要約束規(guī)則包括：角色間的互斥關(guān)系谁鳍，在處理用戶和這些角色之間的關(guān)系時，包括靜態(tài)分離和動態(tài)分離蒸甜，靜態(tài)分離指互斥的角色不能同時賦予同一個用戶棠耕；動態(tài)分離指用戶不能同時操作兩個互斥的角色進(jìn)行登錄。RBAC3（統(tǒng)一模型）同時包含了1和2的特性柠新。

如圖所示窍荧，每個用戶關(guān)聯(lián)一個或多個角色，每個角色關(guān)聯(lián)一個或多個權(quán)限恨憎，從而可以實現(xiàn)了非常靈活的權(quán)限管理蕊退。角色可以根據(jù)實際業(yè)務(wù)需求靈活創(chuàng)建，這樣就省去了每新增一個用戶就要關(guān)聯(lián)一遍所有權(quán)限的麻煩憔恳。

簡單來說RBAC就是：用戶關(guān)聯(lián)角色瓤荔，角色關(guān)聯(lián)權(quán)限。并且在產(chǎn)品和數(shù)據(jù)設(shè)計層面钥组，有更好的擴(kuò)展性输硝，可控制到任意的粒度。

（4）基于屬性的權(quán)限驗證（ABAC：Attribute-Based Access Control）

ABAC則是通過動態(tài)計算一個或一組屬性程梦，來是否滿足某種條件來進(jìn)行授權(quán)判斷（可以編寫簡單的邏輯）点把。屬性通常來說分為四類：用戶屬性（如用戶年齡）橘荠，環(huán)境屬性（如當(dāng)前時間），操作屬性（如讀壤商印）和對象屬性（如一篇文章哥童，又稱資源屬性），所以理論上能夠?qū)崿F(xiàn)非常靈活的權(quán)限控制褒翰，幾乎能滿足所有類型的需求贮懈。該設(shè)計過于復(fù)雜，暫未參透优训。

四朵你、基于RBAC權(quán)限模型的SAAS平臺權(quán)限系統(tǒng)設(shè)計

對于SAAS平臺這樣龐大復(fù)雜的平臺來說，權(quán)限系統(tǒng)設(shè)計得越全面型宙、精細(xì)撬呢、后期的系統(tǒng)擴(kuò)展性就越高，所以這里采用RBAC權(quán)限模型妆兑，RBAC權(quán)限模型是現(xiàn)有比在這方面比較成熟的權(quán)限設(shè)計模型魂拦，應(yīng)用這個模型能解決常規(guī)的系統(tǒng)權(quán)限配置問題，其基本原理也能適用于平臺權(quán)限設(shè)計搁嗓。

RBAC對權(quán)限抽象概括：判斷【W(wǎng)ho是否可以對What進(jìn)行How的訪問操作（Operator）】RBAC支持三個著名的安全原則：最小權(quán)限原則芯勘，責(zé)任分離原則和數(shù)據(jù)抽象原則。最小權(quán)限原則之所以被RBAC所支持腺逛，是因為RBAC可以將其角色配置成其完成任務(wù)所需要的最小的權(quán)限集荷愕。責(zé)任分離原則可以通過調(diào)用相互獨立互斥的角色來共同完成敏感的任務(wù)而體現(xiàn)，比如要求一個計帳員和財務(wù)管理員共參與同一過帳棍矛。數(shù)據(jù)抽象可以通過權(quán)限的抽象來體現(xiàn)安疗，如財務(wù)操作用借款、存款等抽象權(quán)限够委，而不用操作系統(tǒng)提供的典型的讀荐类、寫、執(zhí)行權(quán)限茁帽。然而這些原則必須通過RBAC各部件的詳細(xì)配置才能得以體現(xiàn)玉罐。——來自百度百科

以某物業(yè)公司內(nèi)部信息平臺為例潘拨，該物業(yè)公司平臺分為客戶檔案吊输、房產(chǎn)檔案、收費系統(tǒng)铁追、客服工單等多應(yīng)用結(jié)構(gòu)季蚂，其中物業(yè)公司組織架構(gòu)為多層級，基本樣式如下如。

組織架構(gòu)

應(yīng)用入口

功能頁面

以上我們可以將：

組織架構(gòu)=數(shù)據(jù)權(quán)限應(yīng)用入口以及應(yīng)用菜單=頁面權(quán)限功能操作點=操作權(quán)限

1. 基本模型：RBAC0

抽取角色扭屁，建立角色與用戶的關(guān)系透硝。

這里的角色主要是指在組織內(nèi)承擔(dān)特定的業(yè)務(wù)活動，并和別的業(yè)務(wù)角色進(jìn)行交互的業(yè)務(wù)角色疯搅。業(yè)務(wù)角色的抽取主要有兩種方式：一種是直接和崗位對應(yīng)，另外一種是根據(jù)流程的本質(zhì)和需要定義角色埋泵。

確定各角色的用例圖幔欧，如下圖（簡單示例）：

根據(jù)業(yè)務(wù)復(fù)雜度、用戶特點進(jìn)行原型草圖設(shè)計丽声，在進(jìn)行權(quán)限分配時礁蔗，可以從增加角色維度以及增加用戶維度。如下圖：

新建角色維度

新建用戶維度

使用此模型時雁社，我們需要注意的問題有：

用戶和角色為多對一的關(guān)系浴井，如果需要用到多對多的關(guān)系，將涉及到角色關(guān)系的處理霉撵，此模型并不適用磺浙。權(quán)限一定是動態(tài)可配置的，不是靜態(tài)的徒坡，這點一定要在著手開發(fā)前進(jìn)行說明撕氧，一般情況，權(quán)限的數(shù)據(jù)結(jié)構(gòu)為樹形喇完，合理的數(shù)據(jù)結(jié)構(gòu)伦泥，便于前端根據(jù)實際需求進(jìn)行解析；人員在選擇角色獲取到對應(yīng)的權(quán)限數(shù)據(jù)后锦溪，最好可以提供一個二次編輯界面不脯，權(quán)限會更加靈活。

2. 角色分級模型：RBAC1

RBAC1基于RBAC0模型刻诊，引入角色間的繼承關(guān)系防楷，即角色上有了上下級的區(qū)別，角色分級模型適用于平臺業(yè)務(wù)功能較多坏逢，單個角色設(shè)置操作過于繁瑣域帐，引用角色分級，可讓角色之間存在繼承或被繼承的關(guān)系是整，比如客服主管可直擁有下級所有員工擁有的權(quán)限肖揣。

建立角色管理，確定角色跟用戶之間的關(guān)系浮入。（要求角色間有明顯的層級關(guān)系龙优，所以在沒有其他需求的情況下，這里根據(jù)業(yè)務(wù)部門和崗位進(jìn)行角色的抽取）

建立角色層級關(guān)系和繼承關(guān)系彤断。

角色層級關(guān)系

一般繼承關(guān)系

受限繼承關(guān)系

給角色賦予權(quán)限（應(yīng)用入口權(quán)限——應(yīng)用頁面權(quán)限野舶、應(yīng)用頁面中操作功能權(quán)限、數(shù)據(jù)查看權(quán)限宰衙。）權(quán)限賦予同RBAC0平道。

增加一個角色管理。如下圖：

通過角色管理即可以將下級角色的權(quán)限直接賦值給上級權(quán)限供炼，但由于低級角色的權(quán)限全部被高級角色繼承一屋，就會導(dǎo)致沒有自己角色的私有權(quán)限；也可以為人員提供一個二次編輯權(quán)限界面袋哼，但是一旦編輯后冀墨，若后續(xù)所屬角色權(quán)限發(fā)生變化，會直接覆蓋原有編輯后的權(quán)限涛贯。

3. 角色限制模型：RBAC2

RBAC2诽嘉，它是RBAC的約束模型，RBAC2也是建立的RBAC0的基礎(chǔ)之上的弟翘，在RBAC0基礎(chǔ)上假如了約束的概念虫腋，主要引入了靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。

SSD是用戶和角色的指派階段加入的衅胀，主要是對用戶和角色有如下約束:

互斥角色：同一個用戶在兩個互斥角色中只能選擇一個岔乔；基數(shù)約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的滚躯；先決條件約束：用戶想要獲得高級角色雏门，首先必須擁有低級角色。DSD是會話和角色之間的約束掸掏，可以動態(tài)的約束用戶擁有的角色茁影，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色丧凤。

角色權(quán)限配置界面可參照RBAC0募闲。

用戶在配置角色或角色下新建添加用戶時，需要根據(jù)用戶已有的角色身份進(jìn)行判斷愿待。示例：用戶A配置角色為客服組長浩螺，則可繼續(xù)添加角色為客服主管，若客服主管已被分配給他人仍侥，則也不能分配給用戶A（遵從最大擁有數(shù)原則）要出。若同時將保安主管分派至用戶A，則操作時农渊，需要選擇操作角色患蹂。

當(dāng)一個用戶配置了多個角色身份時，權(quán)限取并集。

4. 統(tǒng)一模型：RBAC3

統(tǒng)一模型是包括了繼承和分離兩種情況的更為復(fù)雜的模型传于，即既要定義角色間的的繼承關(guān)系囱挑，也要維護(hù)好角色間的責(zé)任分離關(guān)系。

在這里就不做過多的贅述（兩張圖供大家參考）沼溜，因為只要維護(hù)好了角色間的約束關(guān)系平挑，其他規(guī)則類的處理方式同RABC1和RABC2。

角色管理

權(quán)限配置

五系草、總結(jié)

1. 角色數(shù)據(jù)權(quán)限

不同的角色身份查看的角色數(shù)據(jù)時不相同的弹惦，比如物業(yè)分公司中深圳區(qū)域分公司的管理人員可能就無法管理長沙區(qū)域分公司，在給角色分配數(shù)據(jù)權(quán)限時就可以將長沙區(qū)域分公司去除悄但。除數(shù)據(jù)權(quán)限外，我們還會遇到字段權(quán)限石抡，比如：分公司C和分公司D都能看到上海區(qū)域分公司的客戶情況檐嚣，但是C看不到客戶聯(lián)系方式，D則能看到聯(lián)系方式啰扛。如果有需要對字段權(quán)限進(jìn)行控制嚎京，則可以在設(shè)置角色的數(shù)據(jù)權(quán)限或者功能權(quán)限時，進(jìn)行控制隐解。題前有提到針對saas模式鞍帝，可能存在一個角色在管理A跟B應(yīng)用時可操作的數(shù)據(jù)權(quán)限時不一樣的，可以在數(shù)據(jù)權(quán)限中增加一個高級設(shè)置權(quán)限煞茫，為不同的角色針對不用的應(yīng)用進(jìn)行分配數(shù)據(jù)操作帕涌。

2. 用戶操作體驗

平臺類或者TO B內(nèi)部產(chǎn)品，雖然不像C端為了留住用戶追求極致用戶體驗续徽，但是也需要確保在交互以及文字理解上面不會讓用戶產(chǎn)生疑惑情緒蚓曼，培訓(xùn)成本也是開發(fā)成本的一環(huán)，尤其針對權(quán)限一塊可能涉及業(yè)務(wù)功能復(fù)雜钦扭，如果在文字描述以及操作上在加大操作難度纫版，可能無法估量的后果。

3. 默認(rèn)賬號以及默認(rèn)權(quán)限的設(shè)置

對于ToB類或者平臺類的產(chǎn)品客情，正常來講都會有一個默認(rèn)的超級管理員的角色以及角色對應(yīng)的賬號其弊，否則系統(tǒng)內(nèi)第一個角色誰來添加？

默認(rèn)權(quán)限的設(shè)置則根據(jù)需要進(jìn)行設(shè)置膀斋，如果是不必要進(jìn)行控制的權(quán)限梭伐，當(dāng)然是可以設(shè)置為默認(rèn)權(quán)限的。

綜上所述概页，根據(jù)以上的設(shè)計模式以及解決方案籽御，已經(jīng)能實現(xiàn)大部分企業(yè)90%的問題了，實際上很多企業(yè)并不需要做到這么小粒度的權(quán)限控制。

文章來自轉(zhuǎn)載技掏，侵權(quán)可聯(lián)系我刪除