CN110535807A - 一种业务鉴权方法、装置和介质 - Google Patents

Abstract

本发明公开了一种业务鉴权方法、装置和介质，用以提高微服务架构***中业务数据处理的安全性。所述业务鉴权方法，包括：接收业务处理请求，所述业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，所述第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，所述第二鉴权因子为已鉴权通过的鉴权因子；对第一鉴权因子进行鉴权；以及利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；如果确定对第一鉴权因子鉴权通过且对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

Description

一种业务鉴权方法、装置和介质

技术领域

本发明涉及微服务技术领域，尤其涉及一种业务鉴权方法、装置和介质。

背景技术

微服务架构***是一项在云中部署应用和服务的技术，其提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个***架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。

传统的单体架构***中，各个服务进程之间是紧耦合的，各服务进程之间通过内部调用实现流程推进，能够保证业务数据的安全。而在微服务架构***中，各个微服务之间是松耦合的，微服务与微服务之间通过网络请求实现流程的推进，由于网络请求存在易被篡改或者易被攻击的风险，因此，在微服务之间传递的业务数据存在一定的安全性风险。

发明内容

本发明实施例提供一种业务鉴权方法、装置和介质，用以提高微服务架构***中业务数据处理的安全性。

第一方面，提供一种业务鉴权方法，包括：

接收业务处理请求，所述业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，所述第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，所述第二鉴权因子为已鉴权通过的鉴权因子；

对第一鉴权因子进行鉴权；以及

利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；

如果确定对第一鉴权因子鉴权通过且对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

可选地，所述第一电子凭证中还包括至少一项验证信息；以及

利用存储的公钥对所述第一电子凭证进行验证，具体包括：

利用存储的公钥对所述第一电子凭证解密；以及

在满足以下条件时，确定对所述第一电子凭证验证通过：

确定利用存储的公钥对所述第一电子凭证解密成功且针对所述第一电子凭证中包含的每一验证信息均验证通过。

可选地，所述所述业务处理请求中携带有第二用户标识，所述验证信息包括第一用户标识；以及

按照以下流程确定对所述第一用户标识验证通过：

比较所述第二用户标识与所述第一用户标识；

如果所述第二用户标识与所述第一用户标识相同，则确定对所述第一用户标识验证通过。

可选地，所述验证信息包括第一电子凭证的生成时间；以及

按照以下流程确定对所述第一电子凭证的生成时间验证通过：

确定当前时间与所述第一电子凭证的生成时间之间的时间间隔；

如果确定出的时间间隔不超过设定的时间间隔阈值，则确定对所述第一电子凭证的生成时间验证通过。

可选地，所述业务处理请求中携带有第二业务参数，所述验证信息包括第一业务参数；以及

按照以下流程确定对所述第一业务参数验证通过：

比较所述第二业务参数与所述第一业务参数；

如果所述第一业务参数与所述第二业务参数相同，则确定对所述第一业务参数验证通过。

可选地，所述验证信息包括第一电子凭证的类型；以及

按照以下流程确定对第一电子凭证的类型验证通过：

判断第一电子凭证的类型是否存在于预先配置的白名单中；

如果第一电子凭证的类型存在于预先配置的白名单中，则确定对第一电子凭证的类型验证通过。

可选地，本发明实施例提供的业务鉴权方法，还可以包括：

利用存储的私钥根据所述第一电子凭证和所述第一鉴权因子生成第二电子凭证，其中，所述公钥为从电子凭证中心***获取的。

可选地，所述公钥或者私钥为按照以下流程从所述电子凭证中心***获取的：

向所述电子凭证中心***发送密钥获取请求，所述密钥获取请求中携带有请求方的网络地址；

接收所述电子凭证中心***针对所述密钥获取请求发送的公钥或者私钥，其中，所述公钥或者私钥为所述电子凭证中心***根据所述网络地址确定所述请求方具有公钥或者私钥获取权限后发送的，所述公钥或者私钥为所述电子凭证中心***生成的公私钥对中的公钥或者私钥。

可选地，本发明实施例提供的业务鉴权方法，还包括：

向所述电子凭证中心***发送心跳消息，所述心跳消息中携带有本地最新密钥版本或者和/或本地当前生效密钥版本，所述密钥包括所述公钥和/或所述私钥；

接收所述电子凭证中心***发送的响应消息，所述响应消息中携带有更新的最新密钥版本和/或更新的当前生效密钥版本，其中所述更新的最新密钥版本为电子凭证中心***在当前生效密钥版本达到预设的密钥更新周期后更新的，所述更新的当前生效密钥版本为所述电子凭证中心***在确定所有服务获取了最新密钥版本之后更新的。

第二方面，提供一种业务鉴权装置，包括：

第一接收单元，用于接收业务处理请求，所述业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，所述第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，所述第二鉴权因子为已鉴权通过的鉴权因子；

鉴权单元，用于对第一鉴权因子进行鉴权；以及利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；

确定单元，如果确定对第一鉴权因子鉴权通过且对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

可选地，所述第一电子凭证中还包括至少一项验证信息；以及

所述鉴权单元，具体用于利用存储的公钥对所述第一电子凭证进行解密；

所述确定单元，具体用于确定利用存储的公钥对所述第一电子凭证解密成功且针对所述第一电子凭证中包含的每一验证信息均验证通过。

可选地，所述业务处理请求中携带有第二用户标识，所述验证信息包括第一用户标识；

所述确定单元，具体用于比较所述第二用户标识与所述第一用户标识，如果所述第二用户标识与所述第一用户标识相同，则确定对所述第一用户标识验证通过。

可选地，所述验证信息包括第一电子凭证的生成时间；以及

所述确定单元，具体用于确定当前时间与所述第一电子凭证的生成时间之间的时间间隔，如果确定出的时间间隔不超过设定的时间间隔阈值，则确定对所述第一电子凭证的生成时间验证通过。

可选地，所述业务处理请求中携带有第二业务参数，所述验证信息包括第一业务参数；以及

所述确定单元，具体用于比较所述第二业务参数与所述第一业务参数，如果所述第一业务参数与所述第二业务参数相同，则确定对所述第一业务参数验证通过。

可选地，所述验证信息包括第一电子凭证的类型；以及

所述确定单元，用于判断第一电子凭证的类型是否存在于预先配置的白名单中，如果第一电子凭证的类型存在于预先配置的白名单中，则确定对第一电子凭证的类型验证通过。

可选地，本发明实施例提供的业务鉴权装置，还包括：

生成单元，用于利用存储的私钥根据所述第一电子凭证和所述第一鉴权因子生成第二电子凭证，其中，所述公钥为从电子凭证中心***获取的。

可选地，本发明实施例提供的业务鉴权装置，还包括：

获取单元，用于向所述电子凭证中心***发送密钥获取请求，所述密钥获取请求中携带有请求方的网络地址；

第二接收单元，用于接收所述电子凭证中心***针对所述密钥获取请求发送的公钥或者私钥，其中，所述公钥或者私钥为所述电子凭证中心***根据所述网络地址确定所述请求方具有公钥或者私钥获取权限后发送的，所述公钥或者私钥为所述电子凭证中心***生成的公私钥对中的公钥或者私钥。

