CN105051749A - 基于策略的数据保护 - Google Patents

Abstract

本发明提供了用于保护数据存储器中存储的资源的方法和系统，其中，可基于针对每个相应资源所定义的、并按分层的方式所构造的不同策略来保护不同资源。该方法通过定义策略使得策略中针对特定资源所定义的最细粒度的策略能够在执行涉及该资源的请求时动态应用于该资源，来允许以可变粒度保护不同资源。

Description

基于策略的数据保护

技术领域

本公开涉及用于提供基于策略的数据保护的方法和能够执行这种方法的系统。

背景技术

如今我们处于数据爆发的年代。具体地，存在着个人数据的爆发，其中，个人持续产生大量的数据，且服务和设备还能够代表个人进行工作。当聚集、处理和注意到这些数据时，这些数据捕捉到我们的简档、偏好、行为以及更多的东西。这是创建个性化服务以及所产生的货币化机会的重要基础。不幸的是，作为数据的名义上的所有者，用户对如何共享和使用他们的数据并没有完全的控制权，且对于他们正被使用的数据的货币化，他们也没有从中获得太多收益。原因之一是数据的所有权通常是逻辑上的而非物质上的。

一般而言，可以使用适合的策略语言来描述通信网络中交换数据的网络节点如何处理资源，例如，如文件、网页、图像或视频。在表述性状态转移(REST)框架下，通常将资源表示为REST端点URL。这种类型的策略通常通过引用该资源的实例来描述要保护的资源。此外，需要知道请求者(或请求者的一些属性)，以能够选择正确的策略。在策略中，规则通常规定访问某个资源的条件。这样的规则可以例如被规定为“应用A仅可以在工作日的早上9点到下午5点之间读取我的位置数据”。这些类型的策略语言通常使用不同的格式(例如，如可扩展标记语言(XML)来描述具体的策略。此外，这种语言在对应该强制执行什么的表达性方面可以不同。

例如，可扩展访问控制标记语言(XACML)是在使用XML来描述访问资源的规则的信息社会高级开放标准(OASIS)标准内规定的策略语言的一个实例。XACML还使用XML描述访问控制判决请求/响应语言，其允许形成用于询问是否允许给定动作且用于相应地解译结果的查询。此外，XACML提供找到应用于给定请求的策略并将请求针对该策略进行评估的能力。

在XACML使用场景中，可假设个人或应用需要采取涉及资源的动作，该资源可例如从文件系统或网络服务器提供，其中，该资源受到策略执行点(PEP)的保护。PEP将会基于与请求者、所讨论的资源、所请求的动作以及可能可涉及请求的任何其他信息相关联的一个或多个属性来形成请求。PEP然后将会向策略判决点(PDP)发送该请求，PDP将会考虑该请求和应用于该请求的策略，并提出与是否应该授权访问有关的答复。将对请求的答复返回给PEP，PEP可在然后允许或拒绝请求者访问资源。

数据存储器通过多种不同的变型可用，例如，数据库(例如，如关系数据库，非仅结构化查询语言(NoSQL)数据库或图形数据库)、文件系统(例如，如Unix、Windows文件系统)或分布式文件系统(例如，如Hadoop分布式文件系统(HDFS))的形式，或者文档(例如，如逗号分隔值(csv)文件汇集)的形式。数据存储器的实例因此可以是数据库、文件系统或多个文档中的任一种。不同种类的数据库存储具有不同数据单位的数据。分别地，在关系数据库和NoSQL数据库中，可识别的最小数据单位是行，相反，在图形数据库中，最小可识别数据单位代之是节点或边缘，而在文档汇集的文件系统中，最小可识别数据单位可以代之是文件或文件中的行。现有用于保护数据存储器中的数据的解决方案通常是粗粒度的，其中，请求者或者对数据所有者的所有数据具有完全的访问权，或者对数据所有者的任何数据都没有访问权，并且该控制规则是静态预定义的。

发明内容

本文档的目标是通过建议一种方法来解决上述问题中的至少一些，该方法使用户能够灵活地定义策略，搜索应用于所定义的策略的资源以及高效地修改和/或删除所定义的策略。

根据一个方案，提供了一种保护数据存储器中存储的资源的方法，其中，能够基于针对每一个相应资源所定义的、并以分层方式所构建的不同策略来保护不同资源，由此通过以下方式来允许以可变粒度保护所述不同资源：定义策略，使得策略中针对具体资源所定义的最细粒度的策略能够在执行涉及该资源的请求时动态应用于该资源。

更具体地，可通过以下方式定义策略：针对表示至少一个数据项的种类来定义第一策略，使得所述第一策略应用于所述种类以及所述种类的未针对其定义策略的每个子类，其中，针对所述子类中已针对其定义了不同于所述第一策略的策略的每个子类，在执行涉及所述子类的至少一个的请求时，所述策略越权所述第一策略。

可通过以下方式来执行对要应用于种类所表示的至少一个数据项的策略的定义：将策略与唯一的标识或名称相关联，其中，每个唯一的标识或名称识别所述数据项之一或所述种类，由此使得所述策略可识别。

根据一个实施例，可针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类来定义策略，所述策略可以是不同于所述第一策略的策略，所述定义是通过将所述第一策略的内容复制到不同于所述第一策略的每个策略来执行的。

根据另一实施例，代之，可通过以下方式定义策略：针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类来定义策略，所述策略可以是不同于所述第一策略的策略，所述定义是通过向每个子类的相应策略提供对所述第一策略进行引用的引用来执行的。

根据另一实施例，代之，可通过以下方式定义策略：通过将包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类作为要应用所述第一策略的资源来列出，定义策略，所述策略可以是不同于所述第一策略的策略。

根据另一方案，建议了一种用于搜索资源的方法，其中，已根据前述任一实施例针对所述资源定义了策略，所述搜索是通过以下方式执行的：识别从请求者接收到的查询；识别所请求的数据项；通过针对每个识别出的数据项将与具体策略相关联的唯一的标识或名称与所存储的策略相匹配，根据相关策略来确定所述请求者能够访问的数据项；以及根据匹配的策略向所述请求者提供响应。

根据另一方案，建议了一种更新第一策略的方法，其中，已根据上述任一实施例，针对表示至少一个数据项的种类定义了所述第一策略，除了更新针对表示所述数据项的种类所定义的所述第一策略之外，所述方法还包括：更新针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。

根据另一方案，建议了一种用于删除第一策略的方法，其中，已根据上述任一实施例，针对表示至少一个数据项的种类定义了所述第一策略，除了删除针对所述数据项所定义的所述第一策略之外，所述方法还包括：删除针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。

根据另一方案，建议了一种计算机程序，包括指令，所述指令当在至少一个处理器上执行时使所述至少一个处理器执行根据上述任一方法所述的方法。

根据另一方案，提供了一种能够包括数据存储器中存储的资源的系统，包括至少一个处理器和包括指令的至少一个存储器，所述指令在由所述至少一个处理器执行时使所述系统基于针对每一个相应资源所定义的、并以分层方式所构建的策略来保护不同资源，由此通过以下方式来允许以可变粒度保护所述不同资源：定义策略，使得策略中针对具体资源所定义的最细粒度的策略能够在执行涉及该资源的请求时动态应用于该资源。

所建议的系统通常还包括在由所述至少一个处理器执行时使系统执行以下操作的指令：针对种类所表示的资源的数据项定义第一策略，使得所述第一策略应用于所述种类表示的每个数据项以及未针对其定义策略的资源子类所表示的每个数据项，其中，针对所述子类中已针对其定义了不同于所述第一策略的策略的每个子类所表示的数据项，在执行涉及所述数据项中的至少一个数据项的请求时，这样的策略越权所述第一策略。

所建议的系统通常还包括在由所述至少一个处理器执行时使系统执行以下操作的指令：通过将策略与唯一的标识或名称相关联，定义要应用于种类的策略，其中，每一个唯一的标识或名称识别所述数据项之一或所述种类，由此使得所述系统可识别所述策略。

根据一个实施例，上述系统还包括在由所述至少一个处理器执行时使系统执行以下操作的指令：针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个种类，定义策略，所述定义是通过将所述第一策略的内容复制到不同于所述第一策略的每个策略来执行的。

根据又一实施例，所述系统还包括在由所述至少一个处理器执行时使系统执行以下操作的指令：针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类，定义策略，所述策略可以是不同于所述第一策略的策略，所述定义是通过向每个子类的相应策略提供对所述第一策略进行引用的引用来执行的。

根据又一实施例，所述系统还包括在由所述至少一个处理器执行时使系统执行以下操作的指令：通过将包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类作为要应用所述第一策略的子类来列出，定义策略，所述策略可以是不同于所述第一策略的策略。

根据另一方案，所述系统还包括在由所述至少一个处理器执行时使系统通过以下方式搜索已针对其定义了策略的资源的指令：识别从请求者接收到的查询；识别所请求的数据项；通过针对每个识别出的数据项将与具体策略相关联的唯一的标识或名称与所存储的策略相匹配，根据相关策略来确定所述请求者能够访问的数据项；以及根据匹配的策略向所述请求者提供响应。

所建议的系统通常还包括当由所述至少一个处理器执行时使系统执行以下操作的其他指令：更新第一策略并更新针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略，且以类似的方式，系统还包括当由所述至少一个处理器执行时使系统执行以下操作的其他指令：删除针对种类所表示至少一个数据项定义的第一策略并删除针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。

附图说明

现在将关于附图更详细地描述实施例，在附图中：

图1是包括PDV和PPM的系统的示意性示意。

图2是图1的PPM的更详细的示意。

图3是包括多个PDV和PPM的系统的示意。

图4是图2的PPM的更详细的示意。

图5是图2的PPM的另一更详细的示意。

图6是根据一个实施例用于定义策略的方法的示意。

图7是用于对已针对资源定义的策略进行识别的资源标签的示意。

图8是根据第一实施例用于定义策略的方法的示意。

图9是根据第二实施例用于定义策略的方法的示意。

图10是根据第三实施例用于定义策略的方法的示意。

图11a-c是根据一个实施例用于处理请求或查询的方法的示意。

图12是根据一个实施例被布置为PDV的数据储存器的示意。

图13是根据一个实施例的PPM的示意。

图14是根据图6中示出的实施例用于定义策略的方法的示意。

图15a是根据图8中示出的实施例用于定义策略的方法的示意。

图15b是根据图9中示出的实施例用于定义策略的方法的示意。

图15c是根据图10中示出的实施例用于定义策略的方法的示意。

图16是根据一个实施例用于处理搜索查询的方法的示意。

图17是根据一个实施例用于处理更新请求的方法的示意。

图18是根据一个实施例用于处理删除请求的方法的示意。

图19是根据一个实施例包括至少一个数据存储器和至少一个PPM的系统的示意。

图20是根据一个实施例的图19的系统的示意。

具体实施方式

近来存在着向个人数据生态系统发展的强劲动力。其提倡将用户的数据还回给他们并使他们在控制要共享什么数据和如何共享数据的圈中处于中心。所能预想到的是全分布式架构，其中，数据所有者(之后称为所有者，例如，如个人、组织、公司或政府)各自具有他/她/它自己单独的数据存储器，该单独的数据存储器安全地保存可以与数据请求者共享的所有数据，但在共享时需要精密的保护。可在个人数据生态系统中开发应用(之后也称为服务或APP)，该应用在数据所有者的授权下从相应数据存储器读取数据/向相应数据存储器写入数据。通常使跨应用共享(应用读取另一应用写入的数据)更加容易，增强了每个应用可被个性化的程度。

数据存储器的概念造成大量的研究挑战。榜单前端是：(1)数据表示--如何通过自然、有意义并易于注意的方式表示数据存储器中的数据，(2)数据访问API--如何使应用与数据存储器内部的数据有丰富且灵活的交互，(3)数据访问控制--如何使得数据所有者对应用如何访问他们的数据存储器中的数据进行动态、粒度可变且上下文感知的控制。根据一个实施例，通过使用基于图形的模型来解决数据表示，且应用数据访问API，在此，数据访问API在调节用于遍历和操纵时被呈现为类似SQL的查询语言。然而，要理解的是，所创建的访问控制框架独立于所使用的数据表示和API框架，并因此该框架也能与不同于本文中提及的数据表示和API的其他形式的数据表示和API一起工作。

访问控制是数据存储器的关键特征。用户将数据保存在数据存储器中的最大动机是隐私。数据所有者想要通过灵活的方式控制谁在什么样的上下文下访问数据的哪部分。此外，数据所有者还可能想要控制在与第三方共享数据之后会有什么发生在数据上。这种控制可通过手动方式进行，使得每次一些应用请求访问某些数据时，都要求数据所有者进行确认。然而，这非常麻烦。因此想要一种代表数据所有者生成访问控制判决的自动化解决方案。其还应该支持上下文信息，例如，如做出访问控制判决的位置和/或时间。可以使用动态定义的隐私策略(此后称为策略)来启用这种自动化处理，在请求数据访问时，在其当前上下文方面对该策略进行评估。拥有各个数据存储器被用于保存不同数据域的多个数据存储器的数据所有者正常而言倾向于在单个管理点处管理隐私策略，且在该单个管理点处做出访问控制判决。

因此，本文中描述的是旨在实现至少以下目标的解决方案：(1)动态性：只要数据所有者重新配置策略，策略就应该马上生效；(2)粒度：数据所有者应该能够以不同的粒度等级来保护数据，或换言之，应该能够缩小到非常低的等级并保护非常具体的数据片，即，单个数据项，且还应该能够放大到非常高的等级并保护包括多个数据项的大的数据种类，(3)上下文感知：应该在可能考虑当前上下文(例如，要考虑的数据、数据所有者和/或数据请求者)的情况下做出访问控制判决；(4)易于管理：数据所有者在理解和管理隐式方面不应有困难。上述目标应该独立于所使用的访问语言和数据存储器来实现。

建议以下的访问控制架构：给予数据所有者动态创建和管理策略以及支持基于当前上下文的访问控制判决的中心位置。此外，引入使得可通过不同粒度等级来保护数据的机制。也可以将这种能力(以上称为缩放)称为模仿将“滑动条”用于个人数据保护，其中，数据所有者能够根据需要，沿着从一个具体种类或多个种类的所有数据单元到各个最小的数据单元以及其之间的每个粒度，来对保护进行微调。

在缺少细粒度和动态性的情况下，现有基于策略的解决方案(例如上述解决方案)不处理对可能已被动态存放在数据存储器中的具体小片数据的保护。因此，本文档还涉及数据存储器架构的安全性和隐私框架，由此使得数据所有者对于以不同粒度访问其数据具有动态的上下文感知控制。

本文档解决实现对安全的数据存储器(本文中称为数据存储器)中数据的可变粒度保护的问题，该保护的范围可从细粒度保护到粗粒度保护。保护可以从任何数据类别等级处的粗粒度(例如，表格或类型)改变为最小识别数据单元等级处的细粒度(例如，如行、节点或边缘)，或其之间的某个位置(例如，子类别或类型等级)。

建议了分层的基于策略的访问控制模型，该模型可应对通过数据存储器中的查询接口可访问的数据的请求而应用。数据所有者可以例如针对种类分层中定义的种类定义较高等级处的策略，该种类分层描述了对数据进行表示的模式(例如，本体论(ontology))，其中，每个种类包括多个数据项。还可以定义较低等级处的策略，例如可应用于具体数据单元的策略。也可以合并策略，使得可利用使用种类分层的策略来规定某些聚合数据，而在聚合之外的一些较小的数据单元由单独的策略来覆盖。后一组合情况可以例如是：针对对象组(在此表示为“音乐”对象)定义第一策略，而在同时针对具体的数据单元(例如，作为“音乐”对象之一的歌曲“dream”)定义另一第二策略。在该情况下，仅将第二策略应用于“歌曲”数据单元，而“音乐”对象(即，种类“音乐”)的剩余数据单元应用第一策略。

图1中示出了系统100的整体安全和隐私框架模型，系统100包括数据存储器(在此称为个人数据储存库(PDV)110)，例如上述的数据存储器。

如图中所示，请求者120(其可以是服务、应用或代表个人用户的软件代理中的任一者)可如步骤1：1所示地请求访问所有者130(其也可称为PDV所有者)的PDV中的数据，该所有者130负责确定请求者120如何以及在什么条件下具有对PDV110中的所有者数据的访问权。如步骤1：2所示，个人隐私管理者(PPM)140通过利用策略执行点(PEP)150来保护对PDV的数据的访问，其中，根据所有者130定义的要在评估请求时在PDV110处强制执行的策略160来做出访问判决，导致如步骤1：3所示，授权请求者120访问所请求的数据或拒绝请求者120访问所请求的数据。可通过基于可扩展访问控制标记语言(XACML)的PrimeLife隐私语言(PPL)来表达这种策略，然而可代之以应用其他语言，例如，如隐私偏好计划(P3P)的平台或者义务规范语言(ObligationSpecificationLanguage，OSL)。策略160阐述允许哪些请求者在什么上下文中访问什么资源。在当前上下文中，资源可以例如是列族或可识别的小数据单元，其中，本体论种类的资源代表高等级保护，而小数据单元代表低等级保护。要理解的是，虽然图仅包括一个PDV，备选地，可将多个PDV连接到PPM。通过管理PEP150(如步骤1：4所示)，所有者130如步骤1：5所示地委托系统100根据可应用于相应数据的策略160来确定是接受还是拒绝访问请求者120所请求的数据内容。在此，执行拒绝或接受的是PEP150。在此，执行拒绝或接受的是PEP150。所有者130还被允许动态修改策略160。如步骤1：6所示。

除了从请求者提供的数据之外，PPM还可以在做出判决中考虑附加上下文信息(例如，如位置和/或时间)。还可以支持信任框架的输入，信任框架给出与服务的可信性有关的推荐，例如2013年1月访问的信任网(WOT)，http://www.mywot.com/。

图2中示出了用于提供上述目标(关注于PPM140和数据存储器或PDV110)的架构200，其中，想要访问来自数据存储器的数据的请求者120(在此由应用来表示)可以经由数据存储器110访问PPM140。

作为前提条件，任何请求者最初都必须被授权并定位相关PPM且注册到该PPM，以能够经由API(可称为保护API部分(未示出)，其是经由数据存储器可访问的)请求资源，同时可经由另一API(可称为授权API(未示出))请求对已注册的资源的访问。然而，可应用其他API来使得可以在一个或多个数据存储器与PPM之间通信。在创建针对相应资源的策略时，可在数据存储器或者授权管理器(AM)210的存储器(未示出)处动态注册资源。

在准许注册之后，请求者120可以向数据存储器110提供请求(可称为数据请求或查询)，数据存储器110将这样的请求重定向到PEP150，PEP150在此驻留在AM210中。备选地，PEP150可以形成隐私策略服务器(PPS)220的一部分。PPS220(备选地可称为策略判决引擎)包括策略判决点(PDP)230，PDP230具有对所有者之前定义的策略的访问权，该之前定义的策略存储在数据存储器或者PPS220的存储器(未示出)中，或者可由PPS220访问。PEP150向PDP转发请求，PDP将请求针对策略来进行评估，并做出判决(也可称为访问控制判决)。取决于评估的输出，即请求与可应用于请求者120的策略有多匹配，PDP230可通过准许或拒绝对一个或多个资源的访问来进行响应。更具体地，在当已经使用了某些策略来评估请求之后已显式地许可了请求的情况下，PDP230可使用“许可”来进行响应，在已经使用策略来评估请求且已显式地拒绝了请求的情况下，PDP230可使用“拒绝”来进行响应，或者在未发现相关策略的情况下，PDP230可使用“不确定”或“不可应用”来进行响应。在后两种情况下，同样拒绝请求。在判决处理中，PDP230还可以考虑对例如用户的位置和/或服务的某个可信值进行定义的一个或多个属性。

如果允许，请求者120将会接收令牌，通常称为包括可应用权利许可的请求许可令牌(RPT)，并因此请求者120可使用这种令牌来访问来自数据存储器110的资源，而在拒绝请求的情况下，令牌将不会包括所需的权利许可。在后一情况下，请求者120将不能够进行访问，但可尝试更新令牌以得到许可的访问权。一旦拥有RPT，请求者可以向数据存储器110发送RPT，数据存储器110再次地联系PEP150，以确定应该向请求者授予什么访问权。一旦PEP150和PDP230已基于RRT(以及可能还基于可应用于请求者120的任何附加属性)进行了交互，数据存储器110接收结果并过滤出请求者120应该具有访问权的资源，且从数据存储器110向请求者120提供结果，请求者120现在可以访问相应资源。虽然图2中没有显式地示出，PPS220还包括编辑功能，允许用户编辑其中存储的策略或添加新的策略。下面将参考图6-11c更详细地描述上述过程的进一步细节。

当基于用户管理访问(UMA)模型并结合由Primelife隐私语言(PPL)提供支持的PPS时，图3-5更详细地示出了以上图1中描述的架构，其中，在http://kantarainitiative.org/confluence/download/attachments/37751312/UMA_IEEE_PosterV08.pdf中描述了用户管理访问(UMA)模型，如S.Trabelsi，G.Neven，andS.Ragett，“ReportonDesignandImplementation，”PrimeLifeProject，Tech.Rep.D5.3.4，May2011所述，PPL基于XACML(可扩展访问控制标记语言)。UMA是基于网络的访问管理协议，使得网络用户可以协调网络资源的保护与共享。图3的架构包括PEP所驻留在的UMA授权管理器(UMAAM)和PPS，在PPS中存储策略，评估访问请求并响应于访问请求做出访问控制判决。在当前示例中，UMAAM因此被丰富得变为XACML架构中的PEP。在该UMA相关示例中，我们再次涉及数据存储器，在此以个人数据储存库来表示数据存储器。

如图3中示出的，PDV110a、110b中的每一个都包含相应的UMA主机部分310a、310b，UMA主机部分310a、310b根据从PEP向请求者提供的访问控制判决中表达的权利许可，或者让数据请求通过，或者阻止数据请求。在本实施例中，以令牌的形式提供访问控制判决，在此称为UMA令牌或RPT。

此外，如图3中示出的，每个PDV110a、110b还可包含相应的UMA请求者320a、320b组件，由此允许PDV110a通过分布式查询从其他PDV110b请求数据。

UMA模型还包括映射到PPL语义中的动作的数据访问范围。当前，支持“读取”和“写入”作为可能的动作。在“读取”动作中，假设共享数据，而“写入”动作还包括删除数据单元。

下面将进一步描述UMA架构中的各个组件。

A.个人隐私管理器

图4中详细示出的PPM包含UMAAM310和个人策略服务器(PPS)320。一个或多个PDV注册在PPM140的AM310的数据存储器或存储器(未示出)中，各个PDV可作为数据主机工作，贮存需要根据策略保护的资源。UMAAM310连接到PEP150(在此提供为XCACMLPEP)，PEP150在此被示出为形成UMAAM310的一部分，然而备选地，其可被布置在UMAAM310外部，而不是形成PPS320的一部分。

1)MA授权管理器

