访问|B端设计实战：基于角色&属性的权限设计( 二 )

文章插图
在B端中后台的设计中，最常见的应用场景为“权限管理”，权限管理涉及的维度也会比版本管理更为复杂。
二、怎么设计权限控制？2.1 了解和选择权限技术模型权限控制的实现依赖于技术实现，而常见的技术模型主要分成如下3类：

【ACL】Access Control Lists 访问控制列表
【RBAC】Role-based Access Control 基于角色的权限访问模型
【ABAC】Attribute-Based Access Control 基于属性的权限访问模型

不同体量的权限系统，我们可以参考不同的权限模型进行梳理和设计。【ACL】访问控制列表 ACL通常用于配置哪些用户可以访问操作哪些资源。当权限系统体量小，用户有直接对应具体功能点即可满足系统诉求时，可以考虑使用ACL模型作为参考。实现原理：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源操作。当系统试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。 ACL权限中，只有用户、资源这两个要素：

用户：是发起操作的主体，可以是1个人，也可以是1个用户群组。例如：后台管理系统的用户、OA系统的内部员工、设计部门等。
资源：用户可以访问操作的客体，例如：页面、文档、数据等。

文章插图
ACL常用于部门隔离场景，适用资源如人事页面、客户页面。如下图部门成员配置页，通过Excel表格来一次性批量导入部门成员信息，使这批成员在提交后自动获取该部门下的数据权限。

文章插图
拓展：【DAC】自主访问
DAC在ACL基础上，增加了权力下放的能力，允许拥有权限的用户再次将权限授予其他用户。

文章插图
DAC常用于文件管理场景，适用资源如培训文档。如下图所示，拥有文档编辑权限的用户可以将编辑权限再次授予其他用户。

文章插图
拓展：【MAC】强制访问
MAC在ACL基础上，增加了双重验证的限制，要求用户和要访问的资源必须具备相应的安全等级关系才可获取权限。

文章插图
MAC常用于保密信息场景，适用资源如保密数据。如绝密级的财务数据只能被企业高级用户查看、访客级用户无法查看企业级的文档、机密级的部门架构信息仅能被部门负责人级别的账号查看。

文章插图
ACL模型优势：研发实现快速简单，不需要耗费较多开发成本。
ACL模型劣势：当拥有大量用户和资源时，维护成本变得极高，每次有新用户&新资源加入时都需要重新挨个配置每个用户与每个资源的关系，不适用于频繁变更用户权限的场景。
【RBAC】基于角色的权限访问模型
RBAC通常用于配置哪些角色拥有哪些权限，而哪些用户可以拥有这些角色。实现原理：把用户按角色进行归类，通过用户的角色来确定用户能否针对某项资源进行某项操作。 RBAC模型的三要素为：用户、角色、权限。

用户：是发起操作的主体，可以是1个人，也可以是1个用户群组。例如：后台管理系统的用户、OA系统的内部员工、设计部门等。
角色：用于连接了用户和权限的桥梁，每个角色可以关联多个权限，同时一个用户也可以关联多个角色，那么这个用户就有了多个角色的多个权限。
- 上一页
- 1
- 2
- 3
- 4
- 5
- 6
- 下一页