杨福军 丁 涛 付 眸 张培红 周 铸

(中国空气动力研究与发展中心计算空气动力研究所 四川 绵阳 621000)

0 引 言

随着计算机领域不断延伸到各行各业，系统权限的复杂度不断增加。在特定的业务场景中，业务系统权限通常指用户具有对计算机软硬件资源的访问、修改、使用等权力。例如，在Windows操作系统中，将用户分为了管理员、一般用户、游客、网络访问用户等类别，不同类别具有不同的权限[1]。传统的DAC权限管理一定程度上减轻了权限配置负担，但随着用户的增多，权限管理也会越来越复杂，往往需要专人负责权限的规划、分配、管理、监控等事务。文献[2]提出了一种DAC(Discretionary Access Control)到RBAC的迁移方法，但该方法只是对DAC进行了兼容，面对大型系统，仍然存在很多问题。因此，我们需要更好的权限管理方法，尤其是随着各业务系统加入网络，对于用户的隐私泄露的问题也亟需解决[3]。

基于角色访问控制的系统权限管理方法，在一定程度上给系统权限的管理带来方便，但角色管理方法也存在一些潜在问题：(1)关键角色可同时被赋予多个用户而导致冲突；(2)角色继承后缺乏权限管理的安全性；(3)没有考虑各类系统设计实现RBAC模型时，权限管理功能的复杂性问题[4]，可能造成人为的数据的泄露、丢失和篡改；(4)不当的权限配置还可能导致系统宕机。在云计算领域，权限管理不仅需要更多灵活性，还要保证数据安全性[5]。例如，通常Software-as-a-service云是使用多租户方式，既要保证数据安全，又要防止内部攻击导致服务崩溃[6]。文献[7]提出了一种在云环境中的CRUAC(Role and Usage based Access Control in Cloud Computing)访问控制模型，主要从用户管理、约束管理、资源管理、授权管理4个角度的权限控制管理。

1 系统权限分析

1.1 数据库权限配置

在现代业务系统中，一般会将权限信息保存于数据库中，数据库相对于业务系统，具有独立的权限管理机制[8]，比如Oracle数据库权限管理非常庞大复杂。应用程序访问后台数据库时，一般会读取配置文件中设置的数据库的配置参数，数据库的连接方式都有相同范式，Oracle连接参数如表1所示。

表1 Oracle访问参数表

数据库系统往往与业务系统分开，通常成熟的大型数据库系统有特殊的权限管理方法，可将操作权限细分到行级。数据库系统为业务系统提供数据存储服务，往往使用中间件进行连接。成功建立连接后，中间件会与Oracle建立会话进程，操作系统会分配一段内存作为此次会话的缓冲区，直到连接关闭、会话结束。在实际业务场景中，业务系统往往会并发与数据库建立多个连接，生成多个会话，连接持有的权限也各不相同，此时的权限概念与业务系统的权限概念不同，在数据库系统中的权限使用内部权限管理方式，与业务系统分离。

1.2 业务系统权限分析

数据库系统为业务系统提供了数据存储服务，同时，业务系统中的权限也以表的形式保存于数据库系统，通过DBMS本身的用户管理模式，如果给每个用户建立一个登录数据库的用户，用户的授权工作由数据库管理员实施和维护;每增加一个用户，都需要在数据库中也增加相应用户，并赋予相应权限；随着系统的不断扩展，权限维护工作会愈发繁重。

在一个成熟的业务系统中，管理员与数据库的交互一般采用网页/客户端的交互模式，即需要中间应用服务器建立连接并操作数据库(见图1)。从数据库系统的角度来看，业务系统的权限也是一种数据，以表的形式保存在数据库。这些特定的权限表保存着业务系统中的所有使用人员、权限分配方式、访问控制等信息，因此权限表的安全性特别重要。

图1 数据库交互模型

权限管理包含两部分内容:(1)对数据资源进行筛选过滤，只将有限的数据开放给用户；(2)用户对这些开放的资源是否具有增加、删除、修改、查询的权限。在本文中，把数据权限定义为对表的访问权控制，又分为行控制和列控制。比如，当要求用户只能操作自己的数据时，需要进行行控制；当要求用户不能看到其他数据的来源信息时，需要进行列控制[9]。

