基于UCON的数据仓库安全模型的设计与实现

李果，宋晶晶

（清远职业技术学院网络信息中心，清远 511510）

0 引言

对信息系统中的敏感信息和资源的访问进行控制一直是信息系统安全的一个基本需求。访问控制通过协调用户或者进程对于特定资源或数据的访问请求，决定是否允许访问相应的资源或数据，从而达到限制用户和进程对敏感信息的访问的目的。在传统的访问控制机制中（DAC、MAC和RBAC等），都是在用户发出访问请求时应用访问控制规则，但是在用户得到授权后系统就失去了对受保护对象的控制，无法实行持续的访问控制，也无法改变主体或者客体的属性[1-2]。而在当今日益复杂的、多平台、多客户端的环境中，对于资源和数据访问或者使用进行持续的控制越来越成为一个基本的需求。为了解决这一问题，人们提出了多种解决方案。UCON是由Jaehong、Ravi等提出的一种系统性控制数字对象使用的访问控制方式，其具体描述方式有多种，UCONABC模型是其中比较典型的一种，包含了授权、职责和条件三个核心模型，每个模型根据访问决策时机的不同又可分为pre和on两种情况[3-4]。

企业数据仓库是一个面向整个企业开放的共享的数据及应用平台，开放性和共享性是它所必须具备的特征。正因为如此，企业数据仓库的安全性才显得更加重要。如何做到开放的同时又保持安全是企业数据仓库必须解决的重要技术问题，也是实现企业数据仓库的技术难点之一。实现企业数据仓库的权限控制可能有很多不同的方法，目前主流的解决方案都是基于RBAC模型建立的，能够很好地解决数据仓库大部分的安全需求，但是在处理一些临时依赖和动态决策的安全需求时就显得无能为力了。

1 相关工作

1.1 UCON模型

传统的访问控制方式缺乏一种可用于任何环境（服务器端或客户端）的系统化的、一致的方式来全面控制数字对象的使用，无法很好地满足现代信息安全需要。文献[4]重新定义了访问控制中的基本问题，扩展了访问控制的内涵，将传统访问控制、信任管理以及数字权利管理（DRM）等三个领域系统地揉合在一起，首次提出了“使用控制（Usage Control）”的概念，并从概念上描述了一种称之为UCON的访问控制模型。该模型由主体、客体和权利三个核心组件构成，并包含三个额外的组件，即授权规则、条件和职责。它是基于会话的，与传统的访问控制方式相比有两个显著特性：决策持续性，即客体即使分发出去后其使用仍然受到授权规则的约束；属性可变性，即在访问客体前、访问客体期间或者访问客体后能对主体或客体的属性进行更新。文献[3]在文献[4]的基础上提出了一个系统的、具体的访问控制逻辑模型，并根据属性更新的时间点讨论了16种基本的UCONABC模型。文献[1]从有限状态机的角度对UCON模型进行了扩展，将访问状态分离为访问和持续检查两个状态，并讨论了基于该扩展模型的原型实现。文献[11]对属性的外延做了扩展，将权限自身的属性也考虑在内，对UCONABC模型进行了扩充。

1.2 数据仓库安全

在文献[10]中提出应该建立一个统一的数据仓库，而不是通过分散的多个异构的数据集市的方式来建立，并给出了基于Oracle数据库特性的访问控制方式。文献[5]中描述了一种基于元数据的数据仓库安全模型，提出通过元数据来描述和管理对于数据仓库的访问。文献[6]提出基于视图安全来建立数据仓库的安全。文献[7]中描述了一种将RBAC模型与UCON模型结合的方法，并描述了基于这种混合模型的系统的总体架构和实现原型。文献[8]从改进SQL的角度提出了一种用于访问控制的形式符号，以便更好地表达数据仓库中多维数据集的访问控制要求。文献[9]描述了一种简单的基于UCON的数据仓库访问控制模型。

2 基于UCON的数据仓库访问控制

2.1 数据仓库主要面临的安全风险

数据仓库和其他信息系统一样存在着一些共同的安全需求，例如受保护的信息和资源只有经过认证的用户才能访问，不同的用户根据职责的不同只能访问部分资源和信息等。同时，数据仓库作为一个综合了多个异构数据源、服务于多级别、多类型用户的决策支持系统，又有着自己独特的安全需要，主要体现在：

