权限管理设计：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+ 的详细介绍可以看这个连结。