架構在 RBAC 上的團隊委任模型

(1)

架構在 RBAC 上的團隊委任模型

研究生：歐家維指導教授：吳美玉博士

中華大學資訊管理學系

摘要

近年來有許多學者針對以角色為基礎的存取控制(Role-Based Access Control, RBAC)進行研究，很多企業組織也相繼使用此存取控制模型，漸漸地又有不同學者利用基本的以角色為基礎的存取控制模型衍生出其他存取控制方法，像是以角色為基礎的委任模型(Role-Based Delegation Model, RBDM)和以團隊為基礎的存取控制(Team-Based Access Control, TMAC )等模型，主要彌補以角色為基礎的存取控制在緊急權限委任指派和團隊形成運作上的不足。但隨著企業組織漸漸發展，規模逐漸龐大之後，過去學者提出的團隊模型已經慢慢無法承受現今的企業組織規模，針對使用者以及權限管理將會造成龐大的管理成本。

本研究主要提出一個架構在 RBAC 上的團隊委任模型，在以角色為基礎的存取控制中，加入了團隊角色，並且利用委任模型的優勢，達到團隊角色的委任，

在權限管理上，提出一個新的權限定義，解決管理者要逐一對使用者做權限的指派問題，有效降低企業組織的團隊管理成本。

關鍵詞：以角色為基礎的存取控制、委任、團隊

(2)

The Team-Based Delegation Model Based on RBAC

Student：Jia-Wei Ou Advisor：Dr. Mei-Yu Wu

Department of Information Management, Chung-Hua University, HsinChu, Taiwan, ROC

ABSTRACT

There are many researches In Role-Based Access Control (RBAC) in recent years. Many enterprises use RBAC sequentially. There are some derivative models of RBAC, such as Role-Based Delegation Model (RBDM) and Team-Based Access Control (TMAC). The main differences between derivative models and RBAC are the emergent permissions assignments and team operations. However, with the development of organizations and enterprise scale, the old team model that has been suggested by academicians in the past can not apply to current large scale enterprises.

The cost of users and permissions management will be enormous.

This research proposes the team-based delegation model based on RBAC. Take the access control method of RBAC adding in team role, and take the advantage of delegation model to delegate to a team role. The researches also propose a method of permission management for administrator to solve of assigning permission to users one by one. The proposed model decreases the management costs of organizations effectively.

Keywords: Role-Based Access Control, delegation, team

(3)

致謝

轉眼間兩年的研究生涯就快結束了，承蒙指導教授吳美玉老師在這兩年的時光細心的指導與教誨，本篇論文才能如期的完成。這兩年來，跟著吳美玉老師的腳步，學習到了許多專業知識以及報告寫作技巧，讓我不僅在學校課業上能夠完成學業，在未來的工作上也能運用所學來達成工作目標。兩年的時間說長不長，

但卻感到非常的充實，如今終於要畢業了，要離開指導教授以及這些日子一貣打拼的同窗好友，非常不捨。

另外要感謝我的口詴委員葉慈章教授、郭明煌教授以及李之中教授，對於我的論文細心的指導與建議，讓我受益良多。也要感謝同實驗室的同學李宗澤、詹智翔以及簡其弘，大家有了共同目標一貣打拼，互相的支持與鼓勵，讓我更有動力完成學業。

最後要感謝一直在背後支持我督促我的雙親，讓我能夠毫無後顧之憂，全心全力在課業上努力學習，才能完成學業。

(4)

圖目錄

圖 1 研究流程圖 ... 4

圖 2 以角色為基礎的存取控制模型 ... 7

圖 3 角色階層示意圖 ... 9

圖 4 以角色為基礎的委任模型 ... 12

圖 5 以角色為基礎的群體委任架構 ... 15

圖 6 以團隊為基礎的存取控制 ... 17

圖 7 以團隊為基礎的存取控制模型 ... 18

圖 8 架構在 RBAC 上的團隊委任模型 ... 22

圖 9 委任角色權限示意圖 ... 25

圖 10 團隊角色委任示意圖 ... 28

圖 11 系統管理者畫面 ... 34

圖 12 使用者管理 ... 35

圖 13 角色管理 ... 36

圖 14 權限管理 ... 37

圖 15 角色指派管理 ... 38

圖 16 權限指派管理 ... 39

圖 17 新增團隊 ... 40

圖 18 選擇團隊 ... 41

圖 19 管理團隊 ... 41

圖 20 撤銷前的團隊TEAM 1 ... 45

圖 21 新增團隊所需求的原始角色TEAM 1 ... 46

圖 23 撤銷後的團隊TEAM 2 ... 48

圖 25 管理者撤銷ROLE3 前使用者USER3 加入團隊TEAM 2 ... 50

圖 26 管理者撤銷ROLE3 後使用者USER3 加入團隊TEAM 2 ... 50

(7)

表目錄

表 1 使用者角色指派 ... 42

表 2 角色權限指派 ... 43

表 3 團隊 ... 43

表 4 團隊角色權限 ... 44

表 5 使用者能夠被委任的團隊角色 ... 44

(8)

第一章緒論

隨著資訊科技的蓬勃發展，企業組織的規模也越來越廣，為了順應時代的變遷，公司目標已經不再是當初成立時所制定的規劃，公司規模將會持續拓展，之後企業的走向也不再是朝向單一目標前進，多元化的企業發展將會是未來的主流，要如何讓企業組織能夠順利邁向多元化的方式運行，目前最普遍的作法就是利用團隊合作來達到企業目標。

在現今的企業組織中，團隊合作的模式已經普遍的運行，不管是公司內部跨部門的專案開發，或是公司間跨組織的合作，經常需要採購、財務、資訊技術部，

甚至是法務等部門的支援，才能完成所要完成的專案；在醫療團隊中，病患也可能需要外科、內科，甚至一些神經科共同合作才能針對病患達到完善的醫療，由以上這些例子可以明顯的指出團隊的重要性。

了解到團隊的重要性之後，要如何管理團隊便成了首要的問題，在企業組織中，大都是利用電腦系統來輔助管理內部員工和所執行的工作，透過網路傳遞資訊具有速度快成本低的特性，管理上將會非常的方便，但是背後卻隱藏了非常大的資訊安全危機，所以現今企業組織對於資訊安全非常的重視並且全力推廣運行。資訊安全技術包含了使用者的認證（Authentication）、資料的加密與解密

（Encryption/Decryption）、金鑰管理（Key management）和存取控制（Access control）等，每個項目都是企業組織內部重要的資訊安全項目，本研究主要針對存取控制項目做進一步的研究。

在存取控制中，權限設定是控制資訊安全最主要的一部分，透過良好的權限管理可以降低企業內部的資訊安全風險。在團隊合作的環境中，團隊的成員可能是由不同部門的跨部門合作，或是來自不同的企業組織達到跨組織的合作，不管是何種團隊的形成，團隊中的權限管理將會是整個團隊安全性最重要的部份，要如何把團隊的概念加入既有的存取控制架構中，並且達到高安全性的權限管理，

則是本研究最主要的目的。

(9)

1.1 研究背景與動機

存取控制一直是許多學者相繼研究的管理領域，一些學者提出的以角色為基礎的存取控制(Role-Based Access Control, RBAC)[11][13][19][20]提供了一套針對使用者、角色與權限之間有效的管理方式，因此有越來越多學者針對以角色為基礎的存取控制做更深入的研究，也提出了許多架構在以角色為基礎的存取控制上的存取控制方法，在 2000 年時，以角色為基礎的存取控制由美國國家標準局 (National Institute of Standards and Technology, NIST)視為一種存取控制的標準 [20]，並開始提倡以角色為基礎的存取控制的應用。

