Business access method, device, electronic equipment and computer readable storage medium

Abstract

Embodiments of the present application disclose a service access method and device, electronic equipment and a computer readable storage medium; after receiving a service access request and a service identifier of a target service required to be accessed by the service access request, the embodiments of the present application perform identity verification on a user corresponding to the service access request, obtain risk verification setting information corresponding to the service identifier when the identity verification of the user is passed, then filter out a risk verification logic corresponding to a risk verification logic identifier from a preset risk verification logic set, add the risk verification logic to the risk verification setting information to obtain risk verification strategy configuration information, then verify the service access request according to the risk verification configuration information to obtain a risk verification result, and finally control the user to access the target service based on the risk verification result; the scheme can improve the security of service access.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to a service access method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] In recent years, with the rapid development of internet technology, the number of services on the internet has also increased significantly. Users can access these services through access requests. To ensure the security of the corresponding business resources, access requests are often verified before access can proceed. Existing business access methods primarily involve authenticating the user and sending the authentication result to the business system, whereby each business system performs risk verification on the access request.

[0003] In the process of researching and practicing existing technologies, the inventors of this invention discovered that after user authentication is completed, each business system independently performs risk verification on access requests, resulting in a lack of unified risk control for business access and making it easy to create security gaps. Therefore, this leads to low security for business access. Summary of the Invention

[0004] This invention provides a service access method, apparatus, electronic device, and computer-readable storage medium, which can improve the security of service access.

[0005] A business access method, comprising:

[0006] Receive a service access request and the service identifier of the target service to be accessed by the service access request, and authenticate the user corresponding to the service access request;

[0007] When the user's authentication is successful, the risk verification setting information corresponding to the business identifier is obtained, and the risk verification setting information includes at least one risk verification logic identifier.

[0008] The risk verification logic corresponding to the risk verification logic identifier is selected from the preset risk verification logic set, and the risk verification logic is added to the risk verification setting information to obtain the risk verification configuration information;

[0009] The service access request is verified based on the risk verification configuration information to obtain the risk verification result;

[0010] Based on the risk verification results, control the user's access to the target service.

[0011] Accordingly, embodiments of the present invention provide a service access device, including:

[0012] The receiving unit is used to receive a service access request and the service identifier of the target service to be accessed by the service access request, and to authenticate the user corresponding to the service access request.

[0013] The acquisition unit is used to acquire risk verification setting information corresponding to the business identifier when the user's authentication is successful. The risk verification setting information includes at least one risk verification logic identifier.

[0014] The filtering unit is used to filter out the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set, and load the risk verification logic into the risk verification setting information to obtain risk verification configuration information.

[0015] The verification unit is used to verify the service access request according to the risk verification configuration information and obtain the risk verification result;

[0016] The control unit is used to control the user's access to the target service based on the risk verification result.

[0017] Optionally, in some embodiments, the verification unit may be specifically used to obtain historical risk verification records corresponding to the service access request; and to verify the service access request based on the historical risk verification records and risk verification configuration information to obtain a risk verification result.

[0018] Optionally, in some embodiments, the verification unit may be specifically used to determine the initial risk verification result of the service access request based on the historical risk verification record; extract the access parameters corresponding to the risk verification logic in the risk verification configuration information in the service access request, and verify the access parameters based on the risk verification logic; and fuse the initial risk verification result and the verification result of the access parameters to obtain the risk verification result.

[0019] Optionally, in some embodiments, the verification unit may be specifically used to filter out the risk verification logic corresponding to the historical risk verification record from the risk verification configuration information; extract the target historical risk verification record of the business access request within a preset time range from the historical risk verification record; count the number of verifications corresponding to each type of historical risk verification result in the target historical risk verification record; and substitute the number of verifications into the verification conditions of the risk verification logic corresponding to the risk verification record for verification to obtain the initial risk verification result of the business access request.

[0020] Optionally, in some embodiments, the verification unit may be specifically used to obtain the attribute information of the risk verification logic, and determine the verification path of the risk verification logic based on the attribute information of the risk verification logic; when the verification path is local verification, the access parameters are verified using the risk verification logic; when the verification path is third-party verification, the corresponding access parameters are sent to the verification server for verification based on the risk verification logic, and the verification result corresponding to the access parameters returned by the verification server is received.

[0021] Optionally, in some embodiments, the verification unit may be specifically used to determine the verification type of the risk verification logic and the verification conditions corresponding to the verification type; extract the access parameter value corresponding to the verification type from the access parameters; substitute the access parameter value into the corresponding verification conditions for verification, and obtain the verification result of the access parameters.

[0022] Optionally, in some embodiments, the verification unit can be specifically used to determine that the risk verification result is risky when the initial risk verification result is risky, or when at least one of the verification results of the access parameters is verification failed; and to determine that the risk verification result is risk-free when the initial risk verification result is risk-free and all the verification results of the access parameters are verification passed.

[0023] Optionally, in some embodiments, the filtering unit may specifically identify at least one loading address for loading risk verification logic in the risk verification setting information; determine the loading address corresponding to the risk verification logic according to the type of the loading address; load the risk verification logic to the corresponding loading address in the risk verification setting information to obtain risk verification configuration information.

[0024] Optionally, in some embodiments, the acquisition unit may be specifically used to acquire index information of a risk verification setting information set, wherein the index information is used to indicate the association between the business identifier of the business and the risk verification setting information; when the business identifier exists in the index information, the risk verification setting information corresponding to the business identifier is filtered out from the risk verification setting information set; when the business identifier does not exist in the index information, the preset risk verification setting information is used as the risk verification setting information corresponding to the business identifier.

[0025] Optionally, in some embodiments, the service access device may further include a configuration unit, which may be used to obtain security configuration information of the service, the security configuration information carrying the service identifier of the service; construct risk verification setting information corresponding to the service based on the security configuration information; establish an association between the service identifier of the service and the risk verification setting information; and add the risk verification setting information of the service to the risk verification setting information set.

[0026] Optionally, in some embodiments, the configuration unit may specifically be used to receive a first security configuration request for a service, the first security configuration request carrying a service identifier of the service; generate a configuration page according to the first security configuration request, the configuration page including a preset set of risk verification logic identifiers; receive risk verification logic identifiers selected for the set of risk verification logic identifiers based on the configuration page, and use the selected risk verification logic identifiers and selection order as security configuration information; the step of constructing risk verification setting information corresponding to the service according to the security configuration information includes: combining the selected risk verification logic identifiers according to the selection order to obtain the risk verification setting information corresponding to the service.

[0027] Optionally, in some embodiments, the configuration unit may specifically be used to receive a second security configuration request for a service, the second security configuration request carrying a service identifier of the service and a target risk verification logic corresponding to the service; obtain a preset risk verification logic set according to the second security configuration request; when the target risk verification logic exists in the preset risk verification logic set, obtain the risk verification logic identifier of the target risk verification logic and use the risk verification logic identifier of the target risk verification logic as security configuration information; when the target risk verification logic does not exist in the preset risk verification logic set, add the target risk verification logic to the preset risk verification logic set and generate the risk verification logic identifier of the target risk verification logic in the preset risk verification logic set; the step of constructing risk verification setting information corresponding to the service according to the security configuration information includes: combining the risk verification logic identifiers to obtain the risk verification setting information corresponding to the service.

[0028] Furthermore, embodiments of the present invention also provide an electronic device, including a processor and a memory, wherein the memory stores an application program, and the processor is used to run the application program in the memory to implement the service access method provided in embodiments of the present invention.

[0029] Furthermore, embodiments of the present invention also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the service access methods provided in embodiments of the present invention.

[0030] In this embodiment of the invention, after receiving a service access request and the service identifier of the target service to be accessed, the user corresponding to the service access request is authenticated. When the user's authentication is successful, the risk verification setting information corresponding to the service identifier is obtained. Then, the risk verification logic corresponding to the risk verification logic identifier is selected from a preset risk verification logic set, and the risk verification logic is added to the risk verification setting information to obtain risk verification configuration information. Then, the service access request is verified according to the risk verification configuration information to obtain the risk verification result. Finally, the user's access to the target service is controlled based on the risk verification result. Since this scheme uses different risk verification configuration information for different services, and the risk verification configuration information is derived from specific risk verification logic in a unified preset risk verification logic set, unified risk control of service access can be performed to avoid the formation of security gaps, thus improving the security of service access. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a schematic diagram of a scenario for the service access method provided in an embodiment of the present invention;

[0033] Figure 2 This is a flowchart illustrating the service access method provided in an embodiment of the present invention;

[0034] Figure 3 This is a schematic diagram of the security policy management page provided in an embodiment of the present invention;

[0035] Figure 4 This is a schematic diagram of the security policy configuration page provided in an embodiment of the present invention;

[0036] Figure 5 This is another schematic diagram of the service access process provided in an embodiment of the present invention;

[0037] Figure 6 This is a schematic diagram of the risk verification strategy framework provided in an embodiment of the present invention;

[0038] Figure 7 This is a schematic diagram of the data structure of the index information provided in the embodiments of the present invention;

[0039] Figure 8 This is a schematic diagram illustrating the determination of risk verification results provided in an embodiment of the present invention;

