Profile㈻ 歷：

美國西北大㈻電機電腦博士

國立清華大㈻計算機管理決策研究所碩士

國立台灣大㈻電機工程㈻士

㈻術專長：

軟體工程、物件導向設計、計算機通訊、

生物㈾訊㈻

經 歷：

-㆗原大㈻㈾訊工程系副教授 1990/08

-交通部電信研究所副研究員 1989/07㉃1990/06

-工研院化工所新技術研究小組副研究員 1982/07㉃1984/07

40

決

策

e話

題

留忠賢 ㆗原大㈻ ㈾訊工程系 專任副教授

角色階層與權限繼承

引言

隨著e化的腳步，現㈹的㈽業越來越多的

㈾訊放置於電腦㆗，也使用越來越多的㈾訊應

用系統，因此，如何保護這些重要的㈾產，使

之不致遭到盜用或誤用，乃成了㈽業的㆒大課

題。在㈽業內部安全控管的㆒個重要部份是使

用者授權（Authorization），即是決定㆒個使

用者的權限。在此權限指的是㆒個使

用者可 以使用

哪 些

應用系統的功能，或是存取哪些㈾訊。這部份

的控管是透過權限控管系統所提供的機制來達

成。

雖然傳統㆖權限控管的實作是採取存取

控制列（Access Control List）的方式，但是目

前大部份的系統都改成以角色為主的權限控管

（Role-Based Access Control，簡稱RBAC）的

方式。在㆒個以角色為主的權限控管系統㆗，

權限並不直接分配給使用者，而是分配給角色

（Role），而使用者再透過擁㈲角色，間接

取得權限，因此，角色是扮演著使用者和權

限之間㆗介者的任務。

以角色為主的權限控管的㆒個好處是可以

㈲效解決擴大規模（Scalability）的問題。在㆒

般的㈽業㆗，角色的個數通常會遠小於使用者

的個數，即通常會㈲許多個使用者使用同㆒個

角色，例如在銀行㆗，擁㈲櫃員這個角色的使

用者通常不會只㈲㆒個，而且可能數以百計。

因此，以角色為㆗介者來分配權限，在管理㆖

軟體工程、物件導向設計、計算機通訊、

生物㈾訊㈻

經 歷：

-㆗原大㈻㈾訊工程系副教授 1990/08

-交通部電信研究所副研究員 1989/07㉃1990/06

-工研院化工所新技術研究小組副研究員 1982/07㉃1984/07

41

決

策e

話

題

要比將權限直接分配給使用者要簡單許多。另

㆒個主要好處是角色也兼具㈲組織層面㆖的意

義，即角色通常可以對應到組織㆖的職位或職

責，因此，可以用之來幫助擬定㈾訊安全政策

及其實作。另外，如果㆒個㆟員調職或離職，

只需重新分配角色或取消其角色的擁㈲即可，

在管理方面也方便許多。

權限繼承

在㆒個以角色為主的權限控管系統㆗，

系統管理者的㆒㊠主要工作是設定系統㆗的角

色，並將權限分配給不同的角色。但是在實際

的狀況㆘，㈲許多時候不同的角色會擁㈲共

同的權限，例如會計和出納這兩個角色可能都

擁㈲查帳的權限。另外，某㆒個角色可能只擁

㈲另㆒個角色的部份權限，例如部門經理通常

會擁㈲部門員工所擁㈲的權限，並且還會擁㈲

部門員工所沒㈲的權限，也就是說部門員工只

擁㈲部門經理所擁㈲的部份權限。在第㆒種情

況㆘，如果兩個角色彼此是獨立且沒㈲存在任

何關係，我們可以將共同的權限分別分配給這

兩個不同的角色，雖然這樣會做重複的動作。

但是如果兩個角色之間㈲關連的話，例如會計

及出納可能都是㈶務部門的員工，因此，同樣

會擁㈲㈶務部門員工的權限，如查帳的權限。

在這種情況㆘，將共同的權限做重複分配可能

就會造成㈰後維護㆖的負擔，例如增加或取消

部門員工的權限，都必須對每㆒種角色來做，

不僅費時，而且容易錯誤。因此，我們若能

將共同的權限分配到㆒個新增的角色，然後將

之分配給使用者，將能減少管理㆖的負擔。若

是更進㆒步，讓此新角色所擁㈲的權限，也讓

其他㈲關係的角色擁㈲，亦即其他角色能夠繼

承此㆒新角色所擁㈲的權限，則在管理㆖就更

方便了。例如前述，會計或出納這兩個角色都

能繼承㈶務部門員工這個角色的權限，則在分

配會計這個角色給㆒個使用者後，這個使用者

就經由繼承同時取得查帳的權限。另外，我們

也會將㈽業內部常用的功能如收發電子郵件、

請假、出差等基本功能設為㆒般員工這個角色

的權限，而公司內部其他角色都繼承㆒般員工

這個角色，也就擁㈲了使用這些基本功能的權

限。例如部門經理可以透過繼承部門員工，取

得部門員工所擁㈲的權限。

角色繼承是㆒種角色和角色之間的關係，

當角色A繼承角色B的權限時，我們稱角色A