以角色為基礎的存取控制已經提供了一套有效的存取控制管理方法，利用所提出的使用者、角色和權限來管理整個企業組織內部的存取控制，但是以角色為基礎的存取控制管理上都是針對單一使用者做權限的管理，並無團隊的概念，因此有越來越多的研究開始探討團隊如何架構在以角色為基礎的存取控制機制上。

在企業組織中，使用者本身應具有他所屬部門的權限，而當使用者加入到一個團隊之中，他該如何把他的權限帶進團隊之中，要如何適當的分享他的權限給其他在同一個團隊中的使用者，還有要如何使用其他人所分享的權限，都是重要的議題。

1.2 研究目的

本研究的主要目的便是延伸以角色為基礎的存取控制機制運用在團隊的形成、團隊角色的委任和團隊中權限的控管上，在使用者、角色與權限之間加上嚴謹的限制條件，擁有更安全的管理，並且利用原始角色和團隊角色委任的方式來達到管理使用者在團隊中的權限，以不影響使用者原始的權限，又能達到團隊權限之控管為目標。

根據研究目的所要解決的問題，本研究提出一個新架構稱之為“架構在 RBAC 上的團隊委任模型（The Team-Based Delegation Model Based on RBAC, TBDM）”，包含原有以角色為基礎的存取控制上權限管理的特點，運用在團隊

(10)

形成上，並且利用委任的方式達到團隊中權限的授予與控管，使團隊達到較高的安全管理。

1.3 研究流程

本研究首先闡述問題背景、研究動機與目的，在確定研究主題為「架構在 RBAC 上的團隊委任模型」後，依據相關文獻的蒐集與分析，進一步確立研究範圍；其次是利用本研究所提出的角色權限規則，和本研究所提出的團隊角色，達到團隊成員間的權限分享。最後分析相關實作結果，並提出適當結論及建議事項。

本研究在文獻資料之蒐集與探討上主要區分下列幾部份，包括：

 以角色為基礎的存取控制模型相關研究

 以角色為基礎的委任模型相關研究

 以團隊為基礎的存取控制模型相關研究

根據文獻資料的分析與整理，可作為本論文研究架構之理論基礎；本研究所提出的架構在 RBAC 上的團隊委任模型實作部份則使用 ASP 來開發系統而資料儲存的部分則使用 ACCESS 資料庫技術，將重點著眼於團隊角色委任的實作，

並期望能把整個理論模型建構完成。本論文之研究流程如圖 1 所示。

(11)

圖 1 研究流程圖

1.4 論文架構

本研究藉由提出新的架構在RBAC上的團隊委任模型，透過企業組織間團隊的形成達到各角色權限的分享，以降低團隊成員逐一指派權限的管理成本。相關章節安排如下：

第一章引述相關文獻資料說明傳統存取控制模型的不足之處，進而討論在存取控制模型中加入團隊角色的觀點，並指出團隊和權限在整個模型中之重要性。

第二章回顧相關文獻，簡介目前在存取控制模型相關之學術研究，說明目前相關研究正朝著滿足不同的企業環境等方面發展，主要有三個存取控制相關背景知識介紹，以角色為基礎的存取控制模型，說明最基本存取控制架構；以角色為基礎的委任模型，說明委任的方式以及委任的限制；以團隊為基礎的存取控制，

研究背景與動機

研究目的

文獻探討與確定研究主題

Role-Based Access Control

Role-Based Delegation Model Team-Based Access Control

Team-Based Delegation Model

系統實作

實驗評估

結果分析與結論

(12)

包含團隊的形成以及權限的控管。

第三章為本研究之模型架構，將詳細描述其研究內容，包括團隊的形成、權限的分類、團隊角色以及如何利用團隊角色達到委任的方法及步驟。

第四章為系統實作及分析，經由上述本研究提出的架構在RBAC上的團隊委任模型進行實作分析，接著利用網頁程式語言來進行模型實作，並綜合分析實作結果，最後提出適當之建議。

第五章是結論與未來研究方向。

(13)

第二章相關研究

本章節將會探討本研究相關的存取控制模型，包含以角色為基礎的存取控制模型、以角色為基礎的委任模型以及以團隊為基礎的存取控制等，第一節探討以角色為基礎的存取控制模型，包含了存取控制中的基本元素、存取控制中的安全原則、存取控制中的角色階層和存取控制中的限制；第二節探討以角色為基礎的委任模型，包含了委任模型的基本元件、委任模型的限制和委任模型的擴充限制；第三節探討以團隊為基礎的存取控制，透過團隊的形成達到權限的管理。

2.1 以角色為基礎的存取控制模型

傳統上有許多的存取控制機制，例如：存取控制串列(Access Control List, ACL)、強制性存取控制(Mandatory Access Control, MAC)和隨意性存取控制 (Discretionary Access Control, DAC)…等，傳統的存取控制主要是探討主體 (Subject)是否有權限去存取受體(Object)的關係，由於傳統上的存取控制架構在執行或是管理上不太具有彈性。針對這個問題，學者提出以角色為基礎的存取控制 (Role-Based Access Control, RBAC)來解決傳統存取控制架構的缺點。

以角色為基礎的存取控制是在1992 年由Ferraiolo和Richard.Kuhn[11]等學者首次正式提出的存取權限控管模組，之後又經過Sandhu等學者加以改進[19]，並由美國國家標準與技術協會(National Institute of Standards and Technology, NIST) 組職加以收編、整理之後訂定標準，稱為NIST RBAC[20]，如圖2所示。

在以角色為基礎的存取控制模型中，使用者被指派到適當的角色，而資源的存取權限則是經由所屬的角色來決定。角色包含了角色階層(Role Hierarchy)的特性，透過角色階層可以反映出組織的授權結構，使得企業在管理角色以及權限上具有較大的彈性。以下我們簡略描述以角色為基礎的存取控制模型基本架構。

(14)

圖 2 以角色為基礎的存取控制模型[20]

2.1.1 基本元素

以角色為基礎的存取控制模型包含了四個基本元素，以及各項元素之間的對應關係，四個基本元素包括使用者(User)、角色(Roles)、權限(PRMS)、會期 (Sessions)等，而權限再細分為操作(OPS)及物件(OBS)。各個元素的說明如下：

 使用者：通常是指與系統互動的人(human being)，另外也包含智慧型代理人，例如：機器人、行動電腦等等。

 角色：是一種工作功能或是一種工作職稱，可以視為組織或存取控制機制中扮演的角色，透過角色能得知在企業裡相關的權限以及責任。

 權限：存取機制中對於物件的權力，包括存取方式或是操作行為。

 會期：角色指派期間，指使用者啟動角色到結束使用角色的期間。

另外元件之間主要的對應關係包含使用者與角色的指派(User Assignment, UA)、權限與角色的指派(Permission Assignment, PA)[14][18]及使用者透過會期啟動角色的關係分別為User_sessions以及Session_roles。關係說明如下：

 使用者與角色之間的指派：使用者和角色之間有多對多的指派關係，亦即使用者可以擁有多個角色；而角色也可以被分配給多個使用者。

 權限與角色之間的指派：角色和權利之間有多對多的指派關係，亦即角色可以包含多個權利，而權利也可以被多個角色所擁有。

(15)

 User_sessions：當使用者要啟動使用者所能擔任的角色時，會先建立一個會期，即是User_sessions，使用者和會期是一對多的關係，一個使用者可以建立多個會期，但當使用者建立會期之後，表示這會期已經被使用者所建立，

也就是說一個會期只能對應到一個使用者。

 Session_roles：使用者透過啟動所擁有的角色建立會期，而每個會期中所包含使用者啟動的一或多個角色即為Session_roles，Session_roles跟角色屬於多對多的關係，也就是一個Session_roles會包含一到多的角色，角色也會被多個Session_roles所啟動。

2.1.2 安全原則

