一种业务访问控制方法、系统及电子设备和存储介质与流程

本申请涉及计算机技术领域，更具体地说，涉及一种业务访问控制方法、系统及一种电子设备和一种计算机可读存储介质。

背景技术：

零信任体系，是一种防止数据从组织的可信网络泄露的一种理念，即总是验证，绝不信任。在一些传统的利用零信任体系对用户权限进行控制的方案中，通常是基于应用进行访问权限控制，即根据业务系统的特征，例如web应用或隧道应用在零信任系统控制中心添加不同的应用，控制中心在评估用户的信任等级后和网络代理服务器交互，以阻断或放行指定的应用访问请求。然而，在这种方式下，难以适配各种各样的业务系统。以web应用为例，有些业务系统以域名区分应用，有些以端口进行区分，有些以路径进行区分，甚至还有基于url参数进行区分的业务系统。因此，如何解决上述问题是本领域技术人员亟待解决的问题。

技术实现要素：

本申请的目的在于提供一种业务访问控制方法、系统及一种电子设备和一种计算机可读存储介质，解决了各种各样的业务系统的适配问题。

为实现上述目的，本申请提供了一种业务访问控制方法，包括：

接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；

通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；

根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。

可选的，所述接收用户发起的业务访问请求之前，还包括：

获取当前登录系统的用户信息；

通过调用所述软件开发工具包的第一接口，获取每个用户针对所有业务的第二访问权限信息；

根据所述第二访问权限信息确定每个用户不具备访问权限的目标业务，并在每个用户对应的交互界面对所述目标业务进行灰化处理。

可选的，还包括：

获取所述软件开发工具包发送的权限变更通知；所述权限变更通知为所述软件开发工具包通过长轮询方式向所述零信任控制中心请求得到最新权限信息之后发送的变更通知；

根据所述权限变更通知判断是否需要对当前登录系统的用户进行强制下线处理或推送权限变更的提示信息。

可选的，所述通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息，包括：

通过调用所述软件开发工具包的第一接口，根据所述目标业务的标识信息在本地缓存中查找是否存在对应的第一访问权限信息；

如果否，则向所述零信任控制中心发送权限获取请求，以接收所述第一访问权限信息并缓存在本地。

可选的，所述根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应，包括：

若所述第一访问权限信息为所述当前用户具备访问所述目标业务的权限，则直接放行所述业务访问请求，允许访问所述目标业务；

若所述第一访问权限信息为所述当前用户不具备访问所述目标业务的权限，则阻断所述业务访问请求，禁止访问所述目标业务，并通过交互界面返回权限不足的提示信息。

可选的，还包括：

根据所述业务访问请求，调用所述软件开发工具包的第二接口，将所述当前用户的业务访问行为记录至本地缓存。

可选的，所述将所述当前用户的业务访问行为记录至本地缓存之后，还包括：

将所述业务访问行为发送至所述零信任控制中心，以便所述零信任控制中心根据所述业务访问行为修改用户权限；

获取修改后的用户权限信息，并根据所述用户权限信息对当前登录用户进行相应的处理。

为实现上述目的，本申请提供了一种业务访问控制系统，包括：

请求接收模块，用于接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；

权限获取模块，用于通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；

权限判断模块，用于根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。

为实现上述目的，本申请提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现前述公开的任一种业务访问控制方法的步骤。

为实现上述目的，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述公开的任一种业务访问控制方法的步骤。

通过以上方案可知，本申请提供的一种业务访问控制方法，包括：接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。由上可知，本申请提供简单通用的软件开发工具包，该软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地，其能够与任何业务系统整合，可对各种业务系统进行访问权限控制，从而可以解决各种各样的业务系统的适配问题，无需针对不同业务系统进行单独的开发，有效节省了开发的成本和时间。

本申请还公开了一种业务访问控制系统及一种电子设备和一种计算机可读存储介质，同样能实现上述技术效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请实施例的一种业务访问控制方法所适用的硬件组成框架示意图；

图2为本申请实施例公开的一种业务访问控制方法的流程图；

图3为本申请实施例公开的业务访问控制方法的一种具体实施方式的流程图；

图4为本申请实施例公开的传统技术中业务无法访问时的显示界面；

图5为本申请实施例公开的一种具体地业务无法访问时的显示界面；

图6为本申请实施例公开的另一种业务访问控制方法的流程图；

图7为本申请实施例公开的又一种业务访问控制方法的流程图；

图8为本申请实施例公开的请求权限信息的具体流程示意图；

图9为本申请实施例公开的记录用户访问行为的流程示意图；

