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

基于组织架构的数据权限模型 OBAC设计与实现摘要：本文针对基于角色的功能权限管理模型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 typefrom 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 typefrom 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。