以角色為基礎的存取控制模型支援著名的三種安全規範[1][3][12][19][22]：

 最少權限(Least privilege)：最少權限是說企業給予角色適當的權限，不能給予超過角色權責的權限。如果給予過多的權限，角色沒有實際運用這些權限，會造成維護時多餘的負擔。而且過多的權限也可能因為使用者無心或是故意的操作，而危及系統的安全。根據以上考量因素，企業提供角色剛好足夠的權限即可，不需過度提供角色不需要的權限。

 權責區分(Separation of duties)：這是一種分工的方式，主要在於避免權責相衝突的兩個角色，操作同一資料所造成實務上的弊端。權責區分主要是在防止性質相互衝突的角色，由同一使用者來擔任，例如開立支票的角色與主管稽核支票的角色若由同一位使用者來擔任，將容易造成監守自盜的情事，此種問題就必頇在權責區分中將開立支票與稽核支票的角色明確劃分開。

而權責區分可分為靜態權責區分(Static Separation of Duties)或稱為強互斥(Strong exclusion)及動態權責區分(Dynamic Separation of Duties)或稱為弱互斥(Weak exclusion)。前者表示同一使用者不得扮演相互衝突的角色；

而後者表示同一使用者可以擁有相互衝突的角色，但是在執行時期，必需要擇一來擔任，不得同一時間來擔任相互衝突的角色。

(16)

靜態權責區分在實作上比較容易，但較不符合企業運作時的實際運作狀況；而動態權責區分需在執行時期依使用者實際扮演角色的狀況來判斷權限，比較符合企業現實狀況，也較能彈性運用，但實作需要考慮的狀況比較多也比較複雜。

 資料抽象化(Data abstraction)：即是將實際的資料隱藏於操作之中，使用者以日常職務類別(如會計系統的借、貸)來取代一連串電腦的低階(如讀、寫資料檔)操作，此種方式有助於提供給系統維護人員或使用者正確的語意，不致於因為誤解而產生錯誤的授權，並且能夠有效的保持整體資料的一致性。

2.1.3 角色階層

在以角色為基礎的存取控制模型中，擁有一個很重要的特性，就是角色階層 (Role Hierarchy)。透過角色階層可以了解到一個企業組織的組織規模以及授權結構。在企業組織裡，每個人因職務上的不同，扮演不同的角色，而角色彼此之間形成一種階層的關係。角色階層中上層的角色可以繼承下層角色的權限，如圖3 所示。

圖 3 角色階層示意圖

總工程師在角色階層中位於較高層級，同時可以繼承軟體工程師及硬體工程師的權限，而軟體工程師及硬體工程師又同時繼承一般工程師的權限，但彼此也

(17)

擁有屬於自己的權限，這種繼承的關係如同實際組織的架構，因此以角色為基礎的存取控制模型利於管理。

2.1.4 存取控制限制

雖然利用角色階層特性，可以方便權限分派控制的管理，但仍需注意以下幾點限制[10][19]：

 互斥角色 (Mutually Exclusive Roles)：此一原則是在某些情況下，避免同一位使用者同時身兼兩個角色，例如：採購人員與審核人員的角色不能同時由一個使用者擔任，以避免有弊端產生，則採購人員與審核人員即為互斥角色，故所有類似此一情況的角色應設為角色互斥。

 使用者數量(Cardinality)：對於一個角色可以給予幾個使用者擔任的數量應予以限制，尤其是一些擁有特殊權限的角色，如系統管理者，則可擔任系統管理者之使用者數量應控制在少量。



前提角色(Prerequisite Roles)：使用者必頇先具有一個角色，才能成為另一個角色，例如：在軟體開發計畫中，必頇先是開發計畫成員，才能成為開發計畫的測詴工程師；此外也可利用於權限上，一個角色先具有某個權限P，才能擁有另一個權限Q。

另外需要注意使用者是否擁有兩個以上的身份，否則使用者可以不同的身份進入，取得不同角色的權限，則上述所提之原則將被破壞。此外對於一個使用者可以使用的Session數量應給予限制。

(18)

2.2 以角色為基礎的委任模型

在以角色為基礎的存取控制中，使用者、角色和權限是互相關聯的，使用者可以擔任一或多個角色，而角色擁有可使用的權限，管理上可以方便的增減使用者可擔任的角色，也可以針對角色做權限的增減，但是這都是屬於靜態的存取控制管理，即事先規劃好使用者、角色和權限之間的關係，無法在實際運行中做到角色或權限的更改。

在一般企業組織中，時常會發生一些緊急事件需要把工作委託給其他使用者幫忙，像是主管出差把工作交付給下屬，或是某些工作需要加派人手來應付一些緊急狀況，對於這些權限都是短時間的指派，不可能更改設定好的存取控制架構，要如何解決權限上的臨時指派又不會變動到原本的存取控制架構，便是之後學者時常去探討的問題。

針對這個問題，Barka 和 Sandhu 學者在 2000 年提出了以角色為基礎的委任模型(Role-Base Delegation Model, RBDM)[7][8]，主要的想法是利用委任的方式，

達到在實際運行的系統中，透過委任的方法做到權限的授予。當系統在運行中，

使用者所擔任的角色如果是委任角色(Delegating Role)，該使用者就能夠把此角色委任給其他使用者，其他使用者得到了此角色就能使用該委任角色所能夠使用的權限，該角色稱之為被委任角色(Delegated Role)，利用委任的方式，就能夠在運行中的系統上，達到動態的權限分享，其他學者也有提出相關的委任模型，包含動態的委任[5][15][17][25][27][30][31]、階層式的委任[9]和群體委任等[28]，圖 4 為以角色為基礎的委任模型關係圖。

(19)

圖 4 以角色為基礎的委任模型[7]

2.2.1 基本元件

以角色為基礎的委任模型中包含了二個元件和四個對應關係，是由委任角色(Delegating Role)和被委任角色(Delegated Role)兩個元件組成，元件之間有原始使用者與角色的指派關係(Original User Assignment, UAO)、被委任角色與使用者的指派關係(Delegated User Assignment, UAD)、原始角色委任關係(Original Delegating, ORID)和被委任角色委任關係(Delegated Delegating, DELD)，委任角色利用 ORID 和 DELD 兩種關係把角色委任給其他使用者，透過 UAO 和 UAD 做權限的指派。各個元件說明如下：

 委任角色：主要包含兩種類型的成員，原始成員(Original members, Users_O(r)) 和被委任成員(Delegated members, Users_D(r))，原始成員的角色是由管理員直接指派，而被委任成員的角色是由原始成員所指派，原始成員指派角色給予被委任成員稱之為委任，兩種類型的成員皆可以把角色再委任給予其他成員，皆屬於委任角色。

 被委任角色：由委任角色透過委任的方式，取得委任角色所委任的角色，稱之為被委任角色，透過委任的方式，被委任角色擁有委任角色相對的被委任角色就會擁有委任角色的權限。

(20)

2.2.2 基本限制

以角色為基礎的委任模型有以下幾種限制[3]：

 完全委任(total delegation)：任何一個使用者擔任委任角色，當需要做委任動作把委任角色委任給其他使用者時，將會把委任角色所有的權限委任給另一個使用者。

 一步驟委任(one step delegation)：只能做一步驟的委任行為，無法更深一層做多步驟的委任，也就是只能由原始成員來做委任的動作，被委任成員將無法再委任給其他人。

 獨立撤回(grant-independent revocation)：任何能夠擔任委任角色的原始成員，皆能夠對擔任此角色的被委任成員做出撤回的動作，給予原始成員有較高的權力去保護從委任成員委任給其他成員的角色，優點在於如果被委任成員表現不好或是行為偏差，其他能夠擔任此委任角色的成員皆有權力去撤回此委任角色。

