梦想还是要有的，万一忘了咋办？

0%

系统权限设计

发表于
本文字数： 2.4k 阅读时长 ≈ 2 分钟

目录

  • 总览
  • ACL模型
  • DAC模型
  • MAC模型
  • ABAC模型
  • RBAC模型

总览

简称 全称 中文
ACL Access Control List 访问控制列表
DAC Discretionary Access Control 自主访问控制
MAC Mandatory Access Control 强制访问控制
ABAC Attribute-Based Access Control 基于属性的访问控制
RBAC Role-Based Access Control 基于角色的访问控制

ACL模型

Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。
原理 ：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。
例如 ：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。
缺点 ：当主体的数量较多时，配置和维护工作就会成本大、易出错。

DAC模型

Discretionary Access Control，DAC是ACL的一种拓展。

原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。

例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。

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

MAC模型

Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。

原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。

例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

ABAC模型

Attribute-Based Access Control，能很好地解决RBAC的缺点，在新增资源时容易维护。

原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。

属性通常有四类：

主体属性，如用户年龄、性别等；
客体属性，如一篇文章等；
环境属性，即空间限制、时间限制、频度限制；
操作属性，即行为类型，如读写、只读等。
例如：早上9:00，11:00期间A、B两个部门一起以考生的身份考试，下午14:00，17:00期间A、B两个部门相互阅卷。

缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。

RBAC模型

Role-Based Access Control，核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。

RBAC三要素

  • 用户：系统中所有的账户
  • 角色：一系列权限的集合（如：管理员，开发者，审计管理员等）
  • 权限：菜单，按钮，数据的增删改查等详细权限。
    在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。

角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色

角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。

优点：便于角色划分，更灵活的授权管理3；最小颗粒度授权；
alt text

RBAC0

  • 用户、角色 多对多
  • 角色、权限 多对多
    alt text

RBAC1

在 RBAC0 的基础之上增加：

  • 角色 之间可以集成
    rbac1

RBAC2

在 RBAC0 基础上增加：

  • 角色互斥
  • 角色 用户数量限制

RBAC2

RBAC3

同时 具备 RBAC0、RBAC1、RBAC2 的特征；

实践RBAC

RBAC 权限模型由三部分：用户管理、角色管理、权限管理，组成。其中权限管理又分：菜单、操作、数据；

用户管理

  • 企业组织架构、业务线、实际业务 架构有所不同，通过授权解决。授权某个人、角色共享某个组织的某个对象组的数据。

角色管理

深入理解公司架构、业务架构后再进行设计；角色相对比较固定；

  • 员工入职后自动获取基础角色；
  • 管理外援，有时效的临时角色；
  • 组织架构不存在的角色，但实际业务中存在，虚拟角色；
  • 业务需要特殊提权，白名单；
  • 危险员工敏感权限收回，黑名单；

权限管理

页面/菜单权限

对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。

操作权限

操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。

数据权限

对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。

数据权限如何控制

数据权限可以分为行权限和列权限。行权限控制：看多少条数据。列权限控制：看一条数据的多少个字段

简单系统中可以通过组织架构来管控行权限，按照角色来配置列权限，但是遇到复杂情况，组织架构是承载不了复杂行权限管控，角色也更不能承载列的特殊化展示。

目前行业的做法是提供行列级数据权规则配置，把规则当成类似权限点配置赋予某个角色或者某个用户。


其他建议

  • 无权限提示页面 应当与 404 区分开
  • 开始就要想好、要简单、不要复杂；
  • 超级管理员在系统初始化好以后就应该被禁用