数据权限设计思路_权限设计数据权限

 任何一个系统中，都离不开权限的设计

权限设计 = 功能权限 + 数据权限+字段权限

【功能权限】：能做什么的问题。如查询、增删改信息【数据权限】：能看到哪些数据的问题。如查看本人、部门团队、区域或者整个公司、甚至整个系统的数据【字段权限】：能看到哪些信息的问题。如联系人姓名，但是不能查看到联系人地址、联系人电话这样的

1.功能权限设计

        常常是基于RBAC(Role-Based Access Control)的一套设计方案

2.数据权限设计

2.1数据权限设计分析

        根据不同的业务场景，则权限却不尽相同，应该根据具体的场景巧妙设计；且必须在项目开始时进行设计，不像功能权限一样，在项目结束的时候在追加。数据权限做不到组件级别，必须在项目设计阶段就已经规划好。之前看网上相同有人想基于SPRING切面的原理去实现数据权限，这样就能够做到了低侵入、低耦合，想法非常好。但是现实非常骨感，这样做使整个应用系统效率大减折扣，相同对数据权限的控制策略也非常不灵活。

2.2SQL语句可扩展，数据权限设计分析
        数据权限往往作为功能权限的高级行为。能够从数据对象的幅度方面进行控制。比方用户仅仅能看自己的订单、普通会员看不到某数据对象的高级属性(字段)等等。颗粒度这么细的情况下对结果集处理显然是不可能了，这时仅仅能介入到SQL语句中，此时又不想在开发阶段让开发者过多的考虑数据权限的问题，这个时候就需要将sql 和数据权限策略分开。再调用接口的时候，进行数据权限接口的拼接。这样也算做到的代码的低侵入。

        数据权限模块的核心之中的一个就有SQL语句的高效解析处理，SQL处理指依据当前登录人信息及数据权限策略生成一个带有数据权限处理结果的SQL语句。所以这里对SQL语句的解析处理必需要求精确、准确。在开发阶段由开发者把SQL写入到配置文件里，在执行阶段由数据权限取得该SQL进行分析处理(加上数据权限)，这样就完毕了SQL的组装处理。

2.3方案

2.3.1 方案一：按照岗位体系建立数据权限

把权限赋予岗位，再把员工(用户)放在岗位上，从而间接把权限赋予用户。

        有的企业的数据权限很简单，就是普通员工只能看到自己的数据，部门负责人可以看到本部门的数据，高层管理可以看到所有下级部门的数据。这样可以把这套规则直接写死在系统里面，然后根据员工的任职岗位和部门去读取对应的数据范围即可。

此方案的典型适用场景就是销售管理系统、客户关系管理系统(CRM)

特点：数据权限的划分严格按照员工岗位体系划分

优点：设置简单，只需要录入需要限制的单据，选择是按照部门或者按照下属来限制即可。

缺点：需要维护一套岗位体系；不够灵活，无法查看跨部门的数据、上级领导的数据等

也就是说，使用岗位体系数据权限只有两种结果，要么受岗位体系限制，要么没有限制(能看到所有数据)， 其他需要限制但不是按照岗位体系限制的需求，则无法满足

比如有些集团中心的财务、人事等岗位，需要看到整个集团的数据，但是他们又不是集团领导，其他人也不是他们的下属，这种情况岗位体系数据权限是满足不了的

2.3.2 方案二：针对角色设置数据权限

把权限赋予角色，角色叠加到用户上，从而间接把权限赋予用户。

角色和岗位相比，有两个好处：1、岗位是在企业组织架构里面设立的，不能随意修改，但是角色是可以灵活设置的，比如可以设置一个“华南大区报销负责人”的角色，但是这个岗位在企业组织架构中不存在，所以不能设立这样一个岗位。2、角色可以多个叠加，比如张三又负责华南大区的费用报销，又负责华东大区的费用报销，就可以把“华南大区报销负责人”和“华东大区报销负责人”两个角色都赋予张三。但是岗位上张三是一个“报销专员”，并没有身兼多职。

所以，角色比岗位要灵活很多。

将单据中的每一个字段都作为一个数据权限对象，然后对这些字段设置比较条件，这些比较条件组合起来就形成一个针对该单据的数据规则。每一个数据规则有一个名称。

比如，我们可以设置一个数据规则，条件是：客户所在地区等于A，并且，客户状态为待续签。那么这条数据规则就可以看到A地区待续签的客户，我们可以把它命名为“A地区待续签”。

所以，数据规则其实是某张单据的一个数据范围，也就是某部分的数据。

比较条件可以设置变量，比如客户的业务员为“当前用户对应的业务员”，更灵活更方便维护。

设置好数据规则之后，我们把这个数据规则跟角色关联起来，就可以限制该角色能看到的数据范围了。

如果不设置数据权限，则默认能看到所有数据。

如果有多个角色赋予同一个用户，且不同角色的数据权限不同，则取范围的并集。

此方案完美解决了方案一的问题，可以通过设置角色的权限来灵活地控制每一个用户的权限，满足很多特殊化的场景。

缺点：1、需要维护用户的角色；2、数据规则虽然可以用变量，如果是多层的计算逻辑，则无法满足。

2.3.3 方案三：岗位数据权限和角色数据权限的结合

企业的数据权限需求，无非就两种，有些数据是基于岗位体系划分数据权限的，有些数据是需要灵活设置的。所以我们把方案一和方案二结合起来，就形成了适用性更高的方案三。

此方案中，可以对角色设置岗位体系数据权限，同时还可以对角色设置其他的数据规则。也就是说，岗位体系数据权限和数据规则权限可以灵活切换、叠加来设置。

有的人可以只按照岗位体系数据权限来限制，有的人可以只按照数据规则来限制；有的人还可以又有岗位体系数据权限，又有数据规则权限。

如果同一角色同一单据，又设置了岗位体系数据权限，又设置了数据规则权限，则取两者的交集。

举例：

企业内所有员工都要使用费用报销模块，要求普通员工只能看到自己的数据，领导可以看到直属下级的数据。同时集团的财务张三负责华南和华东的费用报销，李四负责华北和华中的费用报销。

此时可以设置三个角色：

角色“岗位费用报销”，设置岗位体系数据权限，选择直接下属，并把角色赋予除张三和李四外的所有用户。则这些用户可以看到自己的数据及自己直接下属的数据。(普通员工没有下属，只能看到自己的数据)。

角色 “华南和华东的报销专员”，设置了数据规则为“报销部门为华南 或 报销部门为华东”，该角色赋予张三。

角色 “华北和华中的报销专员”，设置了数据规则为“报销部门为华北 或 报销部门为华中”，该角色赋予李四。

普通员工和领导有岗位体系数据权限，财务张三和李四有数据规则数据权限。

方案三综合了以上两者的优点，更加灵活便捷。很少企业是完全按照岗位体系来划分数据权限的，也很少企业所有的数据权限都可以用数据规则来限制，大多数是两种需求都有的情况。所以方案三的适用性更好，更适用于全员应用的系统。

方案都有好坏，主要是看不同的系统及企业权限管理需求。核心方案是：数据范围划分清晰、准确，设置灵活、维护成本低。

数据是一个企业最重要的资产。很多企业之间的竞争，其实也是数据之争，资源之争。数据权限，就如同为数据筑起的一座座城墙，清晰地划分了用户能看到的数据范围，为数据提供安全保障。