一种业务消息转发的方法、装置及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种业务消息转发的方法，一种业务消息转发的装置，一种计算机可读存储介质和一种计算机程序产品。

背景技术

随着互联网的发展，越来越多的业务通过网络交互数据信息。为了保障传输过程中数据的安全性，通过由发送方对业务消息中数据加密后再进行传输，由接收方解密数据。但现有技术对数据的加解密与业务的耦合度高，随着业务复杂度越来越高，业务自身维护数据安全的成本越来越高，降低了业务效率。

发明内容

针对上述现有技术，本发明实施例公开一种业务消息转发的方法，可以在无需增加业务自身维护安全成本的情况下，保障数据的安全。

鉴于此，本申请实施例提出一种业务消息转发的方法，该方法包括：

拦截业务消息，所述业务消息包括路径信息；

判断所述业务消息所属的服务ID是否记录在事先获得的风险配置信息中，如果已记录在所述风险配置信息中，则确定风险验证结果为所述业务消息属于风险请求；如果未记录在所述风险配置信息中，则确定所述风险验证结果为所述业务消息不属于风险请求；

判断所述业务消息包括的所述路径信息是否已记录在事先获得的资源配置信息中，如果已记录在所述资源配置信息中，则确定资源验证结果为所述业务消息中的数据属于要求安全保障的数据；如果未记录在所述资源配置信息中，则确定所述资源验证结果为所述业务消息中的数据不属于要求安全保障的数据；

根据所述风险验证结果判断所述业务消息是否属于风险请求，如果所述业务消息属于风险请求，则中断所述业务消息转发，退出本流程；如果所述业务消息不属于风险请求，则继续执行；

根据所述资源验证结果判断是否需要对所述业务消息进行密文处理；如果需要进行密文处理，则执行密文处理，根据密文处理结果重构所述业务消息，并转发重构后的业务消息；如果不需要进行密文处理，则直接转发所述业务消息。

进一步地，

所述根据所述资源验证结果判断是否需要对所述业务消息进行密文处理的步骤包括：

根据所述资源验证结果判断所述业务消息中的数据是否属于要求安全保障的数据，如果所述业务消息中的数据属于要求安全保障的数据，则确定需要对所述业务消息进行密文处理，如果所述业务消息中的数据不属于要求安全保障的数据，则确定不需要对所述业务消息进行密文处理。

进一步地，

所述如果业务消息不属于风险请求后，该方法进一步包括：执行令牌处理过程，使得所述业务消息由令牌保护，所述令牌处理过程包括令牌签发过程或令牌验证过程。

进一步地，

所述风险配置信息是事先从资源管理中心获取的风险配置信息，且在监听到所述风险配置信息发生变更时，获取更新的风险配置信息；

所述资源配置信息是事先从所述资源管理中心获取的资源配置信息，且在监听到所述资源配置信息发生变更时，获取更新的资源配置信息。

进一步地，

所述业务消息为请求方发送给服务方的业务请求消息，所述密文处理为加密处理；所述执行密文处理的步骤包括：将所述业务请求消息中的数据传输给加密处理过程，执行所述加密处理过程以获得所述业务请求消息中的数据对应的加密数据；或者，

所述业务消息为所述服务方接收来自所述请求方的所述业务请求消息，所述密文处理为解密处理；所述执行密文处理的步骤包括：将所述业务请求消息中的所述加密数据传输给解密处理过程，执行所述解密处理过程以获得所述业务请求消息中的所述加密数据对应的解密数据；或者，

所述业务消息为所述服务方发送给请求方的业务响应消息，所述密文处理为加密处理；所述执行密文处理的步骤包括：将所述业务响应消息中的数据传输给所述加密处理过程，执行所述加密处理过程以获得所述业务响应消息中的数据对应的加密数据；或者，

所述业务消息为所述请求方接收来自所述服务方的所述业务响应消息，所述密文处理为解密处理过程；所述执行密文处理的步骤包括：将所述业务响应消息中的所述加密数据传输给所述解密处理过程，执行所述解密过程以获得所述业务响应消息中的所述加密数据对应的解密数据。

针对上述现有技术，本发明实施例公开一种业务消息转发的装置，可以在无需增加业务自身维护安全成本的情况下，保障数据的安全。

