多源对象关系数据库细粒度强制访问控制机制实现方法

2021-12-14陈晓娟

计算机应用与软件 2021年12期

缪燕孙燕陈晓娟宋伟

1(北京许继电气有限公司北京 100085)2(武汉大学计算机学院湖北武汉 430074)

0 引言

数据库技术作为计算机系统软件，一直以来都是信息系统中数据存储的核心。传统关系数据库具备坚实的理论基础、完备的配套工具和灵活的数据表达能力，因此以关系数据库为代表的传统数据库系统在产业领域取得了巨大成功。

随着计算机技术的发展，数据存储管理变得越来越重要，无论从数据规模还是数据管理复杂度上都对数据存储和管理提出了越来越高的要求。近年来数据库已经应用到众多新兴应用领域，如社交网络、移动数据、地理信息系统、图数据管理等，各种半结构化、非结构化数据的内在特征和服务特性都使得传统关系型数据库效率低下甚至无能为力。关系数据库具有统一的数据存储和处理规范，在管理结构化数据方面具有优势，但是在表达复杂语义方面则显得效率低下。

面向对象模型及面向对象操作的出现，弥补了关系数据库基于关系对象操作在复杂语义表达性和复杂语义操作方面存在的不足。但是面向对象数据库由于对数据对象进行结构化封装，又使得对象数据库存在数据冗余大、数据表达灵活性差等缺点。为克服关系数据库和对象数据库的不足之处，出现了对象关系数据库。对象关系数据库具有关系数据库表达灵活、理论完备的优势，又支持面向对象特征的数据操作，具有语义表达能力强、数据对象存储持久等诸多优势。

近年随着大数据应用的发展与普及，对象关系数据库受到越来越广泛的关注，知名的开源数据库系统PostgreSQL就是一种对象关系数据库系统。PostgreSQL数据库在复杂数据管理领域扩张迅速，已被广泛应用于地理信息系统、云数据库、图数据管理等诸多领域，但对于PostgreSQL的数据访问授权管理则显得有些滞后。

数据访问授权是信息系统的基本核心功能，也是网络安全等级保护的重要组成部分。传统商用关系型数据库如Oracle、SqlServer、DB2等都有一整套完备的数据访问授权逻辑和实现，但是在对象关系数据库中(以最新版PostgreSQL12为例)仍没有严格意义上完备的强制访问控制。这给对象关系数据库系统在更多商业领域应用造成了巨大困难。

如何基于对象关系数据库的数据模式和服务特点，设计适用于对象关系数据库的强制访问控制模型成为亟需解决的理论和应用问题。本文以PostgreSQL为研究对象，设计并实现了一种对象关系数据库环境下的强制访问控制方法，该访问控制模型实现了完备的强制访问控制逻辑，同时支持多数据源、细粒度授权的特点，通过在PostgreSQL12中的实验证明，设计的强制访问控制方法具有授权访问灵活、数据维护开销小的优点。

1 相关研究

20世纪70年代，Bell等[1]首次提出可证明安全的强制访问控制模型，称为Bell-La Padula(BLP)模型，该模型针对操作系统安全，最初主要应用于军事安全策略实现。此后，为了优化BLP模型，避免引发因使用强制访问控制模型而造成的隐通道问题，国内外的学者们提出了多级安全关系数据模型，其中包括Sea View模型[2]和Jajodia-Sandhu模型[3]等。

在BLP强制访问控制模型中,实体被分为主体和客体，每个实体都被赋予了相应的安全等级。模型通过比较主体和客体的安全等级来决定主体对客体的操作授权[4]。在BLP模型中，主体不能读安全等级比自己高的客体，也不能写安全等级比自己低的客体。因此，信息只能从低安全级向高安全级流动或者在同安全级之间流动，有效防止了由低安全等级的用户读取高安全等级的数据造成的信息泄露。然而当BLP模型的读写规则应用在数据库系统中的时候，低安全等级的用户拥有写高安全等级数据的权限，可能因此造成不恰当的重写操作，给数据安全带来隐患[5]。为此研究者们提出了改进的BLP模型，只有当主体的安全等级和客体的安全等级相同时，主体才能对客体进行写操作，从而避免了低安全等级用户对高安全等级数据重写所造成的问题。

