Access control method and device, storage medium and electronic equipment

Abstract

The invention discloses an access control method and device, a storage medium and electronic equipment. The method comprises the following steps: acquiring an interface access request triggered for a target application program; a key access path associated with the target application program is obtained, and the access frequency of the key access path meets the key access condition in the historical access process of the target application program; performing primary verification on the interface access request by using the key access path; acquiring historical behavior characteristics associated with the target application program under the condition that the first verification is passed; performing secondary verification on the interface access request by using the historical behavior characteristics to obtain a secondary verification result; the method can be applied to a cloud technology scene, and relates to technologies such as cloud security and the like. The technical problem of low access control accuracy is solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to an access control method, device, storage medium and electronic device. Background Art

[0002] In access control scenarios, due to the application programming interface (API), there are problems such as excessive exposure of error information (easy to be exploited for attacks), loopholes in execution logic design, and sensitive data (such as account numbers and passwords) transmitted over plain text networks. In addition, API acts as the boundary between enterprise business logic and data interaction, making it easy to become a target of attack.

[0003] The access request verification method for API in the related art usually verifies the identity information of the API access request. However, when the attacker uses stolen identity information to request access, the access request verification method in the above related art often fails to play the expected role, which leads to the problem of low access control accuracy. Therefore, there is a problem of low access control accuracy.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present application provide an access control method, device, storage medium and electronic device to at least solve the technical problem of low access control accuracy.

[0006] According to one aspect of an embodiment of the present application, there is provided an access control method, comprising: obtaining an interface access request triggered for a target application; obtaining a key access path associated with the target application, wherein the key access path is an access path whose access frequency during a historical access process of the target application satisfies a key access condition; performing a primary verification on the interface access request using the key access path; if the primary verification passes, obtaining a historical behavior feature associated with the target application, wherein the historical behavior feature is used to characterize the access behavior exhibited by historical users of the target application during the historical access process; performing a secondary verification on the interface access request using the historical behavior feature to obtain a secondary verification result; and performing access control on the interface access request based on the secondary verification result.

[0007] According to another aspect of an embodiment of the present application, an access control device is also provided, including: a first acquisition unit, used to acquire an interface access request triggered for a target application; a second acquisition unit, used to acquire a key access path associated with the target application, wherein the key access path is an access path whose access frequency of the target application during a historical access process satisfies a key access condition; a first verification unit, used to perform a single verification on the interface access request using the key access path; a third acquisition unit, used to acquire a historical behavior feature associated with the target application if the single verification passes, wherein the historical behavior feature is used to characterize the access behavior exhibited by historical users of the target application during the historical access process; a second verification unit, used to perform a secondary verification on the interface access request using the historical behavior feature to obtain a secondary verification result; and a first control unit, used to perform access control on the interface access request based on the secondary verification result.

[0008] As an optional scheme, the above-mentioned device also includes: a third verification unit, which is used to temporarily block or temporarily pass the above-mentioned interface access request after the above-mentioned interface access request is verified once using the above-mentioned key access path, if the above-mentioned first verification or the above-mentioned second verification fails, and verify the above-mentioned interface access request three times, wherein the above-mentioned three verifications are used to indicate that the client that has been authenticated by the above-mentioned target application assists in verifying the identity information of the above-mentioned interface access request.

[0009] As an optional solution, the above-mentioned device also includes: a first processing unit, which is used to ban the account associated with the above-mentioned interface access request after temporarily blocking or temporarily passing the above-mentioned interface access request and verifying the above-mentioned interface access request three times, if the above-mentioned interface access request is temporarily passed and the above-mentioned three verifications fail.

[0010] As an optional scheme, the above-mentioned device also includes: a second processing unit, which is used to send permission prompt information to the above-mentioned target client after the above-mentioned interface access request is temporarily blocked or temporarily passed, and the above-mentioned interface access request is verified three times, when the above-mentioned interface access request is temporarily blocked, the above-mentioned three verifications are passed, and the current access volume of the above-mentioned target application is greater than or equal to a preset threshold, wherein the above-mentioned permission prompt information is used to prompt the above-mentioned target client to put the above-mentioned interface access request into a whitelist, and the access requests in the above-mentioned whitelist are prohibited from being temporarily blocked.

[0011] As an optional scheme, the above-mentioned third verification unit includes: a sending module, used to send identity authentication information to the target client that has been authenticated by the above-mentioned target application, wherein the above-mentioned identity authentication information is used to instruct the above-mentioned target client to assist in verifying the identity information of the above-mentioned interface access request; a first determination module, used to determine that the above-mentioned three verifications have failed when receiving the verification failure information fed back by the above-mentioned target client, or when the verification success information fed back by the above-mentioned target client is not received within a preset time period; a second determination module, used to determine that the above-mentioned three verifications have passed when receiving the above-mentioned verification success information fed back by the above-mentioned target client.

[0012] As an optional scheme, the above-mentioned first verification unit includes: an acquisition module, which is used to obtain at least one target object in the process of requesting access to the above-mentioned target application through the above-mentioned interface access request, wherein the above-mentioned target object includes at least one of the following: an application device, an application and a programming interface; a composition module, which is used to compose the path corresponding to the above-mentioned interface access request from the above-mentioned at least one target object; a third determination module, which is used to determine that the above-mentioned interface access request passes the verification of the above-mentioned key access path when the path similarity between the above-mentioned path path and the above-mentioned key access path is greater than or equal to the path similarity threshold; a fourth determination module, which is used to determine that the above-mentioned interface access request does not pass the verification of the above-mentioned key access path when the path similarity between the above-mentioned path path and the above-mentioned key access path is less than the above-mentioned path similarity threshold.

[0013] As an optional scheme, the above-mentioned second verification unit includes: a statistical module, which is used to count the behavioral data in each time period during the process of requesting access to the above-mentioned target application through the above-mentioned interface access request, wherein the above-mentioned behavioral data includes at least one of the following: call success rate, response time and number of requests; a construction module, which is used to use the behavioral data in the above-mentioned various time periods to construct the target behavior characteristics associated with the above-mentioned interface access request; a fifth determination module, which is used to determine that the above-mentioned interface access request has passed the verification of the above-mentioned historical behavior characteristics when the feature similarity between the above-mentioned target behavior characteristics and the above-mentioned historical behavior characteristics is greater than or equal to the feature similarity threshold; a sixth determination module, which is used to determine that the above-mentioned interface access request has not passed the verification of the above-mentioned historical behavior characteristics when the feature similarity between the above-mentioned target behavior characteristics and the above-mentioned historical behavior characteristics is less than the above-mentioned feature similarity threshold.

[0014] As an optional scheme, the above-mentioned first control unit also includes: a second control unit, used to perform access restriction control on the above-mentioned interface access request when the above-mentioned secondary verification result fails; a fourth acquisition unit, used to obtain the historical user information associated with the above-mentioned target application and the user reference information involved in the process of requesting access to the above-mentioned target application through the above-mentioned interface access request when the above-mentioned secondary verification result passes; a seventh determination module, used to determine that the above-mentioned interface access request has passed the verification when the information similarity between the above-mentioned user reference information and the above-mentioned historical user information is greater than or equal to the information similarity threshold; a third control unit, used to determine that the above-mentioned interface access request has not passed the verification when the information similarity between the above-mentioned user reference information and the above-mentioned historical user information is less than the above-mentioned information similarity threshold, and perform the above-mentioned access restriction control on the above-mentioned interface access request.

[0015] According to another aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the access control method as described above.

[0016] According to another aspect of an embodiment of the present application, there is also provided an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the access control method through the computer program.

[0017] In an embodiment of the present application, an interface access request triggered to a target application is obtained; a key access path associated with the target application is obtained, wherein the key access path is an access path whose access frequency of the target application in the historical access process meets the key access condition; the interface access request is verified once using the key access path; if the verification is passed once, the historical behavior characteristics associated with the target application are obtained, wherein the historical behavior characteristics are used to characterize the access behavior of the historical users of the target application in the historical access process; the interface access request is verified twice using the historical behavior characteristics to obtain the secondary verification result; and access control is performed on the interface access request based on the secondary verification result. By using the key access path and behavior characteristics associated with the target application to verify the interface access request multiple times, the attribute information presented by the target application and the user in the historical access process is added to the access control process, and the information dimension of the attribute information is expanded through the multi-attribute information of the path and behavior, so as to achieve the goal of accurately performing access verification when the attacker uses stolen identity information to request access, thereby achieving the technical effect of improving the accuracy of access control, and thus solving the technical problem of low access control accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 is a schematic diagram of an application environment of an optional access control method according to an embodiment of the present application;