图5中更详细地示出的UMA授权管理器(AM)310基于规范T.Hardjono，User-ManagedAccess(UMA)CoreProtocol，draft-hardjono-oauth-umacore-04，InternetDraft，March29，2012，为了能够也应用上述的XACML策略架构进行了一些小的修改。UMAAM提供许可请求服务，许可请求服务连接到PEP，并允许向请求者给予RPT(如果PEP从PPS接收到“许可”访问控制判决)并允许RPT许可更新或不更新。

UMAAM还包括保护API部分，保护API部分是连接到PPM的一个或多个PDV可访问的，且被用于PPM处一个或多个PDV的资源注册，而授权API被用于在请求者进行请求时控制对所注册资源的访问。在创建针对相应资源的策略时，可利用UMAAM来动态注册资源。

RPT可以包含或不包含用于访问所请求资源的许可。在后一情况下，将RPT视为是空RPT。在授权API中，在更新过程的情况下，RPT请求控制器被配置为在允许的情况下分发RPT，且许可请求控制器被配置为在具有必要许可的情况下分发已更新RPT，稍后在本文档中将更详细地对此进行说明。

此外，为了能够接收RPT，请求者将其自身注册到AM。在许可注册控制器处，PDV向AM指示针对具体访问需要哪些许可。

RPT状态控制器与连接到PPM的一个或多个PDV交互，以通知什么许可与向请求者提供并在然后由请求者呈现给相应PDV的具体RPT相关联。

