PLM系统中直接授权模型的研究与设计

PLM系统中直接授权模型的研究与设计

    建立合理、完善的直接授权模型是实现PLM系统中权限高效、细粒度化管理的关键。直接授权模型，就是运用图形或数学语言形式化地描述权限控制策略规定系统中的主体对客体有哪些操作。它与数据保密服务、不可否认服务、身份认证服务和数据完整性服务，在国际化网络安全标准体系设计中列为五大安全服务功能，共同保障网络系统的安全。
 
    根据上一章详细地分析出的某企业所开发的PLM系统中对权限管理的需求以及总结出的权限管理模型设计的原则，本章将对所需求的直接授权模型进行具体的研究与设计，并进行实例验证。
 
1.1经典的直接授权模型
1.1.1DAC模型
    DAC模型的基本思想是系统中的主体可以按照自己的意愿将其所拥有的权限授权给其他主体或进行权限的回收，而不需要经过系统管理员的批准。DAC模型一般利用权限管理矩阵（Access Matrix，简称AM）和权限管理列表（Access Control List，简称ACL）来存储不同的用户或用户组对系统中不同的信息资源、菜单、命令等客体的访问权限，从而限制系统中所有的用户或用户组能够对哪些信息资源、菜单、命令等客体进行一些什么样的具体操作。
 
    DAC模型授权灵活、易于实现，然而其自主特性，会造成权限传递失控，这样很容易产生安全漏洞；此外，如果企业中的用户或客体数量过多时，存放访问控制信息的ACL就会很庞大，造成系统的开销极大。因此，DAC模型只适应于用户量、客体少的系统中。
 
1.1.2MAC模型
    MAC模型的基本思想是系统在后台先判断出主体与客体自身所具有的不可更改的安全等级哪一个高，进而确定系统中某个主体对某个客体有哪些具体的操作权限。其中主体和客体的安全等级是由系统管理员强制设定的，其他人不可更改，一般包括很重要、比较重要、重要和普通四个等级。MAC模型遵循向下取读（主体级别高于或等于客体）和向上写入（主体级别低于客体）两个原则，这样信息只能向级别高的方向传递，防止信息扩散。
 
    MAC模型的安全性较强，然而，这种较强的安全性导致授权麻烦，其缺点是灵活性较低，应用范围小，通常只运用在一些有显著等级分化的领域中，如军事。
 
1.1.3RBAC模型
    RBAC模型的基本思想是系统管理员将对客体操作的权限分派给角色，然后用户通过用户-角色关系表间接地获取自己所对应角色对某客体的权限。角色（Role）是指企业中的员工按照其职能进行分类组合而成，只能由系统管理员定义。此外，一些核心的RBAC模型还提出了“会话”概念，它是某个用户到分派给该用户且当前正被系统激活的角色子集之间多对多的映射关系。该原理如图3-1所示：

    RBAC模型通过引入“角色”概念，让系统中的用户和相应的权限相关联，从而使授权管理变得更为方便、灵活，有效地解决了企业信息化管理系统中用户数量多、人员组织结构变动频繁等问题。因此，RBAC模型被当前国内外企业里中、大型的信息化管理软件广泛地应用。然而随着企业不断的需求，RBAC模型也存在一些不足：①权限粒度不够细化。
 
    系统在实际的应用过程中，用户为执行被分配的任意一个项目任务所必需的权限构成的集合很难与该用户所在的所有角色构成的权限集合相吻合；②运行代价过高。为实现权限管理，每个用户在执行一个操作或任务时，系统都要在后台多次查询权限表、任务表、角色-权限表和用户-角色表等，然后根据一定的策略判断系统中某个用户对某个客体有哪些相应的操作权限。
 
