权限设计种类【RBAC、ABAC】

本文涉及的产品
访问控制,不限时长
简介: 权限设计种类【RBAC、ABAC】
  • ACL 模型访问控制列表
  • DAC 模型:自主访问控制
  • MAC 模型:强制访问控制
  • ABAC 模型:基于属性的访问控制
  • RBAC 模型:基于角色的权限访问控制


一、简介前三种模型:

1.1 ACL(Access Control List):每一个客体都有一个列表,列表中记录的是哪些主体可以对哪些客体做什么。缺点:当主体的数量较多时,配置和维护成本大,易出错。

1.2 DAC(Discretionary Access control):是ACL的扩展,在其基础上,允许主体可以将自己拥有的 权限自主地授予其他主体,权限可以随意传递。缺点:权限控制比较分散,主体权限太大,有泄露信息的危险。


1.3 MAC(Mandatory Access Control):双向验证机制,常用于机密机构或者其他等级观念强的行列;主体和客体都有权限标识,主体能否对客体进行操作取决于双方的权限标识信息。缺点:控制严格、实现工作量大,缺乏灵活性。


二、RBAC详解

2.1 RBAC的概念

RBAC(Role-Based Access Control): 指的是通过用户的角色(Role)授权其相关权限,角色代表了权限。实现了灵活的访问控制,相比直接授予用户权限,要更加简单、高效、可扩展。

RBAC三要素:

用户:系统中的所有账户

角色:一系列权限的集合

权限:菜单、按钮、数据的增删改查

2.2 RBAC的深度拓展

基于角色的访问控制:RBAC 模型可以分为:RBAC0、RBAC1、RBAC2、RBAC3 四个阶段,一般公司使用 RBAC0 的模型就可以。另外,RBAC0 相当于底层逻辑,后三者都是在 RBAC0 模型上的拓展。【迄今为止最为普及的权限设计模型】


RBAC0:用户和角色、角色和权限多对多的关系。


RBAC1:增加了角色的分级逻辑,类似树结构,下一节点继承于上一节点的权限。


RBAC2:增加更多限制条件:角色互斥、角色数量限制,为了权责明确、系统安全


RBAC3:综合了RBAC1和RBAC2的所有特点。


RBAC0  RBAC1  RBAC2


三、ABAC详解

3.1 ABAC的概念

基于属性的访问控制(Attribute-Based Access Control,简称 ABAC) 是一种比 RBAC更加灵活的授权模型,它的原理是通过各种属性来动态判断一个操作是否可以被允许。这个模型在云系统中使用的比较多,比如 AWS,阿里云等


ABAC的四大要素:


  • 对象:对象是当前请求访问资源的用户。用户的属性包括 ID,个人资源,角色,部门和组织成员身份等


  • 资源:资源是当前用户要访问的资产或对象,例如文件,数据,服务器,甚至 API


  • 操作:操作是用户试图对资源进行的操作。常见的操作包括“读取”,“写入”,“编辑”,“复制”和“删除”


  • 环境:环境是每个访问请求的上下文。环境属性包含访问的时间和位置,对象的设备,通信协议和加密强度等。

在 ABAC模型 的决策语句的执行过程中,决策引擎会根据定义好的决策语句,结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时,ABAC模型决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略,访问请求就会被通过。缺点:规则复杂,不易看出主体与客体之间的关系,实现非常难,现在应用的很少。

3.2 ABAC的使用

有一些ABAC语言,如xacml和alpha。使用ALFA,我可以编写以下策略:

  • 允许用户在部门A中添加新的团队成员
  • 在部门B,他只能查看团队列表
  • 在其他部门,他没有任何权限。
  • 角色还必须是可继承的,存储在模型中,并可通过接口进行管理
policyset appAccess{
    apply firstApplicable
    policy members{
        target clause object = "member"
        apply firstApplicable
        /**
         * A user can add a member to a department if they are a manager and if they are assigned to that department.
         */
        rule addMember{
            target clause role == "manager" and action == "add"
            permit
            condition user.department == target.department
        }
    }
}