[0020] Figure 2 is a schematic diagram of a process of an optional access control method according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of an optional access control method according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0025] Figure 7 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0026] Figure 8 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0027] Fig. 9 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0028] Fig.10 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0029] Fig.11 is a schematic diagram of another optional access control method according to an embodiment of the present application;

[0030] Fig.12 is a schematic diagram of an optional access control device according to an embodiment of the present application;

[0031] Fig.13 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described 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 creative work should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0034] For ease of understanding, the following terms are explained:

[0035] Cloud technology refers to a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data computing, storage, processing and sharing.

[0036] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool, which can be used on demand and is flexible and convenient. Cloud computing technology will become an important support. The backend services of the technical network system require a large amount of computing and storage resources, such as video websites, picture websites and more portal websites. With the rapid development and application of the Internet industry, in the future, each item may have its own identification mark, which needs to be transmitted to the backend system for logical processing. Data of different levels will be processed separately. All kinds of industry data need strong system backing support, which can only be achieved through cloud computing.

[0037] Cloud security refers to the general term for security software, hardware, users, organizations, and security cloud platforms based on cloud computing business model applications. Cloud security integrates emerging technologies and concepts such as parallel processing, grid computing, and unknown virus behavior judgment. Through a large number of networked clients, it monitors abnormal software behavior in the network, obtains the latest information on Trojans and malicious programs on the Internet, and sends it to the server for automatic analysis and processing, and then distributes virus and Trojan solutions to each client.

[0038] The main research directions of cloud security include: 1. Cloud computing security, which mainly studies how to ensure the security of the cloud itself and various applications on the cloud, including cloud computer system security, secure storage and isolation of user data, user access authentication, information transmission security, network attack protection, compliance auditing, etc.; 2. Cloudification of security infrastructure, which mainly studies how to use cloud computing to build and integrate security infrastructure resources and optimize security protection mechanisms, including building a large-scale security event, information collection and processing platform through cloud computing technology, realizing the collection and correlation analysis of massive information, and improving the control ability of security events and risk control capabilities of the entire network; 3. Cloud security services, which mainly studies various security services provided to users based on cloud computing platforms, such as antivirus services.

[0039] Trusted application: The application carrier of the internal business system that is authorized by the management end and can be accessed by the terminal, including the application name, application MD5, signature information, etc.

[0040] Reachable zone: A list of internal sites set by the enterprise that end users can access through the zero-trust network.

[0041] Login credentials: After the user successfully logs in to the verification client 902, the verification server specifies an encrypted string for the user, which represents the user's login authorization information, including user information and authorization validity period. It is encrypted and stored on the client.

[0042] Network request credentials: Verify the authorization information issued by the server for a single network request, used to identify the authorization status of the network request.

[0043] Zero Trust Access Control Policy: It consists of process information (trusted applications) that users can use and accessible business sites (accessible areas). When permissions are enabled, users can access any accessible area through any trusted application. The granularity of the Zero Trust Access Control Policy is the logged-in user, allowing different Zero Trust policies to be formulated for different logged-in users.

[0044] Zero Trust Gateway: Deployed at the entrance of enterprise applications and data resources, it is responsible for verifying and forwarding each session request to access enterprise resources;

[0045] Access agent: The terminal access agent is a terminal agent deployed on the controlled device to initiate secure access. It is responsible for initiating requests for trusted identity authentication of the access subject. Once the identity is verified to be trustworthy, an encrypted access connection can be established with the access gateway. It is also the policy enforcement point for access control.

[0046] Direct access: In a zero-trust network access architecture, an application initiates a network access request to a site. After the full-flow proxy hijacks the traffic, it initiates network access to the target site through the full-flow proxy, that is, initiates direct connection access. The full-flow proxy sends the network response of the target site to the application. This access mode is called direct access.

[0047] Proxy access: In a zero-trust network access architecture, an application initiates a network access request to a site. After the full-flow proxy hijacks the traffic, the full-flow proxy initiates traffic forwarding to the intelligent gateway, and the intelligent gateway proxy accesses the target business site. After the access, the intelligent gateway sends the network response of the target site to the full-flow proxy, and the full-flow proxy forwards the network response of the target site to the application. This access mode is called proxy access.

[0048] Access subject: In the network, the party that initiates access, the person / device / application that accesses the intranet business resources, is a digital entity composed of a single person, device, application, etc. or a combination of factors.

[0049] Access object: The party being accessed in the network, that is, the enterprise's intranet business resources, including applications, systems (development and testing environment, operation and maintenance environment, production environment, etc.), data, interfaces, functions, etc.

[0050] Service addressing: In the distributed cascade deployment mode, different services are deployed in different servers. The process of finding the server connection address where the backend services that different business modules of the client care about are deployed is called service addressing.

[0051] Cache thrashing: When the current task is preempted, the content in the current cache needs to be overwritten by the next process that gets the right to run. The next process to be run needs to spend time warming up the cache to achieve good operating efficiency. At the same time, the data in the cache will become invalid during the process of saving and restoring the context. During this period, the cache goes from an invalid state to the last available state, which is called cache thrashing.

[0052] Atomic operation: one or a series of operations supported by the processor that cannot be interrupted, including CAS (Compare & Set) and FAA (Fetch and Add).

[0053] White box cryptography technology: White box cryptography technology is a cryptographic technology that can resist white box attacks. White box cryptography technology can be divided into two categories based on its implementation method: static white box and dynamic white box.

[0054] Static key white box: The algorithm's key is bound and confused with the specified encryption algorithm to generate a key white box. One key corresponds to one key white box, which exists in the form of a file. When developing an application, it needs to be integrated into the project and compiled to generate a binary file.

[0055] Sensitive information: User login information including user ID, password, etc., as well as login credentials (big ticket) and network access credentials (small ticket)

[0056] Business module: A collection of multiple files that complete certain specific functions. The concept of module can not only describe the product more clearly, but also more conveniently specify the content to be installed and uninstalled. For example, we can specify to install only a "threat response" module or an "application management" module.

[0057] Plugin: represents each business execution module, mainly in the form of dll, generally this dll manages multiple sub-modules

[0058] Persistence library: Data persistence is a general term for converting the data structure or object model in memory into a relational model, XML, JSON, binary stream, etc., as well as converting the storage model into the data model in memory. The persistence library is a storage medium for relational models, XML, JSON, binary streams, etc. converted from the data structure or object model in memory and stored in the local disk file or data file of the device. It can be implemented using encrypted files, embedded databases, etc.

[0059] Policy: A set of rules issued by the administrator on the management side for enterprise terminal management. Including patch repair, zero-trust network management, security reinforcement strategy, etc. The policy may contain sensitive information such as tickets, time limit, and validity times.

[0060] Network session: The process of information exchange between a user and a business system, such as the process of sending or receiving data after a client and a server establish a network link. This includes connection establishment and termination, or data sending and receiving.

[0061] Access session: Based on network session, and contains a set of related features. Access session is an abstract concept that is bound to a combination of devices, personnel, network attributes, process attributes, and endpoint attributes for each network session that accesses enterprise intranet business resources (including business applications, core systems, asset data, functional interfaces, etc.).

[0062] Quintuple: Communication term. Refers to the source IP address, source port, destination IP address, destination port, and transport layer protocol related to a network session.

[0063] Application Programming Interface (API): It is a set of predefined interfaces or functions, which are composed of basic information of the interface or function, request paths between the front and back ends, parameters, and request-related protocols. Applications generally encapsulate their service capabilities into APIs and make them available to callers.

[0064] API Gateway: An API management tool located between the front-end and back-end service sets. It is part of the API management system. The API Gateway intercepts all incoming requests and sends them out through the API management system. It is equivalent to a reverse proxy, which is used to accept various API calls from the enterprise, integrate and process the various back-end services required for these calls, and return the corresponding results.

