本发明公开了一种面向云服务的UCON多义务访问控制方法及系统。本方法为：1）设置每一云服务的义务项；建立每一云服务所包含的义务图；2）根据用户所请求的云服务查找该云服务的所有强制义务图和可选义务图，并提取该用户对该云服务的历史完成情况；3）对每一强制义务图，监控其每一义务项所对应属性的属性值，判断该义务项是否完成，并检查所有强制义务图是否已经完成，如果完成则进行步骤4）；4）对每一可选义务图，监控其每一义务项所对应属性的属性值，并根据该义务项的历史完成情况判断该义务项的完成概率；然后计算该云服务所有可选义务图的完成概率，如果其大于设定阈值则开始为该用户提供该云服务。本发明访问控制灵活且效率高。
技术领域
[0001] 本发明提出一种在云服务中实施访问控制的方法，用以保证提供云服务的系统中数据的安全。本发明的技术领域涉及分布式系统，访问控制。
背景技术
[0002] 当今，"云"相关概念已经成为人们关注的热点。通过云服务，用户可从世界上任何一个地方通过互联网访问云端的数据和服务。私有云为一个小型的公司或者组织用户提供数据存储服务，公有云则面向公众提供多样化的数据处理服务。无论云服务规模大小，数据安全都是不容忽视的因素，并且已经成为云服务进一步发展的瓶颈。访问控制则是在身份鉴别之后保护系统资源安全的第二道屏障，对于每个提供远程访问的系统来说都是一个很重要的组成部分。访问控制的核心任务是从物理层到服务层限制主体(通常是系统资源的使用者)对客体(数据或者系统资源)任意访问的行为。一些流行的访问控制模型，如RBAC模型、中国墙模型、UCON模型，已经被很多云服务提供商采纳用以保障云平台安全。
[0003] 传统的访问控制模型，最经典的应该是BLP模型和Biba模型。BLP模型是由David Elliott Bell和Leonard J.LaPadula于1973年提出的，主要用于增强对政府和军事应用的访问控制，它遵循Roger R.Schell为美国国防部提出的应用于为军事安全系统设计的多级安全策略。BLP模型本身是一种强制访问控制，主要面向保护信息的机密性。在该模型中，访问主体、客体、权利、访问矩阵等基本思想被详细阐释，这些思想被随后出现的访问控制模型所沿用。BLP模型提供了访问控制模型中最基本的思想——S-O-R模式，即一个主体S对应一个客体O有相对应的权利R。而Biba模型则关注数据完整性，它是由KennethJ.Biba在1977年提出，主要为了规避BLP模型中未涉及的有关数据完整性的风险。时至今日，这两种模型的思想仍然被广泛使用，然而，由于机密性和完整性在系统安全中都是重要的指标，而BLP模型和Biba模型都只能涵盖其中一个方面，因此很少有系统直接使用这两种模型作为访问控制模型。
[0004] 基于角色的访问控制模型，即RBAC模型，是由Ravi S.Sandhu等人于1996年提出的。它兼顾了强制访问策略和自助访问策略，引入了"角色"的概念，以归类的方式将角色分派给用户，并对应于特定的权限，角色与角色之间也引入了相互关系，这样主体之间和客体之间的关系也就自然地相互关联起来了。RBAC模型是迄今为止使用最广泛的访问控制模型，它涵盖了商业、教育、医疗等各个方面。然而，随着云服务的发展，RBAC在应用中逐渐显现出一些问题。RBAC最主要的问题在于角色爆炸问题和难以管理问题。在云环境下，尤其是公有云环境下，RBAC模型需要定义角色并将角色与权利对应起来。但是，云环境下的访问控制的一个显著需求就是适应频繁变化的环境，系统管理员很难在这种环境下定义出准确的角色并描述角色之间的层级关系，进一步的，角色代表的意义也在频繁变化，因此管理员需要非常小心的调整属性与主体、权利之间的对应关系，这种管理工作量在云环境下是巨大的。虽然随后又出现了 ARBAC这种专门对RBAC角色结构进行管理的模型，然而ARBAC本身就有很大的局限性，因此所管理的RBAC模型的实现也将受到很大的局限性。
[0005] 另一种流行的访问控制模型是中国墙模型。中国墙模型可以提供一个屏障，对于有利益冲突的两个企业，他们的数据资料通过这个屏障可以有效得到保护，阻止对方获取数据。中国墙模型中引入了利益冲突域这个概念，它也是中国墙模型的核心概念。然而，它的特点也给它的使用带来了很大限制，由于任何两个组织或者企业之间的关系完全归纳于两种情形即有相互冲突和没有相互冲突，这种过于简单的限制很难描述现实中复杂的场景。进一步的，一旦一组冲突关系发生变化，影响到的将是整个系统中冲突关系的重新调整。因此，它也不适用于云环境这种相对复杂的场景中。
[0006] 使用控制(Usage Control, UCON)模型是一个细粒度的访问控制模型，它的很多特点都适合于云环境，其中，属性易变性和控制连续性最为引人关注，它们能够显著提升云环境下模型的可用性。属性易变性意味着UCON模型中的属性可以适应云环境下不断变化的情景，并将这种不确定性体现在访问主体和访问客体之上；控制连续性意味着UCON模型对整个访问控制过程是持续监控的，只要有满足触发条件，UCON模型可以在用户访问云服务资源的任何时候进行访问控制检查，以保证访问的合法性，维护系统安全。越来越多的云服务系统已经采用了 UCON作为他们的首选访问控制模型，UCON甚至被誉为下一代访问控制模型。在详细描述我们针对UCON模型的工作之前，了解UCON模型的组成是很有必要的。
[0007] UCON模型如图1所示。图1中，主体(Subjects)通常代表想要获得驻留在云服务提供商处的数据或资源的用户。每个主体都有主体属性(Subject attributes)，主体属性可以对主体进行描述,通过主体属性,访问决策者可以判断出主体的身份并据此做出相应的决策。客体(Objects)是主体所请求的资源或实体。与主体属性相似的是，每个客体都有客体属性(Object attributes)，客体属性可以对客体进行描述，通过客体属性，一个客体可以显著地区分于其他客体。权利(Rights)是一个主体可以拥有并且操作相应客体的特权。授权(Authorizations)通过评价当前主客体属性值,决定该客体的某项特权是否可以授予给主体。条件是系统相关的以及环境相关的因子，用以测量系统状态，它们可以被看作是系统属性。义务会给出一个主体要获得某项权利需要完成的动作。UCON是一个基于事务的模型，而每个事物中既包含了主客体的基本信息，又包含了主体需要完成的任务，前者体现在授权中，而后者恰恰可以由义务反映这样的特性。义务是强制的，这意味着只有所有的与某一权利相关的事务都完成了，云服务系统才可以断言义务成功的完成。
[0008] UCON模型反映了访问控制的强制性要求，即只有满足授权中指明的访问规则，完成义务中要求的任务，并在系统状况正常的情况下，才允许用户访问系统资源。
[0009] 然而在实际使用中，UCON模型的义务部分仍然缺乏灵活性。由于义务的完成往往是用户与访问控制系统交互的过程，因此大量的时间用于等待用户交互的结果，其执行效率受到很大限制。此外，在云环境下，用户的行为以及需求也都是不同的，甚至有时是不确定的，因此，一个严格的模型在实际应用中往往无法处理较为灵活和复杂的问题。更进一步的，由于云环境下的访问用户的不确定性，我们希望在非法用户破坏系统之前就识别出用户的意图，或者通过额外的访问控制检查验证用户的身份，而现有UCON模型仅仅对当前属性进行判定，而不考虑属性未来的趋势。而义务部分会要求用户和访问控制系统进行交互，在这期间，系统可以通过收集用户行为，对用户未来的动作趋势进行预测。从以上讨论中可以看出，义务最能够表现UCON模型的特征，因此，给出一个详细描述义务的实用的模型是非常必要的。本发明的其中一项重要的工作就是要给出UCON模型中义务组件的详细设计。
[0010] 目前，在UCON模型中已经有一些改进的策略，在本发明中，我们参考了这些方案。下面，这些文章内容会被列出，并简要讨论我们的工作与这些工作的区别。
[0011] Park和Sandhu提出了 UCON模型并且定义了 UCON模型中的各个组件。UCON模型既包含了传统访问的访问控制能力，又引入了一些新的特性用以支持细粒度的、面向事务的访问控制方法。Zhang等人给出了 UCON模型的形式化描述，包括UCON模型各部分的详细语义描述。基于这些基本概念和思想，我们扩展了 UCON模型，并仍然保留现有UCON模型的所有特性。
[0012] Tavizi等人构建了一个云环境下的UCON访问控制模型架构。他们清晰地描述了系统中每一部分，并且讨论了系统中的数据流。他们敲掉了义务的重要性，并且设计出了一个架构来存储义务项、对于事件的反馈方法和事件如何触发义务变化。然而，他们的方案中所有的义务项都是相互独立的，并且系统需要等待所有的义务都完成后才可以授予主体相应的权利。
[0013] Chen等人和Almutairi等人通过引入协商机制把用户加入到系统中。并且,Chen等人给出了一个基于访问控制条件的参数自动协商机制的方法。然而，他们都只着眼于UCON模型的整体，并未给出详细的义务设计。我们将着眼于义务的设计，并实现义务完成与用户的交互以及义务执行的自动调整。
[0014] Krautsevich等人指出，每个属性可以归纳出多个离散的值，并且这些值都关联着一个基于历史情况的概率。他们采用连续时间马尔科夫链来预测属性值在下一刻的变化，并根据预测值采取措施规避风险。他们的工作在UCON的属性上很好的工作，但这些工作并不完全适用于义务。我们使用贝叶斯网络构建属性结构，并且用它来预测完成所有义务项的可能性。
[0015] 在本发明中，我们将提出"基于UCON的多义务模型"，定义义务部分的组件，讨论由多义务模型衍生出来的针对访问控制系统的优化，最后给出实现多义务系统的原型架构设计图。
发明内容
[0016] 针对现有UCON模型访问控制过程中灵活性较低，只能检查当前状态而不能预测用户行为的问题，本发明提供了一种改进策略，即通过对UCON模型中的义务模块进行详细设计，使义务模块既能增强系统数据的安全性，又能提高访问控制的灵活性。
[0017] 云环境的特性是频繁变化和不确定性，因此云服务提供商更希望要求用户完成一些任务来表明自己的身份。因此，我们需要一个细粒度的机制来管理和监视每个任务的完成情况。更进一步地，完成任务的序列也是不可以忽视的问题。实际中存在这样的情况，一个任务只有当另一个任务已经完成的前提下，才可以开始完成，因为另一个任务需要为这个任务做数据准备；为了给用户更多的自主权，云服务系统甚至可能允许用户从一些备选任务中自由选择任务去完成。根据用户的选择，系统可以根据不同的需求自动调整后面需要完成的任务。当用户正在完成任务时，我们可以通过用户已完成任务的情况以及历史上完成任务的方式来预测用户下一步的动作。除此之外，任务的完成通常是费时的，现有系统总是会等待用户完成所有的任务。在这种情况下，系统效率很难保证，因为用户必须在完成所有任务后等待系统计算并返回给用户最终结果，因此在能够保证系统安全的前提下，我们可以尝试提前为用户进行数据准备，以缩短用户最终等待数据计算结果的时间，以改善用户体验。
[0018] 为实现上述目标，本发明将访问控制中任务的概念融合到UCON的义务中。我们通过引入义务项的概念，细化了整个模型。一个义务项是一项任务，这个任务是云服务提供商要求用户完成的，例如在购买一张数字唱片的版权之前填写一个相关的调查问卷。接着，我们引入了不同义务项之间执行顺序的的概念。例如，我们需要首先使用用户计算机上的TPM模块来构建一个可信环境，然后一些安全参数如私钥才可以进行传递。我们同时允许用户从多个备选义务项中选择一部分义务项去完成，例如用户可以从使用信用卡支付和使用支票支付中进行选择。根据用户的选择，系统将会提供给用户不同的后续义务项，以达到不同的安全目的。最后，我们会使用概率算法预测用户下一步的动作，如果我们发现用户后续动作很有可能威胁系统安全，我们可能对其实施额外的访问控制检查，甚至在确信该用户是带有不良企图来访问系统时直接吊销其访问资格；另一方面，通过计算我们发现用户有很大可能性完成所有访问控制检查，我们会为用户提前准备执行环境和用户数据，以减少用户在完成访问控制检查后的等待结果时间，提升用户体验。
[0019] 通过多义务访问模型，云环境的安全性可以得到提升，同时，增加了访问控制的灵活性，保证了系统的高效运转。
技术方案
[0021] 一种面向云服务的UCON多义务访问控制方法，其步骤为:
[0022] I)设置每一云服务的义务项；建立每一云服务所包含的义务图并将其保存到一义务图数据库中；所述乂务图包括强制乂务图和可选乂务图；所述乂务图为有向无环图；
[0023] 2)根据用户所请求访问的云服务从所述义务图数据库中查找该云服务的所有强制义务图和可选义务图，并提取该用户对该云服务的历史完成情况；
[0024] 3)对于该云服务的每一强制义务图，依次监控该强制义务图每一义务项所对应属性的属性值，判断该义务项是否完成，并检查该云服务的所有强制义务图是否已经完成，如果完成，则进行步骤4);
[0025] 4)对于该云服务的每一可选义务图，依次监控该可选义务图每一义务项所对应属性的属性值，并根据该义务项的历史完成情况判断该义务项的完成概率；然后计算该云服务所有可选义务图的完成概率，如果其大于设定阈值，则开始为该用户提供该云服务。
[0026] 进一步的，所述有向无环图为BG〈V，E> ;其中，V代表是该有向无环图中所有义务项的集合；E为有向无环图中的边的集合，每一边为一义务项二元组，其中第一个元素指向第二个元素；所述强制义务图为除开始义务项和终结义务项之外的所有义务项都有唯一的一个前驱义务项和一个后继义务项；所述可选义务图为除初始顶点外，每个顶点都有一个或多个后继顶点以及一个或多个前驱顶点。
[0027] 进一步的，所述可选义务图中设置一终节点，所述可选义务图中所有的无后继义务项的义务项顶点指向该终节点。
[0028] 进一步的，所述步骤4)中，如果可选义务图中的义务项完成概率会受到它的前驱节点完成情况的影响，则利用贝叶斯网络计算所述可选义务图的完成概率；其中，贝叶斯网络中代表随机变量的节点为义务项，该节点上附加有对应义务项的完成概率；贝叶斯网络中节点间相互关系的边为可选义务图中表示义务执行先后关系的边。[0029] 进一步的，所述步骤4)中，如果可选义务图中的义务项完成概率不受到它的前驱节点完成情况的影响，即每个义务项的完成情况视为相互独立的，则将该可选义务图中每个义务项的完成概率相乘，得到该可选义务图的完成概率。
[0030] 进一步的，所述步骤4)中，如果可选义务图中的分支大于设定值，则使用Dijkstra算法从该可选义务图中找出最大完成可能性的路径，计算该路径的完成概率作为该可选义务图的完成概率。
[0031] 进一步的，利用公式
计算所述义务项的完成概率r;其中，用户在历史上总共被要求完成此义务项的次数，η为该用户实际完成的η次；η < m。
[0032] 一种面向云服务的UCON多义务访问控制系统，其特征在于包括义务转译器、属性监视器、决策中心、义务图数据库、执行义务图数据库；其中，
[0033] 所述义务图数据库，用于保存针对每一云服务所建的义务图；每一云服务设置有多个义务项；所述义务图包括强制义务图和可选义务图；所述义务图为有向无环图；
[0034] 所述义务转译器，用于根据用户所请求访问的云服务从所述义务图数据库中查找该云服务的所有强制义务图和可选义务图，并将其副本保存到所述执行义务图数据库；并且提取该用户对该云服务的历史完成情况；
[0035] 所述属性监视器，用于根据用户当前执行的义务图，监控对应的属性的属性值；
[0036] 所述决策中心，用于根据用户当前执行的义务图，以及当前监控的属性值和期望的属性值，确定当前义务项的完成情况；并且计算所有强制义务图和可选义务图的完成情况。
[0037] 进一步的，所述属性监视器`在当前执行的义务图未完成时，监控到该义务图中的属性值发生变化，则所述决策中心主动检查该属性对应的义务项是否完成，并根据检查结果对该义务项进行记录。
[0038] 为了实现细粒度的访问控制，我们将UCON的义务部分需要用到的新概念进行定义:
[0039] 义务项
[0040] 一个义务项是系统要求用户完成的构成某个义务的一部分，义务项可以理解为访问控制系统为达到某个目的而要求用户必须完成的一项任务。如果B代表某个义务的义务项全集，B中共有η个元素，Obi代表第i个义务项，那么
[0041] 
[0042] 在现有的UCON模型中，是不区分单个义务项的，而是把所有义务项看成一个整体，统称为义务。
[0043] 义务图
[0044] —个义务图，如BG〈V，E>，是由一组义务项组成的，义务项被组织成有向无环图的形式。这里，V代表是该义务图中所有义务项的集合。其中，V和义务项全集B的关系是
[0045] 
[0046] E是一个二元组的集合，每一二元组由V中两个不同的义务项组成，即E是V中所有元素两两组合的真子集:
[0047] 
[0048] 这里要求，BG必须是一个有向无环图，因此，E中的元素也必须符合有向无环图的标准，即图中找不到一条通路，对于BG中的任何一个节点从该节点出发最终可以回到该节点。E中每个元素表示有向无环图中的一条边，从二元组中的第一个元素指向第二个元素。这实际上表示了义务项的执行顺序，即先执行第一个义务项，后执行第二个义务项；有了 V和E，按照图论的一般知识就可以直接生成所期望的图。
[0049] 义务图可以表示不同义务项之间的完成顺序。义务图中的顶点表示不同的义务项，边表示两个义务项的执行顺序。如果一个义务项是另一个义务项的前提条件，那么我们就用有向线段从后者指向前者。它代表用户必须先完成前者，然后才能完成后者。
[0050] 义务图可以根据他们的特点和功能分成两类:强制义务图和可选义务图。
[0051] 强制义务图
[0052] 强制义务图是一种义务图，在这个义务图中所有的义务项，除了开始义务项和终结义务项，都有唯一的一个前驱义务项和一个后继义务项。开始义务项仅有一个后继义务项，终结义务项仅有一个前驱义务项。实际上，一个强制义务图的结构是一个链状有向图。对于一个强制义务图MBG〈Vm，Em>, Hiobi是第i个义务项，Vm包含k个义务项，即
[0053] 
[0054] 那么，E111可以表示为
[0055] 
[0056] 在强制义务图中，当且仅当所有的义务项都完成，我们才能断言这个强制义务图已经完成。
[0057] 强制义务图通常由一些与系统安全或者数据安全相关的义务项组成，用户必须完成全部义务图中的义务项。我们强烈建议强制义务图中的义务项是安全相关的义务，因为强制义务图本身是源于传统的UCON模型，而传统的UCON模型已经被证明是安全的。
[0058] 图2是一个典型的强制义务图，它包含了三个义务项，用户需要从义务项mobl开始执行，当执行完一个义务项后，下一个义务项才会提供给用户。当义务项mob3执行完成时，我们才会认定，该强制义务图完成。
[0059] 可选义务图
[0060] 可选义务图是一种义务图。在可选义务图中，除了初始顶点外，每个顶点都有一个或多个后继顶点以及一个或多个前驱顶点。当一个义务项有多于一个后继义务项时，意味着当完成当前义务项后，用户可以从多个后继结点中选择一个来执行。对于可选义务图0BG〈V。，E。〉，OObi代表第i个义务项，并且V。中包含k个义务项，即
[0061] 
[0062] 那么，与E相似的是，E0也可以表示为:
[0063] 
[0064] 这里，可选义务图必须是一个无环图。在可选义务图中，有可能存在多于一个的义务项没有后继义务项。如果这些义务项中的其中一个完成，那么我们就可以断言这个可选义务图已经完成 。因此，我们引入了一个特殊顶点"终节点"，并使所有的无后继义务项的义务项顶点指向这个顶点。如果一个与终节点相连的义务项成功被完成，那么终节点就会标记为被完成，此时，系统会断言该可选义务图被完成。
[0065] 实际中，可选义务图中的义务项总是在所有的强制义务图完成后才会开始允许用户完成，这是因为当所有的强制义务图完成后，一个安全的环境才建立完成。我们推荐可选义务图中的义务项是业务相关的，例如从上千种股票中圈定一个股票的范围用以科学计算。
[0066] 图3是一个典型的可选义务图。用户从义务项oobl开始执行。当执行完oobl后，系统会让在oob2和oob3两个义务项中选择一个执行，用户可以根据自己情况自主选择。当oob5完成后，义务图到达"终节点"，这就意味着用户完成了该可选义务图。
[0067] 义务簇
[0068] 义务簇是义务图的集合。与义务图相似的是，义务簇也可以分为两种:强制义务簇和可选义务簇。义务成功完成的充分必要条件是强制义务簇和可选义务簇都分别成功完成。
[0069] 强制义务簇
[0070] 强制义务簇是用户必须完成的强制义务图的集合。一个由k个强制义务图组成的义务簇可以表示为:
[0071 ] 
[0072] 当判断一个强制义务簇是否成功完成时，我们必须检查义务簇的所有义务图是否完成。当且仅当所有的强制义务图都成功完成时，我们才能断言这个强制义务簇成功完成。
[0073] 可选义务簇
[0074] 可选义务簇是用户必须完成的可选义务图的集合。一个由k个可选义务图组成的可选义务簇可以表示为:
[0075] 
[0076] 当判断一个可选义务簇是否成功完成时，我们必须检查可选义务簇中的所有可选义务图是否成功完成。当且仅当所有的可选义务图都成功完成时，我们才能断言可选义务簇成功完成。
[0077] 与强制义务簇不同的是，可选义务簇引入了"预测完成"的概念。我们将在后面的章节中讨论这个概念。
[0078] 在实际中，每个用户会要求完成一个强制义务簇和一个可选义务簇。当且仅当强制义务簇和可选义务簇都被标记为完成时，我们可以说义务就全部完成了。
[0079] 图4给出了这些概念的关系以及在系统中义务关系是如何组织的，从图4中，可以看出，一个用户每次进行义务检查时有唯一的一个MBC和唯一的一个0BC，每个MBC和OBC中可以有若干个义务图，每个义务图中也会有若干个义务项需要完成，强制义务图是链式的结构，而可选义务图一般为有向无环图。需要指出的是，义务图是可以复用的，如果期望对同一安全特性进行检查，可以使用同一义务图。另外，不同义务图也可以有相同的结构，但涉及的义务项一定不同。
[0080] 通过对UCON模型中义务部分的扩展，我们可以细粒度地控制义务的执行过程和执行顺序。在强制义务簇的所有强制义务图中的义务项必须全部完成，因为它反映了多义务模型的强制安全特性。多义务模型要求只有当所有的强制义务簇中的义务项都完成之后，用户才可以开始完成可选义务簇中的义务项。可选义务簇的提出是为了应对业务相关任务的需要。可选义务簇要比强制义务簇更加复杂。在可选义务簇中，义务项通常要求用户参与完成，甚至会需要一定的计算资源，因此它通常是耗时的。用户必须等待很长一段时间来得到服务最终给出的结果。可选义务簇中的义务项总是关于业务或者应用问题的，它们只需要相对较弱的安全控制即可，因此，当用户并没有完成所有的可选义务项，但此时可选义务簇的完成概率极高的情况下，系统提前为用户进行数据准备，甚至为用户开始计算服务，都是合理的。在这种情况下，用户无需等待那么长时间就可以得到最终的结果。在这一部分，我们将给出可选义务簇中的预测完成算法。
[0081] 由于可选义务图和贝叶斯网络都是有向无环图，因此，一个可选义务图就是一个贝叶斯网络，贝叶斯网络中代表随机变量的节点为义务项，贝叶斯网络中节点间相互关系的边为可选义务图中表示义务执行先后关系的边。
[0082] 当可选义务图正在执行时，完成概率将会被附加在每个义务项之上。完成概率是关于该义务项被某一特定用户完成的历史情况记录，使用完成率(％)作为单位。完成率一般通过简单的计算即可得出，例如，某一用户在历史上总共被m次要求完成此义务项，而该
用户实际完成了 η次(η ≤m)，那么完成率r就可以简单的用r=n/mx100%汁算，它表明该
用户完成这个义务项的概率。需要指出的是，不同的用户在相同的义务项上可能有不同的完成概率。
[0083] 可选义务簇的所有可选义务图可以同时被一个用户完成。当一个义务项完成后，我们会计算每个可选义务图的当前完成概率，然后将该用户所有的义务图都集合在一起计算完成整个可选义务簇的概率。多义务模型要求系统通过计算检查是否当前完成概率已经大于一个门限值。如果大于，我们把这个状态称作"预测完成"。此时，系统开始提前为用户提供需要的服务。需要说明的是，门限值是一个经验数值，由系统管理者设定。它代表着系统可以断定用户能够完成整个可选义务簇的最低概率要求。
[0084] 在我们的|旲型中，一共存在着二种状态:未完成、预测完成、完成。未完成意味着强制义务图中有一些义务项还没有完成，或者可选义务簇的完成概率低于门限值。预测完成意味着在强制义务图已经完成，而可选义务簇中的一些义务项还没有完成，但可选义务簇整体的完成概率已经高于门限值。完成意味着强制义务簇和可选义务簇都已经完成。
[0085].基于依赖义务项概率的预测
[0086] 基于依赖义务项概率的预测是处理这样的情形:一个义务项的完成概率会受到它的前驱节点完成情况的影响。
[0087] 在义务项完成概率相互之间有依赖的情况下，可选义务图会被组织成贝叶斯网络的形式，我们采用贝叶斯网络的知识作为我们的预测算法。贝叶斯网络是一个很强大的工具，通过它可以较为准确的预测事件的发生概率，此外贝叶斯网络更有自我学习的能力。贝叶斯网络本身就是一个有向无环图，它的顶点表示系统变量，有权边表示连接顶点的因果关系。
[0088] 我们用一个有限集合
表不一组离散随机变量。对于
每个元素都代表可选义务图中的一个义务项，他们的取值由
表示，每个值都表示对应义务项的完成概率，这个概率是根据用户额访问历史记录计算得出的。初始状态下，我们可以使用方程1.1计算可选义务图的完成概率:
[0090] 当一个用户完成了一部分义务项，并且未完成的义务项为从t(t> 2)到n，那么我们可以断定
[0091] 
[0092] 这里，Pt表示的是当下一个需要完成的义务项为t时的某一义务项的概率。
[0093] 方程1.2的结果是显然的，因为所有的从yi到yt_i的义务项都已经完成了。为了得出此时的完成概率，我们可以用由1.1简化而来的式子1.3来计算:
[0095].基于独立义务项的预测
[0096] 使用贝叶斯网络，义务项之间的依赖关系将会显著影响到完成概率。因此，此时我们必须小心的记录下用户每次完成义务的路径，并记录下每次执行义务时访问主体属性的变化情况，然后根据这些情况对用户行为进行预测。
[0097] 贝叶斯网络预测的准确性是毋庸置疑的，但当使用它进行预测时，需要大量数据作为支撑，同时使用较为复杂的算法，才能将最终结果计算出来。然而，在一些情况下，系统并不需要如此严格的安全性保障，也就是说，系统更多的精力会放在预测用户完成所有义务的概率上。这时候，我们可以简化预测模型。
[0098] 这里，我们提出了两种算法，用来预测可选义务图的完成概率:基于相互独立事件概率算法和Dijkstra算法。
[0099] 在基于相互独立事件概率算法中，所有的义务项之间的完成概率不受其它义务项完成概率的影响。在该算法中，每个义务项被视为相互独立的，因而，它符合概率论中相互独立事件的情形，在计算可选义务图的完成概率时，我们只需要将每个义务项的完成概率相乘即可。我们可以使用方程1.4进行计算:
[0100] 
[0101] 当义务项从I到t-l已经完成时，我们可以使用由方程1.4衍生而来的方程1.5进行计算:
[0102] 
[0103] 然而，实际中，可选义务图中经常会出现一个义务项有多个前驱义务项或者有多个后继义务项，在这时候，从图的层次角度来说，这些前驱义务项或后继义务项都是同一个层次的。对于处于同一个层次的多个义务项，我们计算时按照如下公式进行计算:
[0104] 设义务项Ob1, ob2,...，obn在可选义务图中同属于同一层次，即同为某一义务项的前驱结点或后继结点，那么它们之间的概率按照以下公式进行计算:
[0105] 
[0106] 公式1.6的意义为同层义务项的综合完成概率为所有同层义务项中至少完成一个的概率。
[0107] 我们给出一个简单的例子来解释我们的算法。现在可选义务图中有三个义务项:obl、ob2和ob3。义务项obi和ob2是义务项ob3的共同前驱。如果ob1、ob2和ob3的完成概率分别为90%、85%和80%，那么初始状态下可选义务图的完成概率为:
[0108] 
[0109] 然而，相互独立事件概率算法更适合于可选义务图有一个较简单的结构。一种极端情况是如果可选义务图非常的复杂，存在大量的分支，那么我们考虑每个可能的路径并计算它们的完成概率将是非常低效的方法。因此我们提出了另一种方法，通过使用Dijkstra算法找出最大完成可能性的路径。如果找到的路径高于门限值，我们可以预测用户有很高的可能性能够完成所有的义务项。
[0110] Dijkstra算法适合于要求进行访问控制判定的系统中，在这样的系统，一般并不要求很高的预测精度，而是需要访问控制的决策尽可能快，从而能对更多用户进行访问控制检查。另外，如果可选义务图从起点到终点有很多条通路(通常大于10条)，那么使用Dijkstra算法的效率就会比另两种算法高效得多。
[0111] 在使用Dijkstra算法前,我们必须先处理数据，使得它们满足Dijkstra算法的要求。对于义务项集合
,对应义务项的历史完成概率为{pl，p2，p3,…，pn}。我们需要计算的是义务完成概率P的值，即
的值,但这并不符合Dijkstra算法的要求。现在，我们对P取对数，得到
[0112] 
[0113] 因为pl，p2, p3等都是介于O到I之间的数字，因此它们的对数将为复数。这时，我们对整体取复数，即，
[0114] 
[0115] 这样，我们就可以使用Dijkstra算法，通过计算最短路径，找到最小的-logp，然后再反求P，最终得到概率最大完成可能性的路径。
[0116] 我们给出了使用Dijkstra算法找出完成最大可能性整个计算过程:
[0117] 
[0118] 与现有技术相比，本发明的有益效果:
[0119] 本发明针对云环境下访问控制的特点，基于UCON访问控制模型，设计了多义务访问控制模型。通过该模型的使用，使用户参与到访问控制过程中，针对不同业务需求以及用户特点，提供灵活的访问控制要求，以保证系统的安全。同时，通过收集用户完成义务情况的历史记录，预测用户下一步的行为，可以提前帮助系统规避可能的风险，也可以帮助系统了解用户完成义务的可能性，从而在必要的时候提前为用户进行数据准备等工作，提高系统效率，提升用户体验。
附图说明
[0120] 图1为UCON模型结构图；
[0121] 图2为一个强制义务图；
[0122] 图3为一个可选义务图；
[0123] 图4为多义务模型中义务的组成图；
[0124] 图5为多义务模型的实现架构图。
具体实施方式
[0125] 多义务模型的实现架构如图5所示，给出了多义务模型的组成部分。同时，在义务架构之外还有两个重要的数据库:访问历史数据库和属性数据库。
[0126] 义务转译器
[0127] 义务转译器负责接收访问控制系统的义务检查要求，准备义务图，抽取将要进行监控的属性。义务转译器获得的义务检查要求是由访问控制系统给出的，当接收到相应义务检查要求之后，义务转译器尝试从义务图数据库中找出合适的已经经过预设的义务图，这些预设的义务图一般都是对应于某项特定的服务，由服务提供者设定的。当访问控制系统给义务转译器提出检查要求时，会将具体对应的服务信息也发送给义务转译器，义务转译器根据不同的服务，到义务图数据库中找出合适的预设好的义务图，然后将这个义务图复制一份，并把从访问历史数据库中得到的访问历史概率附加到相应的义务项上面。最后，义务转译器负责触发义务监视器，对所有义务项相关的属性进行监视。需要指出的是，具体需要监视哪些属性，是和义务图中的义务项有关的，只要是义务项涉及的属性，都需要进行监视。
[0128] 属性监视器
[0129] 属性监视器负责从属性数据库中提取主客体属性，响应属性更新请求，以常规时间间隔监视属性值的最新变化，并负责将属性值提交到决策中心。属性监视器为每个访问会话保存一个属性列表。一旦系统的其他部分需要最新的属性数据，属性监视器将立刻从属性数据库中取出最新的数据。同时，属性监视器将会有规律的主动检查是否有最新的属性值更新，一般30秒一次。如果属性值有变化，属性监视器会将最新的属性值以及访问会话信息送到决策中心重新进行决策。
[0130] 决策中心
[0131] 决策中心是义务的决策点。它检查对于一个特定访问会话是否所有的义务都已经完成，并根据决策结果通知执行代理下一步的工作。决策中心根据执行义务图数据库中的信息做决策，那里包含了访问历史，当前访问状态，决策的期望值等信息。基于当前的属性值和期望的属性值，决策中心将会给出决策结果。决策结果包括未完成、预测完成、完成，这些结果将会发送给执行代理。
[0132] 执行代理
[0133] 执行代理将会接收决策中心的决策结果。根据结果，执行代理会为用户传递下一个义务项、执行用户请求、或者仅仅是通知用户义务还未成功完成。
[0134] 义务图数据库
[0135] 义务图数据库保存着所有强制义务图和可选义务图的描述，它们包含着完成义务项的特定任务。它可以由系统管理员或者资源拥有者进行配置。在义务图数据库中保存的义务图都是已经预设好的，不同的义务图都跟随着相应的标识以便方便的匹配不同服务和访问控制检查时需要用户完成的义务图(即标识是区分不同义务图的代号，和具体服务对应)。前面提到，当义务转译器找到合适的义务图后，会复制一份，然后附上相应的历史完成概率。然后，义务图数据库将这个副本存放到执行义务图数据库中。
[0136] 执行义务图数据库
[0137] 执行义务图数据库包括当前访问用户要完成的强制义务图和可选义务图信息。每个服务都对应了一个特定的强制义务簇实例和可选义务簇实例，所有概率信息都已经附加在可选义务项中。同时，当前正在完成的义务项也被记录在这个数据库中用以监视和提示系统用户正在做的义务是和哪个义务项相关联。
[0138] 当一个用户提出了访问请求，基于UCON的访问控制系统会将该请求解析，并分别发送给授权、义务、条件这三大核心模块进行检查。对于义务部分的检查，需要进行一些准备工作。
[0139].服务或数据的准备。所有用户想要获得的服务或者数据是预先已经存在于云平台之上的，云平台提供商负责为数据或服务提供获取接口。
[0140].访问控制规则的设定。访问控制规则一般是伴随着某个数据或某项服务的，规定了满足什么样条件的用户可以访问数据或服务。对于本发明，主要涉及到义务规则的设定。数据或服务的拥有者需要设定对访问者的检查项目，即义务项，每个义务项都是要求访问者通过完成一个特定的动作，以满足数据或服务拥有者的特定要求。在义务项设定好后，数据或服务拥有者还要决定这些义务项的执行顺序，以及这些义务项具体属于哪个义务图。当所有相关的义务项和义务图都设定好后，我们认为，控制规则(即义务图)就已经完全设定完成了。这里，数据或服务的拥有者不需要设定义务簇。义务簇应该是系统自动生成的，根据某一特定的服务或数据要求，将所有可选义务图归类到可选义务簇中，将所有强制义务图归类到强制义务簇中。所有的义务图最终都预先保存在义务图数据库中，同时存入义务图数据库的，还有每个义务项涉及到主、客体属性标识。
[0141].义务项的数据准备。任何一个义务项的完成都伴随着用户与访问控制系统的交互，因而，需要用户完成的一些义务需要加载额外的资源，比如启动一个支付平台以完成用户支付的义务。
[0142].主、客体属性的准备。这一工作主要由云平台服务商提供，由云平台服务商规定系统中主、客体都有哪些属性。
[0143] 有了这些准备工作，系统就可以允许用户开始向某项服务或数据进行请求了。当用户发出请求时，访问控制系统会首先对用户进行访问控制检查。在义务部分，访问控制的流程是这样的:
[0144] 1.主体发出的访问请求会通过访问控制系统发送到义务转译器。
[0145] 2.义务转译器根据主体请求的具体服务，
[0146] a)向义务图数据库查找匹配所请求的服务的义务图，提取需要完成的义务图；
[0147] b)向历史数据库提取该用户完成义务的历史情况。
[0148] 3.在获得相应的义务图以及用户的历史数据后，
[0149] a)义务转译器将要执行的义务图以及历史数据，存入执行义务图数据库中；
[0150] b)义务转译器提取此次义务中需要检查的属性标识，并向属性监视器提出属性缓存请求。
[0151] 4.在执行义务图数据库获得此次主体访问需要的属性和执行的义务图后，它会通知决策中心数据准备已完成，并根据该义务图将第一个需要完成的义务项通知决策中心。
[0152] 5.在获得数据准备已完成的指令后，决策中心提取第一个义务项，通知执行代理为该义务项准备数据。准备的数据一般为用户需要完成的义务项的相关数据。
[0153] 6.执行代理为该义务项准备数据，并将返回的义务项告知用户执行。
[0154] 7.用户执行结果会发送到执行代理。
[0155] 8.执行代理将结果返回给决策中心。
[0156] 9.决策中心向属性监视器请求调取当前主客体的属性值，这里只调取正在处于监控中的并且和当前义务项相关的主客体属性值。
[0157] 10.在收到决策中心的属性调取请求后，它会向属性数据库获取当前主、客体属性值，并返回给决策中心。
[0158] 11.决策中心根据当前属性值和义务项的完成情况，决定该义务项是否完成，并检查强制义务簇是否已经完成，准备计算当前用户完成可选义务簇的概率。
[0159] a)如果完成的是强制义务图中的义务项，这意味着强制义务簇并未完成，因此跳过计算可选义务簇的完成概率，更新执行义务图中对该主体义务图完成情况的跟踪指针，并提取下面需要执行的强制义务项，并发送给执行代理。如果已经没有多余的强制义务项，向执行义务图数据库记录强制义务簇已完成，然后提取第一条可选义务项，重复(6)步骤；
[0160] b)如果完成的是可选义务图中的义务项，这意味着强制义务簇已完成，因此先更新执行义务图数据库中的当前义务项指针，然后计算当前可选义务簇的完成概率，
[0161] 1.如果是未完成状态，则提取下一条可选义务项，重复(6)步骤；
[0162] i1.如果是预测完成状态，由决策中心向访问控制系统发送"预测完成"指令，这个指令表明虽然用户还未完成所有的义务项，但有极高的概率用户可以完成所有的义务项，并且已经确定用户的身份在当前是安全的。然后提取下一条可选义务项，重复(6)步骤；
[0163] ii1.如果是已完成状态，则决策中心向访问控制系统发送"义务检查完成"指令。
[0164] 同时，还有一个异步的操作:用户在义务执行过程中，只要有属性变化，并且是属性监视器中正在监视的属性，那么属性监视器会通知决策中心会立即进行一次义务检查，因为属性的变化很可能预示着用户已经完成了某项义务项，只是决策中心还没有收到用户完成义务项的通知，此时，决策中心会立即主动检查用户是否完成了义务项，以缩短义务检查的时间。
