任何應(yīng)用，都會涉及到用戶權(quán)限管理的問題。RBAC 授權(quán)模型，即基于角色的訪問控制，是指根據(jù)用戶在組織中的角色為用戶分配權(quán)限。

使用 RBAC，只要嚴(yán)格遵守角色的規(guī)則要求，它會讓你的訪問管理變得非常容易，且不容易出錯。

在大中型企業(yè)的實踐中， RBAC 授權(quán)模型已經(jīng)被認(rèn)為是最佳的員工授權(quán)管理解決方案。

例如，您使用 RBAC 來控制 HR 應(yīng)用程序的訪問權(quán)限，您可以為 HR 經(jīng)理提供一個角色，允許他們更新員工詳細(xì)信息，而其他員工只能查看他們自己的詳細(xì)信息。

接下來，我們?yōu)槟鲈敿?xì)的解答。

RBAC 模型是什么?

美國國家標(biāo)準(zhǔn)與技術(shù)研究院（The National Institute of Standards and Technology）認(rèn)為 RBAC 模型由 4 個基礎(chǔ)模型組成：

1. 基本模型 RBAC0（Core RBAC）

2. 角色分層模型 RBAC1（Hierarchal RBAC）

3. 角色限制模型 RBAC2（Constraint RBAC）

4. 統(tǒng)一模型 RBAC3（Combines RBAC）

RBAC 授權(quán)的過程可以抽象概括為：判斷 Who 是否可以對 What 進(jìn)行 How 的訪問操作，以及這個邏輯表達(dá)式的值是否為 True 的計算過程。

Who、What、How 構(gòu)成了訪問權(quán)限三元組，Who 是權(quán)限的擁有者或主體（User、Role），What 是資源（Resource），How 是具體的權(quán)限。

RBAC 模型有什么特點?

RBAC 授權(quán)模型，最根本的初衷是簡化權(quán)限管理，后來被越來越多的企業(yè)應(yīng)用到了員工授權(quán)資源管理系統(tǒng)中。

隨著用戶的規(guī)模和復(fù)雜性增加，角色會變得非常有用。比如，將特定角色添加到特定組織成員中，并允許組織成員訪問特定的程序。這在支持多租戶和 SaaS 產(chǎn)品時特別有用，其中特定用戶可能在一個組織中擁有特權(quán)角色，但在其他組織中沒有。

RBAC 模型的優(yōu)勢：

• 減少授權(quán)管理的復(fù)雜性，降低管理成本；
• 創(chuàng)建系統(tǒng)的、可重復(fù)的權(quán)限分配；
• 輕松審核用戶權(quán)限并糾正已發(fā)現(xiàn)的問題；
• 快速更改角色，以及跨 API 實施角色；
• 減少分配用戶權(quán)限時出錯的可能性；
• 靈活地支持企業(yè)的安全策略，并且有很大的伸縮性；
• RBAC 適用于多對多的映射關(guān)系。

RBAC 模型的缺點：

RBAC模型沒有提供操作順序控制機制。這一缺陷使得 RBAC 模型很難應(yīng)用于那些要求有嚴(yán)格操作次序的實體系統(tǒng)。

例如，公司采購流程就沒有辦法用 RBAC 模型授權(quán)控制采購過程中每一個流程中應(yīng)該怎么樣授權(quán)。

基本模型 RBAC0

RBAC0 是最基礎(chǔ)也是最核心的模型，由五部分組成：用戶（User）、角色（Role）、許可（Permission）、會話（Session）、操作（operations OPS）。

角色通過許可被授權(quán)資源，角色又授權(quán)到用戶身上，通過會話管理用戶和角色的授權(quán)關(guān)系，用戶就繼承了角色的訪問資源權(quán)限。

例如：張三是一家企業(yè)的財務(wù)總監(jiān)，同時他也是該企業(yè)對外的形象大使，財務(wù)總監(jiān)有訪問公司財務(wù)數(shù)據(jù)的權(quán)限，形象大使有訪問公司市場部推廣計劃和編輯發(fā)言稿的權(quán)限。那么張三既有訪問公司財務(wù)數(shù)據(jù)的權(quán)限，又有訪問公司市場部推廣計劃和編輯發(fā)言稿的權(quán)限。突然有一天公司決定做職位調(diào)整，張三被任命為財務(wù)總監(jiān)和人力資源總監(jiān)，撤掉了形象大使。那么張三當(dāng)前就只能訪問財務(wù)總監(jiān)和人力資源總監(jiān)所對應(yīng)的授權(quán)資源。

角色分層模型 RBAC1