[0065] Cartesian product: also known as direct product, refers to the Cartesian product of two sets X and Y in mathematics, expressed as X×Y, where the first object is a member of X and the second object is a member of all possible ordered pairs of Y. The Cartesian product of multiple sets can be calculated. The calculation method of the Cartesian product of multiple sets is as follows: For example, given sets S1, S2 and S3, the calculation method of the Cartesian product of these three sets is: first calculate the Cartesian product of sets S1 and S2. The Cartesian product of S1 and S2 is a set set H, then the Cartesian product of sets S1, S2 and S3 is actually the Cartesian product of H and S3. The calculation method of the Cartesian product extended to N sets is the same.

[0066] According to one aspect of the embodiments of the present application, an access control method is provided. Optionally, as an optional implementation, the access control method can be but is not limited to being applied to: Figure 1 In the environment shown, the environment may include, but is not limited to, a user device 102 and a server 112 . The user device 102 may include, but is not limited to, a display 104 , a processor 106 , and a memory 108 . The server 112 includes a database 114 and a processing engine 116 .

[0067] The specific process can be as follows:

[0068] Step S102, the user device 102 obtains an interface access request triggered by a target application;

[0069] Steps S104-S106, sending the interface access request to the server 112 via the network 110;

[0070] Steps S108-S110, the server 112 obtains the key access path and behavior characteristics associated with the target application from the database 114, and temporarily uses the key access path and behavior characteristics to perform multiple verifications on the interface access request through the processing engine 116 to obtain verification results;

[0071] Steps S112-S114, sending the verification result to the user device 102 via the network 110, the user device 102 temporarily performs access control on the interface access request based on the verification result via the processor 106, displays the verification result on the display 104, and stores the above verification result in the memory 108.

[0072] remove Figure 1 In addition to the examples shown, the above steps can be completed independently by the user device or the server, or by the user device and the server in collaboration, such as the user device 102 executing the above steps S108-S110, thereby reducing the processing pressure of the server 112. The user device 102 includes but is not limited to handheld devices (such as mobile phones), laptops, tablet computers, desktop computers, vehicle-mounted devices, smart TVs, etc., and the present application does not limit the specific implementation of the user device 102. The server 112 can be a single server or a server cluster consisting of multiple servers, or a cloud server.

[0073] Optionally, as an optional implementation, as Figure 2 As shown, the access control method can be executed by an electronic device, such as Figure 1 The user device or server shown in the figure comprises:

[0074] S202, obtaining an interface access request triggered by a target application;

[0075] S204, obtaining a key access path associated with the target application, wherein the key access path is an access path whose access frequency during the historical access process of the target application satisfies a key access condition;

[0076] S206, using the key access path to perform a check on the interface access request;

[0077] S208, when one verification is passed, obtaining historical behavior features associated with the target application, wherein the historical behavior features are used to characterize the access behaviors exhibited by historical users of the target application during historical access processes;

[0078] S210, performing a secondary verification on the interface access request using the historical behavior characteristics to obtain a secondary verification result;

[0079] S212: Perform access control on the interface access request based on the secondary verification result.

[0080] Optionally, in this embodiment, the above-mentioned access control method can be but is not limited to being applied in API security real-time detection and disposal scenarios, and combined with the static attribute information presented by the target application during historical access and the dynamic attribute information presented by historical users who have visited the target application during historical access, the API access request is fully verified to prevent attackers who have stolen identity information from bypassing the verification, thereby improving the accuracy of API access control.

[0081] Optionally, in this embodiment, triggering an interface access request to a target application may be, but is not limited to, triggering a programming interface of the target application, wherein the programming interface may be, but is not limited to, some predefined interfaces or functions, which are composed of basic information of the interface or function, request paths of the front and back ends, parameters, and request-related protocols, etc. Applications generally encapsulate their own service capabilities into APIs, which are opened up for use by callers.

[0082] Optionally, in this embodiment, the critical access path is an access path whose access frequency of the target application meets the critical access condition during the historical access process. For example, at least one access object whose access frequency of the target application meets the critical access condition during the historical access process is used as an access path point, and then the path composed of access path points can be understood as a critical access path without limitation.

[0083] Optionally, in this embodiment, historical behavior characteristics are used to characterize the access behavior exhibited by historical users of the target application during historical access processes. For example, if historical users exhibit the same behavioral habits at a higher frequency during historical access processes in the same time window, the above behavioral habits can be understood, but are not limited to, as the behavioral characteristics of the historical user in the time window.

[0084] Optionally, in this embodiment, verifying the interface access request using key access paths and behavioral characteristics can be understood but not limited to verifying the interface access request using static reference information and / or dynamic reference information, such as using static reference information and dynamic reference information to verify the interface access request in sequence or simultaneously, and integrating the first verification result corresponding to the static reference information and the second verification result of the dynamic reference information to obtain a third verification result, wherein the third verification result is used to indicate whether the user corresponding to the interface access request is a real user authenticated by the target application.

[0085] Optionally, in this embodiment, in order to improve the verification efficiency, static reference information with a relatively small amount of data is used as reference information for the first verification, and dynamic reference information with a relatively large amount of data is used as reference information for the second verification. It is set that the dynamic reference information is used to perform a second verification on the interface access request only when the first verification passes. In other words, when the first verification fails, the dynamic reference information is temporarily used to perform a second verification on the interface access request, thereby saving unnecessary steps in the verification process.

[0086] It should be noted that by utilizing the key access paths and behavioral characteristics associated with the target application and performing multiple verifications on the interface access request, the attribute information presented by the target application and the user during the historical access process is supplemented into the access control process. At the same time, the information dimension of the attribute information is expanded through the multi-attribute information of the path and behavior, so that when the attacker uses stolen identity information to request access, the access verification can still be accurately performed, thereby achieving the purpose of completing precise access control, thereby realizing the technical effect of improving the accuracy of access control.

[0087] To further illustrate, the optional Figure 3 As shown, an interface access request 310 triggered by a programming interface 304 of a target application 302 is obtained; a key access path 306 associated with the target application 302 is obtained, wherein the key access path 306 is an access path whose access frequency of the target application 302 during historical accesses satisfies a key access condition; the interface access request 310 is verified once using the key access path 306; if the verification passes once, a behavior feature 308 associated with the target application 302 is obtained, wherein the behavior feature 308 is a behavior feature exhibited by historical users who have accessed the target application 302 during historical accesses; a secondary verification is performed on the interface access request 310 using the behavior feature 308 to obtain a secondary verification result, and access control is performed on the interface access request 310 based on the secondary verification result.

[0088] Through the embodiments provided by the present application, an interface access request triggered on a target application is obtained; a key access path associated with the target application is obtained, wherein the key access path is an access path whose access frequency during the historical access process of the target application satisfies the key access condition; the interface access request is verified once using the key access path; if the verification is passed once, the historical behavior characteristics associated with the target application are obtained, wherein the historical behavior characteristics are used to characterize the access behavior exhibited by the historical users of the target application during the historical access process; the interface access request is verified twice using the historical behavior characteristics to obtain the secondary verification result; and access control is performed on the interface access request based on the secondary verification result. By using the key access path and behavior characteristics associated with the target application to verify the interface access request multiple times, the attribute information presented by the target application and the user during the historical access process is supplemented into the access control process, and the information dimension of the attribute information is expanded through the multi-attribute information of the path and behavior, so as to achieve the goal of completing accurate access control when the attacker uses stolen identity information to request access, thereby achieving the technical effect of improving the accuracy of access control.

[0089] As an optional solution, after verifying the interface access request once using the key access path, the method further includes:

[0090] If the first or second verification fails, the interface access request is temporarily blocked or temporarily passed, and the interface access request is verified three times, where the three verifications are used to indicate that the client that has been authenticated by the target application assists in verifying the identity information of the interface access request.

[0091] It should be noted that in order to improve the processing diversity of interface access requests after verification and to meet various needs in different scenarios, the interface access request is (temporarily) blocked when the first or second verification fails, or it can be understood as directly rejecting the response to the interface access request; in addition, the interface access request can also be temporarily passed when the first or second verification fails. This is because when the security of the interface access request meets the basic security conditions, the failure of the first or second verification can be temporarily ignored, and the interface access request can be temporarily passed to ensure the response efficiency of the interface access request.

