一种云计算环境下数据的访问方法和装置与流程

文档序号:12177775阅读:386来源:国知局
一种云计算环境下数据的访问方法和装置与流程

本申请涉及数据处理的技术领域,特别是涉及一种云计算环境下数据的访问方法和一种云计算环境下数据的访问装置。



背景技术:

全球正在迎来大数据时代,数据已经成为各国政府和企业高度重视的最具经济价值的战略资源。尽管目前大数据存储和挖掘技术已经逐步成熟,然而,数据孤岛的大量存在,制约了数据的流通和变现。大数据最具有想象力的发展方向是将各类数据整合起来,从而提供全方位立体的数据绘图,力图从系统的角度了解并重塑用户模型,数据的“开放性”和“流动性”成为数据掘金的关键,因此围绕数据所有、使用、定价和交易,在业界讨论不断。

在大数据时代,对于数据进行跨组织进行交换、整合,将数据变成商品或者原材料,并在此基础上进行二次开发后的传播,以及进行合理控制,现已经出现数据交易系统这些的事物,用以带动大数据产业繁荣,然而数据交易系统对于数据的授权和访问,仍然是很多业界人士关心的事情。

目前,虽然在业界中已经出现了数据交易系统,但是仍然存在许多缺点,包括如下几点:1、对于数据多方关联授权和二次售卖,导致关系复杂,规模不可控,缺乏有效的管理机制。2、现有技术基本在公有云上,对于私有云上的数据的控制缺乏行之有效的方法。



技术实现要素:

鉴于上述问题,本申请实施例提出了一种克服上述问题或者至少部分地解决上述问题的一种云计算环境下数据的访问方法和一种云计算环境下数据的访问装置。

为了解决上述问题,本申请实施例公开了一种云计算环境下数据的访问方法,在所述云计算环境下包括一个或多个业务对象空间,所述一个或多个业务对象空间下分别存储有数据包;

所述的方法包括:

针对某一业务对象空间,接收用户的数据包访问请求;所述请求中包括用户标识;

确定所述请求对应的数据包所属的业务对象空间;

依据所述所属的业务对象空间和所述用户标识为用户提供数据包。

优选地,所述数据包包括业务对象空间的内部数据包和业务对象空间的外部数据包,所述确定所述请求对应的数据包所属的业务对象空间的步骤包括:

判断所述请求对应的数据包是否为当前业务对象空间的数据包;

若是,则将所述请求对应的数据包判定为业务对象空间的内部数据包;

若否,则将所述请求对应的数据包判定为业务对象空间的外部数据包。

优选地,所述一个或多个业务对象空间包括一个或多个业务对象类型,所述一个或多个业务对象空间的数据包具有对应的业务对象类型,针对所述用户标识和所述业务对象类型设置有第一访问权限;所述依据所属的业务对象空间和所述用户标识为用户提供数据包的步骤包括:

若所述数据包为业务对象空间的内部数据包,则采用所述用户标识确定用户具有第一访问权限;

确定所述业务对象空间的内部数据包所对应的业务对象类型;

在所述业务对象类型下,采用所述第一访问权限为用户业务对象空间的内部数据包。

优选地,所述业务对象类型包括开发类型业务对象和生产类型业务对象,所述开发类型业务对象下的第一访问权限包括共享型权限和隔离型权限,所述第一访问权限包括读、写和管理;所述在业务对象类型下, 采用所述第一访问权限为用户提供业务对象空间的内部数据包的步骤包括:

在所述开发类型业务对象下,若所述用户的访问权限为共享型权限,则允许用户读/写所述开发类型业务对象的内部数据包;

在所述开发类型业务对象下,若所述用户的访问权限为隔离型权限,则允许用户读/写所述开发类型业务对象的指定内部数据包;

在所述生产类型业务对象下,则允许用户读/写所述开发类型业务对象的内部数据包,但禁止用户管理所述开发类型业务对象的内部数据包。

优选地,针对所述用户标识设置有指定访问权限,所述依据所属的业务对象空间和所述用户标识为用户提供数据包的步骤包括:

若所述数据包为业务对象空间的外部数据包,则采用所述用户标识确定用户具有指定访问权限;

采用所述指定访问权限为用户提供所述业务对象空间的外部数据包。

优选地,所述业务对象空间的外部数据包中包括指定字段,所述业务对象空间的外部数据包由数据提供方提供,所述采用指定访问权限为用户提供所述业务对象空间的外部数据包的步骤包括:

接收针对业务对象空间的外部数据包的字段访问请求;

采用所述访问权限发送针对所述字段访问请求的审批请求至该业务对象空间的外部数据包的数据提供方;

若接收到所述数据提供方发送的,针对所述审批请求的允许访问该指定字段的反馈,则允许所述用户访问外部数据包;

