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

参考资料与拓展阅读

发布于码厩技术博客的所有文章，除注明转载外，均为作者原创，欢迎转载，但必须注明出处。
尊重他人劳动，共创开源社区！转载请注明以下信息：
转载来源： 码厩技术博客 []
原文标题：访问控制
原文地址：
知识共享许可协议