（1）服务于众多的有着不同安全需求的用户群体，他们的安全需求之间往往存在着冲突；

（2）安全功能应当足够灵活、全面，但又不至于严重影响系统性能；

（3）用户可能根据聚合结果推导出底层的细节数据，从而导致信息泄密的问题，这种问题被称作推断攻击（Inference Attack）；

（4）从数据源抓取数据时对数据仓库数据一致性或者完整性的破坏；

（5）得到授权的用户对数据的滥用或者误用。

针对上述问题，传统的做法是一方面是采取系统化的方法建立安全的数据模型，这部分内容不在本文的讨论范围内；另一方面采用基于角色的访问控制模型建立数据仓库安全模型，实现对于受保护对象的访问控制。但是在这种方式下，当用户拿到数据后系统也就无法对其再进行访问控制；另一方面，当提交查询的时候，数据仓库可能并不能一次提供查询要求的所有数据，它必须再从后台的异构数据库中获得需要的数据，这时也涉及到访问控制的问题，也就是说，一次查询执行过程中也可能存在新的授权等安全需求。

2.2 基于RBAC的访问控制模型的不足

基于角色的访问控制主要是从企业职责的角度来对权力和特权进行分组、控制，对于一些临时性的、持续性的访问控制不能很好地进行管理。例如，区域销售经理只能在每个季度的最后三天的工作时间内查看本季度的销售报表，且只能在办公室内打印该报表，最多只能打印三份。传统的RBAC模型并不能很好地解决这种访问控制需求，即使也能够实现，但是主要都是靠开发人员自己设计的方案，并没有系统的解决方法。

从本质上讲，RBAC是通过将不同的角色赋予用户来实现访问控制的。每个角色都关联一组许可，一个许可代表着对访问对象进行某种操作的权力，通过这种方式实现了用户对对象访问的权限控制。但是在如今人员变动频繁、角色职责变更迅速的时代，这种访问控制的方式的维护和管理都很麻烦。同时，针对一些临时性的、动态依赖的访问控制需求，RBAC也无法很好地解决。例如，有进程在执行过程中需要更多特权，或者一些客体在执行过程中需要更新属性值，例如某个用户试图抽取多个数据资源并且需要获取其中某数据的授权，而在会话开始之前并没有得到允许，则此进程必须终止并重新启动才行。

2.3 基于UCON的数据仓库访问控制模型

数据仓库安全需求：

在数据仓库中主要存在着以下几类访问控制需求：

（1）关系型数据库的访问

（2）OLAP数据库的访问

（3）企业数据仓库中采用的其他工具软件（如报表工具等）的权限

（4）应用系统的访问

（5）管理权限

上述五种权限的前三种和具体的产品相关，第四种和应用系统的统一管理相关，而最后一种则规定了该角色是否具有管理者的权限。

在本小节中我们将提出一个我们认为是完整的和可实现的企业数据仓库访问控制模型，并在下一小节中讨论该模型的具体实现。我们所要建立的访问控制模型以RBAC为基础，对授权规则进行扩展，在进行授权决策时不仅考虑用户关联的角色，同时还考虑用户和被访问对象的属性，并在授权决定这一环节交由UCON组件来负责，从而实现一个可动态授权的、基于属性的访问控制模型。

访问控制模型：

建立模型的基本考虑：

（1）建立企业数据仓库中的用户、用户组和角色等基本概念，并规定整个企业数据仓库的权限分配机制。

（2）定义企业数据仓库中的各种操作和要进行访问控制的对象。企业数据仓库中的操作一般来讲可分为两类，一类是常规的系统操作，包括工具的使用、应用的访问和管理等；一类是和数据仓库特定相关的操作，包括数据的钻取、切片、数据源的数据抓取等。要进行访问控制的对象也可相应地分为工具、应用等常规对象和数据项、维度和事实等数据仓库特有的对象。

（3）根据定义的操作和对象定义可施加在每一个对象上的操作的集合，并根据需要定义进行相应操作时应履行的职责和满足的条件，以及访问前、访问中或者访问后应该更新的属性。

（4）为每个企业数据仓库用户规定权限。这一过程一般是通过将包括角色在内的各种属性赋予企业数据仓库用户/用户组和对象来完成的。这样在授权时将用户/用户组的属性与对象的属性根据授权规则进行对比计算即可。