[0092] To further illustrate, the optional Figure 3 The scenario shown, continues with Figure 4As shown, the interface access request 310 is verified once using the key access path 306; when the first verification passes, the behavior feature 308 associated with the target application 302 is obtained, wherein the behavior feature 308 is the behavior feature exhibited by historical users who have accessed the target application 302 during historical access; the interface access request 310 is verified twice using the behavior feature 308, and when the first verification or the second verification fails, it can be regarded as, but not limited to, a failure of the interface access control, and then the interface access request 310 is temporarily blocked or temporarily passed.

[0093] Through the embodiments provided in the present application, when the first or second verification fails, the interface access request is temporarily blocked or temporarily passed, and the interface access request is verified three times, thereby achieving the purpose of improving the processing diversity of the verified interface access request to meet various needs in different scenarios, thereby achieving the technical effect of taking into account both the response efficiency of the interface access request and the accuracy of the interface access control.

[0094] As an optional solution, after temporarily blocking or temporarily passing the interface access request and performing three checks on the interface access request, the method further includes:

[0095] When the interface access request is temporarily approved and fails three verifications, the account associated with the interface access request is banned.

[0096] It should be noted that in order to improve the processing diversity of interface access requests after verification and to meet various needs in different scenarios, the interface access request will be blocked if the first or second verification fails, or it can be understood as directly rejecting the response to the interface access request; in addition, the interface access request can be temporarily passed if the first or second verification fails. This is because when the security of the interface access request meets the basic security conditions, the failure of the first or second verification can be temporarily ignored, and the interface access request is temporarily passed to ensure the response efficiency of the interface access request. However, three subsequent verifications will be performed, and if the three verifications fail, the account associated with the interface access request will be banned. In this way, both the response efficiency of the interface access request and the accuracy of interface access control are taken into account.

[0097] Through the embodiments provided in the present application, when an interface access request is temporarily approved and fails three verifications, the account associated with the interface access request is banned, thereby achieving the purpose of increasing the processing diversity of the interface access requests after verification to meet various needs in different scenarios, thereby achieving the technical effect of taking into account both the response efficiency of the interface access request and the accuracy of the interface access control.

[0098] As an optional solution, after temporarily blocking or temporarily passing the interface access request and performing three checks on the interface access request, the method further includes:

[0099] When the interface access request is temporarily blocked, three checks are passed, and the current access volume of the target application is greater than or equal to the preset threshold, a permission prompt message is sent to the target client, where the permission prompt message is used to prompt the target client to put the interface access request into a whitelist, and access requests in the whitelist are prohibited from being temporarily blocked.

[0100] Optionally, in this embodiment, the identity authentication information is used to verify whether the first user corresponding to the target client is the second user authenticated by the target application, such as by using face, fingerprint, voiceprint, verification code, etc. to verify whether the first user is the second user authenticated by the target application. Figure 5 As shown, identity verification information 502 prompting the first user to perform face verification, after collecting the face information 504 of the first user, will be compared with the face information 504 of the second user to determine whether the first user is the second user authenticated by the target application.

[0101] It should be noted that, considering the current large amount of access, it is necessary to improve the response efficiency of the interface access request as much as possible, and the access control method in this embodiment may have a negative impact on the response efficiency of the interface access request. Therefore, the user can temporarily put the interface access request into the whitelist to prohibit blocking the interface access request and ensure the response efficiency of the interface access request.

[0102] Through the embodiments provided by the present application, when an interface access request is temporarily blocked, three checks are passed, and the current access volume of the target application is greater than or equal to a preset threshold, a permission prompt information is sent to the target client, wherein the permission prompt information is used to prompt the target client to put the interface access request into a whitelist, and the access requests in the whitelist are prohibited from being temporarily blocked, thereby achieving the purpose of ensuring the response efficiency of the interface access request in special scenarios where the current access volume is large, thereby realizing the technical effect of improving the response efficiency of the interface access request.

[0103] As an optional solution, three checks are performed on the interface access request, including:

[0104] S1-1, sending identity authentication information to a target client that has been authenticated by a target application, wherein the identity authentication information is used to instruct the target client to assist in verifying identity information of an interface access request;

[0105] S1-2, when verification failure information is received from the target client, or verification success information is not received from the target client within a preset time period, determining that the three verifications have failed;

[0106] S1-3, upon receiving verification success information fed back by the target client, determining that the three verifications have passed.

[0107] It should be noted that in order to further improve the accuracy of interface access control while taking into account the response efficiency of interface access requests, identity confirmation information will be sent to the target client authenticated by the target application to confirm whether the interface access request is triggered by the second user authenticated by the target application.

[0108] To further illustrate, the optional Figure 6 As shown in (a) of FIG. 1 , the target client 602 authenticated by the target application is sent identity confirmation information 604, wherein the identity confirmation information is used to confirm whether the interface access request is triggered by the second user authenticated by the target application; after responding to the click operation triggered by the virtual button “not logged in by myself”, further as shown in FIG. Figure 6 As shown in (b) in the figure, risk warning information is displayed, wherein the risk warning information is used to prompt that it has been confirmed that the access is not made by the person himself, and a security assistant (which can be understood as a risk handling method with higher authority, or can also be understood as manual handling) will contact you later to handle the risk.

[0109] Through the embodiments provided by the present application, identity authentication information is sent to a target client that has been authenticated by a target application, wherein the identity authentication information is used to instruct the target client to assist in verifying the identity information of an interface access request; upon receiving verification failure information fed back by the target client, or upon not receiving verification success information fed back by the target client within a preset time period, it is determined that the three verifications have failed; upon receiving verification success information fed back by the target client, it is determined that the three verifications have passed, thereby achieving the purpose of further improving the accuracy of interface access control while taking into account the response efficiency of interface access requests, thereby realizing the technical effect of improving the accuracy of interface access control.

[0110] As an optional solution, use the key access path to perform a check on the interface access request, including:

[0111] S5-1, obtaining at least one target object in the process of requesting access to a target application through an interface access request, wherein the target object includes at least one of the following: an application device, an application, and a programming interface;

[0112] S5-2, a path corresponding to the interface access request is formed by at least one target object;

[0113] S5-3, when the path similarity between the access path and the key access path is greater than or equal to the path similarity threshold, determining that the interface access request passes the verification of the key access path;

[0114] S5-4: When the path similarity between the access path and the key access path is less than the path similarity threshold, it is determined that the interface access request fails to pass the verification of the key access path.

[0115] To further illustrate, the optional Figure 7 As shown, the target object in the process of requesting access to the target application through the interface access request is obtained, such as application device 2, application 1, and programming interface 3; then the path composed of application device 2, application 1, and programming interface 3 is obtained, and the path composed of application device 2, application 1, and programming interface 3 is the path corresponding to the interface access request; when the path similarity between the path corresponding to the interface access request and the key access path is greater than or equal to the path similarity threshold, it is determined that the interface access request has passed the verification of the key access path; when the path similarity between the path path and the key access path is less than the path similarity threshold, it is determined that the interface access request has not passed the verification of the key access path.

[0116] As an optional solution, use behavioral characteristics to perform secondary verification on interface access requests, including:

[0117] S6-1, counting the behavior data in each time period during the process of requesting access to the target application through the interface access request, wherein the behavior data includes at least one of the following: call success rate, response time and number of requests;

[0118] S6-2, constructing target behavior features associated with interface access requests using behavior data in each time period;

[0119] S6-3, when the feature similarity between the target behavior feature and the behavior feature is greater than or equal to the feature similarity threshold, determining that the interface access request passes the verification of the behavior feature;

[0120] S6-4: When the feature similarity between the target behavior feature and the behavior feature is less than the feature similarity threshold, it is determined that the interface access request fails to pass the verification of the behavior feature.