除此之外，为了能让BLP模型更好地应用于数据库系统，出现了各类改进工作。文献[6]对BLP模型进行进一步优化，使其契合属性安全值的特点，形成一个灵活的基于属性安全值的强制访问控制模型。文献[7]基于BLP模型提出了一种具有自主控制特性的强制访问控制模型。文献[8]从安全模型构建入手,对智能终端的Web操作系统进行抽象建模,并重定义BLP模型的元素,增强主客体的访问控制以提高其机密性。

Sea View模型引入了多实例和多级关系。多实例和多级关系的存在解决了由于主键唯一性导致的隐通道问题。但因Sea View安全数据视图模型标识粒度较细并定义了完整性规则，这导致一个写操作会产生多个元组，且元组个数可能达到非关键字属性个数的指数级，这些元组中得到属性的产生是不合逻辑的。同时，其多级关系存取的处理也会严重降低系统的性能。

针对Sea View安全数据视图模型中存在的问题，Jajodia-Sandhu模型[3]重新定义了多实例完整性，并且定义了空值完整性和实例间完整性，消除了Sea View模型中的多值依赖，提高了数据安全性和完整性，并且减少了写操作产生的多实例的个数。不过由于该模型中的插入和更新操作仍然会存在着一定数量的多实例[9]。此后，Sandhu等[11]又在Jajodia-Sandhu模型的基础上，吸收了Sea View模型的优点，并引入了Simith-Winslett模型[10]中基于信任的语义概念，提出了MLR综合模型。该模型提供了元素粒度的强制访问控制，定义了数据借用关系，即高安全等级的主体可以从低安全级别的主体借用数据，不过其控制较为复杂，在实现的过程中可能存在安全隐患。

此后，国内外数据库安全领域的学者们针对各种数据库的实际安全需求进行了大量的强制访问控制研究。文献[12]提出了一个安全数据库访问控制模型，包括一个多层关系模型和一个增强自主访问控制能力的元素级粒度的授权，在多层关系模型中拓展了MLR模型，使其支持了传递借用和多值借用。文献[13]提出一种新的云计算环境中数据分布式强制访问控制算法。文献[14]提出一种协作环境下具有时空约束的强制访问控制模型，将任务、时间、空间等要素进行综合考虑，既增强了访问控制模型的安全性，又满足了协作环境下访问控制的灵活性。文献[15]采用数据库资源的染色标记方法，提出了一种基于染色标记的数据库安全强制访问控制体系。文献[16]针对实时操作系统资源少、开销小、实时性要求严格等特点，提出了一种针对RTOS的轻量级强制访问控制模型。文献[17]基于对象代理特性提出了一个适用于TOTEM数据库的强制访问控制模型。文献[18]针对SQL注入、内部人员权限滥用等非法行为，提出可信计算环境下的数据库强制行为控制(MBC)模型。

现有数据库安全访问控制研究重点侧重关系数据库环境中的数据授权访问，但是并没有考虑到对象关系数据库给数据授权带来的新问题，如数据对象之间的继承关系、数据对象的溯源操作带来的隐私泄露问题等。因此需要提出一种安全、实用的强制访问控制逻辑和实现机制，以满足目前对于对象关系数据库的巨大应用需求。

2 对象关系数据对象强制访问控制

2.1 对象关系数据库的访问控制

现有对象关系数据库的自主访问控制安全性能有限，在实际应用场景中也存在授权机制不灵活的限制。现有对象关系数据库访问控制机制存在权限管理不当，可能引发秘密数据泄露，在很多方面也存在安全隐患，并且粗粒度的访问控制也缺乏灵活性。目前的对象关系数据库访问控制中，可以进行访问控制的数据库对象的最小粒度是类，因此在PostgreSQL中使用访问控制列表无法限制数据库用户对数据库列级对象和行级对象的访问，使得PostgreSQL的访问控制机制并不能满足实际应用中细粒度访问控制的需求。

