DOCS

角色存取控制(RBAC)為何?

最後更新於: April 23, 2024

角色存取控制為何?

簡稱為RBAC,Role-based Access Control,中文譯為角色存取控制,是一種以角色來判斷該用戶是否具有不同系統與資料的訪問權限的存取控制模型。

最初在1992年由David Ferraiolo與Richard Kuhn提出,RBAC已經逐漸地成為了現代應用程式與網路系統中,管理存取控制的主要模型。

而成為主流的邏輯也很容易理解,因為相對於單純以個體角色來做權限管理、抑或是以層級來做權限管理,以角色的方式去分配也能更加貼近我們在真實生活的運作。

從實務層面來看,在整個組織落實系統管理時,就可以根據部門與層級,去落實其角色控制。譬如在軟體工程部門的角色就有權限去使用雲端運算平台、訪問軟體相關學習資源、抑或是使用其他相關工具等;而對於在行銷部門的角色來說,則有權限使用客戶體驗平台、訪問客戶數據、以及使用相關工具。

然而傳統的RBAC有一個壞處就是,當新角色建立時,我們必須要從頭到尾的去跑過所有的資源,並開啟相應的權限給該角色;抑或是,需要指派已經擁有相應能力的角色給這一新角色,但時常會導致其擁有不必要的權限(權限過大)。

譬如現在組織想要在財務分析師這一角色的基礎之上,開啟一個風險分析師的角色,其建立在財務分析師已有的權限之上,新增訪問專案數據的權限。那麼這時候,團隊就必須要從頭到尾的把相應的資料開啟權限給這一新角色。

所以絕大多數的企業相對於安排新角色,他們都會直接安排多個角色給這一位風險分析師(譬如財務分析師角色、專案運營角色),讓其能夠訪問相應的資源。然而這往往也會導致該風險分析師擁有許多額外、不必要的權限,造成潛在的安全漏洞。

所以越來越常看到的是,RBAC結合能力存取控制(CBAC, Capability-based Access Control),也就是在管理資料系統時,並非定義「X角色有權限訪問該資料」,而是定義「具備X能力的角色有權限訪問該資料」。 而在定義角色時,我們也會定義出其相應的能力有哪些。

在現在許多系統都逐漸地調整為結合RVAC與CBAC的模式,譬如Google Cloud Platoform、WordPress Core、以及SAP等。

About Us
協助製造業者拓展東南亞市場

OOSGA是一家專注於為工業客戶提供東南亞供應鏈拓展、設廠評估,以及市場情資的顧問公司。我們致力於為客戶企業提供最可靠的市場情報和洞見,並與當地工業不動產開發商,以及相關合作夥伴一同推進當地業務的落地。

倘若您對於進入新市場、抑或是對拓展業務有想法,歡迎隨時聯繫我們團隊討論。

參考資料
作者:專案小組

我們的專案小組結合了內部團隊、外部專家、合作夥伴,並協助客戶探勘市場機會、落實市場進入與成長。

聯繫作者
您的來信內容將會寄送至負責該篇文章/調查/研究之作者或團隊