Server security access method and device, electronic equipment and readable storage medium

Abstract

The invention discloses a server security access method and device, electronic equipment and a readable storage medium, the method and device are applied to a server, the server is in communication connection with one or more clients, and the method comprises the following steps: determining an access log of each user corresponding to each client according to a server log file; analyzing each access log by using a risk assessment rule, and determining a target risk category hit by the corresponding user in the risk assessment rule; the risk assessment rule comprises one or a combination of more of an API connection failure assessment rule, a server resource access frequency assessment rule, a remote login assessment rule and a high concurrent access assessment rule; determining a target restriction rule corresponding to the target risk category according to a corresponding relationship between the risk category and the restriction rule; and limiting the user hitting the corresponding target risk category by using the target limiting rule. According to the scheme, more accurate user risk assessment can be carried out on client users, and more flexible risk user control is realized.

Description

Technical Field

[0001] The present application relates to the field of computer security technology, and in particular to a server-side security access method, and also to a server-side security access device, electronic device, computer-readable storage medium, and computer program product. Background Art

[0002] In the process of data communication between the server and the client, in order to ensure the security of communication, security risk control will be performed on the client users. However, the current security risk restrictions for users have the following problems: only designated types of users are controlled according to user roles, and the risk control method for users is relatively simple, and it is impossible to perform more accurate risk assessment and customized risk control on users, which reduces the system availability.

[0003] Therefore, how to conduct more accurate user risk assessment for client users and implement more flexible risk user control to effectively ensure system availability is an urgent problem to be solved by those skilled in the art. Summary of the invention

[0004] The purpose of the present application is to provide a server-side security access method, which can perform more accurate user risk assessment for client users and achieve more flexible risk user control, effectively ensuring system availability; another purpose of the present application is to provide a server-side security access device, electronic device, computer-readable storage medium and computer program product, all of which have the above-mentioned beneficial effects.

[0005] In a first aspect, the present application provides a server-side secure access method, which is applied to a server, wherein the server is connected to one or more clients for communication, and the method includes:

[0006] Obtaining a server log file, and determining an access log of each user corresponding to each of the clients according to the server log file;

[0007] Analyze each of the access logs using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; the risk assessment rules include one or more combinations of API connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules;

[0008] Determine the target restriction rule corresponding to the target risk category according to the corresponding relationship between the risk category and the restriction rule;

[0009] The target restriction rules are used to restrict users who hit the corresponding target risk category to achieve secure access to the server.

[0010] Optionally, when the risk assessment rule is the API connection failure assessment rule, analyzing each of the access logs using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule includes:

[0011] Determine the API connection failure information of the corresponding user according to the access log;

[0012] Determine the number of token expiration, parameter verification failure, and connection timeout of the user within a unit time according to each of the API connection failure information;

[0013] When the number of token expiration times within the unit time reaches the first number defined in the API connection failure assessment rule, determining that the target risk category hit by the user is the API connection failure risk based on token expiration;

[0014] When the number of parameter verification failures within the unit time reaches the second number defined in the API connection failure assessment rule, determining that the target risk category hit by the user is the API connection failure risk based on parameter verification failure;

[0015] When the number of connection timeouts within the unit time reaches the third number defined in the API connection failure evaluation rule, it is determined that the target risk category hit by the user is the API connection failure risk based on connection timeout.

[0016] Optionally, when the risk assessment rule is the server-side resource access frequency assessment rule, analyzing each of the access logs using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule includes:

[0017] Determine the server resource access information of the corresponding user according to the access log; wherein the server resources include multiple important level resources;

[0018] Determine the number of times the user accesses each of the important-level resources within a unit time according to the server-side resource access information;

[0019] When the number of accesses to the important-level resource reaches the number of corresponding levels specified in the server-side resource access frequency assessment rule, it is determined that the target risk category hit by the user is the over-frequency access risk of the corresponding important-level resource.

[0020] Optionally, when the risk assessment rule is the remote login assessment rule, analyzing each of the access logs using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule includes:

[0021] Determine the remote login information of the corresponding user according to the access log;

[0022] Determine the IP information and token information of the user according to the remote login information;

[0023] If the IP information of the user is different and the token information of the user is different, it is determined that the target risk category hit by the user is a multi-device login risk;

[0024] If the IP information of each user is different and the token information is the same, it is determined that the target risk category hit by the user is an abnormal attack risk.

[0025] Optionally, when the risk assessment rule is the high-concurrency access assessment rule, analyzing each of the access logs using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule includes:

[0026] Determine the number of user accesses of the corresponding user within a unit time according to the access log;

[0027] When the number of user accesses within the unit time reaches the maximum number of accesses defined in the high concurrent access evaluation rule, it is determined that the target risk category hit by the user is an abnormal attack risk.

[0028] Optionally, before analyzing each of the access logs using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule, the method further includes:

[0029] Determining whether each of the users is a risky user according to each of the access logs;

[0030] If the user is a risky user, determining the risk level of the risky user according to the access log;

[0031] The target risk assessment rules hit by the corresponding risk users are determined according to the risk level.

[0032] Optionally, after using the target restriction rule to restrict users who hit the corresponding target risk category to achieve secure access to the server, the method further includes:

[0033] Performing a preset number of risk checks on the user at preset time intervals;