图10为本申请实施例公开的一种业务访问控制系统的结构图；

图11为本申请实施例公开的一种电子设备的结构图；

图12为本申请实施例公开的另一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在现有技术中，通常是基于应用进行访问权限控制，即根据业务系统的特征，例如web应用或隧道应用在零信任系统控制中心添加不同的应用，控制中心在评估用户的信任等级后和网络代理服务器交互，以阻断或放行指定的应用访问请求。然而，在这种方式下，难以适配各种各样的业务系统。以web应用为例，有些业务系统以域名区分应用，有些以端口进行区分，有些以路径进行区分，甚至还有基于url参数进行区分的业务系统。

为了便于理解，先对本申请的业务访问控制对应的方案所适用的硬件组成框架进行介绍。参见图1所示，该硬件组成框架可以包括：用户终端10、业务系统20和零信任控制中心30，用户终端10、业务系统20和零信任控制中心30之间通过网络40通信连接。上述用户终端10、业务系统20和零信任控制中心30中均可以进一步包含有处理器、存储器、通信接口、输入单元、显示器以及通信总线等元件，且处理器、存储器、通信接口、输入单元、显示器、均通过通信总线完成相互间的通信。

具体地，图1中的用户终端10可以包括但不限于智能手机、平板电脑、穿戴式设备和台式计算机等数据处理设备。用户终端10用于接收用户根据需求下发的业务访问请求，并将业务访问请求发送至对应的业务系统20。

本申请中，业务系统20具体可以是指用于实现单一业务的专用服务器，也可以是集成了多种业务功能的服务器，可以包括但不限于云服务器、物理服务器和虚拟服务器等。当业务系统20接收到业务访问请求后，将首先确定当前业务访问请求对应的目标业务，并调用软件开发工具包的第一接口，以获取对应的访问权限信息，以便根据访问权限信息判断是否允许响应当前业务访问请求。需要说明的是，上述软件开发工具包预先从零信任控制中心30下载所有访问权限信息，将所有访问权限信息缓存至本地。可以理解的是，上述零信任控制中心30可以为使用了零信任体系的服务器，能够有效地防止数据泄露。

需要指出的是，本申请中的网络40可以根据实际应用过程中的网络状况和应用需求来确定，既可以是无线通讯网络，如移动通讯网络或wifi网络等，也可以是有线通讯网络；既可以是广域网，在情况允许时也可以采用局域网。

图2为本申请实施例公开的一种业务访问控制方法的流程图，如图2所示，包括：

s101：接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；

本申请实施例中，用户可向业务系统发起业务访问请求，当业务系统接收到业务访问请求之后，将对业务访问请求进行解析，以确定当前业务访问请求对应的目标业务，即当前业务访问请求是访问哪个业务。

s102：通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；

需要说明的是，本申请实施例中，各个业务系统预先配置了统一的接口，即通过上述接口可调用软件开发工具包。软件开发工具包一般指一些特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。在具体实施中，上述软件开发工具包具体用于预先从零信任控制中心获取所有访问权限信息，将所有访问权限信息缓存至本地，并提供第一接口，以便各个业务系统能够通过调用第一接口获取缓存在本地的当前用户针对目标业务的第一访问权限信息，即可根据第一访问权限信息判断当前用户是否具备访问目标业务的权限。

具体地，获取当前用户针对所述目标业务的第一访问权限信息的过程可以具体包括：通过调用软件开发工具包的第一接口，根据目标业务的标识信息在本地缓存中查找是否存在对应的第一访问权限信息；如果否，则向零信任控制中心发送权限获取请求，以接收第一访问权限信息并缓存在本地。参见图3所示，当用户试图访问业务系统时，向业务系统发起访问请求，业务系统将调用共享信任sdk(softwaredevelopmentkit，软件开发工具包)的接口判断该访问请求对应的业务是否允许访问；共享信任sdk为提供统一调用接口的工具包，其用于从零信任控制中心下载并缓存权限信息，可用于多个业务系统的共享使用。若通过共享信任sdk查找到本地缓存中不存在当前访问请求对应的权限信息，则共享信任sdk向零信任控制中心请求权限信息，以接收零信任控制中心返回的请求权限信息，将其缓存至本地后返回至业务系统，以便业务系统根据权限信息判断是否允许响应访问请求，即确定需要阻断访问请求或放行访问请求。