可选地，本发明实施例提供的业务鉴权装置，还包括：

发送单元，用于向所述电子凭证中心***发送心跳消息，所述心跳消息中携带有本地最新密钥版本或者和/或本地当前生效密钥版本，所述密钥包括所述公钥和/或所述私钥；

第三接收单元，用于接收所述电子凭证中心***发送的响应消息，所述响应消息中携带有更新的最新密钥版本和/或更新的当前生效密钥版本，其中所述更新的最新密钥版本为电子凭证中心***在当前生效密钥版本达到预设的密钥更新周期后更新的，所述更新的当前生效密钥版本为所述电子凭证中心***在确定所有服务获取了最新密钥版本之后更新的。

第三方面，提供一种计算装置，包括至少一个处理器、以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行上述任一方法所述的步骤。

第四方面，提供一种计算机可读介质，其存储有可由计算装置执行的计算机程序，当所述程序在计算装置上运行时，使得所述计算装置执行执行上述任一方法所述的步骤。

本发明实施例提供的业务鉴权方法、装置和介质中，在业务处理请求中除了携带本次业务鉴权所需的第一鉴权因子，还携带有电子凭证，电子凭证中携带有鉴权通过的至少一个第二鉴权因子，对于本次业务处理请求来说相当于对至少两个鉴权因子进行了鉴权，这样，一方面实现了已验证鉴权因子的传递，另一方面，避免了绕过边界的鉴权流程从中间发起业务，提高了业务数据访问的安全性。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例的应用场景示意图；

图2为根据本发明实施方式的部署了微服务的物理机器与电子凭证中心***之间的网络结构示意图；

图3为根据本发明实施方式的电子凭证中心***向Agent发送密钥的流程示意图；

图4为根据本发明实施方式的电子凭证中心***更新密钥的流程示意图；

图5为根据本发明实施方式的物理机器上部署的Agent更新物理机器本地存储的本地最新密钥版本和/或本地当前生效密钥版本的流程示意图；

图6为根据本发明实施方式的密钥控制方法的实施流程示意图；

图7为根据本发明实施方式的更新物理机器本地存储的最新密钥版本和本地当前生效密钥版本的流程示意图；

图8为根据本发明实施方式的鉴权服务生成电子凭证的流程示意图；

图9为根据本发明实施方式的商户API服务中的业务处理流程中，生成电子凭证及验证电子凭证的流程示意图；

图10为根据本发明实施方式的运营平台服务中的业务处理流程中，生成电子凭证及验证电子凭证的流程示意图；

图11为根据本发明实施方式的针对不同安全等级的业务数据生成不同电子凭证的示意图；

图12为根据本发明实施方式的业务鉴权方法的实施流程示意图；

图13为根据本发明实施方式的从电子凭证中心获取密钥的流程示意图；

图14为根据本发明实施方式的更新本地存储的本地最新密钥版本和/或本地当前生效密钥版本的流程示意图；

图15为根据本发明实施方式的业务鉴权装置的结构示意图；

图16为根据本发明实施方式的计算装置的结构示意图。

具体实施方式

为了保证微服务架构***中业务数据访问的安全性，本发明实施例提供了一种业务鉴权方法、装置和介质。

需要说明的是，在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

另外，本发明实施例中的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

如图1所示，其为本发明实施例实施的应用场景示意图，用户10通过终端设备11中安装的客户端访问服务器12，其中，客户端可以为网页的浏览器，也可以为安装于终端设备，如手机，平板电脑等中的应用程序客户端。

终端设备11与服务器12之间通过网络进行通信连接，该网络可以为局域网、蜂窝网和广域网等。终端设备11可以为便携设备(例如：手机、平板、笔记本电脑等)，也可以为个人电脑(PC，Personal Computer)，应用服务器12可以为任何能够提供互联网服务的设备。

其中，用户10利用终端设备11通过向服务器12注册获得用户名，服务器12在用户进行注册成功后存储用户名以及与用户10设置的用户密码作为认证信息，后续用户10利用终端设备11再次登录服务器12时，服务器12向应用客户端返回登录页面，用户在应用客户端显示的登录页面输入认证信息(即用户名和用户密码)并提交给服务器12，服务器12比较用户提交认证信息与自身在用户注册时存储的认证信息是否一致以确定是否允许用户登录。

具体实施时，微服务可以用Docker容器实现，一台物理机器同时运行多个容器，也可以只运行一个容器，每个容器承载一个微服务，以实现复杂的微服务架构。

本发明实施例中，为了提高业务处理过程中业务数据的安全性，各个微服务在执行业务处理请求之前，通过本发明实施例提供的电子凭证来对本次业务处理请求进行鉴权，即对业务处理请求中携带有的电子凭证进行解密和验证，以保证业务处理请求的合法性，有效性和完整性，在对电子凭证鉴权通过后再执行业务处理流程。其中，电子凭证由入口的鉴权服务在用户发起业务处理请求时，对用户身份进行验证，身份验证通过后，利用存储的密钥对电子凭证生成参数进行加密得到电子凭证。电子凭证随着业务处理流程在微服务架构***中传递。

本发明实施例中，电子凭证的生成(加密)和验证(解密)采用RSA非对称加解密来保证电子凭证本身不可伪造，只有需要生成电子凭证的微服务可以获取私钥，需要验证电子凭证的微服务可以获取公钥。

具体实施时，为了保证所有需要验证电子凭证的微服务均能解密电子凭证，用于加解密电子凭证的密钥需要统一控制，基于此，本发明实施例中建立电子凭证中心***统一生成密钥并对密钥的使用进行控制。各个部署有微服务的物理机器通过接入电子凭证中心***，以获取公钥或者私钥。在一个实施例中，部署有微服务的物理机器可以通过部署电子凭证代理(Agent)从与电子凭证中心***进行交互，从电子凭证中心***获取公钥或者私钥。

如图2所示，其为部署了微服务的物理机器与电子凭证中心***之间的网络结构示意图。电子凭证中心***可以提供密钥控制服务和密钥同步服务，其中，密钥控制服务利用RSA算法生成加解密电子凭证的公私钥对，密钥同步服务用于根据物理机器上部署的Agent的请求，向各个物理机器分发公钥或者私钥。Agent从电子凭证中心***获取到密钥之后，将获取的密钥写入物理机器本地共享内存中，其中，部署了生成电子凭证的微服务的物理机器从电子凭证中心***获取私钥，部署了验证电子凭证的微服务的物理机器从电子凭证中心***获取公钥，电子凭证中心***在本地数据库中维护各个物理机器的网络地址与获取密钥权限之间的对应关系，根据物理机器的网络地址来控制密钥(包括公钥和私钥)分发，其中，该网络地址可以为物理机器的IP地址，电子凭证中心***根据物理机器的IP地址来判断物理机器具有获取私钥或者公钥的权限，如果具有获取私钥的权限，则向相应的物理机器下发私钥，如果具有获取公钥的权限，则向相应的物理机器下发公钥。