2)隐私策略服务器

如在E.Rissanen，“eXtensibleAccessControlMarkupLanguage(XACML)Version3.0，”August2010中所阐述的，图4中上部示出的隐私策略服务器(PPS)320也遵循XACML策略架构，且除了策略执行点(PEP)150(在此驻留在UMAAM310中)之外，隐私策略服务器(PPS)320包括策略判决点(PDP)410和策略信息点(PIP)420。在该架构中，基于策略来做出对接入请求的实际判决。PDP410从PEP150接收授权请求并利用“许可”、“拒绝”、“不确定”或“不可应用”来进行答复。在判决处理中，PDP410可能需要一个或多个属性：用户的位置和/或服务的某个可信值。这些属性由PIP420提供。PIP420自身向一个或多个属性提供器430提供接口，使得多个属性提供器也可在稍后的时间点连接到PIP420。此外，PPS320向所有者提供编辑(即，添加、修改或删除)策略的手段。这可以是图4中示出的图形策略编辑器440，或是允许用户编辑隐私策略的文本编辑器。

如已经提到的，上述架构的目的是使得不同等级处基于策略的数据保护成为可能，这意味着数据所有者能够“缩小”到非常低的等级并保护由具体的小片数据定义的资源，且在另一方面，能够“放大”到非常高的等级并保护由大的数据种类定义的资源。

