一种访问控制方法及平台与流程

本发明涉及一种云计算数据中心的安全领域，尤其涉及一种访问控制方法及平台。

背景技术：

在云计算数据中心领域，saas(softwareasaservice)是一种新的软件应用模式,它极大地减少了企业在信息基础设施上的投入。目前，saas模式大概可以分为四级成熟度，当saas达到第三级成熟度即多租户模式时，则要求saas能够满足租户各自配置基础数据并能够隔离租户间的数据，以此来使得每个租户的数据足够安全。此时，该模式是否足够安全并具有相当的可管理性是亟待解决的问题。多租户模式使得处于同一实例的租户数据有被其他租户非法访问的风险。

在目前存在的访问控制方法中，主流使用的有：自主访问控制(dac)、强制访问控制(mac)、基于角色的访问控制(rbac)。但对于saas模式来说，目前的研究中，大多都是基于传统rbac模型的，传统rabc模型为单层管理模型，即针对平台层进行访问控制。平台角色分为规则角色和管理角色，规则角色用来执行平台的业务功能，管理角色用来管理平台中角色的创建、权限的分配。但是传统rbac模型对整个平台资源的分配和角色划分都是全局性的，不能根据租户需求进行访问控制策略定制，也不能将各租户之间的规则、管理角色分开，进而无法将同一平台不同租户的数据进行隔离管理；同时，平台管理员具有租户管理员的部分权限，在权限继承上会出现平台管理员干预租户业务的情况，从而影响租户的数据安全性；传统rbac模型也不能根据租户需求对平台功能资源进行个性化定制，导致租户需要为不必要的功能资源买单，从而降低租户满意度。

技术实现要素：

本发明要解决的主要技术问题是，提供一种访问控制方法及平台，以解决现有技术中不能将同一平台中不同租户的数据进行隔离，导致各租户的数据安全无法有效保证的技术问题。

为解决上述技术问题，本发明提供一种访问控制方法，包括：

接收用户向平台发起的资源访问请求，所述资源访问请求包含所述用户账号和目标资源；

根据所述用户账号获取所述用户所在租户中对应的角色及角色权限；

根据该角色权限判断该角色是否具备访问所述目标资源的权限；

若具备访问所述目标资源的权限，提供目标资源给所述用户，若不具备访问所述目标资源的权限，拒绝提供目标资源给所述用户。

在本发明一种实施例中，在所述接收用户向平台发起的资源访问请求之前还包括：

接收所述租户向平台发起的注册申请并进行审核；

审核通过后生成租户管理员，并对所述租户管理员选择的资源进行授权。

在本发明一种实施例中，所述审核通过后生成租户管理员，并对所述租户管理员选择的资源进行授权包括：

为所述租户生成所述租户管理员；

通过所述租户管理员进行角色创建、权限分配和资源选择；

根据选择的资源进行授权。

在本发明一种实施例中，所述租户管理员创建的角色包括租户规则角色和租户管理角色，所述租户管理角色对所述租户规则角色进行管理。

在本发明一种实施例中，在对所述租户管理员选择的资源进行授权之后， 且接收用户向平台发起的资源访问请求之前还包括：

接收管理用户向平台发起的管理请求，所述管理请求包含所述管理用户账号和目标管理对象；

根据所述管理用户账户获取所述管理用户在所述租户中对应的角色及角色权限；

根据所述角色权限确定所述管理用户的管理范围；

根据所述管理范围判断该角色是否具备管理所述目标管理对象的权限；

若具备管理所述目标管理对象的权限，允许所述管理用户对目标管理对象进行管理，若不具备管理所述目标管理对象的权限，拒绝所述管理用户对目标管理对象进行管理。

在本发明一种实施例中，所述平台包含平台规则角色和平台管理角色，所述平台管理角色对所述平台规则角色进行管理。

进一步地，本发明还提供了一种访问控制平台，包括：

第三接收模块，用于接收用户向平台发起的资源访问请求，所述资源访问请求包含所述用户账号和目标资源；

第一获取模块，用于根据所述用户账号获取所述用户所在租户中对应的角色及角色权限；

第一判断模块，用于根据该角色权限判断该角色是否具备访问所述目标资源的权限；

第一处理模块，用于若具备访问目标资源的权限，提供目标资源给所述用户，若不具备访问目标资源的权限，拒绝提供目标资源给所述用户。

在本发明一种实施例中，在所述第三接收模块接收用户向平台发起的资源访问请求之前还包括：

第一接收模块，用于接收所述租户向平台发起的注册申请并进行审核；