[0034] When the user does not hit the target risk category in all the preset number of risk detections, the user restriction is cancelled using the target release rule corresponding to the target restriction rule.

[0035] In a second aspect, the present application further discloses a server-side security access device, which is applied to a server, and the server is connected to one or more clients for communication, and the device includes:

[0036] An acquisition module, used to acquire a server log file, and determine the access log of each user corresponding to each client according to the server log file;

[0037] An analysis module, used to analyze each of the access logs using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; the risk assessment rules include one or more combinations of API connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules;

[0038] A determination module, used to determine the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule;

[0039] The restriction module is used to restrict users who hit the corresponding target risk category by using the target restriction rules to achieve secure access to the server.

[0040] In a third aspect, the present application further discloses an electronic device, comprising:

[0041] Memory for storing computer programs;

[0042] A processor is used to implement the steps of any of the above-mentioned server-side secure access methods when executing the computer program.

[0043] In a fourth aspect, the present application further discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of any of the server-side security access methods described above are implemented.

[0044] In a fifth aspect, the present invention further discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of any one of the server-side security access methods described above.

[0045] The present application provides a server-side security access method, which is applied to a server side, and the server side is communicatively connected to one or more clients. The method includes: obtaining a server-side log file, and determining the access log of each user corresponding to each of the clients based on the server-side log file; analyzing each of the access logs using a risk assessment rule to determine a target risk category hit by the corresponding user in the risk assessment rule; the risk assessment rule includes a combination of one or more of an API connection failure assessment rule, a server-side resource access frequency assessment rule, a remote login assessment rule, and a high-concurrency access assessment rule; determining a target restriction rule corresponding to the target risk category based on a correspondence between a risk category and a restriction rule; and restricting users who hit the corresponding target risk category using the target restriction rule to achieve server-side security access.

[0046] By applying the technical solution provided by the present application, during the data communication between the server and the client, the server log file can be used to record the access log of each user corresponding to each client. Thus, a variety of different types of risk assessment rules can be used to conduct risk assessment on each user, and obtain the target risk category hit by each user under different risk assessment rules, thereby achieving more accurate user risk assessment for client users; at the same time, different restriction rules are set for different risk categories, so that the user can be restricted according to the target restriction rules corresponding to the target risk category hit by the user, that is, more flexible risk user control is achieved. It can be seen that the present technical solution can conduct more accurate user risk assessment for client users and achieve more flexible risk user control, effectively ensuring system availability.

[0047] In one embodiment of the present application, for users of different user categories (risky users and non-risky users) and risk levels (such as medium, low and high risk levels), different numbers and types of risk assessment rules can be set to perform risk assessments on them, which helps to achieve more accurate user risk assessments and more accurate risky user control, further improving system availability.

[0048] The server-side security access device, electronic device, computer-readable storage medium, and computer program product provided in this application also have the above-mentioned technical effects, and this application will not repeat them here. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the prior art and the embodiments of the present application, the drawings required for use in the description of the prior art and the embodiments of the present application are briefly introduced below. Of course, the drawings described below in relation to the embodiments of the present application are only part of the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without creative work, and the obtained other drawings also belong to the protection scope of the present application.

[0050] Figure 1 A schematic diagram of the structure of a secure access system provided by this application;

[0051] Figure 2 A flowchart of a server-side secure access method provided in this application;

[0052] Figure 3 A risk assessment diagram for users of different risk levels provided by this application;

[0053] Figure 4 A functional schematic diagram of a secure access system provided for this application;

[0054] Figure 5 A schematic diagram of the structure of a server-side secure access device provided in this application;

[0055] Figure 6 A schematic diagram of the structure of an electronic device provided in this application. DETAILED DESCRIPTION

[0056] The core of the present application is to provide a server-side security access method, which can perform more accurate user risk assessment for client users and achieve more flexible risk user control, effectively ensuring system availability; another core of the present application is to provide a server-side security access device, electronic device, computer-readable storage medium and computer program product, all of which have the above-mentioned beneficial effects.

[0057] In order to describe the technical solutions in the embodiments of the present application more clearly and completely, the technical solutions in the embodiments of the present application will be introduced below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0058] An embodiment of the present application provides a server-side secure access method.

[0059] First, please refer to Figure 1 , Figure 1 This is a structural diagram of a secure access system provided in the present application. The secure access system includes a server and one or more clients, and the server can communicate with each client. The server-side secure access method provided in an embodiment of the present application is implemented based on the secure access system.

[0060] For further information, please refer to Figure 2 , Figure 2 A flow chart of a server-side secure access method provided in this application, which is applied to Figure 1 The service end shown may include the following S101 to S104.

[0061] S101: Obtain a server log file, and determine the access log of each user corresponding to each client according to the server log file.

[0062] This step aims to determine the access log of each user based on the server log file. Specifically, the server log file refers to the access log file of each client to the server, which is recorded and stored by the server, and includes the log information of each user when accessing the server through each client, that is, the access log of each user mentioned above. Among them, a client may be used by multiple users, and the access log of each user here includes the access log of all users corresponding to each client, so that risk assessment and risk control can be performed for each user.

[0063] S102: Analyze each access log using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; the risk assessment rules include one or more combinations of API (Application Program Interface) connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules.

