以角色為基礎的存取控制（Role-based Access Control, RBAC） 24

以角色為基礎的存取控制（Role-based Access Control, RBAC）的概念，於 1992 年由Ferraiolo與Kuhn等學者所提出[11]，而於 1996 年，Sandhu等學者發表 了完整的「以角色為基礎的存取控制模型」（RBAC Model）[21]，如圖 2.5 所示。

而後由美國國家標準與技術局（National Institute of Standards and Technology, NIST）加以收編、整理，訂定一套稱為NIST RBAC的標準[22]。

Role Permissions

圖2.5 以角色為基礎之存取控制模型[21]

在這個以角色為基礎的存取控制模型中，會將使用者指派到適合的角色，再 根據所屬角色來給予適當的權限，也就是不以人為授權依據，而以角色作為授權 依據，讓每位使用者可以擁有多個角色，每個角色也可授權給多個使用者來擔

User

Constraints

●● … ● Sesssions UA (User Assignment)

PA (Permission Assignment)

user

roles

任，在權限和角色之間亦是如此，藉由這種方式來簡化權限管理的複雜度，讓管 理者能夠更容易的做到安全管理，後續將一一介紹以角色為基礎的存取控制模型 中所包含的各個基本元素、角色階層的特性，以及限制條件，最後再說明其所支 援的安全規範。

(一) 基本元素

以角色為基礎的存取控制模型包含四個主要基本元素，分別是使用者

（User）、角色（Role）、權限（Permission）和會期（Session），以及使用者 指派（User Assignment, UA）和權限指派（Permission Assignment, PA）二個指派 關係，以下將針對各個元素及指派關係做詳細的說明。

1. 使用者（User）

指的是真實世界的使用者，是直接與系統有互動的人。

2. 角色（Role）

可以視為組織中的職務，每一個角色會根據其工作屬性來給予適當的權限，

即透過角色的指派，讓使用者能依據所擁有的角色來執行權限。

3. 權限（Permission）

即系統中對物件的特定操作的許可，像是新增、修改、刪除…等。

4. 會期（Session）

當使用者要存取資源時，需透過會期的建立，才可以使用被允許執行的角 色，且要在會期的期間內，才能執行角色所擁有的權限。而這裡的會期包含了二

z user function：將每個會期對應到一個使用者，當使用者想執行特定一 個角色時，需藉由會期來進行，而使用者和會期之間是呈現一對多的對 應關係，也就是在一個特定的會期中，使用者只能扮演一個角色，但一 個使用者可以對應到多個會期。

z roles function：將每個會期對應到多個角色，在一個會期中，可以有許 多不同功能的角色一起參與，所以可以有許多不同的角色在同時間一起 進行，在角色和會期之間是呈現多對多的對應關係，也就是在一個特定 的會期中，可以同時執行多個角色，而且每個角色也可以同時給多個會 期來執行。

5. 使用者指派（User Assignment）

即將使用者指派到適合的角色，在使用者和角色之間呈現多對多的對應關 係，也就是說，一個使用者可以指派多個角色，而一個角色也可以指派給多個使 用者。

6. 權限指派（Permission Assignment）

表示將每一個角色給予適當的權限，在權限和角色之間也是呈現多對多的對 應關係，也就是一個權限可以指定給多個角色，而一個角色也可以同時被指定多 個權限。

(二) 角色階層

在以角色為基礎的存取控制模型中的角色階層（Role Hierarchy），可以反映 出組織中的權限和責任之間的關係，藉由利用上層的角色來繼承下層的角色，讓 上層角色不但擁有本身的權限外，還繼承了下層角色的權限，而管理者在做授權 時，可以減少許多重覆的指派動作，其角色階層之範例如圖2.6 所示。

主管

倉管人員 收銀員

工讀生

圖2.6 角色階層範例圖

工讀生位於角色階層中的最下層，可以得知工讀生所擁有的權限最少，而倉 管人員和收銀員繼承了工讀生的角色，所以除了本身的權限外，還同時擁有工讀 生的權限，最後，主管為最高層級的角色，不但能繼承倉管人員和收銀員的權限，

透過角色階層之間的關係，主管還能繼承了工讀生的權限，因此，這種模式就如 同實際的組織架構，讓以角色為基礎的存取控制能有利於組織做管理。

(三) 限制條件

在以角色為基礎的存取控制模型中的限制條件（Constraints），可以依據組織 中的需求來加入不同的限制條件，但並不會改變最原始的角色指派關係，只會額 外判斷是否接受該角色的指派，例如：互斥角色、使用者數量和前提角色…等 [21]，其說明如下：