2.2.3 擴充限制

以角色為基礎的委任模型有以下幾種擴充限制[4]：

 部份委任( partial delegation)：在部份委任中，權限分為兩種類型，可委任的權限(delegable permissions)和不可委任的權限(non-delegable permissions)，在委任成員要做委任動作時，只會把可委任的權限委任給被委任成員，對於權限管理上有較高的安全性，能夠分離出可委任權限和不可委任權限。

 多步驟委任(multi-step delegation)：被委任成員接受到委任角色之後，能夠再委任給另一個被委任成員，管理上會設置一個限制委任層度，委任層度將不能超過所限制的層度，每往下委任一層將會逐一減少委任層度，直到委任層度等於所限制的層度，將不能繼續委任。

 相依撤回(grant-dependent revocation)：被委任成員所擔任的委任角色不能被能夠擔任此角色的委任成員所撤回，只能由當初委任此角色的委任成員撤回

(21)

此角色，用此限制的好處在於，透過委任角色以及被委任角色的相依性，容易追蹤此角色是由那位委任成員委任，也能夠保護被委任成員的權力，但也很難防止委任成員管理不善。

 角色階層(hierarchical roles)：委任在角色階層中有三種主要的類型，向上委任(upward delegation)、向下委任(downward delegation)和跨部門委任(cross sectional delegation)，向上委任在角色階層中是不太需要的一種方式，在角色階層的特性上，較高階層角色的權限已經包含了較低階層角色的權限，不需要再由委任的方式取得權限；向下委任是一個讓角色階層較低的成員能夠晉升加入到較高階層角色的一種方式，利用委任的方法，能夠暫時提供低階層角色較高層的權限，卻不會破壞整個角色階層；跨部門委任在角色階層中是一個很有用的委任方式，他能夠把權限分享給不同角色階層下的成員，在角色階層下，對於權限的分享是一種便利的角色分享方式。

2.2.4 群體委任架構

以角色為基礎的委任模型漸漸被學者們所重視之後，相關研究不斷的推陳出新，由 Hua Wang 等學者在 2006 年所提出的以角色為基礎的群體委任架構(A framework for role-based group delegation in distributed environments)已經開始加入了團隊的概念[28]。他們根據 Barka 和 Sandhu 學者所提出的以角色為基礎的委任模型(Role-Base Delegation Model, RBDM)[7][8]再加入了群體(group)的元件，形成新的委任模型，圖 5 為以角色為基礎的群體委任模型。

(22)

圖 5 以角色為基礎的群體委任架構[28]

以角色為基礎的群體委任模型透過委任的方式讓使用者加入到團隊中，只要委任角色所要委任的使用者符合限制條件，則使用者能夠接受到委任角色的委任而加入團隊，使用者加入團隊之後，透過使用者對使用者(user to user)之間的互相委任達到分享其委任角色之權限。以角色為基礎的群體委任模型中，多加了委任角色與群體的指派關係(Delegate Group Assignment, GAD)、原始角色與群體委任關係 (Original Group Delegation, ORIGD) 和被委任角色與群體委任關係 (Delegated Group Delegation, DELGD)三種關係，委任角色利用 ORIGD 和 DELGD 兩種關係把角色委任給使用者而形成一個群體，透過 GAD 來做權限的指派。

雖然以角色為基礎的群體委任加入了團隊的概念，但還是透過使用者對使用者的委任方式達到角色的委任，沒有利用到以角色為基礎的存取控制所提出針對角色管理的優勢；在權限部份也沒有提出針對權限的管理，單純只有透過角色所擁有的權限來指派權限給使用者，安全性較為不足。

(23)

2.3 以團隊為基礎的存取控制

以角色為基礎的存取控制提供了一個相當有效益的存取控制方法，透過角色與權限之間的關係，降低了企業組織上相當大的管理成本。在合作的環境中 [6][21][23]，企業組織開始運用團隊來完成特定的工作及目標，但是以角色為基礎的存取控制雖然提供了強大的存取控制管理方式，利用了使用者、角色和權限之間的關係，達到單一的使用者、角色和權限的指派，對於多使用者的團隊形成，

並沒有提供有效的管理方法，所以無法滿足現階段企業組織對於團隊的管理以及運用。

鑑於團隊在組織中已被使用，又以角色為基礎的存取控制對於團隊管理上的不足等問題， Thomas 等學者在 1997 年提出了以團隊為基礎的存取控制 (Team-based Access Control, TMAC )[24]，利用了以角色為基礎的存取控制所提出的角色權限的關係和團隊目標的結合，提出團隊 (team) 、團隊成員 (team members/users)、團隊角色(team roles)、團隊權限(team missions)、目標類型(object types)和目標實例(object instances)，團隊中包含了團隊成員和使用者，在全部成員中，會有一個團隊的領導人(team head)，每個團隊成員所擔任的角色集合即為團隊角色，目標類型裡面包含了許多目標實例，目標實例中所需要的權限總和將會是目標類型所需要的權限，透過團隊角色以及目標類型的權限集合，就形成了團隊的權限，圖 6 為以團隊為基礎的存取控制。

(24)

圖 6 以團隊為基礎的存取控制 [24]

Fahad T. Alotaiby和J. X. Chen兩位學者在2004年也提出了一個以團隊為基礎的存取控制模型2004(A Model for Team-based Access Control (TMAC 2004))[4]，

透過以角色為基礎的存取控制既有的使用者、角色和權限，又增加了團隊 (team) 、團隊使用者 (team users) 、團隊角色 (team roles) 、團隊權限 (team permission)、團隊實例(team instance)和團隊情境(team context)，團隊事先在定義時間定義好之後，在執行時間透過會期來執行團隊實例，並且根據團隊的情境做進一步的權限限制，如圖7以團隊為基礎的存取控制模型。在此模型中，主要有以下五個關係：

 角色團隊關係(Role-Team Relation)：團隊角色的形成，是根據企業組織形成團隊所需要的角色來完成團隊的目標。

 使用者團隊關係(User-Team Relation)：團隊使用者是組織內部使用者並且必頇能夠使用團隊中所需要的角色。

 團隊會期關係(Team-Session Relation)：每個使用者能夠執行角色加入團隊，使用者能夠同時開啟多個會期，扮演不同角色加入不同團隊，但限制同一個使用者不能重複加入同一個團隊會期中。

(25)

 團隊情境關係(Team-Context Relation)：每個團隊實例必頇要符合它的團隊情境才能夠執行團隊的權限。

 團隊權限關係(Team-Permission Relation)：當使用者加入了團隊，而團隊也符合了團隊情境限制，使用者就能夠把他所能執行的權限帶進團隊中，並且把權限給予其他在團隊中的使用者。

圖7 以團隊為基礎的存取控制模型 [4]

2.3.1 基本元件

針對團隊的存取控制中，不同學者所提出的團隊為基礎的存取控制模型 [4][16][24][26]，都提到了相同的團隊基本元件如下：

 團隊：在執行時間前優先定義出團隊的成員，根據團隊的目標來挑選適合的使用者加入團隊，是直接針對使用者來做團隊的管理。

 團隊使用者：屬於企業組織內部的使用者，透過團隊領導人的指派加入到團隊中。

 團隊角色：每個團隊使用者加入到團隊後，會把團隊使用者所合適的角色加入到團隊中，而團隊角色即是每個團隊使用者所提供的角色集合，透過每個使用者提供的角色形成團隊角色之後，加入團隊的使用者即可被指派團隊角色給予使用。

 團隊實例：當團隊在定義時間定義好團隊成員後，透過團隊實例在執行時間執行團隊所要完成的工作，每個使用者可以使用角色加入多個團隊實例，但

(26)