在对象关系数据库实际应用中，用户会根据不同的使用目的，生成不同类型的继承类，包括SELECTED选择型继承类、JOIN连接型继承类、UNION合并型继承类和GROUP分组型继承类。其中对于拥有多个数据源(即源类)的继承类，仅仅只在其属性上分配一个统一的安全标签可能会造成部分源类的数据无法通过继承类被合法用户访问的问题。为了让基于对象关系特性的强制访问控制模型为多源继承类提供更为方便灵活的访问控制，本文针对多源继承类在理论和实际应用方面的特性，从更细的粒度上探讨了各种继承类中属性级对象的安全等级管理，并在此基础上阐述继承类上细粒度访问控制的过程。

为方便描述访问控制规则及介绍对象安全等级管理方法，表1列出了本文中使用的符号及其意义。

表1 正文符号表及意义

在详细介绍对象关系数据库的强制访问控制规则之前，先对用到的基本概念进行定义。

(1) 安全级别序列。安全级别序列是一个有n个元素的有序序列，用SL=(sl1,sl2,…,sln)表示，其中sli(i=1，2，…，n)表示第i个元素，对于任意两个元素sli和slj，若i

(2) 类别范围集合。类别范围集合是一个有m个元素的集合，用CR={cr1,cr2,…,crm}表示，其中cri(i=1，2，…，m)表示第i个元素，对于任意两个元素cri和crj，若i≠j，则有cri≠crj。

(3) 安全标签。一个安全标签SecL由一个安全级别元素和一个类别范围集合组成，表示为SecL=sl:cr，其中sl∈SL为安全级别序列SL中的一个元素，cr为空集或者类别范围集合CR中的一个或多个元素的集合。数据库对象的安全标签表示为SecLobj=SLobj:CRobj，请求访问数据库对象的主体的安全标签表示为SecLsub=SLsub:CRsub。

(4) 安全等级。数据库对象的安全等级由数据库对象的安全标签来体现。对于数据库对象obj1和obj2，obj1的安全标签SecLobj1表示为SLobj1:CRobj1，obj2的安全标签SecLobj2表示为SLobj2:CRobj2。当且仅当SLobj1>SLobj2且CRobj1⊃CRobj2，认为obj1的安全等级高于obj2的安全等级；当且仅当SLobj1=SLobj2且CRobj1=CRobj2时，认为obj1的安全等级等obj2的安全等级。

(5) 源类。对象关系数据库中存在着继承关系，即通过特定的继承规则从源类继承部分或全部属性值，这里的源类就是继承类中部分属性的数据源。一个继承类可以有一个或多个源类，一个继承类的n个源类用集合SC表示，SC={SCi|i=1,2,…,n}。

(6) 继承类。继承类中必定会有虚属性，即根据规则从源类中继承的属性，这些属性的内容并未实际存储。同时继承类中也可以新增属性，这些属性为继承类中实际存储的实属性，继承类中的实属性个数可为0个或若干个。继承类用IC表示，继承类的第i个虚属性表示为IC.vai，继承类的第j个实属性表示为IC.raj，则继承类的安全标签表示为SecLIC=SLIC:CRIC，继承类的第i个虚属性的安全标签表示为SecLIC.vai=SLIC.vai:CRIC.vai，继承类的第j个实属性的安全标签表示为SecLIC.raj=SLICIC.raj:CRIC.raj。

(7) UNION继承类。UNION继承类合并了若干个源类中共有属性的选择型继承结果，用UIC表示，那么代表其安全等级的安全标签表示为SecLUIC=SLUIC:CRUIC。

2.2 强制访问控制安全模型

对象关系数据库强制访问控制的安全模型主要基于BLP(Bell-La Padula)安全模型，该模型如图1所示。数据库系统中的每一个数据库对象都被分配一个安全标签，这个安全标签反映了数据库对象的安全等级。数据库中除了数据库、源类、继承类等数据库对象被分配了安全标签外，源类的实属性、继承类的虚属性和实属性也被分配了安全标签。同时，对数据库进行操作和访问的主体也被授予了一个安全标签。当主体访问数据库对象时，需要比较二者的安全标签是否符合主体访问数据库对象管理规则。

图1 对象关系数据库的强制访问安全模型

2.3 基于多源数据的安全等级细化方法

