不同的公司或软件提供商,设计了无数种控制用户访问功能或资源的方法。但无论哪种设计,都可归到四种经典权限模型里——自主访问控制(DAC, Discretionary Access Control)、强制访问控制(MAC, Mandatory Access Control)、基于角色访问控制(RBAC, Role-based Access Control)和基于属性访问控制(ABAC, Attribute-based Access Control)。
从本质来说,无论何种类型的权限管理模型都可以抽象出三个基本的要素——即:用户(user)、系统/应用(system/application)、策略(policy)。
访问控制模型三要素
自主访问控制模型(DAC,Discretionary Access Control)是根据自主访问控制策略建立的一种模型,允许合法用户以用户或用户组的身份访问策略规定的客体,同时阻止非授权用户访问客体。拥有客体权限的用户,可以将该客体的权限分配给其他用户。例如没有文件 File1 访问权限的用户可以从有访问权限的 B 用户那里得到访问权限。
权限控制列表
访问控制列表 (ACL, Access Control List),每一个客体都配有一个列表,这个列表记录了主体对客体进行何种操作。当系统试图访问客体时,先检查这个列表中是否有关于当前用户的访问权限。ACL 是一种面向资源的访问控制模型,它的机制是围绕资源展开的。
对于一个文件对象的 ACL:
表示 Alice 可以对该文件进行读写操作,Bob 只能读取。
权限控制矩阵
访问控制矩阵 (ACM,Access Control Matrix) 是通过矩阵形式描述主体和客体之间的权限分配关系。每个主体而言,都拥有对哪些客体的哪些访问权限;而对客体而言,又有哪些主体对他可以实施访问;
DAC 常见于文件系统,LINUX,UNIX、WindowsNT 版本的操作系统都提供 DAC 的支持。在实现上,先对用户鉴权,然后根据控制列表决定用户能否访问资源。用户控制权限的修改通常由特权用户或者管理员组实现。
特点
授权的实施主体(1、可以授权的主体;2、管理授权的客体;3、授权组)自主负责赋予和回收其他主体对客体资源的访问权限。DAC 模型一般采用访问控制矩阵和访问控制列表来存放不同主体的访问控制信息,从而达到对主体访问权限的限制目的。
缺点
强制访问控制模型 (MAC, Mandatory Access Control), 是为了弥补 DAC 权限控制过于分散的问题而诞生的。在计算机安全领域指一种由操作系统约束的访问控制,目标是限制主体或发起者访问或对对象或目标执行某种操作的能力。任何主体对任何对象的任何操作都将根据一组授权规则(也称策略)进行测试,决定操作是否允许。
MAC 非常适合机密机构或者其他等级观念强烈的行业,过重强调保密性,管理不够灵活。在实现上,MAC 和 DAC 通常为每个用户赋予对客体的访问权限规则集,考虑到管理的方便,在这一过程中还经常将具有相同职能的用户聚为组,然后再为每个组分配许可权。
强制访问控制系统根据主体和客体的敏感标记来决定访问模式,模式包括
由于安全性,这种方式一直被军方所使用,下面讲述两种被广泛使用的强制访问控制安全模型
管理员定义一系列角色(roles)并把它们赋予主体。系统进程和普通用户可能有不同的角色。设置对象为某个类型,主体具有相应的角色就可以访问它。这样就把管理员从定义每个用户的许可权限的繁冗工作中解放出来。
基于角色的访问控制 (RBAC, Role Based Access Control) 在用户和权限之间引入了 “角色(Role)” 的概念,角色解耦了用户和权限之间的关系。
角色和组的主要区别:
基于角色的访问控制模型 RBAC,有时成为基于规则的基于角色的访问控制(Rule-Based Role-Based Access Control,RB-RBAC)。它包含了根据主体的属性和策略定义的规则动态地赋予主体角色的机制。例如,你是一个网络中的主体,你想访问另一个网络中的对象。这个网络在定义好了访问列表的路由器的另一端。路由器根据你的网络地址或协议,赋予你某个角色,这决定了你是否被授权访问。
RBAC0
RBAC0 作为基础模型,只包含核心的三要素,用户,角色,权限。用户和角色可以是多对多的关系,权限和角色也是多对多的关系。
RBAC1
RBAC1 包括了 RBAC0 并且添加了角色继承。顾名思义,角色继承就是指角色可以继承于其他角色,在拥有其他角色权限的同时,自己还可以关联额外的权限。这种设计可以给角色分组和分层,一定程度简化了权限管理工作。也就是角色之间存在上下级的关系,对应到实体设计中也就是角色实体的自身关联。
RBAC2
RBAC2 也包括 RBAC0 并且添加了约束。RBAC1 和 RBAC2 相互独立. RBAC2 的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
互斥约束:包括互斥用户,互斥角色,互斥权限。同一个用户不能拥有相互排斥的角色,两个互斥角色不能分配一样的权限集,互斥的权限不能分配给同一个角色,在 session 中,同一个角色不能拥有互斥权限。
基数约束:一个角色被分配的用户数量受限,它指的是有多少用户能拥有这个角色。例如:一个角色专门为公司 CEO 创建的,那这个角色的数量是有限的。
先决条件角色:指要想获得较高的权限,要首先拥有低一级的权限。例如:先有副总经理权限,才能有总经理权限。
RBAC3
RBAC3 是一个全功能的 RBAC,RBAC3 合并了 RBAC0,RBAC1,RBAC2.
基于属性的访问控制 (ABAC, Attribute Based Access Control) 通过动态计算一个或一组属性是否满足某种条件来进行授权判断。可以按需实现不同颗粒度的权限控制,但定义权限时不易看出用户和对象间的关系。如果规则复杂,容易给管理者带来维护和追查带来麻烦。
属性通常来说分为四类:
指定基于属性的控制协议需要将主体,环境,客体的属性构建集合,通过关联控制策略形成响应结果.
跟 RBAC 相比,ABAC 对权限的控制粒度更细,如控制用户的访问速率。实际开发中可以结合 RBAC 角色管理的优点和 ABAC 的灵活性一起使用。
文章来源:博客园
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。