第三章 相關研究
3.3 單一登入使用RBAC之研究
2、 責任區分(Separation of Duties)：
這是屬於多人控制安全策略，對於有互斥性質的職務可以分配給不同的角色，並且限 制使用者取得相互斥的角色，以避免發生有舞弊的情況發生，例如出納與會計的職務 不能由同一個員工來擔任。
3、 資料抽象(Data Abstraction)：
傳統的存取控制限定於實際的操作動作，如讀取、寫入等。RBAC可以利用語意的方式
圖 3.7 User-Pull 架構合作圖
資料來源：Joon S.Park et al.(2001)[12]
在User-Pull架構中，使用者透過瀏覽器(Browser)向Role Server取得授予的角色，並 儲存在使用者的主機中，接著將此角色與認證憑證一併提交給Web Server，待Web Server 確認認證憑證無誤後，便可讓使用者透過瀏覽器(Browser)，來取得該角色所擁有的權限。
圖 3.8 Server-Pull 架構合作圖
資料來源：Joon S.Park et al.(2001)[12]
在Server-Pull架構中，使用者透過瀏覽器(Browser)將認證憑證提交給Web Server，
待Web Server確認認證憑證無誤後，Web Server即向Role Server請求取得授予使用者的角 色，接著使用者透過瀏覽器(Browser)請求服務時，Web Server便依照該使用者的角色，來
提供應有的權限。
User-Pull與Server-Pull架構最大的不同點在於，User-Pull架構是將Role Server所
授予的角色儲存在使用者主機中，而Server-Pull架構是儲存在Web Server中；由於User-Pull架構 Server-Pull架構 使用者便利性(User's convenience) 低 高 網頁伺服器效能(Performance) 高 低 可重複使用性(Reusability) 高 低 角色新穎度(Role freshness) 低 高 單點故障(Single-point failure) 低 高
資料來源：Joon S.Park et al.(2001) [12]
隨著網路的發達，使用網路服務的人數大量增加，讓採用RBAC來管理使用者權限的網 路系統無法有效的減輕管理上的負擔，因此，在2005年Q. Li等人[13]提出一個以群組 (Groups)為概念，分散式的角色為基礎存取控制(Decentralized RBAC,DRBAC)模型，以解 決大量使用者對於傳統 RBAC 的衝擊。
分散式的角色為基礎存取控制(DRBAC)模型是由使用者(Users)、群組(Groups)、角色
(Roles)、權限(Permissions)和會期(Sessions)等五個元件組成，其模型如下圖3.8。圖 3.9 DRBAC 模型圖
資料來源：Q. Li et al.(2005)[13]
由於傳統的RBAC是利用使用者對應角色，角色對應權限的方式來運作，一旦面臨大量 的使用者與角色之間關係的轉換配置時，就會大大降低處理效率。因此透過群組(Groups) 將具有相同屬性的使用者集合起來，並賦予群組(Groups)適當的角色，可以免去繁瑣的使 用者角色配置。
在國中、小行政體制中，常用團隊或社群來執行上級所交辦之任務，並利用群組的概 念將參與此團隊或社群的教師設定成群組角色，但是事實上，群組角色是讓每位教師所擁 有的權限都一樣，這樣的做法卻與實際運作情況不盡然相符。因為在同一團隊或社群的教 師，可能會透過分工合作的方式來執行任務，所以把這些教師設為同一個群組角色並不恰 當，因為每位老師都會有自己負責的任務。因此在2007年Wei Zhou等人[14]便提出了一個 以團隊與任務為基礎的角色存取控制(Team and Task Based RBAC Access Control，簡稱 TT-RBAC) 架構來實行權限控制與認證管理，TT-RBAC增加了團隊和任務(Team and Task) 兩元件，並整合NIST RBAC所提出的架構，因此TT-RBAC也承襲了RBAC角色階層的概念，透 過角色階層(Role Hierarchy)的概念，使高層的角色可以繼承低層角色的權限，例如：教 務主任擁有教學組長及訓導組長的權限。
在TT-RBAC架構中，使用者(Users)被分配到某些角色(Roles)或某些團隊(Teams)；而
角色(Roles)或任務(Tasks)被分配給某些團隊(Teams)，接著權限(Permissions)再被分配 給角色(Roles)或任務(Tasks)，因此使用者可執行的權限是由他被賦予的角色或隸屬的團 隊所決定，而此團隊被指派的任務，將決定參加此團隊的使用者所能執行的權限。例如：
某位教師擔任六年級導師的角色，又因其專長而參加數學領域這個團隊，接著教務處將數 學競賽這個任務指派給數學領域團隊來負責，而此團隊成員便各司其職，以完成此任務。
以TT-RBAC為核心加上階層概念的架構圖，如圖3.9所示。
圖 3.10 階層的 TT-RBAC
資料來源：Wei Zhou et al.(2007)[14]
最後我們針對傳統RBAC、DRBAC與TT-RBAC的運作原理與缺點分析彙整如下表3.3：
表 3.3 傳統 RBAC、DRBAC 與 TT-RBAC 的運作原理與缺點分析表
傳統RBAC
原理： 利用角色來控管權限，再授予使用者應有的角色身分；而當使 用者更換職務時，只需要改變它原有的角色即可，不用逐一修 改使用者權限。
缺點： 若面臨大量的使用者與角色之間關係的轉換配置時，就會降低 處理效率。
DRBAC
原理：將具有相同屬性的使用者集合起來，並賦予群組(Groups)適當的 角色，免去繁瑣的使用者角色配置。
缺點：在合作式的環境中，群組的角色並無法有效的定義，每個角色所 被賦予的權限。
TT-RBAC
原理：使用者可執行的權限是由他被賦予的角色或隸屬的團隊所決定，
而此團隊被指派的任務，將決定參加此團隊的使用者所能執行的 權限。
缺點：並非任何情況下，團隊成員都需要利用合作的方式來完成任務。
為了能讓本系統存取控制與授權機制更加富有彈性，我們將整合DRBAC與TT-RBAC的優 點，讓相同屬性的使用者具有群組角色(Group role)的權限，而且在需要合作式的環境中，
也能利用團隊(Team)分工的方式來達成任務(Task)，詳細的設計將在第四章中加以說明。