您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

超级管理员英文_超级管理员英文怎么写

权限,用户,角色超级管理员英文_超级管理员英文怎么写

发布时间：2016-12-08加入收藏来源：互联网点击：

拓展：【RBAC2】 角色限制

RBAC2模型是在RBAC模型基础上，增加对角色的限制约束。主要包括以下约束:

互斥关系: 同一用户只能分配到一组互斥角色集合中至多一个角色，互斥角色是指各自权限互相制约的两个角色。例如一个用户不能同时具备销售和财务2个角色，否则就可以自己审批自己的报销申请了。

基数约束:

一个角色被分配的用户数量受限，例如一个部门内能只能存在1个总监角色；一个用户可拥有的角色数目受限，例如一个供应商生产员可以同时最多拥有组长和员工2个角色；同一个角色对应的访问权限数目受限，例如一个业务职能员工角色最多只能拥有1个业务的数据权限，而中台职能员工角色可以拥有多个业务的数据权限。

先决条件: 简单理解即如果某用户想获得上级角色，必须得先获得其下一级的角色。例如一个员工角色必须在系统内先晋升为主管角色，才能继续晋升为经理角色。

运行互斥：允许一个用户具有两个角色的资格，但在运行中不可同时激活这两个角色。

拓展：【RBAC3】 统一模型

可以单纯的理解为RBAC0 + 1 + 2的集合体，在基本模型的基础上同时具备了分层能力和限制能力。

RBAC模型优势： 当拥有大量用户和资源时，维护成本较低。

RBAC模型劣势： 无法对单个用户、单个资源进行个体定制。比如，某角色拥有创建、删除的权限，当我们要对针对拥有该角色的某个用户去掉删除的权限。那么，我们就必须创建另一个角色来满足需求。如果这种情况很频繁，就会丧失角色的统一，降低系统的可维护。

【ABAC】基于属的权限访问模型

ABAC通常用于配置哪些属的用户在哪些属的环境下可以对哪些属的资源进行哪些操作。 实现原理：通过各种属条件来动态判断一个操作是否可以被允许，也可以理解为我们俗称的“配置规则”。 我们在配置规则时需要定义属条件和资源的关系。其中属条件又分成以下3类：

用户属：如年龄、部门、职位、别等；环境属：如时间、地点、场景等；资源属：如资源状态、资源创建时间、资源存放位置、资源保密等级等。

以1个权限控制策略为例：

只有设计部门内职位为视觉设计师的用户，在工作时间内且处于上海办公区时，才可以访问和编辑草稿状态的人物素材库。

其中“设计部门”、“视觉设计师”为用户属，“工作时间”、“上海办公区”为环境属，“草稿状态”为资源属，只有命中符合这些属条件时，该规则才会生效，用户才能具备对相应资源的操作权限。 我们设置的属条件也可以定义“且/或”的关系，当我们定义“且”关系时，必须所有属条件命中才会生效规则；当我们定义“或”关系时，只需要命中部分属条件就可以生效规则。

ABAC的使用场景较灵活，常用于复杂多变的策略定制场景。如定制架构可见范围、定制会话权限等。

ABAC模型优势： 能够根据上下文动态执行，可以发挥权限控制最大的灵活，满足更细颗粒度的场景需求。ABAC模型劣势：学习成本比较高，随着规则（策略）的不断增多，管理和维护成本也会攀升。

综合以上3大权限模型的优劣来看：

ACL模型基于资源进行配置，适用于用户量少、更新频次低、无明确职能划分的小型组织，开发成本低但后期管理维护成本高，适合作为平台搭建初期时的临时过渡方案；RBAC模型基于角色进行配置，适用于用户量一般、更新频次一般、有明确职能划分、较少定制权限的中型组织，开发成本高但后期维护成本低，适合作为平台管理少量内外部用户时的方案；ABAC模型基于属进行配置，适用于用户量多、更新频次高、职能划分复杂多变、有安全合规诉求、权限定制多样化的大型组织，能够在保障效率的同时降低安全风险，适合作为平台管理大批量复杂用户时的方案。
2.2 基于业务梳理关键信息

第一步：选择权限模型

不同的业务特点指向不同的使用场景，因此我们需要基于业务特点选择合适的权限模型。 以众包平台为例，平台具备B/C双端的特点，因此在进行权限设计时需要考虑两端的使用场景和受众群体。

基于以上业务特点，我们可以发现B端后台管理权限分配更适合基于“角色”进行设计，而C端前台的生产权限更适合基于“属”进行设计。

完成模型选择后，我们需要基于模型进一步梳理平台内所需的角色、属和权限信息。

第二步：明确关键角色和属

角色是连接用户和权限的桥梁，因此我们需要对平台内的B端管理角色进行穷举。 角色定义通常取决于岗位职能划分和任务流分工。

超级管理员是一种特殊的角色，主要作用是为了添加首批管理人员，通常为隐形状态，且该角色不可通过配置进行分配。 通过盘点，我们在该步骤可以得出一份「角色列表」。 属是触发规则运行的基本条件，我们需要将平台内所有影响规则运行的属进行整理归类。 关键属通常取决于平台用户数据的字段定义、用户操作环境的客观因子和业务资源数据的标签维度。

通过盘点，我们在该步骤可以得出一份「属列表」。

第三步：梳理权限

权限是用户能够访问的资源，本步骤需要将平台内所有权限点按照类型进行整理归类。权限点主要有以下几种类型需要盘点：

页面权限即用户在平台内可见的页面，由导航菜单来控制，包括一级导航菜单、二级导航菜单，甚至三级导航菜单，只要用户有对应导航菜单的权限即可访问页面。

操作权限即页面内的功能按钮，包括我们常规认知的增删改查操作。 如下图众包平台的权限示例：

在实际操作场景中，部分操作权限会因状态而发生变化，在盘点操作权限时，需要梳理状态关联来检查是否有缺漏，如下图所示：

一期因时间问题，我们统一仅基于页面配置“查看”与“操作”两类权限。

数据权限即用户在同一页面看到的数据，不同数据权限的用户在同一页面内将看到截然不同的数据。 如下图示例，切换力家长或GauthMath项目后，在同一页面内看到的数据完全不同：

B端后台出于数据安全考量，各业务会期望数据处于仅自己业务管理员可见的状态，因此我们发现站在业务角度使用“项目组”的形式来分隔数据更加简单有效，通俗来讲就是每个业务对应一个项目，将用户加入项目内即可获取对应业务的数据权限。

各业务在面向C端生产角色开放数据权限时，通常需要综合效率、质量和成本等多种目的来进行考量选择，权限也会针对相同类型的用户进行集中配置，因此针对生产角色的会更多基于“用户群组”的形式来进行数据分隔，我们将相同类型的用户进行编组，再对整组用户按照分流规则授予相应的数据权限，群组在命中分流规则后可在任务广场内看到相应的任务数据。

通过盘点，我们在该步骤可以得出一份「权限点列表」。

第四步：关联权限

关联角色和权限：结合「角色列表」、「属列表」和「权限点列表」，我们可以整合出一张完整的权限对应表。在梳理角色和权限的关系时，可以通过“角色行为穷举”来进行权限点转化和连接。

 2/4   首页 上一页 1 2 3 4 下一页 尾页