在对象关系数据库中，具有多个源类的继承类有两种，分别是UNION继承类和JOIN继承类。其中，UNION继承类存在着类中不同实例的同一属性内容来源于多个源类中对应属性的内容。下面将结合具体的例子说明这种多源类继承类上在进行强制访问控制时可能出现的问题。

假设音乐网站的数据库中有两个基本类，命名为vipmusic和freemusic，分别存储付费歌曲和免费歌曲的信息。其中，vipmusic类和freemusic类中共有的属性有编号number、歌名name、歌手singer和歌曲音频内容context，不过付费歌曲的音频内容只有在用户付费成为会员后才能听到，免费的歌曲音频内容普通用户和会员都可以听到。为了方便在音乐网站的构建中对歌曲共有的属性信息进行统一的获取和处理，需要构建一个提供所有歌曲信息的更抽象的类。UNION继承类便可以满足这个需求，将vipmusic和freemusic两个基本类作为源类，创建一个名为music的UNION继承类，如图2所示。

图2 UNION继承类中多数据源属性示例

那么通过直接对UNION继承类music进行查询即可得到所有歌曲共有属性的信息。music类中继承自源类的属性均为虚属性，其扩展定义的属性comment为实属性，表示网站用户对歌曲的评论，其中music类中所有实例的虚属性内容都不是实际存储在本地的，而是通过访问源类vipmusic和freemusic中对应属性的内容而得到的，实属性的内容是实际存储在本地的。

假设源类vipmusic中，除了表示歌曲音频内容的context属性之外的所有属性安全级别为sl1，例如SLvipmusic.name=sl1，而context属性的安全级别为sl5，即SLvipmusic.context=sl5。源类freemusic中，所有属性的安全级别均为sl1，例如SLfreemusic.name=sl1，SLfreemusic.context=sl1。若UNION继承类music的安全级别也为sl1，那么有music中除context属性的以外的所有属性的安全级别为sl1，context属性安全级别为sl5。对于context外的其他属性，显然能访问源类中这些属性内容的用户也能通过UNION继承类music访问到这些属性内容。然而，只有安全级别大于等于sl5的用户才可以通过music同时访问到两个源类中context属性的内容。安全级别为sl1、sl2、sl3和sl4的用户可以访问源类freemusic中的context属性内容，却无法通过继承类music而访问到源类freemusic中的context属性内容。因此，可以看到UNION继承类上的强制访问控制在某些情况下阻止了部分拥有源类数据访问权限的用户通过UNION继承类访问源类数据，从而影响了UNION继承类在实际条件下的使用。

为了解决多源类继承类中多数据源虚属性的内容在强制访问控制模型中的访问受限问题，本文设计了多数据源虚属性的安全等级细化方法，为多源类继承类上灵活的细粒度访问控制提供支持。

对于一个UNION继承类UIC，其有m个源类SC={SCi|i=1,2,…,m}，UIC有从这m个源类中继承的n个虚属性va={vaj|j=1,2,…,n}。这些虚属性都是拥有多个数据源的虚属性，且每个虚属性的数据源为m个源类中与这个虚属性相对应的属性。

任一虚属性va的安全标签只有一个，表示为SecLUIC.va=SLUIC.va:CRUIC.va，其中SLUIC.va为va的安全级别，CRUIC.va为va的类别范围，该安全标签代表了va的安全等级。因此，UNION继承类虚属性va在所有UIC实例中对应内容都由同一个安全标签SecLUIC.va来进行访问控制。

为了支持多源类继承类UIC中多数据源属性上的细粒度访问控制，设计了UIC虚属性的安全等级细化方法，使得同一属性中来自不同数据源的属性内容拥有各自的安全等级。其具体表现为：对于有m个源类的UIC中的任一虚属性va，设置一个安全标签集SecLUIC.va，该安全标签集合中默认有m个安全标签，va中从一个源类继承的属性内容与一个安全标签对应。UIC虚属性va安全等级的细化实际上就是将UIC所有实例的va属性内容根据数据源进行划分，并为来自不同数据源的属性内容分配与之对应的安全标签。

1) 虚属性va按数据源划分。