在具体实施中，共享信任sdk会根据客户业务系统的不同有对应不同的实现，例如javascript版本的实现、php版本的实现等。其可以提供业务系统获取信任等级的接口，业务系统判断指定子业务是否可以访问的接口，以及业务系统监听信任等级变化的接口，以便实时响应信任等级变更事件。共享信任sdk内部可利用缓存机制预先缓存所有访问权限信息，避免每次都需要访问零信任控制中心；并且可以建立共享信任sdk与零信任控制中心之间的长连接，用于实时监听零信任控制中心的信任等级变化。可以理解的是，现有基于应用进行访问权限控制的方式，无法管控到业务系统内的具体业务，而是以业务系统为单位，从而无法实现精细化的权限控制。为此，本申请实施例为每个业务创建对应的标识，并预先设置有各个用户针对每个业务的权限信息，从而可精细化的针对各种业务进行权限控制，例如，若某业务系统内包含普通的办公业务和敏感的知识产权管理业务，为确保信息安全，需要保证用户在访问知识产权管理业务时具备更高的信任等级，通过本申请实施例提供的方式，为各种业务设置对应不同的权限，在用户访问系统时通过业务标识获取相应的权限信息，实现精细化的权限控制管理。

s103：根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。

在本步骤中，根据上述第一访问权限信息，即可判断能否响应当前业务访问请求。若第一访问权限信息为当前用户具备访问目标业务的权限，则直接放行业务访问请求，允许目标业务；若第一访问权限信息为当前用户不具备访问目标业务的权限，则阻断业务访问请求，禁止访问目标业务，并通过交互界面返回权限不足的提示信息。

在现有技术方案中，参见图4所示，由于基于应用的访问权限控制系统与业务系统没有任何联动，导致用户在一个已经授权的业务系统中尝试使用更高信任等级的业务时，将整个页面跳转到控制中心，或直接提示网络不通无法访问，导致用户体验不佳。由此，本申请实施例可通过hook技术、中间件技术将软件工具开发包和业务系统整合，能够联动地对用户进行相应的提示，如图5所示，可向用户显示需要提升信任等级才能继续进行访问的友好提示信息。

通过以上方案可知，本申请提供的一种业务访问控制方法，包括：接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。由上可知，本申请提供简单通用的软件开发工具包，该软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地，其能够与任何业务系统整合，可对各种业务系统进行访问权限控制，从而可以解决各种各样的业务系统的适配问题，无需针对不同业务系统进行单独的开发，有效节省了开发的成本和时间。

本申请实施例公开了一种业务访问控制方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体的：

参见图6，本申请实施例提供的另一种业务访问控制方法的流程图，如图6所示，包括：

s201：获取当前登录系统的用户信息；

s202：通过调用软件开发工具包的第一接口，获取每个用户针对所有业务的第二访问权限信息；

s203：根据所述第二访问权限信息确定每个用户不具备访问权限的目标业务，并在每个用户对应的交互界面对所述目标业务进行灰化处理；

传统技术中，由于业务系统与零信任控制中心没有联动，因此将显示内部的所有业务，即便有一些业务是无法访问的，因此无法提前直观地告知用户无法访问的业务，造成用户体验不佳。作为一种优选的实施方式，本申请实施例在接收用户发起的业务访问请求之前，首先调用软件开发工具包的第一接口，获取每个用户针对所有业务的第二访问权限信息，即可根据第二访问权限信息确定出每个用户具备访问权限的业务和不具备访问权限的业务。进一步地，可以对用户不具备访问权限的目标业务在该用户对应的交互界面进行灰化处理，以使用户提前可视化地获知哪些业务无法访问，需要提升信任等级才能继续访问。

s204：接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；

s205：通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；

s206：根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。

本申请实施例公开了一种业务访问控制方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体的：

参见图7，本申请实施例提供的又一种业务访问控制方法的流程图，如图7所示，包括：

s301：接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；

s302：通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；

s303：根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应；

s304：获取所述软件开发工具包发送的权限变更通知；所述权限变更通知为所述软件开发工具包通过长轮询方式向所述零信任控制中心请求得到最新权限信息之后发送的变更通知；

s305：根据所述权限变更通知判断是否需要对当前登录系统的用户进行强制下线处理或推送权限变更的提示信息。

本申请实施例中，软件开发工具包在预先从零信任控制中心下载所有权限信息之后，还会通过长轮询方式不断向零信任控制中心请求最新权限信息。若零信任控制中心存在最新的权限信息，则直接返回至软件开发工具包；若零信任控制中心当前不存在最新的权限信息，则挂起软件开发工具包的请求。若请求超时或发生权限更新事件，则零信任控制中心返回相应的更新事件或超时事件。当软件开发工具包接收到权限更新事件之后，将清除本地对应的权限信息缓存，并向业务系统发送权限变更通知，以便业务系统根据权限变更进行相应的处理，例如：对在线用户进行强制下线处理，或显示权限变更的友好提示信息等。

