访问控制模型学习心得

最新推荐文章于 2024-09-01 10:48:41 发布

稻草。

最新推荐文章于 2024-09-01 10:48:41 发布

阅读量646

点赞数

文章标签：架构后端 sql 需求分析团队开发

本文链接：https://blog.csdn.net/weixin_43420186/article/details/131983257

版权

访问控制模型

基本要素

访问控制模型包括三个要素，即：

主体（Subject) 指主动对其它实体施加动作的实体
客体(Object) 是被动接受其他实体访问的实体
**控制策略(Policy)**为主体对客体的操作行为和约束条件

安全策略

主体、客体，控制策略三者需要满足的基本安全策略：

**最小特权原则：**给主体分配权限时要遵循权限最小化原则，最小特权原则的优点是最大限度地限制了主体实施授权行为，可以避免来自突发事件、错误和未授权用主体的危险。
**最小泄漏原则：**它是指主体执行任务时,按照主体所需要知道的信息最小化的原则分配给主体权利。也就是要保护敏感信息不要被无关人员知道，别人知道得越少越好。
**多级安全策略：**多级安全策略是指主体和客体间的数据流向和权限控制按照安全级别的绝密（TS）、秘密（S）、机密（C）、限制（RS）和无级别（U）五级来划分。多级安全策略的优点是避免敏感信息的扩散，只有安全级别比他高的主体才能够访问。

分类

UGO

“UGO”经常作为“User(Owner),Group,and Other”的缩写来使用，中文表示：“用户、组和其他”。
UGO是Linux中对于资源进行权限管理的访问模型。Linux中一切资源都是文件，每个文件都可以设置三种角色的访问权限（文件所有者，文件创建者所在组，其他人）。

文件的所有者
文件的所有者一般是创建该文件的用户，对该文件具有完全的权限。在一台允许多个用户访问的 Linux 主机上，可以通过文件的所有者来区分一个文件属于某个用户。当然，一个用户也无权查看或更改其它用户的文件。
文件所属的组
我们可以创建一个组，然后把需要合作的用户都添加都这个组中。在设置文件的访问权限时，允许这个组中的用户对该文件进行读取和修改。
其他人
在设置文件的访问权限时，允许其他人户对该文件进行读取和修改。

ACL(访问控制列表)

访问控制列表 ACL（Access Control List）是由一条或多条规则组成的集合。

简单来说就是，每个资源都配置有一个列表，这个列表记录哪些用户可以对这项资源进行操作。当系统试图访问这项资源的时候，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定这个用户是否有权限访问当前资源。

RBAC(基于角色的权限访问控制)

在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

基本概念

RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为Who、What、How的问题，Who、What、How构成了访问权限三元组。

Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege,正向授权与负向授权）。

RBAC的组成

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。
请添加图片描述

User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
Role（角色）：不同角色具有不同的权限
Permission（权限）：访问权限
用户-角色映射：用户和角色之间的映射关系
角色-权限映射：角色和权限之间的映射

他的核心逻辑为：

某用户是什么角色？
某角色具有什么权限？
通过角色的权限推导用户的权限

RBAC模型分类

基本模型RBAC0

RBAC0是基础，很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。

角色分层模型RBAC1

RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念。简单理解就是，给角色可以分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理。

角色限制模型RBAC2

RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

静态职责分离SSD
1. 互斥角色限制: 同一个用户在两个互斥角色中只能选择一个;
2. 基数限制:一个用户拥有的角色是有限的，一个角色拥有的权限也是有限的
3. 先决条件限制:用户想要获得更高级的角色，首先必须拥有低级角色
动态职责分离DSD
- 动态的限制用户及其拥有的角色:如一个用户可以拥有两个角色，但是运行时只能激活一个角色

统一模型RBAC3

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。

基于RBAC的延展—用户组

基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。

缺陷

**RBAC 的流行很重要很大程度上是贴近现实生活，方便大家理解与使用，对于管理人员来说，只是修改不同的 role 对应的权限而已。**RBAC 在很多时候是管用的。
比如我们的系统是面向销售公司或者学校这种组织架构很严整的地方，但是在复杂场景下，RBAC 渐渐就不够用了，它会产生很多虚无的 role 而且在管理和控制上更难。

一般来说，在 RBAC 中滥用 role 所带来的问题被称为 “role explosion”，跟“曹操”与“曹操小时候”这个笑话很类似，但的确我们的访问控制系统中存在很多这样的 role。

ABAC(基于属性的权限验证)

ABAC 基于属性的访问控制 (Attribute Based Access Control) 是一种灵活的授权模型。，限验证模式是用属性来标记资源权限的。
通过实体的属性、操作类型、相关的环境来控制是否有对操作对象的权限。

传统的 RBAC 与 ACL 等访问控制机制中，可以认为是 ABAC 的子集，对于 RBAC，只是我们的访问机制的实现只是基于属性 role 而已，ACL 则是基于属性是 identity 的 AC。

简单来说，对于 ABAC 我们判断一个用户是否能访问某项资源，是对其很多不同属性的计算而得到的。
例如：

P5（职级）的同学有OA系统的权限。
通过实体的职级这一属性来控制是否有OA系统的权限
P5（职级）的研发（职位）同学有公司Gitlab的权限
通过一组实体的属性（职级和职位）来控制对操作对象的权限
P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。
上述例子显然比之前两个更加复杂，除了判断实体的属性（职级和职位），还判断了当前的环境属性和操作属性

ACBC使用场景

ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或者RBAC也能满足需求。

在属性的组合比较多，需要更细粒度地划分角色的情况下。RBAC需要建立大量的角色。ABAC授权模型会更加灵活。

优点

Attribute 易于管理

我们可以很容易的为不同的用户设计 attribute。