如表1所示，其为电子凭证中心***维护的物理机器网络地址与获取密钥的权限之间的对应关系示意：

表1

物理机器网络地址	获取密钥的权限
		IP1	公钥
IP2	私钥和公钥
		IP3	公钥
IP4	私钥和私钥
		……	……

具体实施时，部署有微服务中的物理机器上部署的Agent可以按照图3所示的流程从电子凭证中心***获取密钥：

S31、Agent向电子凭证中心***发送密钥获取请求。

具体实施时，电子凭证中心***的密钥控制服务按照设定的周期定期生成公私钥对，并存储于电子凭证中心***本地的密钥数据库中。部署有微服务的物理机器上部署的Agent向电子凭证中心***发送密钥获取请求，该发送的请求中携带有物理机器的网络地址。

S32、电子凭证中心***根据网络地址确定请求方具有的密钥获取权限。

本步骤中，电子凭证中心***可以根据密钥获取请求中携带的物理机器网络地址，查找其对应的密钥权限，以确定该物理机器具有私钥获取权限还是公钥获取权限。

S33、根据确定出的密钥获取权限，获取相应的密钥并发送给请求方。

具体实施时，如果确定该物理机器具有私钥获取权限，则从本地密钥数据库中存储的公私钥对中获取私钥发送给该物理机器上部署的Agent，如果确定该物理机器具有公钥获取权限，则从本地密钥数据库中存储的公私钥对中获取公钥发送给该物理机器上部署的Agent，如果该物理机器同时具有公钥和私钥的获取权限，则从本地密钥数据库存储的公私钥对中获取公私钥发送给该物理机器。

具体实施时，公私钥可以按照机器维度进行分发，部署了微服务的物理机器通过(Agent)定时向电子凭证中心***请求公钥和/或私钥。在一个实施例中，为了保证公私钥的安全性，避免公私钥泄露造成的业务数据被非法篡改或者泄露的风险，电子凭证中心***可以定时更新公私钥对，并根据物理机器上部署的Agent的请求，将更新的密钥下发给相应的Agent。

如图4所示，电子凭证中心***可以按照以下流程更新密钥，包括以下步骤：

S41、电子凭证中心***检查密钥数据库中存储的所有物理机器的当前生效版本是否一致。

本步骤中，可以由电子凭证中心***中的密钥控制服务通过数据访问接口(DAO，Data Access Object)检查密钥数据库中存储的所有物理机器的当前生效版本是否一致。

每个物理机器通过Agent获取了密钥之后，按照设定的周期定期向电子凭证中心***上报其本地存储的本地最新版本的密钥和/或本地当前生效密钥版本，具体实施时，各个物理机器可以通过心跳消息通过密钥同步服务向电子凭证中心***上报上述信息。电子凭证中心***在接收到各个物理机器上报的心跳信息后，更新密钥数据库中存储的各个物理机器对应的其本地存储的本地最新密钥版本和本地当前生效密钥版本。

如表2所示，电子凭证中心***可以按照表2所示的结构存储物理机器本地存储的最新版本的密钥和当前生效版本的密钥。

表2

S42、如果所有物理机器本地当前生效密钥版本一致且当前生效密钥版本达到设定的密钥存储周期，则生成新的密钥对并写入密钥数据库。

具体实施时，如果所有物理机器本地当前生效密钥版本一致，则判断当前生效密钥版本是否达到设定的密钥存储周期。如果判断出当前生效密钥版本达到设定的密钥存储周期，则生成新的密钥对并写入密钥数据库。

具体实施时，如果存在至少一个物理机器本地当前生效密钥版本不一致，则在相应物理机器发送心跳消息上报其本地存储的本地最新密钥版本和/或本地当前生效密钥版本时，向该物理机器发送更新当前生效密钥版本的响应消息。

生成了新的密钥对之后，在物理机器中部署的Agent发送心跳消息时，向Agent下发最新版本的密钥，由此，各个物理机器可以获取到最新版本的密钥并写入物理机器本地共享内存中。在下一次物理机器中部署的Agent发送的心跳消息中携带的物理机器本地最新密钥版本将更新为电子凭证中心***新下发的密钥版本，密钥控制服务更新密钥数据库中存储的相应字段。

S43、密钥控制服务检查所有物理机器是否已获取了最新密钥版本。

本步骤中，密钥控制服务通过DAO检查密钥数据库中存储的各个物理机器上报的其本地最新密钥版本是否为更新后的最新密钥版本。

S44、如果确定所有物理机器均已获取了最新密钥版本，则更新当前生效密钥版本为最新密钥版本。

本步骤中，如果密钥控制服务确定所有物理机器均已获取了最新密钥版本，则更新当前生效密钥版本为最新密钥版本。在更新了当前生效密钥版本为最新密钥版本之后，各个物理机器再次发送心跳消息时，密钥控制服务可以向物理机器返回更新当前生效密钥版本的响应消息，这样，各个物理机器可以获取当前生效密钥版本，并更新物理机器本地当前生效密钥版本，在下一次上报心跳消息时，其中携带的本地当前生效密钥版本即可进行更新。

由于Agent从电子凭证中心拉取密钥是渐进的，在分布式***中无法保证所欲的Agent同时拿到密钥，因此，具体实施时，需要保证密钥的平滑更换：在使用任一版本的私钥作为加密密钥之前，需要保证所有Agent已经获取了该版本的公钥，否则，没有获取该版本公钥的物理机器上部署的微服务无法解密电子凭证；从电子凭证中心***更换私钥开始，部分Agent会先于其他Agent获取到私钥，因此，整个***中可能存在多个版本的私钥加密的电子凭证，因此，需要部署了验证电子凭证的物理机器上保存多个版本的公钥。

基于此，本发明实施例中，各个物理机器中部署的Agent可以按照设定的周期定期向电子凭证中心***上报物理机器本地存储的最新版本密钥和本地当前生效的密钥，如图5所示，其为物理机器上部署的Agent更新物理机器本地存储的本地最新密钥版本和/或本地当前生效密钥版本的流程示意图，包括以下步骤：

S51、Agent向电子凭证***发送心跳消息。

本步骤中，物理机器中部署的Agent按照设定的周期定期向电子凭证中心***中的密钥同步服务发送心跳消息，在发送的心跳消息中携带有物理机器本地存储的本地最新密钥版本和/或本地当前生效密钥版本。

S52、电子凭证中心***更新本地密钥数据库中存储的相应物理机器对应的本地最新密钥版本和/或本地当前生效密钥版本。

本步骤中，密钥同步服务根据物理机器上报的本地最新密钥版本和本地当前失效密钥版本更新密钥数据库中存储的数据。

S53、密钥同步服务从密钥数据库查询更新的最新密钥版本和/或更新的当前生效密钥版本。

本步骤中，密钥同步服务可以按照设定的周期定期从密钥数据库查询是否有更新的最新密钥版本和/或更新的当前生效密钥版本。

S54、密钥数据库向密钥同步服务返回更新的最新密钥版本和/或更新的当前生效密钥版本。