[0064] This step is intended to implement the user risk assessment function. Specifically, one or more risk assessment rules can be pre-set, and the access logs of each user can be analyzed using the risk assessment rules, so as to determine the target risk category hit by the corresponding user in the risk assessment rule. Among them, the API connection failure assessment rule is used to evaluate the user's API connection failure within a unit time; the server resource access frequency assessment rule is used to evaluate the user's server resource access frequency within a unit time; the remote login assessment rule is used to evaluate the user's remote login situation; the high-concurrency access assessment rule is used to evaluate the number of times the user visits the server within a unit time.

[0065] It should be noted that the number and categories of pre-set risk assessment rules are not unique, and the number and categories of risk assessment rules used to analyze each access log in this step are also not unique. As mentioned above, the risk assessment rules may include one or more combinations of API connection failure assessment rules, server-side resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules. However, in this step, when the risk assessment rules include the above four assessment rules at the same time, user A can only use two of the assessment rules to conduct risk assessment on him, user B can only use three of the assessment rules to conduct risk assessment on him, and user C can use all the assessment rules to conduct risk assessment on him.

[0066] Moreover, each risk assessment rule contains multiple risk categories. Correspondingly, when a user is assessed on risk using one of the above four assessment rules, the hit risk category of the user under this assessment rule can be obtained (the number of target risk categories is 1); when a user is assessed on risk using two of the above four assessment rules, the hit risk categories of the user under these two assessment rules can be obtained (the number of target risk categories is 2); when a user is assessed on risk using three of the above four assessment rules, the hit risk categories of the user under these three assessment rules can be obtained (the number of target risk categories is 3); when a user is assessed on risk using the above four assessment rules respectively, the hit risk categories of the user under these four assessment rules can be obtained (the number of target risk categories is 4).

[0067] Based on this, in one embodiment of the present application, before analyzing each access log using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule, the following may also be included:

[0068] Determine whether each user is a risky user based on each access log;

[0069] If the user is a risky user, the risk level of the risky user is determined based on the access log;

[0070] Determine the target risk assessment rules that the corresponding risk users will hit based on the risk level.

[0071] In this embodiment, for users of different user categories (non-risk users / risky users) and risk levels (low-risk users / medium-risk users / high-risk users), different numbers and types of risk assessment rules can be set to implement risk assessment. For example, please refer to Figure 3 , Figure 3A risk assessment schematic diagram for users of different risk levels provided in this application, for risk-free users, no risk assessment rules may be used for their risk assessment; for risk users of low risk levels, one of four assessment rules may be selected for their risk assessment (the number of target risk assessment rules hit is 1); for risk users of medium risk levels, two of four assessment rules may be selected for their risk assessment (the number of target risk assessment rules hit is 2); for risk users of high risk levels, three or more of four assessment rules may be selected for their risk assessment (the number of target risk assessment rules hit is 3 or 4).

[0072] Among them, whether each user is a risky user and the risk level of each risky user can be customized by the technical staff according to the actual situation. After obtaining the access log of a user, before using the risk assessment rules to conduct risk assessment on it, the user category and user risk level can be judged to determine the corresponding target risk assessment rules, and then the access logs are analyzed using the risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules.

[0073] It can be seen that the embodiments of the present application can set different numbers and types of risk assessment rules to perform risk assessment on users of different user categories (risky users and non-risky users) and risk levels (such as medium, low and high risk levels), which helps to achieve more accurate user risk assessment and more accurate risk user control, further improving system availability.

[0074] S103: Determine the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule.

[0075] This step aims to determine the target restriction rules so that the target restriction rules can be used to control the risks of the corresponding users. Specifically, the correspondence between different risk categories and restriction rules can be created in advance. Different risk categories may correspond to different restriction rules. Therefore, the target risk category hit by the user in the risk assessment rule can be compared and analyzed with the correspondence to determine the target restriction rules corresponding to the target risk category. It can be understood that restriction rules are rules that restrict users. Their specific content is not unique and is customized by technical personnel according to actual needs. For example, the number of times a user visits the server, the frequency of a user's access to a certain type of server resources, and the number of API connections a user makes to the server can be limited.

[0076] S104: Use target restriction rules to restrict users who hit corresponding target risk categories to achieve secure access to the server.

[0077] This step aims to implement user restrictions based on target restriction rules, that is, to implement risky user control, which helps to achieve user security access to the server.

[0078] Furthermore, in one embodiment of the present application, after restricting users who hit the corresponding target risk category by using the target restriction rule to achieve secure access to the server, the following may also be included:

[0079] Perform risk detection on the user for a preset number of times at a preset time interval;

[0080] When the user does not hit the target risk category in all the preset number of risk detections, the user restriction is cancelled using the target release rule corresponding to the target restriction rule.

[0081] Specifically, for users who have been restricted, risk detection can be performed cyclically. Once it is detected that the target risk category hit by the user is lifted, the target release rule corresponding to the target restriction rule can be used to remove the restriction on the user, that is, the user restriction release operation is realized. It should be noted that the specific values ​​of the above-mentioned preset time interval and preset number of times do not affect the implementation of this technical solution, and can be set by technical personnel according to actual needs, and this application does not limit this.