該模型主要是在 RBAC0 的基礎(chǔ)上，增加了角色層級關(guān)系的繼承邏輯，也就是說角色有了組織樹的邏輯。

角色有了上下級關(guān)系，上一級的角色可以繼承其下所有角色的授權(quán)資源。

例如：張三是一家企業(yè)的財務(wù)總監(jiān)，同時他也是該企業(yè)對外的形象大使，財務(wù)總監(jiān)有訪問公司財務(wù)數(shù)據(jù)的權(quán)限，形象大使有訪問公司市場部推廣計劃和編輯發(fā)言稿的權(quán)限。那么他的上級領(lǐng)導(dǎo)，比如是該公司的 CFO，既有訪問公司財務(wù)數(shù)據(jù)的權(quán)限，又有訪問公司市場部推廣計劃和編輯發(fā)言稿的權(quán)限。這是繼承關(guān)系。

角色限制模型 RBAC2

該模型主要添加了授權(quán)約束。約束規(guī)定了權(quán)限被賦予角色時，或角色被賦予用戶時，以及當(dāng)用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。

責(zé)任分離包括：靜態(tài)責(zé)任分離（SSD）和動態(tài)責(zé)任分離（DSD）。

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

互斥角色：同一個用戶在兩個互斥角色中只能選擇一個。比如財務(wù)部有會計和審核員兩個角色，他們是互斥角色，那么用戶不能同時擁有這兩個角色，體現(xiàn)了職責(zé)分離原則。

基數(shù)約束：一個角色被分配的用戶數(shù)量受限，一個用戶可擁有的角色數(shù)目受限，同樣一個角色對應(yīng)的訪問資源權(quán)限數(shù)目也受限，以控制高級權(quán)限在系統(tǒng)中的分配。比如李四是 COO，王五不能也是 COO。同樣的李四不能既是 COO 又是 CTO 又是 CFO。COO 、CTO、 CFO 三個角色所能訪問的資源權(quán)限也不能是一模一樣的。

先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色。

DSD 是會話和角色之間的約束，可以動態(tài)的約束用戶擁有的角色。

如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。如一個人如果既是運動員又是教練，當(dāng)比賽開始的時候，只能選擇一個角色身份入場。

統(tǒng)一模型 RBAC3

RBAC3 是 RBAC1 與 RBAC2 的合集，所以 RBAC3 是既有角色分層又有約束的一種綜合授權(quán)模型。

Authing 基于角色的訪問控制

Authing 的授權(quán)模型是在 RBAC3 的基礎(chǔ)上，改進(jìn)的一種授權(quán)模型。提高了性能和可擴展性，主要由用戶、組織、租戶角色、應(yīng)用角色、資源等模塊進(jìn)行交叉管理，最終提供更加靈活、適用范圍更廣泛的 RBAC 系統(tǒng)。

Authing RBAC 可適用的場景非常多，舉兩個典型場景示例：

場景一：A 公司旗下有 3 個子公司（假定 3 個子公司分別為 A1、A2、A3），每個子公司都有自己的組織架構(gòu)和相對應(yīng)不同的資源訪問權(quán)限。該公司希望通過 Authing 可以統(tǒng)一的管理這三家公司之間人員交叉訪問資源的授權(quán)問題。

我們最終實現(xiàn)，A1 公司的員工只需要登錄 Authing 一次，就可以在訪問 A2 公司資源的時候，系統(tǒng)給他的權(quán)限是這個員工對應(yīng)在 A2 公司的角色權(quán)限；而且還可以限定很多附加條件，在該員工全部滿足以后才可以拿到 A2 公司的資源；幫助 A 公司實現(xiàn)了集團型公司統(tǒng)一的權(quán)限分配管理。

場景二：X 應(yīng)用在最初設(shè)計的時候沒有考慮到多個用戶組訪問資源時，如何解決不同用戶組之間和用戶組內(nèi)部的交叉授權(quán)資源的關(guān)系。

我們最終實現(xiàn)，用戶組 A 和 B 訪問 X 應(yīng)用的時候，資源隔離，并且 A1 用戶可以被授權(quán)訪問 B1 用戶的部分資源的需求。

Authing RBAC 權(quán)限模型的可拓展性

Authing 在基于角色資源授權(quán)上有非常豐富的模型設(shè)計，將用戶、角色、資源這三個權(quán)限模型 “源” 進(jìn)行非常精細(xì)的劃分和管理，讓授權(quán)管理這件事變得像拼積木一樣靈活便捷，能夠應(yīng)對各種復(fù)雜的場景。

您可以點擊閱讀原文，了解如何使用 Authing API ，為您的應(yīng)用配置合適的權(quán)限模型。