首页  思维导图  详情

功能权限系统设计

2021-10-12 10:46:38   0  举报





AI智能生成

软件系统中的功能权限设计

权限设计

RBAC

ABAC

作者其他创作

大纲/内容

基础概念

越权访问

概念

权限系统设计的目的是为了将系统使用者对系统的操作约束在一个合法的范围内，系统的使用者不一定是人，也可能是另外一个系统，如果操作不在合法范围内，就会发生越权访问行为

分类

垂直越权

垂直越权是一种权限非法提升的行为，比如说现在有个系统，它的普通用户使用的页面是xxx.com/user , 管理员使用的页面是xxx.com/manager ,

水平越权

因为服务端没有判断数据的归属所造成的越权行为，比如说，现在我们登陆了一个系统，进入了查看用户id为1的详细信息的页面，这个页面的url是这样子的：xxx.com/user/1 ,然后我使个坏，把最后面的1改成了2，这时候由于后端系统没有判断我是否可以查看id为2的用户，就把数据返回给了我。

鉴权

指的是在进行一个操作的时候，需要权限系统先去判断用户是否具有进行这个操作的权限，在某些复杂场景之下还会包括对请求数据的归属权的校验。

设计模式

RBAC

概念

RBAC(Role Based Access Control)：基于角色的访问控制，这应该是当今IT系统使用的最多的权限管控模型

描述

角色即为操作（API）的聚合，RBAC通过给用户绑定某个角色，使用户具备了某些操作的能力，这是最简单的RBAC模型，学术上也称为RBAC0，与之对应的还有RBAC1、RBAC2、RBAC3，RBAC1是引入了角色继承的关系。

角色继承(Hierarchical Role)

角色继承很容易理解，即角色B继承了角色A，那么当用户绑定了角色B的时候，也就具备了角色A的操作能力；RBAC2是引入了角色互斥的关系，比如如果用户绑定了角色A就不能绑定角色B，这是因为考虑到现实世界中如果是运动员就不能是裁判这样的业务场景；RBAC3则是结合了RBAC1和RBAC2的能力，同时拥有角色互斥和角色继承的功能。

职责分离(Separation of Duty)

为了避免用户拥有过多权限而产生利益冲突，例如一个篮球运动员同时拥有裁判的权限（看一眼就给你判犯规狠不狠？），另一种职责分离扩展版的RBAC被提出。

职责分离有两种模式：静态职责分离(Static Separation of Duty)：用户无法同时被赋予有冲突的角色。
动态职责分离(Dynamic Separation of Duty)：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。

扩展

在有的权限系统的中，为了方便用户的使用，还衍生出了权限组或者是用户组的实体模型，权限组是一类API的聚合，比如用户操作权限组就可以包含对用户数据的增删查改操作，使用权限组的时候，角色不是和api去绑定，而是去和权限组绑定；用户组是将某一类用户分组，这个分组和角色去绑定，而不是用户和角色绑定，这样只要用户加入了这个组，就具备了某些操作权限，现实世界中这个组也有可能是公司部门等实体。

总结

我们可以看出来，在RBAC中，不管实体怎么变，角色（Role）的本质其实就是一系列API操作的聚合，通过用户与角色的直接或者间接绑定，使用户具备了某些操作的能力，这也是RBAC的本质。

ABAC

概念

ABAC(Attribute Based Access Control)：翻译过来意思是基于属性的权限访问控制，这个模型在如今的云系统中使用的比较多，比如AWS，阿里云，腾讯云，京东云等，它们都是用ABAC来管控IaaS以及PaaS的资源，曾经K8s也使用过这个模型来进行权限管控。

描述

RBAC的能力可以用这么一句话来描述：一个用户通过和角色绑定，具备了一些对数据操作的能力，往简单的说就是一个用户有了一些对数据操作的能力。但是，如果在复杂的权限管控场景中，RBAC显得有些力不从心，比如说：
- 用户在晚上不能访问这个系统，但是白天可以
- 用户只能在内网对订单具备修改权限，而在外网就只有查看权限
- 用户对2021-03-19日之前创建的订单有操作权限
- 用户只能在深圳进行查看订单，而去了国外就不可以
- 用户在公司内部可以访问所有数据，但是在外部就只能访问公开数据
我们很容易就发现，RBAC仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，模型本身是没有这些限制的，这也是由于其模型能力的不足所导致的，但这却恰恰是ABAC的长处，ABAC的思想是基于用户、以及将要访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。我们先简单介绍一下NIST ABAC设计指引中的一些术语:
- subject 指的是系统的使用者，可以是用户(user),也可以是其他非服务的个体(non-person entity，NPE)
- object 泛指被访问的数据
- operation/action 指操作行为，一般对应系统中的API
- policy 访问策略，它规定了一个用户在什么条件下可以对哪些数据做什么，是ABAC系统核心实体之一
- pdp pdp是policy decision point，策略点，其实我理解这玩意就是一个policy的展示出来的形式而已
- pep pep是policy enforcement point,策略执行点，简单说就是根据policy来鉴权
- acm acm是access control mechanism,权限管控机制，一般来说就是权限系统本身
- attribute 它泛指各种属性，可以是subject的，也可以是object的
- condition 各种额外的限制条件

扩展

ABAC仅仅受限于可以用来计算的属性的数量，这也很容易让很多人产生误解，误认为ABAC什么类型的权限都可以来管控，事实上，权限系统仅仅擅长于管控垂直越权，即使ABAC具备一定的管控水平越权的能力，也不要妄想可以用它来管控所有的水平越权。

LBAC

基于标签的访问控制(Label-based Access Control)

基于标签的访问控制模型，这是个非常复杂的模型，知识面有限，目前已知的应用场景只有IBM的DB2数据库，DB2通过使用安全标签方式来实现行级和列级的读写访问控制

DAC

自主访问控制（DAC: Discretionary Access Control）

系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。
而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。
这种设计最常见的应用就是文件系统的权限设计，如微软的NTFS。
DAC最大缺陷就是对权限控制比较分散，不便于管理，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。

MAC

强制访问控制（MAC: Mandatory Access Control）

MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。
MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。