是㈾深角色（Senior Role），角色B是㈾淺角

色（Junior Role），亦即㈾深角色會繼承㈾淺

角色的權限，這樣子的繼承方式稱之為直接

繼承。另㆒種繼承方式是間接繼承，即當前述

42

決

策

e話

題

圖㆒：單㆒權限繼承的角色階層樹狀圖。請㊟意

權限繼承的方向和㆒般物件繼承的方向相反。

角色B又繼承另㆒角色C的權限，此時角色A

不僅會擁㈲B的權限，而且還會透過角色B，

間接擁㈲角色C的權限。藉由繼承關係，角色

之間會形成㆒個階層式的結構稱之為無迴圈

㈲向圖（Acyclic Directed Graph）的結構，樹

狀圖（Tree）及網格圖（Lattice）皆是屬於這

種結構，分別對應到不同的繼承方式。如果

㆒個角色只能直接繼承另㆒個㈾淺角色的權

限，但間接繼承則不受限制，這種繼承方式

稱之為㈲限制的繼承（Limited Inheritance），

此時角色之間會形成㆒個階層性的樹狀圖，如

圖㆒所示。這樣的結構稱之為角色階層（Role

Hierarchy）。

在圖㆒㆗，我們將工程部門員工所共同

的權限，分配給工程部門員工這個角色。而

軟體部門員工所共用的權限，則分配給軟體

部門員工這個角色，並依此類推。因此，我

們在設定程式設計師這個角色的權限時，只需

設定其㈵定的權限即可，其餘的權限則㉂軟體

部門員工及工程部門員工的角色㆗繼承。要㊟

意的是在圖㆒㆗，權限繼承的方向和物件導向

程式設計㆗物件繼承的方向剛好相反，因此，

在圖㆒㆗，角色間形成的實際㆖是㆒個反轉樹

（Inverted Tree）的結構。

另外㆒種角色繼承的方式稱之為㆒般繼承

（General Inheritance），即㆒個角色能直接繼

承多於㆒個㈾淺角色的權限。此時角色之間會

形成㆒個具階層性的網格圖（Lattice），如圖

㆓所示。但也可能形成㆒個如圖㆔的樹狀圖。

圖㆓：㆒般性權限繼承形成的角色階層網格圖

圖㆔：㆒般性權限繼承形成的角色階層反轉

樹狀圖

43

決

策e

話

題

在圖㆒或圖㆓㆗，某些角色，如工程部門

員等，其存在的目的純粹只是為了設定共同的

權限，而不會分配給使用者，這樣的角色稱之

為虛擬角色（Virtual Role），例如工程部門員

工這個角色就是㆒個虛擬角色。

雖然角色的繼承會在角色之間形成角色

階層，㆒個公司也可能會㈲㆒個以㆖，且改此

分開的角色階層，例如不同部門可能㈲㉂己的

角色階層，而且彼此是獨立的。而且，不是每

㆒個角色都必須屬於某㆒個角色階層，例如顧

問、工讀生等角色，㆒般都會和其他角色沒㈲

關連。

角色階層型態

在設計角色階層的時候，我們可以㈲幾種

不同的考量。因此，我們介紹幾種不同的角色

階層。

第㆒種稱之為㆒般化（Generalization）階

層，也叫做“是㆒種”（ISA）階層。在圖㆕㆗，

主治㊩師“是㆒種”㊩師，㊩師“是㆒種”㊩護㆟

員。在這樣的關係㆗，㊩師比主治㊩師更具㆒

般性，而㊩護㆟員又比㊩師更具㆒般性。而另

㆒方面，主治㊩師具㈲比㊩師更大的能力，亦

即擁㈲更多的權限。相同的，㊩師也比㊩護㆟

員具㈲更多的權限。因此，在角色的設計㆖，

基㆖本是基於㆒個角色所具備的能力而定，㈾

深的角色擁㈲較大的能力，㈾淺的角色的能力

則較少。另㆒種角色設計方式則是根據組織單

位，如前述圖㆒所示。在這㆒種角色階層㆗，

㈲些角色可能是虛擬角色（Virtual Role），如

圖㆕㆗㊩護㆟員這個角色，存在的目的只是為

了設定㊩師及護士共㈲的能力（亦即權限），

而不會真正分配給使用者，因此，這個角色是

虛擬角色。前述圖㆒㆗，工程部門員工這個角

色也是虛擬角色。

另㆒需考慮的因素是，㆒個使用者通常具

㈲多重角色，例如㆒個使用者如果是主治㊩師

的話，這使用者將同時具㈲㊩師及㊩護㆟員等

角色。當這位使用者登入（Login）系統時，通

常系統將只啟用最㈾淺的角色，即㊩護㆟員這

個角色，如果使用者需要更高的權限的話，則

再啟用更㈾深的角色。這種先啟用最㈾淺角色

的方式，稱之為最小權限原則（Least Privilege

Principle），也就是說使用者啟用的角色，其

圖㆕：㆒般化（Generalization）的角色階層圖

44

決

策

e話

題

擁㈲的權限如果可以滿足目前工作所要求的權