由UIC类实例的介绍可知，UNION继承类中的所有类实例集合表示为TUIC，将TUIC按照实例对应源类实例所属类的不同进行划分，可以得到：

2) 虚属性va多安全标签分配。

对TUIC.va中包含的其他m-1个分组，都按照相同的方法为其分配安全标签，可以得到UIC中虚属性va的安全标签集合为:

各个安全标签和虚属性va按数据源进行划分后的各个分组为一一对应关系。

为了进一步说明多源类继承类中虚属性的安全等级细化方法，下面将结合实际的例子对安全等级细化方法进行具体的介绍。此处同样以图2的UNION继承类music为例，对于其中的虚属性context，由于其内容继承自两个源类，因此context的属性内容可以划分为两组，分组结果表示为：

为每个分组分配安全标签以表示来自数据源的属性内容的安全等级，由于此例中各级对象的类别范围CR均未设置，因此安全标签的内容只需考虑安全级别SL，则有：

经过以上处理的UNION继承类中context虚属性的安全标签由之前的单一安全标签变成了一个安全标签集合，图3直观地展现了music继承类中虚属性context安全等级细化后的结果。

图3 多数据源属性安全等级细化示例

通过对同一虚属性中来自不同源类的属性内容进行划分并添加安全标签，多源类继承类UIC中同一虚属性继承自不同数据源的属性内容以分组为单位拥有了各自的安全标签，从而实现了多源类继承类中虚属性的安全等级细化。

2.4 细粒度访问控制机制

当数据库用户企图访问UNION继承类中的虚属性va中的部分属性内容时，细粒度访问控制机制可以通过获取待访问属性内容对应的一个或者多个安全标签进行更为具体的访问控制。其具体过程为：

(1) 获取请求访问多源类继承类的用户的安全标签SecLsub，得到其安全级别SLsub和类别范围CRsub。

(7) 在初步访问结果PreResva中属性va的所有属性值都经过以上判断后，若PreResva=∅，则不返回任何va属性内容给用户。否则，将初步访问结果PreResva中剩余的属性内容作为最终访问结果返回给用户。

为了进一步说明多源类继承类中的细粒度访问控制机制，下面同样将结合图3中已进行虚属性安全等级细化的UNION继承类music为例，对多源类继承类中进行细粒度访问控制的流程和方法进行介绍。

假设音乐网站上有一普通用户user，并且该普通用户的安全标签为SecLuser=SLuser:CRuser，其中安全级别SLuser的内容为sl3，CRuser的内容默认为空。用户user请求访问UNION继承类music中歌曲名字包含“晴天”的歌曲内容。则采用细粒度访问控制机制对用户user的访问请求进行控制的流程如下：

对初步访问结果PreRescontext中的context虚属性内容依次进行访问权限判定后，PreRescontext={r18.context，r57.context}表示初步访问结果经过访问权限筛选后仅剩下music继承类中第18个实例和第57个实例中的context属性内容。最后，将PreRescontext作为访问结果返回给用户user。

由以上介绍可知，多源类继承类中属性级对象的强制访问控制可以细化到具体的属性内容，用户可以访问在多数据源属性中其安全等级可以访问到的所有数据，而属性上安全等级高于用户安全等级的属性内容则不会包含在用户的访问结果中，从而很好地避免了多数据源属性上单一安全标签导致的用户访问受限的问题，实现了多源类继承类上的细粒度访问控制。

2.5 安全性分析

在多源数据上进行细粒度的访问控制是为了在保证数据安全的前提下，最大限度地提高多源类数据中各虚属性内容的可用性。为了实现这一目的，本文提出了基于多源数据的安全等级细化方法。该方法考虑到对象继承数据库中的主体是通过访问继承类中的虚属性而得到源类中对应属性内容的，因此若要对继承类中的虚属性进行粒度更细的访问控制，需要对继承类的虚属性内容根据其继承数据所在的源类的不同而进行分组，并为继承自不同源类的数据分组分配相应的安全标签，从而实现对多源类继承类中同一虚属性中来自不同数据源的数据分别进行互相独立的访问权限判断。由于访问权限的判断完全是基于用户的安全标签和属性内容安全标签的比较的，所以同一虚属性中各个内容分组安全标签的设定将直接决定细粒度访问控制的安全性。

