中后台学习笔记 – 数据权限

编辑导语：我们常常在数据权限中找不到合适的门路，中后台的数据权限该怎么设计才能够满足我们所需业务的数据权限架构体系？作者给我们从三个方面讲解了有关数据权限的知识，我们一起来看下吧。

曾经看到过这样一个需求：他想知道，我“为什么”能够看到这条数据? 如果这条数据是我自己创建的，那么其他能看到这条数据的人，都由于什么原因呢?

我的第一反应是：数据权限设计的太复杂了。

随后又想到: “为什么数据权限要设计的这么复杂呢，有没有更好的实现方案?”

但在回答这个问题之前，可能要先完成另一件事情，分析清楚到底什么是数据权限? 都有哪些业务场景，需要数据权限的支持?

简单来讲，数据权限就是“用户是否能够查看数据”，主要是为了业务系统的信息安全考虑，不同的人，在不同的场景下，所能看到的数据范围也不一样。

为了行文方便，后续统一使用“查看数据”进行描述，实际上像增/删/改/查/锁定/解锁/分享等的数据权限类型有很多，就不在本文中介绍了。

本文将结合在工作中遇见的一些业务场景，跟大家分享一些常见的数据权限设计，也希望能够总结出一套，最符合本公司业务的数据权限架构体系。

一、基础数据权限

1. 对象级权限
基础数据权限通常会承载到一个权限媒介上，比如说权限集，职能等。他通常包括两部分，对象级权限与字段级权限。

简单来讲，对象级权限可以控制到一个用户是否能够看到某一个业务菜单或者业务Tab，也就是说用户甚至可以不知道系统中有这一类的数据。对象级权限的设计会包含下面几部分。

当然，对于不同的企业，可能还会有更精细的管理，比如针对数据的转移，锁定/解锁等基本功能可以也需要做控制。

关于“查询所有关联”和 “修改所有关联”，他的权限优先级是要高于其他权限规则。比如商机、订单、报价单等业务对象都关联了客户，那么如果在客户上设置了“查询所有关联”的话，就会覆盖掉具体关联业务实体设置的对象级权限。

2. 字段级权限
根据业务需要，即使可以看到某个业务对象，但也需要对某些隐私字段做数据权限处理。 例如：联系人电话、薪水等信息，不会对所有人开放。

如果企业的系统中，有包含页面布局的相关设置，那么字段级权限设置，要覆盖掉布局的设置。

二、记录级数据权限

其实对于很多业务系统来说，可能上面的基础数据权限设计已经能够满足大部分数据权限场景了，但问题是有一类“特殊场景”解决不了。

某“一部分”数据，只允许“一部分”人查看。

几乎所有复杂的数据权限设计，都是为了解决这个问题，而且因为使用场景差异太大，很难找到一个一揽子解决方案。所以需要多种方案结合，才能在便捷性、安全性上，满足中大企业复杂的数据权限要求。

1. 系统默认权限
要想解决 某“一部分”数据，只允许“一部分”人操作，理论上那就意味着每一条数据都应该可以被控制。

那么 每一个用户与每一条数据之间到底是什么关系，是业务系统需要回答的第一个问题。

通常来讲，系统默认权限应该是“最严格的”，“唯一”的“限制”数据权限的方式，其他的记录级数据权限，应该是在系统默认权限的基础上，增加额外的数据权限。

比如最极端的限制条件，所有的业务数据都是不可见的。 当然对于某些公司来讲，一些数据是全员可见的，比如像公告、通讯录、社区帖子等类型的数据。

系统默认权限如果需要修改，应该要受到严格的控制流程管理，毕竟这是整个数据权限架构中，唯一的限制。

2. 记录所属人
通常来说，如果一个用户拥有某个业务实体创建对象的权限，那么针对这条特定的记录，用户创建完成记录后，会自动变为这条记录的所属人(owner)。

在系统默认权限的基础上，记录的所属人就属于一种新增的数据权限，可以对这个用户进行查看操作(可进行的操作应该基于基础数据权限)。

由于业务的需要，记录会在不同的用户之间进行数据转移的操作(transfer ownership)，所以记录所属人，不一定是记录的创建人。

还有一种例外情况，一条记录不属于某个特定的用户。

在有些公司的业务中，会有类似公海池、队列等记录分配器功能。

那么在分配记录之前，这些记录也是可以属于这些分配器的。

相关功能的成员可以在列表视图中看到这些分配器中的记录数据，并进行所属人认领的操作（更多详细内容，我会更新在后续的公海池设计当中）。

3. 部门/相关部门
每个企业的组织架构都会区分部门，那么就有一个非常自然的需求场景：看到本部门以及下级部门相关的所有数据。

一种比较简单的做法，就是在创建数据的时候，自动将数据关联到创建用户的所属部门上。

