權限管理設計：ACL、RBAC

之前在這篇文章中我們談了驗證 (authentication) 與授權 (authorization) 的區別，今天針對這個主題，想進一步談權限管理。

授權與權限管理的基礎

如前一篇談到，所謂的授權是涉及你有什麼權限。在系統確認你確實是你後，系統會需要進一步判斷你有什麼權限，並基於你有的權限，開放讓你能做不同的操作。

權限管理對一個系統來說非常重要，特別是對 B2B 的產品而言。先前聽 Databricks 共同創辦人的訪談，其中談到從最開始 Databricks 就是以面向企業出發打造系統，所以一開始就花很多時間把治理 (governance) 做好，其中包含權限管理的部分。因為這塊沒做好，基本上不會有企業買單。

這時就會要面對一個常見的相關面試問題：如果要處理權限的管理，該如何設計?

最簡單的權限機制：ACL

所以假如要設計一種最簡單的權限機制，其實我們可以有一個清單，這個清單會對應到某些權限，而只要被加入到這清單中的使用者，都能夠獲得這些權限。這種做法又被稱為 ACL (Access Control List 存取控制清單)，透過加入清單 (list)，讓使用者直接獲得權限 (access)。

而在 ACL 的做法下，假如使用者 A 想要瀏覽某個頁面時，會先去檢查在瀏覽頁面的權限清單中，有沒有使用者 A，有的話才能瀏覽，沒有的話就不行。

而基於 ACL，你可能聽過一種叫 DAC (Discretionary Access Control 自主存取控制) 的做法，意思是假如今天使用者 A 有瀏覽的權限，他也可以將該權限賦予其他人，讓其他使用者也能瀏覽。

ACL 的限制與 RBAC 的出現

相信你讀到這，腦中可能會有個疑問，這種做法雖然適用不少情境，但擴展性似乎感覺不太好?

假如你有這種疑問，表示你的直覺很準確。沒錯，假如用 ACL 的方式，在使用者人數少時，用起來快速方便；然而，當使用者人數一多，只要有一個新的權限點，就要把一整批人都加到某個清單，這樣在操作上會變得麻煩很多。

ACL 不太好擴展，但有一個叫 RBAC 的模式則相對好擴展。

RBAC：基於角色的存取控制

RBAC 是 Role-based Access Control 的簡寫，用中文理解是「基於角色的存取控制」。顧名思義，這種模式的核心在於角色 (role)。

比起直接把使用者加入某個存取清單，這個模式會先創建角色，每個角色有不同的存取權，然後賦予使用者角色藉此來獲得對應的權限。許多業界著名的系統，都採用 RBAC 的模式。舉例來說，知名的資料庫 MongoDB 就是採取 RBAC 的權限模式，或是軟體專案管理工具 Jira 也採用 RBAC 的模式。

具體來說，假如今天有一個角色是工程師，該角色會有各類工程師都該有的權限，例如閱讀工程相關文件；假如今天公司決定讓所有工程師都不僅可以讀，還都能編輯工程相關文件，不需用把所有人再加到編輯工程文件的清單，而是只要賦予工程師角色編輯的權限即可，這讓新增與修改權限的操作變少許多。

RBAC 的局限性

然而，在某些場景下，RBAC 有局限性。

舉例來說，假如今天原本所有工程師都有編輯工程文件的權限，但如果公司改變政策，決定實習生工程師不能編輯，在 RBAC 模式下，就需要創建不同資深程度的工程師，然後賦予初階到高階一路到 CTO 的角色編輯權限，然後創建新的實習生角色，賦予瀏覽但不賦予編輯的權限。

可以看到，在這種狀況下，角色數量可能暴增，導致操作變很多且麻煩，這是 RBAC 相對不靈活的地方。

其他解決方案

針對 RBAC 的問題，業界有其他的模式來解決。關於權限，常見的還包含 ABAC、ReBAC 等等，有興趣深入了解的讀者，歡迎加入 E+ 看完整的主題文

E+ 的詳細介紹可以看這個連結。