TOC

访问控制

关于访问控制,我们接触最多的是操作系统,我们在设计应用的权限系统时多少可以借鉴借鉴。

  • 可信操作系统 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 的实现途径。

原则

  1. 用户权限来自所属角色
  2. 最小权限

概念

  • 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

  1. 核心 RBAC (RBAC0)
  2. 分层 RBAC (RBAC1),支持角色层次
  3. 受限 RBAC (RBAC2):
  4. Separation of Duty (SOD), 职权分离
    • Static Separation of Duties
      角色互斥,比如:禁止用户同时是会计和出纳
    • Dynamic Separation of Duties
      权限判断时,限制关联操作不能由同一个用户完成,比如:禁止用户审核自己提交的申请
  5. 限制:限制用户角色数量或权限数量,限制角色拥有的用户数量
  6. 前置条件:用户需要获得某个角色或权限之前必须拥有另一组角色或权限
  7. 统一 RBAC (RBAC3):
  8. rbac1 + rbac2
  9. 角色的父角色或子角色数量限制
  10. 指定两个角色之间是否可以有共同的父角色或子角色

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 的拓展,引入了和常规角色互斥的管理角色。

  1. URA: User-Role Assignment
  2. RRA: Role-Role Assignment
  3. PRA: Permission-Role Assignment

ABAC

基于属性访问控制 Attribute-based, 又被称之为基于策略访问控制 Policy-based, 或基于声明访问控制 Claims-based。

其思路是设置一组策略,包含操作类型和一组相关属性,当有人执行指定操作时,判断当前时刻相关属性是否满足要求。比如判断时间是否正确,判断系统状态是否合适,判断文件的保密级别是否符合。

策略包含来自以下三个方面的属性:

  • 用户属性:角色,地区...
  • 资源属性:所有者,保密级别,类型...
  • 环境属性:访问时间,系统状态...

比 RBAC 灵活性更强,同时也更复杂。可以认为 RBAC 是 ABAC 的一种简单的实现。

思考

ABAC 的思路令人感觉非常棒。只是和 RBAC 一样,在具体实现中,需要考虑使用的可操作性:便捷、易于理解、不容易发生错误。

  1. 权限中包含的资源范围
    1. 有时候的实现中,操作权限和资源权限是分开管理的。
  2. 前置条件约束:比如说操作顺序
  3. 管理方面的约束:
    1. 如果操作权限和资源权限分开管理,如果分配了某一个操作权限,就必须分配相应的资源。
    2. 可能需要参考 ARBAC 中的设计。
  4. 用户组的概念
    1. 用户 - 角色之外,增加用户 - 用户组 - 角色的关联。
  5. 系统已有的用户管理,比如企业组织结构和 RBAC 中角色的同步。
  6. 同一个用户允许多少个 Session 的判断纳入 RBAC 约束中(CreateSession 时处理)。
  7. 大多数时候,我们都没有在权限系统中实现 Session 的概念,用户直接拥有其所有所属角色的权限。
  8. 其实最麻烦的问题是交付,客户希望权限控制灵活,同时操作简单:
    1. 有时,客户要求用户粒度的权限控制,同时为了管理便捷性(用户数不多,同时不想维护太多角色),保留一个弱化的 Role 概念,实际上 Role 只起到权限模板的作用(应该不能称之为 RBAC 了):用户设置角色时,将角色的权限全部赋给用户,然后有很多更加复杂的说明,比如角色权限调整了怎么处理,用户角色调整时如何处理。
    2. 还有时,可能为了减少角色维护的工作量,允许直接对用户赋予权限。