关于访问控制,我们接触最多的是操作系统,我们在设计应用的权限系统时多少可以借鉴借鉴。
- 可信操作系统 Trusted OS
- Trusted Computer System Evaluation Criteria 可信计算机系统评估标准(美国国防部)
- 多级别安全 Multilevel Security, MLS
ACL 访问控制表
Access Control List
Access Control Entry, ACE, 访问控制条目
- 资源
- 主体,即操作者(用户,或者用户组)
- 操作
ACM 访问控制矩阵
DAC 自主访问控制
Discretionary Access Control
可以认为是 ACL 的一种实现,但是多了一个自主的概念,表示资源的权限由资源拥有者(或管理者)进行管理。
Linux 中,操作者分成四种:管理员(root),所有者 u,所有组 g,其他 o
MAC 强制访问控制
Mandatory Access Control
PS: Windows Vista 之后引入 Mandatory Integrity Control(强制完整性控制,MIC),可能是类似概念。
强制的意思是权限的管理应该由管理员来负责。
资源拥有一组
在 Linux 系统中,就是美国国家安全局(NSA)开源的 SELinux 安全模块提供 MAC 功能。
PS: Linux 带有一组钩子,叫做 Linux Security Mmodule (LSM),执行于在 DAC 检查之后,实际操作发生之前。SELinux 就是在这些钩子上注册了一些处理逻辑。
sudo apt install -y selinux-basics
ls -lZ ~/.ssh/config
# -rw-------. 2 catroll catroll system_u:object_r:unlabeled_t:s0 7384 2021-07-27 16:23:04 /home/catroll/.ssh/config
- Subject 主体:操作发起方,某个进程
- Object 客体:操作访问对象,进程、文件、Socket、端口、设备,或别的进程
- Action 操作
- Context 上下文
- SELinux User
- SELinux Role
- SELinux Type
- SELinux Level (可选)
SELinux 中不管什么 root 用户不 root 用户,都要遵守规则(不过 root 可以修改规则)。
AVC:Access Vector Cache
RBAC 基于角色的访问控制
RBAC 是 MAC 和 DAC 的实现途径。
原则
- 用户权限来自所属角色
- 最小权限
概念
- U = User 用户
- R = Role 角色
- P = Permission 权限
- SE = Session 会话
用户在一次会话中可以激活所有角色,或者角色的一个子集,从而获得一组权限。 - UA = 用户分配
U * R
- PA = 权限分配
P * R
- RH = 角色层次
R * R
上级权限是所有下级权限的父集
关联
- User -> Session -> Role
-
User -> Role -> Permission -> (Operation 操作 + Object 目标)
-
用户和角色多对多
- 角色和权限多对多
- 权限和操作多对多
- 用户和角色之间的约束
- 会话和角色之间的约束
NIST RBAC 模型
A Proposed Standard for Role-Based Access Control, 2000/12/18
- 核心 RBAC (RBAC0)
- 分层 RBAC (RBAC1),支持角色层次
- 受限 RBAC (RBAC2):
- Separation of Duty (SOD), 职权分离
- Static Separation of Duties
角色互斥,比如:禁止用户同时是会计和出纳 - Dynamic Separation of Duties
权限判断时,限制关联操作不能由同一个用户完成,比如:禁止用户审核自己提交的申请
- Static Separation of Duties
- 限制:限制用户角色数量或权限数量,限制角色拥有的用户数量
- 前置条件:用户需要获得某个角色或权限之前必须拥有另一组角色或权限
- Separation of Duty (SOD), 职权分离
- 统一 RBAC (RBAC3):
- rbac1 + rbac2
- 角色的父角色或子角色数量限制
- 指定两个角色之间是否可以有共同的父角色或子角色
ARBAC97
https://profsandhu.com/cs5323_s17/arbac97.pdf
https://profsandhu.com/articles/advcom/adv_comp_rbac.pdf
https://www.sis.pitt.edu/jjoshi/ARBAC07.pdf
Administrative RBAC,RBAC 管理模型,相当于 RBAC 的拓展,引入了和常规角色互斥的管理角色。
- URA: User-Role Assignment
- RRA: Role-Role Assignment
- PRA: Permission-Role Assignment
ABAC
基于属性访问控制 Attribute-based, 又被称之为基于策略访问控制 Policy-based, 或基于声明访问控制 Claims-based。
其思路是设置一组策略,包含操作类型和一组相关属性,当有人执行指定操作时,判断当前时刻相关属性是否满足要求。比如判断时间是否正确,判断系统状态是否合适,判断文件的保密级别是否符合。
策略包含来自以下三个方面的属性:
- 用户属性:角色,地区...
- 资源属性:所有者,保密级别,类型...
- 环境属性:访问时间,系统状态...
比 RBAC 灵活性更强,同时也更复杂。可以认为 RBAC 是 ABAC 的一种简单的实现。
思考
ABAC 的思路令人感觉非常棒。只是和 RBAC 一样,在具体实现中,需要考虑使用的可操作性:便捷、易于理解、不容易发生错误。
- 权限中包含的资源范围
- 有时候的实现中,操作权限和资源权限是分开管理的。
- 前置条件约束:比如说操作顺序
- 管理方面的约束:
- 如果操作权限和资源权限分开管理,如果分配了某一个操作权限,就必须分配相应的资源。
- 可能需要参考 ARBAC 中的设计。
- 用户组的概念
用户 - 角色
之外,增加用户 - 用户组 - 角色
的关联。
- 系统已有的用户管理,比如企业组织结构和 RBAC 中角色的同步。
- 同一个用户允许多少个 Session 的判断纳入 RBAC 约束中(CreateSession 时处理)。
- 大多数时候,我们都没有在权限系统中实现 Session 的概念,用户直接拥有其所有所属角色的权限。
- 其实最麻烦的问题是交付,客户希望权限控制灵活,同时操作简单:
- 有时,客户要求用户粒度的权限控制,同时为了管理便捷性(用户数不多,同时不想维护太多角色),保留一个弱化的 Role 概念,实际上 Role 只起到权限模板的作用(应该不能称之为 RBAC 了):用户设置角色时,将角色的权限全部赋给用户,然后有很多更加复杂的说明,比如角色权限调整了怎么处理,用户角色调整时如何处理。
- 还有时,可能为了减少角色维护的工作量,允许直接对用户赋予权限。
参考资料与拓展阅读
- CSDN, 史上最全的权限认证服务的权限模型大全
- Thoughtworks, 分布式系统下的认证与授权
- 掘金,李少博,史上最强的权限系统设计攻略(上)、基础概念、RBAC以及ABAC模型
- 掘金,李少博,史上最强的权限系统设计攻略(下)、ABAC在复杂场景下的实现思路