跳转至

第 4 章：基于角色的访问控制

相对于找到恶意程序然后干掉它们，设置一个白名单似乎更容易保障安全。

个人化的白名单

  • 普通模式：
  • 只执行已知的程序。
  • 信任的签名、信任的安装器：加入到白名单中。
  • 不在白名单中：爬。
  • 安装模式：
  • 任何程序都能执行。
  • 执行了的程序、写入的文件：加入到白名单中。
  • 安装模式会尽量快地退出。

RBAC 模型

在 RBAC（Role Based Access Control）模型中，“Who”、“What”和“How”可以称作访问权限的三元组，即“Who 对 What 进行 How 的操作”。

比如在采用 RBAC 模型之前：

1
2
3
4
阿尔宙斯有访问时间线和空间分配的权限。
帝牙卢卡有访问时间线的权限。
帕路奇亚有空间分配的权限。
Kate 对它们什么权限都没有。

在采用 RBAC 模型之后：

1
2
3
4
5
6
7
阿尔宙斯是主管理员。
帝牙卢卡是时间管理员。
帕路奇亚是空间管理员。
Kate 是信任用户。
主管理员有访问所有东西的权限。
时间管理员有访问时间线的权限。
空间管理员有访问空间分配的权限。

发现复杂度从平方变成了线性，并且增加了一层容易理解的抽象。

RBAC0

这个东西由四个部分组成：用户 U、角色 R、会话 S 和权限 P。

  • 用户可以对应多个角色，角色可以对应多个权限。
  • 用户会和一些会话相联系，会话会激活角色。

静态关系：

  • \(PA \subseteq P \times R\)，角色 R 和权限 P 的关系。
  • \(UA \subseteq U \times R\)，用户 U 和角色 R 的关系。

动态关系：

  • 用户：\(S \to U\)，每个会话有一个用户。
  • 角色：\(S \to 2^R\)，会话所扮演的角色组合；此时需要 \(r\) 满足 \((user(s), r) \in UA\)。

因此某个会话所拥有的权限等于 \(\cup_{r \in roles(s)} \{p | (p, r) \in PA\}\)。

RBAC1

  • 角色间出现了继承关系。
  • 一般继承关系：不要出现环即可，角色间可以进行多继承。
  • 受限继承关系：继承关系是一棵树。

  • 角色 \(r_1 \geq r_2\) 代表所有属于 \(r_1\) 的角色也会属于 \(r_2\)；\(r_1\) 拥有所有 \(r_2\) 的权限；激活 \(r_1\) 也会激活 \(r_2\)。

  • \(RH \subseteq R \times R\)：一个偏序关系，记录像 \(r_1 \geq r_2\) 的关系。

  • 角色：\(S \to 2^R\)；此时需要 \(roles(s) \subseteq \{r | \exist r', r' \geq r \land (users(s), r') \in UA\}\)。

因此某个会话所拥有的权限等于 \(\cup_{r \in roles(s)} \{p | \exist r', r \geq r' \land (p, r') \in PA\}\)。

RBAC2

  • 出现了角色的互斥关系。互斥角色是指各自权限可以互相制约的两个角色。
  • 静态互斥：一个用户不能同时拥有两个互斥的角色。
  • 动态互斥：一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。
  • 出现了基数限制：比如某个角色最少/最多/必须得几个用户持有/激活等。

RBAC3

是 RBAC1 + RBAC2。

多用户激活和单用户激活

似乎单用户激活更好：

  • 可以通过创建新用户模拟多用户激活的权限。
  • 各种限制在多用户激活的时候判断会很难搞。
  • 更可以达成严格最小权限。
  • 更不容易出故障。