构造PDV中存储的数据。可以将这种结构始终认为是分层，而与所使用的持续技术无关。在一种情况下，可以将分层布置为表格-列元素分层，而在另一情况下，如果通过本体论来管理数据模式，可将分层布置为本体论中定义的种类或子类。在这种分层策略结构中，较低分层等级处的策略覆盖较少量的数据，但具有更细的粒度。当正在请求某些数据时，搜索策略分层，以找到属于所涉及的数据的最细粒度的策略。将针对相关隐私策略来评估数据请求，以做出访问控制判决。在本文档中，稍后将描述可如何执行这种搜索的进一步细节。

图6示出了分层策略结构的示例，其中，我们假设遵循简单的本体论来表示资源，资源包括在数据存储器中以不同的种类布置的一个或多个数据项或数据片。本体论的种类分层是树600，根在由“事物”表示的较高种类610处。在“事物”下面存在两个子类620a、620b，分别表示为“音乐”和“视频”。子类“音乐”620a被进一步分类为三个子类630a、630b、630c，分别表示为“流行”、“爵士”和“摇滚”。现在假设存在两片数据：属于“流行”种类630a的数据片A640a以及作为“摇滚”种类630c的数据片B640c。还假设已经定义了两个策略：针对于“音乐”种类620b的策略1650以及针对数据片A640a的策略2660。如果存在针对数据片A640a的请求，策略2660将会应用被越权策略1650，因为策略2660对于数据片A640a而言更具体。相反，如果数据请求针对于数据片B640c，策略1650将应用，因为该数据片不具有针对其定义的策略，且因此，针对较高种类定义的第一策略是策略1650，其因此是对于数据片B640c而言最具体的策略。

该模型给予数据所有者用于根据他们的需要来微调数据保护的粒度的“滑动条”。在一个极端情况下，较不关注隐私的数据所有者定义覆盖数据储存库中所有数据的一个单独的策略。在另一极端情况下，高度保守的数据所有者针对数据储存库中的每个单独的数据片都具有策略。在典型的场景中，多数数据所有者将会落在其间的某个位置：具有针对大的数据种类的策略，也针对具体的数据片定义一些例外情况。

在上述的UMA示例中，作为其实现是可能的工业标准，因为其XACML隐私特征扩展以及XACML自身，PPL是适合的。PPL允许表达访问和使用控制策略。因此，其允许数据存储器/PDV所有者规定接收实体应如何对待来自数据存储器的数据。除了生成新的策略之外，也可以通过利用一些约束扩展现有的XACML隐私简档来对此进行实现。

