🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
[https://www.jianshu.com/p/2a07763bc81f](https://www.jianshu.com/p/2a07763bc81f) [http://www.woshipm.com/pd/2310691.html/comment-page-1](http://www.woshipm.com/pd/2310691.html/comment-page-1) ![](https://img.kancloud.cn/ac/ba/acbae65a1df7846634fcfbf88b0e3dc2_697x364.png) ##### 权限一句话来理解就是对资源的控制,对web应用来说就是对url的控制 权限系统理解透彻了很简单的,就是**用户和资源**!你的页面也好,输入框或者按钮也罢,甚至列表里面的一行或一列,都可以理解为资源。然后,不就是A可以访问某个页面而B不可以,C可以录入数据而D只能看么?所以说: **权限就是用户使用资源的规则** 在这个规则里面,根本性的数据只有用户和资源,但因为用户太多,不方便授权操作,所以引入了角色、用户组、组织机构等等。通过角色进行授权,又通过用户组、职位这些关联用户可以大大减少具体的授权操作工作量。所以一个完善的权限系统,是必然要包含这些的。 ***** 编辑、查看、审核、删除 、添加、数据管理、权限管理 ACL, DAC, MAC, RBAC, ABAC模型的不同应用场景 ### **ACL 访问控制列表** ![](https://img.kancloud.cn/a4/fe/a4fefabc427862a2e14073353408c1fa_260x99.png) >[info] 规定**资源**可以被哪些**主体**进行哪些**操作** `ACL`是`Access Control List`的缩写,称为访问控制列表. 定义了谁(用户)可以对某个数据进行何种操作(权限). 关键数据模型有: 用户, 权限. ACL规则简单, 也带来一些问题: 资源的权限需要在用户间切换的成本极大; 用户数或资源的数量增长, 都会加剧规则维护成本; #### 典型应用 1. 文件系统 文件系统的文件或文件夹定义某个账号(user)或某个群组(group)对文件(夹)的读(read)/写(write)/执行(execute)权限. ![](https://img.kancloud.cn/7c/49/7c49a238c7b4a47e9bfaace1c3af60d1_633x235.png) 2. 网络访问 防火墙: 服务器限制不允许指定机器访问其指定端口, 或允许特定指定服务器访问其指定几个端口. 3. 场景:部门隔离 适用资源:客户页面、人事页面 在ACL权限模型下,权限管理是围绕**资源**来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下: ~~~ ACL配置表 资源: 客户页面 主体: 销售部(组) 操作:增删改查 主体: 王总(用户) 操作: 增删改查 资源: 人事页面 主体: 王总(组) 操作: 增删改查 ~~~ 注:主体可以是用户,也可以是组。 在维护性上,一般在粗粒度和相对静态的情况下,比较容易维护。 在细粒度情况下,比如将不同的客户视为不同的资源,1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的,那么就要对每种资源做相同的操作;如果权限配置是无规律的,那么ACL不妨也是一种恰当的解决方案。 在动态情况下,权限经常变动,每添加一名员工,都需要配置所有他需要访问的资源,这在频繁变动的大型系统里,也是很难维护的。 在一些情况下,ACL也可应用于细粒度场景,接下来将介绍两种ACL的拓展。 * * * ### **DAC 自主访问控制** >[info] 规定**资源**可以被哪些**主体**进行哪些**操作** > 同时,**主体**可以将**资源**、**操作**的权限,授予其他**主体** 场景:文件系统 适用资源:人事培训文档 DAC是ACL的一种实现,强调灵活性。纯粹的ACL,权限由中心管理员统一分配,缺乏灵活性。为了加强灵活性,在ACL的基础上,DAC模型将授权的权力下放,允许拥有权限的用户,**可以自主地将权限授予其他用户**。 比如,在纯粹ACL模型下,每次新人培训,人事总监都要通知IT部,将培训文档的访问权限授予新人。在DAC模型下,人事总监只需将文档的访问权限授予人事专员。之后,每次新人培训,由人事专员将文档的访问权限授予不同的新人。 * * * ### **MAC 强制访问控制** >[info] a. 规定**资源**可以被哪些**类别的主体**进行哪些**操作** > b. 规定**主体**可以对哪些**等级的资源**进行哪些**操作** > 当一个操作,同时满足a与b时,允许操作。 ![](https://img.kancloud.cn/a6/01/a601b404a92337cdb0d2d36b96e07400_704x489.png) 场景:保密系统 适用资源:机密档案 MAC是ACL的另一种实现,强调安全性。MAC会在系统中,对资源与主体,都划分类别与等级。比如,等级分为:秘密级、机密级、绝密级;类别分为:军事人员、财务人员、行政人员。 比如,一份机密级的财务档案,可以确保只有主体的等级是机密级,且是财务人员才能访问。如果是机密级的行政人员就无法访问。 ~~~text 资源配置表 资源: 财务文档 主体: 财务人员 等级:机密级 操作:查看 主体配置表 主体: 李女士 类别: 财务人员 等级:机密级 ~~~ 所以,MAC的优势就是实现资源与主体的双重验证,确保资源的交叉隔离,提高安全性。 * * * ### **RBAC 基于角色的访问控制** `RBAC`是`Role-based access control`的缩写, 称为 基于角色的访问控制. 核心数据模型有: 用户, 角色, 权限. * 权限:规定**角色**可以对哪些**资源**进行哪些**操作** * 角色:规定**主体**拥有哪些**角色**,一个角色,可拥有多个权限 * 账户:成员用账户登陆管理后台,账户对应角色 如果层级比较深,业务线条多,可以增加‘部门’,用以抽象角色,方便更高效配置。比如销售部门下,有助理和经理两个角色,他们拥有销售部共同的权限,也拥有各自角色不同权限,助理只能看到自己的销售额,经理可以看到部门销售总额。 用户具有角色, 而角色具有权限, 从而表达用户具有权限. 由于有角色作为中间纽带, 当新增用户时, 只需要为用户赋予角色, 用户即获得角色所包含的所有权限. ## 权限有哪些 模型中权限这个元素,按颗粒度从大到小,可以分为: * 导航:由路由控制,是否可以访问一组页面 * 页面:是否可以访问某个页面 * 操作:访问某个页面时,按钮是否可以见,可否增删改查 * 字段:页面中某个字段是否可见、是否可编辑 导航权限最好实现,适用简单管理后台上线初期,协作者少的项目。比如电商业务开始只有商品和客服两组人,商品要管理品类、上传编辑商品、发起折扣;客户要回复留言、查看购买记录。如此组织,可将‘商品模块’和‘客服模块’的权限以导航组织,一级导航下整组页面,所有数据可见,所有操作可执行。只是和开发商量好,设计数据结构和逻辑规则时考虑扩展性,准备好未来细化到操作甚至字段级别的颗粒度。 操作级别的权限,如果技术是微服务架构,可以做成以url控制操作。比如按钮点击时,访问url,不同权限,可访问不同url;未授权时点击按钮操作无效。若希望按钮完全不可见,需要前端增加判断。 字段级别,是最精细的权限控制。比如电销人员浏览客户信息时,电话号码不可见,客服人员看到客户销售订单时,销售金额不可见;权限设计时,需要隐藏页面上相应字段。 ## 任意组合权限,给谁? 上述这些不同颗粒度权限,相互组合之后,分配给不同角色。比如电商中,创建以一个角色‘商品运营’,这个角色拥有权限可以这样描述:可以访问和编辑‘商品’一级导航下所有页面。因为业务线上不止一个员工,‘商品运营’这个角色,可以有多个人承担;在这些员工自己账号下,分配‘商品运营’角色。 用角色作为权限和账号的中介,最大好处在一次批量配置,不用每个账号单独配置。 ## 界面怎么画? 如果只要导航级别权限,其实只需要两个页面。一个角色页面,一个账户页面。角色页面主体是角色列表,可新建角色,新建时勾选权限。账户页面主体是账户列表,可新建账户,新建时选择账户对应的角色。 更多具体细节,可以看SAAS产品的帮助文档,因为是给客户用的,文档会有教科书级别的页面和描述,比如某CRM产品权限模块使用说明: > 如果员工没有某对象“查看列表”的权限,则该对象的功能入口会被隐藏 如果员工没有某对象的操作点权限,则在对象页面上隐藏相应操作按钮 如果员工没有某对象的指定字段的可见权限,则在对象页面上隐藏相应字段 `RBAC`存在多个扩展版本, `RBAC0`、`RBAC1`、`RBAC2`、`RBAC3`。这些版本的详细说明可以参数[这里](https://www.jianshu.com/p/b078abe9534f)。我们在实际项目中经常使用的是`RBAC1`,即带有角色继承概念的RBAC模型。 RBAC其实是一种分析模型,主要分为:基本模型RBAC0(Core RBAC)、角色分层模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines RBAC)。 #### **1)RBAC0** RBAC0,它是RBAC0的核心,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合,RBAC0由四部分构成: * a、用户(User) * b、角色(Role) * c、会话(Session) * d、许可(Pemission),其中许可又包括“操作”和“控制对象”其中许可被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的许可。会话是动态的概念,用户必须通过会话才可以设置角色,是用户与激活的角色之间的映射关系。 ##### 如图,用户与角色是多对多的关系;角色和许可也是多对多的关系;用户与会话是一对一关系;会话与角色是一对多关系; ![](https://img.kancloud.cn/9f/58/9f58fa49821cded7316b6f190a9e487d_626x268.png) #### **2)RBAC1** RBAC1,它是RBAC角色的分层模型,RBAC1建立在RBAC0基础之上,在角色中引入了继承的概念,有了继承那么角色就有了上下级或者等级关系,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对[偏序关系](https://link.jianshu.com?t=http://baike.baidu.com/view/1469650.htm),允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。 这种模型合适于角色之间的层次明确,包含明确。 ![](https://img.kancloud.cn/7f/29/7f29b0c5dd1850563fca18f24bfea413_579x294.png) #### **3)RBAC2** RBAC2,它是RBAC的约束模型,RBAC2也是建立的RBAC0的基础之上的,在RBAC0基础上假如了约束的概念,主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。 ##### SSD是用户和角色的指派阶段加入的,主要是对用户和角色有如下约束: * a、互斥角色:同一个用户在两个互斥角色中只能选择一个 * b、基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的 * c、先决条件约束:用户想要获得高级角色,首先必须拥有低级角色 ##### DSD是会话和角色之间的约束,可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。 ![](https://img.kancloud.cn/72/2e/722e6f07ae5ddde9193a2a36b34c00d6_590x339.png) #### **4)RBAC3** RBAC3,它是RBAC1与RBAC2合集,所以RBAC3是既有角色分层又有约束的一种模型 ![](https://img.kancloud.cn/39/ef/39ef73b859bbce0e14360f08c25c9661_592x381.png) 场景:企业数据 适用资源:客户信息 RBAC的思想,来源于现实世界的企业结构。比如,销售角色,拥有查看客户信息的权限。当一个销售人员小王入职了,可以把销售角色赋予小王,那么小王就拥有了查看客户的权限。这种方式,避免了ACL模型下,每次新人入职,需要逐个配置资源表的情况。同样,权限变动也变得很方便,只要修改角色,即可实现多用户的权限修改。 **权限表** ~~~ 名称:创建客户 资源: 客户信息 操作:创建 名称:删除客户 资源: 客户信息 操作:删除 名称:查看客户 资源: 客户信息 操作:查看 名称:修改客户 资源: 客户信息 操作:修改 ~~~ **角色表** ~~~ 名称:销售角色 权限: 创建客户、删除客户、查看客户、修改客户 ~~~ **用户表** ~~~ 主体:小王 角色: 销售角色 ~~~ RABC并不总能满足所有权限的场景。比如,我们无法对销售角色,进行个体定制。比如,销售角色拥有创建、删除的权限。如果我们要对销售小李,去掉删除的权限。那么,我们就必须创建另一个角色,来满足需求。如果这种情况很频繁,就会丧失角色的统一性,降低系统的可维护性。 角色和组两个概念可能会让人混淆,在这里做个区分: * 角色赋予的是主体,主体可以是用户,也可以是组 * 角色是权限的集合 * 组是用户的集合 * * * ### **ABAC 基于属性的访问控制** >[info] 规定哪些**属性的主体**可以对哪些**属性的资源**在哪些**属性的情况**下进行哪些**操作**, `ABAC`是`Attribute-based access control`的缩写, 称为基于属性的访问控制. 权限和资源当时的状态(属性)有关, 属性的值可以用于正向判断(符合某种条件则通过), 也可以用于反向判断(符合某种条件则拒绝): #### 典型应用 1. 论坛的评论权限, 当帖子是锁定状态时, 则不再允许继续评论; 2. Github 私有仓库不允许其他人访问; 3. 发帖者可以编辑/删除评论(如果是RBAC, 会为发帖者定义一个角色, 但是每个帖子都要新增一条用户/发帖角色的记录); 4. 微信聊天消息超过2分钟则不再允许撤回; 5. 12306 只有实名认证后的账号才能购票; 6. 已过期的付费账号将不再允许使用付费功能; 场景:防火墙 适用资源:端口访问 ABAC其中的属性就是与主体、资源、情况相关的所有信息。 * 主体的属性:指的是与主体相关的所有信息,包括主体的年龄、性别、职位等。 * 资源的属性:指的是与资源相关的所有信息,包括资源的创建时间、创建位置、密级等。 * 情况的属性:指的是客观情况的属性,比如当前的时间、当前的位置、当前的场景(普通状态、紧急状态)。 * 操作:含义还是一样,比如增删改查等。 设定一个权限,就是定义一条含有四类属性信息的策略(Policy)。 ~~~css 策略表 效果:允许 操作:流入 主体:来自上海IP的客户端 资源:所有以33开头的端口(如3306) 情况:在北京时间 9:00~18:00 效果:禁止 操作:流出 主体:任何 资源:任何 情况:任何 ~~~ 一个请求会逐条匹配策略,如果没有匹配到策略,则返回默认效果,默认效果可以根据场景定制,可以是默认拒绝或是默认允许。另外,匹配方式也可以根据场景定制,可以使用**逐条顺序匹配**,匹配到策略直接返回。也可以使用**完全匹配**,匹配所有的策略,如果有一个拒绝(允许),则拒绝(允许)。 阿里云的RAM访问控制运用的就是ABAC模型: ~~~bash 阿里云RAM策略配置表 { "Version": "1", "Statement": [{ "Effect": "Allow", "Action": ["oss:List*", "oss:Get*"], "Resource": ["acs:oss:*:*:samplebucket", "acs:oss:*:*:samplebucket/*"], "Condition": { "IpAddress": { "acs:SourceIp": "42.160.1.0" } } }] } ~~~ ABAC可以发挥权限系统最大的灵活性,但在灵活的同时,如果不对策略加以管理,也有可维护性的问题。