业务思考｜数据权限问题

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

操作权限：是用户是否能使用某个功能的接口权限。 数据权限：是用户是否能操作某个范围的数据，例如：订单记录修改接口，“用户”只能修改所属的（用户 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、当数据复杂时数据权限不好控制，会伴有大量的验证操作

其他方面及不足：

只是简单讨论了数据权限方面，没有联系安全框架 security、shiro 和流行的认证授权协议。

参考

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