基于组织架构的数据权限模型OBAC设计与实现

基于组织架构的数据权限模型 OBAC设计与实现

吴军荣

中煤航测遥感集团有限公司，陕西省西安市， 710199

摘要：本文针对基于角色的功能权限管理模型RBAC控制粒度粗，不足以满足现代MIS系统复杂、精细的数据权限管理需求，而参考其设计思想设计出一种基于组织架构的权限管理模型策略OBAC(Organization-Based Access Control)。该策略创新性地引入组织架构数据信息，配合传统RBAC权限管理策略，实现了功能权限加数据权限的双重管理和过滤，达到了数据精细化管理要求，能够满足复杂环境下企业对敏感信息数据权限的管理要求，能够提高系统数据的安全性和灵活性。本文给出了该模型的设计和实现方法，对于具有多层次数据权限管理需求的系统软件权限管理的设计和开发具有参考价值。

1.前言

随着我国信息化产业的高速发展，信息系统覆盖的领域广泛，涉及到各行各业。同时信息系统的功能愈加复杂，使用的客户群愈加庞大，客户需求愈加复杂，随之而来的问题就是针对系统数据安全的管理愈加困难和复杂。因此，信息系统引入访问控制功能将是一个不可或缺的步骤，尤其是在金融、国防、能源、民生等行业，保证信息系统的安全将是首要考虑的问题，利用访问控制极大降低了系统的安全风险，同时监管对敏感信息的访问以及防止非法用户的入侵^[1]。

目前信息系统主要是通过用户、角色、资源三方面来实现系统的访问控制。具体来说，就是赋予用户某个角色，角色能访问及操作不同范围的资源。通过建立角色系统，将用户和资源进行分离，以保证权限分配的实施。根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。从控制类型来看，可以将权限管理分为两大类：功能级权限管理与数据级权限管理。功能级权限与数据级权限协同才能实现完整、精细的权限管理功能。目前功能级权限有多种成熟方案可供选择，但数据级权限管理方面，一直没有统一的技术方案。本文将介绍一种数据权限实现技术方案，并且通过在多个信息系统上的应用得到论证。

2.访问控制系统与RBAC简介

访问控制（RAM）是信息系统提供的管理用户身份与资源访问权限的服务，信息系统可以创建并管理多个身份，并允许给单个身份或一组身份分配不同的权限，从而实现不同用户拥有不同资源访问权限的目的。要实现访问控制，需要有主体，客体，还有一定的策略或者叫机制。

主体：访问的发起者，可以是访问系统的某个用户也可以是调用系统的外部服务。

客体：可供访问的各种软硬件资源，如文件、数据库数据、服务资源等。

策略：定义了主体对于客体的访问权限策略，不同的策略模型下有不同的访问控制管理模式。常见策略有自主访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）。

DAC允许合法用户以用户或用户组的身份访问策略规定的客体，同时组织非授权用户访问客体，某些用户还可以把自己拥有的客体的访问权限授予其他用户；MAC按照系统级策略限制主体对客体的访问。用户所创建的资源，也拒绝用户的完全控制。系统的安全策略完全取决于权限，权限由管理员设置^[2]。RBAC是将权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便，因而信息系统大多使用RBAC模式作为功能级权限实现策略^[3]。

图1 RBAC设计模式

RBAC设计模式如图1所示，每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现非常灵活的权限管理。角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。简单来说RBAC就是：用户关联角色，角色关联权限。

RBAC的缺点也比较明显：RBAC只关心在用户和权限之间的关系设计，并没有考虑到用户和权限之间的判断，恰恰这种情况在在实际的MIS系统中非常常见，比如在销售领域华东区域经理无权查看华北区域销售数据虽然都是区域经理角色，其只拥有查看本地区销售数据权限，又比如在管道信息化系统中各个油气场站只能查看各自场站的生产数据，无权查看其它场站生产数据，虽然其都是场站角色。

图2 完整权限集合

完整的权限集合示意图如图2所示，应当包含对象、操作和数据三类权限。对象访问权限：MIS系统中是指拥有菜单的权限；操作权限：MIS系统中是指菜单的操作，例如某菜单下的新增、编辑、删除等操作权限；数据可视权限：MIS系统中是指菜单的数据权限，不同的数据权限客体进入某个菜单后看到的数据范围不同。可以看到，RBAC是只涉及了对象和操作权限，没有涉及到数据可视权限。

3.数据权限OBAC模型介绍

数据权限管理主要控制某条数据记录对用户是否可见，结合功能权限可以更灵活的配置业务过程中用户的功能操作权限及数据可见范围。目前，并没有统一的数据权限策略模型，通常有下列做法：

（1）硬编码，也就是将这种逻辑以if/else等形式与业务代码耦合在一起，这种情况居多；

（2）使用第三方专业软件或开源中间件；

