当前位置：首页 > news >正文

【面试】如何设计SaaS产品的数据权限？

news 2026/2/9 2:25:01

前言

一套系统的权限可以分为两类，数据权限和功能权限，今天我们从以下几个点，细聊下如何设计数据权限。

要从三个方面回答这个问题。

数据权限的设计，理应遵循两个原则：安全性、灵活性

新增一个菜单，专门用于系统的数据权限控制维护，可以按用户名+菜单+字段+内容来设计。
当然，如果是一整套系统包括了很多子系统，设计的时候需要把系统也加上。
需要注意菜单和字段一定要校验在系统中是否存在，要不然就白维护了。
用户在打开一个菜单，就会调用这个数据权限维护的信息，判断里面的字段，显示的内容就是这些字段维护的，如果没有查到，可以默认显示全部数据（因为用户可以进入菜单说明已经拥有菜单的查看功能权限）。

RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。
RBAC事先会在系统中定义出不同的角色，不同的角色拥有不同的权限，一个角色实际上就是一组权限的集合。而系统的所有用户都会被分配到不同的角色中，一个用户可能拥有多个角色。使用RBAC可以极大地简化权限的管理。
RBAC模型还可以细分为RBAC0，RBAC1，RBAC2，RBAC3。这里我们不讨论他们之间的差异，感兴趣的同学可以自行研究，我们主要聚焦于常见的RBAC0模型上。
如下图就是一个经典RBAC0模型的数据库设计。

在RBAC模型下，系统只会验证用户A是否属于角色RoleX，而不会判断用户A是否能访问只属于用户B的数据DataB。这种问题我们称之为“水平权限管理问题”。

我们来看看应该怎么来控制登录人的数据权限，这里可以分为数据范围权限控制、数据操作权限控制和业务对象字段权限控制。

B 端客户内部的业务对象通常来说会按管理层级划分管辖范围，比如我曾经做过的物业平台，他们会按小区（也叫物业项目）、片区、分公司、大区和总部五个层级来划分管辖范围。

这里的小区其实就是一个基础的授权业务对象，然后将多个小区集合起来会形成片区。同时，经营小区的会是具有法人资质的主体，即分公司。多个分公司又会按地理区域划分到不同的大区，最后到总部管辖全部的业务数据。这个时候，我们就需要支持从基础的业务对象到更大范围的数据授权。

比如下面几个场景：

通常来说，不同层级的授权方式是互斥的，也就是一个人不能说既按小区级别授权又按片区级别授权。同时，同一个层级的，是支持授权多个的。

对于 B 端客户的外部业务对象，因为不存在管辖层级，往往是通过分配的方式进行。即将一个或多个业务对象分配给某类角色或某个员工，登录人只能看到分配给自己的业务对象。典型的就是 CRM 系统的客户公海资源，员工只能看到分配给自己的客户。

业务对象操作权限是指对业务对象以及业务对象属性能够进行的操作。典型的业务对象的操作就是新增、删除、编辑、查看、导出、改变业务对象状态（如市场线索转销售线索）等等。比方说，我们控制 A 员工只能查看客户信息，不能新增、编辑、删除和导出客户信息。

业务对象字段的颗粒度就更小一点，是针对某个类型的业务对象，约束登录人能查看、编辑或导出业务对象的哪些属性。业务对象属性在技术上对应的是数据表的字段。

举个例子，CRM 系统的“客户”这个业务对象，会有名称、地址、电话、级别、所属行业等等信息。我们就可以控制A 员工（或角色）只能查看客户名称、级别和所属行业，不允许查看地址和电话。

总的来说，数据权限的授权分为三个方面，业务对象范围授权、业务对象操作授权和业务对象字段授权。

为了实现这三个方式的授权，我们在产品设计上需要支持业务对象范围的划分、业务对象操作的定义和业务对象字段的定义，如下图所示。之后，我们就可以配置某个角色或人员的数据权限了。

在这里插入图片描述

数据权限是SaaS产品必不可少的功能。企业的数据很多涉及敏感信息，包括商业机密信息等等，因此必须在产品规划之初就明确权限管控的颗粒度，以及按何种方式管理数据权限。