若接收到所述数据提供方发送的,针对所述审批请求的禁止访问该指定字段的反馈,则禁止所述用户访问外部数据包。

优选地,所述业务对象空间的外部数据包设置有对应的主题,针对所述用户标识、所述主题和/或预置的授权关系表设置有第二访问权限,所述依据所属的业务对象空间和所述用户标识为用户提供数据包的步骤包括:

若所述数据包为业务对象空间的外部数据包,则采用所述用户标识确定用户具有第二访问权限;

采用所述第二访问权限为用户提供所述业务对象空间的外部数据包。

本申请实施例还公开了一种云计算环境下数据的访问装置,在所述云计算环境下包括一个或多个业务对象空间,所述一个或多个业务对象空间下分别存储有数据包;

所述的装置包括:

请求接收模块,用于针对某一业务对象空间,接收用户的数据包访问请求;所述请求中包括用户标识;

空间确定模块,用于确定所述请求对应的数据包所属的业务对象空间;

数据提供模块,用于依据所述所属的业务对象空间和所述用户标识为用户提供数据包。

优选地,所述数据包包括业务对象空间的内部数据包和业务对象空间的外部数据包,所述空间确定模块包括:

数据包判断子模块,用于判断所述请求对应的数据包是否为当前业务对象空间的数据包;若是,则调用第一判定子模块,若否,则调用第二判定子模块;

第一判定子模块,用于将所述请求对应的数据包判定为业务对象空间的内部数据包;

第二判定子模块,用于将所述请求对应的数据包判定为业务对象空间的外部数据包。

优选地,所述一个或多个业务对象空间包括一个或多个业务对象类型,所述一个或多个业务对象空间的数据包具有对应的业务对象类型,针对所述用户标识和所述业务对象类型设置有第一访问权限;所述数据提供模块包括:

第一访问权限确定子模块,用于在所述数据包为业务对象空间的内部数据包时,采用所述用户标识确定用户具有第一访问权限;

业务对象类型确定子模块,用于确定所述业务对象空间的内部数据包所对应的业务对象类型;

第一数据提供子模块,用于在所述业务对象类型下,采用所述第一访问权限为用户业务对象空间的内部数据包。

优选地,所述业务对象类型包括开发类型业务对象和生产类型业务对象,所述开发类型业务对象下的第一访问权限包括共享型权限和隔离型权限,所述第一访问权限包括读、写和管理;所述第一数据提供子模块包括:

共享权限提供单元,用于在所述开发类型业务对象下,若所述用户的访问权限为共享型权限,则允许用户读/写所述开发类型业务对象的内部数据包;

隔离权限提供单元,用于在所述开发类型业务对象下,若所述用户的访问权限为隔离型权限,则允许用户读/写所述开发类型业务对象的指定内部数据包;

限定权限提供单元,用于在所述生产类型业务对象下,则允许用户读/写所述开发类型业务对象的内部数据包,但禁止用户管理所述开发类型业务对象的内部数据包。

优选地,针对所述用户标识设置有指定访问权限,所述数据提供模块包括:

指定访问权限确定子模块,用于在所述数据包为业务对象空间的外部数据包时,采用所述用户标识确定用户具有指定访问权限;

指定数据提供子模块,用于采用所述指定访问权限为用户提供所述业务对象空间的外部数据包。

优选地,所述业务对象空间的外部数据包中包括指定字段,所述业务对象空间的外部数据包由数据提供方提供,所述第二数据提供子模块包括:

字段访问请求接收单元,用于接收针对业务对象空间的外部数据包的字段访问请求;

审批请求发送单元,用于采用所述访问权限发送针对所述字段访问请求的审批请求至该业务对象空间的外部数据包的数据提供方;

允许访问单元,用于在接收到所述数据提供方发送的,针对所述审批请求的允许访问该指定字段的反馈时,允许所述用户访问外部数据包;

禁止访问单元,用于在接收到所述数据提供方发送的,针对所述审批请求的禁止访问该指定字段的反馈时,禁止所述用户访问外部数据包。

优选地,所述业务对象空间的外部数据包设置有对应的主题,针对所述用户标识、所述主题和/或预置的授权关系表设置有第二访问权限,所述数据提供模块包括:

第二访问权限确定子模块,若所述数据包为业务对象空间的外部数据包,则采用所述用户标识确定用户具有第二访问权限;

第二数据提供子模块,用于采用所述第二访问权限为用户提供所述业务对象空间的外部数据包。

本申请实施例包括以下优点:

本申请实施例中云计算环境下的数据的授权,在经统一的授权流程后为用户分配相应的访问权限,且对于数据的授权可以支持项目空间内,以及跨项目空间的数据授权,破除现有复杂网式的数据权限结构,能够满足公有云和私有云的各类需求场景。本申请实施例在用户需要对于项目空间的数据进行访问时,根据用户申请访问数据的项目空间,以及数据所在的项目空间,确定用户的访问权限从而给予用户相应的访问服务。