[0040] Figure 9 This is a schematic diagram of the overall framework of the Identity and Access Management System (IAM) provided in this embodiment of the invention;

[0041] Figure 10 This is a schematic diagram of the process of verifying business access requests by the identity recognition and access management system provided in this embodiment of the invention;

[0042] Figure 11 This is a schematic diagram of the structure of the service access device provided in an embodiment of the present invention;

[0043] Figure 12 This is another structural schematic diagram of the service access device provided in an embodiment of the present invention;

[0044] Figure 13 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] This invention provides a service access method, apparatus, electronic device, and computer-readable storage medium. The service access apparatus can be integrated into an electronic device, which may be a server or a terminal, etc.

[0047] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0048] For example, see Figure 1 Taking the integration of a service access device into an electronic device as an example, after receiving a service access request and the service identifier of the target service to be accessed by the service access request, the electronic device authenticates the user corresponding to the service access request. When the user's authentication is successful, it obtains the risk verification setting information corresponding to the service identifier. Then, it filters out the risk verification logic corresponding to the risk verification logic identifier in the risk verification setting information from the preset risk verification logic set, and adds the risk verification logic to the risk verification setting information to obtain risk verification configuration information. Then, it verifies the service access request according to the risk verification configuration information to obtain the risk verification result. Finally, it controls the user's access to the target service based on the risk verification result, thereby achieving the purpose of security control over service access.

[0049] The authentication of users corresponding to business access requests and the verification of business access requests using risk verification configuration information can be performed on the cloud platform, and the risk verification results can also be stored on the cloud platform. A cloud platform, also known as a cloud computing platform, refers to a service that provides computing, network, and storage capabilities based on hardware and software resources. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go.

[0050] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called an IaaS (Infrastructure as a Service) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0051] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS (Infrastructure as a Service) layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0052] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0053] This embodiment will be described from the perspective of a service access device, which can be integrated into an electronic device, such as a server or a terminal. The terminal can include tablet computers, laptops, personal computers (PCs), wearable devices, virtual reality devices, or other smart devices that can access services.

[0054] A business access method, comprising:

[0055] The system receives a business access request and the business identifier of the target business to be accessed by the business access request. It then authenticates the user corresponding to the business access request. When the user's authentication is successful, it obtains the risk verification setting information corresponding to the business identifier. This risk verification setting information includes at least one risk verification logic identifier. It selects the risk verification logic corresponding to the risk verification logic identifier from a preset risk verification logic set and adds the risk verification logic to the risk verification setting information to obtain risk verification configuration information. Based on the risk verification configuration information, it verifies the business access request to obtain the risk verification result. Based on the risk verification result, it controls the user's access to the target business.

[0056] like Figure 2 As shown, the specific process of this service access method is as follows:

[0057] 101. Receive business access requests using the business identifier of the target business to be accessed, and authenticate the user corresponding to the business access request.

[0058] There are several methods for receiving service access requests and the service identifier of the target service. For example, one can directly receive the service access request and the service identifier of the target service sent by the service server corresponding to the target service. Alternatively, one can receive the service access request and the service identifier of the target service to be accessed sent by the client of the user corresponding to the service access request, and so on. Specifically, the methods are as follows:

[0059] (1) Receive the service access request and the service identifier of the target service sent by the service server.

[0060] For example, when the business server corresponding to the target business receives a business access request, the business access device can directly receive the business access request and the business identifier of the target business sent by the business server. Alternatively, the business access device can also receive an authentication request sent by the business server, which is used to authenticate the user corresponding to the business access request. The business access device extracts the business access request and the business identifier of the target business from the authentication request.

[0061] (2) Receive the business access request sent by the client of the user corresponding to the business access request and the business identifier of the target business to be accessed by the business access request.

[0062] For example, the service access device can directly receive a service access request sent by a user through a client and the service identifier of the target service to be accessed by the service access request; or it can receive a service access request sent by a user through a client and obtain the service identifier of the target service to be accessed by the service access request from the service access request; or it can intercept a service access request sent by a user through a client to the service server corresponding to the target service, thereby obtaining the service access request and the service identifier of the target service to be accessed by the service access request.

[0063] After receiving a business access request and the business identifier of the target business, the user corresponding to the business access request can be authenticated. There are several ways to authenticate a user, including the following:

[0064] Based on the business access request, an information channel is established between the client corresponding to the user, and the current identity information input by the user through the information channel is received. When the current identity information is the same as the preset identity information, the user's identity verification is confirmed.

[0065] There are various methods for establishing an information channel between a user and their corresponding client. For example, an information request can be sent to the client, and based on the information request, a long connection or a short connection can be established with the user's client to form an information channel.

[0066] After establishing the information channel, the user's current identity information can be obtained through this channel. There are several ways to obtain the current identity information. For example, the service access device can send information collection page information to the client, so that the client displays the information collection page corresponding to the information collection page information, and receive the account, fixed password, one-time password (OTP), or information entered by the user through the information collection page as the current identity information. Alternatively, the device can send preset information to the user's corresponding client through the information channel. The preset information may include a verification code or other information used to verify identity. Then, the device can receive the SMS or other information containing the preset information returned by the client to obtain the user's current identity information.

[0067] After receiving the user's current identity information, it can be compared with the preset identity information. If the current identity information is the same as the preset identity information, the user's identity verification is successful. If the current identity information is different from the preset identity information, the user's identity verification is unsuccessful.

[0068] When a user's authentication fails, there are several ways to control the user's access to the target service. For example, the user can directly refuse the access request to the target service, or the authentication failure result can be sent to the service server corresponding to the target service, so that the service server refuses the access request to the target service.

[0069] The source of the preset identity information can be various. For example, it can be obtained from the business server corresponding to the target business, or it can be preset information such as the verification code sent to the user's client when authenticating the user, or it can be identity information in a third-party identity information database, which can be an identity information database that shares information with the target business.

[0070] 102. When the user's authentication is successful, obtain the risk verification settings information corresponding to the business identifier.

[0071] The risk verification setting information includes at least one risk verification logic identifier. The risk verification setting information is used to indicate the risk verification logic for performing risk verification on business access requests.

[0072] Specifically, when a user's authentication is successful, the risk verification settings information can be obtained in the following ways:

[0073] For example, index information of a risk verification setting information set can be obtained. This index information is used to indicate the association between business identifiers and risk verification setting information. There are multiple ways to obtain the index information. For example, attribute information of the risk verification setting information set can be obtained, and the index information can be extracted from the attribute information. Alternatively, the business identifier corresponding to each risk verification setting information in the risk verification setting information set can be read, and the index information of the risk verification setting information set can be constructed based on the read business identifier. The risk verification setting information set can contain risk verification setting information corresponding to different businesses. For example, it can include risk verification setting information for instant messaging services, risk verification setting information for live streaming services, risk verification setting information for text processing services, and risk setting information for image processing services, etc. Taking the risk verification setting information for instant messaging services as an example, this risk verification setting information can include setting information consisting of one or more verification methods or verification strategies set by the user for risk verification of business access requests for instant messaging services.

[0074] After obtaining the index information of the risk verification setting information set, it is possible to query whether the business identifier of the target business exists in the index information. When the business identifier exists in the index information, the risk verification setting information corresponding to the business identifier is filtered out in the risk verification setting information set. When the business identifier does not exist in the index information, the preset risk verification setting information is used as the risk verification setting information corresponding to the business identifier.

[0075] The preset risk verification setting information can be any risk verification from the set of risk verification setting information. This preset risk verification setting information is a common risk verification setting information for the business. This means that if the business administrator has not configured the corresponding risk verification configuration information, the business access request will be risk verified according to the risk verification configuration information corresponding to the preset risk verification setting information.

[0076] Optionally, before obtaining the index information of the risk verification setting information set, the risk verification policy configuration information of the business can also be configured. Therefore, before the step "obtaining the index information of the risk verification setting information set", the business access method may also include:

[0077] Obtain the security configuration information of the service, which carries the service identifier. Based on the security configuration, construct the risk verification settings information corresponding to the service, establish the association between the service identifier and the risk verification settings information, and add the service's risk verification settings information to the risk verification settings information set. Specifically, this can be done as follows:

[0078] (1) Obtain the security configuration information of the service.

[0079] Among them, the security configuration information carries the service identifier of the service. The so-called security configuration information can be the security information configured by the service administrator to verify the risk of service access requests.

[0080] There are several ways to obtain security configuration information, including the following:

[0081] A1. Obtain security configuration information through the configuration page.

[0082] For example, a first security configuration request for a service can be received, which carries the service identifier of the service. A configuration page can be generated based on the first security configuration request. The configuration page includes a preset set of risk verification logic identifiers. The selected risk verification logic identifiers are received based on the configuration page, and the selected risk selection logic identifiers and selection order are used as security configuration information.

[0083] There are several ways to generate a configuration page based on the first security configuration request. For example, the service identifier of the service can be extracted from the first security configuration request, the service type of the service can be determined based on the service identifier, the configuration page information corresponding to the service type can be filtered from the preset configuration page information set, and the configuration page can be generated based on the configuration page information. Alternatively, the preset configuration page information can be obtained based on the first security configuration request, and then the configuration page can be generated based on the preset configuration page information, and so on.