[0082] It can be seen that the server-side security access method provided by the embodiment of the present application can use the server-side log file to record the access log of each user corresponding to each client during the data communication between the server and the client. Therefore, it is possible to use a variety of different types of risk assessment rules to conduct risk assessment on each user, and obtain the target risk category hit by each user under different risk assessment rules, thereby achieving more accurate user risk assessment for client users; at the same time, different restriction rules are set for different risk categories, and it is possible to implement risk restrictions on the user according to the target restriction rules corresponding to the target risk category hit by the user, that is, to achieve more flexible risk user control. It can be seen that the technical solution can conduct more accurate user risk assessment for client users and achieve more flexible risk user control, effectively ensuring system availability.

[0083] Based on the above embodiments:

[0084] In one embodiment of the present application, when the risk assessment rule is an API connection failure assessment rule, analyzing each access log using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule may include:

[0085] Determine the API connection failure information of the corresponding user based on the access log;

[0086] Determine the number of token expiration, parameter verification failure, and connection timeout times of a user within a unit of time based on each API connection failure information;

[0087] When the number of token expiration times per unit time reaches the first number specified in the API connection failure assessment rule, it is determined that the target risk category hit by the user is the API connection failure risk based on token expiration;

[0088] When the number of parameter verification failures within a unit time reaches the second number specified in the API connection failure assessment rule, it is determined that the target risk category hit by the user is the API connection failure risk based on parameter verification failure;

[0089] When the number of connection timeouts per unit time reaches the third number specified in the API connection failure assessment rule, it is determined that the target risk category hit by the user is the API connection failure risk based on connection timeout.

[0090] The embodiment of the present application provides a user risk assessment method based on API connection failure assessment rules. Specifically, the access log may include the corresponding user's API connection failure information for the server, where the reasons for the API connection failure mainly include token expiration, parameter verification failure, and connection timeout. Therefore, the number of occurrences of each reason per unit time can be counted separately, so as to identify the target risk category by referring to each statistical number.

[0091] On this basis, in a possible implementation, determining the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule may include:

[0092] Determine the number of API connections that can be made for the target risk category based on the correspondence between the risk category and the restriction rules;

[0093] Among them, the API connection failure risk based on token expiration, the API connection failure risk based on parameter verification failure, and the API connection failure risk based on connection timeout correspond to different API connection times.

[0094] Specifically, when using the API connection failure assessment rules to conduct risk assessment on users, different API connection times can be set for different API connection failure risks caused by different reasons, that is, the maximum number of API connections that users can make is limited. The number of API connections that can be made is specifically the number of API connections that can be made per unit time.

[0095] In one embodiment of the present application, when the risk assessment rule is a server-side resource access frequency assessment rule, each access log is analyzed using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule, which may include:

[0096] Determine the server resource access information of the corresponding user according to the access log; wherein the server resources include multiple important level resources;

[0097] Determine the number of times a user accesses resources of each importance level within a unit time based on the server resource access information;

[0098] When the number of accesses to important-level resources reaches the corresponding number of times specified in the server-side resource access frequency assessment rule, it is determined that the target risk category hit by the user is the over-frequency access risk of the corresponding important-level resources.

[0099] The embodiment of the present application provides a user risk assessment method based on the server-side resource access frequency assessment rules. Specifically, the access log may include the corresponding user's access information to resources of different importance levels in the server, which can be used to determine the number of times the user accesses resources of different importance levels in the server per unit time. Obviously, the higher the number of accesses per unit time, the greater the probability of overclocking access risk. Among them, for server-side resources with higher importance levels, a lower number of accessible times can be limited; for server-side resources with lower importance levels, a higher number of accessible times can be limited.

[0100] On this basis, in a possible implementation, determining the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule may include:

[0101] Determine the number of times resources of each importance level corresponding to the target risk category can be accessed based on the corresponding relationship between the risk category and the restriction rules;

[0102] Among them, resources of different importance levels correspond to different access times.

[0103] Specifically, when using the server resource access frequency assessment rules to conduct risk assessment on users, different access times can be set for server resources of different importance levels, that is, the maximum access times of users for resources of different importance levels are limited. The access times are specifically the access times per unit time.

[0104] In one embodiment of the present application, when the risk assessment rule is a remote login assessment rule, analyzing each access log using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule may include:

[0105] Determine the remote login information of the corresponding user based on the access log;

[0106] Determine the user's IP information and token information based on the remote login information;

[0107] If the user's IP information is different and the token information is different, it is determined that the target risk category hit by the user is multi-device login risk;

[0108] If the IP information of each user is different and the token information is the same, it is determined that the target risk category hit by the user is an abnormal attack risk.

[0109] The embodiment of the present application provides a user risk assessment method based on off-site login assessment rules. Specifically, the access log may include the off-site login information of the corresponding user, and the IP and token used by the user to log in to the server off-site each time can be analyzed and determined based on the off-site login information. It can be understood that if the IP and token used for multiple off-site logins are different, it means that the user may be using multiple devices (i.e., multiple clients) to log in to the server off-site, and there may be a risk of multiple device logins at this time; if the IP used for multiple off-site logins is different, but the token is the same, it means that the token may have been leaked, and there is a high probability of abnormal attack risks from illegal users.

[0110] On this basis, in a possible implementation, determining the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule may include:

[0111] According to the correspondence between the risk category and the restriction rule, the target restriction rule corresponding to the multi-device login risk is determined to restrict the user's access to high-importance resources;

