复杂系统设计基础 —— 权限控制

7,002 阅读5分钟

权限控制(AC)

即 Access Control,一句话介绍:「谁(Who)可以对什么资源(What)进行什么操作(How)」

权限控制属于系统设计的一部分,常见于几乎所有 ToB 的系统内。尤其是一些传统的层级很多的企业内,权限控制非常重要

什么是资源

资源是一个非常宽泛的概念,任何需要控制的实体都可以定义为资源,如:页面、链接、接口、数据

操作有什么

读写,或者更详细一些:增删改查

什么是权限

对某种资源的某个操作,称为权限

这么简单的东西为什么要讲呢

不就是这玩儿意么?

简单问题会随着规模提升而变成复杂问题,上面只是课后习题,而现实世界是这样的:

假设一个公司 500 人规模,后台系统大概 10 几个,姑且全计算大概 500 个页面(不计页面内的读写权限),这些页面的使用者预估 200 人,大概划分成 60 个工种,那么实际的关系大概如下图所示:

到这里其实也不是很复杂,不就是一堆关系表嘛,总能理顺清楚。但是上面的结构并不是不变的,人员流动,岗位变更,功能增加,组织结构调整等等,会变成下面这样

说完了复杂情况,我们来讲一些理论

理论模型 RBAC

基本上提到权限控制,大多数人的第一反应都是下面的模型

【用户 - 角色】 - 解决了 who 的问题

【角色 - 权限】 - 解决了what 和 how 的问题

是不是只有这一种解决方案呢?

一种更简单的模型:基于资源的权限控制(Source-Based Access Control)

即:谁有什么权限

基于角色的权限控制(Role-Based Access Control)

本质是增加了【角色】这一中间层,将用户和权限解耦。角色的本质是权限的集合

RBAC 96 模型族 为目前最为主流的理论模型,由美国 George Mason(乔治梅森)大学信息安全技术实验室(LIST)提出。

Google Scholar 上关于 RBAC 被引用次数最多的论文:csrc.nist.gov/CSRC/media/…

其他模型如:ARBAC 97(Administration RBAC)、NIST RBAC(美国 NIST 的标准化 RBAC 模式)等等

1. 我们来讲讲 RBAC 96 模型族

我们逐个介绍:

2. RBAC 0 - 最基本的 RBAC 模型

【用户 - 角色】和【角色 - 权限】的对应关系都可以是 1:N 或者 1:1,视具体情况而定

3. RBAC 1 - 限制了角色的 RBAC 模型

RBAC1 对角色进行了限制,增加了角色之间的继承关系,解决的是层级关系带来的权限继承

比如都是前端开发,细分为了「后台前端开发」和「H5 前端开发」,就可以基于这种模型

角色之间只存在继承关系

4. RBAC 2 - 基于 RBAC0 增加了角色、和权限本身限制的 RBAC 模型

分为静态职责分离 SSD(Static Separation of Duty)和动态职责分离 DSD(Dynamic Separation of Duty)

静态职责分离 SSD

  1. 互斥角色限制:角色间存在互斥关系,用户只能选择其中一个角色;

  2. 基数限制:一个用户拥有的角色数量是有上限的,一个角色对应的权限数量也是有上限的;

  3. 先决条件限制:角色之间存在前置依赖关系,用户必须先获得低级角色才能拥有高级角色;

动态职责分离 DSD

  1. 如果用户拥有两个及以上角色,则同一时间段内有且只有一个角色可以生效

限制条件有些抽象,举几个例子 🌰

  1. 出纳和会计就是两个互斥的角色,不能由同一个人同时担任(互斥角色一般是两者权限存在串通或者监督关系)

  2. 一些体系内角色有高级和低级区别,比如专员和经理

5. RBAC 3 - 最完善的 RBAC 模型

RBAC 3 = RBAC 1 + RBAC 2

落地实现

技术实现

前端如何控制

简单来说,if 条件判断控制显隐

<el-button type="primary" v-if="hasPermission" @click="awesomeFunc">
  一个牛逼的按钮
</el-button>

具体能做哪些控制

  1. 根据可访问内容生成菜单

  2. 路由跳转前校验权限

  3. 表格数据显示判断权限

  4. 无权限页面、消息提醒

  5. 。。。

后端如何控制

  1. 判定当前用户是否有该接口权限

  2. 记录用户的接口请求(访问日志)

常见角色设计

RBAC 模型中的角色是一个抽象概念,实际设计中还可能会增加其他中间层。具体是基于 RBAC 哪个模型,只取决于实际业务需求的限定条件

1、用户 - 角色 - 权限

即 RBAC0 的最基本情况,适用于大多数场景

2、用户 - 岗位 - 角色 - 权限

岗位决定了角色,用户身处什么岗位即拥有相应的角色

比如:我是一名会员线的电子书编辑,自然我的角色就是电子书编辑,可以访问 CMS 里电子书相关的所有页面。一段时间后,我同时开始负责了锦囊的编辑,那就增加锦囊编辑的角色就好了

3、其他

进一步还可以增加【职责】【组织/部门】等