数据权限问题的几种处理和思考

背景

在权限管理中一般分为两类：操作权限、数据权限

操作权限：是用户是否能使用某个功能的接口权限。
数据权限：是用户是否能操作某个范围的数据，例如：订单记录修改接口，“用户”只能修改所属的（用户A不能修改用户B的订单记录），“admin”可修改所有的。

现有权限管理一般是基于RBAC（Role-Based Access Control）模型，都只能解决操作权限的控制，即使粒度再小（如把订单权限划分为增、删、改、查权限）也不能解决数据权限的问题。

操作权限与数据权限的关系，下面是个例子：

admin和张三（员工）都有公寓大门的钥匙，他们都能进入公寓（访客不能进入），虽然他们都能进公寓但他们管理但房间是不同的，张三只能使用自己的房间，管理员可以使用所有的房间，如果张三使用了其他人的房间就会引发问题——数据权限安全问题。

那么如何在已有的权限管理模型下对数据权限进行管理是数据安全难以避免的问题。

数据权限问题的解决

数据权限问题的来源

不属于用户拥有的一条或多条数据被非法操作。

解决方式

1、通过业务逻辑对数据所属进行验证，因为不同业务对数据安全性有不同的需求，这种是常用方式
2、通过框架验证，这种一般要提前在安全框架中设计好，通常想要设计成通用的比较难

解决方案

关键点：将数据的拥有信息（数据所属）与用户绑定，然后进行校验。
绑定需要记录用户所属信息，例如：存储数据A的owner为张三或单独为一个所属关系表；验证是查询是否为所属。

数据权限操作的数据由于业务的不同会呈现不同复杂程度（一条/多条/混合…)，暂先以下修改订单记录为例子：

api/modifyOrder?orderId=123;

方案1：

在web层进行验证，获取session的用户信息与数据库的信息进比对，判断是否有权限操作，记录所属用户则允许操作。
分析：
1）针对单条件、少量记录的情况，如果是复杂的数据会牵扯更新多个表就不好判断（这种情况以一个表的记录为基准）
2）如果这个数据是共享的，这种方式查询开销会增大
3）需要查询数据库
优点：优点实现简单；
缺点：只能针对简单数据操作权限进行管理，存在查询开销，当数据复杂查询开销进一步增大

方案2:

在修改信息时，通过sql验证是否对数据所属 where owner=zhansan，如果不符合则不会对数据进行修改，修改与否可以通过sql记录更新数据判断。

分析：
1）针对单条记录，一个表中对记录；数据不复杂对情况
2）避免了数据库查询
3）数据存在共享但情况需要做连表查询，否则就又回到了查询数据库

优点：避免了查数据库
缺点：针对单条记录，同表中但记录；共享数据记录需要做连表查询

方案3:

用户修改这个数据之前必定先查询出来，将查询数据信息（查询出认为有权限)与当前用户sessionId绑定生成token，请求时带上token，后端操作时拿当前用户sessionId与数据信息（如orderId）生成token进行比对，判断是否是同一个人操作。

api/modifyOrder?orderId=456&token=ABCSXXXXXX

案例：

用户1 orderId=123 token=ABC1（123+用户1的sessionId）
用户2 orderid=456 token=ABC2 （456+用户2的sessionId)

用户2篡改用户1订单请求情况：
1） api/modifyOrder?orderId=123&token=ABC1 // 用户1的orderId和token
2）api/modifyOrder?orderId=123&token=ABC2 // 用户1的orderId、用户2的token

后端处理情况：
1）生成token（123+用户2的sessionId）与传入token（123+用户1的sessionId）比较，不匹配拒绝
2）生成token（123+用户2的sessionId）与传入token（456+用户2的sessionId）比较，不匹配拒绝

分析：
1）使用情况：针对单条记录，或一次表单修改时
2）将数据权限和当前用户绑定并抽象出一个token

优点：避免了查询数据库或数据库计算开销（where owner=zhansan）
缺点：前期需要查询配合生成token，因此业务复杂性增加了

总结

1、数据权限操作往往和业务牵连比较大，通常在业务中判断处理
2、当数据复杂时数据权限不好控制，会伴有大量的验证操作

参考

1、https://www.cnblogs.com/hnsongbiao/p/3752617.html
2、https://www.jianshu.com/p/ed39d9bc6798
3、https://coolshell.cn/articles/19395.html