[0084] After generating the configuration page, the selected risk verification logic identifiers for the risk verification logic identifier set can be received based on the configuration page. There are several ways to receive them. For example, the configuration page can be sent to the business terminal corresponding to the business, so that the configuration page is displayed on the business terminal, and the risk verification logic identifiers and the selection order corresponding to the selection operation are obtained by the user's selection operation on the configuration page for the risk verification logic identifier set.

[0085] A2. Obtain security configuration information through the target risk verification logic carried in the security configuration request.

[0086] For example, a second security configuration request for a service can be received. This second security configuration request carries the service identifier and the target risk verification logic corresponding to the service. A preset risk verification logic set is obtained according to the second security configuration request. When the target risk verification logic exists in the preset risk verification logic set, the risk verification logic identifier of the target risk verification logic is obtained and used as security configuration information. When the target risk verification logic does not exist in the preset risk verification logic set, the target risk verification logic is added to the preset risk verification logic set, and a risk verification logic identifier of the target risk verification logic in the preset risk verification logic set is generated.

[0087] There are several ways to receive the second security configuration request from a service. For example, information about the security management page can be sent to the service terminal corresponding to the service, so that the security management page is displayed on the service terminal, and the second security configuration request generated after the user performs security configuration on the security management page can be received.

[0088] The security management page can be like this: Figure 3 As shown, it includes a business selection control 31 and a security configuration control 32. The business selection control 31 is used by the business administrator to select the business to be configured on the security configuration page. The security configuration control 32 is used by the business administrator to configure the risk verification corresponding to the business. The security configuration control 32 can perform various operations. For example, it can upload risk verification logic to obtain the target risk verification logic, or it can modify the preset risk verification logic to obtain the target risk verification logic, or it can add logic parameters to the risk verification logic framework to generate the target risk verification logic.

[0089] After the target risk verification logic is generated at the business terminal, it can receive the second security configuration request sent by the business terminal, which carries the target risk verification logic and the business identifier.

[0090] (2) Construct risk verification settings for the business based on the security configuration information.

[0091] For example, there are multiple ways to construct the risk verification settings information corresponding to a business. For instance, the selected risk verification logic identifiers can be combined according to the selection order to obtain the risk verification settings information corresponding to the business. Alternatively, the risk verification logic identifiers of the target risk verification logic can be directly combined to obtain the risk verification settings information corresponding to the business, and so on.

[0092] There are several ways to combine risk verification logic identifiers to obtain the risk verification settings information corresponding to a business. For example, risk verification logic identifiers can be combined to obtain the combined risk verification logic identifiers, and then the risk verification settings information corresponding to the combined risk verification logic identifiers can be filtered from a preset risk verification settings information set to obtain the risk verification settings information corresponding to the business. Alternatively, risk verification logic identifiers can be combined to obtain the combined risk verification logic identifiers, and then the initial risk verification settings information can be obtained. The combined risk verification logic identifiers can be added to the initial risk verification settings information to obtain the risk verification settings information corresponding to the business. Or, risk verification logic identifiers can be directly combined with the initial risk verification settings information to obtain the risk verification settings information corresponding to the business.

[0093] (3) Establish the association between the business identifier and the risk verification setting information of the business, and add the risk verification setting information of the business to the risk verification setting information set.

[0094] For example, a relationship can be established between a business identifier and risk verification settings information, and this relationship can be stored in the form of an index. The business's risk verification settings information is added to a risk verification settings information set, and the index is associated with the risk verification settings information set, thus obtaining the index information for the risk verification settings information.

[0095] 103. Select the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set, and add the risk verification logic to the risk verification settings information to obtain the risk verification configuration information.

[0096] The risk verification configuration information can be configuration information for verifying whether a business access request is risky. This configuration information may include one or more loaded risk verification logics.

[0097] There are several methods to obtain risk verification configuration information, including the following:

[0098] For example, the risk verification logic corresponding to the risk verification logic identifier is selected from the preset risk verification logic set. Then, at least one loading address for loading the risk verification logic is identified in the risk verification setting information. Based on the type of the loading address, the loading address corresponding to the risk verification logic is determined. The risk verification logic is loaded into the corresponding loading address in the risk verification setting information to obtain the risk verification configuration information.

[0099] There are several ways to determine the loading address corresponding to the risk verification logic based on the type of the loading address. For example, you can obtain the logic type corresponding to the loading address, match the logic type corresponding to the loading address with the risk verification logic, and determine the loading address corresponding to each risk verification logic based on the matching result.

[0100] After determining the loading address corresponding to each risk verification logic, the risk verification logic can be loaded into the corresponding loading address in the risk verification settings information. There are several ways to load it. For example, the loading time of each risk verification logic can be determined according to its verification type. Based on the loading time, the risk verification logic can be loaded into the loading address in the risk verification settings information to obtain the risk verification configuration information. Alternatively, the loading order of each risk verification logic can be determined according to its verification type. Based on the loading order, the risk verification logic can be loaded into the loading address in the risk verification settings information to obtain the risk verification configuration information.

[0101] 104. Verify the business access request based on the risk verification configuration information to obtain the risk verification result.

[0102] For example, historical risk verification records corresponding to business access requests can be obtained. Based on these historical risk verification records and risk verification configuration information, the business access requests can be verified to obtain the risk verification results. Specifically, this can be done as follows:

[0103] B1. Obtain historical risk verification records corresponding to business access requests.

[0104] Among them, the historical risk verification record is used to record the verification results of risk verification of business access requests before the current time.

[0105] There are several ways to obtain historical risk verification records, including the following:

[0106] For example, historical risk verification records corresponding to the business access request can be directly obtained from the risk verification record database. For instance, based on the business identifier and terminal identifier carried in the business access request, query conditions can be constructed, and the corresponding risk verification records can be queried in the preset risk verification record database to obtain the historical risk verification records corresponding to the business access request. Alternatively, the attribute information of the business access request can be obtained, and query conditions can be constructed based on this attribute information. The corresponding risk verification records can then be queried in the preset risk verification record database to obtain the historical risk verification records corresponding to the business access request. Alternatively, candidate historical risk verification records corresponding to the target business can be obtained from the risk verification record database, and the historical risk verification records corresponding to the business access request can be selected from these candidate records. For instance, based on the business identifier carried in the business access request, candidate historical risk verification records corresponding to the target business can be selected from the risk verification record database, and the historical risk verification records corresponding to the terminal identifier or user identifier carried in the business access request can be selected from these candidate records to obtain the historical risk verification records corresponding to the business access request.

[0107] B2. Based on historical risk verification records and risk verification configuration information, verify business access requests to obtain risk verification results.

[0108] For example, based on historical risk verification records, the initial risk verification result of a business access request can be determined. Access parameters corresponding to the risk verification logic in the risk verification configuration information can be extracted from the business access request. These access parameters are then verified based on the risk verification logic. Finally, the initial risk verification result and the verification results of the access parameters are merged to obtain the final risk verification result. Specifically, this can be done as follows:

[0109] (1) Determine the initial risk verification result of the business access request based on the historical risk verification records.

[0110] For example, risk verification logic corresponding to historical risk verification records can be filtered out in the risk verification configuration information. Target historical risk verification records within a preset time range can be extracted from the historical risk verification records. The number of verifications corresponding to each type of historical risk verification result can be counted in the target risk verification records. The number of verifications can be substituted into the verification conditions of the risk verification logic corresponding to the risk verification record for verification to obtain the initial risk verification result of the business access request.

[0111] The preset time range can be varied. For example, it can be a specific time period, such as 10 minutes, 1 hour, or 1 day, or it can be multiple specific time periods, such as 1-2 pm and 3-5 pm.

[0112] The types of historical risk verification results can include various categories, such as two categories: risk exists and risk does not exist, or multiple risk levels such as risk level 1, risk level 2 and risk level 3.

[0113] There are several ways to count the number of verifications corresponding to each type of historical risk verification result. For example, you can directly count the number of times the type appears in the target historical risk verification record to get the corresponding number of verifications. Alternatively, you can count the number of verifications for each type of historical risk verification result in the target historical risk verification record according to preset conditions. For example, the preset conditions can be the number of verifications for the same type of risk verification result consecutively, or the number of verifications for the same type of risk verification result within the same period, and so on.

[0114] After calculating the number of verifications corresponding to each type of historical risk verification result, these verification counts can be substituted into the verification conditions of the risk verification logic corresponding to the risk verification record for verification. There are multiple verification methods. For example, taking the number of verifications corresponding to the verification result with risk as an example, the number of verifications can be compared with the quantity threshold corresponding to the verification condition. When the number of verification results with risk within a preset time range exceeds the preset quantity threshold, it can be determined that the business access request has a risk; otherwise, it can be determined that the business access request does not have a risk. Alternatively, the number of verifications can be converted into a verification probability. For example, the ratio of the number of verifications to the total number of verifications can be calculated to obtain the risk ratio of the number of verifications with risk. This risk ratio can be compared with a preset risk ratio threshold. When the risk ratio exceeds the preset risk ratio threshold, it can be determined that the business access request has a risk; otherwise, it can be determined that the business access request does not have a risk. Thus, the initial risk verification result of the business access request can be obtained.

[0115] (2) Extract the access parameters corresponding to the risk verification logic in the risk verification configuration information from the business access request, and verify the access parameters based on the risk verification logic.