本步骤中，在当前生效密钥达到密钥存储周期时，由密钥控制服务生成更新的密钥，以及在确定所有物理机器均获取了更新后的密钥之后，密钥控制服务更新当前生效密钥版本，并发送给密钥同步服务，由密钥同步服务根据各个物理机器上部署的Agent发送的请求中回复给各物理机器。

S55、密钥同步服务将更新的最新密钥版本和/或更新的当前生效密钥版本发送给Agent。

本步骤中，密钥同步服务将更新的最新密钥版本和/或更新的当前生效密钥版本携带在心跳消息的响应消息中发送给物理机器上部署的Agent。

需要说明的是，本发明实施例中，步骤S55的实施是密钥同步服务根据各个物理机器上部署的Agent发送的请求，在向Agent回复的响应消息中携带更新的最新密钥版本和/或更新的当前生效密钥版本，即由Agent主动向密钥同步服务拉取更新的最新密钥版本和/或更新的当前生效密钥版本。

S56、物理机器上部署的Agent将接收到的更新后的最新密钥版本和/或更新后的当前生效密钥版本写入本地共享内存中。

需要说明的是，上述描述中的密钥包括私钥和公钥，密钥同步服务根据存储的各个物理机器的密钥获取权限向各物理机器分发私钥或者公钥，公钥或者私钥的分发实施流程相同。

如图6所示，其为本发明实施例提供的密钥控制方法的实施流程示意图，包括以下步骤：

S61、接收密钥获取请求。

本步骤中，电子凭证中心***中的密钥同步服务接收物理机器上部署的Agent发送的密钥获取请求，其中携带有请求方即物理机器的网络地址，具体实施时，该网络地址可以为物理机器的IP地址。

S62、根据网络地址确定请求方具有的密钥获取权限，并根据确定出的密钥获取权限向请求方发送相应的密钥。

本步骤中，密钥同步服务查询密钥数据库中存储的网络地址与密钥获取权限之间的对应关系，如果根据网络地址确定请求方具有私钥获取权限，则向请求方发送密钥控制服务生成的公私钥对中的私钥；如果根据网络地址确定请求方具有公钥获取权限，则向请求方发送密钥控制服务生成的公私钥对中的公钥。

具体实施时，为了提高公私钥对的安全性，本发明实施例中，密钥控制服务器可以按照设定的周期定期生成公私钥对。其中，设定的周期可以根据实际需要进行设定，本发明实施例对此不进行限定，例如，该周期可以设定为2天。

如图7所示，本发明实施例中，可以按照以下流程更新物理机器本地存储的最新密钥版本和本地当前生效密钥版本，包括以下步骤：

S71、电子凭证中心***接收请求方发送的心跳消息。

需要说明的是，本实施例中涉及的请求方可以为各个物理机器。本步骤中，物理机器中部署的Agent按照设定的周期向电子凭证中心***的密钥同步服务发送心跳消息，心跳消息中携带有物理机器本地存储的本地最新密钥版本和本地当前生效密钥版本。密钥同步服务更新密钥数据库中存储的相应物理机器对应的本地最新密钥版本和本地当前生效密钥版本。

S72、电子凭证中心***检查所有请求方的本地当前生效密钥版本是否一致，如果是，则执行步骤S73，否则，执行步骤S71。

具体实施时，在每一轮更新后，所有物理机器的本地当前生效密钥版本应该一致，即更新到当前最新密钥版本，如果所有物理机器的本地当前生效密钥版本不一致，则继续等待各个物理机器上报的心跳消息，并在这个过程中通知各个物理机器将本地当前生效密钥更新为当前最新版本密钥。

S73、判断当前生效密钥版本是否达到预设的密钥存储周期，如果是，执行步骤S74，否则，执行步骤S71。

本步骤中，密钥控制服务进一步判断当前生效密钥版本是否达到预设的密钥存储周期，如果是，则生成新的公私钥对。如果否，则循环执行上述流程，直到当前生效密钥达到预设的密钥存储周期。

S74、生成新的公私钥。

在本步骤中，密钥控制服务在生成了新的公私钥对之后，将新生成的公私钥对写入密钥数据库中，密钥同步服务从密钥数据库中获取到更新的最新密钥版本之后，在各个物理机器通过部署的Agent上报心跳消息时，将更新的最新密钥版本携带在响应消息中发送给各个物理机器。各个物理机器之后上报的心跳消息中将携带更新后的最新密钥版本，密钥同步服务根据物理机器上报的心跳消息更新密钥数据库中存储的各个物理机器对应的本地最新密钥版本，密钥控制服务通过检查密钥数据库，确定所有物理机器对应的本地最新密钥版本均一致且更新为当前最新密钥版本之后，更新当前生效密钥版本，并更新密钥数据库中存储的当前生效密钥版本，由密钥同步服务在各个物理机器上报的心跳消息的响应消息中通知各个物理机器更新的当前生效密钥版本。

本发明实施例中，为了保证业务处理过程中业务数据的安全性，在业务***中，通过业务入口的鉴权服务将鉴权结果信息加密生成电子凭证，随着业务处理请求向后续的服务传递，后续服务在接收到业务处理请求后，首先对电子凭证进行解密并进行验证，如果验证通过，则允许执行业务处理流程，以此保证业务处理请求的合法性、有效性和完整性。

基于此，本发明实施例中，业务***入口的鉴权服务可以按照图8所示的流程生成电子凭证，包括以下步骤：

S81、接收业务处理请求。

本步骤中，业务***入口的鉴权服务接收业务处理请求，其中，接收到的业务处理请求中至少携带有鉴权因子。

例如，在商户API验签的应用场景中，在鉴权因子可以为利用第一密钥生成的签名信息。其中，第一密钥可以为用户安装的业务客户端的API(应用程序接口)-key，API-key，该API-key为唯一的，且鉴权服务针对该用户存储有同样的API-key，为了与客户端存储的API-key相区分，本发明实施例中称之为第二密钥。

S82、对业务处理请求中携带的鉴权因子进行鉴权。

延续上例，在商户API验签的应用场景中，鉴权服务查找该商户API对应的API-key，利用查找到的API-key解密接收到的业务处理请求中携带的签名信息，如果解密成功，则确定对鉴权因子的鉴权通过，如果解密失败，则确定对鉴权因子的鉴权不通过。

S83、如果确定鉴权通过，则利用存储的私钥，根据验证信息针对接收到的业务处理请求生成电子凭证。

其中，验证信息可以包括以下至少一项：第一用户标识、第一业务参数、生成电子凭证的时间和电子凭证的类型，其中，第一业务参数可以从业务处理请求中获取。

在生成电子凭证之后，鉴权服务可以在向后续服务发送业务处理请求的同时传递生成的电子凭证，并且伴随着业务处理流程继续传递鉴权服务生成的电子凭证，后续服务根据接收到的电子凭证对业务请求进行鉴权或者验证，鉴权或者验证通过后再执行相应的业务流程。

