[F10_WebComp] 期末專題報告- Role-Based Access Control (RBAC)

一、Introduction

RBAC最主要的動機可提供企業執行安全上的政策以及簡化繁瑣的管理程序,除此之外,RBAC提供較為彈性和可詳細的設定控制細目的優點。

在過去,組織內系統管理使用者,這些使用者都有權限控制的設定,這些設定必須花上較多的成本才能夠妥善管理,隨著RBAC的發展,若導入RBAC,可將這種對「人」控管改以為「角色」來管理,在組織或機構應用,不但能降低管理成本,而且藉由RBAC可以受到更為安全的保護政策。同時,RBAC可執行多種規範的保護政策,較適合須對組織內訂作安全管理的對象。

RBAC是以角色為基礎設計,因此管理使用者時,只須將使用者加入到角色當中,這位使用者就擁有這個角色所擁有的權限,但要踢除這名使用者所能行使的權限時,只須對該名使用者踢除該角色群當中,因此,在作權限設定時,只須對角色去作設定即可。

下圖說明RBAC基本的概念,雙箭頭代表多對關係,因此使用者與角色間的關係為多對多,而角色與操作(Operations)也為多對多,在此操作(Operations)意指角色能夠允許權限所作的事。

 

二、User, roles, and operation

在圖一當中,大致了描述RBAC基本的運作,但在此要在作清楚的定義:

  • User: a person.
  • Role:a collection of  job function.
  • Operations:a particular mode of access to set of one or more protected RBAC objects.
  • Subject:an active user process

上圖說明User與Subject的關係,在前面定義也提到subject是使用者受active的過程,但每一個操作(Operations),都必須先經過受過active的使用者才能夠進行,因此在圖二User與Subject的關係為一對多,即代表使用者在同一時間受到多次以上的active過程。

上圖則是繼續延伸上上圖,說明操作(Operations)的對象即是Object,且兩者的關係為多對多,但真正要執行操作前,必須確認是否受到圖二的關係圖,操作者是否真正經過Subject的過程。

下面即舉一個情景例子:

  • 環境假設:
    • 角色:出納員、會計主管
    • 地點:銀行

上圖說明一個清楚的例子內容,在Users有A、B、C…等人,A及B或者更多人為出納員的角色,只有C一名為會計主管的角色,所以在出納員的角色,只要有新成員加入,要行使出納員的職務,只要加進出納員角色就能夠行使,操作(Operations)提 / 存款及審核的動作都是針對同一份檔案作讀寫的動作,但這兩項操作而言,對於出納員及會計主管是必須要分明清楚,自己的角色只能夠作自己權限以內的事。

三、Roles and role hierarchies

在這個部份介紹角色的階層式架構,在此他的定義為roles that have unique attributes and that may “contain” other roles, that is, that one role may implicitly include the operations , constrains, and objects that are associated with another role.

上圖說明一個Role hierarchy的例子,意即Cardiologist及Rheumatologist隱含可以作Specialist、Doctor及Intern所能行使的權限,但Cardiologist及Rheumatologist本科內的職權卻不互相干擾,依據圖中的階層架構,Specialist及Doctor也隱含底下角色所能行使的職務。

因此角色的階層式架構也推導出了一些性質,最頂端的角色有較高控制力的權限,但越往下層,控制力的權限也會隨之變小。

四、Roles authorization

角色擁有權限去對Object操作,這個權限也不是無中生有,是必須透過授權這個機制,將這些權限授權給角色之上才能夠去行使。在這邊也提出幾點要點:

  • 最小職權的劃分
  • 使用者在Roles不能有互斥的行為
  • Role成員有一定的上限

在這邊就舉一個例子:Nicholas Leeson[3]於英格蘭一家投資銀行工作,他主要負責投資以及風險管理的職務,他在新加坡以及日本的股市市場皆有投資證券,但在神戶大地震中,把亞洲股市打亂了,導致Nicholas Leeson投資糟殃,他為了回復這些損失,作了一系列更高風險的投資,但卻沒有任何人去阻止他這種危險的舉動,因為他也負責風險管理,最後拖垮這家投資銀行,最終導致破產收場。

上述的例子就清楚說明了他這種職務上的分配,有極大的矛盾之處,這種角色上的分配就很明險有互斥上的行為,而且也沒有作到最小職權劃分,這種作法可能會導致一人權力獨大的情況,對組織及機構是非常不利,因為恐會牽涉到利益衝突的問題。

前面提到權限是授權給角色行使,但角色當中可以加入User,因此Role一定會有成員的上限,假設一個組織有總裁、經理、員工三角色,員工人數可能很多,但也應有一定的範圍,經理、總裁更明顯,萬一人數超過一定的限制,也可能會造成行使的互相牽制。

五、Roles activation

前面介紹了使用者、角色、權限對於操作(Operations)間的關係,在這邊是要更詳細說明對active的內容,雖然已有的權限去操作的機制,但角色中使用者可能眾多,所以在RBAC當中定義了activation的機制,在已有控制的權限底下,還未能真正去存取,必須針對角色裡的特定使用者去作active,如下圖所示,在active前必須先授權角色權限,在active過程當中必須先建立session,建立完才針對使用者active的動作,同時可針對於此作限制內容,而在此session具時效性,當這個session不存在時,也就代表activation失效,不能繼續存取,若要再次存取,一樣還要經過activation的程序。

六、conclusion

企業或組織藉由導入RBAC的概念,可以降低管理上的成本以及簡化繁瑣的程序,而且提供極好的彈性,也可針對組織內部作特別設計的安全政策的管理,但要使用RBAC前,也必須遵守著RBAC的前提,將內部職權的劃分、角色行使職務不互斥等等,這樣才能有效保護內部的資源,達到更高的安全政策,也更降低利益衝突、監守自盜、權限一人獨大等問題。

七、Referances

[1] David F. Ferraiolo, Janet A. Cugini, D. Richard Kuhn, "Role-Based Access Control (RBAC): Features and Motivations", Proceedings of 11th Annual Computer Security Application Conference, IEEE Computer Society Press, pages 241-248, December 1995.
[2] Role-based access control, wikipedia, http://en.wikipedia.org/wiki/Role-based_access_control
[3] Nick Leeson, wikipedia
    http://zh.wikipedia.org/zh/%E5%B0%BC%E5%85%8B%C2%B7%E6%9D%8E%E6%A3%AE