1.1.4TBAC模型
    TBAC模型引入了“任务”概念，其基本思想是利用工作流程中的每个“任务”构建访问控制模型，从而达到了实时、动态的权限管理的目的。一般地，多个具有一定逻辑关系的任务组合成一个工作流（Work flow，简称Wf）工作流中的每个流程任务都与一个授权单元(Authorization Unit，简称Au）相对应，每个Au由相应的一些授权步（Authorization Step，简称As）构成，Au或As之间都是根据某种依赖关系（如失败依赖、顺序依赖）组合起来。其模型如图3-2所示：

    前面介绍的三种直接授权模型通常采用(S，O，P)三元组来描述系统中某个主体S可以对某个客体O操作的权限集合P。然而，TBAC模型通常采用(S，O，P，L，As)五元组来描述系统中某个主体S对某个客体O所对应的授权步As在其整个生命周期L过程中所拥有的权限集合P。如果授权步As没有被系统中的某个用户或用户组激活，则As所拥有的权限集合P是不能被该用户或用户组所拥有的；只有当As被激活后，As所拥有的P才被激活，进入保护态等待执行，同时As的存活周期L开始进行倒计；当L终止后，相应的As无效，As对应的P也被回收。
 
    TBAC模型支持对于不同的任务或同一任务不同的状态的不同授权方式，实现了动态的授权管理，广泛应用在分布式以及工作流系统中。然而，由于TBAC模型中并没有完全的实现项目任务与角色之间的彻底分离，因此该模型不支持被动访问以及角色分层。
 
1.1.5经典直接授权模型的总结
    通过以上对四大经典直接授权模型的分析，总结出他们的特性、优缺点以及适用领域如表3-1所示：

    综上所述，四个直接授权模型都有自己所特有的优点或缺点，但是每个直接授权模型都不能独立地实现企业信息化管理系统中权限管理的高效性、准确性、灵活性、动态性以及细粒度化等需求。根据第二章所述PLM权限管理的需求分析以及四种经典直接授权模型的比较，可以看出综合RBAC和TBAC模型能基本满足PLM系统，下面两节将进一步完善这两种直接授权模型中的不足之处，进而提出基于用户-角色-流程的多约束直接授权（C-URTBAC）模型。
 
1.2C-URTBAC模型的特点
    根据第二章PLM系统权限管理需求的分析以及3.1所分析的四大经典直接授权模型，本章所提出的C-URTBAC模型具有五大特点：
1）细粒度化的约束、权限
    细粒度的权限表现在：该模型引入了约束，并根据约束的对象不同将其细化为关系约束以及属性约束。其中关系约束用来约束在流程-权限，用户-角色，角色-流程，用户-权限的授权过程，以免在授权过程中发生一些冲突。属性约束用来实现用户-临时角色，临时角色-流程、流程-权限的自动化分派。细粒度化的权限表现在：该模型支持流程-权限、用户-权限分派，从而保证用户完成某个任务所拥有最小的权限。
2）支持多授权方式
    该模型支持用户通过流程-权限，临时角色-流程、临时角色-权限间接获得流程权限的方式，也支持用户-权限直接分派方式，满足授权的灵活性。
3）自动化授权控制策略
    该模型引入用户-临时角色、流程-权限、临时角色-流程三种自动分派策略，大大地减少了系统中管理员的工作量。
4）角色和权限实时回收
    该模型定义的用户或角色的权限都是根据流程-权限来获取的，当某个流程任务完成之后，该角色与流程相关的权限全部回收，相应的角色或用户的权限也被回收；根据流程某个状态建立的角色也被回收了，对应的用户-角色关系也解除了，节省了数据库空间；当系统在后台计算某个用户对某个客体的权限时，也加快了读取数据库的时间。
 
5）用户分级管理
    该模型根据用户的工作性质将其细化为企业管理员角色、项目管理员角色、临时角色、稳定角色和一般用户。企业管理员是企业中完成整个PLM系统所有主体、客体以及权限等所有管理的工作，一个企业通常只有一个；项目管理员角色是根据企业中的不同项目而建立的，其数目由企业中的项目数目而定，主要执行项目下的任务分派，项目团队中具体权限分派等；临时角色是根据工作流程中的每个任务而自动建立的角色，稳定角色是企业管理员根据企业人员组织结构建立的必要角色，用来完成企业日常的行政工作；一般用户是指企业中目前没有参与到项目中的一些新员工。
 
1.3C-URTBAC模型的设计
    本文提出的基于用户-角色-流程的多约束直接授权模型（C-URTBAC）如图-3所示。该模型将“约束”细化到属性约束以及关系约束，并详细地说明基本元素之间的约束关系；根据企业项目或是员工职责将角色分为三大类；根据系统中主体、客体以及流程任务的属性以及属性约束规则提出三种自动分派策略。

1.3.1基本元素和映射关系
基本元素定义
    用户集U（Users）：每个企业中应用PLM系统的所有登录用户组成的一个集合，也就是企业里应用PLM系统的所有员工。
 
    角色集R（Roles）：用户的责任在PLM系统中的虚拟呈现，一般执行同一性质的任务构成的用户集合构建一个角色。该模型将角色细分为管理员角色（AR）、临时角色（TR）以及稳定角色（SR）。管理员角色包括了企业管理员角色（EAR）和项目团队管理员角色（PTAR），分别设置在企业和每个项目团队之中企业在完成某个项目阶段。临时角色是管理员根据项目任务需求设定的临时角色集合，当项目任务完成后，临时角色自动撤销。稳定角色是完成正常的行政工作而创建的角色，一般由企业管理员进行管理。
 
    项目团队（PT）：企业中每个项目是由不同部门的员工合作执行的，参与到一个项目的所有员工构建一个项目团队。
 
    任务（T）：分为项目任务（P_T）和其他任务（O_T）。项目任务，包括流程任务和子任务，是指企业员工为完成项目所需要执行操作的集合。企业的项目根据完成的部门不同被分解成一个个子任务，子任务的进度由文件来控制，文件通过工作流中的每个流程任务来推进进度，这些子任务与流程任务体现了用户在项目中的职责；其他任务是指某些行政工作等。
    客体（O）：主要指PLM系统中可以被用户或角色操作的对象，如文档、零件、菜单、文件夹、材料明细单等。
 
    权限集P（Permissions）：依据2.2.3节分析的权限可知，根据操作对象不同把PLM系统中的权限集P细分为功能性权限集FP和实体性权限集TP。FP是指用户对系统功能模块入口以及界面上的功能操作的权限，如用户管理，订单管理等；TP是又分文件夹权限DTP和流程状态权限WTP，DTP主要指对PLM系统中每个项目产生的文件夹的权限或非项目文件夹的权限；WTP是针对一个工作流程不同状态，用户或角色所拥有某个文件的状态权限。
    操作集（Ops）：主要指企业所应用的PLM系统中的用户或角色对系统中信息资源、菜单、命令等客体的全部操作方式组成的集合。
 
1.3.2约束定义
    该模型引入了关系约束和属性约束，关系约束用来限制在授权过程中基本元素之间的关系，避免发生各种冲突；属性约束用来实现临时角色的自动建立、任务-权限以及用户-角色的自动分派。
1.关系约束（RC）
该模型中的关系约束（RC）主要包括项目间的关系，角色间的关系，权限间的关系以及任务间的关系。
 
1）项目间的关系
    通常企业各部门都会同时执行两个或以上的项目，而且由于企业的人才、设备等基本不变，这些项目之间是有一定的关系的。总结这些项目之间的关系可以让不同团队相互交流项目相关的资源、或者防止不同项目之间的信息泄露，从而提高产品创新能力以及加快项目实施进度。企业在项目立项成功后由管理员来设置该项目与企业已完成或正在执行的其他项目之间的关系，同时项目在进行的不同阶段的资源交流也会实时变化。该汽车企业中的项目之间一般有如下五种关系：
    ①继承关系（VR）：表示某个企业里的所要完成的两个项目生产的产品类似。例如一个轴生产任务，团队M负责第一类轴制造，团队N负责第二类轴的生产，在任务执行的过程中，M可以查看N中的有效资源。
    ②所属关系（SR）：表示某个企业所要完成的一个大项目与其被项目负责人分解的一个个子项目之间的关系。规定企业内某一项目的责任人可以查看、引用或复制其子项目中的所有信息，但是子项目的负责人不一定就可以对这个项目的所有信息进行查看等操作。例如用户M是主项目的负责人，在项目具体的进行过程中M中可以任意查看其主项目下的子项目的所有信息。
    ③引用关系（RR）：表示团队M在处理处于某阶段的某一个项目时需要参考团队N中的一些信息。也就是说存在引用关系的两个项目，执行项目的团队M可以直接将另一个团队N的有用信息复制过来使用，这样可以提高完成项目的效率。
    ④顺序关系（PR）：表示当企业中一个大项目被项目负责人分解成若干个小项目，一个小项目执行的前提是上一个小项目完成，这两个小项目之间就是顺序关系。
    ⑤相斥关系（ER）：表示两个项目必须独立完成，参与到两个项目的团队不能相互访问。例如两个存在相斥关系的项目由团队M、N分别来执行，M和N中所拥有的资源不能相互共享。
 
    由3.3.2中关系约束定义可知，在企业管理员或项目管理员实际的授权过程中，权限之间、流程任务之间以及角色之间存在很多约束限制，而且它们之间又有一定的联系，若某类关系约束可以导致另外一类关系约束，则就称这两类约束之间有一定的传递性。这种传递性对于企业管理员或项目管理员在实际的授权中具有一定的影响，分析这种传递性可以提高授权效率，为此引入约束传递。
属性约束
 
    由于PLM系统中用户、角色、流程任务以及权限的数量庞大，导致其权限管理比传统的权限管理更加复杂。为了实现该模型的自动化控制策略，需要引入一些属性相关的概念。用户、角色、工作流程中的每个任务等自身都具备相应的一些属性，其中，用户或角色的属性反映用户或角色具有完成某类任务的能力或工作经验；任务属性表明角色或用户完成这一流程任务需要用户具备什么样的能力和工作经验。
 
    模型中这些元素的属性通过关系运算符构成属性关系式，然后用户、角色以及流程任务所特有的属性关系式两两进行匹配，匹配成功后系统会自动在后台进行流程-权限分派、用户-临时角色分派以及用户-流程分派，从而实现了系统授权的自动化，提高了授权的高效性以及准确性。
 
1.4基于集合的冲突检测算法
    由于模型设计到的基本元素比较多，各元素之间又有一定的约束关系，所以在实际授权过程中，会出现各种冲突，如权限冲突、任务冲突、角色冲突。为避免这些冲突，在系统根据属性约束自动授权后或根据一些特殊需求进行手动授权的过程中要进行关系约束检测。本节所提出来的检测算法主要是针对工作流程中的每个流程任务授权的过程以及用户激活要执行的任务。
 
1.4.1直接授权冲突检测算法
    当企业PLM系统中某个工作流程中的所有流程任务授权完成后，系统需要检测是否满足关系约束，这样才能确保授权合理。本文根据上面定义的关系约束集合，利用集合运算来判断授权是否会发生冲突。检测的步骤为：1）依据权限约束，检测工作流程中每个任务所拥有权限是否准确；2）依据关系约束的传递性，检测权限和任务间、角色和权限间是不是会引起一些冲突；3）依据任务间的约束检测两两任务是否与任务约束发生冲突；4）根据级差任务以及用户-角色表判断任务的执行用户是否合理。同时根据角色约束，检测执行当前任务的用户激活的角色是否有相斥关系。
 
1）权限约束检测
    采用函数CK_Per(AT，CP)来检测某个工作流程中的每个任务被管理员或自动授权策略授予的权限是不是合理的。检测的基本思路为：首先根据授权任务t与权限包含api或权限相依apd是否有交集来更新任务的权限集；然后采用P（t）获取任务的权限集，并根据相关指标分别判断与强/弱相斥权限交集的元素，从而保证授权的任务权限集满足强/弱相斥约束；最后根据势约束集的元素之间关系判断任务的权限是否满足权限势约束。具体的算法流程为：

2）关系约束传递检测
    采用函数CK_Per Tran(CP，CT，CR)检测关系约束的传递是不是会导致冲突。检测的基本思路为：首先判断强/弱相斥任务集中的任意两个任务对的权限集是不是属于强/弱相斥权限集，从而检测是否满足任务权限传递约束；最后根据角色包含关系及获取权限集函数P(r)来更新角色权限集。具体的算法流程为：

3）任务约束检测
    采用函数CK_Task(AT，CT)来检测工作流程中的所有流程任务是不是满足系统规定的任务约束。检测的的基本思路为：判断授权任务集中的任意两个任务是否既属于相容任务又属于相斥任务或级差任务，进而保证任务约束的合理性。具体的算法流程为：

4）角色约束检测
    采用函数CK_Role(AT，CR，tr)用来检测执行某个工作流程中的任意一个流程任务的角色是不是满足系统规定的角色约束。检测的基本思路为：首先分别采用Max(Role(t))、Min(Role(t))来获取执行任务t的角色最大级别和最小级别，并判断两者的大小来检测是否满足任务级差约束；接着用Executed User(t)获取执行当前正执行任务的用户集；最后判断该用户集是否属于相斥约束集，进而保证角色约束的合理性。具体的算法流程为：