具体实施时，通过对电子用户标识进行鉴权，后续的服务可以确定业务发起用户是否被篡改，通过对业务参数进行鉴权，后续服务可以检查电子凭证中的业务参数与业务处理请求中的业务参数是否一致，这样，可以避免业务参数被篡改，生成电子凭证的时间可以用于对电子凭证的有效性进行检查，而生成电子凭证的类型可以用于检查生成电子凭证的服务是否符合要求等等。具体实施时，如果确定验证失败，则向请求方返回操作失败的提示消息。

具体实施时，图8所示的电子凭证生成流程可以应用于基于微服务架构***的业务处理流程中，如，运营平台服务、商户API服务和商户平台服务等等。以下分别结合运营平台服务和商户API服务中的业务处理流程为例，对本发明实施例的具体实施过程进行说明。

如图9所示，其为商户API服务中的业务处理流程中，生成电子凭证及验证电子凭证的流程示意图，可以包括以下步骤：

S91、入口服务接收业务处理请求。

其中，接收到的业务处理请求中携带有利用第一密钥生成的签名信息，用户标识和业务参数等信息。其中签名信息用于对发起业务用户的身份进行鉴权。

以商家请求生成订单为例，具体实施时，用户通过扫描图形码或者通过网页在线向商家支付费用时，商家API服务将请求针对本次支付生成支付订单，其中，可以携带有商家标识和支付金额等信息。

在基于微服务架构***中，生成支付订单的业务流程可能由若干个微服务共同完成。本步骤中，商家API服务首先通过入口服务发起业务处理请求，本例中，通过入口服务发起支付订单生成请求。

S92、入口服务向鉴权服务转发业务处理请求。

入口服务在接收到用户发送的业务处理请求之后向鉴权服务转发该业务处理请求，以对对发起业务用户的身份进行鉴权。

S93、鉴权服务判断针对本次业务处理请求的鉴权是否通过，如果是，执行步骤S94，如果否，执行步骤S95。

鉴权服务根据业务处理请求中携带的签名信息对发起业务用户的身份进行鉴权，具体地，鉴权服务可以利用其存储的该商家API对应的第二密钥对签名信息进行解密，如果解密成功，则确定身份鉴权成功，否则确定身份鉴权失败。

S94、鉴权服务利用自身存储的私钥生成电子凭证并发送给入口服务，并执行步骤S96。

本步骤中，鉴权服务可以利用从电子凭证中心***获取的私钥对业务处理请求中携带的用户标识和业务参数进行加密得到电子凭证。

S95、操作失败，流程结束。

S96、入口服务向第二级服务发送业务处理请求。

本步骤中，入口服务向第二级服务发送业务处理请求，其中还携带有鉴权服务生成的电子凭证。

本例中，以第二级服务为普通服务为例，普通服务不涉及敏感数据的操作，则第二级服务可以无需对电子凭证进行验证，直接执行对应的业务流程即可，处理完成后向下一级服务发送业务处理请求，并携带鉴权服务生成的电子凭证。

S97、第二级服务向第三级服务发送业务处理请求。

其中，第二级服务向第三级服务发送业务处理请求中携带有鉴权服务生成的电子凭证。以商户A向用户X发放10元红包为例，即本例中涉及的业务参数包括商户A，用户X，以及红包金额10元。这样，在鉴权服务为本次业务处理请求生成电子凭证时，其中携带的业务参数包括商户A，用户X，以及红包金额10元等关键数据。

以第二级服务在向第三级服务发送业务处理请求时，某恶意服务将业务处理请求篡改为“商户A向用户Y发放100元红包”为例，此时业务处理请求中携带的业务参数包括商户A，用户Y和红包金额100元。恶意服务向篡改了业务处理请求之后，向第三季服务发送篡改后的业务处理请求，其中携带有鉴权服务生成的电子凭证。

S98、第三级服务处理接收到的业务处理请求，并向第四级服务发送业务处理请求。

以第三级服务为普通服务为例，无需对业务处理请求进行鉴权，则第三级业务进行处理后向第四级服务发送业务处理请求，该业务处理请求仍然为篡改后的业务处理请求。

S99、第四级业务根据接收到的电子凭证针对业务处理请求进行验证。

以第四级服务为敏感数据操作服务为例，其需要对接收到的业务处理请求进行验证。第四级服务利用从电子凭证中心***获取的公钥对业务处理请求中携带的电子凭证进行解密，获得原始业务参数，本例中，原始业务参数为商户A，用户X，以及红包金额10元，但是实际接收到的业务处理请求中携带的业务参数为商户A，用户Y和红包金额100元，第四级服务比较电子凭证中携带的业务参数与原始业务参数，发现两者不一致，则拒绝本次业务处理请求，即不允许对敏感数据进行操作，由此，提高了业务数据的安全性。

需要说明的是，业务处理处理流程中涉及的各个微服务，其是否需要针对业务处理请求进行验证可以根据实际需要进行配置，本发明实施例中不对此进行限定，通常，一些涉及用户敏感数据处理的微服务需要对业务处理请求进行鉴权。

如图10所示，其为运营平台服务中的业务处理流程中，生成电子凭证及验证电子凭证的流程示意图，可以包括以下步骤：

S101、入口服务接收业务处理请求。

其中，接收到的业务处理请求中携带有利用第一密钥生成的签名信息，用户标识和业务参数等信息。其中签名信息用于对发起业务用户的身份进行鉴权。

以运营平台的客服请求查询用户信息为例，在基于微服务架构***中，查询用户信息的业务流程可能由若干个微服务共同完成。本步骤中，运营平台客服首先通过入口服务发起业务处理请求，本例中，通过入口服务发起用户信息查询请求。

S102、入口服务向鉴权服务转发业务处理请求。

入口服务在接收到客服发送的业务处理请求之后向鉴权服务转发该业务处理请求，以对对发起业务用户的身份进行鉴权。

S103、鉴权服务判断针对本次业务处理请求的鉴权是否通过，如果是，执行步骤S104，如果否，执行步骤S105。

鉴权服务根据业务处理请求中携带的签名信息对发起业务用户的身份进行鉴权，具体地，鉴权服务可以利用其存储的该运营平台对应的第二密钥对签名信息进行解密，如果解密成功，则确定身份鉴权成功，否则确定身份鉴权失败。

S104、鉴权服务利用自身存储的私钥生成电子凭证并发送给入口服务，并执行步骤S106。

本步骤中，鉴权服务可以利用从电子凭证中心***获取的私钥对业务处理请求中携带的用户标识、生成电子凭证的时间和鉴权服务生成的电子凭证类型进行加密得到电子凭证。

S105、操作失败，流程结束。

S106、入口服务向第二级服务发送业务处理请求。

本步骤中，入口服务向第二级服务发送业务处理请求，其中还携带有鉴权服务生成的电子凭证。

本例中，以第二级服务为普通服务为例，普通服务不涉及敏感数据的操作，则第二级服务可以无需对电子凭证进行验证，直接执行对应的业务流程即可，处理完成后向下一级服务发送业务处理请求，并携带鉴权服务生成的电子凭证。