[0112] According to the correspondence between risk categories and restriction rules, the target restriction rule corresponding to the abnormal attack risk is determined to restrict user access to the server.

[0113] Specifically, in order to effectively ensure the information security of the server, in response to the risk of multiple device logins, the corresponding user's access to high-importance resources can be restricted. In other words, the user is not allowed to access high-importance resources in the server, and can only access low-importance resources in the server; in response to the risk of abnormal attacks, the user's access to the server is directly denied.

[0114] In one embodiment of the present application, when the risk assessment rule is a high concurrent access assessment rule, analyzing each access log using the risk assessment rule to determine the target risk category hit by the corresponding user in the risk assessment rule may include:

[0115] Determine the number of user accesses per unit time for the corresponding user according to the access log;

[0116] When the number of user accesses per unit time reaches the maximum number of accesses specified in the high concurrent access assessment rule, it is determined that the target risk category hit by the user is an abnormal attack risk.

[0117] The embodiment of the present application provides a user risk assessment method based on high concurrent access assessment rules. Specifically, the access log may include the number of visits to the server by the corresponding user within a unit time, that is, the above-mentioned number of user visits. Obviously, the higher the number of user visits within the unit time, the greater the possibility of high concurrent access, and at this time there is a greater probability of abnormal attack risks from illegal users. It should be noted that the above-mentioned number of user visits may include the number of successful user visits and the number of failed user visits.

[0118] On this basis, in a possible implementation, determining the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule may include:

[0119] Determine the number of times the server corresponding to the target risk category can be accessed based on the correspondence between the risk category and the restriction rule;

[0120] Among them, different user access times correspond to different server accessible times.

[0121] Specifically, when using high-concurrency access assessment rules to conduct risk assessment on users, different server access times (limited access times) can be set for different user access times (actual access times), that is, the number of times a user can access the server is limited. The server access times are specifically the number of times the server can access the server per unit time.

[0122] It should be noted that the specific values ​​of the various thresholds (first number, second number, third number, limited level number, maximum number of visits, etc.) in the above embodiments do not affect the implementation of this technical solution, and can be set by technical personnel according to actual needs. This application does not limit this.

[0123] Based on the above embodiments, the embodiment of the present application provides another server-side secure access method.

[0124] Please refer to Figure 4 , Figure 4 The functional principle diagram of a secure access system provided in this application, and the corresponding implementation process of the server-side secure access method are as follows:

[0125] 1. Risk Assessment

[0126] 1. Manual setting: Risk assessment can be set manually. You can set risks for each user in the user management section. The settable items include no risk, low risk, medium risk and high risk. This setting will not be affected by the self-assessment and has a higher priority than the self-assessment. If users want to set low risk, medium risk and high risk, they need to select restriction items for the rules. Among them, low-risk users need to select one restriction rule in the setting rules, medium-risk users need to select two restriction rules in the setting rules, and high-risk users need to select three or more restriction rules in the setting rules.

[0127] 2. Rule setting: The rule setting will set the risk rules, mainly including the following four items:

[0128] (1) API connection failure. According to the reasons for failure, they are mainly classified into API connection failure caused by common errors (such as token expiration), API connection failure caused by attack errors (such as parameter verification abnormalities), API connection failure caused by timeout, etc., all of which will have an impact on the system. For example, for token expiration, if the same user fails multiple times within 1 minute, there is reason to suspect that the username or password has been leaked and the login has been preempted by others. In this case, login can be restricted; for parameter verification abnormalities, the parameters transmitted through the page should all be in line with the server request. Such errors are generally caused by attackers forging data attacks. The number of API connections can be restricted for such problems; for timeout errors, it may be because the server is overloaded and cannot handle more requests in time. At this time, the server situation can be alleviated by reducing the request frequency. Based on this, the above conditional rules are introduced to facilitate risk assessment and restriction of users, so that dangerous users can be handled in a timely manner and system security risks can be reduced.

[0129] (2) Resource access frequency. Server resources can be classified into general resources, medium resources, and critical resources according to their importance, and then restrictions can be imposed on resources of different importance. For example, a single user cannot access general resources more than 1,000 times per hour, a single user cannot access medium resources more than 300 times per hour, and a single user cannot access critical resources more than 100 times per hour. If the number exceeds these limits, the access frequency of resources of different importance will be restricted, thus achieving different restrictions at the resource level.

[0130] (3) Number of off-site logins. If the number of off-site logins exceeds the limit, a restriction will be imposed. This section includes two situations: one is that the user logs in again, and the login IP is inconsistent with the previous one, and the user's token is inconsistent. In this case, if the user logs in from a different location more than 20 times within a month, access to important resources or login will be restricted. The other is that the token is the same but the IP is different. In this case, it is likely that the attacker has hijacked the token for operation, because for clients with different IPs, the login token is likely to be inconsistent. If this happens more than 3 times a day, the user is considered to be at risk and access to important resources is restricted.

[0131] (4) Single-user high concurrent access: For this rule, you can set the high concurrent number of a single user within 1 minute. If the limit is exceeded, the number of accesses will be limited in subsequent visits to avoid consuming the number of connections and causing system service blockage.

[0132] 2. Self-assessment