z 互斥角色（Mutually Exclusive Roles）：在分配角色給使用者之前，會先 依照需求來限制某些角色無法同時指派給同一個使用者，例如：為避免 發生舞弊的現象，採購人員角色和驗收人員角色不能由同一個使用者來

z 使用者數量（Cardinality）：即限制角色可指派的人數，尤其是一些較高 職位或是具有特別權限的角色，像是在組織中最高職位的總經理，或是 擁有最高權限的系統管理者等，最好都加以限制可指派的數量，以增加 系統的安全。

z 前提角色（Prerequisite Roles）：也就是想要指派某一個角色給使用者 時，該使用者需已擔任過另一個角色，才能將該角色指派給使用者，例 如：在一個賣場中，想要擔任店長的角色，須先擔任過副店長的角色，

由此可知，工讀生的角色即為領班的前提角色。

(四) 安全規範

在以角色為基礎的存取控制模型中，除了基本的操作外，如讀、寫、執行等，

還支援三種常見的安全規範，分別是最少授權、權責區分和資料抽象化，這些皆 能增加系統的安全性，避免使用者不小心或故意，因錯誤的操作而危及系統的安 全，其說明如下[10][21]：

z 最少授權（Least privilege）：指提供角色剛好且符合操作的權限，因為 過多的權限不但對實際的運作並沒有太大的幫助，反而會增加系統管理 者在維護時的負擔，而且也可能讓使用者在有心或是無心下，因錯誤的 操作，而危害到系統的安全，因此，給予使用者最少的權限，不但能避 免不必要負擔，還能增加系統的安全性。

z 權責區分（Separation of duties）：主要避免權責相衝突的二個角色，操 作同一份資料而產生舞弊，也就是說，要避免某些角色同時指派給同一 個使用者，例如：若採購人員角色和驗收人員角色由同一個使用者來擔 任，則容易產生監守自盜的問題，因此，為了預防這類型的事件發生，

就要做到權責區分。

z 資料抽象化（Data abstraction）：利用將實際的資料隱藏在操作之中，

計系統中，將讀寫資料檔這種語意不清的表示，改成用借、貸來表示，

以輔助使用者了解該操作的真正涵意，才不會因為誤解而產生錯誤的操 作或授權。

而上述的權責區分，又可區分為靜態權責區分以及動態權責區分這二種，其 詳細說明如下[14][15][28]：

z 靜態權責區分（Static Separation of Duties）：又可稱為強互斥（Strong Exclusion），表示不能指派給同一個使用者二個相互衝突的角色，以避 免中間有任何可能發生的利益輸送問題，例如開立支票的角色和稽核支 票的角色不能讓同一個使用者來擔任，也就是說，一旦將二個角色設立 為強互斥的角色，則無論如何那二個角色將永遠都不能同時指派給同一 個使用者。

z 動態權責區分（Dynamic Separation of Duties）：又可稱為弱互斥（Weak Exclusion），不同於靜態權責區分強硬規定二個相互衝突的角色不能指 派給同一個使用者，而是一個使用者可以同時擁有相互衝突的角色，但 是不能在同一時間點上執行這二個角色，只能在二個角色中選擇其中一 個角色來執行，例如採購人員的角色和驗收人員的角色可以同時指派給 一個使用者，只是在同一時間不能一起使用這二個角色，所以和靜態權 責區分比較起來，較具有彈性，也比較能符合組織實際使用狀況。

2.3 情境（Context）

根據Dey等人對情境的定義[7]，情境是「任何可以描述一個個體狀況的資

訊。而Schilit等人則認為情境應著重在描述環境變化的相關資訊，其中包含三個 重要觀點[26]：

z 你的位置在那？

z 誰跟你在一起？

z 有什麼資源在附近？

Schilit等人並將情境分類為位置（Location）和身分（Identity）二大類[27]，

雖然不同的學者對於情境都有不同的看法，但所針對的主體是相同的，如果依據 他們對情境的觀點加以分類，可以協助我們按照自己的需求，將情境做適當的應 用。其它如Ryan等人[30]將情境分類為所在位置（Location）、環境（Environment）、 身分（Identity）與時間（Time），而Zhan等學者[34]則根據使用者所使用不同的 設備，當成是不同的情境資訊，像是桌上型電腦、個人數位助理、智慧型手機…

等，依據當時情境資訊的不同，而使網頁上所呈現內容而有所不同。