同一個使用者只能加入同一個團隊實例，團隊實例受到團隊情境控制，要符合團隊情境才能夠開啟團隊實例。

 團隊權限：根據團隊使用者所加入的角色提供團隊權限，每個權限都要符合企業組織內部原本的權限，根據團隊的類型來決定出團隊有那些權限，再把這些權限指派給團隊角色。

(27)

2.4 小節

在存取控制的相關研究中，以角色為基礎的存取控制已經被廣為接受以及普遍的運用在各個領域上，利用所提出的角色元素，透過角色的指派給予使用者以及權限指派給角色，有效連接使用者與權限之間的關係，提昇管理者對於使用者以及權限管理的效益，雖然以角色為基礎的存取控制已經提出了相當有效的存取控制管理方法，但卻只針對單一的使用者以及權限做指派，所以之後有許多學者利用以角色為基礎的存取控制，運用在更多的領域上。

在以角色為基礎的存取控制中，缺少了緊急權限指派和團隊的概念，之後學者針對這兩個以角色為基礎的存取控制所欠缺的元素，提出了以角色為基礎的委任模型和以團隊為基礎的存取控制。在以角色為基礎的委任模型中，利用了委任的機制，在運行系統上做動態的權限指派動作，達到緊急權限指派的目的；以團隊為基礎的存取控制中，加入了以角色為基礎的存取控制所沒有的團隊元素，在現今團隊合作環境普遍運用下，在原有的存取控制中加入了團隊概念，對於管理者在管理團隊角色權限上更能夠有效率的管理。

雖然以角色為基礎的委任模型和以團隊為基礎的存取控制都提出了以角色為基礎的存取控制上所欠缺的元素，但是在管理上還是不夠具有彈性，所以本研究針對以角色為基礎的存取控制所欠缺的緊急權限指派和團隊的概念並加以改良以角色為基礎的委任模型和以團隊為基礎的存取控制所提出的特性加入到以角色為基礎的存取控制，而提出一個新的「架構在RBAC上的團隊委任模型」。

(28)

第三章架構在RBAC上的團隊委任模型

企業組織已經開始慢慢利用合作的環境，透過合作的方式形成團隊，針對企業組織的需求，利用團隊達到所要的目標。團隊的形成是一門學問，而團隊中的管理更是不可或缺的一環，有不少學者利用了以角色為基礎的存取控制所提供的有效存取控制加入了團隊的要素，但是在權限管理上卻沒有提出有效的管理方式，在企業組織中，有效的管理可以降低企業的管理成本，但是安全性方面也不能輕忽。本研究將會探討團隊的管理方式、團隊權限的限制和如何利用委任的方法達到團隊角色指派給使用者。

本研究之架構在RBAC上的團隊委任模型，分成團隊的形成、團隊角色、團隊的權限、團隊的委任和定義五個部份做介紹，先了解團隊是如何形成，根據團隊的形成而產生團隊角色，再說明團隊的權限如何定義以及分享，接著說明委任在本研究中的重要性，最後根據本研究的架構，提出七點相關定義與限制，包含了基本架構關係、團隊角色的形成和團隊角色及團隊的撤銷。

3.1 團隊的形成

團隊形成的方式有許多種，但不外乎都是為了某個目的及目標才會形成團隊，團隊的定義就是一群人一貣工作以完成共同目標，從定義來看[2]，可以很明確了解到團隊的意義，從中可以發現，團隊主要有三個形成要素，團體、工作和共同目標。團體必頇要由人來組成，成員也要大於一位才能算是團體，像是企業組織是由公司員工組成團隊，醫院診所則是由醫師護士等來形成，甚至從跨組織的角度來看，不同公司企業也有可能為了某個目的而形成合作的環境；團體的運作，必頇靠著團隊裡每一位成員共同努力，而每個團隊成員在團隊中所要做的工作不同，扮演的角色也不同，透過每個成員的專長才能讓團隊持續運作；有了目標就很容易了解到團隊的需求，透過要完成的團隊目標，可以明確知道團隊所需要的成員，根據團隊的需求找尋適當的人選。

(29)

由此可見，使用者、角色和權限在團隊中也扮演相當重要的角色，為了達到團隊目標，從中挑選出團隊需要且適當的角色，而能擔任這些角色的使用者，則可以擔任團隊成員形成了一個團體，透過這些使用者所擁有的權限，來讓團隊能夠持續的運作達到團隊所要的目標。在以角色為基礎的存取控制中已經提供了完善對於使用者、角色和權限的管理，不過都是針對單一使用者分別處理，並無團隊的概念，本研究利用了以角色為基礎的存取控制管理上的優勢，加入了團隊的概念，透過使用者所能擔任的角色加入團隊，再根據角色的權限進行分析達到完善的存取控制管理，圖8為本研究之架構在RBAC上的團隊委任模型。

圖 8 架構在 RBAC 上的團隊委任模型

團隊的形成根據團隊的需求來決定由那些角色加入團隊，由管理者決定團隊所包含的角色，使用者透過所能擔任的角色與團隊所需要的角色比對，以決定是否有權限加入到團隊中，在團隊進行中，可能會根據團隊目標的改變或是需求的不同進而更改團隊中的角色，對團隊角色內容做角色的增減，當團隊完成目標或是某些原因造成不再需要團隊，管理者也能夠撤銷整個團隊。一般團隊大多是因為短時間的需求而形成，像是公司內部的專案或是緊急醫療團隊[29]，如果為了短時間的團隊形成，對使用者逐一設定權限，對於企業組織的管理成本將會大幅提高，所以本研究利用了既有的以角色為基礎的存取控制模型加上了團隊角色的

(30)

概念，根據團隊需求，透過需求角色的集合形成一團隊角色，利用委任的方式，

把團隊角色的權限分享給能夠加入團隊的使用者，降低權限逐一指派給使用者的管理成本，又因為團隊的形成是短時間運作的因素，利用團隊角色的撤銷也能大幅降低權限撤銷的成本。

3.2 團隊角色

角色是使用者和權限之間重要的橋樑，透過角色更容易管理使用者和權限，

團隊角色也是扮演一樣的角色，透過團隊角色，能夠方便的把權限指派給團隊成員。團隊角色主要是由管理者來決定團隊所需要的角色，透過管理者的選擇，把所需要的角色集合貣來便形成團隊角色，因為有繼承的關係又要符合最少權限的特性，找尋角色的方式會以最低階層的角色又符合團隊需求的角色來加入團隊，

達到較高的安全機制，目前判斷是否符合為最少權限之角色，必頇由管理者自行做判別，本研究並無加入此判斷規則。

本研究利用了委任的方式達到權限的指派，根據之前學者提出的以角色為基礎的委任模型，使用兩種類型的角色，原始角色 (original role) 和委任角色 (delegated role)，一般使用者在傳統的以角色為基礎的存取控制設定下，所能擔任角色皆為原始角色，當管理者選擇好團隊需求角色而形成團隊角色時，這時的團隊角色稱之為委任角色，若沒有透過團隊角色來指派權限給使用者，可能必頇要使用以下兩種方式來達到權限的指派：

 管理者直接指派：管理者針對每個加入團隊的使用者進行權限的指派，因為團隊的形成都是臨時或者短時間的運作，若管理者逐一進行權限指派，勢必是個非常耗時且浪費成本的管理方式；權限撤銷部分，當管理者要刪除團隊角色或是團隊完成目標需要解散時，管理者又必頇逐一的進行權限撤銷，管理上並不符合管理成本。

 使用者之間互相委任：委任的方式，主要就是要解決當遇到緊急事件時，及時把角色委任給其他使用者，來處理臨時發生的事件，過去以醫療團隊例子

(31)

最為貼切，當病患突然引貣併發症，可能臨時需要其他不同科的醫師檢查，

