哪一个权限控制模型呢？(DAC|MAC|RBAC|RuBAC|ABAC)
前言
最近想给自己的小程序的GPT调用接口增加一个权限控制，比如可以是这类策略：普通用户智能免费调用10次该接口，然后用户可以购买VIP会员，然后就可以无限次调用该接口。
社区中听得最多的权限控制模型就是RBAC，比如Nest的官方文档中介绍权限控制的章节就是以该模型为例。
但是我就一定要选择这种方案吗？这种方案对于我现在的实际业务情况是最佳选择吗？所以，下面我们来详细聊聊常见的几种权限模型，再来根据实际情况谈谈设计方案。
自主访问控制（DAC）
基本介绍
自主访问控制模型（Discretionary Access Control，DAC）是一种基于主体（如用户、进程）和客体（如文件、目录、资产）之间关系来控制访问的权限控制模型。在DAC中，主体可以自主控制访问对象的权限，即主体拥有对对象的完全控制权，可以自由授权和收回对对象的访问权限。
重点就在于一个自主，即主体拥有对对象的完全控制权
DAC模型的优点是简单易于实现，适用于权限控制较为简单的场景，资源的权限可以非常灵活的进行传播。
说是灵活，但也可以说是随意。它也有缺点，例如权限分散，难以管理；安全性较低，容易受到攻击等。
例子
举几个生活中的例子来帮助大家理解：
- 社交媒体：在社交媒体平台中，用户可以设置自己的个人资料和隐私权限，例如是否公开自己的名字、头像和个人信息等。再详细一点，比如朋友圈，朋友圈就是每个用户自己拥有的资源，而是否公开，向哪些人公开，公开哪几条朋友圈都是由用户自己说了算。
- 手机热点：手机热点也是用户自己拥有的资源，用户可以随意更改哪些用户可以访问我的热点，最多几人访问我的人热点等等。
- 移动设备：在移动设备中，整个移动设备属于用户自己拥有的资源。用户可以设置各种应用程序的权限，例如访问设备存储、网络、电话、短信等权限。用户可以根据需要给予或收回应用程序的权限。
上面举的几个例子都是DAC比较适用的例子，因为上层管理员不会有统一或者分组管理相应资源的场景。但是比如出现该场景：比如重庆市所有人三个月前发的朋友圈不能共享，如果真要来实现这个功能，可能并不太好操作，这也是DAC权限过于分散的缺点体现。
来，我们一起来类比理解一下（当然，没有下面的相关经验也可以直接跳过）：
- 其实就有点区块链去中心化的那种感觉，所以这也是为什么对于这方面监管这么严格的原因，太乱了，不好管理。
- 也好比JWT将登录控制分发出去，凭证由用户自己控制，那强制下线就很难做，只能额外增加一层黑名单控制逻辑。
强制访问控制（MAC）
基本介绍
还是其实从名字上就能理解，DAC是自主，MAC是强制。
这种强制就体现在：在MAC模型里，授权不是由每个用户来掌控的。相反，授权的决定是由系统管理员来定制的。这样，管理员可以更好地控制用户的访问权限。同时，也有效地避免了用户通过其他手段来绕过访问控制系统的限制，确保了系统的强制性。
例子
我们再来举几个生活的例子帮助大家理解
- 护照：如果您想要访问某些国家，您需要先获得批准并获得护照。利用这种方式，国家可以通过MAC模型，为不同的人员授予不同的访问权限。
- 校园卡：学校使用MAC模型，针对不同的学生身份，赋予其进入对应寝室楼的权利，不是该寝室楼的（没有该权限的）不能进入该寝室。
这样系统管理员就需要记录每位用户拥有哪些权限，太细了，上面的例子同样也是比较适合MAC模型的例子，因为只有一种权限，就是是否能进出；
但是在其他场景中，比如员工系统中，用户升职了，就得专门为这个用户增加几条对应职位的权限，不同的用户可能对应有几十上百条权限需要管理，我们的安全管理员又要跑路了。
基于角色的访问控制（RBAC）
基本介绍
上面两个模型似乎都太过于极端，一个极端的自由，一个极端的约束。所以，程序员经典的一句话就是“遇事不决，再加一层”。增加一层适配解耦呗，RBAC的关键就是在MAC的基础上，主体与资源操作权限中增加了一层角色进行权限控制。
这样系统管理员，或者说是安全员要管理的逻辑就轻松多了。不同对每位用户细分到每一条具体的权限，只需要分配一个角色（权限组）就可以了。
RBAC是如今非常流行的一种权限控制模型，因此也分为了0-3四种。
RBAC0
这也是RBAC最基础的模型，好处就是角色附带多个权限，绑定角色身份给某个用户，就相当于批量调整了一堆权限给该用户，即可以批量调整了。
RBAC1
RBAC1的主要思想也非常简单，就是基于RBAC0增加了角色继承的概念。还是那句话“遇事不决，再加一层”，一层角色不够，那就多加几层角色。就好比军队中的班排连旅这样。
当然，具体加几层根据自己系统的复杂度而定。
RBAC2
RBAC2的主要思想也比较简单，就是基于RBAC0增加了角色约束控制的条件，比如用户不能同时为上海的员工角色以及重庆的员工角色之类的。
主要包括了以下约束条件：
- 互斥约束：绑定了该角色，就不能与该角色互斥的其他角色进行绑定；
- 基数约束：
- 角色被分配的用户数量
- 用户可绑定的角色数量
- 角色对应的权限数量
- 先决条件角色：即用户想获得某上级角色,必须先获得其下一级的角色
RBAC3
RBAC3 = RBAC1 + RBAC2，就是同时拥有角色继承以及角色约束的功能，没啥说的，反正就是根据自己的业务复杂情况自行扩展。主要思想还是主要用了解耦"角色"。
小结
- RBAC0：增加了角色的解耦层
- RBAC1：角色内再解耦，角色继承
- RBAC2：角色分配增加约束条件，不能随意分配
- RBAC3：结合RBAC1与RBAC2灵活使用
基于规则的访问控制（RuBAC）
基本介绍
Ru代表Rule，与RBAC中的R代表Role做区分
安全管理员设置高级规则来确定员工如何、在何处以及何时可以访问空间或资源。管理员为每个空间或资源设置一个控制列表。当员工试图获得访问权限时，访问控制系统会检查要求列表并授予或拒绝访问权限。
基于规则的模型经常与其他模型结合使用，尤其是基于角色的模型。这种混合方法使管理员能够设置精细的规则，提供额外的安全级别以满足特定类型的风险。访问权限与特定角色无关，它可用于覆盖员工拥有的其他权限。
例子
- 具有基于角色的权限访问保存人事记录的房间的 HR 专业人员可能无法访问该区域，如果该区域包含在周末拒绝所有员工访问的规则。
- 该资源维护期间拒绝任何访问。
- 安全系统检测到多次失败的授权尝试，拒绝用户访问。
基于属性的访问控制（ABAC）
基本介绍
你可以将其简单理解为更加细粒度的RBAC模型，ABAC模型通常是基于用户的属性（如身份、地点、时间等）和资源属性（如文件类型、敏感度等）进行判断的。你甚至可以把角色理解为该用户的一个属性，这些模型之间本身就不是互斥的，最终还是为了方便管理权限而来，所以灵活使用即可。
值得注意的是，ABAC模型一般是基于已有的一些属性来进行的权限划分，而RBAC模型则是在人为重新设置了几个角色来管理权限。
例子
- 学校通知：在学校，通知的发布需要基于课程、年级或批次，让只有那些有资格看到通知的学生可以看到。
- 小区管理：物业管理人员可能需要基于住户身份、房屋所有权、访问时间等来管理小区门禁。
- 男女厕所：男生进男厕所，女生进女厕所。
我的场景
我的场景比较简单，并不涉及到类似于组织架构这类庞大的系统。总的来说基本需求如下，当然并不是最后的设计，只是简单举个例子：
- 需求1：VIP用户拥有几种权限（如无限次访问该接口、无广告、可免费使用付费问卷等等）
- 需求2：该接口访问频率过快限制其一天的访问权限（只限制接口访问权限）
显然，使用RBAC0结合RuBAC这类混合模型是最佳选择，RBAC0提供VIP角色和普通用户角色的权限区分，而RuBAC提供一些精细化的规则控制。
如上是一个简单的RBAC0的实现，非常简单，就是一个用户<-->角色<-->权限的多对多关系。当然RuBAC由于只有一条规则就没有单独针对接口资源与该规则建表了（真懒🤣）
最后
本文主要讲述了几种常见的权限控制模型
- DAC：自主，用户自己控制自己拥有的权限资源
- MAC：强制，管理员统一控制用户拥有的权限
- RBAC：解耦角色，用户<-->角色<-->权限，多对多关系，便于批量管理
- RuBAC：对资源增加特定规则的控制
- ABAC：根据实体已有的属性进行划分权限
总之，就像标题说的该加哪一个模型这种说法就是错误的，大多数场景都不是固定化的，要灵活解耦、灵活使用。
本文更多是基于别人的理解而理解，实际操作经验较少，如有理解不到位或者错误的地方，欢迎在评论区中友善讨论。