鉴于此，本申请提供一种业务消息转发的装置，该装置包括：拦截模块、风险验证模块、资源验证模块、第一处理模块、第二处理模块、密文处理模块；

所述拦截模块，用于拦截业务消息，所述业务消息包括路径信息；

所述风险验证模块，用于判断所述业务消息所属的服务ID是否记录在事先获得的风险配置信息中，如果已记录在所述风险配置信息中，则确定风险验证结果为所述业务消息属于风险请求，如果未记录在所述风险配置信息中，则确定所述风险验证结果为所述业务消息不属于风险请求；

所述资源验证模块，用于判断所述业务消息包括的所述路径信息是否已记录在事先获得的资源配置信息中，如果已记录在所述资源配置信息中，则确定资源验证结果为所述业务消息中的数据属于要求安全保障的数据；如果未记录在所述资源配置信息中，则确定所述资源验证结果为所述业务消息中的数据不属于要求安全保障的数据；

所述第一处理模块，用于根据风险验证结果判断所述业务消息是否属于风险请求，如果所述业务消息属于风险请求，则中断所述业务消息转发，退出本流程；如果所述业务消息不属于风险请求，则继续执行第二处理模块；

所述第二处理模块，用于根据资源验证结果判断是否需要对所述业务消息进行密文处理；如果需要进行密文处理，则将所述业务消息发送给密文处理模块执行密文处理，根据密文处理结果重构所述业务消息，并转发重构后的业务消息；如果不需要进行密文处理，则直接转发所述业务消息；

所述密文处理模块，执行密文处理，将密文处理结果返回给所述第二处理模块。

进一步地，

该装置进一步包括：资源管理模块；

所述资源管理模块，用于生成资源配置信息，并在所述资源配置信息发生变更时更新所述资源配置信息；生成风险配置信息，并在所述风险配置信息发生变更时更新所述风险配置信息；

所述风险验证模块进一步用于，在监听到所述风险配置信息发生变更时，从所述资源管理模块获取更新的风险配置信息。

所述资源验证模块进一步用于，在监听到所述资源配置信息发生变更时，从所述资源管理模块获取更新的资源配置信息。

进一步地，

所述第二处理模块在根据所述资源验证结果判断是否需要对所述业务消息进行密文处理时，包括：根据所述资源验证结果判断所述业务消息中的数据是否属于要求安全保障的数据，如果所述业务消息中的数据属于要求安全保障的数据，则确定需要对所述业务消息进行密文处理，如果所述业务消息中的数据不属于要求安全保障的数据，则确定不需要对所述业务消息进行密文处理。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时可实现上述任一项业务消息转发的方法。

本申请实施例还提供一种计算机程序产品，包括计算机指令，所述计算机指令在被处理器执行时实施如上述任一项所述的业务消息转发的方法。

综上所述，本申请实施例方案对业务消息进行拦截，对业务消息进行验证并根据验证结果确定是否需要密文处理，在需要密文处理时进行密文处理，无需密文处理时直接转发，可以保障业务消息中数据的安全。另外，由于本申请实施例的方案与业务自身是解耦合的，消除了业务自身维护数据安全的成本，提高业务的效率。

附图说明

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

图1是本申请实现业务消息转发的方法实施例一的流程图。

图2是本申请实现业务消息转发的方法实施例二的流程图。

图3是本申请实现业务消息转发的方法实施例三的流程图。

图4是本申请实现业务消息转发的装置实施例一的结构示意图。

图5是本申请实现业务消息转发的装置实施例二的结构示意图。

图6是本申请实现业务消息转发的系统实施例结构示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

本申请实施例在业务之外单独设置拦截组件，由拦截组件拦截业务消息，对业务消息进行验证，并根据验证结果确定是否需要进行密文处理，并对需要密文处理的业务消息进行密文处理以后再进行转发。

图1是本申请实现业务消息转发的方法实施例一的流程图。如图1所示，该方法包括：

步骤101：拦截业务消息，所述业务消息包括路径信息。

业务消息是按照业务本身的流程执行产生的消息，但在转发业务消息之前，由本申请实施例设置的拦截组件对业务消息进行拦截。

步骤102：判断业务消息所属的服务ID是否记录在事先获得的风险配置信息中，如果已记录在风险配置信息中，则确定风险验证结果为业务消息属于风险请求；如果未记录在风险配置信息中，则确定风险验证结果为业务消息不属于风险请求。