[0116] The access parameters can be access information carried in the business access request, such as access address (IP), proxy address (agent), request frequency, custom parameters, and parameters required by the third-party verification server, etc.

[0117] Specifically, the verification of access parameters can be performed as follows:

[0118] For example, the access parameters corresponding to the risk verification logic loaded in the risk verification configuration information are extracted from the business access request. Then, the attribute information of the risk verification logic is obtained, and the verification path of the risk verification logic is determined according to the attribute information of the risk verification logic. When the verification path is local verification, the access parameters corresponding to the risk verification logic are used for verification. When the verification path is third-party verification, the corresponding access parameters are sent to the verification server for verification according to the risk verification logic, and the verification result corresponding to the access parameters returned by the verification server is received.

[0119] There are several ways to extract the access parameters corresponding to the risk verification logic. For example, you can obtain the header data of the business access request, filter out the parameters corresponding to the risk verification logic from the header data, and obtain the access parameters. Alternatively, you can extract the parameter type of the parameter to be verified from the risk verification logic, extract the parameter type corresponding to the parameter from the business access request, and obtain the access parameters corresponding to the risk verification logic.

[0120] There are several ways to determine the verification path of a risk verification logic. For example, one can query the attribute information of the risk verification logic to see if a third-party verification address exists. If a third-party verification address exists, the verification path of the risk verification logic is determined to be third-party verification; otherwise, the verification path is determined to be local verification. Alternatively, one can query the attribute information of the risk verification logic to see if a third-party verification condition exists. A third-party verification condition can be a verification condition that is different from the verification condition corresponding to each risk verification logic in the preset risk verification logic set. If a third-party verification condition exists in the attribute information of the risk verification logic, the verification path is determined to be third-party verification; otherwise, the verification path is determined to be local verification. Another method is to compare the attribute information of the risk verification logic with preset attribute information. If the attribute information of the risk verification logic is the same as the preset attribute information, the verification path is determined to be local verification; otherwise, the verification path is determined to be third-party verification.

[0121] When the verification path of the risk verification logic is local verification, the risk verification logic can also be called built-in risk verification logic. When the verification path of the risk verification logic is third-party verification, the risk verification logic can also be called third-party risk verification logic.

[0122] C1. When the verification path is local verification.

[0123] When the verification path is local verification, there can be multiple ways to verify access parameters. For example, the verification type of the risk verification logic and the verification conditions corresponding to the verification type can be determined. The access parameter value corresponding to the verification type can be extracted from the access parameters, and the access parameter can be substituted into the corresponding verification conditions for verification to obtain the verification result of the access parameters.

[0124] The verification types for risk verification logic can be varied. For example, when the verification method is local verification, the verification types can include blacklist / whitelist verification, request frequency verification, multi-factor combination logic verification, and so on. When the verification method is third-party verification, the verification type can be third-party verification, etc. The verification conditions corresponding to each verification type can also be varied. For example, when the verification type is blacklist / whitelist verification, the corresponding verification condition can be whether the access parameters are on the blacklist or whitelist; when the verification type is request frequency verification, the corresponding verification condition can be a request frequency threshold; when the verification type is multi-factor combination logic verification, the corresponding verification condition can be the decision condition of multi-factor combination logic, and so on.

[0125] After determining the verification type and verification conditions, the access parameter value corresponding to the verification type can be extracted from the access parameters. There are several ways to extract it. For example, when the verification type is blacklist / whitelist verification, the parameter value corresponding to the blacklist / whitelist can be extracted from the access parameters to obtain the access parameter value. When the verification type is request frequency, the request frequency value of the business access request can be extracted from the access parameters to obtain the access parameter value. When the verification type is multi-factor combination logic verification, the parameter value corresponding to the multi-factor combination can be extracted from the access parameters to obtain the access parameter value, and so on.

[0126] After extracting the access parameter values, these values ​​can be substituted into the corresponding verification conditions for verification. Verification methods can include various approaches. For example, when the access parameter value corresponds to a blacklist or whitelist, it is substituted into the corresponding blacklist / whitelist verification condition. If the parameter value meets the verification condition, the business access request is determined to be on the whitelist, thus the blacklist / whitelist verification passes; otherwise, it fails. When the verification type is request frequency verification, the request frequency value is compared with a request frequency threshold. If it does not exceed the threshold, the request frequency verification passes; otherwise, it fails. When the verification type is multi-factor combination logic verification, the parameter values ​​corresponding to the multi-factor combination are substituted into the multi-factor combination verification condition. If the parameter value meets the multi-factor combination verification condition, the multi-factor combination logic verification passes; otherwise, it fails, and so on.

[0127] C2. When the verification path is third-party verification.

[0128] For example, based on the risk verification logic, the corresponding access parameters can be sent to the verification server for verification. There are multiple verification methods. For instance, the verification address of the third-party verification can be extracted from the risk verification logic, and the access parameters corresponding to the risk verification logic can be sent to the verification server so that the verification server can verify the access parameters. Alternatively, the type or identifier of the third-party verification model can be extracted from the risk verification logic, and the verification address corresponding to the third-party verification model can be determined based on the type or identifier of the third-party verification model. The access parameters corresponding to the risk verification logic can then be sent to the verification address so that the verification server can verify the access parameters.

[0129] The specific verification process of the access parameter by the third-party verification model can also be understood as substituting the access parameter value into one or more verification conditions stored in the third-party verification model for verification. If the verification condition is met, the access parameter can be determined to have passed the verification; otherwise, the access parameter can be determined to have failed the verification.

[0130] After the verification server verifies the access parameters, you can receive the verification result corresponding to the access parameters returned by the verification server.

[0131] It should be noted that the risk verification logic used to verify access parameters can be an independent and parallel binary judgment or a multi-factor judgment, etc.

[0132] (3) The initial risk verification results and the access parameter verification results are combined to obtain the risk verification results.

[0133] For example, if the initial risk verification result is that there is a risk, or if at least one of the verification results of the access parameters is that the verification failed, the risk verification result is determined to be that the business access request has a risk; if the initial risk verification result is that there is no risk, and all the verification results of the access parameters are that the verification result of the business access request is determined to be that there is no risk.

[0134] Specifically, determining whether a risk verification result indicates the presence of risk can be understood as follows: when verifying a business access request using historical risk verification records and risk verification logic, if any one of the judgment results is a malicious request, the risk verification result for the business access request can be determined to be risk-averse. Conversely, determining whether a risk verification result indicates the absence of risk can be understood as follows: when verifying a business access request using historical risk verification records and risk verification logic, only if all judgment results are non-malicious requests can the risk verification result for the business access request be determined to be risk-free.

[0135] 105. Control user access to target services based on risk verification results.

[0136] For example, there are several ways to control user access to target services based on risk verification results. These include directly controlling user access to target services, or indirectly controlling user access to target services, as detailed below:

[0137] (1) Directly control users' access to target services.

[0138] For example, when the risk verification result indicates that a business access request is risky, the user's access to the target business can be denied. There are several ways to deny access. For instance, the business access request can be directly intercepted, preventing the user from accessing the target business. This could be done by adding interception parameters to the data packet of the business access request, preventing the request from accessing the target business's server; or by isolating the business access request to a preset isolation area; or by directly setting the access permission of the business access request to inaccessible; or by modifying the access address in the business access request to an empty address or another preset address, preventing the user from accessing the target business through that business access request.

[0139] When the risk verification result indicates that there is no risk in the business access request, the user is allowed to access the target business. For example, an information channel between the user's client and the target business can be built directly based on the business access request. This channel can be a long-connection channel or a short-connection channel between the client and the business server of the target business, so that the user can access the target business through the client.

[0140] (2) Indirectly control users' access to target services.

[0141] For example, the risk verification result can be sent to the business server corresponding to the target service, enabling the business server to control user access to the target service. This control can take several forms; for instance, if the risk verification result indicates a risky access request, the business server can reject the request. Conversely, if the risk verification result indicates a risk-free access request, the business server can allow the request, thus enabling the user to access the target service normally.

[0142] Optionally, the risk verification result can also be sent to the user's corresponding client to indicate whether the user can access the target service.

[0143] Optionally, in one embodiment, the business access device further includes storing the risk verification result of the business access request on a blockchain.

[0144] As described above, after receiving a service access request and the service identifier of the target service to be accessed by the service access request, this embodiment of the invention authenticates the user corresponding to the service access request. When the user's authentication is successful, the risk verification setting information corresponding to the service identifier is obtained. Then, the risk verification logic corresponding to the risk verification logic identifier is selected from the preset risk verification logic set, and the risk verification logic is added to the risk verification setting information to obtain risk verification configuration information. Then, the service access request is verified according to the risk verification configuration information to obtain the risk verification result. Finally, the user's access to the target service is controlled based on the risk verification result. Since this scheme uses different risk verification configuration information for different services, and the risk verification configuration information is derived from specific risk verification logic in a unified preset risk verification logic set, unified risk control of service access can be performed to avoid the formation of security gaps. Therefore, the security of service access can be improved.

[0145] Based on the method described in the above embodiments, the following examples will provide further detailed explanations.