必须要指出的是，和常规的RBAC模型只根据用户的角色属性进行授权不同，在我们这个模型中，授权时除了考虑角色这一属性之外还会考虑其他属性，以及相应的要履行的职责和满足的条件，并有可能在访问前、访问中或访问后对用户或者对象的某些属性进行更新，更具有动态性和灵活性。

数据仓库访问控制模型的定义：

定义1基本组件

ACModel={S，ROLE，R，OR，O，F，D，L，A，B，C，ATTR(S)，ATTR(O)，preA，preB，onB，preC，onC}

其中：

S：用户集合

ROLE：角色的部分有序集合，定义了关系≥

R：除去OLAP之外的其他操作

OR：OLAP 操作

O：要进行访问控制的对象（不包括事实、维度等数据仓库特有对象）

F：数据仓库中的事实

D：数据仓库中的维度

L：维度的层次的集合

A：授权

B：职责

C：条件

ATTR（S）：用户属性的集合

ATTR（O）：对象属性的集合

preA，onA，preB，onB，preC，onC：分别代表访问前授权决策、访问中授权决策、访问前职责履行检测、访问中职责履行检测、访问前条件检查、访问中条件检测。

定义2数据仓库操作基本定义

OR={read，drill-down，roll-up，drill-through，slice，audit}DH：D→2L，表示一个维度到对应的维度层次的映射

PT：S×F→2D×DH×OR，表示一个用户对一个事实到对应的维度和维度层次能进行的操作的映射

定义3基本访问控制

sRole：S→2ROLE

oRole：O → 2ROLE

actRole：O → 2ROLE

ATTR(S)={sRole，actRole}

ATTR(O)={oRole}

ATTR(F)={2D}

allowed(S，O，R)→ actRole(S)⋂oRole≠∅，

preA(ATTR(s)，ATTR(O)，R)

allowed(S，F，D，OR)→actRole(S)⋂oRole≠∅，

preA(ATTR(s)，ATTR(O)，R)

定义4访问期间授权

除了定义3之外，还包括以下规则：

onA（持续授权检测）

allowed(S，O，R)→ true

allowed(S，F，D，OR)→true

stopped(S，O，R)→ ¬onA(ATTR(S)，ATTR(O)，R)

stopped(S，D，F，OR)→ onA(ATTR(S)，ATTR(F)，D，OR)

定义5访问前和访问中职责检查

除了定义4之外，还包括以下规则：

OBS→职责主体

OBO→职责对象

OB→要履行的职责

preOBL⊆OBS×OBO×OB

preFulfilled：OBS×OBO×OB→{true，false}

getPreOBL：S×O×R→2preOBL

getPreOBL：S×F×D×OR→2preOBL

preFulfilled(getPreOBL(S，O，R))

preFulfilled(getPreOBL(S，F，D，OR))

allowed(S，O，R)→ onFulfilled(getOnOBL(S，O，R))

allowed(S，F，D，OR)→ onFulfilled(getOnOBL(S，F，D，OR))

定义6访问前和访问中条件检测

除了定义5之外，还包括以下规则：

preCON(条件元素集合)

getPreCon：S×O×R→2preCON

getPreCon：S×F×D×OR→2preCON

preConChecked：preCON →{true，false}

preC(S，O，R)= ∧preCon∈getPreCON(S，O，R)preConChecked(preCon)

preC(S，F，D，OR)= ∧preCon∈getPreCON(S，F，D，OR)preConChecked(preCon)

allowed(S，O，R)→ preC(S，O，R)

allowed(S，F，D，OR)→ preC(S，F，D，OR)