這時候主治醫師就能夠把他的角色委任給其他不同科的醫師，讓他們有權限來對病患做治療，這屬於非常緊急，團隊運行時間也較短的團隊，如果對於團隊需求時間較長或是成員較多的團隊，團隊成員之間的委任頻率可能會增加許多，管理上也會較繁瑣。

對於以上兩種方法的問題，利用團隊角色就能夠在使用者以及權限之間作連結，管理者只需要針對團隊角色做管理，選擇出團隊需要那些角色，再把團隊角色委任給使用者即可，角色撤銷的部份，也是針對團隊角色進行處理，把不需要的角色移除，自然角色連帶的權限也跟著移除，若團隊任務完成或需要解散時，

管理者也只需要直接把團隊角色撤銷，不需要再逐一撤銷使用者的權限。

團隊角色的選取上，必頇要符合以角色為基礎的存取控制所提出的安全原則，最少權限和權責區分，因為角色繼承的關係，在選取團隊所需角色時，必頇選取已達到所需求權限的最少權限角色為主，避免在權限管理上產生不安全的權限指派；管理者在選取團隊需求角色時，也要考慮到角色間是否有衝突，避免發生兩個衝突角色加入到同一團隊中，造成團隊安全危機。

3.3 團隊的權限

在原始角色的定義上，為了達到原始角色加入團隊角色之後，團隊角色自動分享權限的目的，又因為使用傳統以角色為基礎的存取控制中的權限設定，無法達到權限分享上的安全性與便利性，在本研究中，改變傳統以角色為基礎的存取控制中權限的設定，每種角色將會有兩種型態的權限設定，一種是公開(public) 的權限，另一種是私有(private)的權限，當一個角色加入到一個團隊中，所帶過去的權限只能使用公開的權限(Public Permission, PuP)，將無法使用以及分享私有的權限(Private Permission, PrP)給其他團隊中的角色，以確保達到較高的安全性；而在團隊中將會多一個原始不屬於任何一個原始角色的權限，稱為團隊權限 (Group Permission, GrP)，來表示加入團隊的角色能使用團隊中所分享的權限，團

(32)

隊權限則是由團隊所需要的原始角色中所有原始角色公開權限的集合。圖9為委任角色權限示意圖。

圖 9 委任角色權限示意圖

權限的定義上，為了達到管理上的方便以及迅速，在權限設計階段就要把公開權限和私有權限定義好，根據每個原始角色權限去判斷是否能夠指派給其他角色，把原始角色中較重要不能分享的權限設定成私有權限，而其他權限則是公開權限，使用這種方式能夠在角色委任上做較快速的權限分享，當管理者把原始角色加入到團隊中時，只有公開權限會隨著角色加入到團隊中，當團隊所需要的角色較多時，管理者只要針對原始角色的選擇，不需要再去考慮權限的指派問題，

達到較方便快速的管理。

過去學者提出的團隊存取控制模型[4][16][24][26]，大多都有以下兩個主要問題：

 使用者：團隊角色的選擇都是直接針對使用者，當企業組織規模越來越大時，組織內部的使用者數量將會持續成長，對於針對使用者的管理上，會越來繁瑣，而企業組織為了要研發新產品或是處理某問題，常常會形成團隊，

企業內部的團隊越來越多時，針對使用者的管理也會開始無法負荷團隊數量的成長。

(33)

 權限：過去學者提出的權限管理方法，也是針對角色個別的權限進行權限的指派，當團隊成員越多時，針對權限逐一指派的方式，在權限管理上勢必會造成相當大的負擔。

本研究則是加入了團隊角色來間接管理使用者以及權限之間的指派，此方法主要是利用以角色為基礎的存取控制已經架構好的存取控制模型，透過角色來管理使用者，所以使用團隊角色也能夠輕易解決使用者指派的問題，根據團隊的需求挑選適合的角色，再去判斷使用者是否能夠擔任團隊所需求的角色加入團隊，

此方法並不會影響已經設定好的以角色為基礎的存取控制架構，利用團隊需求只是短時間運作的特性，建立臨時的團隊角色來管理使用者；過去團隊針對使用者逐一做權限的指派不外乎是為了提高整個架構的安全性，如果仔細分析之後，會發現這種指派方法主要是把權限區分為可指派給其他使用者和不可指派給其他使用者，利用這特點事先把權限分類成公開權限和私有權限之後，再來的指派動作就不需要逐一針對使用者與權限上去做管理，只要團隊所需要的角色透過管理者加入團隊之後，直接把此角色的公開權限指派給團隊角色，不僅能夠維持整個架構的安全性，也降低了管理者逐一針對使用者做權限指派的工作。

3.4 團隊的委任

角色委任主要要解決以角色為基礎的存取控制對於臨時權限指派的問題，在以角色為基礎的存取控制上所設定好的架構都屬於靜態的存取控制架構，並無提供對於動態執行時的權限修改方法，所以之後有許多學者以以角色為基礎的存取控制為基礎針對委任關係做進一步的研究，解決以角色為基礎的存取控制在緊急權限指派上的問題。

委任在存取控制上主要有以下幾個優點：

 及時的權限指派：當發生緊急事件或是臨時需要把工作交付給他人請求幫忙的時候，能夠透過委任把角色委任給其他使用者，其他使用者就能夠利用委任角色的權限來輔助緊急事件的處理，委任的好處是，他不破壞既有的存取

(34)

控制架構就能達到權限的指派，當工作結束之後，直接撤銷委任角色即能把指派的權限收回，也不會造成安全性上的顧慮。

 虛擬的委任角色：委任是利用建立虛擬委任角色來達到權限的指派，當委任角色要把角色委任給其他人時，當收到委任角色委任的使用者，會擁有一個被委任角色，而此被委任角色因為是臨時新增的虛擬角色，所以並不會影響原本的存取控制架構，當委任結束後，委任角色只要把被委任角色撤銷，就能把委任出去的角色收回，管理上非常迅速以及方便。

 多層的委任方法：多步驟的委任方法，也是委任管理上的優勢，當被委任角色需要更多的使用者來解決突發狀況時，被委任角色能夠再把委任角色委任給他的角色委任給其他使用者，來應付更多元的緊急事件，當事件結束後，

最初的委任角色使用者只需要把第一層的委任角色撤銷，之後委任出去的角色也一併全部撤銷，對於原始以角色為基礎的存取控制架構中的角色權限管理，不會有任何的變動導致架構安全受到威脅。

本研究利用了委任的優勢加入到團隊中，把委任的特性與團隊角色做結合，

團隊角色可視為一個虛擬的委任角色，每個團隊所需要的角色透過委任的方式把自己的角色委任給團隊角色，團隊角色再透過委任給加入團隊的使用者，在團隊角色管理中，想要從團隊角色中移除某個角色，只要撤銷原始角色到團隊角色的委任即可，如果是要移除整個團隊，也只需要把每個團隊角色中接收到原始角色的委任撤銷即可完成移除的管理，原始角色委任到團隊角色為第一層的委任，團隊角色委任給使用者為第二層的委任，根據委任的特性，第一層委任如果被撤銷之後，第二層委任也就跟著撤銷，也符合本研究的管理架構，圖10為團隊角色委任示意圖。根據本研究提出的權限管理中，每個原始角色的權限分為公開權限和私有權限，當原始角色委任給團隊角色時，只會委任公開權限到團隊角色中，因為權限跟角色有關聯，所以如果角色被撤銷權限也將會跟著被撤銷，也符合了團隊管理上的靈活性。

(35)

圖 10 團隊角色委任示意圖

3.5 定義

本研究之相關定義主要分成團隊角色關係、團隊的委任、權限的授予和權限的撤銷四個部份，定義一主要說明團隊角色與使用者、角色和權限之間的關係，