S107、第二级服务向第三级服务发送业务处理请求。

第二级服务向第三级服务发送的业务处理请求中携带有鉴权服务生成的电子凭证。

S108、第三级服务处理接收到的业务处理请求。

以第三级服务为敏感数据操作服务为例，其需要对接收到的业务处理请求进行验证。第三级服务利用从电子凭证中心***获取的公钥对业务处理请求中携带的电子凭证进行解密，获得其中的用户标识，生成电子凭证的时间和电子凭证类型。第三级服务根据解密得到的验证信息对首先对本次业务处理请求进行验证，例如，第三级服务比较接收到的业务处理请求中携带的用户标识与解密得到的用户标识是否一致，根据当前时间和电子凭证的生成时间判断电子凭证是否有效，以及根据电子凭证类型判断其是否合法等等，具体实施时，不同的服务生成的电子凭证类型可以相同，也可以不同，验证电子凭证的服务根据预先配置的白名单，判断接收到的电子凭证的电子凭证类型是否在白名单中，如果在，则确定对电子凭证类型验证通过，否则，确定对电子凭证类型验证不通过，例如，本例中，如果接收到的电子凭证中为商户API服务的鉴权服务生成的电子凭证，则确定电子凭证类型验证不通过。

具体实施时，如果上述验证均通过，则确定本次业务处理请求的验证通过，允许查询用户信息，如果其中一项不通过，则确定针对本次业务处理请求的验证不通过，不允许查询用户信息。

S109、第三级服务向第四级服务发送业务处理请求。

在发送的业务处理请求中携带有鉴权服务生成的电子凭证。

S1010、第四级服务对接收到的业务处理请求进行处理。

本步骤中，以第四级服务为普通服务为例，第四级服务无需针对本次业务处理请求进行验证，直接执行业务处理流程即可。

S1011、第四级服务向第五级服务发送业务处理请求。

以第五级服务为敏感数据操作服务为例，第五级服务需要根据电子凭证对接收到的业务处理请求进行处理。以某恶意自建服务向第五级服务发送了业务处理请求，商户C充值100元，这种情况下，第五级服务通过验证第四级服务传递的电子凭证即可发现本次业务处理请求为非法请求，确定不允许此次操作。

本发明实施例中，为了进一步地提高业务数据访问的安全性，针对不同安全等级的业务数据设定不同的访问权限，不同的访问权限对应不同数量的鉴权因子。如图11所示，不同的电子凭证类型经过了不同的鉴权流程，并且不同类型的电子凭证之间具有前后依赖关系。例如，生成(4)kTypeMchWebCert类型的电子凭证之前，除了验证商户平台员工操作证书签名，还需要验证(3)kTypeMchWebLogin类型的电子凭证。由于(3)kTypeMchWebLogin类型的电子凭证颁发需要验证商户平台的登录态，因此(4)kTypeMchWebCert类型的电子凭证相当于验证了两个鉴权因子。同理，请求带有(8)kTypeMchOpPasswd类型的电子凭证相当于该请求验证了三个鉴权因子。

为满足业务数据安全等级保护的需求，根据不同的鉴权场景和鉴权因子的数量，将电子凭证类型划分成了多个安全等级。业务可以根据自身数据的安全性需要，对访问这些数据的请求进行安全等级的限制。使用这样的方法，业务只需限制特定的电子凭证类型即可达到等级保护的要求。

基于此，本发明实施例提供了一种业务鉴权方法，如图12所示，可以包括以下步骤：

S121、接收业务处理请求。

其中，接收到的业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，第二鉴权因子为已鉴权通过的鉴权因子。

具体实施时，第一电子凭证至少可以为鉴权服务所生成的电子凭证，而随着业务处理流程在微服务***中传递，第一电子凭证还可以由其他中间服务根据自身所处理业务的业务数据安全等级所生成的电子凭证。例如，图11中，编号为(1)的kTypeMchApiSign商户API验签电子凭证为鉴权服务生成的电子凭证，在下一级服务中，除了需要验证电子凭证(1)以外，还需要验证当前业务处理所需的鉴权因子，即商户API验双向证书，该鉴权因子需要携带在业务处理请求提交。

以商家处理用户提交退款请求为例，第一鉴权因子可以为商家电子支付账户的支付密码，而在接收到商家的退款请求中携带的第一电子凭证，可以为鉴权服务根据商家登录的用户名和用户密码而生成的电子凭证。

S122、对第一鉴权因子进行鉴权。

以商家处理用户提交退款请求为例，当前服务需要验证商家输入的电子支付账户密码是否准确。

S123、利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的。

S124、如果确定对第一鉴权因子鉴权通过且利用存储的公钥对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

在步骤S123和步骤S124中，针对当前接收到的业务处理请求，除了需要对第一鉴权因子进行验证以外，还需要利用存储的公钥对第一电子凭证进行验证，其中，公钥为从电子凭证中心***获取的。如果确定对第一鉴权因子和第一电子凭证的验证均通过，则确定本次业务鉴权通过，允许执行本次业务处理操作，否则，确定鉴权失败，不允许执行本次业务处理操作。

如图11所示，以编号为(8)的电子凭证对应的业务处理请求为商户退款为例，即用户发起退款操作时，需要携带编号为(4)的kTypeMchWebCert商户平台验证书电子凭证和新的鉴权因子：商户操作密码，其中，kTypeMchWebCert商户平台验证书电子凭证中携带有已验证的两个鉴权因子，一个是商户平台验员工操作证书签名，另外一个是商户平台验登录态，即本次退款操作所需要验证的是3个鉴权因子。

在一个实施例中，当前微服务可以利用存储的公钥对接收到的第一电子凭证进行解密，如果解密成功则可以确定对第一电子凭证的验证通过。

在另一实施例中，第一电子凭证中还可以包括以下至少一项验证信息：第一用户标识、第一电子凭证的生成时间、第一业务参数和第一电子凭证的类型。在这种实施方式下，当前微服务在利用存储的公钥对第一电子凭证解密成功后，还可以进一步地对解密时得到的验证信息进行验证，如果所有验证信息均验证成功，则确定对第一电子凭证的验证通过，如果有一项验证信息的验证不通过，则确定验证不通过。

具体实施时，针对第一用户标识，当前微服务可以比较第一用户标识与接收到的用户处理请求中携带的第二用户标识是否相同，如果相同，则确定对第一用户标识的验证通过；针对第一电子凭证的生成时间，当前微服务可以确定当前时间与所述第一电子凭证的生成时间之间的时间间隔，如果确定出的时间间隔不超过设定的时间间隔阈值，则确定对所述第一电子凭证的生成时间验证通过；对于第一业务参数，当前微服务可以比较第一业务参数与接收到的业务处理请求中携带的第二业务参数是否相同，如果相同，则确定对第一业务参数的验证通过；对于生成第一电子凭证的类型，当前微服务可以判断第一电子凭证的类型是否存在于预先配置的白名单中，如果存在，则确定对第一电子凭证的类型验证通过。