ABAC的主要优点之一是,可以开发任意多的策略,对它们进行审计和共享,而不必触及应用程序代码,因为最终将授权外部化。

3.3 两种模型对比


四、新权限系统的设计思想

新权限系统的权限模型:用户最终权限 = 用户拥有的角色带来的权限 + 用户独立配置的权限,两者取并集。

对于权限系统自身的用户,会分为三类:

  1. 超级管理员:拥有权限系统的全部操作权限,可以进行系统自身的任何操作,也可以管理接入权限的应用系统的管理操作。


  1. 权限操作用户:拥有至少一个已接入的应用系统的超级管理员角色的用户。该用户能进行的操作限定在所拥有的应用系统权限范围内。权限操作用户是一种身份,无需分配,而是根据规则自动获得的。


  1. 普通用户:普通用户也可以认为是一种身份,除去上述 2 类人,其余的都为普通用户。他们只能申请接入系统以及访问权限申请页面。


新权限系统中,把权限分为两大类,分别是:


  • 菜单功能权限:包括系统的目录导航、菜单的访问权限,以及按钮和 API 操作的权限


  • 数据权限:包括定义数据的查询范围权限,在不同系统中,通常叫做 “组织”、”站点“等,在新权限系统中,统一称作 ”组织“ 来管理数据权限


  • 每个统中设计了三个默认角色,用来满足基本的权限管理需求,分别如下:


  • 超级管理员:该角色拥有该系统的全部权限,可以修改系统的角色权限等配置,可以给其他用户授权。


  • 系统管理员:该角色拥有给其他用户授权以及修改系统的角色权限等配置能力,但角色本身不具有任何权限。


  • 授权管理员:该角色拥有给其他用户授权的能力。但是授权的范围不超出自己所拥有的权限


相关实践学习
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
相关文章
|
1月前
|
数据安全/隐私保护
基于RBAC0模型的简单权限系统设计角色
基于RBAC0模型的简单权限系统设计角色
|
1月前
|
Kubernetes API 数据安全/隐私保护
k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)
k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)
72 0
|
7月前
|
数据安全/隐私保护
RBAC权限模型
RBAC权限模型
90 0
|
SQL 存储 数据库
RBAC模型整合数据权限
RBAC模型整合数据权限
368 0
|
存储 缓存 运维
基于RBAC模型的权限管理设计
RBAC模型(Role-Based Access Control:基于角色的访问控制)是比较早期提出的权限实现模型,在多用户计算机时期该思想即被提出,其中以美国George Mason大学信息安全技术实验室(LIST)提出的RBAC96模型最具有代表,并得到了普遍的公认。 RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为Who、What、How的问题,Who、What、How构成了访问权限三元组,具体的理论可以参考RBAC96。
472 0
基于RBAC模型的权限管理设计
|
数据安全/隐私保护
【工作中问题解决实践 三】深入理解RBAC权限模型
【工作中问题解决实践 三】深入理解RBAC权限模型
132 0
|
安全 数据安全/隐私保护
RBAC的用户权限管理原理
RBAC的用户权限管理原理
127 0
|
监控 安全 数据安全/隐私保护
【应用安全】RBAC与ABAC:有什么区别?
在任何公司,网络用户必须经过身份验证和授权,才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。在本指南中,我讨论了管理系统访问控制的两种主要方法:基于角色的访问控制(RBAC)和基于属性的访问控制。
|
安全 JavaScript Java
复杂场景下的权限系统该怎么玩?ABAC权限模型帮你搞定它
复杂场景下的权限系统该怎么玩?ABAC权限模型帮你搞定它
|
调度 数据安全/隐私保护 网络架构
RBAC权限设计思想的理解和使用
RBAC权限设计思想的理解和使用
RBAC权限设计思想的理解和使用