【認證與授權】Authorization策略 — RBAC模型介紹

更新於 發佈於 閱讀時間約 2 分鐘
前一篇的「Authentication、Authorization,傻傻分不清楚?」主要在介紹認證與授權的差異之處,而本章節著重於授權這部分,也使用了經典的RBAC模型進行說明。

概述

RBAC模型(Role-Based Access Control:基於角色的訪問控制), 認為可以抽象的表示:
Who是否可以對What進行How的訪問操作
並針對這樣的邏輯進行求解的過程。
當然這樣的概念不僅限於軟體世界,套用到真實世界也是非常適合的,就以公司組織來說,RBAC的公式就是非常貼近生活化的例子了。
誰可以對財務報表進行修改?
誰可以對公司規章進行新增?

基本模型的組成元素: RBAC0

根據權限的複雜程度, 又區分為RBAC0RBAC1RBAC2RBAC3, 但是不論如何都脫離不了以下的三個元素(用戶、角色、權限)來進行延伸, 也就是基礎的RBAC0
  • 用戶(User): 每個使用者可以被賦予不同角色。
  • 角色(Role): 每個角色具有不同的存取權限。
  • 許可權(Permission): 訪問許可權。

實際案例

假設我們有管理者跟一般使用者, 分別操作權限有所不同, 如下圖,管理者具有所有的操作權限, 而一般使用者只有查看個人訊息、修改個人用戶名稱的權限。

角色分層模型: RBAC1

主要在角色中引入繼承的概念, 也就是替角色分組並區分等級, 每個等級所對應的權限也有所不同。

角色限制模型: RBAC2

RBAC2是基於RBAC0擴展的, 增加了一些限制, 分別為:
  • 靜態職責分離(SSD): 約束於用戶與角色之間。
  1. 同一使用者不能擁有多個會發生權責衝突的角色。
  2. 互斥角色: 同一個用戶不能授予互斥關係的角色, 例如: 同一個員工不能同時為會計及研發。
  3. 基數約束: 一個用戶所被賦予的角色是有限的。
  4. 先決條件約束: 用戶想要擁有更高權限之前必須先具有前一級的權限。
  • 動態職責分離(DSD):
  1. 同一使用者可以擁有多個會發生權責衝突的角色。
  2. 實際執行時只能選擇其中一個角色來擔任。

RBAC 3