[0146] In this embodiment, the service access device is specifically integrated into an electronic device, the electronic device is a security server, the risk verification setting information is the risk verification strategy framework, the risk verification configuration information is the risk verification strategy, and the risk verification logic includes built-in risk verification logic and third-party risk verification logic. The built-in risk verification logic includes blacklist / whitelist verification logic, frequency request verification logic, and multi-factor combination verification logic as an example for explanation.

[0147] (i) The security server configures the security policy of the business and obtains the security configuration information corresponding to the business.

[0148] (1) The security server obtains the security configuration information of the service.

[0149] For example, there are several ways for a security server to obtain the security configuration information of a service, such as the following:

[0150] D1. The security server obtains security configuration information through the configuration page.

[0151] For example, a business administrator can send a first security policy configuration request to the security server through a configuration terminal. This first security configuration request carries the business identifier of the business. The security server extracts the business identifier from the first security policy configuration request, determines the business type of the business based on the business identifier, filters the configuration page information corresponding to the business type from a preset configuration page information set, and generates a configuration page based on the configuration page information. Alternatively, it can obtain preset configuration page information based on the first security policy configuration request, and then generate a configuration page based on the preset configuration page information. The security server sends the configuration page to the configuration terminal, which displays the configuration page. The business administrator makes a selection operation on the risk verification logic identifier set on the configuration page. The configuration terminal sends the risk verification logic identifiers and selection order selected by the business administrator to the security server. The security server uses the selected risk verification logic identifiers and selection order as security configuration information.

[0152] D2. The security server obtains security configuration information through the target risk verification logic in the security policy configuration request.

[0153] For example, the security server sends information about the security policy management page to the corresponding business terminal, causing the security policy management page to be displayed on the business terminal. The business administrator can then select the business whose security policy needs to be configured by triggering the business selection control on the security policy management page. Next, the security policy configuration control will be triggered, and the security policy configuration page will be displayed on the configuration terminal. Figure 4 As shown, the security policy configuration page can include a security policy selection area 41 and a judgment condition configuration area 42. In the security policy selection area 41, security policies such as blacklists / whitelists, frequency control, multi-factor judgment, historical records, and third-party policies can be selected. In the judgment condition configuration area 42, the selected security policy can be configured. The specific configuration process can include configuring judgment keywords, judgment conditions, judgment values, logical relationships, and judgment operations, etc. After the user completes the configuration in the judgment condition configuration area, the target risk verification logic for the service is generated on the configuration terminal. Then, the configuration terminal triggers the generation of a second security policy configuration request, adding the service identifier and target risk verification logic to the second security policy configuration request, and sending the second security policy configuration request to the security server, enabling the security server to receive the second security policy configuration request.

[0154] The security server obtains a preset risk verification logic set according to the second security policy configuration request. When the target risk verification logic exists in the preset risk verification logic set, it obtains the risk verification logic identifier of the target risk verification logic and uses the risk verification logic identifier of the target risk logic as security configuration information. When the target risk verification logic does not exist in the preset risk verification logic set, it adds the target risk verification logic to the preset risk verification logic set and generates the risk verification logic identifier of the target risk verification logic in the preset risk verification logic set.

[0155] (2) The security server constructs a risk verification strategy framework corresponding to the business based on the security configuration information.

[0156] For example, the security server can combine the selected risk verification logic identifiers according to the selection order to obtain the combined risk verification logic identifiers. Then, it can filter out the risk verification strategy framework corresponding to the combined risk verification logic identifiers from the preset risk verification strategy framework set to obtain the risk verification strategy framework corresponding to the business. Alternatively, the risk verification logic identifiers can be combined to obtain the combined risk verification logic identifiers. Then, the initial risk verification strategy framework can be obtained, and the combined risk verification logic identifiers can be added to the initial risk verification strategy framework to obtain the risk verification strategy framework corresponding to the business. Or, the risk verification logic identifiers can be directly combined with the initial risk verification strategy framework to obtain the risk verification strategy framework corresponding to the business.

[0157] (3) The security server establishes the association between the business identifier and the risk verification strategy framework of the business, and adds the risk verification strategy framework of the business to the risk verification strategy framework set.

[0158] For example, the security server establishes a relationship between a business's business identifier and a risk verification strategy framework, storing this relationship in the form of an index. The business's risk verification strategy framework is added to a risk verification strategy framework collection, and the index is associated with the collection to obtain the index information of the risk verification strategy framework.

[0159] (ii) The security server controls user access to target services based on security configuration information and a risk verification strategy framework.

[0160] like Figure 5 As shown, one business access method has the following specific process:

[0161] 201. The security server receives the service access request with the service identifier of the target service to be accessed by the service access request.

[0162] For example, a security server can directly receive a business access request and the business identifier of the target business sent by a business server. Alternatively, a security server can also receive an authentication request sent by a business server, which is used to authenticate the user corresponding to the business access request. The security server can extract the business access request and the business identifier of the target business from the authentication request.

[0163] The security server can also directly receive service access requests sent by users through clients and the service identifier of the target service to be accessed by the service access request; or, it can receive service access requests sent by users through clients and obtain the service identifier of the target service to be accessed by the service access request from the service access request; or, it can intercept service access requests sent by users through clients to the service server corresponding to the target service, thereby obtaining the service access request and the service identifier of the target service to be accessed by the service access request.

[0164] 202. The security server authenticates the user corresponding to the business access request.

[0165] For example, based on a business access request, the security server sends information collection page information to the client, causing the client to display the information collection page corresponding to the information collection page information. The server receives the user's account, fixed password, one-time password, or information entered by scanning the information collection icon through the information collection page as the current identity information. Alternatively, the server can also send preset information to the user's corresponding client through this information channel. This preset information may include a verification code or other information used to verify identity. Then, the server receives a text message or other form of information containing the preset information returned by the client to obtain the user's current identity information.

[0166] The security server compares the current identity information with the preset identity information. If the current identity information is the same as the preset identity information, the user's identity verification is successful. If the current identity information is different from the preset identity information, the user's identity verification is unsuccessful.

[0167] When a user's authentication fails, the security server can directly reject the service access request to the target service, or it can send the authentication failure result to the service server corresponding to the target service, so that the service server will reject the service access request to the target service.

[0168] 203. When a user's authentication is successful, the security server obtains the risk verification strategy framework corresponding to the business identifier.

[0169] For example, when a user's authentication is successful, the security server obtains the attribute information of the risk verification strategy framework set, extracts the index information from the attribute information, or it can read the business identifier corresponding to each risk verification strategy framework in the risk verification strategy framework set, and construct the index information of the risk verification strategy set based on the read business identifier.

[0170] After obtaining the index information of the risk verification policy framework set, the security server can query the index information to see if a business identifier for the target business exists. If the business identifier exists in the index information, the server filters out the risk verification policy framework corresponding to that business identifier from the risk verification policy framework set. If the business identifier does not exist in the index information, the preset risk verification policy framework is used as the risk verification policy framework corresponding to that business identifier. The acquisition process is as follows: Figure 6 As shown, the data structure of the index information can be as follows: Figure 7 As shown.

[0171] 204. The security server selects the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set, and loads the risk verification logic into the risk verification strategy framework to obtain the risk verification strategy.

[0172] For example, the security server filters out the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set, obtains at least one loading address used to load the risk verification logic in the risk verification strategy framework, obtains the logic type corresponding to the loading address, matches the logic type corresponding to the loading address with the risk verification logic, and determines the loading address corresponding to each risk verification logic based on the matching result.

[0173] After determining the loading address corresponding to each risk verification logic, the security server determines the loading time of each risk verification logic based on its verification type. Based on the loading time, the risk verification logic is loaded into the loading address in the risk verification policy framework to obtain the risk verification policy. Alternatively, the server can determine the loading order of each risk verification logic based on its verification type and load the risk verification logic into the loading address in the risk verification policy framework based on the loading order to obtain the risk verification policy.

[0174] 205. The security server obtains historical risk verification records corresponding to business access requests.

[0175] For example, the security server can directly obtain the historical risk verification records corresponding to the access request of the service from the risk verification record library. Alternatively, it can obtain the candidate historical risk verification records corresponding to the target service from the risk verification records and filter out the historical risk verification records corresponding to the access request of the service from the candidate historical risk verification records.

[0176] 206. The security server determines the initial risk verification result of the business access request based on historical risk verification records.

[0177] For example, the security server filters out the risk verification logic corresponding to historical risk verification records in the risk verification strategy, and extracts the target historical risk verification records of business access requests within a preset time range from the historical risk verification records. Then, the security server directly counts the number of times this type appears in the target historical risk verification records to obtain the corresponding verification count. Alternatively, it can count the verification count of each type of historical risk verification result in the target historical risk verification records according to preset conditions. For example, the preset conditions could be the number of consecutive verifications of the same type of risk verification result, or the number of verifications of the same type of risk verification result within the same period, and so on.

[0178] After the security server tallies the number of verifications corresponding to each type of historical risk verification result, it can compare the number of verifications with the quantity threshold corresponding to the verification conditions. When the number of verification results with risks within a preset time range exceeds the preset quantity threshold, it can be determined that the business access request is risky; otherwise, it can be determined that the business access request is not risky. Alternatively, the number of verifications can be converted into a verification probability. For example, the ratio of the number of verifications to the total number of verifications can be calculated to obtain the risk ratio of verification results with risks. This risk ratio can be compared with a preset risk ratio threshold. When the risk ratio exceeds the preset risk ratio threshold, it can be determined that the business access request is risky; otherwise, it can be determined that the business access request is not risky. Thus, the initial risk verification result of the business access request can be obtained.