步骤103：判断业务消息包括的路径信息是否已记录在事先获得的资源配置信息中，如果已记录在资源配置信息中，则确定资源验证结果为业务消息中的数据属于要求安全保障的数据；如果未记录在资源配置信息中，则确定资源验证结果为业务消息中的数据不属于要求安全保障的数据。

上述步骤102～步骤103是对业务消息进行验证的过程，包括风险验证和资源验证。其中，风险验证是指判断业务消息是否来自于攻击者，如果是来自于攻击者，就认为该业务消息具有一定风险。资源验证是指判断业务消息是否敏感信息，如果是敏感信息，则需要对其进行安全保障。

步骤104：根据风险验证结果判断业务消息是否属于风险请求，如果业务消息属于风险请求，则中断业务消息转发，退出本流程；如果业务消息不属于风险请求，则继续执行。

如上所述，如果风险验证结果判断出业务消息属于风险请求，那么说明该业务消息很可能来自于攻击者，可以中断该业务消息的转发。

步骤105：根据资源验证结果判断是否需要对业务消息进行密文处理；如果需要进行密文处理，则执行密文处理，根据密文处理结果重构业务消息，并转发重构后的业务消息；如果不需要进行密文处理，则直接转发业务消息。

如果风险验证结果判断出业务消息不属于风险请求，说明该业务消息不是来自于攻击者，那么进一步根据资源验证结果判断是否需要对业务消息进行密文处理。如果业务消息是敏感信息，需要进行密文处理，且重构业务消息保护其敏感信息。当然，如果业务消息不属于敏感信息，直接转发即可，无需保护。

应用本申请实施例方案，由于对需要安全保障的数据进行密文处理，可以保证业务数据的安全。另外，由于本申请实施例与业务本身解耦合，可以减轻业务维护数据安全的负担，提高业务效率。

为了更好地描述本申请实施例方案，下面用其他实施例进行详细描述。

图2是本申请实现业务消息转发的方法实施例二的流程图。如图2所示，该方法包括：

步骤201：拦截业务消息，所述业务消息包括路径信息。

本步骤与方法实施例一的步骤101相同。

步骤202：判断业务消息所属的服务ID判断是否记录在事先获得的风险配置信息中，如果已记录在风险配置信息中，则确定风险验证结果为所述业务消息属于风险请求；如果未记录在风险配置信息中，则确定风险验证结果为所述业务消息不属于风险请求。

这里所述风险配置信息可以是事先从资源管理中心获取的风险配置信息，且在监听到风险配置信息发生变更时，可以获取更新的风险配置信息。

步骤203：判断业务消息包括的路径信息是否已记录在事先获得的资源配置信息中，如果已记录在资源配置信息中，则确定资源验证结果为所述业务消息中的数据属于要求安全保障的数据；如果未记录在资源配置信息中，则确定资源验证结果为所述业务消息中的数据不属于要求安全保障的数据。

这里所述资源配置信息可以是事先从资源管理中心获取的资源配置信息，且在监听到资源配置信息发生变更时，可以获取更新的资源配置信息。

上述步骤202和步骤203是对业务消息具体的验证。本申请实施例对风险和资源分别进行了验证，与方法实施例一中的步骤102和步骤103相同。

实际应用中，为了防止被非法请求攻击，可以事先记录风险配置信息。这里所述风险配置信息相当于“黑名单”，其中记录有攻击者的服务ID。如果业务消息所属的服务ID是风险配置信息中记录的服务ID，则可以确定该业务消息的请求是风险请求。

实际应用中，为了敏感数据在传输过程中安全性的保障，可以事先记录资源配置信息。这里所述的资源配置信息可以是路径信息，表示访问这些路径信息对应的路径时传输的数据是需要安全保障的敏感数据。如果业务消息中的路径信息是资源配置信息中记录的路径信息，则可以确定业务消息中数据是需要安全保障的数据。

另外，本申请实施例对风险和资源分别进行了验证，实际应用中也可以仅包括其中之一进行验证，或者进一步对其他方面进行验证，并不以本申请实施例的示例作为保护范围的限制。

经过上述步骤202和步骤203验证之后，后续就可以根据验证结果进行相应处理。

步骤204：根据风险验证结果判断业务消息是否属于风险请求，如果业务消息属于风险请求，则执行步骤205；如果业务消息不属于风险请求，则继续执行步骤206。