授权模块，用于审核通过后生成租户管理员，并对所述租户管理员选择的资源进行授权。

在本发明一种实施例中，所述授权模块包括：

生成子模块，用于为所述租户生成所述租户管理员；

配置子模块，用于通过所述租户管理员进行角色创建、权限分配和资源选择；

授权子模块，用于根据选择的资源进行授权。

在本发明一种实施例中，在所述授权模块根据选择的资源进行授权之后，且所述第三接收模块接收用户向平台发起的资源访问请求之前还包括：

第二接收模块，用于接收管理用户向平台发起的管理请求，所述管理请求包含所述管理用户账户和目标管理对象；

第二获取模块，用于根据所述管理用户账户获取所述管理用户在所述租户中对应的角色及角色权限；

确定模块，用于根据所述角色权限确定所述管理用户的管理范围；

第二判断模块，用于根据所述管理范围判断该角色是否具备管理所述目标管理对象的权限；

第二处理模块，用于若具备管理权限所述目标管理对象的权限，允许所述管理用户对目标管理对象进行管理，若不具备管理权限所述目标管理对象的权限，拒绝所述管理用户对目标管理对象进行管理。

本发明的有益效果是：

本发明提供了一种访问控制方法及平台，包括：接收用户向平台发起的资源访问请求，该资源访问请求包含用户账号和目标资源；根据该用户账号获取 用户所在租户中对应的角色及角色权限，然后根据该角色权限判断该角色是否具备访问目标资源的权限，若具备访问所述目标资源的权限，提供目标资源给所述用户，若不具备访问所述目标资源的权限，拒绝提供目标资源给所述用户。通过本发明的实施，当用户在平台中进行资源访问时，通过用户所在租户的角色权限验证该用户是否具备访问该目标资源的权限，有效的将不同租户的数据进行隔离，从而保证在同一平台下的每个租户数据安全。而现有的基于角色的访问控制模型是单层管理模型，其访问控制策略使得整个系统资源的分配、角色等级的划分都是全局性的，导致租户不能自主进行角色划分、权限分配和资源选择，同时在进行资源访问时对于同一平台中的不同租户的数据也不能进行有效隔离管理，从而无法保障租户的隐私安全。相比之下，本申请提供的访问控制方法通过将各租户的数据进行隔离，更灵活有效的提升租户隐私的安全性。

此外，本申请将租户概念引入基于角色的访问控制模型中，增加了租户规则角色和租户管理角色，将单层管理模型扩展为两层管理管理模型(即平台层和租户层)，使得平台与租户管理模型之间部分分开，避免平台管理员对租户的干预，同时，租户可根据自身需求进行差异化定制，从而避免用户为不需要的平台资源买单。

附图说明

图1为本发明实施例一提供的saas系统结构示意图；

图2为本发明实施例一提供的用户资源访问控制流程图；

图3为本发明实施例一提供的企业注册流程图；

图4为本发明实施例一提供的管理用户管理控制流程图；

图5为本发明实施例二提供的访问控制平台示意图。

具体实施方式

下面通过具体实施方式结合附图对本发明作进一步详细说明。

实施例一：

本发明提供了一种访问控制方法，请参见图1所示的saas系统结构示意图。图1中，包含以下几个基本元素：

租户，指saas(softwareasaservice，软件即服务)平台的使用企业，记作t＝{t1,t2,...,tn}，表示所有租户的集合。

用户，指可以独立访问平台中的资源的主体，各用户只能在租户许可的范围内访问平台的资源，记作u＝{u1,u2,...,un}，表示所有用户的集合；在saas平台中，租户t的用户集为u(t)，而saas平台管理员为u(pa)。

角色，指组织或任务中的工作或岗位，在saas平台中角色包括租户规则角色r、租户管理角色ar、平台规则角色par和平台管理角色paar。其中，r(t)、ar(t)分别表示租户t的规则角色集和管理角色集。

访问权限，指允许对资源进行的各项操作，访问权限分为：

租户规则权限：p＝{p1,p2,...,pn}

租户管理权限：ap＝{ap1,ap2,...,apn}

平台规则权限：pap＝{pap1,pap2,...,papn}

平台管理权限：paap＝{paap1,paap2,...,paapn}

用p(t)、ap(t)分别表示租户t的规则权限集和管理权限集。

资源，指所有需要设置权限的资源通称，如某部分数据，记作res＝{res1,res2,...,resn}。其中res(t)表示租户t的资源集合。

操作，指对资源的操作，比如删除、增加，记作opera＝{opera1,opera2,...,operan}，表示所有操作集，如读、写、执行。其中opera(t)表示租户t的操作集。

