权限管理系统
权限的抽象
分权分域
权限访问控制模型
UGO（User、Group、Other）
ACL（访问控制列表）
DAC（自主访问控制）
MAC（强制访问控制）
RBAC（基于角色的访问控制）
ABAC（基于属性的权限验证）
权限管理系统
ToB 产品的权限管理系统是一个非常重要的组成部分，没有权限管理的系统仿佛一个没有门的房子，任何人都可以随意查看甚至调整，对系统的安全性存在非常大的隐患。
权限管理，即：根据系统设置的安全规则（Rule）或策略（Policy），用户可以且只能访问自己被授权的资源。权限管理是任何系统的标配模块，它的作用不仅在于保护系统数据的安全性、防止留下系统漏洞，更能在庞大的系统下进行模块和数据配置，让不同的角色进入系统看到不同的模块和数据，最大程度地提高系统的易用性。
权限的抽象
权限到底是名词属性？还是动词属性？还是名词、动词属性均包含？这对定义权限的含义很重要。如果是名词属性的话，那么它应该是有具体的指代物；如果是动词，则应该具有行为表示。
权限的名词属性的指代物：API、页面、功能点。
权限的动词属性的指代物：可操作、不可操作。
普遍的，权限是同时具有名词、动词属性的，它表达了两层含义。即：限制指定对象的操作。向上引申可将权限划分为 3 个组成部分：
页面权限：用户可以看到那些页面；
操作权限：用户可以在页面内进行那些操作，增删改查等；
数据权限：用户可以看到那些数据或内容；
分权分域
分权分域，是权限管理系统所能实现的效果之一，简单来说就是两点：
（分权）定制用户权限，不同的用户登录系统后的界面不同，所能进行的操作也不同。
（分域）控制用户权限，防止越权访问和跨域访问。
权限访问控制模型
权限访问控制的本质就是询问这么一个问题：“某个用户，对某个资源，是否可以进行某种操作？”
UGO（User、Group、Other）
UGO 是 Linux 对文件对象进行权限管理的访问控制模型，Linux 中一切资源都是文件，每个文件都可以设置三种角色的访问权限（文件创建者，文件创建者所在组，其他人）。
UGO 模型的缺点很明显，就是只能为一类用户设置权限，如果这类用户中有特殊的某一个人，那么它无能为力了。
ACL（访问控制列表）
ACL 的原理是，每个资源都配置有一个列表，这个列表记录哪些用户可以对这项资源进行 CRUD 操作。当系统试图访问这项资源的时候，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定这个用户是否有权限访问当前资源。
Linux 在 UGO 之外，也增加了 ACL 模型，可以使用 getfacl、setfacl 指令来对某个资源设置增加某个人、某个组的权限列表。操作系统会根据这个权限列表进行判断，当前用户是否有权限操作这个资源。
DAC（自主访问控制）
ACL 模式存在一个问题：谁可以为资源增加访问控制权限？常见的办法就是增加一个 Super Admin 来做统一的操作。还有一种办法，由某个权限的用户来负责给其他用户分配权限。这个就叫做自主访问控制。Windows 操作系统的 Administer 就是 DAC 模型。
系统首先会识别用户，然后根据被操作对象的 ACL（Access Control List，权限控制列表）或者 ACM（Access Control Matrix，权限控制矩阵）的信息来决定用户的是否能对其进行哪些操作，例如：读取或修改。而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为 “自主（Discretionary）” 控制。
DAC 最大缺陷就是所有用户的权限不能统一管理，用户和用户的权限比较分散，后期调整只能单个进行调整，不易维护。
MAC（强制访问控制）
MAC 和 DAC 模型相反，它不将某些权限下放给用户，而是在更高维度（比如操作系统）上将所有的用户设置某些策略，这些策略是需要所有用户强制执行的。这种访问控制也是基于某些安全因素考虑。
在 MAC 的模型中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制且无法回避的。强制访问控制多应用于对安全性要求比较高的系统，如：多级安全军事系统；
RBAC（基于角色的访问控制）
1996年，莱威·桑度（Ravi Sandhu）等人在前人的理论基础上，提出以角色为基础的访问控制模型，故该模型又被称为 RBAC96。之后，美国国家标准局重新定义了以角色为基础的访问控制模型，并将之纳为一种标准，称之为 NIST RBAC。
RBAC（Role-based access control，以角色为基础的访问控制）是当前使用范围最广的一种权限设计模型。不同于 DAC 和 MAC 方式，后两者直接赋予使用者权限，而前者则是将权限赋予角色。RBAC 是一种更为中性且更具灵活性的访问控制技术。
RBAC 的特点是在用户和具体权限之间增加了一个角色。通过设置一个角色，比如管理员，然后将用户关联某个角色中，再将角色设置某个权限。用户和角色是多对多关系，角色和权限是多对多关系。所以一个用户是否有某个权限，根据用户属于哪些角色，再根据角色是否拥有某个权限来判断这个用户是否有某个权限。
如图所示，每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。
简单来说 RBAC 就是：用户关联角色，角色关联权限。并且在产品和数据设计层面，有更好的扩展性，可控制到任意的粒度。
标准的 RBAC 模型包括四个部件模型：
基本模型 RABC0：定义了完全支持 RBAC 概念的任何系统的最低需求。RBAC0 的模型中包括用户（U）、角色（R）和许可权（P）等 3 类实体集合，RABC0 是权限管理的核心部分，其他的版本都是建立在 RABC0 的基础上。
角色分级模型 RABC1：基于 RBAC0 模型，引入角色间的继承关系，即：角色之间上有了上下级关系。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承；而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种模型合适于角色之间的层次明确，包含明确。
角色限制模型 RABC2：引入了角色间的约束关系，约束概念有两种：
一种是 SSD（Static Separation of Duty，静态职责分离）：
a、互斥角色：同一个用户在两个互斥角色中只能选择一个。
b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的。
c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色。
一种是 DSD（Dynamic Separation of Duty，动态职责分离）：
可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
统一模型 RABC3：同时包含了 1 和 2 的特性，既有角色约束，又有角色继承，就是前面两种角色变种的集合。
通过对 RBAC 各部件的详细配置，RBAC 可以支持三个著名的安全原则：
最小权限原则：RBAC 可以将其角色配置成其完成任务所需要的最小的权限集。
责任分离原则：通过调用相互独立互斥的角色来共同完成敏感的任务来体现，例如：要求一个计帐员和财务管理员共参与同一过帐。
数据抽象原则：通过权限的抽象来体现，例如：财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。
ABAC（基于属性的权限验证）
ABAC（Attribute-based access control，基于属性的权限验证）通过动态计算一个或一组属性，来是否满足某种条件来进行授权判断（可以编写简单的逻辑），即：使用属性来标记资源的权限。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。该设计过于复杂，暂未参透。
Kubernetes 中就用到了这种方法，比如：某个资源有 Pod 属性，有 Namespace 属性，那么就可以这样设置：
# 用户 Bob 可以在命名空间 projectCaribou 中读取 Pod：
{
"apiVersion":"abac.authorization.kubernetes.io/v1beta1",
"kind":"Policy",
"spec":{
"user":"bob",
"namespace":"projectCaribou",
"resource":"pods",
"readonly":true
}
}
-----------------------------------
©著作权归作者所有：来自51CTO博客作者范桂飓51cto的原创作品，如需转载，请注明出处，否则将追究法律责任
权限管理系统的分权分域设计
https://blog.51cto.com/u_15301988/3227163