由于物联网、BYOD、云和 SaaS 等技术的发展和广泛采用，访问控制概念的根本改变变得非常必要。原因很明显。
虽然旧的访问控制方法旨在满足集中管理所有用户的企业的授权需求，但当今的 IT 现实要求公司处理他们不管理身份的用户，并在不断变化和分布的情况下保护数字资产环境。
著名程序员 Alan Perlis 曾经说过：“简单不先于复杂，而是跟随它。” 在访问控制的背景下，他的话是正确的。随着企业采用新技术并将越来越多的资源转移到云端——NGAC，专为基于云的分布式部署而设计——简化了访问控制并应对当今无边界网络的安全挑战。
下一代访问控制(NGAC)是对传统访问控制的重新发明，以适应现代、分布式、互联企业的需求。NGAC的设计是可扩展的，支持广泛的访问控制策略，同时执行不同类型的策略，为不同类型的资源提供访问控制服务，并在面对变化时保持可管理。NGAC遵循一种基于属性的构造，其中特征或属性用于控制对资源的访问，并描述和管理策略。
1、ACL（Access-Control List，访问控制列表）
Subject：主体，访问方，可以是人也可以是系统、设备等
Action：访问的具体动作，如 Create、Read、Edit...
Object：客体，被访问方，可以是系统中的某个条目、某个文件等
一种比较基础的权限管控机制，简单直接，常应用于操作系统中的文件系统。
2、MAC（Mandatory Access Control，强制访问控制）
Subject：主体，访问方，可以是人也可以是系统、设备等
Action：访问的具体动作，如 Create、Read、Edit...
Object：客体，被访问方，可以是系统中的某个条目、某个文件等
Attributes：在 Subject 和 Object 上均可能有多个 Attributes ，用于鉴权判断的元数据
主体和客体会被分别赋予一个机密等级，访问时双向检查主体和客体的等级是否匹配，常被应用于安全要求性高的领域，如军事、金融、政府、计算机系统安全等，双向鉴权时遵循 authorization rule，该 rule 的存储位置和管理通常非常严格。
3、DAC（Discretionary Access Control，自主访问控制）
Subject：主体，访问方，可以是人也可以是系统、设备等
Action：访问的具体动作，如 Create、Read、Edit...
Object：客体，被访问方，可以是系统中的某个条目、某个文件等
Grant：转授权行为，Subject 1 可对 Object 执行的全部或部分 Action 转授给 Subject 2
自主访问控制简单理解是权限 Subject 可将自己拥有的权限转移给其他主体，通常是为了解决权限分配灵活度的问题，但是在 B 端系统里往往不会仅仅采用 DAC 这一种权限模型（比如会结合 MAC 模型），因为该模型会导致管理员无法掌控的权限扩散。
4、RBAC（Role Based Access Control，角色访问控制）
RBAC 认为权限的本质是 Who 对 What 进行了 How 操作
User：主体，访问方，代表系统中的用户，但也可以是机器、网络等 - Who
Object：客体，被访问方，可以是系统中的某个菜单、按钮、数据记录、API 等 - What
Operation：系统中用户可执行的某个动作 - How
Permissions：权限，代表可向 RBAC 保护下的 Object 执行 Operation （What + How）
Role：角色，代表组织内一些职责及该职责下的用户拥有某些指定的权限
Session：会话，会话由一个用户触发，同时会话激活会话关联的一个或多个 Role
本文重点介绍被 INCITS（国际信息技术标准委员会） 采纳的标准 RBAC 模型
标准 RBAC 分为 4 个子模型：
RBAC0 - Core RBAC - 只有基本角色，无继承和职责
RBAC1 - Hierarchical RBAC-支持继承
一般继承：角色之间的是一个绝对偏序的继承关系（有向无环，成环的角色继承无意义），这个设计比单一的树状继承更自由，适用于角色权限有继承需求但又不是严格的上下层级关系的权限场景。
RBAC2 - Constrained RBAC - 支持职责
RBAC3 = RBAC 1 + RBAC 2
RBAC3 是 RBAC1 和 RBAC2 的合集，既包含了角色继承也包含了相关约束。
优点：能力最强大。
缺点：4 种模型中最复杂的模型，管理成本较高。
总体上，RBAC 被认为满足了三个重要权限原则：
- 最小权限：用户仅在触发会话动作时获取到其所在角色，该角色定义了完成该动作所需的最小权限。
- 权限抽象：可结合业务抽象出具体的权限行为，如发表评论、上传附件，而不是简单的 读、写、查。
- 职责分离：角色本身表征了职责，加上 RBAC 支持角色和角色间的互斥机制，实现高风险动作分治。
对标准 RBAC 的扩展：
- 面向单个用户授权时的管理成本：可以跳过 Role 直接对用户授权
- 面向大批量用户授权时的管理成本：Group 也可以被分配到 Role 中
- 面向维护 Role 的管理成本：用户在 Role 中可进行权限裁剪（代表这个用户仅拥有这个 Role 的部分权限）、可复制 Role 等等
- 和其他权限模型的结合：和 DAC 、MAC 的结合，和 ABAC 的结合
1、ABAC概念
从实施访问控制时所使用的属性来看，ACL和RBAC可以看做是ABAC的特例。ACL使用“身份标识”的属性。RBAC使用“角色”属性。它们之间的关键区别在于ABAC的策略概念，ABAC的策略可以表示为针对多种不同属性的复杂的布尔运算。虽然可以使用ACL或RBAC来实现ABAC的策略目标，但是由于ABAC访问控制的需求与ACL和RBAC模型之间的抽象层次不同，这种实现方式执行起来非常困难，而且代价非常大。ACL或RBAC模型的另一个问题是，如果AC需求发生了变化，可能很难确定所有需要更新的数据在ACL或RBAC实现中的位置。
一般来说，在主体发出请求之前，ABAC避免将权限（“操作-客体”对）直接分配给主体/角色/组。相反，当主体请求访问时，ABAC引擎根据请求者的指派属性、客体的指派属性、环境条件以及根据这些属性和条件指定的一组策略，来做出访问控制决策。根据这种设计，策略在创建和管理时无需直接引用过多的用户和客体，用户和客体也不会直接引用策略。
2、ABAC元素
Subject：主体，访问方，代表系统中的用户，但也可以是机器、网络等
Object：客体，被访问方，可以是系统中的某个文件、设备、数据库记录等
Operation：系统中主体对客体请求执行的功能/行为，可包括 read、write、edit、delete 等
Attributes：属性，Subject、Object、Operation 和 Environment Condition 都有属性，属性是一对键值
Policy：一系列由属性和属性值构成的规则或关系，通过该规则/关系可判断一个访问能否被允许
Environment Conditions：可被识别的环境条件，访问行为发生的环境，通常可以是时间、地点、IP、设备、操作系统、风险级别等
ABAC 是建立在 Subject 属性、Object 属性、环境属性及访问 Policy 之上的细粒度权限管控，ABAC 能做到只有符合特定属性的 Subject 在特定条件下可以对符合特定属性的 Object 执行某权限行为。
对比：
ABAC与NGAC都是基于策略控制权限，差异在于：
1）ABAC的策略是即时计算，每次请求都会获取属性计算是否允许访问。
2）NGAC基于控制图和容器化进行派生特权，会将大部分计算量提前完成，提高用户访问效率。
更多精彩内容，下期继续更新。
道一云七巧-与你在技术领域共同成长
更多技术知识分享：https://bbs.qiqiao668.com/
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/4036.html