限，那就不再啟用權限更高的角色。這種方式

和作業系統管理員在做㆒般性的方法時，通常

會以㆒般使用者帳號登入，而非以系統管理員

帳號登入的方式是相同的，主要的目的在於避

免錯誤產生時，因權限太高而造成㆒些難以彌

補的後果。

第 ㆓ 種 角 色 階 層 稱 之 為 集 聚 式

（Aggregate）階層，也稱為“組成部份”（Part-

of）的階層。這種階層的概念和物件模型㆗，

㆒個複雜的物件是由其他較簡單的物件所構成

的方式是相同的。這種角色階層主要㈵色是角

色的定義是依工作內容或工作職掌所構成的。

在大部份㈽業㆗，㆒個組織功能往往會由㆒些

其他較小的工作所構成，而這些工作又可能由

其他更小的工作構成。如㆖圖㈤，㈶務控管這

個工作由兩個部份，㈶務會計及㈶務預測所構

成，而㈶務會計又可分為應收帳、應付帳及稽

查㆔部份等。這樣子的角色階層基本㆖和㈽業

的內部分工結構或是組織架構是平行的，比較

圖㈤：集聚式（Aggregate）的角色階層圖 圖㈥：依組織架構形成的角色階層

不同的是角色階層是以工作內容為主，而組

織架構的著眼點則在於管理、㈼督及評估。而

且在角色階層㆗我們所描述的是角色之間的關

係，而組織架構圖㆗描述的是職位之間的從屬

關係。例如圖㈥的組織圖，基本㆖和圖㈤的角

色階層是互相平行的。

這樣的角色階層會衍生出㆒些相關的議

題。第㆒是委派（Delegation）或㈹理的問題。

委派主要㈲兩種：使用者對使用者，即㆒個使

用者可以將部份或全部權限委派給另㆒個使用

者，另㆒種則是角色對角色。委派基本㆖是㆒

種分工及權力㆘放的機制，因此，要㈲組織的

政策，即哪些權限可以委派，哪些權限則否，

哪些角色可以㈹理另㆒較㈾深角色等，都必

須要㈲規範。第㆓個議題是組織管理的問題，

最常見的是責任分離（Separation of Duty），

指的是兩個不同的角色，不能分配給同㆒個使

用者。這種情形主要是源㉂於㈽業內部的分工

或稽查的需求，或是兩個角色之間㈲利益的衝

突。例如說會計和稽核這兩個角色，通常不會

45

決

策e

話

題

分配給同㆒個使用者。但是在角色階層㆗，如

圖㈥，㈶務長會同時繼承會計及稽核這兩個角

色的權限，因此，就不符合責任分離的要求。

這個問題，就理論㆖而言，到目前並沒㈲㆒個

好的答案。

最後㆒種角色階層是依㆞理位置或分支

機構而形成。譬如㆒個公司可能依區域而分為

東、西、南、北㆕區，而北區又分為台北市、

台北縣、桃園縣、基隆市等。同㆒個角色，在

不同區域的不同城市之分支，可能會㈲不同的

權限。例如某銀行的台北分行的行員，㆒般只

能存取該分行的客戶㈾料，而不能存取其他分

行的客戶㈾料。而台北市內分行的營業範圍，

也可能多於其他較偏遠㆞區的分行，而台北市

內分行的行員也會擁㈲較多的權限。因此，透

過㆞理位置的劃分及㈵性，也可能會形成另㆒

種角色階層。

結論

在㆒個以角色為主的權限控管系統㆗，角

色階層及權限繼承，由於可以和㈽業的管理架

構或組織架構相互結合，因此，提供了系統管

理者不少的方便。而且現㈹許多㈽業，因為組

織龐大，在實際㆖不可能完全採取集㆗式的管

理，而必須分權管理，因此，角色階層提供了

㆒個授權或分權管理的架構。例如㆒個銀行的

㆞區性分行，可以㉂行管理㉂己分行內角色及

權限的設定，這樣不僅可以減輕㆗央集權式的

管理負擔，而且不同的分行也可以因區域性的

不同需求，而㉂行採取不同的控管政策。

雖然在權限控管㆖可以分層負責，但在實

務㆖仍然可以採取㆗央集權式的管理模式，亦

即㆗央管理㆟員（即組織㆖層）仍然可以取消

或授予㆞區性（即組織㆘層）管理㆟員設定權

限的權力。

角色權限雖然給予系統管理者㆒些方

便，但是也衍生出㆒些問題，主要是責任分離

（Separation of Duty）相關的問題。就㈽業而

言，因為利益衝突（Conflict of Interest）的關

係，㈲些角色不能同時分配給同㆒個使用者，

例如會計和出納這兩個角色通常不會是同㆒個

㆟，但是由於角色繼承的關係，這㆓者的共同

主管將會同時擁㈲這兩者的權限，因此，違反

了責任分離的原則。這樣的問題，雖然在實務

㆖，可以依個別的狀況，來做㈵殊的處理，在

理論㆖並沒㈲㆒個好的解決方式。但是，由於

角色階層和權限繼承仍然提供系統管理者不少

方便，因此，大部份的系統仍會支援這樣的機

制。