在所描述的上下文中，必须利用以下方式进行策略管理：将策略映射到它们所保护的数据或资源，在分层结构中维护策略，并处理如搜索、创建、更新和删除策略的操作。为了解决策略和数据之间的映射，使用标签(在此称为PPL的“目标”部分的资源标签)。策略在其PPL表示中使用资源标签来描述其保护的资源。在策略属于一类数据的情况下，将相应种类的唯一名称或标识(ID)放在资源标签内。在针对具体数据单元定义细粒度的策略的情况下，代之以将数据单元的唯一ID或名称放在资源标签中，如图7所示。关于维持策略分层和处理操作，有几个方案是可能的。其中的每一个在简单性、存储效率和搜索效率上都伴随着好的方面和不好的方面。在实现中选择追寻哪个方案是折衷的平衡。

下面示出针对被称为“音乐”的资源的策略的示例：

下面将描述针对如何存储策略的三个不同的方案，其中，不同的资源涉及或属于种类或子类。然而，子类并非是排他的。更具体地，单个数据项不仅属于相应子类，还属于该子类所属于的种类。

策略分层实际持续的方式完全确定了策略管理模型的存储效率和搜索效率。其还部分确定了操作(如更新和删除)的效率。下面三个方案在如何维持相关策略之间的联系方面不同。

策略复制：在图8中示出的第一方案中，针对数据分层700中的种类或资源“音乐”创建策略(策略1850)，其中，还针对其尚未具有任何现有策略的所有子类同时创建附加策略(例如，分别是策略1’860’、策略1”860”和策略1”’860”’)，在本示例中，这隐含了种类“音乐”620a的所有三个子类。后面的策略复制前面策略的内容，除了它们保护的资源之外。考虑以上参考图6示出的之前的示例，图8示出了当针对种类“音乐”620a通过复制来创建策略且其子类都不具有任何现有策略时所发生的事。通过将每个相应资源的资源ID或名称映射到所存储的策略并通过应用相关策略，在仅仅一个步骤中执行对这种策略的搜索。如果在这种搜索期间不存在匹配，这意味着不存在针对该资源的策略，且因为不存在策略，应该缺省拒绝所有这种请求。该方案在本文中建议的方案中是最简单且搜索效率最高的。很明显，与该方案的简单和搜索效率相伴的代价是其低存储效率。因此，该方案更适合于较不复杂的数据分层。

还参考图15a示出了策略复制方法(例如上述的策略复制方法)，其中，在第一步骤14：1中，针对某个种类定义策略(在此称为第一策略)。如果其策略之前未被定义的相应种类存在一个或多个子类，也将针对这些子类定义第一策略，如步骤14：3和14：4a所示。在该情况下，将第一策略的内容复制到可应用于上述种类的相关子类的每个策略，如步骤14：4a中所示。在步骤14：2和之后的步骤14：3和14：4a中，针对种类的子类重复相同考虑。在针对上述子类中的一个子类定义不同于第一策略的策略的情况下，不针对该子类执行第一策略的复制。

策略链：在图9中示出的第二方案中，针对数据分层900中的某个种类(“音乐”620a)创建策略(策略1950)，同时还针对其不存在任何现有策略的子类“流行”630a、“爵士”630b和“摇滚”630c分别创建附加的相应策略960、970、980。因为除了它们所保护的资源之外，后面的策略都包含了与前面策略相同的内容，这些策略中的每一个都将保持与前面策略的相应引用，而不是与前面的方案中所进行的一样复制策略的内容。这可通过使用参数(在此称为“PolicyIdReference标签”)来进行。使用这种引用节省了空间，并因此存储效率相当高。此外，其搜索效率也相当高。当针对保护资源的最具体的策略执行搜索时，可通过将资源ID或名称与隐私策略进行匹配来快速定位策略，且在一些成功的情况下，可直接地或通过遵循相应的引用来获取实际的内容。

还参考图15b示出了策略链方法(例如上述的策略链方法)，其中，在第一步骤14：1中，针对某个种类定义策略(称为第一策略)。如果其策略之前未被定义的相应种类存在一个或多个子类，也将针对这些子类定义第一策略，如步骤14：3和14：4b所示。然而在本情况下，这是通过向上述种类的相关子类提供对第一策略的引用来执行的，如步骤14：4b中所示的。在步骤14：2和之后的步骤14：3和14：4b中，然后针对上述种类的每个子类重复相同考虑。在针对子类中的一个子类定义不同于第一策略的策略的情况下，不针对该子类执行所述策略链。

策略聚合：在图10中示出的第三方案中，针对数据分层中的种类(在此是种类“音乐”920a)创建策略1000，同时针对其任何的子类“流行”630a、“爵士”630b和“摇滚”630c不创建附加隐私策略。相反，在针对种类“音乐”创建的策略中，种类“音乐”的所有未曾具有针对其定义的现有策略的子类将被作为资源列出。这是所建议的方案中最具存储效率的方案。此外，仅需要一个步骤(为了找到适当的隐私策略最多仅必须解析一个引用)，与链方案相比还更有效率地进行了搜索。然而，取决于所使用的策略操作处理方案，所建议的处理可使得更新和删除简单或更复杂。

还参考图15c示出了策略聚合方法(例如上述的策略聚合方法)，其中，在第一步骤14：1中，针对某个种类定义策略(称为第一策略)。如果其策略之前未被定义的相应种类存在一个或多个子类，也将针对这些数据项定义第一策略，如步骤14：3和14：4c所示。然而，在本情况下，这是通过将相应子类作为第一策略是可应用策略的子类进行列出来执行的，如步骤14：4c中所示。在步骤14：2和之后的步骤14：3和14：4c中，针对上述种类的每个子类重复相同考虑。在针对上述子类中的一个子类定义不同于第一策略的策略的情况下，不针对该子类执行所述策略聚合。

策略操作处理关注于在创建、更新或删除相关策略时相关策略发生什么情况：对于具有带有相同内容的策略的子类，相应操作是否应该级联进行。如已经提到的，创建始终是级联操作。亦即，当创建针对种类的策略时，还将针对其不具有任何现有策略的子类创建策略。因为分层策略结构的特性，这对于某些操作是有意义的。对于更新和删除操作，存在级联和非级联选项。对要选择的选项的选择不仅是技术问题，也是对于最终用户而言更直观且可理解的用户体验设计考虑。

利用级联操作，当针对某个种类的策略更新“流行”630a、“爵士”630b和“摇滚”630c时，相应地更新针对其子类定义的具有相同内容的策略。在删除种类的策略时，针对子类定义的具有相同内容的策略也被删除。该模型与策略聚合持续方案在一起特别好用，因为在该情况下，仅需要改变或移除一个物理策略。

利用非级联操作，在更新或删除种类的策略时，其他策略不受影响。该模型与策略复制持续方案在一起特别好用，因为在该情况下，仅需要改变或移除一个物理策略。

下面将要更详细地描述在两个不同的授权流中可如何通过分层的方式处理数据请求。低层处是常规授权流，可通过其来处理针对具体资源的数据请求。在实际请求可能处于查询形式(根据其不能够知道正在请求什么资源)的高层处，流处理这种查询的不确定性和复杂性。

假设在请求中以可识别数据单元或数据种类的形式规定数据存储器处正请求的资源，授权请求者访问所请求资源的工作流遵循上述的UMA工作流。

UMA基于OAuth2.0，并通过规定授权服务器(即AM)与资源服务器(即，所使用的数据存储器)之间的通信来扩展OAuth2.0。在写入时，将UMA规范重写为OAuth2.0简档。