[0121] To further illustrate, the optional Figure 8 As shown, the behavior data in each time period (window) during the process of requesting access to the target application through the interface access request is counted, such as the call success rate (10%), response time (5 seconds), and number of requests (10 times) in time window 1, the call success rate (90%), response time (3 seconds), and number of requests (100 times) in time window 2, and the call success rate (0%), response time (1 second), and number of requests (1 time) in time window 3; the behavior data in each time period (window) is then used to construct the target behavior feature associated with the interface access request; when the feature similarity between the target behavior feature and the behavior feature is greater than or equal to the feature similarity threshold, it is determined that the interface access request passes the verification of the behavior feature; when the feature similarity between the target behavior feature and the behavior feature is less than the feature similarity threshold, it is determined that the interface access request fails the verification of the behavior feature.

[0122] As an optional solution, access control is performed on interface access requests based on the secondary verification result, including:

[0123] S2-1, if the secondary verification result fails, access restriction control is performed on the interface access request;

[0124] S2-2, if the secondary verification result passes, obtaining historical user information associated with the target application, and user reference information involved in the process of requesting access to the target application through an interface access request;

[0125] S2-3, when the information similarity between the user reference information and the historical user information is greater than or equal to the information similarity threshold, determining that the interface access request passes the verification;

[0126] S2-4, when the information similarity between the user reference information and the historical user information is less than the information similarity threshold, it is determined that the interface access request has not passed the verification, and access restriction control is performed on the interface access request.

[0127] Optionally, in this embodiment, user reference information can be understood, but is not limited to, as other reference information other than user identity information associated with the real user authenticated by the target application. In the process of using user reference information for verification, the problem of malicious interface access requests being erroneously responded to due to identity information theft can be avoided, thereby improving the accuracy of interface access control.

[0128] Through the embodiments provided by the present application, when the secondary verification result fails, access restriction control is performed on the interface access request; when the secondary verification result passes, historical user information associated with the target application and user reference information involved in the process of requesting access to the target application through the interface access request are obtained; when the information similarity between the user reference information and the historical user information is greater than or equal to the information similarity threshold, it is determined that the interface access request has passed the verification; when the information similarity between the user reference information and the historical user information is less than the information similarity threshold, it is determined that the interface access request has not passed the verification, and access restriction control is performed on the interface access request, thereby achieving the purpose of avoiding the problem of malicious interface access requests being erroneously responded to due to identity theft, thereby achieving the technical effect of improving the accuracy of interface access control.

[0129] As an optional solution, for ease of understanding, the above access control method is applied to the API security real-time detection and disposal scenario, and real-time monitoring is adopted. The API key access path and the behavioral feature data in each time window are used as the judgment method to distinguish between normal API calls and abnormal API calls. Then, the misjudgment rate is reduced by re-authenticating the access subject identity, dynamically adjusting the API behavior feature parameters, pushing security events and user interactive confirmation, etc., to achieve a certain balance between the efficiency of handling abnormal APIs and user experience.

[0130] Optionally, in this embodiment, the scenarios of API requests and responses are divided into front-end and back-end, and a new API security real-time detection scheme is proposed. On the one hand, two means are combined to detect in real time whether the current interface request belongs to an abnormal API call, such as firstly associating the API call initiated by a client application with the device information (device ID and the hardware and software information of the device, etc.) and the characteristic information of the application itself, forming an API key access path combined with elements such as user-device-application-API, and organizing it with the user as the dimension. In the process of API request and response, the API access path data of each user is dynamically maintained. Once the current access path of a user does not match the commonly used key access path stored in the system, the user is subjected to secondary identity authentication to strengthen identity verification. Through the dynamic association of login identity, device and API call, the high-frequency attack of the attacker on the enterprise API through automated means is identified and prevented. Secondly, the trend distribution, call success rate, time consumption and other statistical data in the API call process are formed into different behavioral feature data with the user and target API as the dimension, and different in different time intervals, and this is used as the basis for real-time detection in the process of API forwarding and calling. On the other hand, when there is an abnormal risk in real-time monitoring of API calls, the user's secondary identity verification and dynamic setting of parameters to execute elastic expansion and contraction of restriction conditions, as well as the push of security events and user interactive confirmation, can achieve self-service release of real-time API interception, improve the accuracy of API interception, and reduce the data security risks and business threats faced by enterprises to a certain extent.

[0131] It should be noted that, compared with the traditional verification method, this embodiment adds key access paths and time window-based behavioral feature data comparison to the real-time API identification logic, which is more accurate than the simple and crude filtering method adopted by the serial device in the prior art (for example, only judging the frequency). On the other hand, compared with the method of adopting big data analysis, then carrying complex feature calculation tasks through the real-time computing platform, and then performing bypass blocking (generally, the API gateway is linked with the real-time computing platform, and the API gateway is given the ability to receive blocking commands and perform bypass blocking through plug-ins or modules), it reduces the computing cost of the enterprise, and integrates the user's secondary identity verification and dynamic setting parameters (to elastically expand and shrink the execution restrictions), as well as the push of security events and user interactive confirmation (to achieve self-service release of real-time API interception and reduce the misjudgment rate), to achieve a certain balance between the efficiency of handling abnormal APIs and user experience.

[0132] To further illustrate, the optional Fig. 9As shown, in the device, the verification client 902 and the server detect in real time whether the enterprise API initiated by each application in the terminal is a normal call. If it is abnormal, the verification client 902 will pop up a confirmation box to the terminal user based on the real-time push of the server. Through the push of security events and user interactive confirmation, self-service release of API real-time interception is achieved, thereby improving the accuracy of API interception.

[0133] Optionally, in this embodiment, if Fig.10 and Fig.11 As shown, the solution proposed in this embodiment is applicable to security detection and disposal scenarios of API types with front-end and back-end separation, and can be a C / S mode API request scenario initiated from an independent application in a certain device to the enterprise back-end service. The API can be a list of interfaces scattered among various back-end services, or an interface type uniformly managed by an API gateway, or a mixed deployment scenario, that is, one part is not connected to the API gateway, and the other part is uniformly controlled, forwarded and managed by the API gateway. The execution components of this embodiment include a verification client 902, a verification server, an intelligent gateway and an API gateway, etc. Among them, for the API type uniformly managed by the API gateway, a zero-trust network is integrated with the existing API gateway, as follows Fig.10 As shown, when the smart gateway detects the corresponding API call, it forwards it to the API gateway for forwarding processing. For independent and decentralized APIs that are not connected to the API gateway (due to historical reasons such as business particularity or resource constraints, the prior art recommends unified access to the API gateway), the smart gateway participates in the execution of security detection and automatic disposal in this embodiment, as follows Fig.11 shown.

[0134] Optionally, in this embodiment, whether it is Fig.10 or Fig.11 (i.e., whether there is access to the API gateway), the verification client and the server form the access control flow. The control flow mainly completes the authentication of the logged-in user, application detection and issuance of access tickets (the access agent initiates a ticket application to the verification server through the verification client, and after the verification server responds, the verification client responds back to the access agent) and authentication (the gateway initiates ticket authentication to the verification server with the ticket). As important roles in the data flow, the access agent and the intelligent gateway bear the responsibility of traffic proxy in the zero-trust system. The terminal access agent generally uses a four-layer traffic proxy method to forward the original API request traffic initiated by the application to the intelligent gateway through full-flow hijacking TUN / TAP or network filtering driver. In zero-trust network access, the traffic initiated by the user first reaches the intelligent gateway through the access agent, and then the gateway verifies the ticket to the control flow (i.e., the verification server), and then replaces the access subject to perform actual access to the business site to complete the complete API request process.

[0135] Optionally, in this embodiment, the network access traffic initiated by each application in the terminal will be hijacked by the access proxy and transferred to the target service via the intelligent gateway. The access proxy adopts a four-layer traffic proxy method, does not parse the application layer protocol of the traffic, and most of the existing traffic is TLS encrypted, which is generally not decrypted at the terminal. Therefore, the terminal access proxy does not distinguish between API calls or non-API calls. The access proxy uniformly initiates traffic authentication to the control flow (optionally, the control flow is mainly composed of the verification client and the verification server), and after the authentication is passed, it is forwarded to the intelligent gateway by the access proxy. The CA certificate is deployed on the gateway side to perform SSL / TLS decryption. That is, after the access traffic initiated by the access subject reaches the intelligent gateway via the access proxy, the intelligent gateway can decrypt the HTTPS message and parse the message information, and further judge whether the user's request traffic belongs to the API call based on the API judgment rules based on the parsed information. If it belongs to the API request traffic, it is forwarded to the API gateway or the target backend service (for scenarios without access to the API gateway).