具体实施时，当前微服务在对第一鉴权因子和第一电子凭证验证均通过之后，还可以利用存储的私钥根据第一电子凭证和第一鉴权因子生成第二电子凭证，其中，公钥为从电子凭证中心***获取的，以供后续业务鉴权所用。

本发明实施中涉及的密钥可以为从电子凭证中心***获取的。具体实施时，微服务可以按照图13所示的流程从电子凭证中心***获取密钥：

S131、向电子凭证中心***发送密钥获取请求。

具体实施时，微服务通过物理机器中部署的Agent向电子凭证中心***的密钥同步服务发送密钥获取请求，其中，密钥获取请求中携带有请求方的网络地址，本实施例中，密钥获取请求中可以携带有部署了微服务的物理机器的网络地址。

S132、接收电子凭证中心***针对密钥获取请求发送的密钥。

其中，接收到的密钥为电子凭证中心***根据网络地址确定请求方具有的密钥获取权限后发送的，该密钥可以为电子凭证中心***生成的公私钥对。

具体实施时，密钥同步服务在接收到部署了生成电子凭证的服务的物理机器上部署的Agent发送的密钥获取请求之后，根据其中携带的网络地址，查询相应的物理机器的密钥获取权限，本例中，微服务所部署的物理机器可以被配置为具有获取私钥和公钥的权限，因此，密钥同步服务通过数据访问接口(DAO)从密钥数据库中读取公私钥，并将读取的公私钥携带在响应消息中发送给Agent。

Agent接收到私钥和公钥之后，将其本地共享内存中，微服务在需要生成电子凭证时，可以从共享内存中调用私钥；微服务在需要解密电子凭证时，可以从共享内存中调用公钥。

为了保证密钥的安全性，电子凭证中心***可以定期更新密钥，基于此，部署了微服务的物理机器可以按照图14所示的流程更新本地存储的本地最新密钥版本和/或本地当前生效密钥版本：

S141、向电子凭证中心***发送心跳消息，其中携带有本地最新密钥版本和/或本地当前生效密钥版本。

具体实施时，部署了微服务的物理机器中部署的Agent按照设定的周期向电子凭证中心的密钥同步服务发送心跳消息，其中，携带有物理机器本地最新密钥版本和/或本地当前生效密钥版本，密钥同步服务根据Agent上报的心跳消息中携带的信息，更新密钥数据库中存储的该物理机器对应的本地最新密钥版本和/或本地当前生效密钥版本。

S142、接收电子凭证中心***发送的响应消息。

其中，接收到的响应消息中可以携带有更新的最新密钥版本和/或更新的当前生效密钥版本，其中更新的最新密钥版本为电子凭证中心***在当前生效密钥版本达到预设的密钥更新周期后更新的，更新的当前生效版本的密钥为电子凭证中心***在确定所有微服务均获取了最新密钥版本之后更新的，需要说明的是，这里的最新密钥版本包括最新私钥版本和最新公钥版本，即个物理机器根据其密钥获取权限，均已获取了相应权限的最新密钥版本。

其中，电子凭证***更新最新密钥版本和更新当前生效密钥版本的流程可以参见图4和图5所示的流程，这里不再赘述。

本发明实施例提供的业务方法中，在业务处理请求中除了携带本次业务鉴权所需的第一鉴权因子，还携带有电子凭证，电子凭证中携带有鉴权通过的至少一个第二鉴权因子，对于本次业务处理请求来说相当于对至少两个鉴权因子进行了鉴权，这样，一方面实现了已验证鉴权因子的传递，保证验证通过请求是有效、合法且完整的，另一方面，可以对不同请求进行分级控制，避免了***在内部被非法调用，绕过边界的鉴权流程从中间发起业务，防止了外部请求横向越权造成的业务数据访问安全性问题。

基于同一发明构思，本发明实施例中还提供了一种业务鉴权装置，由于上述装置解决问题的原理与上述的业务鉴权方法相似，因此上述装置的实施可以参见方法的实施，重复之处不再赘述。

如图15所示，其为本发明实施例提供的业务鉴权装置的结构示意图，包括：

第一接收单元151，用于接收业务处理请求，所述业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，所述第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，所述第二鉴权因子为已鉴权通过的鉴权因子；

鉴权单元152，用于对第一鉴权因子进行鉴权；以及利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；

确定单元153，如果确定对第一鉴权因子鉴权通过且对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

可选地，所述第一电子凭证中还包括至少一项验证信息；以及

所述鉴权单元，具体用于利用存储的公钥对所述第一电子凭证进行解密；

所述确定单元，具体用于确定利用存储的公钥对所述第一电子凭证解密成功且针对所述第一电子凭证中包含的每一验证信息均验证通过。

可选地，所述业务处理请求中携带有第二用户标识，所述验证信息包括第一用户标识；

所述确定单元，具体用于比较所述第二用户标识与所述第一用户标识，如果所述第二用户标识与所述第一用户标识相同，则确定对所述第一用户标识验证通过。

可选地，所述验证信息包括第一电子凭证的生成时间；以及

所述确定单元，具体用于确定当前时间与所述第一电子凭证的生成时间之间的时间间隔，如果确定出的时间间隔不超过设定的时间间隔阈值，则确定对所述第一电子凭证的生成时间验证通过。

可选地，所述业务处理请求中携带有第二业务参数，所述验证信息包括第一业务参数；以及

所述确定单元，具体用于比较所述第二业务参数与所述第一业务参数，如果所述第一业务参数与所述第二业务参数相同，则确定对所述第一业务参数验证通过。

可选地，所述验证信息包括第一电子凭证的类型；以及

所述确定单元，用于判断第一电子凭证的类型是否存在于预先配置的白名单中，如果第一电子凭证的类型存在于预先配置的白名单中，则确定对第一电子凭证的类型验证通过。

可选地，本发明实施例提供的业务鉴权装置，还包括：

生成单元，用于利用存储的私钥根据所述第一电子凭证和所述第一鉴权因子生成第二电子凭证，其中，所述公钥为从电子凭证中心***获取的。

可选地，本发明实施例提供的业务鉴权装置，还包括：

获取单元，用于向所述电子凭证中心***发送密钥获取请求，所述密钥获取请求中携带有请求方的网络地址；

第二接收单元，用于接收所述电子凭证中心***针对所述密钥获取请求发送的公钥或者私钥，其中，所述公钥或者私钥为所述电子凭证中心***根据所述网络地址确定所述请求方具有公钥或者私钥获取权限后发送的，所述公钥或者私钥为所述电子凭证中心***生成的公私钥对中的公钥或者私钥。

可选地，本发明实施例提供的业务鉴权装置，还包括：

发送单元，用于向所述电子凭证中心***发送心跳消息，所述心跳消息中携带有本地最新密钥版本或者和/或本地当前生效密钥版本，所述密钥包括所述公钥和/或所述私钥；

第三接收单元，用于接收所述电子凭证中心***发送的响应消息，所述响应消息中携带有更新的最新密钥版本和/或更新的当前生效密钥版本，其中所述更新的最新密钥版本为电子凭证中心***在当前生效密钥版本达到预设的密钥更新周期后更新的，所述更新的当前生效密钥版本为所述电子凭证中心***在确定所有服务获取了最新密钥版本之后更新的。