可将工作流划分为三个阶段。图11a中示出的第一阶段是从请求者的视角来看的。如步骤11：1中所示，请求者定位或识别保护某个数据存储器的PPM。这是通过数据存储器将请求重定向至PPM来实现的，或是通过向请求者发送阐明PPM的位置的配置信息来实现的。

一旦已经识别了相关PPM，请求者尝试访问该PPM，如步骤11：2和11：3中示出的。如果准许访问(如步骤11：4中所示)，授予请求者访问令牌，且可以进行第二阶段(阶段II)，如步骤11：5所示。如果访问未被准许，即，请求者不具有对相关PPM的访问权，终止处理，如步骤11：6中所示。

参考图11b描述阶段II。请求者(如今被授权访问PPM)通过发出和接收查询来开始，如步骤11：7中所示。这种查询可例如表达为：http://localhost：8080/pdv/query？q＝SELECTtitleFROMMusic。在下一步骤11：8中，数据存储器向PPM发出针对RPT的请求，该请求可被例如表达为：http://localhost：8080/ppm/requester/rpt。

为了确定是否应该授予RPT，在PPM处考虑策略，如步骤11：9中所示，且如果某些策略指示不授予，则将不会授予RPT，且处理结束，如步骤11：10所示。相反，如果授权RPT，则RPT可以是“空”RPT，即不与任何许可相关联的RPT。请求者在步骤11：11中接收这种空RPT。如果授予许可，在步骤11：12中，相反将由PPM发出指示这种许可的RPT。请求者在步骤11：13中接收这种RPT。从PPM向请求者提供该RPT。

如图11c的初始步骤11：14中示出的，通过数据存储器从再次向数据存储器发出和之前一样的查询(即，在本情况下是“http://localhost：8080/pdv/query？q＝SELECTtitlefromMusic”)的请求者接收请求来发起阶段III，阶段III很大程度上示出了数据存储器中执行的处理。然而此次将RPT插入到请求的HTTP授权首部中。如步骤11：15中所示，数据存储器处理该查询，包括生成未过滤的结果，即从请求识别的所有资源。针对未过滤结果中的每个资源，在数据存储器处检查RPT中是否包含正确的许可，如步骤11：16中所示。如果包含正确的许可，如步骤11：17中所示，数据存储器发起授权请求，授权请求被发送给PPM并通过针对策略检查该请求来进行相应处理，如步骤11：18中所示。虽然在图中该处理仅执行一次，然而要理解的是，通常针对步骤11：16中识别出的每个资源重复步骤11：16-11：18所描述的处理，即，每次针对资源的RPT中包含正确的许可，都触发单独的授权请求。该处理的结果(即，步骤11：17中触发的请求)作为单独的授权请求或组合请求(仍然触发PPM处利用策略的单独检查)发送给PPM。在一个或多个响应(也可称为过滤列表)中从PPM向数据存储器提供处理结果。在下一步骤11：19中，数据存储器基于过滤列表从未过滤结果中过滤出拒绝资源，且因此如最后的步骤11：20中所示的，数据存储器装配对访问请求的响应，允许仅访问过滤之后授予的资源，并如步骤11：21中所示地向请求者提供该响应，请求者现在可以相应地访问所允许的资源。

如果数据存储器确定请求者不具有正确的许可，将请求者再次重定向到PPM，以利用所需的许可来升级RPT。步骤11：22对此进行了示出，如“A”所示出的，再次重定向到阶段II，其中，重复从11：11向上的步骤。同样地，在空RPT的情况下，如“B”所示出的，发起升级处理。在RPT升级处理的情况下，PPM因而再次定位可应用的策略，且如果找到，针对该策略评估请求。作为结果，授予或者拒绝RPT升级(如果没有找到可应用的处理，同样拒绝RTP升级)。在前一情况下，PPM在其记录保持器中更新RPT与所添加的许可的关联。然后，请求者向数据存储器(其再次针对PPM进行检查)呈现所升级的RPT，并进而可获得对资源的访问。例如由于从较早的尝试开始的时间改变，升级结果与之前的尝试可不同。

在请求中没有规定要访问的资源的情况下，基本工作流单独不起作用。例如，如果请求是SQL查询或类SQL查询的形式(例如“从音乐选择标题”)，请求显式地规定了仅一个资源“音乐”，然而查询结果可能包括更细粒度的其他资源(例如，具有其自已的隐私的具体音乐标题)。因此，引入高层工作流来处理查询所带来的复杂性，且同时将UMA逻辑与查询处理分离。为了易于理解，下面我们使用SQL语法来描述高层工作流。在“选择”查询的情况下，应用授权后流程。这意味着首先处理查询以得到未过滤的结果，使得可识别实际请求的所有资源。接着，然后通过低层流程来确定这些资源中的哪些是请求者可访问的。从而过滤查询结果，以仅返回许可请求者访问的那些条目。该处理的确切步骤如下所示。

1)数据请求者发出被发送给数据存储器的“选择”查询。例如，这种查询可被表达为：SELECTtitleFROMMusic

2)数据存储器通过向选择添加三个特性来修改“选择”查询，即：id(每个数据单元的ID)、类型(每个数据单元最具体的种类)以及策略(对每个相应数据单元是否具有其自已的策略进行指示的标记)。在本示例中，可以将查询表达为：SELECT_id，_type._policy，titleFROMMusic。

3)数据存储器处理接收到的查询，产生包含一个或多个数据单元的未过滤结果。本示例产生：((id1，′Music’，false，’SilentNight')，(id2，'Music’，true，'AmazingGraze’)，(id3，'Music’，false，'BadRomance’))

4)通过数据存储器识别所请求的资源(即，数据单元最具体的种类，以及具有其自已的策略的数据单元)，处理继续。

5)数据存储器设计(requesterID，resourceID，action)三元组形式的授权请求，并将其发送给PPM。本示例产生：(‘Requester’，’Music’，’Read')，(‘Requester’，id2，'Read')

6)PPM通过定位与相应(requesterID，resourceID，action)三元组匹配的策略并基于策略评估请求来处理该请求，以响应各个授权请求。本示例产生：“许可”(‘Requester’，’Music’，’Read')，“拒绝”(‘Requester’，id2，'Read')。然后以过滤列表的形式向数据存储器提供该结果。

7)基于从PPM提供的结果，数据存储器在没有接收到“许可”判决的结果中过滤出条目。本示例产生：((id1，’Music’，false，’Silennight')，(id3，'Music’，false，'BadRomance’))

8)数据存储器向请求者返回根据过滤的结果，该结果现在指示允许请求者访问的资源。本示例产生：((‘SilentNight')，(‘Badromance’))

在“插入”查询的情况下，规定具体数据单元，并因此识别要插入的资源。预授权流程使得这种流程极大简化，且其示例可以如下

1)数据请求者发出被发送给数据存储器的“插入”查询。示例：INSERTINTOMusic(title)VALUES(‘DayandNight')

2)数据存储器设计(requesterID，resourceID，action)三元组形式的授权请求，并将其发送给PPM(resourceID是要插入的数据单元的类型)。本示例产生：(‘Requester’，’Music’，’Write’)

3)PPM通过定位对应的策略并针对该策略评估请求来响应于授权请求，并做出访问判决。本示例产生：对于(‘Requester’，’Music’，’Write’)的“许可”，其被作为响应提供给数据存储器。

4)如果判决是本示例中的“许可”，数据存储器通过根据相关策略插入所讨论的资源来处理查询。