par/pap(platformrole/platformpermission)，指平台规则角色/权限，这些角色使用这些权限来负责平台日常维护，包括租户账号审核、租户状态管理、租户费用管理，租户权限的管理。但是平台管理员没有任何权限干涉租户的具体业务，一般部署该服务的企业才会是平台管理员。

paar/paap(platformadministrativerole/platformadministrativepermission)，指平台管理角色/权限，这些角色使用这些权限来维护平台规则角色等，一般整个saas平台中也只有较少几个这样的角色。

papac/paapac：平台规则权限/平台管理权限分配约束，定义平台规则权限/平台管理权限在分配给规则角色/管理角色时的相关约束条件。

pauac/paauac，指平台规则角色-用户/平台管理角色-用户分配约束，定义了将平台规则角色/平台管理角色分配给用户时的相关约束条件。

t(tenant)，指租户，单个租户包含多个规则角色r、规则权限p、管理角色ar、管理权限ap，而会话集s、约束集c中为所有租户各自的会话集的合集。并且由于平台管理角色paar与租户没有关系，平台对租户的管理通过平台规则角色pap来完成。租户部分，规则角色、管理角色以及用户之间的关系与平台部分类似，这里不再赘述。

此外，平台部分与租户部分的1:n关系，表示该模型的平台控制结构只有一个，而可以有多个租户控制结构，由各租户自行实现。

进一步地，在上述基本元素的基础上，请参见图2，图2为本实施例提供的用户资源访问控制流程图。在本实施例中，访问控制方法的步骤具体如下：

s201，接收用户向平台发起的资源访问请求，资源访问请求包含用户账号和目标资源；

s202，根据用户账号获取用户所在租户中对应的角色及角色权限；

s203，根据该角色权限判断该角色是否具备访问目标资源的权限，若具备访问所述目标资源的权限，请转入s204步骤，若不具备访问所述目标资源的权限，请转入s205步骤；

s204，提供目标资源给该用户；

s205，拒绝提供目标资源给所述用户。

通过上述方法，平台获取用户在租户中分配到的角色以及该角色对应的角色权限，根据角色权限确定租户分配给用户的资源，该资源是由租户从系统中选择的资源提供，然后验证用户请求访问的目标资源是否在租户分配给用户的资源中，若是，则正常进行目标资源访问，反之，结束访问。有效的验证用户是否具备访问目标资源的权限，进而将各租户间的数据进行隔离，保障租户数据安全。

进一步地，在平台接收用户发起的资源访问请求之前，租户需向平台发起注册申请，申请通过后租户(即企业)中的用户才可正常进行资源访问。请参见图3，租户在平台的注册流程如下：

s301，接收租户向平台发起的注册申请并进行审核；

s302，审核通过后生成租户管理员，并对租户管理员选择的资源进行授权。

进一步地，租户向平台申请注册时，包括租户企业名称等租约相关信息，并设置管理员账号，然后平台方(即运营服务提供商)对租户进行审核，在审核通过后为租户生成租户管理员，该租户管理员代表租户，并通过该租户管理员对租户进行角色划分、权限分配以及系统资源选择等初始化工作。具体的，租户管理员创建租户规则角色和租户管理角色，租户管理角色对租户规则角色进行管理，不同的租户规则角色和不同的租户管理角色赋予对应的角色权限，如：租户管理角色对其在租户中的管理范围进行划分，租户规则角色对其在租 户中所需的资源进行选择，然后运营服务提供商根据租户规则角色从系统中选择的资源进行收费，并授权租户规则角色使用其定制的系统功能，最后租户企业就可正常进行租户业务。通过该注册流程，解决了平台中系统资源的按需授予，将系统资源按租户需求从总资源池中映射出子资源池给租户，然后租户对子资源池进行自主分配，该方法简单且便于租户租费的计算和收取，亦可避免租户为不必要的资源买单，从而造成资源浪费的情况。应该注意的是，资源包括各种基础数据以及各种系统功能。

进一步地，在租户企业成功注册并获取平台授权之后，且在用户对平台发起资源访问请求之前，还包括对租户管理用户的管理权限进行验证的流程，该管理控制流程与普通用户的资源访问控制流程相对应，请参见图4，图4为本实施例提供的管理用户管理控制流程图，具体管理控制流程如下：

s401，接收管理用户向平台发起的管理请求，该管理请求包含管理用户账号和目标管理对象；

s402，根据管理用户账号获取管理用户在租户中对应的角色及角色权限；