还有一些情况，有些公司的数据是由专门的团队负责创建的，那么针对于这些数据，就需要可以变更数据的所属部门的能力。

随着业务的不断发展，可能会遇到跨部门数据查看的需求，也就是说，一个用户有主要的所属部门，以及根据数据权限需要而设置的多个相关部门。

4. 直属负责人/助理
在传统的组织架构中，除了部门层级之间的数据共享需求之外，还有人员汇报关系线。

通常的做法，就是在为每一个用户，指定一个直属上级负责人，直属上级负责人会被赋予所有下属层级的相同数据权限。

为了管理方便，也可以为直属负责人设置助理，助理与直属负责人具备相同的数据权限，这样更灵活的让不同的用户能够跳脱出公司组织架构的束缚。

5. 岗位层级
使用部门权限体系会带来一个问题，企业的组织架构往往与业务的架构是不一致的。而且业务架构会经常变化，而结构变化对于数据权限控制来讲，是一个挑战。

岗位层级，可以根据数据权限需要，将一个用户或者一组用户放在同样的岗位下。

这样的话，在创建岗位的同时，也可以很好的了解公司架构到底应该以什么样的形式组织在一起更高效。

可以从上至下的设置岗位层级，比如说最高层岗位叫CEO，可以查看整个组织的数据。然后以事业部总经理或者地区负责人的岗位，继续向下细分，查看各自岗位下的数据。

岗位层级权限还有一个更加强大的能力，就是岗位与数据之间可以是 m:n 关系，也就是说同一条数据可以同时共享给多个岗位，满足更加复杂的数据共享场景。

岗位层级的设计，可以将数据与用户解绑，这在人员变动，业务调整时，可以很方便的做数据共享的变更。

6. 共享规则
对于数据权限还有一类更加接近直觉的设计方式，也就是别搞那些花里胡哨的概念，我就是要把“这一部分”数据，共享给“那一部分”人，简单直接一点，怎么做？

换句话来讲，如果上面的权限设计体系统统不能满足业务场景，可不可以提供一种直接的数据共享方式。

“共享规则”的设计方案可能是一种解决思路。通常来讲，共享规则解决了两类场景：

把特定用户的数据，共享给特定用户。
把符合特定条件的数据，共享给特定用户。
当然这里面的“特定用户”，不仅仅只用户本身，所有包含用户的容器概念元素(部门、群组、角色等)，应该都包含在内。

7. 手工共享
共享规则虽然方便，但解决不了一类更要命的数据权限场景，有些共享场景是没有办法提前可以预想的，是随机的，是随时随地的，怎么办?

其实这种场景的前提条件就决定了权限设计的方式，既然规则不行，那就手工来指定好了。

手工共享的数据权限设计，完全是基于记录所属人的自由意志，记录所属人认为数据应该共享给谁，就共享给谁好了。

需要注意的是，当记录的所属关系发生变更时，那么手工共享关系应该直接解除。记录所属人也需要可以随时查看和修改，当前这条数据的手工共享情况。

8. 团队成员
手工共享的确可以解决非常态化规则的数据权限场景，但麻烦的是，共享关系会随着记录所属人的所属关系转移，而全部丢失。

对于一条记录来讲，如果大部分需要共享的用户不会经常发生变动，可以尝试使用团队成员的方式来进行手工共享。

记录所属人或者有记录编辑权限的团队成员，可以同时添加其他用户作为这条记录的团队成员，记录会对所有团队成员共享。

这样即使记录所属人发生变化，其他的团队成员会仍然保留与此条记录的数据共享关系。

团队成员除了支持用户外，也需要支持部门，群组才能更灵活的支撑单条数据的共享。

9. 群组共享
团队成员共享方案，能够解决大部分需要灵活配置的单条数据共享场景，但操作比较繁琐。

如果需要频繁共享给一个虚拟组织团队，就需要在每一条数据上添加若干个，相同的团队成员，效率很低。

群组就会很好地解决这个问题，若几个用户之间需要经常共享数据，那么可以将用户们用群组圈起来，记录的所属人，可以通过将自己创建的、符合条件的数据，自动共享到若干群组中，用户也可以通过手动共享的方式，将某条数据共享到群组中。

而只有群组成员才能看到群组中的数据，群组一般分为公用群组和私用群组。

公用群组是整个公司都能看到的群组，任何人都可以将数据共享到公用群组中。
私用群组是每个人独立创建的，只有群组成员可以将数据共享到私用群组中。
群组应该是可以支持嵌套关系的，比如：用户、角色、岗位、群组本身，都是可以是群组的一员。

当然处于性能的考虑，最好对类似群组套群组的这种方式，做一个层级上的限制。

群组与数据的关系应该是多对多的，也就是说，同样一条数据，可以在不同的群组中做共享。