定義二、定義三和定義四在說明團隊角色如何委任給予使用者，定義五在說明團隊角色之權限指派給團隊角色之條件，定義六和定義七在說明團隊角色的撤銷以及團隊的解散。

定義1：

 Tr  R where R is the total set of the roles in the organization information system;

 TrUA  U x Tr is a many to many user to team role assignment relation;

 TrPA  P x Tr is a many to many public permission to team role assignment relation;

 TrRA  R x Tr is a many to many original role to team role assignment relation;

第一層委任

第二層委任

使用者團隊角色原始角色

(36)

U為組織內部能夠使用系統之使用者，R為組織內部所擁有的角色，P為組織內部所擁有的權限，T為組織所需要完成某目標之形成的團隊，Tr為組織所形成的團隊中所需要的原始角色集合即團隊角色，TrUA為團隊角色與使用者的指派，

TrRA為團隊角色與原始角色的指派，TrPA為團隊角色與公開權限的指派，U、R、

P、UA和PA為以角色為基礎的存取控制基本元件，UA為角色和使用者的指派關係，PA為權限與角色的指派關係，UA和PA在以角色為基礎的存取控制中已經定義好之間的關係。Tr、TrUA、TrPA和TrRA為本研究所提出的定義，Tr屬於角色，

Tr中的角色皆為企業組織中的角色，Tr是管理者依據團隊所需求的原始角色的集合而形成，TrUA為使用者與團隊角色之間的指派，屬於多對多的關係，TrPA為公開權限與團隊角色之間的指派，屬於多對多的關係，TrRA為原始角色與團隊角色之間的指派，屬於多對多的關係。

在團隊為基礎的委任模型中，首先定義出使用者能夠擔任的角色，如定義 2。

定義 2：Uusers, o_roleiroles,

cando_role(U) = {o_role₁, o_role₂, …, o_rolen}

U 為使用者，cando_role(U)為一個使用者 U 所能夠擔任的角色集合，o_rolei為使用者能夠擔任的其中之ㄧ的角色，一個使用者可以擔任多種 o_role 的角色，但是同一個會期，使用者只能挑選其中一種角色擔任。

管理者開創一個新團隊時，需要先定義好一個團隊所需要的角色有哪些，如定義 3。

定義 3：TTeams, o_roleiroles,

team_role(T) = {o_role1, o_role2, …, o_rolen}, n2

T 為一個團隊，team_role(T)表示 T 此團隊需要哪些角色，而一個團隊應包含兩個以上的 o_role 角色，n2 即表示團隊中必頇要兩個角色以上的成員才能形成一個團隊。

(37)

在執行階段，使用者選擇了一個其所能擔任的角色，如定義 2，且該角色為 一個團隊中所需要的角色，如定義 3，則此使用者能夠以該角色之身分加入此團隊，如定義 4。

定義4：Uusers, TjTeams, o_roleiroles,

o_role_icando_role(U) and o_role_iteam_role(T_j)  Uteam_member(T_j) and URA(U, d_role_Tj), where d_role_Tj

=team_role(Tj)

o_rolei為一個使用者所能擔任的角色之ㄧ，且為團隊 Tj所需要的角色之一時，

則此使用者 U 即可加入團隊 T_j，表示使用者 U 為團隊 T_j中的一員，同時會將此 團隊角色 team_role(Tj)視為一個 d_roleTj，並將此 d_roleTj授權給使用者 U 擔任，

使用者往後將可利用 d_role_Tj來執行團隊角色 team_role(T_j)的工作。

當團隊形成之後，就必頇把團隊中的權限定義完成，如定義 5。

定義 5：o_roleroles, PuPPermissions, PrP Permissions,

T_jTeams,

o_roleteam_role(Tj) and perm(o_role)={PrPPuP}

PrPteam_perm(Tj)

當 o_role 為團隊 T_j中所需要的角色，且此 o_role 角色中的權限包含有私有權限

（PrP）和公開權限（PuP）的集合，則 o_role 的私有權限（PrP）將不能成為團隊的權限，亦不能委任給其他團隊角色。

團隊的形成是由團隊管理員所組成，而團隊在進行中可能會針對團隊的需求做角色的增減，所以當原有的團隊成員被迫離開團隊時，團隊名單中將會移除該名使用者，而該使用者的所有 d_roleTj將會被撤銷，如定義 6。

定義 6：Uusers, TjTeams, o_roleiroles Uteam_member(T_j) and URA(U, d_role_Tj) and

o_role_irevoke_role(T_j)  revoke_user(T_j)= { U }, where o_role_id_role_Tj

(38)

使用者為團隊 T_j 中的成員，且使用者所擔任的角色為團隊所需求的角色，當團隊不再需要此角色時，則透過 revoke_role(Tj)把此角色從團隊中刪除，當使用者所擔任的角色為從團隊中刪除的角色，則透過 revoke_user(T_j)刪除加入團隊之使用者，撤銷其權限。

而團隊活動結束之後，管理者必頇把團隊解散，避免在團隊活動結束後，權 限還被其他使用者繼續使用，利用團隊的解散，可以不需要針對使用者逐一撤銷權限，管理上較為方便，團隊的撤銷如定義 7。

定義 7：o_roleiroles, TTeams

If team T finished then revoke_role(T)={ o_role1, o_role2,...,o_rolen } 當團隊完成所要完成的工作或是因為某些因素必頇要管理者撤銷其團隊，透過 revoke_role(T)，把團隊T中所有的原始角色撤銷，原始角色撤銷之後，團隊中所有原始角色之公開權限也跟著移除，藉此解散團隊，使用者將無法再加入此團隊。

3.6 小節

本研究所提出「架構在RBAC上的團隊委任模型」是針對以角色為基礎的存取控制所欠缺的緊急指派和團隊兩個元素加以結合而提出新的團隊委任模型，根據之前學者所提出的以角色為基礎的委任模型和以團隊為基礎的委任模型所提出的概念加以結合，並針對此兩個存取控制模型加以改良讓管理上更有效率。

本研究利用以角色為基礎的委任模型所提出的委任方法，在運行的系統上達到動態的權限指派，但過去學者所提出的委任架構，都只針對委任的方法和委任的限制來加以定義，對於委任的權限則是針對使用者來進行權限的指派，失去了以角色為基礎的存取控制所提出的角色元素來連結使用者和權限之間的關係，所以本研究把以角色為基礎的存取控制中的權限分成公開權限和私有權限，利用公開權限皆為可分享權限的特性，委任角色把角色委任給被委任角色時，此角色的公開權限隨著此角色的委任而指派給被委任角色，在撤銷被委任角色權限時，管

(39)

理者只需要撤銷其委任給其他使用者之角色即可隨同撤銷其權限，不需要針對委任給使用者的權限逐一撤銷。

本研究也加入了以角色為基礎的存取控制中所欠缺的團隊元素，配合委任的方法達到動態運行中團隊權限的即時指派，過去學者所提出的團隊存取控制模型，都是靜態的團隊形成，透過管理者先建立好團隊的成員和團隊權限，再由使用者加入團隊使用團隊權限，本研究則是配合委任的特性，透過緊急權限的指派，管理者能夠即時的依照團隊的需求改變團隊所需要的角色以及權限，達到動態的權限指派。

根據以角色為基礎的存取控制所欠缺的兩個重要元素，本研究把委任和團隊的特性加入以角色為基礎的存取控制中，提出一個新的「架構在RBAC上的團隊委任模型」，利用團隊角色來連接使用者以及權限之間的關係，透過委任的方式達到團隊角色動態委任給使用者，團隊的權限則是分為公開權限以及私有權限，

利用公開權限為可分享權限之特性，委任團隊角色給予使用者時，此團隊角色之公開權限隨著團隊角色指派給予使用者，使管理者對於權限上的管理較為方便，