[0179] 207. The security server extracts the access parameters corresponding to the risk verification logic from the business access request and verifies the access parameters based on the risk verification logic.

[0180] For example, the security server extracts the access parameters corresponding to the risk verification logic from the business access request. Then, it obtains the attribute information of the risk verification logic and checks if a third-party verification address exists in the attribute information. If a third-party verification address exists, the verification path of the risk verification logic is determined to be third-party verification; otherwise, the verification path is determined to be local verification. Alternatively, the server can check if third-party verification conditions exist in the attribute information. If third-party verification conditions exist, the verification path is determined to be third-party verification; otherwise, the verification path is determined to be local verification. Another approach is to compare the attribute information of the risk verification logic with preset attribute information. If the attribute information matches the preset attribute information, the verification path is determined to be local verification; otherwise, the verification path is determined to be third-party verification. Risk verification logic with a local verification path can be considered built-in risk verification logic, and risk verification logic with a third-party verification path can be considered third-party risk verification logic.

[0181] (1) For the built-in risk verification logic.

[0182] The security server determines the verification type and corresponding verification conditions of the built-in risk verification logic, thereby obtaining built-in risk verification logic such as blacklist / whitelist verification, request frequency verification, and multi-factor combination logic verification, as well as the risk conditions corresponding to these risk verification classes. For example, the security server obtains the risk verification logic identifier of the built-in risk verification logic, and determines the verification type of the risk verification logic based on the risk verification logic identifier. For instance, it compares the risk verification logic identifier with the preset risk verification logic identifier corresponding to the preset verification type. When the risk verification logic identifier is the risk verification logic identifier for blacklist / whitelist verification, the verification type of the risk verification logic can be determined to be blacklist / whitelist verification. Then, the verification conditions corresponding to blacklist / whitelist verification are extracted from the risk verification logic. By analogy, the built-in risk verification logic such as blacklist / whitelist verification, request frequency verification, and multi-factor combination logic verification, as well as the risk conditions corresponding to these risk verification classes, can be obtained.

[0183] The security server extracts the parameter values ​​corresponding to the blacklist / whitelist, the request frequency value of the business access request, and the parameter value corresponding to the multi-factor combination from the access parameters to obtain the access parameter values. Substituting the parameter values ​​corresponding to the blacklist / whitelist into the blacklist / whitelist verification conditions, if the parameter values ​​corresponding to the blacklist / whitelist meet the verification conditions, the business access request is determined to be on the whitelist, thus the blacklist / whitelist verification is considered successful; otherwise, it is considered unsuccessful. The request frequency value is compared with a request frequency threshold. If the request frequency value exceeds the threshold, the request frequency verification is considered unsuccessful; otherwise, it is considered successful. Substituting the parameter values ​​corresponding to the multi-factor combination into the multi-factor combination verification conditions, if the residual value corresponding to the multi-factor combination meets the verification conditions, the multi-factor combination logic verification is considered successful; otherwise, it is considered unsuccessful.

[0184] (2) For third-party risk verification logic.

[0185] For example, a security server can extract the verification address of a third-party verification from the third-party risk verification logic and send the access parameters corresponding to the third-party risk verification logic to the verification server, so that the verification server can verify the access parameters. Alternatively, it can extract the type or identifier of the third-party verification model from the third-party risk verification logic, determine the verification address corresponding to the third-party verification model based on the type or identifier of the third-party verification model, and send the access parameters corresponding to the third-party risk verification logic to the verification address, so that the verification server can verify the access parameters.

[0186] The verification server's verification of access parameters can be understood as substituting the access parameter values ​​into one or more verification conditions stored in the third-party verification model for verification. If the verification conditions are met, the third-party verification is considered successful; otherwise, it is considered unsuccessful. After the verification server verifies the access parameters, the security server can receive the verification result corresponding to the access parameters returned by the verification server.

[0187] 208. The security server merges the initial risk verification result and the access parameter verification result to obtain the risk verification result.

[0188] For example, if the initial risk verification result is that there is a risk, or if at least one of the verification results of the access parameters is that the verification failed, the security server determines that the risk verification result of the business access request is risky; if the initial risk verification result is that there is no risk, and all the verification results of the access parameters are that the verification passed, the security server determines that the risk verification result of the business access request is that there is no risk.

[0189] Specifically, determining whether a risk exists during the risk verification process can be understood as follows: when verifying a business access request using historical risk verification records and the risk verification logic, if any one of the judgment results is a malicious request, the risk verification result for the business access request can be determined as having a risk. Conversely, determining whether a risk does not exist during the risk verification process can be understood as follows: when verifying a business access request using historical risk verification records and the risk verification logic, only if all judgment results are non-malicious requests can the risk verification result for the business access request be determined as having no risk. When the risk verification result indicates a risk exists, a rejection can be returned; when the risk verification result indicates no risk, a pass can be returned. Specifically, it can be done as follows... Figure 8 As shown.

[0190] 209. The security server controls user access to target services based on risk verification results.

[0191] For example, a security server can control user access to target services based on risk verification results in several ways. For instance, it can directly control user access to target services, or it can indirectly control user access to target services, as detailed below:

[0192] (1) The security server directly controls the user's access to the target business.

[0193] For example, when the risk verification result indicates that a business access request is risky, the security server can directly block the business access request, preventing the user from accessing the target business, or modify the access address in the business access request, preventing the user from accessing the target business through that business access request.

[0194] When the risk verification result indicates that there is no risk in the business access request, the security server can directly construct an information channel between the user's client and the target business based on the business access request, enabling the user to access the target business through the client.

[0195] (2) The security server indirectly controls the user's access to the target business.

[0196] For example, the security server sends the risk verification result to the business server corresponding to the target business, enabling the business server to control user access to the target business. For instance, if the risk verification result indicates a risky access request, the business server will deny that access. Conversely, if the risk verification result indicates a safe access request, the business server can allow the request, thus enabling the user to access the target business normally.

[0197] Optionally, the security server can also send the risk verification result to the user's corresponding client to indicate whether the user can access the target service.

[0198] The security server here primarily functions to authenticate users corresponding to business access requests and to perform risk verification on those requests. It can be viewed as an Identity and Access Management (IAM) system. Traditional IAM systems often only have an authentication module, interfacing with various business systems to complete authentication. This solution adds a risk verification module (also known as a risk control module), which can be described as follows: Figure 9 As shown, this module interacts with the identity authentication module through internal calls to achieve configuration-based authentication risk control capabilities on the IAM side. In this solution, taking business A as an example, the administrator of business A configures security configuration information through the configuration page of the management console. This security configuration information can include authentication policies and risk verification policies. Users send business access requests to business system A through a client. The business server corresponding to business system A sends an authentication request to IAM. The IAM system verifies the user's identity based on the authentication request. After successful authentication, it internally calls the risk verification module of business system A. This risk verification module includes a built-in risk verification logic module and a third-party risk verification logic module. The built-in risk verification logic module includes four functional sub-modules: blacklists / whitelists, frequency control policies, multi-factor authentication, and authentication records. The risk verification of the business access request is performed using the historical access records corresponding to the business access request in the authentication records to obtain the initial risk verification result. Then, the system can verify whether a business access request is on a blacklist or whitelist, verify whether the access frequency of a business access request exceeds the frequency limit through frequency control policies, determine whether a business access request meets the multi-factor combination through multi-factor judgment, and send the access parameters of the business access request to a third-party audit server for auditing through a submodule of third-party verification logic. These judgments are all independent and parallel binary judgments. As long as any one of the judgment results determines that the business access request is malicious, the risk of the business access request can be determined. After performing risk verification (judgment) on the business access request, the IAM system can process the business access request itself based on the verification result to control user access to business A, or it can send the verification result to the business server corresponding to business system A, so that business system A can process the business access request itself, thereby controlling user access to business A.

[0199] The risk verification module is divided into a built-in risk verification logic module and a third-party risk verification logic module. The built-in risk verification logic module is responsible for the execution of specific risk verification strategies, while the third-party risk verification logic module interfaces with third-party strategies through external calls. Through synchronous requests, it returns the judgment results of the external third-party risk control strategies, thus expanding the risk verification module.

[0200] The overall process of verifying business access requests through the IAM system can be described as follows: Figure 10 As shown, the process specifically includes receiving a business access request, authenticating the user corresponding to the business access request, and after successful authentication, querying the risk verification policy of the specific business system. The specific query process may involve first querying the risk verification policy framework, then obtaining the risk verification logic corresponding to the risk verification policy framework, loading the risk verification logic into the risk verification policy framework to obtain the risk verification policy, and using the risk verification policy to determine the business access request. If the determination is successful, a pass is returned; if the determination is unsuccessful, a rejection is returned.

