My logo
Published on

常见的几种权限设计模式

auth

auth

1，ACL

Access Control List 权限控制列表

ACL(Access Control List)访问控制列表，一种访问控制机制，是最早也是最基本的一种访问控制机制，它的原理非常简单：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行CRUD中的那些操作。当系统试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。　　主要包含三个关键要素用户（User）、资源（Resource）和操作（Operate）。当用户请求操作资源时会检查资源的权限列表，如果资源的权限列表中存在该用户的操作权限则允许否则拒绝。

auth

应用场景

ACL目前比较广泛的应用是物联网中,在设备硬件层安全基础上, 通过对在软件层面对设备间通信进行访问控制, 使用可编程方法指定访问规则。我们平时用路由器,或者手机热点wifi限制网络流量,限制访问域名,禁止局域网设备访问外网等都属于ACL的应用,当然也有人利用ACL做防火墙。

auth

总结

ACL是一种面向资源的访问控制模型，它的机制是围绕“资源”展开的。由于ACL的简单性，使得它几乎不需要任何基础设施就可以完成访问控制。但同时它的缺点也是很明显的，

由于需要维护大量的访问权限列表，ACL在性能上有明显的缺陷。另外，对于拥有大量用户与众多资源的应用，管理访问控制列表本身就变成非常繁重的工作。

2，DAC

Discretionary Access Control自主访问控制

本质上他还是维护了一个访问控制列表,但是在ACL的基础上:规定资源可以被哪些主体进行哪些操作的同时，主体可以将资源、操作的权限，授予其他主体。

比如Windows的文件, 如果你有这个文件的权限, 你还可以给其他用户赋予这个文件的操作权限但是如果你可以连接一个路由器(路由器配置了你的mac地址), 你并不能把连接这个路由器的权限赋予给其他设备, 除非你有路由器管理页面的密码。

auth

DAC强调灵活性。纯粹的ACL，权限由中心管理员统一分配，缺乏灵活性。为了加强灵活性，在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，可以自主地将权限授予其他用户。

一般在实现上, DAC还会引入用户组的概念, 多个用户属于一个用户组, 给用户组配置权限就相当于给组里所有的用户配置权限,这样可以减少很多维护成本。

总结

DAC常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。在实现上，先对用户鉴权，然后根据控制列表决定用户能否访问资源。用户控制权限的修改通常由特权用户或者管理员组实现。

DAC最大缺陷就是对权限控制比较分散，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大,无意间就可能泄露信息。

3，MAC

Mandatory Access Control强制访问控制

MAC是ACL的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。比如，等级分为：秘密级、机密级、绝密级；类别分为：军事人员、财务人员、行政人员。

auth

在模型上, MAC引入了一个级别的概念并且一般会有和DAC的用户组类似的”类别”。

判断一个用户能否对一个资源进行某种操作要校验两点:

  1. 首先要校验用户的类别,
  2. .还要校验该用户在该类别下的级别是否大于操作的要求级别

所以之前一个访问列表的设计就无法满足MAC的要求了, MAC一般会有两个列表:

  1. 资源配置表:某个资源的某个操作要求是什么类别和什么级别
  2. 用户配置表:某个用户属于哪个类别的那个级别

auth

总结

MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。

4，RBAC（重点）

Role-Based Access Control基于角色的访问控制

RBAC（Role-Based Access Control：基于角色的访问控制）是20世纪90年代研究出来的一种新模型

说明

RBAC支持三个著名的安全原则：

  • 最小权限原则、责任分离原则和数据抽象原则最小权限原则：RBAC可以将角色配置成其完成任务所需的最小权限集合责任分离原则：
  • 可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作数据抽象原则：
  • 可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读、写、执行权限

RBAC认为权限授权的过程可以抽象地概括为：

Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为What、How的问题，Who、What、How构成了访问权限三元组

auth

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

auth

应用场景

有一个图书管理系统, 管理员和读者都使用这个系统系统有丢弃图书,购买图书,管理借阅人,借阅图书,修改个人信息等功能系统有图书管理员和读者两个角色右图展示了如何通过RBAC来控制不同用户可以使用的什么样的功能：

auth

介绍

auth

RBAC0

最简单、最原始的实现方式，是其他RBAC模型的基础：

auth

RBAC1

增加了角色的分层（即：子角色），子角色可以继承父角色的所有权限；

auth

RBAC2

基于RBAC0的另一种优化，增加了对角色的一些限制：角色互斥、角色容量等；

auth

角色容量为1, 用户已经占用了这个容量, 这时候用户2想再关联这个角色就不通过

auth

用户想要关联某个角色, 必须先关联另外一个角色

auth

RBAC3

最复杂也是最全面的RBAC模型, 也叫统一模型，它在RBAC0的基础上，将RBAC1和RBAC2中的优化部分进行了整合；模型图参照RBAC1和RBAC2

RBAC3已经很强大了, 但是在实际企业开发中, 光有用户,角色,权限还是不够的, 必须将:

  • 组织架构
  • 岗位
  • 职级
  • 资源

等概念和RBAC进行融合

基于RBAC3的企业权限模型设计

auth

总结

RBAC大量应用于现代企业应用的权限管理设计

功能强大：RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则

生态成熟：许多Java安全框架都是基于RBAC进行设计的,如:Shiro, Kasai, Spring Security

扩展灵活：RBAC由于基础概念简单灵活, 可以和企业的实际场景进行融合定制, 满足多样的诉求

5，ABAC

Attribute Based Access Control基于属性的访问控制

ABAC（Attribute-Based Access Control）基于属性的访问控制, 有时也被称为PBAC（Policy-BasedAccess Control）或CBAC（Claims-Based Access Control），不同于常见的用户通过某种方式关联到权限的方式。ABAC是通过动态计算一个或一组属性是否满足某种条件而进行授权判断。

auth

ABAC有如下特点：

  • 集中化管理
  • 可以按需实现不同颗粒度的权限控制
  • 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
  • 定义权限时，不能直观看出用户和对象间的关系

ABAC模型设计

auth

案例：

阿里云RAM访问控制

auth

优点

  • 对于大型组织，基于RBAC的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活；对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC授权模型。
  • 新增资源时，ABAC仅需要维护较少的资源。而RBAC需要维护所有相关的角色。ABAC可扩展性更强、更方便。
  • ABAC支持带有动态参数的授权规则，RBAC只能基于静态的参数进行判断。
  • ABAC权限控制的粒度比RBAC更细。

缺点

  • 模型设计相对复杂
  • 需要维护大量的规则, 而规则一般以脚本语言或者XML,JSON等形式存在, 非开发人员一般无法使用

RBAC与ABAC之间的主要区别在于方法授予访问权限的方式。 RBAC按照角色授予访问权限，ABAC可以根据用户特征，对象特征，操作类型等属性确定访问权限。ABAC可以发挥权限系统最大的灵活性，但在灵活的同时，如果不对策略加以管理，也有可维护性的问题。

6，总结

常见的权限系统有5种模式

  • ACL(Access Control List)访问控制列表
  • DAC(Discretionary Access Control)自主访问控制模型
  • MAC(Mandatory Access Control)强制访问控制模型
  • RBAC(Role-Based Access Control)基于角色的访问控制
  • ABAC(Attribute-Based Access Control)基于属性的访问控制

ACL DAC 适用于底层硬件或操作系统

MAC 适用于等级森严的军队, 政府

ABAC 灵活但维护成本高

RBAC应用成熟, 是综合最适用于一般企业场景的权限系统设计