步骤205：中断业务消息转发，并退出本流程。

对于风险请求的验证结果，本申请实施例将中断业务消息转发，从而防止被攻击。如果不属于风险请求，则需要进一步执行。

步骤206：执行令牌处理过程，使得所述业务消息由令牌保护。

这里所述令牌处理过程包括令牌签发过程或令牌验证过程。如果业务消息是请求方发送的业务请求消息，则需要执行令牌签发过程；如果业务消息是服务方接收业务请求消息，则需要执行令牌验证过程。

步骤207：根据资源验证结果判断业务消息中的数据是否属于要求安全保障的数据，如果业务消息中的数据属于要求安全保障的数据，则确定需要对业务消息进行密文处理，并执行步骤208；如果业务消息中的数据不属于要求安全保障的数据，则确定不需要对业务消息进行密文处理，执行步骤209。

对于资源验证结果，如果需要安全保障，本申请实施例将利用步骤208进行密文处理，如果不需要安全保障，则利用步骤209直接转发。

步骤208：如果需要进行密文处理，则执行密文处理过程，根据密文处理结果重构业务消息，并转发重构后的业务消息。

假设本申请实施例中的业务消息为请求方发送给服务方的业务请求消息，并假设密文处理为加密处理，那么，本步骤208中执行密文处理的步骤具体可以包括：将业务请求消息中的数据传输给加密处理过程，执行加密处理过程以获得业务请求消息中的数据对应的加密数据。

或者，

假设本申请实施例中的业务消息为服务方接收来自请求方的业务请求消息，并假设密文处理为解密处理。那么，本步骤208中执行密文处理的步骤具体可以包括：将业务请求消息中的加密数据传输给解密处理过程，执行解密处理过程以获得业务请求消息中的加密数据对应的解密数据。

或者，

假设本申请实施例中的业务消息为服务方发送给请求方的业务响应消息，并假设密文处理为加密处理。那么，本步骤208中执行密文处理的步骤具体可以包括：将业务响应消息中的数据传输给加密处理过程，执行加密处理过程以获得业务响应消息中的数据对应的加密数据。

或者，

假设本申请实施例中的业务消息为请求方接收来自服务方的业务响应消息，并假设密文处理为解密处理过程。那么，本步骤208中执行密文处理的步骤具体可以包括：将业务响应消息中的加密数据传输给解密处理过程，执行解密过程以获得业务响应消息中的加密数据对应的解密数据。

步骤209：如果不需要进行密文处理，则直接转发业务消息。

应用本申请实施例方案，先对拦截到的业务消息进行风险和资源方面的验证，验证通过后再对需要安全保障的业务消息进行密文处理，不但防止被攻击，而且有效地保证了数据的安全。另外，本申请实施例方案由独立的拦截组件实施，对业务流程本身透明，实现了与业务的解耦合目的，减少业务维护数据安全的成本，提高业务效率。

实际应用中，可以在业务消息收发的两端分别安装上述实施例所述的拦截组件。其中，请求方将发送业务请求消息并接收业务响应消息，服务方将接收业务请求消息和发送业务响应消息。具体地，请求方在发送业务请求消息时，会拦截该业务请求消息，利用上述方法实施例处理之后再转发出去；服务方拦截业务请求消息，利用方法实施例处理之后再进行业务流程的处理；服务方在返回业务响应消息时，会拦截该业务响应消息，利用上述方法实施例处理之后再转发出去；请求方拦截业务响应消息，利用方法实施例处理之后再进行业务流程的处理。总之，无论是请求方还是服务方，无论是业务请求消息还是业务响应消息，都可以采用上述方法实施例的方案对业务消息进行拦截和处理。在整个过程中，拦截业务消息对业务本身是透明的，无感知的，和业务之间没有耦合关系。

假设拦截组件分为拦截模块、风险验证模块、资源验证模块、第一处理模块、第二处理模块、令牌处理模块、密文处理模块、资源管理模块。其中，资源管理模块主要对资源进行管理，包括生成资源配置信息和风险配置信息等。实际应用中，服务ID和路径信息都属于资源，可以由资源管理模块进行统一管理。资源管理模块可以事先将资源配置信息和风险配置信息发送给验证和密文处理模块，以便后续运用。另外，资源管理模块与风险验证模块之间，以及资源管理模块与资源验证模块都可以采用心跳机制保持通信。当资源验证模块监听到所述资源配置信息发生变更时，可以获取更新的资源配置信息。同样，当风险验证模块监听到所述风险配置信息发生变更时，获取更新的风险配置信息。

