[https://www.jianshu.com/p/2a07763bc81f](https://www.jianshu.com/p/2a07763bc81f) [http://www.woshipm.com/pd/2310691.html/comment-page-1](http://www.woshipm.com/pd/2310691.html/comment-page-1)  ##### 权限一句话来理解就是对资源的控制，对web应用来说就是对url的控制 权限系统理解透彻了很简单的，就是**用户和资源**！你的页面也好，输入框或者按钮也罢，甚至列表里面的一行或一列，都可以理解为资源。然后，不就是A可以访问某个页面而B不可以，C可以录入数据而D只能看么？所以说： **权限就是用户使用资源的规则** 在这个规则里面，根本性的数据只有用户和资源，但因为用户太多，不方便授权操作，所以引入了角色、用户组、组织机构等等。通过角色进行授权，又通过用户组、职位这些关联用户可以大大减少具体的授权操作工作量。所以一个完善的权限系统，是必然要包含这些的。 ***** 编辑、查看、审核、删除 、添加、数据管理、权限管理 ACL, DAC, MAC, RBAC, ABAC模型的不同应用场景 ### **ACL 访问控制列表**  >[info] 规定**资源**可以被哪些**主体**进行哪些**操作** `ACL`是`Access Control List`的缩写，称为访问控制列表. 定义了谁（用户）可以对某个数据进行何种操作（权限）. 关键数据模型有: 用户, 权限. ACL规则简单, 也带来一些问题: 资源的权限需要在用户间切换的成本极大; 用户数或资源的数量增长, 都会加剧规则维护成本; #### 典型应用 1. 文件系统 文件系统的文件或文件夹定义某个账号(user)或某个群组(group)对文件(夹)的读(read)/写(write)/执行(execute)权限.  2. 网络访问 防火墙: 服务器限制不允许指定机器访问其指定端口, 或允许特定指定服务器访问其指定几个端口. 3. 场景：部门隔离 适用资源：客户页面、人事页面 在ACL权限模型下，权限管理是围绕**资源**来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下： ~~~ ACL配置表 资源: 客户页面 主体: 销售部（组） 操作：增删改查 主体: 王总（用户） 操作: 增删改查 资源: 人事页面 主体: 王总（组） 操作: 增删改查 ~~~ 注：主体可以是用户，也可以是组。 在维护性上，一般在粗粒度和相对静态的情况下，比较容易维护。 在细粒度情况下，比如将不同的客户视为不同的资源，1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的，那么就要对每种资源做相同的操作；如果权限配置是无规律的，那么ACL不妨也是一种恰当的解决方案。 在动态情况下，权限经常变动，每添加一名员工，都需要配置所有他需要访问的资源，这在频繁变动的大型系统里，也是很难维护的。 在一些情况下，ACL也可应用于细粒度场景，接下来将介绍两种ACL的拓展。 * * * ### **DAC 自主访问控制** >[info] 规定**资源**可以被哪些**主体**进行哪些**操作** > 同时，**主体**可以将**资源**、**操作**的权限，授予其他**主体** 场景：文件系统 适用资源：人事培训文档 DAC是ACL的一种实现，强调灵活性。纯粹的ACL，权限由中心管理员统一分配，缺乏灵活性。为了加强灵活性，在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，**可以自主地将权限授予其他用户**。 比如，在纯粹ACL模型下，每次新人培训，人事总监都要通知IT部，将培训文档的访问权限授予新人。在DAC模型下，人事总监只需将文档的访问权限授予人事专员。之后，每次新人培训，由人事专员将文档的访问权限授予不同的新人。 * * * ### **MAC 强制访问控制** >[info] a. 规定**资源**可以被哪些**类别的主体**进行哪些**操作** > b. 规定**主体**可以对哪些**等级的资源**进行哪些**操作** > 当一个操作，同时满足a与b时，允许操作。  场景：保密系统 适用资源：机密档案 MAC是ACL的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。比如，等级分为：秘密级、机密级、绝密级；类别分为：军事人员、财务人员、行政人员。 比如，一份机密级的财务档案，可以确保只有主体的等级是机密级，且是财务人员才能访问。如果是机密级的行政人员就无法访问。 ~~~text 资源配置表 资源: 财务文档 主体: 财务人员 等级：机密级 操作：查看 主体配置表 主体: 李女士 类别: 财务人员 等级：机密级 ~~~ 所以，MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。 * * * ### **RBAC 基于角色的访问控制** `RBAC`是`Role-based access control`的缩写, 称为 基于角色的访问控制. 核心数据模型有: 用户, 角色, 权限. * 权限：规定**角色**可以对哪些**资源**进行哪些**操作** * 角色：规定**主体**拥有哪些**角色**，一个角色，可拥有多个权限 * 账户：成员用账户登陆管理后台，账户对应角色 如果层级比较深，业务线条多，可以增加‘部门’，用以抽象角色，方便更高效配置。比如销售部门下，有助理和经理两个角色，他们拥有销售部共同的权限，也拥有各自角色不同权限，助理只能看到自己的销售额，经理可以看到部门销售总额。 用户具有角色, 而角色具有权限, 从而表达用户具有权限. 由于有角色作为中间纽带, 当新增用户时, 只需要为用户赋予角色, 用户即获得角色所包含的所有权限. ## 权限有哪些 模型中权限这个元素，按颗粒度从大到小，可以分为： * 导航：由路由控制，是否可以访问一组页面 * 页面：是否可以访问某个页面 * 操作：访问某个页面时，按钮是否可以见，可否增删改查 * 字段：页面中某个字段是否可见、是否可编辑 导航权限最好实现，适用简单管理后台上线初期，协作者少的项目。比如电商业务开始只有商品和客服两组人，商品要管理品类、上传编辑商品、发起折扣；客户要回复留言、查看购买记录。如此组织，可将‘商品模块’和‘客服模块’的权限以导航组织，一级导航下整组页面，所有数据可见，所有操作可执行。只是和开发商量好，设计数据结构和逻辑规则时考虑扩展性，准备好未来细化到操作甚至字段级别的颗粒度。 操作级别的权限，如果技术是微服务架构，可以做成以url控制操作。比如按钮点击时，访问url，不同权限，可访问不同url；未授权时点击按钮操作无效。若希望按钮完全不可见，需要前端增加判断。 字段级别，是最精细的权限控制。比如电销人员浏览客户信息时，电话号码不可见，客服人员看到客户销售订单时，销售金额不可见；权限设计时，需要隐藏页面上相应字段。 ## 任意组合权限，给谁？ 上述这些不同颗粒度权限，相互组合之后，分配给不同角色。比如电商中，创建以一个角色‘商品运营’，这个角色拥有权限可以这样描述：可以访问和编辑‘商品’一级导航下所有页面。因为业务线上不止一个员工，‘商品运营’这个角色，可以有多个人承担；在这些员工自己账号下，分配‘商品运营’角色。 用角色作为权限和账号的中介，最大好处在一次批量配置，不用每个账号单独配置。 ## 界面怎么画？ 如果只要导航级别权限，其实只需要两个页面。一个角色页面，一个账户页面。角色页面主体是角色列表，可新建角色，新建时勾选权限。账户页面主体是账户列表，可新建账户，新建时选择账户对应的角色。 更多具体细节，可以看SAAS产品的帮助文档，因为是给客户用的，文档会有教科书级别的页面和描述，比如某CRM产品权限模块使用说明： > 如果员工没有某对象“查看列表”的权限，则该对象的功能入口会被隐藏 如果员工没有某对象的操作点权限，则在对象页面上隐藏相应操作按钮 如果员工没有某对象的指定字段的可见权限，则在对象页面上隐藏相应字段 `RBAC`存在多个扩展版本, `RBAC0`、`RBAC1`、`RBAC2`、`RBAC3`。这些版本的详细说明可以参数[这里](https://www.jianshu.com/p/b078abe9534f)。我们在实际项目中经常使用的是`RBAC1`，即带有角色继承概念的RBAC模型。 RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。 #### **1）RBAC0** RBAC0，它是RBAC0的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。RBAC0定义了能构成RBAC控制系统的最小的元素集合，RBAC0由四部分构成： * a、用户（User） * b、角色（Role） * c、会话（Session） * d、许可（Pemission）,其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。 ##### 如图，用户与角色是多对多的关系；角色和许可也是多对多的关系；用户与会话是一对一关系；会话与角色是一对多关系；  #### **2）RBAC1** RBAC1，它是RBAC角色的分层模型，RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对[偏序关系](https://link.jianshu.com?t=http://baike.baidu.com/view/1469650.htm)，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。 这种模型合适于角色之间的层次明确，包含明确。  #### **3）RBAC2** RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。 ##### SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束: * a、互斥角色：同一个用户在两个互斥角色中只能选择一个 * b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的 * c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色 ##### DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。  #### **4）RBAC3** RBAC3，它是RBAC1与RBAC2合集，所以RBAC3是既有角色分层又有约束的一种模型  场景：企业数据 适用资源：客户信息 RBAC的思想，来源于现实世界的企业结构。比如，销售角色，拥有查看客户信息的权限。当一个销售人员小王入职了，可以把销售角色赋予小王，那么小王就拥有了查看客户的权限。这种方式，避免了ACL模型下，每次新人入职，需要逐个配置资源表的情况。同样，权限变动也变得很方便，只要修改角色，即可实现多用户的权限修改。 **权限表** ~~~ 名称：创建客户 资源: 客户信息 操作：创建 名称：删除客户 资源: 客户信息 操作：删除 名称：查看客户 资源: 客户信息 操作：查看 名称：修改客户 资源: 客户信息 操作：修改 ~~~ **角色表** ~~~ 名称：销售角色 权限: 创建客户、删除客户、查看客户、修改客户 ~~~ **用户表** ~~~ 主体：小王 角色: 销售角色 ~~~ RABC并不总能满足所有权限的场景。比如，我们无法对销售角色，进行个体定制。比如，销售角色拥有创建、删除的权限。如果我们要对销售小李，去掉删除的权限。那么，我们就必须创建另一个角色，来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。 角色和组两个概念可能会让人混淆，在这里做个区分： * 角色赋予的是主体，主体可以是用户，也可以是组 * 角色是权限的集合 * 组是用户的集合 * * * ### **ABAC 基于属性的访问控制** >[info] 规定哪些**属性的主体**可以对哪些**属性的资源**在哪些**属性的情况**下进行哪些**操作**， `ABAC`是`Attribute-based access control`的缩写, 称为基于属性的访问控制. 权限和资源当时的状态(属性)有关, 属性的值可以用于正向判断(符合某种条件则通过), 也可以用于反向判断(符合某种条件则拒绝): #### 典型应用 1. 论坛的评论权限, 当帖子是锁定状态时, 则不再允许继续评论; 2. Github 私有仓库不允许其他人访问; 3. 发帖者可以编辑/删除评论(如果是RBAC, 会为发帖者定义一个角色, 但是每个帖子都要新增一条用户/发帖角色的记录); 4. 微信聊天消息超过2分钟则不再允许撤回; 5. 12306 只有实名认证后的账号才能购票; 6. 已过期的付费账号将不再允许使用付费功能; 场景：防火墙 适用资源：端口访问 ABAC其中的属性就是与主体、资源、情况相关的所有信息。 * 主体的属性：指的是与主体相关的所有信息，包括主体的年龄、性别、职位等。 * 资源的属性：指的是与资源相关的所有信息，包括资源的创建时间、创建位置、密级等。 * 情况的属性：指的是客观情况的属性，比如当前的时间、当前的位置、当前的场景（普通状态、紧急状态）。 * 操作：含义还是一样，比如增删改查等。 设定一个权限，就是定义一条含有四类属性信息的策略（Policy）。 ~~~css 策略表 效果：允许 操作：流入 主体：来自上海IP的客户端 资源：所有以33开头的端口（如3306） 情况：在北京时间 9:00~18:00 效果：禁止 操作：流出 主体：任何 资源：任何 情况：任何 ~~~ 一个请求会逐条匹配策略，如果没有匹配到策略，则返回默认效果，默认效果可以根据场景定制，可以是默认拒绝或是默认允许。另外，匹配方式也可以根据场景定制，可以使用**逐条顺序匹配**，匹配到策略直接返回。也可以使用**完全匹配**，匹配所有的策略，如果有一个拒绝（允许），则拒绝（允许）。 阿里云的RAM访问控制运用的就是ABAC模型： ~~~bash 阿里云RAM策略配置表 { "Version": "1", "Statement": [{ "Effect": "Allow", "Action": ["oss:List*", "oss:Get*"], "Resource": ["acs:oss:*:*:samplebucket", "acs:oss:*:*:samplebucket/*"], "Condition": { "IpAddress": { "acs:SourceIp": "42.160.1.0" } } }] } ~~~ ABAC可以发挥权限系统最大的灵活性，但在灵活的同时，如果不对策略加以管理，也有可维护性的问题。