s403，根据角色权限确定管理用户的管理范围；

s404，根据管理范围判断该角色是否具备管理目标管理对象的权限，若具备管理所述目标管理对象的权限，请转入s405步骤，若不具备管理所述目标管理对象的权限，请转入s406步骤；

s405，允许管理用户对目标管理对象进行管理；

s406，拒绝管理用户对目标管理对象进行管理。

在上述管理控制流程中，管理用户为租户中管理角色对应的用户，普通用户为租户中规则角色对应的用户，管理用户对普通用户进行权限分配、资源划分等管理。平台在接收管理用户发起的管理请求时，管理请求中包含管理用户 的登录信息，登录信息中含有管理用户账号以及目标管理对象，该目标管理对象为管理用户请求管理的其所在租户中的相应信息，相应信息包括但不限于普通用户的角色权限和角色等级。管理用户对该相应信息进行管理前，首先需要通过平台进行验证，验证其是否具备管理该相应信息的权限，即验证其管理的目标管理对象是否超过其职责管理范围。如果验证未通过，平台拒绝管理用户的管理请求，通过该方法，有效的控制租户管理用户的管理范围，使得租户的管理行为都在自身的安全域内进行，该租户不会干扰到其他租户，当然其他租户也不会干扰到该租户本身。

通过该访问控制平台，各租户企业可以很方便地对租户业务进行执行，对租户内部进行管理。当租户企业中某个用户职位发生变化时，其管理权限也相应变化，本实施例提供的方法可以很灵活的对该用户对应的角色进行调整，管理用户也相应的对该角色赋予对应的权限，真正实现saas第三级成熟度模型，实现租户数据的有效隔离。

进一步地，提供平台服务的运营服务提供商中的平台角色包括平台管理角色和平台规则角色，其中，平台管理角色通常在整个saas平台中只有较少的几个，其主要对平台规则角色进行管理；而平台管理角色相对要多些，主要负责对平台的日常维护，包括租户账号审核、租户状态管理、租户费用管理以及租户权限的管理，但是平台管理员没有任何权限干涉租户的具体业务，一般部署该服务的企业才会是平台管理员。此外，在模型中引入平台管理用户类型和租户管理用户类型，实现平台管理、租户管理的职能分离，进而消除了平台管理员和租户管理员权限的继承关系，实现平台安全管理。

由于本实施例引入租户概念，在租户系统中分别增加了租户-用户管理，租户-角色管理，租户-权限管理，通过该管理模型，有效地对统一系统中的不同 租户的数据进行隔离管理，并且将基于角色访问控制模型的单层管理模型扩展到两层管理模型(平台层到租户层)，使得平台与租户管理模型之间得以部分分开，以实现平台管理者对租户的不可干预，有效保障各租户的隐私。

在本实施例中，上述流程均基于以下规则定义进行执行，具体定义如下：

租户规则部分定义：

其中x∈{r,u,p}；

表示从角色集/用户集/权限集到租户集的多对一映射。

其中x∈{u,p,r}；

表示从角色集到用户集/权限集/角色集的多对多映射。

租户管理部分定义：

其中x∈{ar,ap}；

表示从管理角色集/管理权限集到租户集的多对一映射。

其中x∈{u,ap,ar}；

表示从管理角色集到用户/管理权限集/管理角色集的多对多映射。

平台规则部分定义：

其中x∈{pap,u,par}；

表示某saas应用中，从saas平台规则角色集到saas平台规则权限集/用户/平台规则角色集的多对多映射。

平台管理部分定义：

其中x∈{paap,u,paar}；

表示某saas应用中，从saas平台管理角色集到saas平台管理权限集/用户/平台管理角色集的多对多映射。

映射定义：

permission：opera->res；

表示操作到资源的映射关系，用(opera，res)二元组表示，如：

(read,res1)∈permission，表示对res1具有读取权限。

users：s->u；

表示会话到用户的映射关系，用(session，user)表示，如：

(session1,user1)∈users，表示session1是属于用户user1的会话。

roles：roles:s→2^{rt∪art∪par∪paar}；

表示会话到角色集的映射关系，用二元组(session,roleset)表示，如：(session1,roleset1)∈roles，表示session1所具有的相应角色集，其中roleset表示一组角色的集合。并且有：(在实现时，可以将服务提供商视为一个特别的租户)

其中，会话权限如下：

由于管理权限只能赋予管理角色，规则权限只能赋予规则角色，所以租户规则权限、租户管理权限、平台规则权限、平台管理权限两两无交集。

实施例二：