图3是本申请实现业务消息转发的方法实施例三的流程图。如图3所示，该方法包括：

步骤301：拦截模块拦截业务消息，所述业务消息包括路径信息。

本步骤与方法实施例二的步骤201相同，此处的拦截模块可以是请求方拦截模块，也可以是服务方的拦截模块。实际应用中，拦截模块拦截到业务消息后，可以向验证和密文处理模块发起验证。

实际应用中，拦截模块在此处环节还可以进一步利用设置的控制策略判断是否需要验证，如果需要验证，再执行步骤302后续步骤，如果不需要验证，则直接转发该业务消息。这里的控制策略可以根据实际情况设置，比如可以事先设置“白名单”，根据业务消息中的消息头(header)标识判断是否属于“白名单”中的记录，如果属于，则直接转发业务消息(即转发业务消息明文)，如果不属于，再执行步骤302。当然，实际应用中也可以省略本步骤，要求验证所有业务消息。

步骤302：风险验证模块判断业务消息所属的服务ID判断是否记录在事先获得的风险配置信息中，如果已记录在风险配置信息中，则确定风险验证结果为业务消息属于风险请求；如果未记录在风险配置信息中，则确定风险验证结果为业务消息不属于风险请求。

本步骤与方法实施例二的步骤202相同，此处的风险验证模块可以是请求方的风险验证模块，也可以是服务方的风险验证模块。

步骤303：资源验证模块判断业务消息包括的路径信息是否已记录在事先获得的资源配置信息中，如果已记录在资源配置信息中，则确定资源验证结果为业务消息中的数据属于要求安全保障的数据；如果未记录在资源配置信息中，则确定资源验证结果为业务消息中的数据不属于要求安全保障的数据。

本步骤与方法实施例二的步骤203相同，此处的资源验证模块可以是请求方的资源验证模块，也可以是服务方的资源验证模块。

上述步骤302和步骤303是分别对风险和资源进行验证，实际应用中可以将风险验证结果和资源验证结果返回给拦截模块。

步骤304：第一处理模块根据风险验证结果判断业务消息是否属于风险请求，如果业务消息属于风险请求，则执行步骤305；如果业务消息不属于风险请求，则继续执行步骤306。

本步骤与方法实施例二的步骤204相同，此处的拦截模块可以是请求方的拦截模块，也可以是服务方的拦截模块。本申请实施例在确定业务消息不属于风险请求时，会继续执行步骤306。

步骤305：第一处理模块中断业务消息转发，并退出本流程。

本步骤与方法实施例二的步骤205相同，此处的拦截模块可以是请求方的第一处理模块，也可以是服务方的第一处理模块。

步骤306：令牌处理模块执行令牌处理过程，使得所述业务消息由令牌保护。

但实际应用中，在确定不属于风险请求时，为了保障安全，这里还可以进一步包括：执行令牌(token)处理过程，使得所述业务消息由令牌保护。所述令牌处理过程包括令牌签发过程或者令牌验证过程。具体的，如果是请求方向服务方发送业务请求消息，则可以由请求方的验证和密文处理模块执行令牌签发过程。如果是服务方接收到业务请求消息，则可以由服务方的验证和密文处理模块执行令牌验证过程。实际应用中，验证和密文处理模块在执行令牌签发或验证过程时，可以由第三方服务器实现令牌签发或验证。实际应用中，签发令牌后，可以将令牌放置于业务消息的消息头(header)中。当然，实际应用中如果需要令牌保护，也可以省略步骤306。

步骤307：第二处理模块根据资源验证结果判断业务消息中的数据是否属于要求安全保障的数据，如果业务消息中的数据属于要求安全保障的数据，则确定需要对业务消息进行密文处理，并执行步骤308；如果业务消息中的数据不属于要求安全保障的数据，则确定不需要对业务消息进行密文处理，执行步骤309。

本步骤与方法实施例二的步骤307相同，此处的第二处理模块可以是请求方的第二处理模块，也可以是服务方的第二处理模块。