在介绍了本发明示例性实施方式的电子凭证生成及验证和密钥控制方法和装置之后，接下来，介绍根据本发明的另一示例性实施方式的计算装置。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为***、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

在一些可能的实施方式中，根据本发明的计算装置可以至少包括至少一个处理器、以及至少一个存储器。其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行本说明书上述描述的根据本发明各种示例性实施方式的电子凭证生成及验证和密钥控制方法中的步骤。例如，所述处理器可以执行如图12中所示的步骤S121、接收业务处理请求，和步骤S122、对第一鉴权因子进行鉴权、步骤S123、利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；以及步骤S124、如果确定对第一鉴权因子鉴权通过且利用存储的公钥对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

下面参照图16来描述根据本发明的这种实施方式的计算装置160。图16显示的计算装置160仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图16所示，计算装置160以通用计算设备的形式表现。计算装置160的组件可以包括但不限于：上述至少一个处理器161、上述至少一个存储器162、连接不同***组件(包括存储器162和处理器161)的总线163。

总线163表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、***总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器162可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1621和/或高速缓存存储器1622，还可以进一步包括只读存储器(ROM)1623。

存储器162还可以包括具有一组(至少一个)程序模块1624的程序/实用工具1625，这样的程序模块1624包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算装置160也可以与一个或多个外部设备164(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与计算装置160交互的设备通信，和/或与使得该计算装置160能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口165进行。并且，计算装置160还可以通过网络适配器166与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器166通过总线163与用于计算装置160的其它模块通信。应当理解，尽管图中未示出，可以结合计算装置160使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

在一些可能的实施方式中，本发明提供的电子凭证生成及验证和密钥控制方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算装置上运行时，所述程序代码用于使所述计算装置执行本说明书上述描述的根据本发明各种示例性实施方式的电子凭证生成及验证和密钥控制方法中的步骤，例如，所述计算机设备可以执行如图12中所示的步骤S121、接收业务处理请求，和步骤S122、对第一鉴权因子进行鉴权、步骤S123、利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；以及步骤S124、如果确定对第一鉴权因子鉴权通过且利用存储的公钥对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

所述程序产品可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本发明的实施方式的用于电子凭证生成及验证和密钥控制的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

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

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

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

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

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

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种业务鉴权方法，其特征在于，包括：

接收业务处理请求，所述业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，所述第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，所述第二鉴权因子为已鉴权通过的鉴权因子；

对第一鉴权因子进行鉴权；以及

利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；

如果确定对第一鉴权因子鉴权通过且对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

2.如权利要求1所述的方法，其特征在于，所述第一电子凭证中还包括至少一项验证信息；以及

利用存储的公钥对所述第一电子凭证进行验证，具体包括：

利用存储的公钥对所述第一电子凭证解密；以及

在满足以下条件时，确定对所述第一电子凭证验证通过：

确定利用存储的公钥对所述第一电子凭证解密成功且针对所述第一电子凭证中包含的每一验证信息均验证通过。

3.如权利要求2所述的方法，其特征在于，所述业务处理请求中携带有第二用户标识，所述验证信息包括第一用户标识；以及

按照以下流程确定对所述第一用户标识验证通过：

比较所述第二用户标识与所述第一用户标识；

如果所述第二用户标识与所述第一用户标识相同，则确定对所述第一用户标识验证通过。

4.如权利要求2所述的方法，其特征在于，所述验证信息包括第一电子凭证的生成时间；以及

按照以下流程确定对所述第一电子凭证的生成时间验证通过：

确定当前时间与所述第一电子凭证的生成时间之间的时间间隔；

如果确定出的时间间隔不超过设定的时间间隔阈值，则确定对所述第一电子凭证的生成时间验证通过。

5.如权利要求2所述的方法，其特征在于，所述业务处理请求中携带有第二业务参数，所述验证信息包括第一业务参数；以及

按照以下流程确定对所述第一业务参数验证通过：

比较所述第二业务参数与所述第一业务参数；

如果所述第一业务参数与所述第二业务参数相同，则确定对所述第一业务参数验证通过。

6.如权利要求2所述的方法，其特征在于，所述验证信息包括第一电子凭证的类型；以及

按照以下流程确定对第一电子凭证的类型验证通过：

判断第一电子凭证的类型是否存在于预先配置的白名单中；

如果第一电子凭证的类型存在于预先配置的白名单中，则确定对第一电子凭证的类型验证通过。

7.如权利要求1所述的方法，其特征在于，还包括：

利用存储的私钥根据所述第一电子凭证和所述第一鉴权因子生成第二电子凭证，其中，所述公钥为从电子凭证中心***获取的。

8.如权利要求1～7任一权利要求所述的方法，其特征在于，所述公钥或者私钥为按照以下流程从所述电子凭证中心***获取的：

向所述电子凭证中心***发送密钥获取请求，所述密钥获取请求中携带有请求方的网络地址；

接收所述电子凭证中心***针对所述密钥获取请求发送的公钥或者私钥，其中，所述公钥或者私钥为所述电子凭证中心***根据所述网络地址确定所述请求方具有公钥或者私钥获取权限后发送的，所述公钥或者私钥为所述电子凭证中心***生成的公私钥对中的公钥或者私钥。

9.如权利要求8所述的方法，其特征在于，还包括：

向所述电子凭证中心***发送心跳消息，所述心跳消息中携带有本地最新密钥版本或者和/或本地当前生效密钥版本，所述密钥包括所述公钥和/或所述私钥；

接收所述电子凭证中心***发送的响应消息，所述响应消息中携带有更新的最新密钥版本和/或更新的当前生效密钥版本，其中所述更新的最新密钥版本为电子凭证中心***在当前生效密钥版本达到预设的密钥更新周期后更新的，所述更新的当前生效密钥版本为所述电子凭证中心***在确定所有服务获取了最新密钥版本之后更新的。

10.一种业务鉴权装置，其特征在于，包括：

第一接收单元，用于接收业务处理请求，所述业务处理请求中携带有第一电子凭证和本次业务处理所需的第一鉴权因子，所述第一电子凭证中携带有本次业务处理所需的至少一个第二鉴权因子，所述第二鉴权因子为已鉴权通过的鉴权因子；

鉴权单元，用于对第一鉴权因子进行鉴权；以及利用存储的公钥对所述第一电子凭证进行验证，其中，所述公钥为从电子凭证中心***获取的；

确定单元，如果确定对第一鉴权因子鉴权通过且对所述第一电子凭证验证通过，则确定本次业务处理请求鉴权通过。

11.一种计算装置，其特征在于，其特征在于，包括至少一个处理器、以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行权利要求1～9任一权利要求所述方法的步骤。

12.一种计算机可读介质，其特征在于，其存储有可由计算装置执行的计算机程序，当所述程序在计算装置上运行时，使得所述计算装置执行权利要求1～9任一所述方法的步骤。