还可参考图16来描述上述处理，图16是用于搜索从用户提供的具体查询的方法的简化示意，其中，在步骤16：1中，首先识别查询。在下一步骤16：2中，发起对相关数据项的识别，即对应于查询并可由用户访问的数据项。更具体地，如步骤16：3中示出的，考虑已根据本文档中之前所述的不同方法中的任何方法定义的策略。如已经提到的，可应用于种类或子类的数据项的任何细粒度的策略将会越权现有的粗粒度策略，如备选步骤16：4a和15：4b所示。如步骤16：5所示，针对种类或相关联子类的所识别出的所有相关数据项重复所述处理。一旦已在相关分层中的每个等级处应用了相应策略，响应于查询，包括根据相应策略的每个数据项的响应是用户可访问的，如步骤16：7所示。

如下将要描述的，“更新”和“删除”查询遵循类似模式。

图17中可以看出，步骤17：1-17：3分别对应于步骤16：1-16：3，而步骤17：5和17：6分别对应于步骤16：5和16：6。在步骤17：3中确定针对数据项的细粒度的策略的情况中，不执行对可应用于该数据项的策略的更新。然而，如果仅针对相应数据项定义了粗粒度的策略，还针对该数据项更新粗粒度的策略。

在图18中示出了用于删除策略的对应方法，其中，步骤18_：1-18_：3分别对应于步骤16：1-16：3，而步骤18：5和18：6分别对应于步骤16：5和16：6。在步骤18：3中确定针对数据项的细粒度的策略的情况中，不执行对可应用于该数据项的策略的删除。然而，如果仅针对相应数据项定义了粗粒度的策略，还针对该数据项更新粗粒度的策略。

建议可如简化图12中所示地配置的数据存储器，其中，数据存储器1200(备选地，可称为PDV或数据储存库)可包括本文档中所述的处理器1210和用于存储资源的第一存储器1220，以及用于允许与交互实体(例如，请求者或PPM管理的用户设备)的通信的通信接口1250。数据存储器1200还包括第二存储器1230，第二存储器1230包括在由处理器1210执行时使处理器1210执行方法或处理(例如，本文档中上述方法和示例中的任何方法和处理)的指令，例如本文中所述的向第一数据存储器1220添加可访问数据(本文中称为资源)，编辑已存储的数据，或处理访问请求或查询，或注册请求。可将这种指令布置在一个或多个交互模块1240a-1240n中，交互模块提供允许数据存储器担当请求者的主机的功能。更具体地，这种模块可以包括至少一个GUI，用于允许所有者查看并与数据和本体论交互。通过点击本体论中具体数据片或具体种类，数据所有者将被重定向到PPM，且将因此能够添加和编辑PPM中存储的策略。通常还包括允许数据存储器1200与PPM通信所需的API。GUI和API可从任何已知的适合备选中选择，且因此它们的功能在本文档的范围之外。此外，第二存储器1230可包括模块，例如，如用于将请求者重定向到PPM的重定向模块、用于处理从请求者接收到的访问请求的处理模块、以及用于过滤对从PPM接收到的授权请求的响应的过滤模块。然而，也可替代使用其他的功能模块组合，只要可以执行本文档中描述的功能即可。

还建议了如图13中所建议地配置的PPM，其中，PPM1300包括处理器1310、用于存储如本文档中所述地组织的策略的第一存储器1320、以及用于允许与交互实体(例如，请求者管理的用户设备和本文档中描述的数据存储器)的通信的通信接口1350。PPM1300还包括第二存储器1230，第二存储器1230包括在由处理器1310执行时使处理器1310执行方法或处理(例如，本文档中描述的任一方法或处理)的指令，例如，如发出RPT，在运行时执行访问控制判决，或允许所有者创建新的策略或编辑已存储在第一存储器1320中的策略。这种指令可布置在一个或多个交互模块1240a-1240n中，提供本文中所述的允许PPM担当AM和PPS的功能。更具体地，这种模块可以至少包括用于向数据所有者提供主机视图、所有者定义的应用和策略、以及用于允许所有者管理这些策略(例如，通过修改、删除、查看或编辑策略)的GUI。通常还包括允许数据存储器1200与PPM通信所需的API。GUI和API可从任何已知的适合备选中选择，且因此它们的功能在本文档的范围之外。此外，第二存储器1330可包括例如用于将请求者重定向到PPM的重定向模块、用于处理从请求者接收到的注册请求或RPT请求、或从数据存储器接收到的授权请求或从PPM接收到的授权请求的一个或多个处理模块。然而，也可替代使用其他的功能模块组合，只要可以执行本文档中描述的功能即可。

可定义系统1900，系统1900包括至少一个数据存储器和至少一个PPM(例如，以上参考图13描述的PPM)，该至少一个数据存储器在本上下文中可备选地称为至少一个PDV(例如以上参考图12描述的PDV)。图19中示出了这种系统。

图19的系统能够保护上述数据存储器中存储的资源，且包括至少一个处理器1210、1310和包括指令的至少一个存储器1230、1330，指令在由至少一个处理器1210、1310执行时使系统基于针对每一个相应资源所定义的、并以分层方式所构建的策略来保护不同资源，由此通过以下方式来允许以可变粒度保护不同资源：定义策略，使得策略中针对具体资源所定义的最细粒度的策略能够在执行涉及该资源的请求时动态应用于该资源。虽然数据存储器和PPM在图19中作为单独单元呈现，备选地，系统可被配置为包括所描述功能的一个单独的物理单元。

上述系统还可包括还包括在由至少一个处理器1210、1310执行时使系统执行以下操作的指令：针对表示至少一个数据项的种类定义第一策略，使得第一策略应用于所述种类以及所述种类的未针对其定义策略的子类，其中，针对所述子类中已针对其定义了不同于第一策略的策略的每个子类，在执行涉及所述种类的至少一个数据项的请求时，这样的策略越权第一策略。

如上所述，可根据三个可能实施例之一来应用策略。根据一个实施例，系统1900还包括在由至少一个处理器1210、1310执行时使系统执行以下操作的指令：针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个资源，定义策略，所述定义是通过将所述第一策略的内容复制到其他策略中的每个策略来执行的。

根据又一实施例，系统1900还包括在由至少一个处理器1210、1310执行时使系统执行以下操作的指令：针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类，定义策略，所述策略可以是不同于第一策略的策略，所述定义是通过向子类中每个子类的相应策略提供对第一策略进行引用的引用来执行的。

根据第三实施例，系统1900还包括在由至少一个处理器1210、1310执行时使系统执行以下操作的指令：通过将包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类作为要应用第一策略的资源来列出，定义策略，所述策略可以是不同于第一策略的策略。

一旦应用了策略，可以在系统中执行搜索。更具体地，系统1900还可包括在由至少一个处理器1210、1310执行时使系统通过以下方式搜索已针对其定义了策略的资源的指令：识别从请求者接收到的查询；识别所请求的数据项；通过针对每个识别出的数据项将与具体策略相关联的唯一的标识或名称与所存储的策略相匹配，根据相关策略来确定请求者能够访问的数据项；以及根据匹配的策略向请求者提供响应。