[0201] As described above, in this embodiment, after the security server receives the business access request and the business identifier of the target business to be accessed by the business access request, it authenticates the user corresponding to the business access request. When the user's authentication is successful, it obtains the risk verification strategy framework corresponding to the business identifier. Then, it filters out the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set and loads the risk verification logic into the risk verification strategy framework to obtain the risk verification strategy. Then, it verifies the business access request according to the risk verification strategy to obtain the risk verification result. Finally, it controls the user's access to the target business based on the risk verification result. Since this scheme adopts different risk verification strategies for different businesses, and the risk verification strategy is obtained by loading specific risk verification logic from a unified preset risk verification logic set, it can perform unified risk control on business access, avoid the formation of security gaps, and thus improve the security of business access.

[0202] To better implement the above methods, embodiments of the present invention also provide a service access device, which can be integrated into an electronic device, such as a server or terminal, and the terminal may include a tablet computer, a laptop computer, and / or a personal computer.

[0203] For example, such as Figure 11 As shown, the service access device may include a receiving unit 301, an acquiring unit 302, a filtering unit 303, a verification unit 304, and a control unit 305, as follows:

[0204] (1) Receiving unit 301;

[0205] The receiving unit 301 is used to receive a service access request and the service identifier of the target service to be accessed by the service access request, and to authenticate the user corresponding to the service access request.

[0206] For example, receiving unit 301 can specifically be used to receive a business access request sent by a business server and the business identifier of the target business to be accessed by the business access request; or, it can receive a business access request sent by the client of the user corresponding to the business access request and the business identifier of the target business to be accessed by the business access request. Based on the business access request, an information channel is established between the user and the client corresponding to the user, and the user's current identity information is received through the information channel. When the current identity information is the same as the preset identity information, the user's authentication is confirmed to be successful.

[0207] (2) Obtain unit 302;

[0208] The acquisition unit 302 is used to acquire risk verification setting information corresponding to the business identifier when the user's authentication is successful. The risk verification setting information includes at least one risk verification logical identifier.

[0209] For example, the acquisition unit 302 can be used to acquire the index information of the risk verification setting information set when the user's authentication is successful, query whether the business identifier of the target business exists in the index information, filter out the risk verification setting information corresponding to the business identifier in the risk verification setting information set when the index information exists, and use the preset risk verification setting information as the risk verification setting information corresponding to the business identifier when the index information does not exist.

[0210] (3) Filtering unit 303;

[0211] The filtering unit 303 is used to filter out the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set, and add the risk verification logic to the risk verification setting information to obtain the risk verification configuration information.

[0212] For example, the filtering unit 303 can be used to filter out the risk verification logic corresponding to the risk verification logic identifier in the preset risk verification logic set, then identify at least one loading address for loading the risk verification logic in the risk verification setting information, determine the loading address corresponding to the risk verification logic according to the type of the loading address, load the risk verification logic to the corresponding loading address in the risk verification setting information, and obtain the risk verification policy configuration information.

[0213] (4) Verification unit 304;

[0214] Verification unit 304 is used to verify business access requests based on risk verification configuration information and obtain risk verification results.

[0215] For example, verification unit 304 can be used to obtain historical risk verification records corresponding to business access requests, determine the initial risk verification result of business access requests based on historical risk verification records, extract access parameters corresponding to risk verification logic in risk verification configuration information from business access requests, verify access parameters based on risk verification logic, and merge the initial risk verification result and the verification result of access parameters to obtain the risk verification result.

[0216] (5) Control unit 305;

[0217] Control unit 305 is used to control user access to target services based on risk verification results.

[0218] For example, the control unit 305 can be used to refuse a user's access to the target service when the risk verification result indicates that the service access request is risky, allow the user to access the target service when the risk verification result indicates that the service access request is not risky, or send the risk verification result to the service server corresponding to the target service so that the service server controls the user's access to the target service.

[0219] Optionally, the service access device may also include a configuration unit 306, such as Figure 12 As shown, the specific details are as follows:

[0220] Configuration unit 306 is used to configure the risk verification configuration information for the business.

[0221] For example, configuration unit 306 can be used to obtain the security configuration information of a service. This security configuration information carries the service identifier of the service. Based on the security configuration, a risk verification framework corresponding to the service is constructed, the association between the service identifier and the risk verification setting information is established, and the risk verification setting information of the service is added to the risk verification setting information set.

[0222] In practice, each of the above units can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units, please refer to the previous method embodiments, which will not be repeated here.

[0223] As can be seen from the above, in this embodiment, after the receiving unit 301 receives the service access request and the service identifier of the target service to be accessed by the service access request, it authenticates the user corresponding to the service access request. When the user's authentication is successful, the obtaining unit 302 obtains the risk verification setting information corresponding to the service identifier. Then, the filtering unit 303 filters out the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set and adds the risk verification logic to the risk verification setting information to obtain risk verification configuration information. Then, the verification unit 304 verifies the service access request according to the risk verification configuration information to obtain the risk verification result. Finally, the control unit 305 controls the user's access to the target service based on the risk verification result. Since this scheme uses different risk verification configuration information for different services, and the risk verification configuration information is obtained based on specific risk verification logic in a unified preset risk verification logic set, it can perform unified risk control on service access and avoid the formation of security gaps. Therefore, it can improve the security of service access.

[0224] This invention also provides an electronic device, such as... Figure 13 As shown, it illustrates a structural schematic diagram of the electronic device involved in an embodiment of the present invention, specifically:

[0225] The electronic device may include components such as a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will understand that... Figure 13 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0226] The processor 401 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 402, and by calling data stored in the memory 402, it performs various functions and processes data, thereby performing overall detection of the electronic device. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0227] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0228] The electronic device also includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0229] The electronic device may also include an input unit 404, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0230] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402 to realize various functions, as follows:

[0231] The system receives a business access request and the business identifier of the target business to be accessed by the business access request. It then authenticates the user corresponding to the business access request. When the user's authentication is successful, it obtains the risk verification setting information corresponding to the business identifier. This risk verification setting information includes at least one risk verification logic identifier. It selects the risk verification logic corresponding to the risk verification logic identifier from a preset risk verification logic set and adds the risk verification logic to the risk verification setting information to obtain risk verification configuration information. Based on the risk verification configuration information, it verifies the business access request to obtain the risk verification result. Based on the risk verification result, it controls the user's access to the target business.

[0232] For example, an electronic device receives a service access request from a service server, along with the service identifier of the target service to be accessed. Alternatively, it receives a service access request from a client of a user corresponding to the service access request, along with the service identifier of the target service to be accessed. Based on the service access request, an information channel is established between the electronic device and the client corresponding to the user. The user's current identity information is received through this channel. If the current identity information matches the preset identity information, the user's authentication is confirmed. When the user's authentication is successful, the index information of the risk verification setting information set is obtained. The index information is then used to check if the service identifier of the target service exists. If the service identifier exists in the index information, the risk verification setting information corresponding to that service identifier is selected from the risk verification setting information set. If the service identifier does not exist in the index information, the preset risk verification setting information is used as the risk verification setting information corresponding to that service identifier. The risk verification logic corresponding to the risk verification logic identifier is selected from the preset risk verification logic set. Then, at least one loading address for loading the risk verification logic is identified in the risk verification setting information. Based on the type of the loading address, the loading address corresponding to the risk verification logic is determined. The risk verification logic is loaded into the corresponding loading address in the risk verification setting information to obtain the risk verification configuration information. The system retrieves historical risk verification records corresponding to business access requests. Based on these records, it determines the initial risk verification result for each request. It then extracts the access parameters corresponding to the risk verification logic from the risk verification configuration information within the request and verifies these parameters based on the logic. Finally, it merges the initial risk verification result with the verification result of the access parameters to obtain the final risk verification result. If the risk verification result indicates a risk in the business access request, the system denies the user access to the target business. Conversely, if the result indicates no risk, the system allows the user to access the target business, or it sends the risk verification result to the corresponding business server, enabling the business server to control user access to the target business.

[0233] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0234] As described above, after receiving a service access request and the service identifier of the target service to be accessed by the service access request, this embodiment of the invention authenticates the user corresponding to the service access request. When the user's authentication is successful, the risk verification setting information corresponding to the service identifier is obtained. Then, the risk verification logic corresponding to the risk verification logic identifier is selected from the preset risk verification logic set, and the risk verification logic is added to the risk verification setting information to obtain risk verification configuration information. Then, the service access request is verified according to the risk verification configuration information to obtain the risk verification result. Finally, the user's access to the target service is controlled based on the risk verification result. Since this scheme uses different risk verification configuration information for different services, and the risk verification configuration information is derived from specific risk verification logic in a unified preset risk verification logic set, unified risk control of service access can be performed to avoid the formation of security gaps. Therefore, the security of service access can be improved.

[0235] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0236] To this end, embodiments of the present invention provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the service access methods provided in the embodiments of the present invention. For example, the instructions can execute the following steps:

[0237] The system receives a business access request and the business identifier of the target business to be accessed by the business access request. It then authenticates the user corresponding to the business access request. When the user's authentication is successful, it obtains the risk verification setting information corresponding to the business identifier. This risk verification setting information includes at least one risk verification logic identifier. It selects the risk verification logic corresponding to the risk verification logic identifier from a preset risk verification logic set and adds the risk verification logic to the risk verification setting information to obtain risk verification configuration information. Based on the risk verification configuration information, it verifies the business access request to obtain the risk verification result. Based on the risk verification result, it controls the user's access to the target business.

