支持工作流和团队协作增强RBAC模型.docVIP

支持工作流和团队协作增强RBAC模型 　　摘要：针对传统的访问控制模型不能直接应用到工作流和团队协作环境中的现象，本文提出了一种支持工作流和团队协作的增强RBAC模型，通过添加工作流任务、工作流上下文、团队和协同约束等组件，扩展RBAC核心模型，以解决在工作流和团队协作环境中对信息访问控制的特殊要求，提高工作流管理系统的安全性和灵活性。 　　关键词：角色 任务 访问控制 工作流 团队协作 　　中图分类号：TN401 文献标识码：A 文章编号：1007-9416（2013）11-0200-02 　　自20世纪60年代以来，学术界提出了各种信息访问控制模型来满足信息管理系统的安全需求。传统的访问控制模型分为两类：自主访问控制DAC和强制访问控制MAC[1]。DAC是在确认主体身份以及它们所属组的基础上对访问进行限制的一种方法，MAC通过预先定义用户的可信任级别及信息的敏感程度来完成信息的访问控制。美国国家标准与技术研究院提出的RBAC（基于角色的访问控制）模型[2][3]引入了角色的概念，先将访问权限分配给角色，然后再将用户分配给适当的角色，从而获得相应角色的权限。但RBAC模型是被动的安全模型，授权是静态的，没有考虑到工作流[4]。Sandhu提出的TBAC（基于任务的访问控制）模型[5]，依据任务和任务状态的不同，对权限进行管理。虽然TBAC模型支持工作流，但应用于复杂的企业环境时，仍有很多缺陷。例如在企业环境中，角色是一个重要的概念，但TBAC模型没有将角色与任务分开，也不支持角色的层次等级。 　　上述访问控制模型，虽然得到了很好的应用和发展，但不能直接应用到工作流和团队协作环境中。本文通过对RBAC模型进行扩展，提出了一种支持工作流和团队协作的增强RBAC模型。模型通过引入任务集、任务实例集、工作流上下文、实例团队和协同约束等组件，来支持工作流和团队协作的特殊需求。 　　1 RBAC访问控制模型 　　RBAC模型引入了角色的概念，通过角色控制用户访问计算机的资源，参考模型如图1所示。在RBAC中，权限被定义为操作和对象的集合，这些权限不是直接分配给特定的用户，而是通过用户角色分配（URA）和角色权限分配（RPA）来完成用户到权限之间的映射。角色继承（RH）定义了角色之间的继承与包含关系。约束被定义为规范URA、RPA和RH之间的关系，如职责分离是一种典型的约束，要求循环不相容的职责相互分离，实现合理的组织分工，以防止潜在的安全漏洞。RBAC模型通过动态地分配和取消用户的角色来完成用户权限的授予和取消。实现了用户与访问权限的逻辑分离，简化了权限的管理。 　　RBAC模型的授权是静态的，在执行任务之前，主体就拥有某种权限，在任务执行后，会继续拥有这种权限。在工作流和团队协作环境中，当数据在工作流中流动时，执行任务的用户在变，用户的操作权也在变，此时用户的权限与工作流上下文环境有关，传统的访问控制技术对此无能为力。若使用RBAC，则需要频繁更换角色，给系统管理带来不便。 　　2 支持工作流和团队协作的访问控制模型 　　2.1 模型描述 　　支持工作流和团队协作的访问控制（TG-RBAC）模型如图2所示。TG-RBAC模型的思想是在传统RBAC模型的基础上分别引入工作流任务、工作流上下文、团队和协同约束等组件来支持工作流和团队协作对信息访问控制的特殊需求。 　　模型的形式化定义如下： 　　用户：指独立访问计算机系统资源的主体，用USERS表示系统中所有用户的集合。 　　角色：角色是在企业组织结构或者一个任务中用户拥有的一种职责或地位，用ROLES表示系统中所有角色的集合。 　　团队和实例团队：团队是拥有不同角色的用户集合和完成特定任务所需要的角色集合，用TEAMS表示系统中所有团队的集合。实例团队是执行一次任务实例所需要的所有用户的集合。 　　会话：是用户与角色和团队之间的映射。当用户激活了部分或者全部被授予的角色和团队时，就建立了一个会话，用户是通过在会话期间激活角色和团队来获取操作权限和任务的。 　　权限：是用户对计算机系统资源进行某种操作的许可权，用PERMS表示系统中权限的集合。 　　任务和任务实例：任务是要进行操作的统称，包括工作流管理系统中的流程任务和用户对计算机系统资源的各种操作权限，用TASKS表示系统中所有任务的集合。任务实例是任务运行中的实例。 　　角色继承：为了避免相同权限的重复设置，角色除了自身的属性和权限之外，还可以继承其它角色，从而自动拥有被继承角色的属性和权限。 　　URA：URA USERS×ROLES，表示多对多的用户角色分配关系，即一个用户可以被授予多个角色，一个角色可以分配给多个用户。TRA：TRA TASKS×ROLES，表示多对多的任务角色分配关系