本申请实施例中的项目空间的数据授权分为项目空间内授权和跨项目空间授权。对于项目空间内的数据授权,根据项目空间的业务对象类型针对用户分配有相应的访问权限,当用户访问项目空间的数据时,根据访问权限分别为用户提供相应的访问服务。对于跨项目空间的数据授权,针对用户划分有指定的访问权限,当用户访问项目空间的数据时, 根据访问权限为用户提供相应的访问服务。

本申请实施例在用户访问项目空间的数据时,如果访问的数据是项目空间的敏感数据,那么还可以针对用户的访问发送审批请求至数据提供方,最后根据数据提供方的反馈实现对于数据的访问,可以提高数据的安全性。

附图说明

图1是本申请的一种云计算环境下数据的访问方法实施例的步骤流程图;

图2是本申请的一种项目空间内授权的示意图;

图3是本申请的一种跨项目空间授权的AA/AB类型的示意图;

图4是本申请的一种跨项目空间授权ABC类型的示意图;

图5是本申请的一种项目空间的数据授权的整体流程示意图;

图6是本申请的一种云计算环境下数据的访问装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。

目前,对于云计算环境下数据的授权,一般是在一个封闭的企业环境内,不需要考虑跨组织(项目空间)的数据交换场景,因此,对于数据的授权解决方案相对比较简单。例如,在大数据分析平台Hadoop下,只需要为平台内的每个用户分配一个Linux账号,并统一由该平台的管理员来为Linux账号授予指定权限,用户就可以根据该Linux账号所授予的指定权限对于平台的数据进行访问。

目前的解决方案没有租户、项目空间的分层概念,因此对于数据的授权没有跨租户(项目空间)的概念,数据的授权关系为多对多的复杂关系,没有进行分层,且全部由管理员来控制。目前并没有针对跨组织的数据交换场景行之有效的数据授权方案。尤其是面向公有云环境的场 景下,故用户进行访问时有可能会造成一定的混乱。

本申请实施例的解决方案是跨租户(项目空间)的分层管理授权关系,数据提供方和数据使用方可以分别管理自己的数据授权关系,数据提供方关心授权给了哪些租户,数据使用方关心租户内授权给了哪些项目空间和哪些项目空间内的成员。本申请实施例能够基于云计算的数据交易平台,既能提供计算资源控制,又能提供大数据开放和基于这些数据的开发服务,并支持多方授权交易。本申请实施例中为用户分配了相应的访问权限,当用户在某一项目空间下访问数据时,将根据用户所在项目空间,以及用户访问的数据所在的项目空间,确定用户的访问权限从而为用户提供相应的访问服务。

参照图1,示出了本申请的一种云计算环境下数据的访问方法实施例的步骤流程图,在所述云计算环境下可以包括一个或多个业务对象空间,所述一个或多个业务对象空间下可以分别存储有数据包;

在本申请实施例中,所谓的业务对象空间是指云环境下分布的组织,也可以称为项目空间,可能是属于公有云或者属于私有云,在不同的项目空间下分别存储有其相应的数据包。其中,公有云支持跨组织进行数据交换的权限控制,对应的是对外数据包,私有云支持对内部用户的授权场景,对应的是内部数据包。

在项目空间提供数据包的卖家可以称为数据提供方,数据提供方可以将其项目空间的数据包提供给项目空间的内部成员,或者提供给项目空间的外部成员,被提供数据包的项目空间的外部成员也可以是买家,买家也可以称为租户,在数据提供方授权的情形下,租户还可以将数据包提供给其他的租户。通常项目空间下的数据包由数据提供方指定的项目管理员进行管理。

为了使本领域技术人员更好地理解本申请实施例,以下对于本申请实施例涉及的数据概念进行介绍。

数据:在本申请实施例中的数据是广义上的概念,例如表、用户自 定义函数(例如mapreduce编程模型函数)、数据服务、报表等都属于数据。

数据包:数据包是若干数据的集合,具体可以包括以下多种类型:

1、内部数据包:项目空间内部使用的数据包,用于项目管理员给该项目空间内部成员授权和使用。

2、对外数据包:项目空间之间使用的数据包,用于租户项目空间之间授权、数据市场售卖,可进一步细分为:

a)租户内数据包:租户在项目空间之间进行授权和使用的数据包;

b)租户间数据包:租户在不同项目空间之间进行授权、数据市场售卖的数据包;

c)通过中介代理的数据包:官方租户(数据交易平台的租户)与其他租户通过数据市场售卖的数据包。