细粒度授权支持

ABAC 能做到细粒度的授权管理。

在 policy 中，我们的准许访问的判断是可以写的很灵活的，我们甚至可以判断请求中的某个属性是否满足于一个正则表达式，或者字符串相等（这个很常见，特别是在使用 AWS IAM 做最小权限原则时），我们也可以使用逻辑与、逻辑或的关系自由组合很多不同的访问规则。你可以使用之前提到的 Specification Pattern 很轻松的实现灵活的 policy，解析 JSON 或者 XML 去动态的创建规则，而这些含有规则的 JSON 或 XML，则是可以被编程实现的（可编程的 policy 是动态的授权验权的前提）。

访问控制管理成本很低

ABAC 对系统管理员是友好的。管理员的管理对象会缩减到 policy，也就是只处理访问控制。在 RBAC 的时代，如果我需要实现细粒度的资源管理或者经常 subject 与 object 的对应关系经常变动，那么管理员难以操作的，也很容易出现问题，其中常常被采用的解决方案就是创建那些本不应该存在的 role。

动态的总体控制

Environment conditions 也能够提供统一的系统级别的控制，比如威胁等级或者按照区域划分安全级别，不同的区域使用 ABAC 时，可能环境上会有变化。
Environment conditions 可以提供“拉闸”这样的功能，而且它也是可以动态调整的。

ABAC与 RBAC的区别是什么？

RBAC（Role-Based Access Control）和ABAC（Attribute-Based Access Control）都是常见的权限模型，它们之间有以下区别：

基础原理不同： RBAC是基于角色的访问控制，根据用户的角色来分配权限；而ABAC是基于属性的访问控制，根据用户的属性来分配权限。
应用场景不同： RBAC更适用于大型组织的权限管理，可以简化权限管理流程；而ABAC更适用于动态权限分配的场景，可以灵活地控制用户的访问权限。
实现方式不同： RBAC的实现方式比较简单；而ABAC的实现方式比较复杂

**对于哪种权限模型更好，这取决于具体的应用场景和需求。**RBAC模型更适用于大型组织的权限管理，可以简化权限管理流程；而ABAC模型更适用于动态权限分配的场景，可以灵活地控制用户的访问权限。

在选择权限模型时，应该根据具体的应用场景和需求来进行选择。如果需要简化权限管理流程，则可以使用RBAC模型；如果需要灵活地控制用户的访问权限，则可以使用ABAC模型。

DAC（自主访问控制）

自主访问控制模型（DAC，Discretionary Access Control）是根据自主访问控制策略建立的一种模型，允许合法用户以用户或用户组的身份访问策略规定的客体，同时阻止非授权用户访问客体。拥有客体权限的用户，可以将该客体的权限分配给其他用户。例如没有文件File1访问权限的用户可以从有访问权限的B用户那里得到访问权限。
自主访问控制机制允许对象的属主来制定针对该对象的保护策略。通常DAC通过授权列表（或访问控制列表）来限定哪些主体针对哪些客体可以执行什么操作。

每个主体拥有一个用户名并属于一个组或具有一个角色
每个客体都拥有一个限定主体对其访问权限的访问控制列表（ACL）
每次访问发生时都会基于访问控制列表检查用户标志以实现对其访问权限的控制。

强制访问控制和自主访问控制有时会结合使用。例如，系统可能首先执行强制访问控制来检查用户是否有权限访问一个文件组（这种保护是强制的，也就是说：这些策略不能被用户更改），然后再针对该组中的各个文件制定相关的访问控制列表（自主访问控制策略）

应用场景

DAC常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。在实现上，先对用户鉴权，然后根据控制列表决定用户能否访问资源。用户控制权限的修改通常由特权用户或者管理员组实现。DAC最大缺陷就是对权限控制比较分散，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大,无意间就可能泄露信息。

MAC(强制访问控制)

强制访问控制模型(MAC, Mandatory Access Control),是为了弥补DAC权限控制过于分散的问题而诞生的。

用来保护系统确定的对象，对此对象用户不能进行更改。也就是说，系统独立于用户行为强制执行访问控制，用户不能改变他们的安全级别或对象的安全属性。这样的访问控制规则通常对数据和用户按照安全等级划分标签，访问控制机制通过比较安全标签来确定的授予还是拒绝用户对资源的访问。强制访问控制进行了很强的等级划分，所以经常用于军事用途。

在强制访问控制系统中，所有主体（用户，进程）和客体（文件，数据）都被分配了安全标签，安全标签标识一个安全等级。

**Subject：**主体 (用户, 进程) 被分配一个安全等级
Object：客体 (文件, 数据) 也被分配一个安全等级
访问控制执行时对主体和客体的安全级别进行比较，这个判断通常有系统硬性限制
　　
用一个例子来说明强制访问控制规则的应用，如WEB服务以"秘密"的安全级别运行。假如WEB服务器被攻击，攻击者在目标系统中以"秘密"的安全级别进行操作，他将不能访问系统中安全级为"机密"及"高密"的数据。

资料来源

稻草。

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
访问控制模型学习心得

在 policy 中，我们的准许访问的判断是可以写的很灵活的，我们甚至可以判断请求中的某个属性是否满足于一个正则表达式，或者字符串相等（这个很常见，特别是在使用 AWS IAM 做最小权限原则时），我们也可以使用逻辑与、逻辑或的关系自由组合很多不同的访问规则。用户和角色，角色和权限都是多对多的关系。传统的 RBAC 与 ACL 等访问控制机制中，可以认为是 ABAC 的子集，对于 RBAC，只是我们的访问机制的实现只是基于属性 role 而已，ACL 则是基于属性是 identity 的 AC。
复制链接

扫一扫