同时，对每个权限赋予有效期限，在有效期内，权限才有效，未做特别时间约束的权限会一直有效。将时间、身份特征段作为权限的属性，设计完善从访问控制模型、基于属性的密文访问控制和外包数据的访问控制三个方面的权限方法可极大增加系统安全性[10]。一些大型业务系统不仅权限数量多，而且权限种类多种多样，还需要经常变化，于是对权限进行分门别类，就产生了角色(Role)的概念。角色是某一类权限的集合。综上所述，总结出了用户、角色、权限和资源的关系如图2所示。

图2 用户-角色-权限-资源关系

2 RBAC层次模型

通常RBAC模型由4个子权限模型组成，分别是基本权限模型RBAC0、角色分级权限模型RBAC1、角色限制权限模型RBAC2和统一权限模型RBAC3[11]。

2.1 RBAC0层分类

在系统中的所有最小粒度权限，可分为五个类别：用户类(U)、角色类(R)、对象类(O)、操作类(J)、许可类(P)。这些最小粒度权限用RBAC0表示。五个类别权限相互之间可定义1 ∶N，M∶N关系，如下：

(1)U∶R=M∶N

(2)O∶J=1 ∶N

(3)R∶P=1 ∶N

(4)O∶P=1 ∶N

(5)J∶P=M∶N

权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展[12]。

2.2 RBAC1继承关系

RBAC1定义角色的继承关系，继承关系使得权限管理灵活性得到提升，从管理角度出发，管理者拥有普通员工的权限，也扩展相应职能特权，则管理者继承了普通员工权限[13]。RBAC1也可实现多继承关系，进一步提升角色间权限赋予的灵活性。

2.3 RBAC2约束关系

RBAC2定义了权限约束关系，包括权限间继承的约束、用户指派角色的约束、活动用户行使的权限范围约束。在RBAC2中，具体访问许可由用户、角色、权限三者关系决定。RBAC2约束关系使得权限管理安全性提升，但过多的约束关系会使得RBAC1的继承关系管理变得更加繁琐。因此，RBAC2约束关系的定义应从总体需求出发进行规划。

2.4 RBAC3复合关系模型

RBAC3是包含一系列复合关系的模型，是对角色-用户关系的定义，关系模型为M∶N；称为用户角色分配和角色许可分配[14]。

2.5 RBAC-权限集模型分析

传统的RBAC只针对用户作为权限拥有者，用户具有对资源、数据、网络等操作的许可，RBAC1、RBAC2、RBAC3是用户权限关系的集合。随着业务系统的复杂性增加，本文将系统中一些用户分组，提取分组用户所有权限，称为权限集，按照继承关系-约束关系-复合关系分析组内权限，计算复杂度，按复杂度进行权限修正。RBAC子权限集要满足安全性、灵活性、便捷性三个特点，进一步分析梳理，确定参与权限集复杂运算的主要包含对象有：用户数、角色、分组权限类别、RBAC层次权值、权限关系权重。主要的关系有：分配用户(组)角色、分配角色权限;将用户与权限通过角色隔离开,减少了用户权限赋值关系太多时带来的管理难度。用户-角色-组关系如图3所示。

图3 用户-角色-组关系

角色：一定数量的权限的集合。角色权限分配的原则是：不与其他角色所拥有的权限产生交集。在本模型中，角色权限来源于RBAC0层。

用户组：用户组与角色是M∶N的关系，即用户组可以有多个角色，角色可以有多个用户组。按照角色权限分配原则，在遇到1 ∶N关系时，用户组需要进行并集运算，提取权限元素，避免角色之间产生权限交集。

2.6 RBAC分层模型分析

2.6.1便于授权管理

在传统的访问控制中，用户或其职能发生变化时，需要进行大量的授权更改工作。在RBAC中，用户的职能改变时，重新指定相关角色即可，而角色的权限一旦定义好,就很少去更改。要对角色的权限进行更改，只需要修改角色的功能或定义新角色，而不必更新每一个用户的权限设置。

2.6.2角色划分

RBAC将角色组织起来，能够很自然地反映组织内部人员之间的职权、责任、赋予关系，也可以使用类似PowerDesigner的工具，导出权限关系，为系统权限设置优化提供参考。