[0133] 1. API connection failure assessment: Failed API connection requests can be filtered out from the operation log and system log (server log file) and classified according to the failure reason. If too many tokens expire in a unit time, it is suspected that the account password has been leaked, and the login can be restricted and the user can be locked; if there are too many abnormal parameter checks in a unit time, it is suspected that an attacker has attacked, and the number of API connections in a unit time can be restricted; if there are too many timeouts in a unit time, it is suspected that the server is overloaded, and the number of API connections in a unit time can be restricted.

[0134] 2. Resource access frequency assessment: First, classify the importance of server resources, then filter out all access requests from each user within 1 hour from the system log, classify the access requests according to the resource importance level, count the number, and then evaluate according to different rules. The number of accesses to general resources by a single user in one hour cannot exceed 1,000 times, the number of accesses to medium resources by a single user in one hour cannot exceed 300 times, and the number of accesses to serious resources by a single user in one hour cannot exceed 100 times. If the number is exceeded, the user's access to various types of server resources can be restricted. The general resource limit can be set to 500 accesses per hour, and access requests exceeding this limit will be discarded; the medium resource limit can be set to 100 accesses per hour, and access requests exceeding this limit will be discarded; the important resource module limit can be set to 50 accesses, and access requests exceeding this limit will be discarded. In this way, the security and availability of the system can be effectively guaranteed.

[0135] 3. Evaluation of the number of remote logins:

[0136] (1) Different tokens for different IPs: Users may log in from different clients. If a user frequently switches clients to log in, and there is a suspicion of username or password leakage, their login can be restricted or IP whitelist restrictions can be implemented to ensure the security of the user account. The number of occurrences of different login IPs can be counted by filtering the operation logs and compared with the rule restrictions. If the number exceeds the limit, the user can be locked or the IP whitelist can be configured according to the rule configuration.

[0137] (2) Same token for different IPs: Abnormal attacks may occur. The number of times different IPs appear in all access requests of the same user can be filtered out from the system log. Under normal circumstances, if the same user logs in on different clients, the tokens generated must be different. If the same token appears for different IPs, it can be considered that the attacker carries the token and switches the proxy IP to attack. According to the rules, if the number of different IPs counted for the same token exceeds the limit, the login or access frequency can be restricted.

[0138] 4. High-concurrency access assessment: High-concurrency access is a way to occupy system resources extremely, and normal user operations will not cause high concurrency. For such problems, the system log can be used to count the number of all access requests of users in a unit of time, and compared with the set rules. If the limit is exceeded, the number of user access requests can be limited without distinguishing the importance level of resources, so as to ensure service availability.

[0139] Furthermore, based on the above four types of rules, users can also be classified into risk categories. If they do not meet all the rules, they are risk-free users; if they meet one rule, they are low-risk users; if they meet two rules, they are medium-risk users; and if they meet three or more rules, they are high-risk users.

[0140] 3. Risk Recovery

[0141] Risk recovery is an auxiliary module that can refer to multiple assessment results. For example, after a user is restricted due to high concurrency, he can be tested ten times in a row. If the number of concurrent connections of the user does not reach the restricted number of connections, the risk level can be lowered and the restriction on high concurrency items can be cancelled.

[0142] Therefore, through user risk assessment, restriction and recovery plan, restrictions are implemented at the user level to ensure server security and user security, and further ensure the availability of the system.

[0143] It can be seen that the server-side security access method provided by the embodiment of the present application can use the server-side log file to record the access log of each user corresponding to each client during the data communication between the server and the client. Therefore, it is possible to use a variety of different types of risk assessment rules to conduct risk assessment on each user, and obtain the target risk category hit by each user under different risk assessment rules, thereby achieving more accurate user risk assessment for client users; at the same time, different restriction rules are set for different risk categories, and it is possible to implement risk restrictions on the user according to the target restriction rules corresponding to the target risk category hit by the user, that is, to achieve more flexible risk user control. It can be seen that the technical solution can conduct more accurate user risk assessment for client users and achieve more flexible risk user control, effectively ensuring system availability.

[0144] An embodiment of the present application provides a server-side secure access device.

[0145] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the structure of a server-side security access device provided by the present application. The server-side security access device is applied to the server, and the server communicates with one or more clients, and may include:

[0146] Acquisition module 1, used to acquire the server log file, and determine the access log of each user corresponding to each client according to the server log file;

[0147] Analysis module 2, used to analyze each access log using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; the risk assessment rules include one or more combinations of API connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules;

[0148] Determination module 3, used to determine the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule;

[0149] The restriction module 4 is used to restrict users who hit the corresponding target risk category by using the target restriction rules to achieve secure access to the server.

[0150] It can be seen that the server-side security access device provided in the embodiment of the present application can use the server-side log file to record the access log of each user corresponding to each client during the data communication between the server and the client. Therefore, it can use a variety of different types of risk assessment rules to conduct risk assessment on each user, and obtain the target risk category hit by each user under different risk assessment rules, so as to achieve more accurate user risk assessment for client users; at the same time, different restriction rules are set for different risk categories, so that the user can be restricted according to the target restriction rules corresponding to the target risk category hit by the user, that is, more flexible risk user control is achieved. It can be seen that the technical solution can conduct more accurate user risk assessment for client users and achieve more flexible risk user control, effectively ensuring system availability.

