权限设计 · PHP学习

# 权限设计 <http://www.woshipm.com/pd/2310691.html/comment-page-1> ![](https://img.kancloud.cn/ac/ba/acbae65a1df7846634fcfbf88b0e3dc2_697x364.png) ##### 权限一句话来理解就是对资源的控制，对web应用来说就是对url的控制权限系统理解透彻了很简单的，就是**用户和资源**！你的页面也好，输入框或者按钮也罢，甚至列表里面的一行或一列，都可以理解为资源。然后，不就是A可以访问某个页面而B不可以，C可以录入数据而D只能看么？所以说： **权限就是用户使用资源的规则** 在这个规则里面，根本性的数据只有用户和资源，但因为用户太多，不方便授权操作，所以引入了角色、用户组、组织机构等等。通过角色进行授权，又通过用户组、职位这些关联用户可以大大减少具体的授权操作工作量。所以一个完善的权限系统，是必然要包含这些的。 - - - - - - 编辑、查看、审核、删除、添加、数据管理、权限管理 ACL, DAC, MAC, RBAC, ABAC模型的不同应用场景 ### **ACL 访问控制列表** ![](https://img.kancloud.cn/a4/fe/a4fefabc427862a2e14073353408c1fa_260x99.png) > 规定**资源**可以被哪些**主体**进行哪些**操作** `ACL`是`Access Control List`的缩写，称为访问控制列表. 定义了谁（用户）可以对某个数据进行何种操作（权限）. 关键数据模型有: 用户, 权限. ACL规则简单, 也带来一些问题: 资源的权限需要在用户间切换的成本极大; 用户数或资源的数量增长, 都会加剧规则维护成本; #### 典型应用 1. 文件系统文件系统的文件或文件夹定义某个账号(user)或某个群组(group)对文件(夹)的读(read)/写(write)/执行(execute)权限. ![](https://img.kancloud.cn/7c/49/7c49a238c7b4a47e9bfaace1c3af60d1_633x235.png) 2. 网络访问防火墙: 服务器限制不允许指定机器访问其指定端口, 或允许特定指定服务器访问其指定几个端口. 3. 场景：部门隔离适用资源：客户页面、人事页面在ACL权限模型下，权限管理是围绕**资源**来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下： ``` <pre class="calibre10">``` ACL配置表资源: 客户页面主体: 销售部（组）操作：增删改查主体: 王总（用户）操作: 增删改查资源: 人事页面主体: 王总（组）操作: 增删改查 ``` ``` 注：主体可以是用户，也可以是组。在维护性上，一般在粗粒度和相对静态的情况下，比较容易维护。在细粒度情况下，比如将不同的客户视为不同的资源，1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的，那么就要对每种资源做相同的操作；如果权限配置是无规律的，那么ACL不妨也是一种恰当的解决方案。在动态情况下，权限经常变动，每添加一名员工，都需要配置所有他需要访问的资源，这在频繁变动的大型系统里，也是很难维护的。在一些情况下，ACL也可应用于细粒度场景，接下来将介绍两种ACL的拓展。 - - - - - - ### **DAC 自主访问控制** > 规定**资源**可以被哪些**主体**进行哪些**操作** > 同时，**主体**可以将**资源**、**操作**的权限，授予其他**主体** 场景：文件系统适用资源：人事培训文档 DAC是ACL的一种实现，强调灵活性。纯粹的ACL，权限由中心管理员统一分配，缺乏灵活性。为了加强灵活性，在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，**可以自主地将权限授予其他用户**。比如，在纯粹ACL模型下，每次新人培训，人事总监都要通知IT部，将培训文档的访问权限授予新人。在DAC模型下，人事总监只需将文档的访问权限授予人事专员。之后，每次新人培训，由人事专员将文档的访问权限授予不同的新人。 - - - - - - ### **MAC 强制访问控制** > a. 规定**资源**可以被哪些**类别的主体**进行哪些**操作** > b. 规定**主体**可以对哪些**等级的资源**进行哪些**操作** > 当一个操作，同时满足a与b时，允许操作。 ![](https://img.kancloud.cn/a6/01/a601b404a92337cdb0d2d36b96e07400_704x489.png) 场景：保密系统适用资源：机密档案 MAC是ACL的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。比如，等级分为：秘密级、机密级、绝密级；类别分为：军事人员、财务人员、行政人员。比如，一份机密级的财务档案，可以确保只有主体的等级是机密级，且是财务人员才能访问。如果是机密级的行政人员就无法访问。 ``` <pre class="calibre10">``` 资源配置表资源: 财务文档主体: 财务人员等级：机密级操作：查看主体配置表主体: 李女士类别: 财务人员等级：机密级 ``` ``` 所以，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）,其中许可又包括“操作”和“控制对象”其中许可被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的许可。会话是动态的概念，用户必须通过会话才可以设置角色，是用户与激活的角色之间的映射关系。 ##### 如图，用户与角色是多对多的关系；角色和许可也是多对多的关系；用户与会话是一对一关系；会话与角色是一对多关系； ![](https://img.kancloud.cn/9f/58/9f58fa49821cded7316b6f190a9e487d_626x268.png) #### **2）RBAC1** RBAC1，它是RBAC角色的分层模型，RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对[偏序关系](https://link.jianshu.com?t=http://baike.baidu.com/view/1469650.htm)，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种模型合适于角色之间的层次明确，包含明确。 ![](https://img.kancloud.cn/7f/29/7f29b0c5dd1850563fca18f24bfea413_579x294.png) #### **3）RBAC2** RBAC2，它是RBAC的约束模型，RBAC2也是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。 ##### SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束: - a、互斥角色：同一个用户在两个互斥角色中只能选择一个 - b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的 - c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色 ##### DSD是会话和角色之间的约束，可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。 ![](https://img.kancloud.cn/72/2e/722e6f07ae5ddde9193a2a36b34c00d6_590x339.png) #### **4）RBAC3** RBAC3，它是RBAC1与RBAC2合集，所以RBAC3是既有角色分层又有约束的一种模型 ![](https://img.kancloud.cn/39/ef/39ef73b859bbce0e14360f08c25c9661_592x381.png) 场景：企业数据适用资源：客户信息 RBAC的思想，来源于现实世界的企业结构。比如，销售角色，拥有查看客户信息的权限。当一个销售人员小王入职了，可以把销售角色赋予小王，那么小王就拥有了查看客户的权限。这种方式，避免了ACL模型下，每次新人入职，需要逐个配置资源表的情况。同样，权限变动也变得很方便，只要修改角色，即可实现多用户的权限修改。 **权限表** ``` <pre class="calibre10">``` 名称：创建客户资源: 客户信息操作：创建名称：删除客户资源: 客户信息操作：删除名称：查看客户资源: 客户信息操作：查看名称：修改客户资源: 客户信息操作：修改 ``` ``` **角色表** ``` <pre class="calibre10">``` 名称：销售角色权限: 创建客户、删除客户、查看客户、修改客户 ``` ``` **用户表** ``` <pre class="calibre10">``` 主体：小王角色: 销售角色 ``` ``` RABC并不总能满足所有权限的场景。比如，我们无法对销售角色，进行个体定制。比如，销售角色拥有创建、删除的权限。如果我们要对销售小李，去掉删除的权限。那么，我们就必须创建另一个角色，来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。角色和组两个概念可能会让人混淆，在这里做个区分： - 角色赋予的是主体，主体可以是用户，也可以是组 - 角色是权限的集合 - 组是用户的集合 - - - - - - ### **ABAC 基于属性的访问控制** > 规定哪些**属性的主体**可以对哪些**属性的资源**在哪些**属性的情况**下进行哪些**操作**， `ABAC`是`Attribute-based access control`的缩写, 称为基于属性的访问控制. 权限和资源当时的状态(属性)有关, 属性的值可以用于正向判断(符合某种条件则通过), 也可以用于反向判断(符合某种条件则拒绝): #### 典型应用 1. 论坛的评论权限, 当帖子是锁定状态时, 则不再允许继续评论; 2. Github 私有仓库不允许其他人访问; 3. 发帖者可以编辑/删除评论(如果是RBAC, 会为发帖者定义一个角色, 但是每个帖子都要新增一条用户/发帖角色的记录); 4. 微信聊天消息超过2分钟则不再允许撤回; 5. 12306 只有实名认证后的账号才能购票; 6. 已过期的付费账号将不再允许使用付费功能; 场景：防火墙适用资源：端口访问 ABAC其中的属性就是与主体、资源、情况相关的所有信息。 - 主体的属性：指的是与主体相关的所有信息，包括主体的年龄、性别、职位等。 - 资源的属性：指的是与资源相关的所有信息，包括资源的创建时间、创建位置、密级等。 - 情况的属性：指的是客观情况的属性，比如当前的时间、当前的位置、当前的场景（普通状态、紧急状态）。 - 操作：含义还是一样，比如增删改查等。设定一个权限，就是定义一条含有四类属性信息的策略（Policy）。 ``` <pre class="calibre10">``` 策略表效果：允许操作：流入主体：来自上海IP的客户端资源：所有以33开头的端口（如3306）情况：在北京时间 9:00~18:00 效果：禁止操作：流出主体：任何资源：任何情况：任何 ``` ``` 一个请求会逐条匹配策略，如果没有匹配到策略，则返回默认效果，默认效果可以根据场景定制，可以是默认拒绝或是默认允许。另外，匹配方式也可以根据场景定制，可以使用**逐条顺序匹配**，匹配到策略直接返回。也可以使用**完全匹配**，匹配所有的策略，如果有一个拒绝（允许），则拒绝（允许）。阿里云的RAM访问控制运用的就是ABAC模型： ``` <pre class="calibre10">``` 阿里云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可以发挥权限系统最大的灵活性，但在灵活的同时，如果不对策略加以管理，也有可维护性的问题。