如何合理配置网站权限：系统权限管理策略与实施技巧汇总

系统权限规划理念与技巧汇总

几乎所有管理界面均需考虑权限的规划，权限管理是管理界面的关键功能，能有效增强系统的安全性，降低误操作、数据泄露等风险的发生。然而，许多产品经理对权限功能存有畏惧心理，一方面是因为可供参考的案例不多，权限管理算是一项“系统级”的基础功能，通常只有管理员可以操作，不像其他功能可以通过在其他系统中试用体验，另一方面，对于权限功能，普通用户无法操作使用，因此存在感较低，做好了也不会显眼，但没做好就会导致整个流程受阻、产品崩溃。

一 RBAC模型

当前，被广泛认可的权限模型是RBAC（基于角色的访问控制）模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而获得这些角色的权限。这极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而设立，用户则根据其职责和资质被分配相应的角色，用户可以轻松地从一种角色转换到另一种角色。角色可以根据新的需求和系统合并而赋予新的权限，而权限也可以根据需要从某个角色中收回。

1.角色的作用

如果没有角色的概念，直接将用户与权限对应，虽然会更加灵活，但后台的数据表设计会变得复杂，操作成本也会很高，同时容错能力也会变得很差。

引入“角色”概念后，用户与角色可以形成多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。此时只需为角色分配权限，就能大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也得到很大提升。

2.引入用户组

在一些大型平台上，如果用户数量较多，在添加角色时，需要为大量用户分配新的角色，工作量巨大，此时可以引入用户组的概念，将这些用户拉到同一个用户组中，然后对整个用户组进行角色的指定，这样就大大减少了角色分配的工作量。

同理，如果权限较多时也会存在同样的问题，对角色进行权限设置时也需要大量的操作，此时可以考虑引入权限组的概念，将关联性较强的权限打包成组赋予角色，从而减少赋值时的工作量，现实中权限组的使用相对较少，因为系统中的权限一般来讲是有限的。需要注意的是，即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这可以视具体业务情况而定。

下图所示为mac系统中运行添加用户组，并以用户组为单位配置权限。

3.角色继承的RBAC模型

在一个业务场景中，如果角色需要区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需要使用角色继承的RBAC模型。上层角色继承下层角色的全部权限，并且可以额外分配权限。

此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。

继承关系通常来源于公司团队的组织结构，此时通常将角色与组织结构进行关联，以达到继承角色模型的效果。如下图所示的赵同学，其角色是“三级团队负责人”，与其并列的小组中有多个“三级团队负责人”的角色，但依附于左侧的组织结构树，各级负责人仅有查看和操作自己下属子节点的权限。

4.限制的RBAC模型

在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。这与我们熟知的“不能既是‘运动员’又是‘裁判员’”的道理相同。

因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中只能被赋予一个角色，在管理员角色组中也只能被赋予一个角色。

此外，限制还可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。

限制的模型不仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。

根据不同的业务需求，限制的形式很多。需要注意的是，不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。

三、权限的划分与设计

通过RBAC模型已经能够很好地搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？

这些都需要分析清楚才能进一步设计出完善的权限系统。

首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。

整体关系如下图所示：

因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅。

保证初期设计支持后，配置权限时，还需要注意以下几点：

（1）确定是否支持前端配置

如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。

若需定制角色或各个角色在各类使用者情境下拥有不同权限，需将角色设定、角色与权限间的配置反映于“前端用户设置界面”。此类情况适用于经常变动且需自定义角色权限，以及拥有租户体系的系统。

（2）以基本单元拆分，以业务逻辑配置

通常可以将每个对象的“新增、删除、修改、查询”各自视为一个基本的权限单元。打个比喻，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好划分为4个权限单元。在技术和设计上，我们期望尽可能实现解耦和模块化。

然而，在业务层面，某些操作却是一体的。这些无法拆分的权限在“前端用户设置界面”中建议整合为一个整体进行配置。例如：如果我们确定在系统的现有和未来业务中，仅将普通成员赋予“人员管理”的查看权限，管理员拥有操作权限，则可将“新增、删除、修改”三个基本权限单元合并为“操作”权限进行配置。

（3）页面权限优于操作和数据权限

必须先配置页面模块权限，才能配置当前页面模块下的具体操作权限以及页面模块的数据展示权限。

（4）查看权限优于增删改权限

在正常情况下，一定要先能查看某个模块或操作，其它增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者在配置其它权限时默认赋予查看权限。

（5）角色与权限的多种关系

角色与权限的关系不仅是单纯的“是/否”关系，还包括以某种限制进行操作，以及以某种程度访问数据。

例如在“人员管理”中：

数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；数据边界限制（上限等）：添加人员时不能超过20个等。数据字段：HR能查看人员列表中包括职级、薪资等字段，其它角色仅能查看姓名邮箱等字段；

（6）角色与权限的设计表达

在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则非常多，当通篇以这样的形式描述时，表达对象将很难理解。

正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

如下图所示：

四、需要注意的Tips

1.隐形的admin

在可自定义角色和权限的系统中，一般需要预留一个admin角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。

有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。

2.初始权限的赋予

对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。

初始权限还可以与用户既有的某些数据字段进行关联，如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。

3.人员管理中对自己的处理

在人员管理中，管理员角色处理自己时需要额外注意。因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。

4.无页面权限的提示

虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统bug。

总结一下，整个权限系统设计就是定义各个节点和节点间关系的过程。

节点包括：

用户；用户组；角色；角色组；权限（页面、操作、数据）；权限组（页面、操作、数据）；

谁能说说权限是如何设计的

权限设计目前为止都没有一个最完美的设计，只有一个最适合的设计

比如WINDOWS，本身设计也就是到了角色的级别，如果WINDOWS权限能够控制到文件，文件夹，甚至是文件的某一行，相反还太过繁琐，属于设计过度。

在软件开发中，为软件加入权限控制功能，使不同的用户有不同的使用权限，是非常重要的一项功能，尤其在开发数据库方面的应用，这项功能更为重要。一般均以菜单访问功能的形式出现，按照常规的做法，只要让注册进入应用的不同用户，可以访问不同的功能菜单，从而实现功能权限的控制，但是，有这样一个问题，此种方法便无能为力，现在的应用软件，为了提高软件的易操作性，同一功能可能有多种不同的访问方式，如工具条、右键菜单等；同样，同一个功能，也可能在软件的不同地方被调用，而不仅仅被限制为用程序的主菜单来调用，这样，才能保证应用的易用性。

目前使用的比较多的设计方法一般是基于角色的，即

用户——角色——权限

判断一个用户有没有权限做某件事情，先判断该用户所属的角色，然后查看该角色的权限，通过查找出来的权限，来判断该用户能否进行操作。

数据库的设计可以参考以下：