[0151] In one embodiment of the present application, when the risk assessment rule is an API connection failure assessment rule, the above-mentioned analysis module 2 can be specifically used to determine the API connection failure information of the corresponding user based on the access log; determine the number of token expirations, parameter verification failures, and connection timeouts of the user within a unit time based on each API connection failure information; when the number of token expirations within a unit time reaches the first number specified in the API connection failure assessment rule, determine that the target risk category hit by the user is the API connection failure risk based on token expiration; when the number of parameter verification failures within a unit time reaches the second number specified in the API connection failure assessment rule, determine that the target risk category hit by the user is the API connection failure risk based on parameter verification failure; when the number of connection timeouts within a unit time reaches the third number specified in the API connection failure assessment rule, determine that the target risk category hit by the user is the API connection failure risk based on connection timeout.

[0152] In one embodiment of the present application, when the risk assessment rule is a server-side resource access frequency assessment rule, the above-mentioned analysis module 2 can be specifically used to determine the server-side resource access information of the corresponding user based on the access log; wherein the server-side resources include multiple importance-level resources; the number of visits of the user to each importance-level resource in a unit time is determined based on the server-side resource access information; when the number of visits to the importance-level resource reaches the corresponding level number specified in the server-side resource access frequency assessment rule, it is determined that the target risk category hit by the user is the overfrequency access risk of the corresponding importance-level resource.

[0153] In one embodiment of the present application, when the risk assessment rule is an off-site login assessment rule, the above-mentioned analysis module 2 can be specifically used to determine the off-site login information of the corresponding user based on the access log; determine the user's IP information and token information based on the off-site login information; if the user's IP information is different and the token information is different, then it is determined that the target risk category hit by the user is a multi-device login risk; if the user's IP information is different and the token information is the same, then it is determined that the target risk category hit by the user is an abnormal attack risk.

[0154] In one embodiment of the present application, when the risk assessment rule is a high-concurrency access assessment rule, the above-mentioned analysis module 2 can be specifically used to determine the number of user accesses of the corresponding user in a unit time based on the access log; when the number of user accesses in a unit time reaches the maximum number of accesses specified in the high-concurrency access assessment rule, it is determined that the target risk category hit by the user is an abnormal attack risk.

[0155] In one embodiment of the present application, the server-side security access device may also include a judgment module for determining whether each user is a risky user based on each access log before analyzing each access log using the risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; if the user is a risky user, determining the risk level of the risky user based on the access log; and determining the target risk assessment rule hit by the corresponding risky user based on the risk level.

[0156] In one embodiment of the present application, the server-side security access device may also include a release module, which is used to perform a preset number of risk detections on users at preset time intervals after restricting users who hit the corresponding target risk category using the target restriction rules to achieve server-side security access; when the user does not hit the target risk category in all preset number of risk detections, the target release rule corresponding to the target restriction rule is used to cancel the user restriction.

[0157] For an introduction to the device provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0158] An embodiment of the present application provides an electronic device.

[0159] Please refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application, and the electronic device may include:

[0160] A memory 11, used for storing computer programs;

[0161] The processor 10 can implement the steps of any of the above-mentioned server-side secure access methods when executing a computer program.

[0162] like Figure 6 , which is a schematic diagram of the composition structure of an electronic device, the electronic device may include: a processor 10, a memory 11, a communication interface 12 and a communication bus 13. The processor 10, the memory 11 and the communication interface 12 all communicate with each other through the communication bus 13.

[0163] In the embodiment of the present application, the processor 10 may be a central processing unit (CPU), an application specific integrated circuit, a digital signal processor, a field programmable gate array or other programmable logic devices, etc.

[0164] The processor 10 may call a program stored in the memory 11. Specifically, the processor 10 may execute operations in an embodiment of the server-side secure access method.

[0165] The memory 11 is used to store one or more programs, which may include program codes, and the program codes include computer operation instructions. In the embodiment of the present application, the memory 11 at least stores programs for implementing the following functions:

[0166] Obtain the server log file, and determine the access log of each user corresponding to each client according to the server log file;

[0167] Analyze each access log using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; risk assessment rules include one or more combinations of API connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules;

[0168] Determine the target restriction rules corresponding to the target risk category according to the corresponding relationship between the risk category and the restriction rules;

[0169] Target restriction rules are used to restrict users who hit the corresponding target risk category to achieve secure access to the server.

[0170] In a possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function, etc.; the data storage area may store data created during use.

[0171] In addition, the memory 11 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0172] The communication interface 12 may be an interface of a communication module, and is used to connect to other devices or systems.

[0173] Of course, it should be noted that Figure 6 The structure shown does not constitute a limitation on the electronic device in the embodiment of the present application. In actual applications, the electronic device may include Figure 6 More or fewer components than shown, or combinations of certain components.

[0174] An embodiment of the present application provides a computer-readable storage medium.

[0175] The computer-readable storage medium provided in the embodiment of the present application stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned server-side security access methods can be implemented.

[0176] Among them, the computer-readable storage medium can be any available medium that can be stored in a computer or a data storage device such as a server or data center that includes one or more available media integrated. For example, it can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape, etc.), an optical medium (such as a DVD) or a semiconductor medium (such as a solid-state hard disk) and other media that can store computer program codes.