需要注意的是,租户间数据包一定是在不同项目空间之间的数据包,反之,在不同项目空间之间的数据包则不一定是租户间数据包,因为一个租户下可以有多个项目空间,租户内数据包也可以是跨项目空间进行授权。通过中介代理的数据包其实是租户间数据包的一种特殊形式,即也属于跨项目空间之间的数据包,但是授权的方式比较特殊,需要涉及到数据交易平台、数据提供方、数据使用方这三方。

所述的方法具体可以包括如下步骤:

步骤101,针对某一业务对象空间,接收用户的数据包访问请求;所述请求中包括用户标识;

在具体实现中,用户标识是指在云环境下的用户账号等其他可以用来识别用户的标识,如果在某一项目空间下接收到数据包访问请求,那么会首先提取出该访问请求中的用户标识,以确认该用户的身份,从而为该用户提供相应的访问服务。

步骤102,确定所述请求对应的数据包所属的业务对象空间;

在本申请的一种优选实施例中,所述数据包可以包括业务对象空间的内部数据包和业务对象空间的外部数据包,所述步骤102可以包括如下子步骤:

子步骤S11,判断所述请求对应的数据包是否为当前业务对象空间的数据包;若是,则执行子步骤S12,若否,则执行子步骤S13;

子步骤S12,将所述请求对应的数据包判定为业务对象空间的内部数据包;

子步骤S13,将所述请求对应的数据包判定为业务对象空间的外部数据包。

在具体实现中,用户可以在通过某一项目空间,访问该项目空间下的数据包,或者访问其他项目空间下的数据包。因此,本申请实施例的项目空间在接收到数据包访问请求后,将进一步确认该请求所要求的数据包是该项目空间的内部数据包,或者是其他项目空间的外部数据包。

步骤103,依据所述所属的业务对象空间和所述用户标识为用户提供数据包。

在本申请实施例中,对于数据的授权场景,可以分为两种情况,一种是项目空间内授权,另一种是跨项目空间授权。其中,项目空间内授权包括A类型,跨项目空间授权包括AA类型,AB和ABC类型。其中,A类型涉及数据包为内部数据包;AA、AB、ABC这三种类型涉及数据包都为对外数据包。以下对于A,AA,AB和ABC类型三种类型进行介绍。

A类型:分为共享型和隔离型两种,专指项目空间内的数据授权。

对于A类型而言,自己提供数据包供给内部人员,即项目空间内部使用的数据包,用于项目管理员给该项目空间内部成员授权和使用。

AA类型:涉及两方授权(租户内跨项目空间的数据授权)。

AB类型:涉及两方授权(跨租户跨项目空间授权)。数据提供方开放数据给其他数据使用方(租户)使用,租户购买数据后,可以直接使用全量的数据。

AB类型在数据授权过程只需要两方,故简称为AB类型。较于ABC类型,它的特点是可以获取全量数据,不过也可以进一步区分为两类:开发者和生产者都可以获取全量数据;开发者只能获取抽样后的数据, 生产者才能获取全量数据。数据提供方在售卖数据时可以对此进行选择。

ABC类型:涉及三方授权(跨租户跨项目空间代理授权)。官方租户(数据交易平台的租户)开放数据给开发者(租户)做数据应用,开发者购买数据后,只能得到卖家(数据提供方)进行二次授权的对应的数据,而不能得到全量数据。

为了便于理解,下面举个例子说明下ABC类型的场景。假设某一数据交易平台的一个官方租户,它开放了一份商家主题的数据,如淘宝上所有商家的店铺流量数据;ISV(Independent Software Vendor,独立软体开发商)会为商家开发APP应用,商家会订购APP进行店铺经营;那么,不同的ISV来数据交易平台上购买这份商家店铺流量数据时,将只能获取自己APP的订购商家的店铺流量数据,另外,若是在开发环境只能获取抽样以后的样本数据。

需要说明的是,AB类型中“全量的数据”是为了区别于ABC类型而言的。参照前面所举例子,对于ABC类型授权,假设卖家的数据出售表里有100w(万)行记录,可能某个买家购买后只能获取10w条订购商家的记录。

另外,对于数据售卖的典型场景,不同的租户(包括官方租户)都可以在数据交易平台上上架数据进行售卖,或者从其他租户购买数据进行使用。待售卖的数据可以分多个不同的主题,每个主题下又可以有多张表,按照每张表进行数据的购买。上面提及的AA,AB和ABC类型针对的都是某一张数据表的具体不同情景。

在本申请的一种优选实施例中,所述一个或多个业务对象空间可以包括一个或多个业务对象类型,所述一个或多个业务对象空间的数据包可以具有对应的业务对象类型,针对所述用户标识所述业务对象类型可以设置有第一访问权限;所述步骤103可以包括如下子步骤:

子步骤S11,若所述数据包为业务对象空间的内部数据包,则采用所述用户标识确定用户具有第一访问权限;