请参见图5，图5为本实施例提供的访问控制平台示意图；此外，上述基本元素和规则定义同样适用于本实施例，这里不再阐述。

在本实施例中，访问控制平台5包括：

第三接收模块501，用于接收用户向平台发起的资源访问请求，资源访问请求包含用户账号和目标资源；

第一获取模块502，用于根据用户账号获取用户所在租户中对应的角色及角 色权限；

第一判断模块503，用于根据该角色权限判断该角色是否具备访问目标资源的权限；

第一处理模块504，用于若具备访问目标资源的权限，提供目标资源给所述用户，若不具备访问目标资源的权限，拒绝提供目标资源给所述用户。

通过上述访问控制平台5，在获取用户在租户中分配到的角色以及该角色对应的角色权限后，根据角色权限确定租户分配给用户的资源，该资源是由租户从系统中选择的资源提供，然后验证用户请求访问的目标资源是否在租户分配给用户的资源中，若是，则正常进行目标资源访问，反之，拒绝目标资源的访问，有效的验证用户是否具备访问目标资源的权限，进而将各租户间的数据进行隔离，保障租户数据安全。

进一步地，在第三接收模块501接收用户向平台发起的资源访问请求之前，租户需向平台发起注册申请，申请通过后租户(即企业)中的用户才可正常进行资源访问，因此还包括以下模块：

第一接收模块505，用于接收所述租户向平台发起的注册申请并进行审核；

授权模块506，用于审核通过后生成租户管理员，并对租户管理员选择的资源进行授权。

其中，授权模块506包括：

生成子模块5061，用于为租户生成租户管理员；

配置子模块5062，用于通过租户管理员进行角色创建、权限分配和资源选择；

授权子模块5063，用于根据选择的资源进行授权。

上述子模块具体为：租户向平台申请注册时，注册的信息包括租户企业名 称等租约相关信息，同时设置管理员账号，然后平台方(即运营服务提供商)对租户进行审核，在审核通过后生成子模块5061为租户生成租户管理用户，该租户管理用户代表租户，对租户执行角色划分、权限分配以及系统资源选择等初始化工作。具体的，租户管理用户创建租户规则角色和租户管理角色，不同的租户规则角色和不同的租户管理角色赋予对应的角色权限，如租户管理角色对其在租户中的管理范围进行划分，租户规则角色对其在租户中所需的资源进行选择。然后运营服务提供商通过授权子模块5063根据租户规则角色从系统中选择的资源进行收费，并授权租户规则角色使用其定制的系统功能，最后租户企业正常进行租户业务，使得平台中系统资源能按需授予，将系统资源按租户需求从总资源池中映射出子资源池给租户，然后租户对子资源池进行自主分配，避免租户为不必要的资源买单，从而造成资源浪费。

此外，在授权模块506根据选择的资源进行授权之后，且第三接收模块501接收用户向平台发起的资源访问请求之前还包括：

第二接收模块507，用于接收管理用户向平台发起的管理请求，所述管理请求包含所述管理用户账号和目标管理对象；

第二获取模块508，用于根据所述管理用户账号获取所述管理用户在所述租户中对应的角色及角色权限；

确定模块509，用于根据所述角色权限确定所述管理用户的管理范围；

第二判断模块510，用于根据所述管理范围判断该角色是否具备管理所述目标管理对象的权限；

第二处理模块511，用于若具备管理权限所述目标管理对象的权限，允许所述管理用户对目标管理对象进行管理，若不具备管理权限所述目标管理对象的权限，拒绝所述管理用户对目标管理对象进行管理。

在上述各模块中，管理用户为租户中管理角色对应的用户，普通用户为租户中规则角色对应的用户，管理用户对普通用户进行权限分配、资源划分等管理。平台在接收管理用户发起的管理请求时，管理请求中包含管理用户的登录信息，登录信息中含有管理用户账号以及目标管理对象，该目标管理对象为管理用户请求管理的其所在租户中的相应信息，相应信息包括但不限于普通用户的角色权限和角色等级。管理用户对该相应信息进行管理前，首先需要通过平台进行验证，验证其是否具备管理该相应信息的权限，即验证其管理的目标管理对象是否超过其职责管理范围。如果验证未通过，平台拒绝管理用户的管理请求，通过该方法，有效的控制租户管理用户的管理范围，使得租户的管理行为都在自身的安全域内进行，该租户不会干扰到其他租户，当然其他租户也不会干扰到该租户本身。

显然，本领域的技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储介质(rom/ram、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换， 都应当视为属于本发明的保护范围。