更方便於團隊安全性上的控管。

(40)

第四章系統實作與展示

本章節介紹系統實作部份，根據本研究所提出的架構在RBAC上的團隊委任模型，利用ASP來進行網頁模型實作，資料庫選用ACCESS當儲存的主要工具，最後根據此系統來分析本研究的主要功能。

4.1 程式開發環境

本研究系統實作主要利用ASP(Active Server Pages)設計，透過網頁的互動以及使用Script語言加在HTML標記的網頁中，在伺服器端產生動態的互動網頁內容，ASP和VBscript語言都是和HTML標記結合在一貣，直接用單純文字檔案編輯，並不需要額外的程式進行編譯，只需Web伺服器支援ASP，就可以在網頁加上程式碼，ASP程式最後傳到客戶端電腦仍然是HTML標準網頁，所以不論使用何種瀏覽器都能夠正確的顯示，伺服器後端的處理能夠輕易連接ACCESS資料庫，對於資料的儲存、查詢和管理上相當方便，所以本研究使用ASP動態伺服器網頁技術搭配ACCESS資料庫來實作系統的雛型架構。

4.2 系統架構

本研究利用網頁方式呈現系統雛型主要有幾個架構，以角色為基礎的存取控制基本系統設定、團隊角色管理和使用者登入查詢權限三個部份。

 以角色為基礎的存取控制基本系統設定：以角色為基礎的存取控制利用了使用者、角色和權限管理系統的存取控制架構，在以角色為基礎的存取控制基本系統設定架構中，透過新增刪除使用者、新增刪除角色、新增刪除權限來設定以角色為基礎的存取控制中的使用者、角色和權限管理，再透過系統角色指派和權限指派對使用者和角色進行指派動作，達到基本以角色為基礎的存取控制架構所提出的使用者、角色和權限關係。

 團隊角色管理：團隊角色管理主要是本研究主要的工作之一，新增團隊之後，管理者開始選擇原始角色加入團隊，透過原始角色的加入，漸漸形成團隊角色和團隊角色的權限，在團隊管理中，管理者能夠對團隊做原始角色的

(41)

新增和刪除動作，當團隊完成所要完成的工作或是其他理由解散團隊，管理者也能夠直接對團隊進行撤銷。

 使用者登入查詢權限：使用者透過登入來查詢目前所能擔任的角色以及能夠使用的權限，本研究主要透過使用者登入查詢觀察使用者加入團隊以及團隊中原始角色的改變和團隊角色的撤銷對於使用者權限的更動，來驗證本研究雛型架構的正確性。

4.3 系統功能

本系統是根據本研究所提出「架構在RBAC上的團隊委任模型」所開發的資訊系統，系統根據「架構在RBAC上的團隊委任模型」主要有三大功能，管理者功能包含以角色為基礎的存取控制基本系統設定和團隊管理兩項功能，使用者功能提供使用者登入查詢權限。在以角色為基礎的存取控制基本系統設定中，包含了五項子功能，使用者、角色、權限、角色指派和權限指派；在團隊管理中，包含了二項子功能，新增團隊和管理團隊，如圖11為系統管理者畫面。

圖 11 系統管理者畫面

(42)

4.3.1 基本系統設定

在以角色為基礎的存取控制基本系統設定中，有五項管理設定，使用者管理、角色管理、權限管理、角色指派和權限指派，讓管理者能夠透過管理達到以角色為基礎的存取控制的基本系統設定。

 使用者管理：本系統使用者管理中，使用者必頇為企業組織內部的使用者，

由管理者做新增刪除的管理，如圖12 使用者管理。

圖 12 使用者管理

(43)

 角色管理：本系統角色管理中，角色必頇屬於企業組織內部的所定義的角色，由管理者做新增刪除的管理，如圖13為角色管理。

圖 13 角色管理

(44)

 權限管理：本系統權限管理中，權限必頇屬於企業組織內部的所定義的權限，由管理者做新增刪除的管理，本研究在權限設定上，分成公開權限和私有權限，在權限管理中先設定好權限的類型，權限主要把公開權限和私有權限先行分類，在此階段分類完成之後，在透過權限指派給角色步驟來達到角色權限的指派，利用此方式分開權限，能夠在團隊角色權限管理上較為方便，如圖14為權限管理。

圖 14 權限管理

(45)

 角色指派管理：以上使用者、角色和權限都由管理者設定好之後，接下來就是針對使用者角色的指派管理，透過使用者角色的指派，管理者能夠設定好使用者所能擔任的角色，在之後的系統中，使用者能夠根據所擔任的角色來登入系統，執行使用者的工作，管理者透過下拉式選單來選擇角色指派給使用者，圖15為角色指派管理。

圖 15 角色指派管理

(46)

 權限指派管理：根據管理者所新增的角色、私有權限和公開權限，在權限指派管理做權限的指派，管理者透過下拉式選單選擇要指派的私有權限或公開權限來指派給角色，圖16為權限指派管理。使用者、角色、權限、角色指派和權限指派都設定完成之後，以角色為基礎的存取控制基本設定就算完成，

接下來就是透過以設定好的以角色為基礎的存取控制基本架構來做團隊角色管理以及團隊角色的委任動作。

圖 16 權限指派管理

(47)

4.3.2 團隊角色管理

在以角色為基礎的存取控制基本架構設定完成後，管理者能夠透過新增團隊和管理團隊來管理團隊角色。

 新增團隊：在新增團隊中，管理者針對企業組織的需求新增團隊，團隊角色透過新增團隊形成此團隊專屬的團隊角色，透過團隊角色委任讓有權限的使用者使用團隊角色來完成團隊所要達成的目標，當團隊任務完成或是團隊角色必頇解散，管理者也能透過此功能解散團隊，圖17為新增團隊。

圖 17 新增團隊

(48)

 管理團隊：新增團隊完成之後，就要針對團隊進行原始角色的選擇，首先管理者要先選擇所要管理的團隊，如圖18選擇團隊，選擇完之後進入團隊管理，管理者能透過下拉式選單選擇要加入團隊的原始角色，也可以透過此功能撤銷團隊中的原始角色，當管理者新增與撤銷原始角色時，團隊角色權限會即時顯示目前團隊角色所擁有的權限，而團隊角色之權限是根據團隊中所需求之角色的公開權限集合，圖19為管理團隊。

圖 18 選擇團隊

圖 19 管理團隊

(49)

4.3.3 使用者登入查詢權限

使用者登入查詢權限為使用者功能，本系統主要是做前端的團隊委任模型架構的雛型，並沒有對於使用者登入之後能夠執行的實際功能，所以在使用者登入查詢權限功能中，只展示使用者能夠擔任的角色以及使用者所擁有的權限，由此表示使用者如果在實際的完整系統中，能夠使用所顯示的角色登入系統，執行該角色所能執行的權限，透過使用者登入查詢權限主要是要展示本研究針對團隊角色的委任，透過團隊角色的委任，使用者如果能夠擔任團隊角色裡的原始角色之一，使用者即可選擇此團隊角色登入此系統，本功能主要要觀察使用者在團隊角色撤銷以及更改團隊角色中的原始角色的權限變化，來驗證本研究所提出的架構在RBAC上的團隊委任模型。

4.4 系統展示

此章節分成兩部份說明，第一部份先介紹管理者設定，第二部份依據管理者設定結果，顯示使用者選擇加入團隊之改變。

4.4.1 管理者設定

管理者首先在基本系統設定中，把使用者、角色、權限、角色指派和權限指派設定完成，表1為使用者角色指派，表2為角色權限指派，表3為團隊。

表 1 使用者角色指派使用者角色

user1 role1 role2 user2 role3 role4 user3 role3 role5 user4 role4

架構在 RBAC 上的團隊委任模型