子步骤S12,确定所述业务对象空间的内部数据包所对应的业务对象 类型;

子步骤S13,在所述业务对象类型下,采用所述第一访问权限为用户业务对象空间的内部数据包。

在具体实现中,项目空间可以划分为一个或多个的业务对象类型,在本申请实施例中,根据用户申请访问的数据所在的项目空间的业务对象类型,用户将采用不同的访问权限对于项目空间的内部数据包进行访问。

在本申请的一种优选实施例中,所述业务对象类型可以包括开发类型业务对象和生产类型业务对象,所述开发类型业务对象下的用户访问权限可以包括共享型权限和隔离型权限,所述第一访问权限可以包括读、写和管理;所述子步骤S13可以包括如下子步骤:

子步骤S13-1,在所述开发类型业务对象下,若所述用户的访问权限为共享型权限,则允许用户读/写所述开发类型业务对象的内部数据包;

子步骤S13-2,在所述开发类型业务对象下,若所述用户的访问权限为隔离型权限,则允许用户读/写所述开发类型业务对象的指定内部数据包;

子步骤S13-3,在所述生产类型业务对象下,则允许用户读/写所述开发类型业务对象的内部数据包,但禁止用户管理所述开发类型业务对象的内部数据包。

对于项目空间内授权,参照图2所示的本申请的一种项目空间内授权的示意图,在该项目空间分为ODPS(Open Data Processing Service,开放数据处理服务)和DE(Data Engine,数据引擎),项目空间内的一个数据包对应的一个角色(role),这个角色被授权了数据包里中数据(表)的访问权限(如读、写)。

在项目空间内授权的情形,具体可包括如下特征:

(1)项目管理员预先创建好数据包,其中创建数据包可以按项目空间的内部用户群体,或者数据本身的内聚性来划分数据包。比如,有数据开发和数据分析师两类成员,那么可以分别创建不同的数据包:数据 包A可以读写项目内的所有表,授权给数据开发人员;数据包B只能读取项目内的指定表,授权给数据分析人员进行分析。

(2)项目管理员主动把数据包授权给用户,或者用户主动申请加入。通常情况下,用户无需针对单张数据表申请访问权限。

(3)不管项目空间下数据包内的数据表是否包含敏感字段,都采取整表授权的方式。也即是说,用户在申请访问项目空间内的数据包时,不需要一个个字段地勾选数据表来申请访问。

(4)项目管理员的主要工作只需要创建并维护好数据包,持续地往数据包里面增加、删除数据表。

在本申请实施例中,对于项目空间内授权情形,由于项目空间的类型可以包括开发类型和生产类型,也就是项目空间下包括开发环境(开发project)和生产环境(生产project),还可以按照类型划分访问权限,并且还以在此基础上进一步划分访问权限,例如在开发project下,进一步划分共享型权限和隔离型权限。

在开发project下,若用户的访问权限为共享型权限,允许用户读,写开发project下的数据包;若用户的访问权限为隔离型权限,允许用户读,写开发project下指定的数据包。在生产project下,允许用户读,写生产project下的数据包,但禁止用户管理生产project下的数据包,避免过度授权,从而导致一些误操作出现的问题。

在本申请实施例中,对于项目空间内授权的情形,用户可以根据其所分配或申请的访问权限,去访问项目空间下的数据包。此外,基于项目空间不同的环境,还可以设置不同的访问权限。由于项目空间内采用整表授权的方式,因此即使访问的数据包中包含敏感字段,也无需一个个字段地进行访问申请。当然,对于一些实在不方便用户访问的数据表的敏感字段,也可以设置为只有经过数据提供方的同意才可进行访问,以提高数据的安全性,本申请实施例对此不加以限制。

在本申请的一种优选实施例中,针对所述用户标识可以设置有指定访问权限,所述步骤103可以包括如下子步骤:

子步骤S21,若所述数据包为业务对象空间的外部数据包,则采用所述用户标识确定用户具有指定访问权限;

子步骤S22,采用所述指定访问权限为用户提供所述业务对象空间的外部数据包。

在本申请的一种优选实施例中,所述业务对象空间的外部数据包中可以包括指定字段,所述业务对象空间的外部数据包可以由数据提供方提供,所述子步骤S22可以包括如下子步骤:

子步骤S22-1,接收针对业务对象空间的外部数据包的字段访问请求;

子步骤S22-2,采用所述访问权限发送针对所述字段访问请求的审批请求至该业务对象空间的外部数据包的数据提供方;

子步骤S22-3,若接收到所述数据提供方发送的,针对所述审批请求的允许访问该指定字段的反馈,则允许所述用户访问外部数据包;

子步骤S22-4,若接收到所述数据提供方发送的,针对所述审批请求的禁止访问该指定字段的反馈,则禁止所述用户访问外部数据包。