图8为一种具体实施方式下共享信任模型sdk向零信任控制中心请求权限信息的流程图。如图8所示，共享信任模型sdk可以按照固定的时间周期定时触发向零信任控制中心发送信息获取请求，以请求零信任控制中心最新的事件。若零信任控制中心存在需要派发的事件，则直接返回至共享信任模型sdk；若零信任控制中心不存在需要派发的事件，则挂起共享信任模型sdk的请求等待事件。当事件发生或等待超时之后，零信任控制中心将会返回相应的事件或超时事件。在共享信任模型sdk接收到事件之后，若该事件为权限变更事件，则清除本地对应的权限信息，缓存最新的权限信息，并根据最新的权限信息向业务系统发送权限信息变更通知，以便业务系统根据最新的权限信息对当前登录用户进行相应的处理。

在上述任一实施例的基础上，如图9所示，本申请实施例还可以进一步根据用户发起的业务访问请求调用软件开发工具包的第二接口，将该业务访问请求对应的业务访问行为记录至本地缓存。软件开发工具包可进一步将业务访问行为发送至零信任控制中心，以便零信任控制中心根据业务访问行为修改用户权限，具体可以分析业务访问行为，评估当前用户访问行为中存在的风险，进而调整用户信任等级，对用户的权限进行修改。在修改用户权限之后，将修改后的用户权限信息发送至业务系统进行更新，以便业务系统根据最新用户权限信息对当前登录的用户进行相应的处理。

下面对本申请实施例提供的一种业务访问控制系统进行介绍，下文描述的一种业务访问控制系统与上文描述的一种业务访问控制方法可以相互参照。

本申请实施例提供的一种业务访问控制系统的结构图如图10所示，具体包括：

请求接收模块401，用于接收用户发起的业务访问请求，并确定所述业务访问请求对应的目标业务；

权限获取模块402，用于通过调用软件开发工具包的第一接口，获取当前用户针对所述目标业务的第一访问权限信息；所述软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地；

权限判断模块403，用于根据所述第一访问权限信息判断是否允许对所述业务访问请求进行响应。

关于上述模块401至403的具体实施过程可参考前述实施例公开的相应内容，在此不再进行赘述。

本申请还提供了一种电子设备，参见图11，本申请实施例提供的一种电子设备的结构图，如图11所示，包括：

存储器100，用于存储计算机程序；

处理器200，用于执行所述计算机程序时可以实现上述实施例所提供的步骤。

具体的，存储器100包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令，该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。处理器200在一些实施例中可以是一中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器或其他数据处理芯片，为电子设备提供计算和控制能力，执行所述存储器100中保存的计算机程序时，可以实现前述任一实施例公开的业务访问控制方法的步骤。

在上述实施例的基础上，作为优选实施方式，参见图12，所述电子设备还包括：

输入接口300，与处理器200相连，用于获取外部导入的计算机程序、参数和指令，经处理器200控制保存至存储器100中。该输入接口300可以与输入装置相连，接收用户手动输入的参数或指令。该输入装置可以是显示屏上覆盖的触摸层，也可以是终端外壳上设置的按键、轨迹球或触控板，也可以是键盘、触控板或鼠标等。

显示单元400，与处理器200相连，用于显示处理器200处理的数据以及用于显示可视化的用户界面。该显示单元400可以为led显示器、液晶显示器、触控式液晶显示器以及oled(organiclight-emittingdiode，有机发光二极管)触摸器等。

网络端口500，与处理器200相连，用于与外部各终端设备进行通信连接。该通信连接所采用的通信技术可以为有线通信技术或无线通信技术，如移动高清链接技术(mhl)、通用串行总线(usb)、高清多媒体接口(hdmi)、无线保真技术(wifi)、蓝牙通信技术、低功耗蓝牙通信技术、基于ieee802.11s的通信技术等。

图12仅示出了具有组件100-500的电子设备，本领域技术人员可以理解的是，图12示出的结构并不构成对电子设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

本申请还提供了一种计算机可读存储介质，该存储介质可以包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。该存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述任一实施例公开的业务访问控制方法的步骤。

本申请提供简单通用的软件开发工具包，该软件开发工具包用于预先从零信任控制中心获取所有访问权限信息并缓存至本地，其能够与任何业务系统整合，可对各种业务系统进行访问权限控制，从而可以解决各种各样的业务系统的适配问题，无需针对不同业务系统进行单独的开发，有效节省了开发的成本和时间。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

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