2.6.3赋予最小权限原则

权限的分配应以实际业务需求为标准，即用户尽可能分配职责规则的权限，避免用户拥有冗余权限而带来安全问题。本文分析了RBAC权限继承、约束、复合关系，定义了关系间的分配原则，从不同维度解释权限关系。

2.6.4职责分离

在一些业务场景，往往需要多个不同角色的用户完成一项业务，例如企业流程审批，需要多个用户参与。如果让某一个用户完成该业务处理，则该用户需要赋予较大权限，这在一些金融、政府、军队等行业容易造成人为的安全事故。因此，对于某些特定的操作，需要进行职责分离，RBAC较为灵活地提供了该支持。

3 权限治理策略

权限治理策略主要是建立在系统稳定的基础上，将权限划分为三个治理方向：可靠性策略、复杂性策略、权限修正。

3.1 可靠性计算

在软件系统工程领域，广泛使用可靠性增长模型(Software Reliability Growth Model，SRGM)进行建模分析故障数量、累积检测率、排除故障数等数据[15]。SRGM研究的机理是对系统运行和测试过程中各随机变量间建立适当的数学模型，通常SRGM有两类：随机过程与非随机过程，如表2所示。

表2 SRGM特点

非随机过程需要人为提前设计相关参数和用例，基于贝叶斯的SRGM需要收集系统研发过程中的测试用例和结果。本文中的权限配置模型不对具体的软件开发过程进行研究，即面向系统成品中的权限配置。随机过程中的执行时间过程模型假定了故障间隔与时间服从某种概率关系[16]，其应用场景限制在了特定的环境中，比如在线购物商城、电力调度系统、电子支付等，但不适用于本文提出的权限控制模型。马尔可夫与NHPP建立的模型都可根据已检测故障计算出系统可靠性，NHPP在针对RBAC的权限配置过程中的计算，需要构建有效的均值函数，设[N(t),t≥0]为随机计数过程，N(t)为[0,t]内累积检测错误，NHPP如下：

(1)

式中：m(t)为均值函数。本文将RBAC进行了分层处理，定义了权限类关系；构建均值函数需要对不同的关系类型，如1 ∶N、N∶M、1 ∶1等进行加权处理，将进一步引入加权函数，使得NHPP的计算更加复杂。文献[15]对SRGM的研究现状进行了分析比较，马尔可夫模型满足在不完美排错环境下且符合新故障引入机制。本节主要参考文献[17-18]基于马尔可夫的JM方法进行数学建模。

设N0为权限集合中可造成安全事故的权限分配数，进一步定义为不合理权限分配、系统错误生、角色权限冲突(相同)。

排除安全事故后且没有新的错误产生，则每次迭代运算时:

N0=N0-1

(2)

在一个时间间隔内，产生错误数与系统中剩余错误个数成正比，设Ne为产生错误数，Nr为剩余错误数，存在一个常数φ使Ne与Nr线性相关。设该比例为:

(3)

设ti为0时刻到i时刻之间的错误时间间隔。发生第i-1个错误至第i个错误之间，失效(故障)函数可表示为：

μ(ti)=φ(N0-i+1)

(4)

造成权限配置出错的原因大多在初始配置时刻，即这与初始安全人员的专业技能水平等因素相关，则存在强度函数，用以表示错误率发生强度，该函数为:

F(ti)=φ(N0-i+1)e-φ(N0-i+1)ti

(5)

可靠性度量函数为：

R(ti)=e-φ(N0-i+1)ti

(6)

在不同业务系统中，发生错误的概率有所不同，比如，一般权限集与管理权限集产生的错误不同，概率分布函数用式(7)表示。

Ι(ti)=1-e-φ(N0-i+1)ti

(7)

式(7)中φ与N0未知，使用最大似然法对φ与N0进行估算。

由可靠性度量函数得似然函数:

(8)

式(8)进行对数运算，得：

(9)

对式(9)中的φ和N0求偏导：

(10)

(11)

(12)

式(12)进一步化简(省略中间计算)得:

(13)

式中：T表示总时间。

(14)

3.2 复杂度计算