[0136] The API judgment rules are set by the enterprise administrator (based on the API specified filtering rules used by the enterprise, such as RESTful, XML-based SOAP protocol or SDKs provided by various programming languages, etc.). After the intelligent gateway decrypts the request content, it identifies whether it is an API request traffic based on this rule. If it meets the rules, it is forwarded to the API gateway node or backend business server based on the service access address in the request.

[0137] In the above-mentioned process of API traffic detection and forwarding, the application information and device information that initiates the API call will collect user information, device information and application information when the data flow requests traffic authentication to the control flow (the request for a network access ticket must at least carry user identity information, device, original application information and traffic five-tuple information, etc., and the server decides whether to issue an access ticket based on this information). After the intelligent gateway identifies the API call traffic (optionally, the intelligent gateway can decrypt the HTTPS message and parse the message information, and further determine whether the user's request traffic belongs to an API call based on the API judgment rules based on the parsed information), when the access ticket is sent to the verification server to perform ticket verification, the verification server collects user, device, application and target API information. The server associates the API call initiated by the device and the relevant application in the device with the device information and the characteristic information of the application itself, forming an API key access path composed of elements such as user-device-application-API, and organizes it by user. Among them, the characteristic information of the application itself refers to the static and dynamic characteristics related to the software process that initiates the API call, including static characteristic information such as the absolute path of the software, the hash of the process executable file, the application signature, and the application copyright information, as well as dynamic characteristic information such as which system account (SYSTEM or the current operating system account) started the application and the command line information for starting the process.

[0138] Optionally, in this embodiment, the API key access path is based on the user as the dimension, and the enterprise administrator can set a certain time period as the statistical time. During the time period, the API call information initiated by the user is sent to the verification server, and the top N "device-application-API" items with higher frequency counted by the verification server are used as the user's API key access path (list). For example, user sam has initiated calls to API_1, API_2...API_n using applications app-A, app-B and app-C in commonly used devices dev1 and dev2. The Cartesian product composed of the device set {dev1, dev2}, the application set {app-A, app-B, app-C} and the API set {API_1, API_2...API_n} that initiated the API call is the key access path or key access path list related to user sam.

[0139] The API key access paths based on the user dimension will be stored on the server. In the above example, the range of APIs initiated by user sam on devices dev1 and dev2 using applications app-A, app-B and app-C can cover {API_1, API_2…API_n}. The server can store the Cartesian product of the device set {dev1, dev2}, the application set {app-A, app-B, app-C} and the API set {API_1, API_2…API_n} that initiates API calls. If the API ranges initiated by user sam on devices dev1 and dev2 are different, for example, the API call function initiated by application app-A in dev1 covers API_1, API_2 and API_3, while the API call function initiated by application app-A in dev2 only includes API_1, then dev1, app-A and {API_1, API_2, API_3} and dev2, app-A and {API_1} are two independent access paths, and these key access paths will be tried first when filtering.

[0140] Optionally, in this embodiment, filtering of API key access paths occurs during the process of the gateway initiating ticket verification to the verification server. Optionally, when the intelligent gateway sends the network access ticket to the verification server to perform ticket verification, the verification server collects the user, device, application and target API information related to the current API request traffic. The verification server compares the device, application and target API information with the key access path list to which the user belongs. This process is real-time serial. Since the user-related key access path list stored on the server is added to the cache in advance, this matching process is a fast filtering at the memory level, and the performance consumption and execution efficiency can be controlled within a set range. If the access path (device, application and target API) corresponding to the current API request traffic is in the key access path list corresponding to the user, the detection is passed, otherwise, similar to the behavioral feature data in this embodiment, it will trigger the interaction of the terminal user or directly block the API request.

[0141] Optionally, in this embodiment, the behavior characteristics of the API are affected by changes in business, API call groups, network environment and many other factors from the time the API is released to the actual use in the enterprise. First, the call success rate, response time and the like are the basic characteristics of the API. Under normal circumstances, the success rate and response time are maintained in a relatively stable range. If there is a fluctuation beyond the set parameters, it may be an abnormality of the service relied on by a third party or there is a risk of attack by an attacker. Therefore, the access of abnormal API calls needs to be included for intervention. Secondly, the API call behavior is greatly affected by the caller. Different terminal users (referring to the login account of the verification client 902, non-system account) have different trend distributions for API calls. For example, the calls to APIs by groups in some positions in the enterprise are scattered and the frequency is low, while some groups are centralized and access specific APIs at high frequency. Moreover, the same user has different API request volumes in different time windows, showing different statistical data. For example, some users have more requests for specific APIs during working hours, while some users use automation tools to have more API call actions in the early morning. Therefore, we choose to form statistical data such as trend distribution, call success rate, and time consumption during the API call process to form different behavioral feature data in different time intervals based on users and target APIs, and use this as a basis to perform real-time detection during API forwarding and calling.

[0142] Specifically, the statistics data directly related to API calls, such as call success rate and response time, can be directly collected by the intelligent gateway. The API request volume can be collected by the intelligent gateway, or it can be automatically accumulated by the verification server itself based on the request type (statistical API type request) during ticket verification. Whether it is the API request volume, call success rate or response time, it is based on the user and the target API as the dimension, and is counted within the set time window. The size of the time window is set by the enterprise administrator. For example, time periods can be distinguished, or working days can be used as the division unit. After a certain period of statistics, a relatively stable behavioral feature data for different users and target APIs is formed, which is stored in the verification server with a similar idea to the key access path. After the verification server receives the ticket verification of the access request of the specified user to access a specific API, it verifies whether the relevant data of the current API request traffic conforms to the historical behavioral characteristics. Of course, for the call success rate and response time, the current API request traffic has no corresponding data because it has not completed the complete process of request and response. These two items mainly depend on the statistical data of the API traffic that has been processed (completed the complete process of request and response) within the current time window. If the call frequency, duration, and call success rate of the current API in the current time window meet the behavioral characteristics of the user in the corresponding time window, the detection passes. Otherwise, similar to the key access path above, it will trigger the end user's interaction or directly block the API request.

[0143] To further illustrate, optionally, for example, user sam has a 90% call success rate for the target API_e within the time window [t3, t4], the call frequency is high, and the call time is between 5ms and 20ms. As long as the difference between the corresponding indicators of the API_e that has completed the call within the time window [t3, t4] and the above parameters is controlled within a reasonable range, it is considered that the API call of this user meets the behavioral characteristics of the API_e request.

[0144] For another example, based on the behavior feature data stored on the server, user sam's call to the target API_d should have a 91% call success rate within the time window [t1, t2]. However, during the actual detection, it was found that the API_d with complete traffic that had completed the request and response (the current API has not completed the request and response, so the API data that has been processed within the time window) had a call success rate of less than 91% within the time window [t1, t2], and the difference exceeded the set parameters, so it was considered abnormal. Or, based on the behavior feature data stored on the server, user sam's call to the target API_d should have been less than 10 calls within the time window [t5, t6], but in fact, it triggered hundreds of calls. Because the difference exceeded the set parameters, it was considered abnormal.

[0145] Optionally, in this embodiment, the API behavior feature data can be set as a benchmark value by the API provider and the enterprise administrator, and the value can be obtained by comprehensive calculation of the access data of each user for different target APIs. In the next step, real-time filtering and detection are performed when the ticket verification is performed on the verification service. Since the data is loaded into the cache in advance, and the cache design takes into account the efficiency of hot data hits (such as LFU cache, etc., using the service's memory cache and distributed cache, such as redis, etc. to build a multi-level cache), the efficiency can be controlled within a certain range during real-time filtering. However, due to API call individuals, when the business changes or encounters emergencies, they may initiate API call behaviors that are different from historical characteristics. This part of API requests initiated by compliant users will be counted as abnormal API calls, and the existing technology basically blocks them directly. This embodiment takes into account the reduction of false alarm rate, and realizes an effect of real-time interception and self-help relief of API through linkage with users, so as to achieve a certain balance between the efficiency of handling abnormal APIs and user experience.

[0146] To further illustrate, for example, when the verification server detects that the access path of the current API call does not match the key access path corresponding to the user, the current access is blocked, and the verification client 902 is triggered to remind the user to complete the identity secondary verification method including face verification, SMS verification, and multi-factor token authentication through a pop-up box. After the user completes the authentication, the access path corresponding to the user can be further dynamically expanded, such as adding new devices and applications that initiate API access. In addition, you can also choose to allow this access and trigger a security event asynchronously, such as when the verification server detects that the characteristics of the current API request in the corresponding time window do not match the behavioral characteristics corresponding to the user, the current access is blocked, and the verification client 902 is triggered to remind the user to complete the identity secondary verification method including face verification, SMS verification, and multi-factor token authentication through a pop-up box. After the user completes the authentication, the characteristic parameters of the user's access to a specific API can be further dynamically expanded within the set range (for example, setting the upper limit of the adjustment time and related parameters), such as ignoring the verification of factors such as the corresponding API call frequency within a certain time period. Or, the push of security events and user interactive confirmation. When the verification server detects that the access path of the current API call does not match the key access path corresponding to the user, it temporarily allows the access and asynchronously sends the security event to the verification client 902 through the server, and asks the end user to confirm whether it is his own behavior in the form of a pop-up box reminder, including the user, time point, and business category of the API call (to avoid exposing detailed information related to the API). If the user chooses a behavior that is not triggered by himself, it can be further handed over to the security team for one-on-one handling.

[0147] Through the embodiments provided in this application, the accuracy of API interception can be improved, which can alleviate the data security risks and business threats faced by enterprises to a certain extent. It is more accurate than the simple and crude filtering method of serial devices in related technologies (for example, only judging the frequency). Compared with the method of using big data analysis, then carrying out complex feature calculation tasks through a real-time computing platform, and then performing bypass blocking, it can reduce the computing cost of the enterprise to a certain extent and improve the efficiency of handling abnormal API calls.

[0148] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0149] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0150] According to another aspect of the embodiments of the present application, an access control device for implementing the above access control method is also provided. Fig.12 As shown, the device comprises:

