将介绍权限系统的设计和五种主流的权限模型。权限控制可以通俗地理解为权力制约，即由于不同的人拥有不同的权力，他所看到的和能使用的可能是不同的。对应一个应用系统，其实一个用户可能有不同的数据权限（看）和操作权限（使用）。主流的权限模型主要分为以下五种：ACL模型：访问控制列表DAC模型：自主访问控制MAC模型：强制访问控制ABAC模型：基于属性的访问控制RBAC模型：基于角色的权限访问控制ACL模型：访问控制列表AccessControlList，ACL是最早也是最基本的访问控制机制。它是一种基于对象控制的模型，其他模型中也使用了ACL。为了解决一一配置相同权限用户的问题，后来也采用了用户组的方式。原理：每个客体都有一个列表，记录了哪些主体可以对这个客体做哪些行为，很简单。例如：当用户A要编辑一篇文章时，ACL会先检查文章编辑功能的控制列表中是否有用户A。又如：不同级别的会员可以使用产品中不同的功能。缺点：当被试数量较多时，配置和维护工作成本高且容易出错。DAC模型：DiscretionaryAccessControl，DAC是ACL的扩展。原理：在ACL模型的基础上，允许主体将自己的权限独立授予其他主体，权限可以任意传递。例如：常见于文件系统，LINUX、UNIX、WindowsNT版本操作系统均提供DAC支持。缺点：权限控制比较分散，比如不能简单的把一组文件的统一权限设置给指定的一组用户。主题权限过大，可能会无意中泄露信息。MAC模型：MandatoryAccessControlMandatoryAccessControl，MAC模型中主要的双向认证机制。常见于涉密机构或其他层次感强的行业，如军政安保软件。原理：主体有权限标识，客体也有权限标识，主体能否对客体进行操作取决于双方权限标识的关系。例如：将军分为Admiral>LieutenantGeneral>MajorGeneral，军事文件的机密级别分为TopSecret>Secret>Secret。规定不同军衔只能访问不同保密级别的文件。当访问某个文件时，系统会验证账户的军衔，同时也会验证文件的机密级别。只有军衔对应保密级别，才能访问。缺点：管控过于严格，实施工作量大，没有灵活性。ABAC模型：Attribute-BasedAccessControl，可以解决RBAC的缺点，添加新资源时易于维护。原理：通过动态计算一个或一组属性是否满足某种机制来进行授权，是一种非常灵活的权限模型，可以根据需要实现不同粒度的权限控制。通常有四种属性：主体属性，如用户年龄、性别等；对象属性，如文章等；环境属性，即空间约束、时间约束和频率约束；例如：上午9：00-11：00，A、B两个部门作为考生一起参加考试，下午14：00-17：00，A、B部门进行检查给彼此的论文。缺点：规则复杂，不容易看清主客体关系，实施起来非常困难，现在已经很少使用了。RBAC，Role-BasedAccessControl，核心是用户只与角色相关联，角色代表正确的权限，是一系列权限的集合。RBAC的三要素：用户：系统中的所有账户角色：一系列权限的集合（如：管理员、开发人员、审核管理员等）权限：菜单、按钮、数据增删改查等详细权限，修改等。在RBAC中，权限与角色相关联，用户通过成为相应角色的成员来获得这些角色的权限。创建角色是为了完成各种任务，用户根据职责和资格分配相应的角色。可以轻松地将用户从一个角色分配到另一个角色。可以根据新的需求和系统集成赋予角色新的权限，也可以根据需要收回角色的权限。角色与角色之间也存在继承关系，防止越界。优点：角色划分容易，权限管理更灵活；最小粒度授权；RBAC的深度扩展RBAC模型可以分为四个阶段：RBAC0、RBAC1、RBAC2、RBAC3。一般企业可以使用RBAC0模型。另外，RBAC0相当于底层逻辑，后三者都是在RBAC0模型上提升的。下面简单介绍一下这四种RBAC模型：RBAC0模型用户与角色、角色与权限的多对多关系。简单的说，一个用户拥有多个角色，一个角色可以被多个用户拥有。这是用户和角色之间的多对多关系；角色和权限也是如此。RBAC0模型如下图所示：没有画太多的线，但是已经可以看出多对多的关系了。与RBAC0模型相比，RBAC1模型增加了角色分类的逻辑，类似于树形结构。下一个节点继承前一个节点的所有权限。比如role1的根节点下有两个子节点role1.1和role1.2。逻辑可以有效规范角色创建（主要是权限继承逻辑）。以前做过BD工具（比如CRM），BD之间有分类（manager，supervisor，specialist）。如果使用RBAC0模型作为权限体系，我可能需要创建manager、supervisor、specialist的角色（角色之间没有权限继承），很可能会出现问题。由于权限配置错误，supervisor连manager都没有权限。RBAC1模型很好的解决了这个问题。创建manager角色并配置权限后，supervisor角色的权限继承manager角色的权限，支持定向删除supervisor权限。RBAC2模型是在RBAC0模型的基础上，增加了对角色的更多约束。如果角色互斥，一个典型的案例就是财务系统的出纳不能兼任审计，那么在给财务系统操作员分配角色时，同一个操作员不能兼任出纳和审计两个角色。同一时间。比如角色人数限制，比如：专门为公司CEO创建了一个角色，最后发现公司里有10个人是CEO这个角色，一个公司有10个CEO？这是对角色数量的限制，指的是有多少用户可以拥有这个角色。RBAC2模型主要是增加了对角色分配的限制，这也符合权限体系的目标：权责明确，系统使用安全保密。RBAC3模型也是在RBAC0模型的基础上发展起来的，但是它结合了RBAC1和RBAC2的所有特点，这里不再赘述。读者可以回到RBAC1和RBAC2模型的描述。RBAC权限管理在实际系统中的应用RBAC权限模型由三部分组成，即用户管理、角色管理和权限管理。用户管理按企业架构或业务线架构划分。这些结构本身都比较清晰，扩展性和可读性都很好。角色管理必须在深入理解业务逻辑之后进行设计。一般以各部门的真实角色为基础，再根据业务逻辑进行扩展。权限管理是前两种管理方式的强化。太薄会太碎，太厚又不够安全。这里需要根据经验和实际情况进行设计。1、用户管理用户管理中的用户是企业中的每一位员工。他们有自己的组织结构。我们可以直接以企业部门结构或业务条线结构为线索，构建用户管理系统。需要特别注意的是：实际业务中的组织结构可能与企业部门结构、业务条线结构不同，需要考虑数据共享机制。一般的做法是授权某个人或某个角色组在某个组织层面共享某个对象组的数据。2、角色管理在设计系统角色时，要深入了解公司结构和业务结构，然后根据需求设计角色和角色内的层级。通常，角色相对于用户是固定的，每个角色都有自己明确的权限和限制。这些权限在系统设计时就确定了，以后不会轻易改变。自动获取基础角色当员工加入部门后，该员工的账号会自动添加到该部门对应的基础角色，并拥有相应的基础权限。此操作是为了保证系统安全，减少管理员的大量人工操作。使新入职人员能够快速使用系统，提高工作效率。临时角色和失败时间公司的业务有时需要外部支持。他们不是公司的员工，只是在某个时候支持公司。这时候我们就需要设置临时角色来应对这种可能跨部门协作的临时员工。如果公司安全级别高，这类账户默认有固定的失效时间，当达到失效时间后，需要重新审核才能重新开通。避免因流程不完善导致临时账户遗忘在系统中，造成安全隐患。虚拟角色department角色中的层级可以授权同层级的员工拥有相同的权限，但部分员工因工作原因需要调用角色层级以外的权限，同层级的不同员工需要使用不同的权限.对于这种超出角色级别且合理的权限授予，我们可以设置虚拟角色。这个虚拟角色可以集成这个工作所需的所有权限，然后可以分配给特定的员工。这样既不需要调整组织架构和相应的角色，又能满足工作中特殊情况的权限需求。白名单与白名单：部分用户并不拥有某个部门的顶级角色，但由于业务需要，需要在角色之外授予高级权限。那么我们就可以设计一个限定范围的白名单，将需要的用户添加进去。在安全流程中，我们只需要为白名单设计一个安全流程，对白名单中的特殊用户进行审核，实现对特殊权限用户的监控，降低安全风险。黑名单：比较常见的黑名单场景是，一些犯错的员工，虽然在职，但不能再给他们任何公司权限。在这种既不能取消角色关联，又不能完全停用账号的情况下，可以设置黑名单，让此类用户可以登录账号查看基本信息，但大部分关键权限已经被限制黑名单。权限管理权限管理一般从三个方面进行限制。页面/菜单权限、操作权限、数据权限。页面/菜单权限对于没有操作权限的用户，直接隐藏相应的页面入口或菜单选项。这种方法简单、快捷、直接，对于一些对安全性不敏感的权限非常有效。操作权限操作权限通常是指不同用户是否可以增删改查同一组数据。某些用户的只读浏览数据，其他用户的可编辑数据。数据权限对于安全性要求高的权限管理，前端只限制隐藏菜单和编辑按钮是不够的，还需要对数据接口进行限制。如果用户试图通过非法手段编辑不属于其权限的数据，服务器将进行识别、记录和限制访问。如何控制数据权限数据权限分为行权限和列权限。行访问控制：看多少条数据。列权限控制：看一条数据有多少个字段。在一个简单的系统中，可以通过组织结构来控制行权限，可以根据角色配置列权限。但是在复杂的情况下，组织结构无法承载复杂的行权限控制，更不用说角色了。主机列的专门表示。目前业界的做法是提供行列级别的数据权限规则配置，将规则分配给某个角色或某个用户??，作为类似的权限点配置。用户管理系统权限设计更多实用细节1.超级管理员超级管理员是用来启动系统和配置系统的帐户。配置系统并创建管理员后，应隐藏此帐户。超级管理员账号拥有系统所有权限，可以穿梭查看各部门数据。如果使用不当，会给系统管理带来安全隐患。2.如何处理互斥角色当用户已经有用的角色和要添加的角色互斥时，在添加新角色时，应该提示管理员由于互斥角色无法添加新角色.如需添加，必须先撤销之前的角色，再添加新的角色。3、用户管理权限体系的设计必须简洁明了。在设计权限系统时，一定要理清思路，一切从简，尽量不要增加多余的角色和权限逻辑。因为随着公司业务的扩大，权限和角色也会增加。如果一开始的设计思路不严谨，随着业务的扩大，权限体系会变得无限混乱。这个时候整理权限已经来不及了。所以初期的设计一定要清晰，简单明了，可以避免后续很多不必要的麻烦。4.无权提示页面有时候员工A会直接把自己当前操作的页面分享给员工B，但是员工B可能没有权限查看。此时，我们应该考虑在这里增加一个“无权限提示页面”，避免粗鲁的404页面让员工B认为系统出错。