步骤308：如果需要进行密文处理，则密文处理模块执行密文处理过程，将密文处理结果返回给第二处理模块，第二处理模块根据密文处理结果重构业务消息，转发重构后的业务消息。

本步骤与方法实施例二的步骤208相同，密文处理模块可以是请求方的第二处理模块，也可以是服务方的密文处理模块。也就是说，第二处理模块判断出需要进行密文处理时，将业务消息中的数据发送给密文处理模块，密文处理模块对该数据进行密文处理，再将密文处理结果返回给第二处理模块。

这里所述的密文处理可以加密处理或解密处理，根据实际情况确定。

比如请求方向服务方发送业务请求消息，请求方的拦截模块判断出需要进行加密处理，请求方的拦截模块将业务请求消息中的数据传输给请求方的验证和密文处理模块，由请求方的验证和密文处理模块执行加密处理过程，将数据进行加密，获得加密数据并返回给请求方的拦截模块。

再比如，服务方接收到来自请求方的业务请求消息，服务方的拦截模块判断出需要进行解密处理，服务方拦截模块将业务请求消息中的加密数据传输给服务方的验证和密文处理模块，由服务方的验证和密文处理模块执行解密处理过程，将数据进行解密，获得解密数据返回给服务方的拦截模块。

再比如，服务方向请求方发送业务响应消息，服务方的拦截模块判断出需要进行加密处理，服务方的拦截模块将业务响应消息中的数据传输给服务方的验证和密文处理模块，由服务方的验证和密文处理模块执行加密处理过程，将数据进行加密，获得加密数据并返回给服务方的拦截模块。

再比如，请求方接收到来自服务方的业务响应消息，请求方的拦截模块判断出需要进行解密处理，请求方拦截模块将业务响应消息中的加密数据传输给请求方的验证和密文处理模块，由请求方的验证和密文处理模块执行解密处理过程，将数据进行解密，获得解密数据返回给请求方的拦截模块。

另外，本申请实施例列举了密文处理的两种方式，即加密或解密。实际应用中，密文处理还可能为其他方式，比如密文脱敏和生成用于检索的密文等。其中，密文脱敏是指利用脱敏算法使数据的一部分为明文，另一部分数据为仍然处于加密状态。密文脱敏可以应用在将显示敏感数据的场景，比如显示用户的身份证号码，可以将一部分数据加密，另一部分采用加密方式。生成用于检索的密文是指在以密文存储的数据库检索时，需要将需要检索的数据也采用密文形式表示，才能从数据库中进行检索的场景。但不管是上述哪种方式，都是进行密文处理，其流程和处理方式是类似的。

步骤309：如果不需要进行密文处理，第二处理模块则直接转发业务消息。

本步骤与方法实施例二的步骤209相同，此处的第二处理模块可以是请求方，也可以是服务方的第二处理模块。实际应用中，并不是所有的业务消息都需要安全保障，都需要密文处理。比如有的业务消息不包括数据，这种情况下就不需要密文处理，直接转发即可。

本申请实施例提供一种具体的实现业务消息转发的方案，其方案可以分别由请求方和服务方实现。在本申请实施例中，无论是请求方还是服务方，无法时发送或接收业务请求消息还是业务响应消息，验证和密文处理模块都可以执行风险验证、资源验证以及令牌签发或验证等过程。但是实际应用中，由于在发送和接收业务请求消息时，已经进行了风险验证并进行了令牌的签发和验证，可以表示本次请求是正常和安全的，那么在发送和接收业务响应消息时，就可以省略风险验证，省略令牌的签发和验证。也就是说，在服务方向请求方发送业务响应消息时，服务方的风险验证模块无需执行风险验证，令牌处理模块无需执行令牌签发过程。同样，在请求方接收到业务响应消息时，请求方的风险验证模块无需执行风险验证，令牌处理模块无需执行令牌验证过程，从而提高业务消息转发的效率。

本申请实施例还提供一种业务消息转发的装置。图4是本申请实现业务消息转发的装置实施例一的结构示意图。如图4所示，该装置为请求方或服务方的拦截组件，包括：拦截模块401、风险验证模块402、资源验证模块403、第一处理模块404、第二处理模块405、密文处理模块406。其中：

拦截模块401，用于拦截业务消息，所述业务消息包括路径信息。