[0151] A first acquisition unit 1202 is used to acquire an interface access request triggered by a target application;

[0152] The second acquisition unit 1204 is used to acquire a key access path associated with the target application, wherein the key access path is an access path whose access frequency during the historical access process of the target application satisfies the key access condition;

[0153] A first verification unit 1206, configured to perform a verification on the interface access request using a key access path;

[0154] The third acquisition unit 1208 is used to acquire the historical behavior characteristics associated with the target application program when the verification is passed once, wherein the historical behavior characteristics are used to characterize the access behaviors exhibited by the historical users of the target application program during the historical access process;

[0155] The second verification unit 1210 is used to perform a secondary verification on the interface access request using the historical behavior characteristics to obtain a secondary verification result;

[0156] The first control unit 1212 is used to perform access control on the interface access request based on the secondary verification result.

[0157] For specific embodiments, reference may be made to the examples shown in the above access control device, which will not be described in detail in this example.

[0158] As an optional solution, the device also includes:

[0159] The third verification unit is used to temporarily block or temporarily pass the interface access request after verifying the interface access request once using the key access path, if the first or second verification fails, and to verify the interface access request three times, wherein the three verifications are used to indicate that the client that has been authenticated by the target application assists in verifying the identity information of the interface access request.

[0160] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0161] As an optional solution, the device also includes:

[0162] The first processing unit is used to temporarily block or temporarily pass the interface access request and perform three verifications on the interface access request. If the interface access request is temporarily passed and fails the three verifications, the account associated with the interface access request is banned.

[0163] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0164] As an optional solution, the device also includes:

[0165] The second processing unit is used to send permission prompt information to the target client after temporarily blocking or temporarily passing the interface access request and performing three checks on the interface access request, when the interface access request is temporarily blocked, the three checks are passed, and the current access volume of the target application is greater than or equal to a preset threshold, wherein the permission prompt information is used to prompt the target client to put the interface access request into a whitelist, and the access requests in the whitelist are prohibited from being temporarily blocked.

[0166] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0167] As an optional solution, the third verification unit includes:

[0168] A sending module, used to send identity authentication information to a target client that has been authenticated by a target application, wherein the identity authentication information is used to instruct the target client to assist in verifying identity information of an interface access request;

[0169] A first determination module is used to determine that the three verifications have failed when verification failure information fed back by the target client is received or verification success information fed back by the target client is not received within a preset time period;

[0170] The second determination module is used to determine whether the three verifications have passed when receiving the verification success information fed back by the target client.

[0171] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0172] As an optional solution, the first verification unit 1206 includes:

[0173] An acquisition module, used to acquire at least one target object in the process of requesting access to a target application through an interface access request, wherein the target object includes at least one of the following: an application device, an application program, and a programming interface;

[0174] A composition module, used for composing a path corresponding to an interface access request from at least one target object;

[0175] A third determination module, configured to determine that the interface access request passes the verification of the key access path when the path similarity between the access path and the key access path is greater than or equal to a path similarity threshold;

[0176] The fourth determination module is used to determine that the interface access request fails to pass the verification of the key access path when the path similarity between the access path and the key access path is less than the path similarity threshold.

[0177] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0178] As an optional solution, the second verification unit 1210 includes:

[0179] A statistics module, used to count the behavior data in various time periods during the process of requesting access to the target application through the interface access request, wherein the behavior data includes at least one of the following: call success rate, response time and number of requests;

[0180] A construction module, used to construct target behavior features associated with interface access requests using behavior data in various time periods;

[0181] a fifth determination module, configured to determine that the interface access request passes the verification of the historical behavior feature when the feature similarity between the target behavior feature and the historical behavior feature is greater than or equal to a feature similarity threshold;

[0182] The sixth determination module is used to determine that the interface access request fails to pass the verification of the historical behavior feature when the feature similarity between the target behavior feature and the historical behavior feature is less than a feature similarity threshold.

[0183] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0184] As an optional solution, the first control unit 1212 includes:

[0185] A second control unit is used to perform access restriction control on the interface access request when the secondary verification result fails;

[0186] A fourth acquisition unit, configured to acquire historical user information associated with the target application and user reference information involved in a process of requesting access to the target application through an interface access request, if the secondary verification result passes;

[0187] A seventh determination module, configured to determine that the interface access request passes verification when the information similarity between the user reference information and the historical user information is greater than or equal to an information similarity threshold;

[0188] The third control unit is used to determine that the interface access request has not passed the verification and perform access restriction control on the interface access request when the information similarity between the user reference information and the historical user information is less than the information similarity threshold.

[0189] For specific embodiments, reference may be made to the examples shown in the above access control method, which will not be described in detail in this example.

[0190] According to another aspect of the embodiment of the present application, an electronic device for implementing the above access control method is also provided. The electronic device can be but is not limited to: Figure 1 The user device 102 or the server 112 shown in FIG. 1 is used as an example to illustrate the electronic device as the user device 102. Fig.13 As shown, the electronic device includes a memory 1302 and a processor 1304. The memory 1302 stores a computer program, and the processor 1304 is configured to execute the steps in any of the above method embodiments through the computer program.

[0191] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0192] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0193] S1, obtaining an interface access request triggered by a target application;

[0194] S2, obtaining a key access path associated with the target application, wherein the key access path is an access path whose access frequency during the historical access process of the target application satisfies a key access condition;

[0195] S3, using the key access path to verify the interface access request;

[0196] S4, when the verification is passed once, obtaining historical behavior features associated with the target application, wherein the historical behavior features are used to characterize the access behaviors exhibited by historical users of the target application during historical access processes;

[0197] S5, performing secondary verification on the interface access request using historical behavior characteristics to obtain secondary verification results;

[0198] S6: Perform access control on the interface access request based on the secondary verification result.

[0199] Alternatively, a person skilled in the art may understand that: Fig.13 The structure shown is for illustration only. Fig.13 The structure of the electronic device is not limited. Fig.13 More or fewer components (such as network interfaces, etc.) as shown in, or with Fig.13 Different configurations shown.