其中，硬编码形式弊端是非常显然的，耦合性强、测试困难、系统组件复用率低、系统后期改动代价大，牵一发而动全身；第三方专业软件则无法定制化，并不适合通用应用系统且通常价格昂贵，学习成本高。

本方法中将企业组织与数据权限规则进行结合，实现隶属不同组织下的用户主体访问同一个权限对象后看到的数据范围不一样，既实现了数据权限管理功能又与RBAC的功能权限解耦合相互独立，互不影响，做到真正意义上的可插拔设计，动态组合。把组织信息与数据权限规则进行关联，用户主体加入组织后，就会自动获得该组织定义的数据规则，解析规则后过滤出该规则下的数据。

规则解析是模型的重点，规则解析是将数据权限规则翻译为数据库执行语句的过程，规则解析是在应用程序利用JDBC连接数据执行QUERY语句前，拦截原始SQL语句，将规则解析后的SQL片段语句织入原始SQL中并执行，利用动态修改SQL执行语句方式实现数据规则过滤。

组织：企业职能部门，如市场部、软件部、工程部等等，是企业MIS信息系统的基本要素。

数据权限规则：定义可访问或不可访问数据范围。本方法规定了四种范围：本人、本部门、指定部门、所有部门。不同的范围能看到的数据不一样，通过解析规则，获取或过滤特定标签的数据。

数据标签：标识数据隶属于某部门的信息。

规则解析：翻译数据权限规则，生成SQL片段，最终将SQL片段织入原始SQL中并执行。

图3 OBAC设计模式

OBAC设计模式如图3所示，用户主体关联部门信息，部门信息关联数据权限规则集，规则集过滤数据集特定标签数据。

3.1数据标签

数据标签标识了数据源信息，只有具备标签，该条数据才可能被规则集中规则匹配，信息系统中不应该出现没有标签的数据条目，也可以设定虚拟标签标识不能被清晰标定的数据条目。标签使用两个信息即可满足：隶属人、隶属部门。隶属人标签可以被规则集中“本人”规则解析，隶属部门标签可以被规则集中“本部门”、“指定部门”规则解析，两个标签均可被“全部”规则解析。

图4 数据标签关联关系图

数据标签关联关系图如图4所示。通常，MIS系统中“用户”实体与“部门”实体有关联关系，例如一对一关系，因而通过用户能获取到用户所属部门信息，从而标签“隶属人”与“隶属部门”原则上可以简化为“隶属人”标签，但是现实情况下经常出现人员在部门间的变动问题，如果仅仅使用“隶属人”标签，则会导致该条数据在人员部门变动前后规则过滤不一致的现象。为了保证数据的前后一致性，需要冗余存储“隶属部门”标签。

3.2数据权限规则

数据权限规则是对组织机构下拥有何种数据可视权限的定义，在本方法中一共定义了四种规则，分别是本人权限、本部门权限、其他部门权限、所有权限。本人权限仅能查看带有本人数据标签数据，本部门权限能查看带有与本人同部门组织的数据标签数据，指定部门权限能查看带有配置中选定的一个或多个部门组织数据标签数据，所有权限则不带限制条件，无视数据标签。

实现数据规则逻辑定义后还需要实现其物理定义，即将规则编码到存储系统中，并可以被读取解析。本文采用关系型数据库将规则存储到数据库系统中，数据表结构设计规则定义表如表1所示，规则定义表附表如表2所示。

表1 规则定义表

表2 规则定义表附表

其中，规则定义表用于定义组织（部门）的数据规则信息，指定组织（用organize_id标识）所拥有的数据权限范围（用rule_type标识），一对多关系。定义表附表是针对数据权限范围为指定部门规则时的扩展表，存储指定的部门主键集合。如此，针对四种规则有四种查询方式。当规则为本人时，直接获取用户信息的主键；规则为本部门时，直接获取用户信息表中的部门字段；规则为指定部门时，需要关联查询规则定义表附表中的数据，获取部门主键集合；规则为所有时，不用作任何处理。

3.3规则解析

本模型最终是将规则解析为一个SQL片段，然后动态地织入原始查询SQL的WHERE子句中，利用WHERE子句提取那些满足指定条件的记录。根据数据库方言不同，解析的SQL片段也就不同，这里以MySQL关系型数据库为例，分别介绍四种规则的解析过程。

根据上文信息，假定信息系统拥有如下数据表：用户表user（id，username，organize_id）、组织表organize（id，organize_name）、规则定义表rule（id， organize_id, rule_type）、规则定义附属表rule_addition（id、rule_id，organize_id）以及目标数据信息表data（id、belong_user_id，belong_organize_id、其它信息字段略）。当前登录用户id用current_user_id标识，当前登录用户组织部门id用current_user_organize_id标识，原始查询data表数据SQL语句为：select * from data。