对于跨项目空间授权,其授权类型可以包括AA类型,AB类型和ABC类型。对于AA类型和AB类型,参照图3所示的本申请的一种跨项目空间授权的AA/AB类型的示意图,对于跨项目空间授权的AA类型和AB类型的情形,具体可包括如下特征:

(1)源project(项目空间)的管理员将数据打包授权给目标project。

(2)目标project的管理员拥有对外来数据表(外来数据包)的管理权。每一个外来数据包都会映射成本项目空间的一个数据包,数据包对内部用户的授权由目标project的管理员来决定,源数据的owner(数据提供者)不必参与审批,从而减少了管理员的负担。

(3)如果用户要申请访问外来数据表的敏感字段,那么审批流程中加入“源数据owner审批”这个环节。即有敏感字段的外来数据表是否可以被用户访问,还需要由源数据owner审批去做一次判断,以确定是否同意用户访问。只有当源数据owner审批为同意用户访问,才能将该数据 提供给用户。

当然,“源数据owner审批”这个环节只是一个补充步骤,不是必须的,也可以默认拒绝用户访问敏感字段,或者设置成其他的敏感字段的访问策略,本申请实施例对此不加以限制。

(4)数据提供方可以追溯查看对外提供的数据表的二次授权情况。即源project给目标project授权后,源project还可以查看目标project对于数据再次授权给其他租户的授权情况。

AA类型和AB类型的效果:简化了项目空间之间数据授权关系的蜘蛛网,project与project之间只存在一个数据包,权限和责任的边界清晰明了。当用户访问数据时,在确定其访问权限后将根据其所分配的权限提供相应的访问服务。

在本申请的一种优选实施例中,所述业务对象空间的外部数据包可以设置有对应的主题,针对所述用户标识、所述主题和/或预置的授权关系表可以设置有第二访问权限,所述步骤103可以包括如下子步骤:

子步骤S31,若所述数据包为业务对象空间的外部数据包,则采用所述用户标识确定用户具有第二访问权限;

子步骤S32,采用所述第二访问权限为用户提供所述业务对象空间的外部数据包。

对于跨项目空间授权的ABC类型,参照图4所示的本申请的一种跨项目空间授权的ABC类型的示意图,在具体实现中,一个项目空间下包括开发环境和生产环境。对于跨项目空间授权的AA类型和AB类型的情形,具体可包括如下特征:

(1)源project的管理员按照数据主题对表进行授权,每个数据主题包含若干张表,每张表对应目标project的一个视图,因为每个目标project的授权关系是动态变化的,而且一旦申请了数据,即立刻需要使用最近一段时间的数据,因此无法预先创建好。

具体来说,数据主题本身是数据仓库内对于数据的组织、管理方式,这里数据主题可以方便批量进行数据(表)的授权。比如,有个商家出 售流量主题的数据,那么可以将这个主题下的所有表一次性授权出去。

(2)目标project中的用户在开发环境访问样本数据,在生产环境使用生产数据,但是不能在开发环境访问到生产数据,可以通过数据血缘追踪机制来控制。

在本申请实施例中,根据用户申请访问数据的项目空间,以及数据所在的项目空间,给予用户相应的访问服务。本申请实施例中的项目空间的数据授权分为项目空间内授权和跨项目空间授权,其中,对于项目空间内授权,根据项目空间的类型针对用户划分不同的访问权限,根据访问权限分别为用户提供相应的访问服务。对于跨项目空间授权,针对用户划分指定访问权限,根据访问权限为用户提供相应的访问服务,另外,在用户访问项目空间数据时,如果访问的数据是项目空间的敏感数据,那么还可以针对用户的访问发送审批请求至数据提供方,最后根据数据提供方的反馈实现对于数据的访问,可以提高数据的安全性。

为了使本领域技术人员更好地理解本申请实施例,参照图5所示的本申请的一种项目空间的数据授权的整体流程示意图,在本申请实施例中,项目空间的数据授权可以分为项目空间内授权和跨项目空间授权。

一、对于项目空间内授权的情形:

跨项目空间授权包括A类型这种类型。

具体来说,项目空间的类型可以分为开发project和生产project,在本申请实施例中针对不同类型还可以针对用户设置如下访问权限:

1、对于开发project:

“共享型”类型下,用户能读写开发环境的所有表。

“隔离型”类型下,用户只能读写自己在开发环境创建的表。

2、对于生产project:

通过自有数据包进行授权时,维护数据包和表的映射关系。

其中,自有数据包指的是管理员对项目空间的内部数据授权。而项目空间的数据又分为开发Project、生产Project。在实际应用中,上面提 到的“共享型”类型和“隔离型”类型指的是多个成员对开发Project中数据的使用方式;而自有数据包专指的是生产Project的数据。