风险验证模块402，用于判断业务消息所属的服务ID是否记录在事先获得的风险配置信息中，如果已记录在风险配置信息中，则确定风险验证结果为业务消息属于风险请求，如果未记录在风险配置信息中，则确定风险验证结果为业务消息不属于风险请求。

资源验证模块403，用于判断业务消息包括的路径信息是否已记录在事先获得的资源配置信息中，如果已记录在资源配置信息中，则确定资源验证结果为业务消息中的数据属于要求安全保障的数据；如果未记录在资源配置信息中，则确定资源验证结果为业务消息中的数据不属于要求安全保障的数据。

第一处理模块404，用于根据风险验证结果判断业务消息是否属于风险请求，如果业务消息属于风险请求，则中断业务消息转发，退出本流程；如果业务消息不属于风险请求，则继续执行第二处理模块。

第二处理模块405，用于根据资源验证结果判断是否需要对所述业务消息进行密文处理；如果需要进行密文处理，则将所述业务消息发送给密文处理模块执行密文处理，根据密文处理结果重构所述业务消息，并转发重构后的业务消息；如果不需要进行密文处理，则直接转发所述业务消息。

密文处理模块406，执行密文处理，将密文处理结果返回给所述第二处理模块。

也就是说，拦截模块401拦截业务消息；风险验证模块402根据业务消息所属的服务ID是否记录在风险配置信息中来进行风险验证，得到风险验证结果；资源验证模块403根据路径信息是否已记录在资源配置信息中来进行资源验证，得到资源验证结果；第一处理模块404根据风险验证结果确定是否中断业务消息转发；如果不属于风险请求，则由第二处理模块405根据资源验证结果确定是否对业务消息进行密文处理；如果需要密文处理，则进行密文处理后再进行转发，否则直接转发即可。

应用本申请实施例方案，由于对需要安全保障的数据进行密文处理，可以保证业务数据的安全。另外，由于本申请实施例与业务本身解耦合，可以减轻业务维护数据安全的负担，提高业务效率。

图5是本申请实现业务消息转发的装置实施例二的结构示意图。如图5所示，该装置为请求方或服务方的拦截组件，包括：拦截模块401、风险验证模块402、资源验证模块403、第一处理模块404、第二处理模块405、密文处理模块406。实际应用中，该装置还可以进一步包括资源管理模块407和令牌处理模块408。其中：

拦截模块401，用于拦截业务消息，所述业务消息包括路径信息。

风险验证模块402，用于判断业务消息所属的服务ID是否记录在事先获得的风险配置信息中，如果已记录在风险配置信息中，则确定风险验证结果为业务消息属于风险请求，如果未记录在风险配置信息中，则确定风险验证结果为业务消息不属于风险请求。其中，风险配置信息从资源管理模块407中获取，且在监听到所述风险配置信息发生变更时，从资源管理模块407获取更新的风险配置信息。

资源验证模块403，用于判断业务消息包括的路径信息是否已记录在事先获得的资源配置信息中，如果已记录在资源配置信息中，则确定资源验证结果为业务消息中的数据属于要求安全保障的数据；如果未记录在资源配置信息中，则确定资源验证结果为业务消息中的数据不属于要求安全保障的数据。其中，资源配置信息从资源管理模块407中获取，在监听到所述资源配置信息发生变更时，从资源管理模块407获取更新的资源配置信息。

第一处理模块404，用于根据风险验证结果判断业务消息是否属于风险请求，如果业务消息属于风险请求，则中断业务消息转发，退出本流程；如果业务消息不属于风险请求，则由令牌处理模块408进行令牌处理，再继续执行第二处理模块405。

第二处理模块405，用于根据资源验证结果判断是否需要对所述业务消息进行密文处理；如果需要进行密文处理，则将所述业务消息发送给密文处理模块执行密文处理，根据密文处理结果重构所述业务消息，并转发重构后的业务消息；如果不需要进行密文处理，则直接转发所述业务消息。实际应用中，第二处理模块405在根据资源验证结果判断是否需要对业务消息进行密文处理时，具体可以按照以下方法实现，即：根据资源验证结果判断业务消息中的数据是否属于要求安全保障的数据，如果业务消息中的数据属于要求安全保障的数据，则确定需要对业务消息进行密文处理，如果业务消息中的数据不属于要求安全保障的数据，则确定不需要对业务消息进行密文处理。

密文处理模块406，执行密文处理，将密文处理结果返回给所述第二处理模块405。

