25 | 授权（下）：系统如何确保授权的结果可控？

用过k8s中的rbac，如果有应用想访问k8s中的资源，需要有一个account，还要有一个role，role里面包含了对哪些数据能够操作的权限。 Account和role没有耦合关系，是相对独立的。他们通过rolebinding进行结合，达到绑定的目的。 如果应用想更换权限，可以操作对应的role也可以改account 。 这样不能在创建一个新role的时候进行继承，这个account可能会对应多个role。个人感觉有一些鸡肋的地方就是对数据的操作力度的定义，如果太细吧，可能会创建很多，如果再粗一点，可能某个role多一个权限或者少一个权限没法补。

我们做的大部分信息系统都是使用RBAC的权限控制，一般有：用户、角色、菜单。用户隶属于角色、角色会赋予能看到的菜单。这大概是最简单最常用的RBAC实现了吧。

角色是为了解耦用户和权限之间的多对多关系，比如有100个用户他们的权限都是一样的，如果每个用户都设一遍权限这就太麻烦了，而且还很容易出错。这时候设置一个角色，把对应的权限配置到角色上，然后这100个用户加到这个角色中就行了。 角色还有一个好处，如果角色的权限变了，所有角色中用户的权限也会同时变更，不用一个个用户去设置了。 许可是为了解耦操作与资源之间的多对多关系，比如有新增用户，编辑用户，删除用户的三种操作，通常都是一起的，要么都能操作，要么都不能操作，这时候就可以把这三种操作打包成一个用户维护许可，用许可和角色关联更简洁。 关于Spring Security中的Role和Authority我是这么理解的： Role就是普通的角色，拥有一组许可，这个角色下的所有用户的权限都是一样的。 但是如果一个角色中的一些用户，有个性化的需求，比如销售助理角色，本来没有查看客户的权限，但是某个销售助理比较特殊，需要查看客户的信息。 这时如果是单角色的系统（我现在设计的系统就是这样子，说多了都是泪），就需要新增一个“销售助理可查看客户角色”，这样很容易导致角色数量爆炸。 有了Authority，就可以满足这种个性化需求，只要把查看客户的权限加到Authority中赋予用户就行了。

关于数据权限的抽象，是不是有一种常用的方案可以抽象为以下几种情况： 1. 仅允许修改自己的数据 2. 允许修改自己及同部门的数据 3. 允许修改自己及同部门及下级部门的数据 4. 允许修改全部数据 5. 自定义，默认自己的数据可以修改，勾选其他可修改的部门。 然后上述五种情况，可以与角色挂钩，也可以与用户直接挂钩。

功能权限主要是用Spring。 数据权限确实很多时候只能系统自己处理，很难跨行业通用，甚至同一行业不同机构也不尽相同。比如两个看似比较通用的场景： 1、当机构架构分为多级时，上级机构能看到下级哪些数据，平级之间能看到那些数据，下级机构能看到什么数据，各行业各类组织互不相同。如果只用功能权限的思路去解决这个问题，容易将功能权限弄得十分复杂。 2、此外就是用户情况比较复杂，比如除了组织架构、岗位、职级外，还有职业证书相关权限控制、客户业务办理关系、项目组组成、项目组轮班，加上审核、稽核、多级质控等功能，仅是功能权限也是力有不逮。 而且，近些年来，各公司对数据权限和数据安全的要求都越来越高、越来越严格了。

一般使用casbin，它提供了各种语言的库。除了RBAC还支持其他各种访问控制模型。

关于那个数据权限的问题，很久以前我就观察到windows的系统权限应该就是典型的RBAC模型，但是windows能把某个文件的某些权限直接授予给特定用户，并禁止其它用户使用这些权限的功能。但是挺震撼的，因为我想了很久，没想出来如何比较方便的实现这个功能

“角色为的是解耦用户与权限之间的多对多关系，而许可为的是解耦操作与资源之间的多对多关系。”，我觉得这个描述不太准确，有为解耦而解耦的感觉。用户与权限之间是多对多，用户与角色之间同样是多对多，可以说解耦用户与权限，但不能说解耦“多对多关系”。实际上，铁打的营盘流水的兵，基于角色来描述组织结构是顺理成章，角色并不是为了解耦用户和权限而生造出来的概念；基于角色管理权限，提升了管理的粒度，因此降低了管理的复杂度，提高了管理的效率。我觉得这才是角色存在的理由。另一方面，许可本质上是一种资格，比如员工可以在餐厅吃饭，也可以不吃，总经理可以在餐厅举办宴会，也可以不举办。如果我们把餐厅当成一种资源，那么吃和举办宴会就是操作，许可并没有解耦操作与资源，而是通过绑定操作和资源，为权限给出具体的定义。

Aws 的权限设计包含role permission和resource permission. 通过resource permission就可以限制可以修改资源的role或者user. 例子是。S3 bucket

对RBAC多了几点认识。1. permission 许可 解耦了操作与资源的关系，更细粒度地控制。 2. Contrains 约束 保证了不同角色、不同许可之间 满足互斥条件，比如出纳和会计不能给同一个人，否则财务账目可能出问题。