SLsub≥SLSCi.a且CRsub⊇CRSCi.a

SLsub≥SLUIC且CRsub⊇CRUIC

可以看出，用户sub的安全等级大于等于SCi中a属性的安全等级，即具备SCi中a属性的访问权限，并且用户sub的安全等级大于等于va所在的继承类UIC的安全等级，即具备了UIC的访问权限。

由以上推理可得，按照基于多源数据的安全等级细化方法处理得到的虚属性安全标签集合中，同一虚属性中继承了不同源类对应属性的内容分组的安全标签和其各自对应的源类属性的安全标签存在着紧密联系，以此可以通过判定用户对虚属性中各个内容分组的访问权限来控制用户对源类属性内容的访问，从而实现安全的细粒度强制访问控制。

3 实验

3.1 实验环境

实验在一台主频为4.00 GHz、内存为8 GB的PC机上进行，实验平台操作系统为Redhat 6.5。实验数据集选用开源音乐数据集Million Song Dataset。

3.2 实验方案设计

基于PostgreSQL12实现了本文提出的支持多数据源、细粒度授权的强制访问控制模型，对该方法进行效率评估。目前还没有一种针对对象关系数据库的多源细粒度授权的访问控制模型实现，因此将本文改进的系统(PostgreSQL12+)与PostgreSQL12系统的访问控制功能进行比较。实验选用10个类，10 000条数据，并逐渐增大数据规模进行数据随机授权、随机撤销授权、查询和更新操作，通过统计分析PostgreSQL12系统执行时间和本文改进系统(PostgreSQL12+)在执行时间上的差异，对设计的细粒度强制访问模型给PostgreSQL12系统带来的性能影响进行分析。

3.3 用户授权实验分析

首先对授权效率进行对比分析，结果如图4所示。可以看出，在10 000条数据里依次随机授权100～1 000条数据给指定用户，PostgreSQL12+在执行数据授权操作时所用的时间小于未使用强制访问控制模型的PostgreSQL12系统执行相同操作时所用的时间。这是由于强制访问控制模型通过细粒度授权规则优化了随机授权方式，在一定程度上减小了随机授权操作的时间开销，使得PostgreSQL12+数据库授权访问更加灵活。

图4 随机授权操作执行时间对比图

3.4 用户撤销授权实验分析

实验分析了撤销不同规模数据的时间开销，结果如图5所示。可以看出，在授权10 000条数据给用户后依次随机撤销100～1 000条数据的授权，PostgreSQL12+在执行数据撤销授权操作时所用的时间小于未使用强制访问控制模型的PostgreSQL12系统执行相同操作时所用的时间，但相对而言，强制访问控制模型对执行随机撤销授权操作的影响要更大于其对随机授权操作的影响。这和系统执行随机授权和随机撤销授权操作本身用时有一定关系，同时由于强制访问控制模型使用基于多源数据的安全等级细化方法，在较大程度上减小了时间开销，使得PostgreSQL12+数据库的撤销授权操作更加高效。

图5 随机撤销授权操作执行时间对比图

3.5 数据查询实验分析

通过上述实验分析可见，本文方法可以获得更好的授权、撤销权限效率，同时作为数据库的访问控制授权策略，也需要衡量其是否会对数据库查询本身产生影响。

设计实验分析PostgreSQL12+的数据查询效率，结果如图6所示。可以看出，在10个类上进行查询操作，对应的数据量分别为1 000～10 000条记录，PostgreSQL12+在执行用户查询请求时所用的时间略大于PostgreSQL12系统执行用户查询请求所用时间，并且随着数据规模的增大，消耗的时间也越多。因此可见强制访问控制模型对PostgreSQL12系统的查询性能是有一定影响的。究其原因，主要是对类中的各个属性上的数据进行查询时，均需要通过调用强制访问控制的模块进行处理，强制访问控制的模块对各个属性进行了访问权限判定后才能继续查询执行操作，造成了一定的时间延迟。但同时强制访问控制模型在保证数据安全的前提下，最大限度地提高多源类数据中各虚属性内容的可用性，改善了PostgreSQL12系统的性能。