角色存取控制（RBAC）為何？

簡稱為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等。