资源管理模块407，用于生成资源配置信息，并在所述资源配置信息发生变更时更新所述资源配置信息；生成风险配置信息，并在所述风险配置信息发生变更时更新所述风险配置信息。

令牌处理模块408，用于执行令牌处理过程，使得所述业务消息由令牌保护。

可以理解的是，本申请装置实施例二中的拦截模块401、风险验证模块402、资源验证模块403、第一处理模块404、第二处理模块405、密文处理模块406、资源管理模块407、令牌处理模块408可以按照上述各方法实施例实现本申请业务消息的转发。具体地：也就是说，拦截模块401拦截业务消息；风险验证模块402根据业务消息所属的服务ID是否记录在风险配置信息中来进行风险验证，得到风险验证结果；资源验证模块403根据路径信息是否已记录在资源配置信息中来进行资源验证，得到资源验证结果；第一处理模块404根据风险验证结果确定是否中断业务消息转发；如果属于风险请求，则中断转发，推出流程；如果不属于风险请求，先由令牌处理模块408执行令牌处理过程，再由第二处理模块405根据资源验证结果确定是否对业务消息进行密文处理；如果需要密文处理，则进行密文处理后再进行转发，否则直接转发即可。

图6是本申请实现业务消息转发的系统实施例结构示意图。如图6所示，该系统包括请求方601和服务方602。其中，请求方601安装了拦截组件6011，服务方602安装了拦截组件6021。具体地，

当请求方601向服务方602发送业务请求消息时，请求方601的拦截组件6011拦截业务请求消息，利用控制策略判断是否需要验证，分别进行风险验证和资源验证，以及执行令牌签发等处理，具体处理流程可以参考上述方法实施例三。拦截组件6011可能有四种处理结果：第一是无需验证，直接转发业务请求消息的明文；第二是经过风险验证和资源验证，业务请求消息为风险请求，将被中断且退出转发流程；第三是需要密文处理，将进行加密处理，用加密数据替换业务请求消息中的原有数据，重构业务请求消息后再转发；第四是不需要密文处理，直接转发业务请求消息的明文。

当服务方602接收到业务请求消息时，服务方602的拦截组件6021拦截业务请求消息，利用控制策略判断是否需要验证，分别进行风险验证和资源验证，以及执行令牌验证等处理，具体处理流程可以参考上述方法实施例三。拦截组件6021可能有四种处理结果：第一是无需验证，直接转发业务请求消息的明文；第二是经过风险验证和资源验证，业务请求消息为风险请求，将被中断且退出转发流程；第三是需要密文处理，将进行解密处理，用解密数据替换业务请求消息中的加密数据，重构业务请求消息后再转发；第四是不需要密文处理，直接转发业务请求消息的明文。

当服务方602向请求方601发送业务响应消息时，服务方602的拦截组件6021拦截业务响应消息，利用控制策略判断是否需要验证，并进行资源验证，具体处理流程可以参考上述方法实施例三。拦截组件6021可能有三种处理结果：第一是无需验证，直接转发业务响应消息的明文；第二是经过资源验证，需要密文处理，将进行加密处理，用加密数据替换业务响应消息中的原有数据，重构业务响应消息后再转发；第三是不需要密文处理，直接转发业务响应消息的明文。

当请求方601接收到业务响应消息时，请求方601的拦截组件6011拦截业务响应消息，利用控制策略判断是否需要验证，并进行资源验证，具体处理流程可以参考上述方法实施例三。拦截组件6011可能有三种处理结果：第一是无需验证，直接转发业务响应消息的明文；第二是经过资源验证，需要密文处理，将进行解密处理，用解密数据替换业务响应消息中的加密数据，重构业务响应消息后再转发；第三是不需要密文处理，直接转发业务响应消息的明文。

应用本申请实施例方案，请求方和服务方的利用拦截组件可以拦截业务消息，并根据实际情况进行验证或密文处理以保证数据安全，而且其过程与业务本身是解耦的，业务自身无需增加维护数据安全的成本。

本申请实施例还提供一种计算机可读介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时可执行如上所述的业务消息转发的方法。实际应用中，所述的计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或多个程序被执行时，可以实现上述各实施例描述的业务消息转发的方法。根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令在被处理器执行时实施如上述任一实施例所述的业务消息转发的方法。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。