[0177] For an introduction to the computer-readable storage medium provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0178] An embodiment of the present application provides a computer program product.

[0179] The computer program product provided in the embodiments of the present application includes a computer program / instruction, which, when executed by a processor, can implement the steps of any of the above-mentioned server-side security access methods.

[0180] Specifically, in the above embodiments, all or part of them can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of them can be implemented in the form of a computer program product.

[0181] Among them, the computer program product may include one or more computer programs / instructions, and when the computer program / instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application may be generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line, etc.) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0182] For an introduction to the computer program product provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0183] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0184] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0185] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0186] The technical solution provided by the present application is described in detail above. The principle and implementation method of the present application are described in detail using specific examples herein, and the description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A server-side secure access method, characterized in that: Applied to a server, the server is connected to one or more clients for communication, and the method includes: Obtaining a server log file, and determining an access log of each user corresponding to each of the clients according to the server log file; Analyze each of the access logs using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; the risk assessment rules include one or more combinations of API connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules; Determine the target restriction rule corresponding to the target risk category according to the corresponding relationship between the risk category and the restriction rule; The target restriction rules are used to restrict users who hit the corresponding target risk category to achieve secure access to the server.

2. The server-side secure access method according to claim 1, characterized in that: When the risk assessment rule is the API connection failure assessment rule, the risk assessment rule is used to analyze each of the access logs to determine the target risk category hit by the corresponding user in the risk assessment rule, including: Determine the API connection failure information of the corresponding user according to the access log; Determine the number of token expiration, parameter verification failure, and connection timeout of the user within a unit time according to each of the API connection failure information; When the number of token expiration times within the unit time reaches the first number defined in the API connection failure assessment rule, determining that the target risk category hit by the user is the API connection failure risk based on token expiration; When the number of parameter verification failures within the unit time reaches the second number defined in the API connection failure assessment rule, determining that the target risk category hit by the user is the API connection failure risk based on parameter verification failure; When the number of connection timeouts within the unit time reaches the third number defined in the API connection failure evaluation rule, it is determined that the target risk category hit by the user is the API connection failure risk based on connection timeout.

3. The server-side secure access method according to claim 1, characterized in that: When the risk assessment rule is the server-side resource access frequency assessment rule, the risk assessment rule is used to analyze each of the access logs to determine the target risk category hit by the corresponding user in the risk assessment rule, including: Determine the server resource access information of the corresponding user according to the access log; wherein the server resources include multiple important level resources; Determine the number of times the user accesses each of the important-level resources within a unit time according to the server-side resource access information; When the number of accesses to the important-level resource reaches the number of corresponding levels specified in the server-side resource access frequency assessment rule, it is determined that the target risk category hit by the user is the over-frequency access risk of the corresponding important-level resource.

4. The server-side secure access method according to claim 1, characterized in that: When the risk assessment rule is the remote login assessment rule, the risk assessment rule is used to analyze each of the access logs to determine the target risk category hit by the corresponding user in the risk assessment rule, including: Determine the remote login information of the corresponding user according to the access log; Determine the IP information and token information of the user according to the remote login information; If the IP information of the user is different and the token information of the user is different, it is determined that the target risk category hit by the user is a multi-device login risk; If the IP information of each user is different and the token information is the same, it is determined that the target risk category hit by the user is an abnormal attack risk.

5. The server-side secure access method according to claim 1, characterized in that: When the risk assessment rule is the high-concurrency access assessment rule, the use of the risk assessment rule to analyze each of the access logs to determine the target risk category hit by the corresponding user in the risk assessment rule includes: Determine the number of user accesses of the corresponding user within a unit time according to the access log; When the number of user accesses within the unit time reaches the maximum number of accesses defined in the high concurrent access evaluation rule, it is determined that the target risk category hit by the user is an abnormal attack risk.

6. The server-side secure access method according to any one of claims 1 to 5, characterized in that: Before analyzing each of the access logs using the risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules, the method further includes: Determining whether each of the users is a risky user according to each of the access logs; If the user is a risky user, determining the risk level of the risky user according to the access log; The target risk assessment rules hit by the corresponding risk users are determined according to the risk level.

7. The server-side secure access method according to claim 1, characterized in that: After restricting users who hit the corresponding target risk category by using the target restriction rule to achieve secure access to the server, it also includes: Performing a preset number of risk checks on the user at preset time intervals; When the user does not hit the target risk category in all the preset number of risk detections, the user restriction is cancelled using the target release rule corresponding to the target restriction rule.

8. A server-side secure access device, characterized in that: Applied to a server, the server is connected to one or more clients for communication, and the device comprises: An acquisition module, used to acquire a server log file, and determine the access log of each user corresponding to each client according to the server log file; An analysis module, used to analyze each of the access logs using risk assessment rules to determine the target risk category hit by the corresponding user in the risk assessment rules; the risk assessment rules include one or more combinations of API connection failure assessment rules, server resource access frequency assessment rules, remote login assessment rules, and high concurrent access assessment rules; A determination module, used to determine the target restriction rule corresponding to the target risk category according to the correspondence between the risk category and the restriction rule; The restriction module is used to restrict users who hit the corresponding target risk category by using the target restriction rules to achieve secure access to the server.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the server-side secure access method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, the steps of the server-side secure access method according to any one of claims 1 to 7 are implemented.

Images