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

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

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

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

很多朋友想了解关于超级管理员英文的一些资料信息，下面是小编整理的与超级管理员英文相关的内容分享给大家，一起来看看吧。

编辑导读：“权限控制”是中后台的基础能力，用于管控操作人员在平台内可做的事项内容。即通过权限控制，可以决定哪些人在平台内可以做哪些事。本文作者围绕角色属的权限设计展开分析，希望对你有帮助。

Hello，我是一名交互设计师。

随着3月暖春的即将到来，苏州的疫情却似乎没有好转的迹象，于是被迫居家隔离的我，反而有了更多的时间来思考复盘自己参与B端设计后的一些收获。

我现在参与的项目是资源生产中台，说白了，就是当字节内部的业务需要某类资源时（如教育业务需要题目资源、电商业务需要竞品价格资源、房产业务需要房源数据资源等等），它们可以选择联系资源生产中台，我们将根据业务的预算提供合规的资源采集，当然我们都知道，对企业而言，这类预算当然是越少越好。

那么，为了帮助企业降低预算，中台便开拓了众包业务（其实BAT早就开拓了），具备高学历的全职奶妈、在校大学生、兼职老师这批Freelancer群体，可以通过我们的众包平台注册为生产员进行接单，来帮助消化业务部门的资源采集诉求，从而也可以为自己赚取一笔额外的收入。

起初，为了快速搭建平台，我们在权限上做了简单处理，管理员和生产员在平台内的权限仅能通过研发和运营进行手动表格配置（可以参考下文中的ACL模型），然而随着业务的不断增多和平台人员的快速扩张，我们发现了一个严重的问题：

因为权限设计的比较简单，随着业务需求的定制化或用户类别的细分化，已经开始大量占用研发时间和运营人力，这种现象严重违背了中台“降本提效“的初衷。

那么为了解决这个问题，我们需要对众包平台的权限系统进行重构设计，实现灵活智能的平台权限配置，减少对研发和运营的人力占用，以下是我在进行设计时的一些思考和尝试：

一、什么是权限控制

“权限控制”是中后台的基础能力，用于管控操作人员在平台内可做的事项内容。即通过权限控制，可以决定哪些人在平台内可以做哪些事。

1.1 权限控制的价值可以让管理者基于安全规则和策略，配置不同用户合理访问对应资源；可以让用户能够在有效的限制范围内访问被授权的资源。

在B端场景中，通过权限控制可以让工作群组内不同的角色专注于自己的工作范围，可以降低操作风险发生概率，便于进一步管理。

1.2 权限控制的应用场景

权限控制的应用主要有两种场景：

版本管理场景

基于版本进行产品权限的分配和控制，该场景主要应用于有商业化诉求的B端产品。 通过权限控制将产品功能切割为普通权限功能和高级权限功能，从而衍生出普通版和高级版，甚至更多版本的产品。 这些版本功能范围基本处于一个包含关系，如下图的企业版就包含了标准版的功能权限。

权限管理场景

基于角色或属规则进行产品权限的分配和控制，该场景适用于逻辑复杂模块繁多需要提升工作效率的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系统的内部员工、设计部门等。角色：用于连接了用户和权限的桥梁，每个角色可以关联多个权限，同时一个用户也可以关联多个角色，那么这个用户就有了多个角色的多个权限。权限：用户可以访问的资源权限，包括：页面权限、操作权限、数据权限。

RBAC常用于企业数据和功能管理场景。如下图当某用户被分配分析师角色时，则该用户账号自动获取了分析师角色下的所有权限。

拓展：【RBAC1】角色分层

RBAC1模型是在RBAC模型基础上，引入了角色分层的概念，即角色具有上下级的关系，每个等级对应不同的权限组，从而实现更细粒度的权限管理。

RBAC1常用于角色内的多级别分层场景。如下图，通过权限组的形式对管理员角色进行再次权限分层，例如可以将设计师角色分成设计师、设计主管、设计经理和设计总监等多级权限。

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