为了允许用户更新策略，系统1900还可以包括在由至少一个处理器1210、1310执行时使系统进行以下操作的指令：更新第一策略，以及更新针对所述种类的子类所定义的与第一策略具有相同内容的每个策略。通过对应方式，系统1900中的策略还可包括在由至少一个处理器1210、1310执行时使系统进行以下操作的指令：删除针对表示至少一个数据项的种类定义的第一策略，以及删除针对所述种类的子类所定义的与第一策略具有相同内容的每个策略。

图20是对以上参考图19描述的系统1900的一个可能配置的示意，包括能够进行交互且由此执行以上参考图11a-c或图14-18中任意图建议的方法步骤的多个交互模块或单元。这些模块可被配置为软件模块、硬件模块、或软件和硬件模块或单元的组合。更具体地，查询识别模块2010被配置为执行本文中所述的方法步骤16：1、17：1和18：1，数据项识别模块2020被配置为执行方法步骤16：2、17：2和18：2，确定模块2030被配置为执行方法步骤16：3、17：3和18：3，提供模块2040被配置为执行步骤16：7，定义模块2050被配置为执行步骤14：1、14：4a-c。

更新模块2060被配置为执行步骤17：4，且删除模块2060被配置为执行步骤18：4。

虽然已经根据若干实施例对实施例进行了描述，在阅读说明书并研究附图之后，预期其备选、修改、置换或等同替代将变得显而易见。因此，意在下面所附的权利要求中包括落在实施例的范围内并由未决权利要求限定的这种备选修改、置换或等同替代。

Claims (19)

1.一种用于保护数据存储器中存储的资源的方法，其中，能够基于针对每一个相应资源所定义的、并以分层方式所构建的不同策略来保护不同资源，由此通过以下方式来允许以可变粒度保护所述不同资源：定义策略，使得策略中针对具体资源所定义的最细粒度的策略能够在执行涉及该资源的请求时动态应用于该资源。

2.根据权利要求1所述的方法，包括：

-针对表示至少一个数据项的种类来定义(14：1)第一策略，使得所述第一策略应用于所述种类以及所述种类的未针对其定义策略的每个子类，

其中，针对所述子类中已针对其定义了不同于所述第一策略的策略的每个子类，在执行涉及所述子类的至少一个数据项的请求时，所述策略越权所述第一策略。

3.根据权利要求1或2所述的方法，其中，定义要应用于种类所表示的至少一个数据项的策略包括：将所述策略与唯一的标识或名称相关联，其中，每个唯一的标识或名称识别所述数据项之一或所述种类，由此使得所述策略可识别。

4.根据权利要求2或3所述的方法，还包括步骤：

-针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类，定义(14：5a)策略，所述策略是不同于所述第一策略的策略，所述定义是通过将所述第一策略的内容复制到不同于所述第一策略的每个策略来执行的。

5.根据权利要求2或3所述的方法，还包括步骤：

-针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类，定义(14：5b)策略，所述策略是不同于所述第一策略的策略，所述定义是通过向每个子类的相应策略提供对所述第一策略进行引用的引用来执行的。

6.根据权利要求2或3所述的方法，还包括步骤：

-通过将包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类作为要应用所述第一策略的子类来列出，定义(14：5c)策略，所述策略是不同于所述第一策略的策略。

7.一种用于搜索资源的方法，其中，已根据前述权利要求中任一项针对所述资源定义了策略，所述搜索是通过以下方式执行的：

-识别(16：1)从请求者接收到的查询；

-识别(16：2)所请求的数据项；

-通过针对每个识别出的数据项将与具体策略相关联的唯一的标识或名称与所存储的策略相匹配，根据相关策略来确定(16：4a、16：4b)所述请求者能够访问的数据项；以及

-根据匹配的策略向所述请求者提供(16：7)响应。

8.一种用于更新第一策略的方法，其中，已根据权利要求1-7中任一项，针对表示至少一个数据项的种类定义了所述第一策略，除了更新(17：4)针对所述数据项所定义的所述第一策略之外，所述方法还包括：

-更新(17：4)针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。

9.一种用于删除第一策略的方法，其中，已根据权利要求1-7中任一项针对表示至少一个数据项的种类定义了所述第一策略，除了删除(18：4)针对所述数据项所定义的所述第一策略之外，所述方法还包括：

-删除(18：4)针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。

10.一种计算机程序，包括指令，所述指令当在至少一个处理器上执行时使所述至少一个处理器执行根据权利要求1-9中任一项所述的方法。

11.一种能够包括数据存储器中存储的资源的系统，包括至少一个处理器(1210、1310)和包括指令的至少一个存储器(1230、1330)，所述指令在由所述至少一个处理器(1210、1310)执行时使所述系统基于针对每一个相应资源所定义的、并以分层方式所构建的策略来保护不同资源，由此通过以下方式来允许以可变粒度保护所述不同资源：定义策略，使得策略中针对具体资源所定义的最细粒度的策略能够在执行涉及该资源的请求时动态应用于该资源。

12.根据权利要求11所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统执行以下操作的指令：

-针对种类定义第一策略，使得所述第一策略应用于表示至少一个数据项的种类、所述种类以及未针对其定义策略的每个子类，

其中，针对所述子类中已针对其定义了不同于所述第一策略的策略的每个子类，在执行涉及所述子类的至少一个数据项的请求时，所述策略越权所述第一策略。

13.根据权利要求11或12所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统执行以下操作的指令：

-通过将策略与唯一的标识或名称相关联，定义要应用于每个子类的策略，所述子类包括种类所表示的至少一个数据项，所述策略是不同于所述第一策略的策略，其中，每一个唯一的标识或名称识别所述数据项之一或所述种类，由此使得所述策略可识别。

14.根据权利要求11、12或13所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统执行以下操作的指令：

-针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类，定义策略，所述策略是不同于所述第一策略的策略，所述定义是通过将所述第一策略的内容复制到不同于所述第一策略的每个策略来执行的。

15.根据权利要求11、12或13所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统执行以下操作的指令：

-针对包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类，定义策略，所述策略是不同于所述第一策略的策略，所述定义是通过向每个子类的相应策略提供对所述第一策略进行引用的引用来执行的。

16.根据权利要求11、12或13所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统执行以下操作的指令：

-通过将包括至少一个数据项并作为所述种类的之前未针对其定义策略的子类的每个子类作为要应用所述第一策略的资源来列出，定义策略，所述策略是不同于所述第一策略的策略。

17.根据权利要求11-16中任一项所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统通过以下方式搜索已针对其定义了策略的资源的指令：

-识别从请求者接收到的查询；

-识别所请求的数据项；

-通过针对每个识别出的数据项将与具体策略相关联的唯一的标识或名称与所存储的策略相匹配，根据相关策略来确定所述请求者能够访问的数据项；以及

-根据匹配的策略向所述请求者提供响应。

18.根据权利要求11-17所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统进行以下操作的指令：更新第一策略，所述第一策略是针对表示至少一个数据项的种类定义的，以及：

-更新针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。

19.根据权利要求11-17所述的系统，还包括在由所述至少一个处理器(1210、1310)执行时使系统进行以下操作的指令：删除第一策略，所述第一策略是针对表示至少一个数据项的种类定义的，以及：

-删除针对所述种类的子类所定义的与所述第一策略具有相同内容的每个策略。