群组数据的共享应该是独立的，通过类似其他岗位层级，直属上级相关的其他权限，是无法突破群组成员限制的。也就是说UserA是群组成员，可以看到群组的数据，但UserA的上司由于不是群组成员，所以看不到群组的数据。

10. 区域层级
对于大型企业应用场景，经常会出现销售、产品、服务分属于不同的业务单元，但需要根据不同的规则共享客户等相关资源。那么就可以创建多个区域层级，让同一个客户按照不同的层级结构共享给各个不同的业务单元。

与岗位层级类似，区域层级通常应用于地盘资源管理的数据权限划分，通过多个不同的区域维度规则，如地区、客户等级、行业、产品线。相应的数据在创建/编辑后，可以自动进入到符合规则的区域。

通过一些级联跟随分配的设置，数据下的相关数据也可以同时进入到相同区域，比如客户下的订单，订单下的回款单等。

数据进入到区域后，区域成员就可以看到数据了。

一般来讲，区域权限分为2级，Object、Hirerachy。

Object 业务对象级权限，说的是一个区域成员针对于具体的业务对象，是什么权限。比如针对于客户，是查看还是编辑?
Hirerachy 层级权限，是说针对于业务实体，除了本级区域的权限，是否也具备下级区域的权限。
针对于单个区域，若有业务需要，也可以添加 Record 级别的权限，类似于记录所属人。

针对于每一个区域，也可以设置这个区域的记录负责人（Territory Record Owner），这样对于基于区域管理的业务属性来讲，可以将记录做到最灵活的配置。

三、如何应用数据权限

回到最初提到的问题，他们的深层考虑是什么?

如果这条数据是我自己创建的，那么其他能看到这条数据的人都有谁?

对于很多企业来讲，从数据隐私安全的角度考虑到数据权限问题，是很重要的命题。

对数据权限因果链条的掌握，可以对整个数据权限体系的优化，起到至关重要的指导作用。

“小王已经从A事业部转岗，还能通过助理权限看到B事业部的客户呢，应该马上取消小王的权限。”
“小张是C事业部的销售成员，通过群组权限看到他本应看到的客户，而不是岗位权限看到这个客户，看来客户的分配逻辑有一些问题。”
有人想知道，我为什么能够看到这条数据?

当用户看到这条数据时，通过看到这条数据的原因，可以快速的找准自己的职责定位。

因为我是这个客户的团队成员，那么我需要对这个客户的培育投入精力。

这个客户是我下属自拓的一名新客户，那么我需要对其给予帮助。

更重要的是，经常的审视数据权限体系的因果关系，也会对业务本身认识得更清晰，优秀的数据权限体系，甚至可以优化公司的业务运营体系，让效率提升自下而上的发生。

那么问题来了，既然优秀的数据权限体系，可以提升管理效率，那有没有什么设计原则是可以遵守的？

或者说作为一个公司业务运营的管理者，到底应该怎么设计公司的数据权限体系呢?

在我们设计权限体系的时候，都是用各种概念将具体的权限，通过满足特定业务场景的方式包装起来。

我们把包装起来的这样一个个的概念，可以称之为 “权限媒介”。

权限媒介在自身属性上，分为三种类型：

（1）Owner

独立媒介，比如记录所属人，岗位层级。

可以自主的满足所有的权限结构；
可以包含其他权限体系。
（2）Child

子媒介，比如群组，区域。

可以自主的满足所有的权限结构；
可以被特定的Owner媒介包含；
可以包含其他权限体系。
3. Element

原子媒介，比如助理/直属上级从属于部门层级。

可以理解为内部权限媒介；
仅可以包含其他原子媒介。
权限媒介的自身属性类型可以帮助我们认识到，权限体系的设计是整体的，而不是混乱的。

一个媒介已经被定为成Element，就不要同时还具备Owner的属性，不然可能虽然一时解决了问题，但今后的扩展会无比艰难。

权限媒介在使用场景上，分为两种类型：

（1）有规则的

比如共享规则，岗位层级。

根据公司的业务需要，总结出来的数据共享场景；
可节省大量的权限共享设置成本。
（2）无规则的

比如团队成员，手工共享。

人为认定的数据权限共享场景，提前无法认知；
规则设置成本，超过了使用成本。
权限媒介的使用场景类型，可以帮助我们认识到，权限的灵活性，要把“人”的判断纳入到整个体系中来。过高的设置成本不但会加大业务的复杂度，而且也会让“人”失去控制感。

相信了解了权限媒介的自身属性和使用场景之后，那我们就可以试着总结出一套适合自己公司数据权限体系架构的最佳实践原则。

让我们一起创造“有良好扩展性，并让人有灵活掌控感”的数据权限体系吧。