本文将对系统中所有权限进行复杂性分析，目的是在不同规模的系统中，提供相应的权限设置。如果系统规模太小，又设置了太复杂的权限，对系统的管理提出了挑战；如果系统规模太大，权限设置太简单，系统的安全性又得不到保障。在2.1节中，梳理了权限关系，这为复杂性计算提供了重要参考。

文献[15]提出了一种基于数据的复杂性计算方法，该方法中，提出的数据结构复杂性表征方法对本文有重要借鉴意义，对其进行修改后，可用于计算权限复杂性。

3.2.1类权限复杂性

类权限有五种：用户类、角色类、操作类、对象类、许可类。每类有权限集合域{x1,x2,…,xn}，每个单位权限对系统总权限复杂度的平均信息量贡献为:

(15)

则类权限复杂性计算式：

(16)

(17)

式中：Shannon对信息熵的定义，b通常取2；I(xi)为随机变数；L为类权限复杂度。

3.2.2系统总权限复杂度

设每类权限集合域中有单位权限元素ni，则该类权限的复杂信息量为Li。如图4所示，每类权限有三种关系：M∶N、1 ∶N(N∶1)、二元关系(1 ∶1)。分别对每种关系进行复杂度计算:

图4 RBAC0层元素关系

(1)在权限集合域中有单位权限元素ni，则二元关系可表示为nib，Lib为二元关系复杂度。

(2)在权限集合域中有单位权限元素ni，二元关系可表示为nib，则M∶N关系复杂度为Libs。

(3)在权限集合域中有单位权限元素ni，二元关系可表示为nib，则1 ∶N关系复杂度为Libt[19]。

系统权限总复杂度为：

L=Libt+Libs

(18)

系统权限复杂度由初始化阶段计算得到，此后当权限发生更改，则重新计算一次。

3.3 权限修正

(19)

式中：α为初始复杂度，该复杂度并不随着权限更改而触发计算，而是当有因为权限导致的安全事故时，重新触发计算；β为业务系统未出现因权限导致安全事故的正常运行天数，系统无故障运行越久，则稳定值越高。β初始值为0，当出现安全事故，则β=β-1，即前一天的稳定态。如果P≥J，则系统处于稳定态；如果P

图5中，权限的修正与修复需要人工介入，该处可引入三员管理。即将超级管理员的权限进一步划分为三部分，相互制约，避免了单一管理员权限过大，缺乏监督和评审，造成人为的错误[20]。本文不对三员管理方式进行具体规约，但强调若按本文方法进行权限控制，三员管理中需要有一员权限为“管理权限的管理员”。

图5 系统权限修正流程

4 实验分析

(1)按照第2节的RBAC层次进行建模。建模主要使用PowerDesigner工具完成，并生成图。

(2)计算出符合要求的权限可靠性值；因为可靠性值引入了时间因素，所以对参与的时间(单位:天)手工填写，发生的系统错误也通过手工触发。

(3)计算出总权限系统复杂度，并且随着权限单元的增加，总复杂度也增加。

(4)进行系统修正修复后，P≥J，否则迭代权限修正。

4.1 实验一：建立权限模型

本实验实现了一个内网管理系统，主要功能是实现对内网成员上网权限管理，采用drupal内核二次开发，权限表保存在Oracle数据库中，权限表结构如下。

系统权限表清单存储系统中权限类，为了进一步细分，新增了三个视图：操作权限表、用户权限表、角色权限表。系统权限表、对象表、操作权限表、操作类权限表、用户权限表如表3-表7所示。

表3 系统权限表清单

表4 对象表

表5 操作权限表

表6 操作类权限表

表7 用户权限表

用户权限与其他类别权限存在继承关系，为了更加方便观察用户所有权限，建立了视图如表8所示。

表8 用户权限视图表

为了更加方便观察系统中所有权限，建立了单位权限视图，该视图中的权限为五类权限并集，单位权限表、角色权限表、许可类权限表如表9-表11所示。

表9 单位权限视图表

表10 角色权限视图表

表11 许可类权限表

以上表保存了系统所有权限，并且按照RBAC进行了规范处理。生成权限表以及相关权限关系，使用SQL语句；限于篇幅，这里只展示对象权限表SQL代码:

CREATE TABLE "T_SAFE_RES" (

"SEQNUM_RES" INT NOT NULL,

"SEQNUM_TASK" INT,

"SEQNUM_TYPEDATA" INT,

"SEQNUM_DEPARTMENT" INT,CONSTRAINT

PK_T_SAFE_RES PRIMARY KEY("SEQNUM_RES"));

ALTER TABLE "T_SAFE_RES"

ADD CONSTRAINT

FK_T_SAFE_R_REFERENCE_T_LIST_T FOREIGN KEY

("SEQNUM_TASK")

REFERENCES "T_LIST_TASK"("SEQNUM_TASK");

ALTER TABLE "T_SAFE_RES"

ADD CONSTRAINT

FK_T_SAFE_R_REFERENCE_T_LIST_T FOREIGN KEY

("SEQNUM_TYPEDATA")

REFERENCES "T_LIST_TYPEDATA"

("SEQNUM_TYPEDATA");

ALTER TABLE "T_SAFE_RES"

ADD CONSTRAINT

FK_T_SAFE_R_REFERENCE_T_LIST_D FOREIGN KEY

("SEQNUM_DEPARTMENT")

REFERENCES "T_LIST_DEPARTMENT"

("SEQNUM_DEPARTMENT");

所有权限及权限关系建立后，使用PowerDesigner工具对以上各表进行分析，得到的权限关系图如图6所示。

图6 权限关系图

4.2 实验二：可靠性实验

本实验的软硬件环境如表12所示。

表12 运行环境参数

权限复合关系分析、权限的依赖关系分析、权限的继承关系分析将消耗大量内存，因此本实验初始配置32 GB内存，视实验情况酌情增加。本实验主要验证RBAG在每一次权限修复后，可靠性值是否符合SRGM增长规律。

表13 样本参数

续表13

图7 可靠性计算实验结果

计算结果表明，在不引入新的错误前提下，系统错误被不断检出、修正，可靠性得到不断提升，并且计算出提升幅度。

4.3 实验三：复杂性实验

4.3.1关系复杂度实验

在3.2节中，将权限关系复杂度列入总复杂度计算。本实验在总权限单元不变的情况下，增加权限单元之间的关系，如图6权限关系图，取M∶N、1 ∶N、二元三种关系进行实验，且每次实验一种关系时，其他两种关系取值为1。计算结果如图8所示。

图8 关系复杂度计算结果

随着权限之间的联系不断增加，总复杂度也不断提升，且复杂度M∶N>N∶1>二元，符合前文理论分析。通过实验可知，随着系统复杂度的增加，M∶N关系是增加权限复杂度的主要因素。

4.3.2权限元素量复杂度实验

RBAC层次中定义了继承关系，比如权限集a可以从权限集b中继承n个权限元素。本实验中，对于继承关系a、b，取二者并集。同时，五个类别的权限每次实验时，只取一种权限进行计算，其他四类权限数量限定为10，对于权限关系，只建立必要的连接，至少为1。实验结果如图9所示。

图9 权限元素量复杂度实验结果

以上实验结果中，五个权限类复杂度呈上升趋势，增量各有不同，这是因为权限类别中还存在依赖、继承关系，导致对复杂度的贡献值不同。

5 结 语

本文选用了RBAC模型，从不同维度对权限关系进行了论述，重新定义了权限之间的连接关系并建模。采用了JM数学模型对可靠性进行度量，改进了文献[15]的复杂度算法，实验结果表明，各项结果符合预期。

治理策略从三个方向对系统权限进行了梳理：

(1)可靠性策略。主要是可靠性计算，这依赖系统运行中，因权限问题带来的系统损坏、宕机、不同级别报警等错误的处理。

(2)复杂性策略。主要是通过对系统进行复杂性计算后，给出对于管理人员具有参考意义的值，同时也参与稳定性计算。

(3)权限修正。这是在问题发生后，对错误原因进行排查，此时需要人工介入，非权限原因导致的系统问题不列入修正内容。修正后重新对可靠性与复杂性进行计算，得出系统稳态值，如果稳态值低于宕机前，则迭代修复过程。

本文对某些方面未做进一步研究，比如：权限修正过程可以划分为更多维度进行计算；系统稳定态算法也可以考虑更多变量，使得结果更精确。在本文中没有改善的问题，可作为下一步研究方向，或为相关领域研究者提供些许思路。