[0200] Among them, the memory 1302 can be used to store software programs and modules, such as the program instructions / modules corresponding to the access control method and device in the embodiments of the present application. The processor 1304 executes various functional applications and data processing by running the software programs and modules stored in the memory 1302, that is, to implement the above-mentioned access control method. The memory 1302 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1302 may further include a memory remotely located relative to the processor 1304, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 1302 may be specifically, but not limited to, used to store information such as interface access requests, key access paths, and behavioral characteristics. As an example, such as Fig.13 As shown, the memory 1302 may include, but is not limited to, the first acquisition unit 1202, the second acquisition unit 1204, the first verification unit 1206, the third acquisition unit 1208, the second verification unit 1210, and the first control unit 1212 in the access control device. In addition, other module units in the access control device may also be included but are not limited to, which will not be repeated in this example.

[0201] Optionally, the transmission device 1306 is used to receive or send data via a network. Specific examples of the network may include a wired network and a wireless network. In one example, the transmission device 1306 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers via a network cable so as to communicate with the Internet or a local area network. In one example, the transmission device 1306 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0202] In addition, the electronic device further includes: a display 1308 for displaying information such as the interface access request, key access path, and behavior characteristics; and a connection bus 1310 for connecting various module components in the electronic device.

[0203] In other embodiments, the user device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes through network communication. Among them, the nodes may form a peer-to-peer (P2P) network, and any form of computing device, such as a server, user device, or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0204] According to one aspect of the present application, a computer program product is provided, the computer program product comprising a computer program / instruction, the computer program / instruction comprising a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication part, and / or installed from a removable medium. When the computer program is executed by a central processing unit, various functions provided by the embodiments of the present application are executed.

[0205] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0206] It should be noted that the computer system of the electronic device is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0207] The computer system includes a central processing unit (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) or the program loaded from the storage part to the random access memory (RAM). In the random access memory, various programs and data required for system operation are also stored. The central processing unit, the read-only memory and the random access memory are connected to each other through a bus. The input / output interface (I / O interface) is also connected to the bus.

[0208] The following components are connected to the input / output interface: an input part including a keyboard, a mouse, etc.; an output part including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage part including a hard disk, etc.; and a communication part including a network interface card such as a local area network card, a modem, etc. The communication part performs communication processing via a network such as the Internet. A drive is also connected to the input / output interface as needed. Removable media, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., are installed on the drive as needed so that the computer program read therefrom is installed into the storage part as needed.

[0209] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication part, and / or installed from a removable medium. When the computer program is executed by a central processing unit, various functions defined in the system of the present application are executed.

[0210] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods provided in the above-mentioned various optional implementations.

[0211] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0212] S1, obtaining an interface access request triggered by a target application;

[0213] S2, obtaining a key access path associated with the target application, wherein the key access path is an access path whose access frequency during the historical access process of the target application satisfies a key access condition;

[0214] S3, using the key access path to verify the interface access request;

[0215] S4, when the verification is passed once, obtaining historical behavior features associated with the target application, wherein the historical behavior features are used to characterize the access behaviors exhibited by historical users of the target application during historical access processes;

[0216] S5, performing secondary verification on the interface access request using historical behavior characteristics to obtain secondary verification results;

[0217] S6: Perform access control on the interface access request based on the secondary verification result.

[0218] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the electronic device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0219] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0220] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which can be personal computers, servers or network devices, etc.) to execute all or part of the steps of the methods of each embodiment of the present application.

[0221] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0222] In the several embodiments provided in the present application, it should be understood that the disclosed user equipment can be implemented in other ways. Among them, the device embodiments described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0223] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0224] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0225] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. An access control method, characterized in that: include: Obtaining the interface access request triggered by the target application; Acquire a key access path associated with the target application, wherein the key access path is an access path whose access frequency of the target application in a historical access process meets a key access condition; Performing a check on the interface access request using the key access path; In the case where the one-time verification passes, obtaining the historical behavior characteristics associated with the target application, wherein the historical behavior characteristics are used to characterize the access behaviors exhibited by the historical users of the target application during the historical access process; Performing a secondary verification on the interface access request using the historical behavior characteristics to obtain a secondary verification result; Access control is performed on the interface access request based on the secondary verification result.

2. The method according to claim 1, characterized in that After verifying the interface access request once using the key access path, the method further includes: In the event that the first check or the second check fails, the interface access request is temporarily blocked or temporarily allowed, and the interface access request is checked three times, wherein the three checks are used to indicate that the authenticated client of the target application assists in verifying the identity information of the interface access request.

3. The method according to claim 2, characterized in that After temporarily blocking or temporarily passing the interface access request and checking the interface access request three times, the method further includes: When the interface access request is temporarily passed and the three verifications fail, the account associated with the interface access request is blocked.

4. The method according to claim 3, characterized in that After temporarily blocking or temporarily passing the interface access request and checking the interface access request three times, the method further includes: When the interface access request is temporarily blocked, the three checks are passed, and the current access volume of the target application is greater than or equal to a preset threshold, a permission prompt message is sent to the target client, wherein the permission prompt message is used to prompt the target client to put the interface access request into a whitelist, and the access requests in the whitelist are prohibited from being temporarily blocked.

5. The method according to claim 3, characterized in that: The performing three checks on the interface access request comprises: Sending identity authentication information to a target client that has been authenticated by the target application, wherein the identity authentication information is used to instruct the target client to assist in verifying the identity information of the interface access request; When verification failure information fed back by the target client is received, or verification success information fed back by the target client is not received within a preset time period, determining that the three verifications have failed; When the verification success information fed back by the target client is received, it is determined that the three verifications are passed.

6. The method according to claim 1, characterized in that The verifying the interface access request once by using the key access path includes: Acquire at least one target object in the process of requesting access to the target application through the interface access request, wherein the target object includes at least one of the following: an application device, an application program, and a programming interface; The at least one target object forms a path corresponding to the interface access request; In a case where the path similarity between the access path and the key access path is greater than or equal to a path similarity threshold, determining that the interface access request passes the verification of the key access path; When the path similarity between the route path and the key access path is less than the path similarity threshold, it is determined that the interface access request fails to pass the verification of the key access path.

7. The method according to claim 1, characterized in that The performing secondary verification on the interface access request by using the historical behavior characteristics includes: Counting the behavior data in each time period during the process of requesting access to the target application through the interface access request, wherein the behavior data includes at least one of the following: call success rate, response time and number of requests; Using the behavior data in each time period to construct a target behavior feature associated with the interface access request; In a case where the feature similarity between the target behavior feature and the historical behavior feature is greater than or equal to a feature similarity threshold, determining that the interface access request passes the verification of the historical behavior feature; When the feature similarity between the target behavior feature and the historical behavior feature is less than the feature similarity threshold, it is determined that the interface access request fails to pass the verification of the historical behavior feature.

8. The method according to any one of claims 1 to 7, characterized in that The performing access control on the interface access request based on the secondary verification result includes: If the secondary verification result fails, performing access restriction control on the interface access request; If the secondary verification result passes, obtaining historical user information associated with the target application and user reference information involved in the process of requesting access to the target application through the interface access request; In a case where the information similarity between the user reference information and the historical user information is greater than or equal to an information similarity threshold, determining that the interface access request passes verification; When the information similarity between the user reference information and the historical user information is less than the information similarity threshold, it is determined that the interface access request has not passed the verification, and the access restriction control is performed on the interface access request.

9. An access control device, characterized in that: include: A first acquisition unit, used to acquire an interface access request triggered by a target application; A second acquisition unit is used to acquire a key access path associated with the target application, wherein the key access path is an access path whose access frequency of the target application in a historical access process meets a key access condition; A first verification unit, configured to perform a verification on the interface access request using the key access path; A third acquisition unit is used to acquire, if the one-time verification is passed, a historical behavior feature associated with the target application, wherein the historical behavior feature is used to characterize the access behavior exhibited by the historical users of the target application during the historical access process; A second verification unit, configured to perform a secondary verification on the interface access request using the historical behavior feature to obtain a secondary verification result; A first control unit is used to perform access control on the interface access request based on the secondary verification result.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 8 when executed by an electronic device.

11. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method described in any one of claims 1 to 8 are implemented.

12. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 8 through the computer program.

Images