RBAC模型的权限设计的6大思路解析 c权限模型怎么分析 _生活百科

c权限模型怎么分析(RBAC模型的权限设计的6大思路解析)，小编带你了解更多信息。

编辑导语：RBAC是一套成熟的权限模型，在传统权限模型中，我们直接把权限赋予用户。而在RBAC中，首先把权限赋予角色，再把角色赋予用户。本文作者以后台系统为例，以RBAC模型为基础，为我们展示了权限设计的过程。

文章插图

文章插图
对于业务复杂或数据庞大的系统，为了方便管理，一定要做权限设计。权限设计是后台系统要考虑的一个授权策略问题。直白的说，权限设计就是根据公司的业务规则，对权限管理系统设置的安全策略。
权限一般分为功能权限，数据权限与菜单权限：

功能权限控制当前账号可以操作的功能按妞，比如风控只能审核标的登记，但不能发起进件申请。
数据权限控制当前账号可以看到的数据范围，比如客服A只能看到分配到她名下的出借人的投资数据。
菜单权限控制当前账号可以看到的页面内容，比如催收人员只能看到案件逾期后流转到催收页面的内容。

文章插图

文章插图
对于权限设计，关键是理清用户、权限、角色三者的关系。即给谁创建账户，分配什么角色，赋予何种权限。

文章插图

文章插图

一、需求背景权限设计的首要问题是明确需求。权限设计牵涉到后台系统底层架构的业务逻辑，在做后台系统之前，一定要对现有的权限控制和业务情况了解清楚，才能避免在权限设计的问题上踩坑。
以某车贷风控系统为例，我们通过相关业务部门的反馈和当前权限系统的调研，发现它存在的问题有以下几点：

用户的权限归属不明确，导致进件的申请和审核操作为同一个人；
敏感数据没有做权限控制和脱敏处理，导致用户隐私数据被泄露；
角色的分类不合理，每个用户只能配置一个角色，导致工作组和流程节点比较复杂；
对所属团队的客户经理、团队经理和城市经理做了三级维护关系，但人员调动和离职率较大，导致管理成本高。

了解完现有需求背景后，我们借鉴钉钉的那套权限维护方式，改进了管理系统的权限设计。
一方面收集权限需求，根据部门需求列一份权限清单，并做好CheckList 。在模块的功能页面要放置哪些权限，完全可以根据《操作权限申请表》的业务需求，进行灵活的权限配置。
另一方面借助UML建模的用例图，将角色按功能Uc级细分到增删改查导，方便确认相关人员的操作权限。

文章插图

文章插图

二、设计过程明确需求后，就要选择合适的权限设计模型。做后台系统权限设计，我们可以借鉴一些控制模型。
常见的权限设计控制模型有：自主访问控制（DAC）、强制访问控制（MAC）、访问控制列表(ACL)、基于角色的访问控制(RBAC) 、基于任务和工作流的访问控制(TBAC) 、基于任务和角色的访问控制(T-RBAC)、基于对象的访问控制（OBAC）、使用控制模型( UCON)、基于属性的访问控制（ABAC）等。
最常见的权限设计控制模型是RBAC模型。像业务复杂且功能庞大的某车贷风控系统，权限设计选择的就是RBAC模型，主要是方便后续的扩展。
RBAC即基于角色的权限访问控制（Role-Based Access Control），在RBAC模型中，权限与角色相关联，用户通过成为对应角色的成员，从而得到这些角色的权限。即用户关联角色，角色关联权限，可实现系统权限的灵活配置。
访问控制的核心是授权策略。在RBAC模型中，Who、What、How构成了权限控制三要素，也就是Who对What(Which)进行How的操作。
RBAC的权限授权其实就是Who、What、How的问题。Who：权限的拥用者，What：权限针对的资源，How：具体的权限。在RBAC中，根据权限设计的复杂程度，可分为RBAC0、RBAC1、RBAC2、RBAC3 。
RBAC模型包含用户(User)、资源(Resource)、操作(Operation)三个关键要素。通过将资源以及资源操作授权给用户，而使用户获得对资源进行操作的权限，保证了权限分配的实施。