在本申请实施例中,对于数据的授权方式可以分为ACL授权和Policy授权,以下对于ACL授权和Policy授权者两种授权进行介绍:

(1)ACL授权是一种基于对象的授权。通过ACL授权的权限数据被看做是该对象的一种子资源。只有当对象已经存在时,才能进行ACL授权操作;当对象被删除时,通过ACL授权的权限数据会被自动删除。ACL授权支持类似于SQL92定义的GRANT/REVOKE语法,它通过简单的授权语句来完成对已存在的项目空间对象的授权或撤销授权。一条ACL授权记录中主要记录了以下信息:角色、资源、授权。

例如:

USE test_project;--打开项目空间

ADD USER ALIYUN$alice@aliyun.com;--添加用户

ADD USER ALIYUN$bob@aliyun.com;--添加用户

CREATE ROLE worker;--创建角色

GRANT worker TO ALIYUN$alice@aliyun.com;--角色指派

GRANT worker TO ALIYUN$bob@aliyun.com;--角色指派

GRANT CreateInstance,CreateResource,CreateFunction,CreateTable,List ON PROJECT test_project TO ROLE worker;--对角色授权

(2)Policy授权仅是针对较为复杂的授权场景来使用。Policy授权则是一种基于主体的授权。通过Policy授权的权限数据(即访问策略)被看做是授权主体的一种子资源。只有当主体(用户或角色)存在时,才能进行Policy授权操作;当主体被删除时,通过Policy授权的权限数据会被自动删除。Policy授权使用自定义的一种访问策略语言来进行授权,允许或禁止主体对项目空间对象的访问权限。

Policy授权是一种新的授权机制,它主要解决ACL授权机制无法解决的一些复杂授权场景,比如:一次操作对一组对象进行授权,如所有的函数、所有以“taobao”开头的表。

Policy授权是带限制条件的授权,如授权只会在指定的时段内才会生效、当请求者从指定的IP地址发起请求时授权才会生效、或者只允许用户使用SQL(Structured Query Language,结构化查询语言)(而不允许其它类型的任务Task)来访问某张表。

Policy授权机制使用访问策略语言(Access Policy)来描述授权,关于ODPS访问策略语言的详细描述,下面给出一个简单的使用Project Policy授权的应用实例:

场景说明:授权用户alice@aliyun.com只能在“2013-11-1123:59:59”这个时间点之前、只能从“10.32.180.0~23”这个IP段提交请求,只允许在项目空间test_project中执行CreateInstance,CreateTable和List操作,禁止删除test_project下的任何表。

例如:

本申请实施例中,对于生产环境生产任务运行的专有账号,需要能够使得该专有账号读写生产环境下的所有表,且同时满足最小权限的原则(如不能拥有管理型操作的权限)。

最小权限原则也是安全设计的基本原则之一。最小权限原则要求系统只授予主体必要的权限,而不要过度授权,这样能有效地减少系统、网络、应用、数据库出错的机会。比如,在Linux系统中,一种良好的操作习惯是使用普通账户登录,在执行需要root权限的操作时,再通过sudo命令完成。这样能最大化地降低一些误操作导致的风险;同时普通账户被盗用后,与root帐户被盗用所导致的后果是完全不同的。

二、对于跨项目空间授权的情形:

跨项目空间授权包括AA类型,AB类型和ABC类型这三种类型。

1、跨项目空间授权(AA/AB)

源project通过将数据打包授权给目标project,源project的管理员创建数据包(package)时,维护数据包和表的映射关系。

目标project的管理员在项目空间内二次授权。

2、跨项目空间授权(ABC)

源project通过view(视图)将每张需要授权的表授权给目标project。

view创建在目标project中,底层实现需要加入源表和授权关系表,从而实现对表的行级授权。

所谓行级授权是指,在ABC类型下,一张表可能有100w行,而只 能授权给其中的一部分(比如10w行或20w行),因此要结合另一张授权关系表(如某个ISV的APP被哪些商家订购了),构建view实现只授权满足指定条件(该行记录中的商家标识(例如商家ID)包含在APP的订购商家ID列表中)的行的记录。

本申请实施例在根据项目空间对于数据授权明晰分层的情形下,当用户需要访问项目空间的数据时,可以根据用户申请访问数据的项目空间,以及数据所在的项目空间,快速确定用户的访问权限从而给予用户相应的访问服务。

综上可以获知,应用本申请实施例可以达到如下效果:

1)本申请实施例中的统一的授权流程同时满足公有云和私有云的各类需求场景,在权限确定的情况下,在用户访问项目空间下的数据时,将根据用户访问权限为用户提供访问服务。