onCON(条件元素集合）

getOnCON：S×O×R→2preCON

getOnCON：S×F×D×OR→2preCON

onConChecked：onCON →{true，false}

onC(S，O，R)= ∧onCon∈getPreCON(S，O，R)onConChecked(onCon)

onC(S，F，D，OR)= ∧onCon∈getPreCON(S，F，D，OR)onConChecked(onCon)

allowed(S，O，R)→ onC(S，O，R)

allowed(S，F，D，OR)→ onC(S，F，D，R)

原型实现：

本文所讨论的访问控制模型是以RBAC为基础建立的，但是与单纯的RBAC不同的地方主要有两点，一是在决策考虑范围上进行了扩展，进行授权决策时不仅考虑到用户所关联的角色，还包括了用户和所访问的资源的属性；二是在处理一次请求时整个授权决策过程是动态的，可根据属性和环境进行灵活的动态决策，而不像RBAC一样，在一次请求中一旦角色确定了所关联的权限也就固定了。在实现该访问控制模型时主要需要考虑以下几个问题：

（1）对于用户请求的授权决策是以会话为基础的，即权限的授予是在一次会话开始后，随着会话的结束而结束，因此需要在处理请求时要对会话进行管理；

（2）由于在授权决策时不仅会考虑用户的角色属性，还会需要用户和资源的属性信息，因此应该有专门的组件来管理用户和资源的属性；

（3）授权的决策和授权实际上是两个独立的过程，授权的决策主要负责的是根据策略对用户请求做出处理，决定该请求是否符合对应的授权规则，而授权则是权限的赋予，它根据授权决策的结果来决定是允许请求还是拒绝。

（4）由于访问策略中可能会包含用户和资源的属性、条件以及职责，需要一种合适的表达方式来描述，并能根据具体应用的需要对表达方式所能描述的内容进行扩展，同时还要好能很好地实现ABAC和UCON的语义。XACML（Extensible Access Control Markup Language）即可扩展的访问控制标记语言，是一种声明式的访问控制策略语言，以XML的形式表示。它鼓励将使用点与访问决策点隔离开来，即将对资源的使用抽象为一个操作，将对这个资源的使用的决策过程抽象为另一个操作，这符合我们逻辑模型的设计。它已经实现了ABAC的语义，我们只需要再对其进行扩展，实现UCON的语义即可。

（5）在我们的设计中，将是否允许请求的执行（执行点）与进行授权决策（决策点）分离为两个不同的点，即执行点接收到请求后只是简单地将其转发给决策点，自身并不进行任何判断，决策点负责根据授权规则进行决策，并将决策结果返回给执行点，让其根据决策结果决定下一步的操作。因此在实现中需要将用户的请求单独抽象为一个对象，考虑到采用XACML来描述访问策略，我们在实现层面执行点应当先将用户的请求转换为XACML再转发给决策点，决策点将决策的结果也以XACML的形式发回给执行点，再由执行点对其进行处理。

（6）执行点与决策点的实现。执行点需要对每一个用户请求都进行检查和转发，因此它应当以全局拦截的方式来实现；而决策点深入到具体方法执行上，需要进行更为精细的控制，执行频率非常高，涉及的决策逻辑也比较复杂，因此在实现时必须考虑到其带来的影响。

（7）其他考虑。在我们的访问控制模型中，有可能根据策略需要进行持续的条件检查和属性更新，一般来讲有两种实现方式，一是基于时间，即每隔一定的时间进行检查或更新，另一种是基于事件，即当某事件发生时进行检查或者更新。事实上基于时间的实现方式可以看做是基于事件的一种特殊实现方式，即当到了一定时间即视作发生了一件事情，因此在实现中应当选用更灵活的基于事件的实现方式；另外，由于我们的访问控制模型主要是应用在数据仓库环境中，绝大部分操作最终都会归于对数据库数据的读写和过滤操作，因此在实现访问控制时必须进行充分考虑，以避免对性能造成大的影响。我们专门实现了一个SQL语句解析和转换组件，当访问控制判断涉及到SQL语句时负责对SQL语句进行解析和过滤，并根据授权策略进行判断，只返回得到授权的数据。

整个系统的实现架构如图1所示。

3 结语

本文首先讨论了数据仓库安全中的主要问题，并以基于角色的访问控制（RBAC）模型为基础，根据基于属性的访问控制（ABAC）对该模型进行了扩展，并将实际的授权决策过程交由UCON组件来执行，从而建立了一个新的数据仓库安全模型；随后我们给出了该安全模型包含的主要组件以及其形式定义，最后讨论了基于该模型的原型系统的实现。

访问控制模型实际上包含了访问控制和访问控制管理两部分的内容，本文主要讨论了访问控制方面的内容，没有涉及访问控制管理方面的问题。另外，在本文所提出的安全控制模型中，对数据库的每次查询都会进行SQL语句的过滤和转换，在实际中对系统的性能是个极大的考验，如何优化SQL解析过滤器，不使其成为系统性能的瓶颈是需要认真考虑的一个问题。

图1 系统实现架构