（1）根据规则定义表，如果是本人数据规则，即查询语句select type from rule where organize_id = current_user_organize_id结果为type=1时，解析的SQL片段为belong_user_id = current_user_id，织入原始sql的WHERE子句后为：select * from data where belong_user_id = current_user_id。

（2）根据规则定义表，如果是本人数据规则，即查询语句select type from rule where organize_id = current_user_organize_id结果为type=2时，解析的SQL片段为belong_organize_id = current_user_organize_id，织入原始sql的WHERE子句后为：select * from data where belong_organize_id = current_user_organize_id。

（3）根据规则定义表，如果是本人数据规则，即查询语句select type from rule where organize_id = current_user_organize_id结果为type=3时，需要关联查询附属表获取具体的组织信息，最终解析的SQL片段为：select ra.organize_id from rule r join rule_addition ra on r.id = ra.rule_id where r.organize_id = current_user_organize_id，belong_organize_id = current_user_organize_id，织入原始sql的WHERE子句后为：select * from data where belong_organize_id in ( select ra.organize_id from rule r join rule_addition ra on r.id = ra.rule_id where r.organize_id = current_user_organize_id，belong_organize_id = current_user_organize_id )。

（4）根据规则定义表，如果是所有数据规则，即查询语句select type from rule where organize_id = current_user_organize_id结果为type=4时，无需任何解析，直接执行原始SQL即可：select * from data。

通过上述对规则的解析以及对原始SQL的织入，利用WHERE查询子句实现了数据权限过滤功能。

4.数据权限OBAC编码实现

根据上文方法生成数据权限规则SQL片段后，还需要设法拦截原始SQL过程，同时分解该SQL语句为基本层次结构，并在合适的条件层次上添加SQL片段，生成新的SQL后发往数据库进行执行。

4.1拦截SQL织入规则

本方法的实现需要拦截原始SQL，并分解SQL为层次结构，将数据权限规则解析成SQL片段后织入到指定的层次中并执行。因此需要一个分解SQL的工具。

JSqlParser便是这样一个SQL语句解析器。它在可遍历的Java类层次结构中转换sql。不局限于一个数据库，它支持Oracle, SqlServer, MySQL, PostgreSQL等。JsqlParse是一款基础工具，通过javaCC这个程序生成sql的语法和词法。作用有两个，一是解析sql到java对象，二是按照允许的规则和层次构建java对象后，将其生成sql。JsqlParse只有解析和生成的功能，没有任何业务或者具体功能。举个例子，比如select * from data where id = '1' limit 1这个sql，它便解析成一个查询java对象，然后这个对象里有查询的字段名，查询的表名，查询的条件，limit以及order等的内容。只需要捕获到查询条件添加SQL片段后生成新的SQL即可完成。

4.2 SQL拦截器

规则解析过程完成后需要系统实现在执行过程中拦截原始SQL并进行织入SQL片段过程。本文选择的拦截器为MyBatis拦截器。Mybatis拦截器设计的初衷就是为了供用户在某些时候可以实现自己的逻辑而不必去动Mybatis固有的逻辑。通过Mybatis拦截器可以拦截某些方法的调用，可以选择在这些被拦截的方法执行前后加上某些逻辑，也可以在执行这些被拦截的方法时执行自己的逻辑而不再执行被拦截的方法。因此利用Mybatis拦截器实现数据权限过滤操作非常适合。

表3 Mybatis核心对象

Mybatis核心对象如表3所示，利用Mybatis拦截器实现数据权限过滤实现步骤：

（1）利用MyBatis拦截器，编写自己的拦截器类，选取合适的过程进行sql拦截，得到将要执行的原始的sql；

（2）从当前请求中获得当前登录的用户的信息，用户id和用户所属组织id；

（3）根据当前用户信息查询其拥有的权限数据，解析规则，生成sql片段；

（4）利用JSqlParser解析原始sql，获得层次结构；

（5）根据权限数据拼接sql并修改原sql：规则织入；

（6）执行修改后的sql。

以上，通过mybatis拦截器配合数据规则解析、织入过程，实现对原始SQL的动态修改过程，达到数据权限过滤要求。

5.结论

文本弥补了传统RBAC的粗放权限模式的不足之处，提出了基于组织架构的权限管理模型策略OBAC(Organization-Based Access Control)，下沉权限功能实现了数据权限精细化管理。文章提出了基于该模型的设计模式、实现原理、数据库设计、编码实现一系列过程。OBAC与RBAC相结合，提高了权限控制粒度，有效地提升了数据方面的安全性与灵活性，在满足客户需求与权限应用开发方面提供了有力支撑。

6.参考文献

[1] 游传强.大型企业集团信息系统的安全防护[J].网络安全技术与应用,2017(2):111-112.

[2] 余杨奎.基于角色的访问控制模型(RBAC)研究[J].计算机技术与发展,2018,29(1):198—201.

[3] 金刚波.基于RBAC模型的通用权限管理系统的分析与设计[J].商情,2013(52):342-343.