2)本申请实施例可以支持项目空间内数据授权,例如A类型,以及项目空间之间数据授权的多种业务类型,例如AA/AB/ABC类型,基于项目空间进行合理分层,破除现有复杂网式的数据权限结构。因此,在用户访问项目空间下的数据时,可以快速确定用户的访问权限,且不需要项目管理员参与,从而提高了数据交易平台的处理效率。

需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请实施例并不受所描述的动作顺序的限制,因为依据本申请实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请实施例所必须的。

参照图6,示出了本申请的一种云计算环境下数据的访问装置实施例的结构框图,在所述云计算环境下可以包括一个或多个业务对象空间,所述一个或多个业务对象空间下可以分别存储有数据包;具体可以包括 如下模块:

请求接收模块201,用于针对某一业务对象空间,接收用户的数据包访问请求;所述请求中包括用户标识;

空间确定模块202,用于确定所述请求对应的数据包所属的业务对象空间;

在本申请的一种优选实施例中,所述数据包包括业务对象空间的内部数据包和业务对象空间的外部数据包,所述空间确定模块202可以包括如下子模块:

数据包判断子模块,用于判断所述请求对应的数据包是否为当前业务对象空间的数据包;若是,则调用第一判定子模块,若否,则调用第二判定子模块;

第一判定子模块,用于将所述请求对应的数据包判定为业务对象空间的内部数据包;

第二判定子模块,用于将所述请求对应的数据包判定为业务对象空间的外部数据包。

数据提供模块203,用于依据所述所属的业务对象空间和所述用户标识为用户提供数据包。

在本申请的一种优选实施例中,所述一个或多个业务对象空间可以包括一个或多个业务对象类型,所述一个或多个业务对象空间的数据包具有对应的业务对象类型,针对所述用户标识和所述业务对象类型可以设置有第一访问权限;所述数据提供模块203可以包括如下子模块:

第一访问权限确定子模块,用于在所述数据包为业务对象空间的内部数据包时,采用所述用户标识确定用户具有第一访问权限;

业务对象类型确定子模块,用于确定所述业务对象空间的内部数据包所对应的业务对象类型;

第一数据提供子模块,用于在所述业务对象类型下,采用所述第一访问权限为用户业务对象空间的内部数据包。

在本申请的一种优选实施例中,所述业务对象类型包括开发类型业 务对象和生产类型业务对象,所述开发类型业务对象下的第一访问权限包括共享型权限和隔离型权限,所述第一访问权限包括读、写和管理;所述第一数据提供子模块包括:

共享权限提供单元,用于在所述开发类型业务对象下,若所述用户的访问权限为共享型权限,则允许用户读/写所述开发类型业务对象的内部数据包;

隔离权限提供单元,用于在所述开发类型业务对象下,若所述用户的访问权限为隔离型权限,则允许用户读/写所述开发类型业务对象的指定内部数据包;

限定权限提供单元,用于在所述生产类型业务对象下,则允许用户读/写所述开发类型业务对象的内部数据包,但禁止用户管理所述开发类型业务对象的内部数据包。

在本申请的一种优选实施例中,针对所述用户标识设置有指定访问权限,所述数据提供模块203可以包括如下子模块:

指定访问权限确定子模块,用于在所述数据包为业务对象空间的外部数据包时,采用所述用户标识确定用户具有指定访问权限;

指定数据提供子模块,用于采用所述指定访问权限为用户提供所述业务对象空间的外部数据包。

在本申请的一种优选实施例中,所述业务对象空间的外部数据包中包括指定字段,所述业务对象空间的外部数据包由数据提供方提供,所述第二数据提供子模块可以包括如下单元:

字段访问请求接收单元,用于接收针对业务对象空间的外部数据包的字段访问请求;

审批请求发送单元,用于采用所述访问权限发送针对所述字段访问请求的审批请求至该业务对象空间的外部数据包的数据提供方;

允许访问单元,用于在接收到所述数据提供方发送的,针对所述审批请求的允许访问该指定字段的反馈时,允许所述用户访问外部数据包;

禁止访问单元,用于在接收到所述数据提供方发送的,针对所述审 批请求的禁止访问该指定字段的反馈时,禁止所述用户访问外部数据包。

在本申请的一种优选实施例中,所述业务对象空间的外部数据包可以设置有对应的主题,针对所述用户标识、所述主题和/或预置的授权关系表可以设置有第二访问权限,所述数据提供模块203可以包括如下子模块:

第二访问权限确定子模块,若所述数据包为业务对象空间的外部数据包,则采用所述用户标识确定用户具有第二访问权限;

第二数据提供子模块,用于采用所述第二访问权限为用户提供所述业务对象空间的外部数据包。

对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白,本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中,所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、 数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非持续性的电脑可读媒体(transitory media),如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例,但本领域内的技术人员 一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种云计算环境下数据的访问方法和一种云计算环境下数据的访问装置,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1