访问控制模型浅析
前言
在一个系统之中,对于权限的把控以及用户的认证可以说是非常的重要。笔者在以前开发的系统中也接触到了各种的对用户访问的控制模型,偶然刷到大佬的文章,特记下此文来进行探讨。
认证与授权
认证
在一个系统中,尤其是企业系统中,对用户的认证很重要。在企业系统中,用户通常分为外部用户和内部用户。这两者的认证通常也不相同,
- 外部用户可能更多使用的手机号、微信等方式来进行登录。登录进入之后,直接使用企业提供的应用即可,提供的也通常是统一权限。
- 内部用户使用诸如企业微信、企业邮箱、域账号等方式来进行登录。因为企业内部通常有许多的内部系统,比如OA、hr等系统。所以每个员工可能拥有着不同系统的使用权,同时各个系统内部可能还拥有自己的权限,比如经典的管理员以及普通用户。
授权/访问控制
授权,也叫做访问控制,就是授予用户访问某个实体(资源,数据)的权限。因此一个好的访问控制模型就至关重要了。
访问控制模型
访问控制列表
ACL (Access Control Lists),访问控制列表。需要管理员为每个资源(客体)显式分配权限。
这是一种比较古老的权限控制机制,它是面向资源的访问控制模型。管理员为每个资源(客体)分配权限列表,这个列表里记录了用户/角色对于资源的操作权限,当需要访问这些资源时,会首先检查访问控制列表中是否存在当前用户/角色的访问权限,如果存在,允许相应的操作,否则就拒绝相应的操作。
优势:
- 实施简单
问题:
- 一旦要修改安全策略或者需要审计,就意味着需要遍历大量的资源;
- 应用开发者必须保证所有的资源在创建出来开始就有合适的保护措施。
基于角色的访问控制
RBAC (Role-Based Access Control),基于角色的访问控制。定义了一系列的角色与权限之间的关系。
基于角色的访问控制,应用特别广泛。它是防止权限泛滥,实现最小特权原则的经典解决方案。RBAC 将用户按角色分类,通过用户的角色来确定用户对某项资源是否具备操作权限,它简化了用户与权限的管理,将用户与角色关联,角色与权限关联,然后权限与资源关联。
RBAC三要素:
- 用户:系统使用者对应的用户
- 角色:一组权限的集合(如:管理员,普通用户等)
- 权限:菜单,按钮,数据的增删改查等详细权限
在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。角色是为了分配多种权限而创建的,用户则依据它的责任和资格来被分配相应的角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
优势:
- 比 ACL 更具扩展性
- 在粗粒度的访问控制中工作得特别好 比如这样的场景:拥有经理角色的用户可以批准采购单。
问题:
- 随着组织的演进,往往出现角色爆炸的现象; 比如在一开始,一个销售的角色可以访问客户记录,这很合理。随着组织的扩张,开始组建按地域划分的销售团队,于是对客户记录的访问也需要按照地域来进行限制,这就导致系统中分别增加了美洲区的销售角色和亚太区的销售角色。
- 当管理员更新用户的权限时,需要大量的手工操作;
- 做不到细粒度的访问控制; 比如这样的场景就做不到:经理只能批准其部门产生的采购单。 为了解决这种场景下的问题,应用开发者需要在应用里写额外的代码来做相应的检查,这导致了一个访问控制被分别定义在了两个不同的地方。从而导致了
- 安全管理成本变高
- 合规和审计变得困难
- 安全策略缺少单一视图
- 资源与角色紧藕合,改一个角色会影响多个资源
基于分组的访问控制
GBAC (Group-Based Access Control),基于分组的访问控制。可以维护具有层级关系的群组权限。
基于群组的访问控制机制。看上去和 RBAC 很像,但是 GBAC 可以用来对一个或多个具有层级关系的群组来定义访问资源的权限。它允许将某个群组的访问权限继承到其下级群组中,当然,也可以选择不去继承。
优势:
- 适用于有组织结构的系统
问题:
- 同RBAC
- 如果组织结构维护在多个系统,容易造成组织结构维护困难
自主访问控制
DAC (Discretionary Access Control),自主访问控制。让资源(客体)所有者来定义访问控制规则。
自主访问控制,让客体(资源)的所有者来定义访问控制规则。它是 Trusted Computer System Evaluation Criteria (TCSEC)定义的和一种访问控制机制,在 DAC 中,系统会根据被操作对象的权限控制列表中的信息,来决定当前用户能够对其进行哪些操作,用户可以将其具备权限直接或者间接授予其他用户(类似于网盘的分享,将文件的获取权限传递)。
优势:
- 灵活
- 维护成本低
- 降低了管理员的工作难度
问题:
- 增强了整体访问控制监管的难度
- 安全性没有保证,完全取决于所有者的个人安全意识
强制访控制
MAC (Mandatory Access Control),强制访问控制。基于安全级别标签的访问控制策略,其安全性最高。
强制访问控制,通过定义安全级别标签来进行访问控制,也叫非自主访问控制,它可以限制主体对资源(客体)执行某种操作。它的安全策略由安全策略管理员集中控制,用户无权覆盖策略。比如为了保证机密性,MAC 不允许低级别的主体读取高级别的客体、不允许高级别的主体写入低级别的客体;为了保证完整性,MAC 不允许高级别的主体读取低级别的客体,不允许低级别的主体写入高级别的客体。一般普通公司不会采取 MAC,除非有相应的合规要求。
优势:
- 相当的安全
问题:
- 对实施要求很高
- 需要对所有数据进行标记
基于声明的访问控制
Claims as Permissions,基于声明的访问控制。很多企业或组织都在某种形式上使用了这种机制。
基于声明式的权限管理,以声明的方式赋予用户指定的权限。这常常和 RBAC 结合使用,以弥补 RBAC 在细粒度的访问控制中的不足(给RBAC的权限管理打补丁)。
优势:
- 自由度高
问题:
- 难以审计
- 难以验证正常的人拥有正确的权限
- 需要重新变动人员组织和责任时,需要手动流程
- 管理员倾向于添加越来越多的权限,但很少移除它们
- 决策数据定义在安全系统中,又被复制到其他的系统中,容易导致不一致发生
- 对于采用了 OAuth 或者 OpenID 单点登录的方案,在用户的令牌中携带全量用户权限,容易出现体积非常大的访问令牌
- 在用户身份声明中携带权限信息,导致认证和授权含混在一起
基于属性的访问控制策略
ABAC (Attribute-Based Access Control policy),基于属性的访问控制策略。
它是基于属性的访问控制,有时也被称为 PBAC (Policy-Based Access Control)。它不给用户直接赋予访问权限,而是通过执行一系列的布尔规则来为资源授权(动态计算一个或者一组属性是否满足某一条件来进行授权)。ABAC 中一般来说包含用户属性、环境属性、操作属性以及资源属性。
- Subject (访问实体)
- 人员,真实员工访问,匹配的可能是员工的工号、隶属的部门,职级等
- 非人类,例如自动运行的程序,甚至是智能机器人访问,匹配的可能是程序ID,机器人编号等
- Object(访问的目标资源)
- 文件
- 机器或者设备
- 数据库
- 等等
- Operation(要进行的操作)
- Read
- Write
- Delete
- So on
- Environment Conditions(环境条件)
- 访问时间
- 访问位置(网络地址、物理地址等)
- 风险等级(类比于本地的是否安全)
- 等等
- Policy(实行的策略)
优势:
- 能够地从组织内部自然获取到的信息来做访问控制决策
- 没有额外的管理成本
- 可以在不需要部署应用的情况下更改这个决策
- 所有的利益相关者都能阅读
- 易于审计
问题:
- 比较复杂
- 实施难度较大
RBAC和ABAC比较
ACL和RBAC可以说是最常用的访问控制模型了,企业内部系统更多使用的是RBAC。在此比较一下传统的RBAC和较为新颖的ABAC模型。
ABAC的优势:
- 对于大型组织,基于RBAC的控制模型需要维护大量的角色和授权关系,相比而言,ABAC更加灵活;
- 新增资源时,ABAC仅需要维护较少的资源,而RBAC需要维护所有相关的角色,ABAC可扩展性更强、更方便。
- ABAC支持带有动态参数的授权规则,RBAC只能基于静态的参数进行判断。
- ABAC权限控制的粒度比RBAC更细。
RBAC的优势:
- 对于中小型组织,维护角色和授权关系的工作量不大,反而定制各种策略相对麻烦,更容易接受RBAC授权模型。
参考
本文参考:




