系统权限控制模型
简介
在业务系统开发过程中系统权限控制的设计是很重要的，尤其是大型的业务系统，一个好的权限控制设计可以为后面业务开发和需求迭代节省大量的成本。
目前流行的权限控制模型常见有一下几种：
- ACLs: access-control list
- RBAC: Role-Based access control
- ABAC: Attribute-Based Access Control
ACLs
这是一种比较常见的权限管理模型，在文件系统管理中常用到这种模型。它的经常由 {subject:action}的模式组成，例如一个文件node有以下的Acl：
{Alice:write; Bob:read}
可以很清晰的表示出赋予了 Alice 写权限和 Bob 读权限。
在文件系统（ Microsoft Windows NT，OpenVMS， Unix-like, and Mac OS X operating systems）中通常以一个list数据结构来存储 entires，每条 entrie中指定一个用户或者一个组对一个文件、程序、进程的访问权限，通常称之为 ACE。ACL通常存储在这些系统上文件的扩展属性中。
NFSv4 ACLs 和 POSIX.1e ACL 是两种常用的file acl 标准。大多数的Unix系统和Unix-like系统（eg.Linux since 2.5.46 or November 2002,[6] BSD, or Solaris）支持 POSIX.e ACL 标准。如AIX，FreeBSD，[7]从版本10.4（“老虎”）开始的Mac OS X或具有ZFS文件系统的Solaris [8]，均支持NFSv4 ACL。目前Linux 有两种实验性的NFsv4实现：一种是对ext3文件系统的支持，另一种是对ext4文件系统的支持-- Richacls。
ACL 算法已经被移植到了SQL 和 现代关系型数据库中 ， 许多的基于 SQL 开发的系统在其管理模块中使用了ACL模型，例如：企业资源计划和内容管理系统。
RBAC
基于角色的权限管理是在大型业务系统和企业管理系统中常用一种模型。它是一种围绕 role 和 privileges 设计的模型，它满足了政府和大型企业一些在行政管理上的要求，它既可以实现DAC(自由访问控制) 也可以实现 MAC(强制访问控制)。
将某些操作的权限绑定到 role，为 user 分配不同的 role，通过 role 来管理 权限，可以通过新建 role 和 更换 role 来进行权限分配。简化了权限管理的操作。
- S = Subject = A person or automated agent
- R = Role = Job function or title which defines an authority level
- P = Permissions = An approval of a mode of access to a resource
RBAC 系统设计时一般要遵循以下原则:
- role 分配：仅当 subject 已选择或分配了 role 时，subject 才能行使权限。
- role 授权：必须为一个 subject 赋予 active role。使用上面的规则1，此规则可确保用户只能承担授权的 role。
- permission 授权：仅当 subject 的 active role 被授权时，subject 才能行使权限。使用规则1和2，此规则可确保用户只能行使其被授权的权限。
也可以应用其他约束，并且可以在层次结构中组合角色，其中更高级别的角色将包含子角色拥有的权限。
- SE = Session = A mapping involving S, R and/or P
- SA = Subject Assignment
- PA = Permission Assignment
- RH = Partially ordered Role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
Role-permission access-control.jpg
- subject : role = m : n
- permission : role = m : n
- operation : permission = m : n
角色管理系统也存在一些问题，因为其管理的权限粒度不够细，只有与role 绑定才能生效，经常会造成 role 爆炸的问题。
Acl vs RBAC
rbac 的权限控制粒度要比acl大，因为RBAC系统将权限分配给具有组织意义的特定操作，而不是低级数据对象。比如acls可以指定谁写入和读取文件，但是不能指定 如何去修改文件。RBAC 可以限定某个操作比如：“买一个西瓜”，“增加一条消息日志”等。
分配执行特定操作的权限是有意义的，因为这些操作在应用程序中具有含义。事实证明，RBAC特别适合执行职责分离（SoD）要求，该要求可确保必须由两个或更多人员参与授权关键操作。分析了RBAC中SoD安全性的充要条件。
SoD的基本原则是，任何人都不能通过双重特权来破坏安全性。此外，任何人都不得担任对另一个同时担任的职务行使审计，控制或审查权限的职务。
然后，可以再次将“最小RBAC模型” RBACm与ACL机制ACLg(其中仅允许将组作为ACL中的条目)进行比较。 Barkley（1997）[19]表明RBACm和ACLg是等效的。
ABAC
基于attributes的权限管理，这些策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。又可以称为基于 polices的权限管理模型。
与传统的RBAC 相比，ABAC的主要区别在于表示复杂布尔规则集的策略的概念可以评估许多不同的属性。属性值可以设置值或原子值。集值属性包含多个原子值。例如角色和项目。原子值属性仅包含一个原子值。例如间隙和灵敏度。可以将属性与静态值进行比较，也可以将属性进行比较，从而实现基于关系的访问控制。
在Microsoft 中也被称为CBAC(claims-based access control ).实现ABAC的关键标准是XACML和ALFA（XACML）。
Attibutes
属性大致可以分为以下四类：
- Subject attributes: 描述用户尝试访问的属性，例如年龄，职务，部门，职位，职务...
- Action attributes：描述尝试执行的动作的属性，例如阅读，删除，查看，批准...
- Object attributes：描述正在访问的对象（或资源）的属性，例如对象类型（病历，银行帐户...），部门，分类或敏感性，位置...
- Contextual(environment) attributes：涉及访问控制场景的时间，位置或动态方面的属性
Police
策略是将属性汇总在一起以表示可能发生和不允许发生的情况的语句。 ABAC中的策略可以是授予或拒绝策略。策略也可以是本地策略或全局策略，并且可以以覆盖其他策略的方式编写。示例包括：
- 如果文档与用户位于同一部门，则用户可以查看该文档
- 如果用户是所有者并且文档处于草稿模式，则用户可以编辑文档
- 上午9点之前拒绝访问
ABAC的概念可以应用于技术堆栈和企业基础结构的任何级别。例如，ABAC可用于防火墙，服务器，应用程序，数据库和数据层。属性的使用带来了更多的上下文，可以评估任何访问请求的合法性，并告知授予或拒绝访问的决定。
评估ABAC解决方案时，一个重要的考虑因素是了解其潜在的性能开销及其对用户体验的影响。期望控件越精细，开销越大。
应用
ABAC 与 传统的RBAC 相比最大的区别就是可以将权限与资源关联起来，RBAC、DAC、MAC 这些访问控制模型是以用户为中心的，并不关心 subject 与 object 之间的关联关心，这种从属关系通常都是由开发人员在业务上实现。ABAC试图通过基于描述请求实体（用户），目标对象或资源，所需动作（查看，编辑，删除...）以及环境或上下文信息的属性定义访问控制来解决此问题。这就是为什么访问控制被称为基于属性的原因。
ABAC 可以用于以下场景：
- API and micro services security
- Application security
- Database security
- Data security
- File server security
- Big data security
实现
ABAC带有推荐的体系结构，如下所示：
- PEP或策略执行点：它负责保护您要对其应用ABAC的应用程序和数据。 PEP检查该请求并生成一个授权请求，然后将其发送到PDP。
- PDP或策略决策点是体系结构的核心。这是根据已配置的策略评估传入请求的部分。 PDP将返回“允许/拒绝”决定。 PDP也可以使用PIP来检索丢失的元数据
- PIP或策略信息点将PDP桥接到属性的外部来源，例如LDAP或数据库