RBAC3 = RBAC1 + RBAC2,因此除了具備角色分層的概念,亦能增加限制,適用於非常大型的複雜系統,一般中小型系統較少使用。
即將進入廣告,捲動後可繼續閱讀
為什麼會看到廣告
avatar-img
119會員
268內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
阿Han的沙龍 的其他內容
認證(authentication)跟授權(authorization)這兩個名詞常常被混淆,但本質上是完全不同的兩個概念,在數位化的時代下,為了確保每位使用者的安全性,每個系統幾乎都具備認證(authentication)與授權(authorization)這兩大功能,而這些概念也常常出現在我們生
在進入Message Queue之前我們先來了解一下同步/非同步任務的概念。 菜單稱為訊息(Message), 為工作內容描述。 送出菜單的客人稱為生產者(Producer), 負責建立訊息。 櫃台就相當於Queue, 負責接單並依序處理。 廚師就是消費者的概念, 負責消化Queue裡面的訊息。 採
認證(authentication)跟授權(authorization)這兩個名詞常常被混淆,但本質上是完全不同的兩個概念,在數位化的時代下,為了確保每位使用者的安全性,每個系統幾乎都具備認證(authentication)與授權(authorization)這兩大功能,而這些概念也常常出現在我們生
在進入Message Queue之前我們先來了解一下同步/非同步任務的概念。 菜單稱為訊息(Message), 為工作內容描述。 送出菜單的客人稱為生產者(Producer), 負責建立訊息。 櫃台就相當於Queue, 負責接單並依序處理。 廚師就是消費者的概念, 負責消化Queue裡面的訊息。 採
你可能也想看
Google News 追蹤
Thumbnail
現代社會跟以前不同了,人人都有一支手機,只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行,然而如今科技快速發展之下,金融App無聲無息地進到你生活中。但同樣的,每一家銀行都有自己的App時,我們又該如何選擇呢?(本文係由國泰世華銀行邀約) 今天我會用不同角度帶大家看這款國泰世華CUB
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
帳號權限管理一直是產品系統的重要議題,近期規劃權限功能時發現 RBAC 這套模型,才開始了解為什麼要有 User-Role-Permission 的架構,隨著系統規模的擴大和複雜度的增加,傳統的權限管理模式已經無法滿足需求,而基於角色的訪問控制(Role-Based Access Control,簡
※ 生產者和消費者模式 定義: 生產者和消費者在同一時間內共同存取某一個資料空間。生產者負責生成數據並將其放入共享空間,消費者負責從共享空間中取走數據進行處理。兩者之間互不相干,也不須互相知道對方的存在。 共同存取資料空間:生產者和消費者共享同一個資料空間。這個空間通常是緩衝區或隊列,用於在它
Thumbnail
本文提供了保人的角色定義以及與連帶保證人的差異,同時解釋了保人需要承擔的債務清償責任。透過法律諮詢,作者建議擔任保人者應該小心瞭解自己的法律責任,以及如何保護自己的權益。
Thumbnail
代理模式通過封裝原始對象來實現對該對象的控制和管理,同時不改變原始對象的行為或客戶端與該對象互動的方式,以此介入或增強對該對象的訪問和操作。
Thumbnail
可能包含敏感內容
這是布雷克替Boss掌管的人事登記冊,記錄著他與其他下屬或客人的許多“私密”數據...。
Thumbnail
權限管理=新增、修改、刪除+審核 通常,這種程式的設計會包含權限管理,其中包括現場修改、刪除等三大類功能。然而,根據經驗,我們還需要關注另一類功能,即審核權限。 審核不執行新增 審核權限通常不執行新增的動作,僅限於某些欄位的輸入。新增、修改、刪除這些操作基本上是容易理解的。也就是說,對於這個工
Thumbnail
情境:想透過 IAM Role 的方式同時切換不同的帳號。 這邊以主帳號 "A" ,子帳號 "B" 為例。即在不重新登入的情況下,先登入A,然後利用 switch role的方式跳進B。
物件導向設計的一個重點就是封裝,這有很多層面上的意義,但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關,這使得有一些時候我們逼不得已必須把函式定義在類別上,這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責,並不需要再給物件相同的能力。 一般的模組系統就是把相
Thumbnail
在工作執行中,部門一定會遇到同仁請假或是人員異動,代理人機制設計可以降低同仁請假或是離職所產生的風險,也就是營運上作業風險。本文將會說明如何進行「代理人機制設計」。
Thumbnail
現代社會跟以前不同了,人人都有一支手機,只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行,然而如今科技快速發展之下,金融App無聲無息地進到你生活中。但同樣的,每一家銀行都有自己的App時,我們又該如何選擇呢?(本文係由國泰世華銀行邀約) 今天我會用不同角度帶大家看這款國泰世華CUB
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
帳號權限管理一直是產品系統的重要議題,近期規劃權限功能時發現 RBAC 這套模型,才開始了解為什麼要有 User-Role-Permission 的架構,隨著系統規模的擴大和複雜度的增加,傳統的權限管理模式已經無法滿足需求,而基於角色的訪問控制(Role-Based Access Control,簡
※ 生產者和消費者模式 定義: 生產者和消費者在同一時間內共同存取某一個資料空間。生產者負責生成數據並將其放入共享空間,消費者負責從共享空間中取走數據進行處理。兩者之間互不相干,也不須互相知道對方的存在。 共同存取資料空間:生產者和消費者共享同一個資料空間。這個空間通常是緩衝區或隊列,用於在它
Thumbnail
本文提供了保人的角色定義以及與連帶保證人的差異,同時解釋了保人需要承擔的債務清償責任。透過法律諮詢,作者建議擔任保人者應該小心瞭解自己的法律責任,以及如何保護自己的權益。
Thumbnail
代理模式通過封裝原始對象來實現對該對象的控制和管理,同時不改變原始對象的行為或客戶端與該對象互動的方式,以此介入或增強對該對象的訪問和操作。
Thumbnail
可能包含敏感內容
這是布雷克替Boss掌管的人事登記冊,記錄著他與其他下屬或客人的許多“私密”數據...。
Thumbnail
權限管理=新增、修改、刪除+審核 通常,這種程式的設計會包含權限管理,其中包括現場修改、刪除等三大類功能。然而,根據經驗,我們還需要關注另一類功能,即審核權限。 審核不執行新增 審核權限通常不執行新增的動作,僅限於某些欄位的輸入。新增、修改、刪除這些操作基本上是容易理解的。也就是說,對於這個工
Thumbnail
情境:想透過 IAM Role 的方式同時切換不同的帳號。 這邊以主帳號 "A" ,子帳號 "B" 為例。即在不重新登入的情況下,先登入A,然後利用 switch role的方式跳進B。
物件導向設計的一個重點就是封裝,這有很多層面上的意義,但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關,這使得有一些時候我們逼不得已必須把函式定義在類別上,這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責,並不需要再給物件相同的能力。 一般的模組系統就是把相
Thumbnail
在工作執行中,部門一定會遇到同仁請假或是人員異動,代理人機制設計可以降低同仁請假或是離職所產生的風險,也就是營運上作業風險。本文將會說明如何進行「代理人機制設計」。