[0238] For example, it receives a business access request from a business server and the business identifier of the target business to be accessed, or it receives a business access request from a client of the user corresponding to the business access request and the business identifier of the target business to be accessed. Based on the business access request, it establishes an information channel between the client and the user, receives the user's current identity information input through the information channel, and determines that the user's authentication is successful when the current identity information matches the preset identity information. When the user's authentication is successful, it obtains the index information of the risk verification setting information set, queries the index information to see if the business identifier of the target business exists, and if the business identifier exists in the index information, it filters out the risk verification setting information corresponding to the business identifier from the risk verification setting information set; if the business identifier does not exist in the index information, it uses the preset risk verification setting information as the risk verification setting information corresponding to the business identifier. It filters out the risk verification logic corresponding to the risk verification logic identifier from the preset risk verification logic set, then identifies at least one loading address for loading the risk verification logic in the risk verification setting information, determines the loading address corresponding to the risk verification logic based on the type of the loading address, loads the risk verification logic into the corresponding loading address in the risk verification setting information, and obtains the risk verification configuration information. The system retrieves historical risk verification records corresponding to business access requests. Based on these records, it determines the initial risk verification result for each request. It then extracts the access parameters corresponding to the risk verification logic from the risk verification configuration information within the request and verifies these parameters based on the logic. Finally, it merges the initial risk verification result with the verification result of the access parameters to obtain the final risk verification result. If the risk verification result indicates a risk in the business access request, the system denies the user access to the target business. Conversely, if the result indicates no risk, the system allows the user to access the target business, or it sends the risk verification result to the corresponding business server, enabling the business server to control user access to the target business.

[0239] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0240] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0241] Since the instructions stored in the computer-readable storage medium can execute the steps in any of the service access methods provided in the embodiments of the present invention, the beneficial effects that any of the service access methods provided in the embodiments of the present invention can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0242] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations of the aforementioned business access aspect or business access request authentication aspect.

[0243] The above provides a detailed description of a service access method, apparatus, electronic device, and computer-readable storage medium provided by embodiments of the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A service access method characterized by, The method comprises the following steps: Receiving a service access request and a service identifier of a target service required to be accessed by the service access request, and performing identity verification on a user corresponding to the service access request, comprising: constructing an information channel between a client corresponding to the user according to the service access request, receiving current identity information input by the user through the information channel, and performing identity verification on the user based on the current identity information; When the identity verification of the user is passed, obtaining risk verification setting information corresponding to the service identifier, the risk verification setting information comprising at least one risk verification logic identifier, the risk verification setting information being used to indicate information of a risk verification logic for performing risk verification on the service access request; Filtering out a risk verification logic corresponding to the risk verification logic identifier from a preset risk verification logic set, and adding the risk verification logic to the risk verification setting information to obtain risk verification configuration information; Obtaining a historical risk verification record corresponding to the service access request, and determining an initial risk verification result of the service access request according to the historical risk verification record, the historical risk verification record being used to record a verification result of performing risk verification on the service access request before a current time; Extracting an access parameter corresponding to the risk verification logic in the risk verification configuration information from the service access request, and performing verification on the access parameter based on the risk verification logic; Fusing the initial risk verification result and a verification result of the access parameter to obtain the risk verification result; Controlling the user to access the target service based on the risk verification result.

2. The service access method according to claim 1, characterized by, The method comprises the following steps: Filtering out a risk verification logic corresponding to the historical risk verification record from the risk verification configuration information; Extracting a target historical risk verification record of the service access request within a preset time range from the historical risk verification record; Counting a verification number corresponding to a historical risk verification result of each type in the target historical risk verification record; Substituting the verification number into a verification condition of the risk verification logic corresponding to the historical risk verification record to perform verification, and obtaining the initial risk verification result of the service access request.

3. The service access method according to claim 1, characterized by, The method comprises the following steps: Obtaining attribute information of the risk verification logic, and determining a verification path of the risk verification logic according to the attribute information of the risk verification logic; When the verification path is local verification, performing verification on the access parameter by using the risk verification logic; When the verification path is third-party verification, sending a corresponding access parameter to a verification server for verification according to the risk verification logic, and receiving a verification result corresponding to the access parameter returned by the verification server.

4. The service access method according to claim 3, characterized by, The method comprises the following steps: Determining a verification type of the risk verification logic and a verification condition corresponding to the verification type; extract an access parameter value corresponding to the verification type from the access parameter; verify the access parameter value in a corresponding verification condition to obtain a verification result of the access parameter.

5. The service access method of claim 1, wherein, The fusing the initial risk verification result and the verification result of the access parameter to obtain the risk verification result comprises: when the initial risk verification result is risk existence, or at least one of the verification results of the access parameter is verification failure, determining that the risk verification result is risk existence; when the initial risk verification result is risk non-existence, and all the verification results of the access parameter are verification success, determining that the risk verification result is risk non-existence.

6. The service access method according to any one of claims 1 to 5, characterized by, The adding the risk verification logic to the risk verification setting information to obtain risk verification configuration information comprises: identifying at least one loading address for loading risk verification logic in the risk verification setting information; determining a loading address corresponding to the risk verification logic according to a type of the loading address; loading the risk verification logic to the corresponding loading address in the risk verification setting information to obtain risk verification configuration information.

7. The service access method according to any one of claims 1 to 5, characterized by, The obtaining risk verification setting information corresponding to the service identifier comprises: obtaining index information of a risk verification setting information set, the index information being used to indicate an association relationship between a service identifier of a service and risk verification setting information; when the service identifier exists in the index information, screening out risk verification setting information corresponding to the service identifier in the risk verification setting information set; when the service identifier does not exist in the index information, taking preset risk verification setting information as the risk verification setting information corresponding to the service identifier.

8. The service access method according to claim 7, characterized by, Before the obtaining index information of the risk verification setting information set, the method further comprises: obtaining security configuration information of a service, the security configuration information carrying a service identifier of the service; constructing risk verification setting information corresponding to the service according to the security configuration information; establishing an association relationship between the service identifier of the service and the risk verification setting information, and adding the risk verification setting information of the service to the risk verification setting information set.

9. The service access method according to claim 8, characterized by, The obtaining security configuration information of a service comprises: receiving a first security configuration request of a service, the first security configuration request carrying a service identifier of the service; generating a configuration page according to the first security configuration request, the configuration page including a preset risk verification logic identifier set; receiving a selected risk verification logic identifier for the risk verification logic identifier set based on the configuration page, taking the selected risk verification logic identifier and a selection order as security configuration information; The constructing risk verification setting information corresponding to the service according to the security configuration information comprises: combining the selected risk verification logic identifier in the selection order to obtain the risk verification setting information corresponding to the service.

10. The service access request of claim 8, wherein, The obtaining security configuration information of a service comprises: receiving a second security configuration request of a service, the second security configuration request carrying a service identifier of the service and target risk verification logic corresponding to the service; According to the second security configuration request, a preset risk verification logic set is acquired; When the target risk verification logic exists in the preset risk verification logic set, a risk verification logic identifier of the target risk verification logic is acquired, and the risk verification logic identifier of the target risk verification logic is taken as security configuration information; When the target risk verification logic does not exist in the preset risk verification logic set, the target risk verification logic is added to the preset risk verification logic set, and a risk verification logic identifier of the target risk verification logic in the preset risk verification logic set is generated; The security configuration information is used for constructing the risk verification setting information corresponding to the business, including: the risk verification logic identifiers are combined to obtain the risk verification setting information corresponding to the business.

11. A service access device, characterized by Comprise: A receiving unit is configured to receive a business access request and a business identifier of a target business required to be accessed by the business access request, and perform identity verification on a user corresponding to the business access request, including: constructing an information channel between a client corresponding to the user according to the business access request, receiving current identity information input by the user through the information channel, and performing identity verification on the user based on the current identity information; An acquiring unit is configured to acquire risk verification setting information corresponding to the business identifier when the identity verification on the user is passed, the risk verification setting information including at least one risk verification logic identifier, and the risk verification setting information being used for indicating information of a risk verification logic for performing risk verification on the business access request; A screening unit is configured to screen a risk verification logic corresponding to the risk verification logic identifier from a preset risk verification logic set, and add the risk verification logic to the risk verification setting information to obtain risk verification configuration information; A verification unit is configured to acquire a historical risk verification record corresponding to the business access request, determine an initial risk verification result of the business access request according to the historical risk verification record, record a verification result of risk verification performed on the business access request before a current time in the historical risk verification record, extract an access parameter corresponding to a risk verification logic in the risk verification configuration information from the business access request, verify the access parameter based on the risk verification logic, and fuse the initial risk verification result and a verification result of the access parameter to obtain the risk verification result; A control unit is configured to control the user to access the target business based on the risk verification result.

12. An electronic device, comprising: The processor is configured to run the application program in the memory to execute steps in the business access method in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a plurality of instructions, and the instructions are adapted to be loaded by the processor to execute steps in the business access method in any one of claims 1 to 10.

14. A computer program product comprising computer instructions, characterized in that, The computer instructions are stored in a computer readable storage medium, and the processor reads the computer instructions to perform the steps in the service access method according to any one of claims 1 to 10.

Images