Access Request Processing Method, Device, and Electronic Device for Zero-Trust Network

Abstract

The present application provides a method, apparatus, electronic device, and computer-readable storage medium for processing access requests in a zero-trust network; relating to security technologies in the field of cloud technology, the method includes: receiving compliance check data, where the compliance check data is generated based on a data access request for the zero-trust network; matching the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor in the dynamic compliance detection policy that characterizes an abnormal data access request; when the abnormal dynamic evaluation factor meets the dynamic verification condition, initiating dynamic verification corresponding to the dynamic compliance detection policy; and performing an operation that complies with the dynamic compliance detection policy for the data access request according to the result of the dynamic verification. Through the present application, the security of responding to data access requests can be improved through the dynamic compliance detection policy.

Description

Technical Field

[0001] This application relates to security technologies in the field of cloud technologies, and in particular, to a method, apparatus, electronic device, and computer-readable storage medium for processing access requests in a zero-trust network. Background Art

[0002] In a zero-trust network, authorized users can access any reachable area through any trusted application. To ensure the security and trustworthiness of data access requests in the zero-trust network, a static compliance detection scheme based on periodic reporting of information by the client is adopted in related technologies to protect the security of the zero-trust network.

[0003] However, in the static compliance detection scheme provided by related technologies, only passive security protection is performed relying on periodic detection by the client, and complex and diverse network attacks cannot be effectively defended. Summary of the Invention

[0004] Embodiments of this application provide a method, apparatus, electronic device, and computer-readable storage medium for processing access requests in a zero-trust network, which can improve the security of responding to data access requests through a dynamic compliance detection policy.

[0005] The technical solution of the embodiments of this application is implemented as follows:

[0006] Embodiments of this application provide a method for processing access requests in a zero-trust network, including:

[0007] Receiving compliance check data, where the compliance check data is generated based on a data access request for the zero-trust network;

[0008] Matching the compliance check data with a dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor representing an abnormal data access request in the dynamic compliance detection policy;

[0009] When the abnormal dynamic evaluation factor meets a dynamic verification condition, initiating a dynamic verification corresponding to the dynamic compliance detection policy;

[0010] Performing an operation that conforms to the dynamic compliance detection policy for the data access request according to the result of the dynamic verification.

[0011] Embodiments of this application provide an apparatus for processing access requests in a zero-trust network, including:

[0012] A receiving module, configured to receive compliance check data, where the compliance check data is generated based on a data access request for the zero-trust network;

[0013] A matching module, configured to match the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor in the dynamic compliance detection policy that characterizes an abnormal data access request;

[0014] A verification module, configured to initiate dynamic verification corresponding to the dynamic compliance detection policy when the abnormal dynamic evaluation factor meets the dynamic verification condition;

[0015] A response module, configured to perform an operation that complies with the dynamic compliance detection policy for the data access request according to the result of the dynamic verification.

[0016] In the above solution, before the matching module matches the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor in the dynamic compliance detection policy that characterizes an abnormal data access request, in response to a configuration operation for at least one dynamic evaluation factor, the priority and abnormal conditions of each dynamic evaluation factor are obtained; the priority and abnormal conditions of at least one dynamic evaluation factor are determined as the dynamic compliance detection policy.

[0017] In the above solution, before the verification module initiates dynamic verification corresponding to the dynamic compliance detection policy, in response to a configuration operation for the dynamic verification, the fixed dynamic verification rules and non-fixed dynamic verification rules corresponding to the dynamic verification are obtained; the fixed dynamic verification rules and non-fixed dynamic verification rules corresponding to the dynamic verification are encapsulated into the dynamic compliance detection policy, and the dynamic compliance detection policy is sent to a zero-trust network client that receives the data access request; reference data that matches the fixed dynamic verification rules is obtained, where the reference data is used as a verification basis during the dynamic verification process.

[0018] In the above solution, the verification module is further configured to, when the fixed dynamic verification rule is the hardware attributes of the terminal installed with the zero-trust network client, obtain at least one of the following reference data: the device identifier of the terminal, the asset number of the terminal, the serial number of the system disk of the terminal, the version of the basic input / output system of the terminal; when the fixed dynamic verification rule is the software attributes corresponding to the zero-trust network client, obtain at least one of the following reference data: the signature information of the binary file of the zero-trust network client, the hash information of the binary file of the zero-trust network client, the memory information of the binary file of the zero-trust network client, the version information of the binary file of the zero-trust network client; when the fixed dynamic verification rule is the key service of the zero-trust network client, obtain at least one of the following reference data: the running status of the key service, the activity of the key service, the executable file corresponding to the key service, the loaded components of the key service; when the fixed dynamic verification rule is the key thread of the zero-trust network client, obtain at least one of the following reference data: the thread start function of the key thread, the components of the key thread, the stack information of the key thread; when the fixed dynamic verification rule is the authenticity data of the terminal of the zero-trust network client, obtain at least one of the following reference data: the protocol data configured by the zero-trust network client and the corresponding zero-trust network server, the historical heartbeat data sent by the zero-trust network client to the zero-trust network server.

[0019] In the above solution, the receiving module is further configured to: when the data access request is a login request for the zero-trust network client, receive the hardware attributes of the terminal installed with the zero-trust network client and use them as the compliance check data; when the data access request is an access request for the target service address, receive the login information of the zero-trust network client, the user location, the hardware attributes, the ticket information corresponding to the access request, and the application information corresponding to the target service address, and use them as the compliance check data.

[0020] In the above solution, the dynamic evaluation factor configured in the dynamic compliance detection policy is the user location factor, and the matching module is further configured to: obtain the user location of the data access request; perform matching processing on the user location and the abnormal location condition of the user location factor; when the matching result indicates that the user location meets the abnormal location condition of the user location factor, determine the user location factor as the abnormal dynamic evaluation factor indicating the abnormal data access request; where the abnormal location condition includes at least one of the following: multiple user locations corresponding to the data access request are queried; the distance between the user location corresponding to the data access request and the historical reference location is greater than the distance threshold.

[0021] In the above solution, the dynamic evaluation factor configured in the dynamic compliance detection policy is an application factor. The matching module is further configured to: obtain the process data corresponding to the data access request; perform matching processing on the process data and the abnormal process conditions of the application factor; when the matching result indicates that the process data meets the abnormal process conditions of the application factor, determine the application factor as the abnormal dynamic evaluation factor representing the abnormal data access request; where the abnormal process conditions include at least one of the following: the application process of the business application client corresponding to the data access request is detected to be abnormal; the component process of the zero-trust network client corresponding to the data access request is detected to be abnormal.

[0022] In the above solution, the dynamic evaluation factor configured in the dynamic compliance detection policy is an access behavior factor. The matching module is further configured to: obtain the access behavior data of the data access request; perform matching processing on the access behavior data and the abnormal behavior conditions of the access behavior factor; when the matching result indicates that the access behavior data meets the abnormal behavior conditions of the access behavior factor, determine the access behavior factor as the abnormal dynamic evaluation factor representing the abnormal data access request; where the abnormal behavior conditions include at least one of the following: the first time interval between the time of the data access request and the historical reference time is greater than the first time interval threshold; the network address corresponding to the data access request is different from the historical network address; for the user account of the data access request, determine the second time interval between the data access request and the most recent historical data access request of the user account for the network address, and the second time interval is less than the second time interval threshold.

[0023] In the above solution, the dynamic evaluation factor configured in the dynamic compliance detection policy is a terminal factor. The matching module is further configured to: obtain the terminal data of the data access request; perform matching processing on the terminal data and the abnormal terminal conditions of the terminal factor; when the matching result indicates that the terminal data meets the abnormal terminal conditions of the terminal factor, determine the terminal factor as the abnormal dynamic evaluation factor representing the abnormal data access request; where the abnormal terminal conditions include at least one of the following: the user account initiating the data access request is logged in on multiple terminals simultaneously; the terminal information corresponding to the data access request does not match the active terminal information.

[0024] In the above solution, the verification module is further configured to: when the abnormal dynamic evaluation factor is a terminal factor, send a first dynamic verification request based on hardware attributes to the terminal corresponding to the data access request; when the hardware attribute response data for responding to the first dynamic verification request returned by the terminal within the first dynamic verification time threshold is the same as the reference hardware data corresponding to the first dynamic verification request, and each terminal receives the hardware attribute response data once for each first dynamic verification request, determine that the first dynamic verification corresponding to the first dynamic verification request is passed, and continue to respond to the data access request; when the hardware attribute response data for responding to the first dynamic verification request returned by the terminal within the first dynamic verification time threshold is different from the reference hardware data corresponding to the first dynamic verification request, or when each terminal receives the hardware attribute response data multiple times for each first dynamic verification request, determine that the first dynamic verification corresponding to the first dynamic verification request fails.

[0025] In the above solution, the verification module is further configured to: when the abnormal dynamic evaluation factor is an access behavior factor or a user location factor, send a second dynamic verification request for identity attributes based on multiple dimensions to the terminal corresponding to the data access request; when the identity attribute response data in multiple dimensions returned by the terminal within the second dynamic verification time threshold is the same as the reference identity data corresponding to the second dynamic verification request, determine that the second dynamic verification corresponding to the second dynamic verification request is passed, and continue to respond to the data access request, where the identity attribute response data in multiple dimensions is used to respond to the second dynamic verification; when at least one dimension of the identity attribute response data returned by the terminal within the second dynamic verification time threshold is different from the reference identity data corresponding to the second dynamic verification request, determine that the second dynamic verification corresponding to the second dynamic verification request fails, where the at least one dimension of the identity attribute response data is used to respond to the second dynamic verification.

[0026] In the above solution, the verification module is further configured to: when the abnormal dynamic evaluation factor is an application factor, send a third dynamic verification request based on process data to the terminal corresponding to the data access request; when the process response data for responding to the third dynamic verification returned by the terminal within the third dynamic verification time threshold is the same as the reference process data corresponding to the third dynamic verification request, determine that the third dynamic verification corresponding to the third dynamic verification request is passed and continue to respond to the data access request; when the process response data for responding to the third dynamic verification returned by the terminal within the third dynamic verification time threshold is different from the reference process data corresponding to the third dynamic verification request, determine that the third dynamic verification corresponding to the third dynamic verification request fails.

[0027] In the above solution, the verification module is further configured to: send a fourth dynamic verification request carrying a ciphertext to the terminal corresponding to the data access request; when, within a fourth dynamic verification time threshold, the plaintext returned by the terminal in response to the fourth dynamic verification request is the same as the reference plaintext corresponding to the fourth dynamic verification request, determine that the fourth dynamic verification corresponding to the fourth dynamic verification request passes, and continue to respond to the data access request; wherein, the plaintext is obtained based on the decryption key of the terminal, and the decryption key is generated by the terminal based on the encryption and decryption mapping table; when, within the fourth dynamic verification time threshold, the plaintext returned by the terminal in response to the fourth dynamic verification request is not the same as the reference plaintext corresponding to the fourth dynamic verification request, determine that the fourth dynamic verification corresponding to the fourth dynamic verification request fails.

[0028] In the above solution, the response module is further configured to: when the abnormal dynamic evaluation factor meets the restricted response condition, query the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy, and perform the response restriction operation on the data access request; wherein, the response restriction operation includes at least one of the following: blocking the terminal corresponding to the data access request from responding; blocking the user account corresponding to the data access request from responding; blocking the response to the data access request; wherein, the risk level of the abnormal dynamic evaluation factor corresponding to the restricted response condition is higher than the risk level of the abnormal dynamic evaluation factor corresponding to the dynamic verification condition.

[0029] In the above solution, the response module is further configured to: query the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy, and perform the response restriction operation on the data access request; wherein, the response restriction operation includes at least one of the following: blocking the terminal corresponding to the data access request from responding; blocking the user account corresponding to the data access request from responding; blocking the response to the data access request.

[0030] An embodiment of the present application provides an electronic device, including:

[0031] A memory for storing executable instructions;

[0032] A processor, when executing the executable instructions stored in the memory, implements the access request processing method of the zero-trust network provided by the embodiment of the present application.

[0033] An embodiment of the present application provides a computer-readable storage medium, storing executable instructions, which are used to implement the access request processing method of the zero-trust network provided by the embodiment of the present application when being executed by a processor.

[0034] The embodiments of the present application have the following beneficial effects:

[0035] Taking the data access request as a trigger to identify abnormal access behaviors and initiate corresponding verifications, thereby actively detecting the occurrence of abnormal access behaviors, to improve the efficiency and accuracy of discovering abnormal behaviors. And active verification is only performed when the dynamic verification conditions are met, which can reduce the bandwidth occupation caused by excessive and frequent full-scale security detections, and can also improve the accuracy of security protection, enhancing the usability and security of the zero-trust network. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 It is a schematic structural diagram of an access request processing system for a zero-trust network provided by an embodiment of the present application;

[0037] Figure 2 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application;

[0038] Figures 3A - 3D It is a schematic flowchart of an access request processing method for a zero-trust network provided by an embodiment of the present application;

[0039] Figures 4A - 4G It is a schematic diagram of a compliance detection interface provided by an embodiment of the present application;

[0040] Figure 5 It is a schematic diagram of an access process for a zero-trust network provided by an embodiment of the present application;

[0041] Figure 6 It is a schematic architecture diagram of an access processing system for a zero-trust network provided by an embodiment of the present application;

[0042] Figure 7 It is a schematic architecture diagram of an access processing system for a zero-trust network provided by an embodiment of the present application;

[0043] Figure 8 It is a compilation and packaging flowchart provided by an embodiment of the present application;

[0044] Figure 9 It is a functional schematic diagram of static compliance detection in related technologies;

[0045] Figure 10 It is a schematic architecture diagram of an access processing system for a zero-trust network provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0046] In order to make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be construed as limitations on the present application. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0047] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. However, it is understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0048] In the following description, the terms "first", "second", and "third" are merely used to distinguish similar objects and do not represent a specific order for the objects. It is understood that "first", "second", and "third" can be interchanged in a specific order or sequence when permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0050] Before further elaborating on the embodiments of the present application, the nouns and terms involved in the embodiments of the present application are described. The nouns and terms involved in the embodiments of the present application are subject to the following explanations.

[0051] 1) Zero Trust Network: A communication architecture for use between an access subject and an access object, based on identity authentication, with the capabilities of secure business access, continuous trust assessment, and dynamic access control. The functions of the Zero Trust Network are used through a Zero Trust Network client (such as a client of an Intelligent Office Automation (IOA) system).

[0052] 2) Access Subject: In a Zero Trust Network, the party initiating the access, such as a person, device, or application accessing intranet business resources.

[0053] 3) Access Object: In a Zero Trust Network, the party being accessed, such as business resources, data, development and test environments, and operation and maintenance environments in an enterprise intranet.

[0054] 4) Direct Access: In a Zero Trust Network architecture, when an application initiates a network access request to a target site, after the request is hijacked by a Zero Trust Network proxy (such as a full traffic proxy), the full traffic proxy directly initiates a network access request to the target site, that is, initiates a direct connection access, and the full traffic proxy sends the network response of the target site to the application. This access mode is called direct access.

[0055] 5) Proxy Access: In a zero-trust network architecture, when an application initiates a network access request to a target site, after the full-traffic proxy hijacks the request, the full-traffic proxy sends a request forwarding to the zero-trust network gateway (such as an intelligent gateway). The intelligent gateway then proxies the access to the target site. After the access, the intelligent gateway sends the network response of the target site to the full-traffic proxy, and the full-traffic proxy forwards the network response of the target site to the application. This access mode is called proxy access.

[0056] 7) Zero-Trust Network Gateway: Deployed at the entrance of enterprise application programs and data resources, it is responsible for verifying and forwarding each session request for accessing enterprise resources.

[0057] 8) Trusted Application: An application carrier that is trusted by the management end and can be accessed by the terminal to the internal business system, including the application name, MD5 value of the application, signature information, etc.

[0058] 9) Reachable Area: The list of internal sites set by the enterprise that end users can access through the zero-trust network.

[0059] 10) Login Credential: After a user successfully logs in to the IOA client, the IOA server assigns an encrypted string to this user, representing the user's login authorization information, including user information and authorization validity period, which is encrypted and stored on the client.

[0060] 11) Network Request Credential: The authorization information issued by the IOA server for a single network request, used to identify the authorization status of this network request.

[0061] 12) Zero-Trust Access Control Policy: Composed of the process information (trusted applications) that users can use and the business sites (reachable areas) that can be accessed. When permissions are enabled, users can access any reachable area through any trusted application. The granularity of the zero-trust access control policy is the logged-in user, and different zero-trust policies can be formulated for different logged-in users.

[0062] 13) Access Proxy: The terminal access proxy is a terminal proxy deployed on a controlled device to initiate secure access, responsible for initiating request verification of the trusted identity of the access subject. If the identity is verified as trusted, it can establish an encrypted access connection with the access gateway, and it is also the policy execution point of access control.

[0063] 14) Service Addressing: In a distributed cascaded deployment method, different services are deployed on different servers. The process of finding the server connection addresses where the background services concerned by different business modules of the client are deployed is called service addressing.

[0064] 15) Cache Thrashing: When the current task is preempted, the content in the current cache needs to be overwritten by the process that obtains the right to run next. The process to be run next needs to spend time warming up the cache to achieve good operating efficiency. At the same time, during the process of saving and restoring the context, the data in the cache will become invalid. The process from the invalid state to the finally available state of the cache during this period is called Cache Thrashing.

[0065] 16) 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 from the implementation method: static white-box and dynamic white-box.

[0066] 17) Dynamic Verification: Dynamic detection automatically issued by the server or manually by the management terminal for real clients. By issuing dynamic instructions to verify the running context and whether the verification information is correctly returned to determine whether it is a real client.

[0067] 19) Static Key White-Box: Bind and confuse the key of the algorithm 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 and needs to be integrated into the project and compiled into a binary file when developing an application program.

[0068] 20) Sensitive Information: User login information including user id, password, etc., as well as login credentials and network access credentials.

[0069] 21) CI System: The continuous integration (CI) system provides continuous integration functions. Continuous integration (CI) is an automated processing process of automatic environment detection, code pulling, code scanning, and compilation and build (including unit tests in some cases) after the source code of the software product is changed. It provides an automated system for software products including processes such as code security scanning, full-scale compilation and build, package output, unit tests, and automatic deployment.

[0070] 22) Business Module: A collection that consists of multiple files and completes certain specific functions. The concept of the module can not only describe the product more clearly but also make it more convenient to specify the content to be installed or uninstalled. For example, it is possible to specify to install only one "Threat Response" module or "Application Software Management" module.

[0071] 23) Policy: A series of rule sets issued by the administrator in the management terminal for enterprise terminal management. It includes patch repair, zero-trust network control, security reinforcement policies, etc. Policies include sensitive information such as tickets, time limits, and the number of valid times.

[0072] The related technology provides a static compliance detection solution based on the periodic reporting of information by the client, that is, the client periodically reports the device-related information to the IOA server, and the IOA server checks whether the device information is consistent with the set list information through the reported data, thereby checking whether the device is compliant. Figure 9 , Figure 9 It is a functional diagram of static compliance detection in related technologies. The IOA client periodically detects static compliance rules and reports them to the IOA server. The IOA client resides in the terminal and continuously and periodically performs virus detection, vulnerability repair, security reinforcement, data protection, real-time protection, heartbeat detection and other functions in silence. The IOA client performs terminal security detection, terminal management and reinforcement, and terminal abnormality repair according to the policies issued by the IOA server. When a terminal with the IOA client installed and characterized as safe by virus detection, real-time protection and other detections is identified, IOA zero-trust network access is allowed. If there are abnormal items that can be automatically repaired after detection, the IOA client performs automatic repair according to the policy of the IOA server. If it is found that there are abnormal items that need to be manually repaired by the user, the IOA client reminds the user by displaying the abnormal items, abnormal reasons and repair suggestions. Before the user repairs these problems, the user is prohibited from logging in to perform identity authentication and zero-trust access. Static compliance detection is achieved through the above process.

[0073] The defects of the relevant technology are: First, it relies heavily on the reporting data and reporting cycle of the IOA client. Because the terminal is vulnerable to reverse engineering and cracking by attackers, sensitive information can be easily misused to access the enterprise network illegally. If the reporting cycle is set too long, it will easily lead to inefficient security detection, and if the reporting cycle is set too short, it will occupy more enterprise network bandwidth and traffic. At the same time, the increase in network connections will increase the pressure on business servers; second, the compliance detection items are hard-wired to the terminal, with no or little grading and automatic triggering processing, and cannot actively discover and respond to risks, and cannot make continuous and dynamic assessments of user behavior. The ability to identify abnormal behavior and attack behavior is not strong, and no sensitive factors are used for linkage processing. When an attack occurs, it cannot be quickly identified and responded to.

[0074] Embodiments of the present application provide a method, device, electronic device, and computer-readable storage medium for processing access requests in a zero-trust network, which can improve the security of responding to data access requests through a dynamic compliance detection strategy.

[0075] The following describes an exemplary application of the electronic device provided by the embodiment of the present application. The device provided by the embodiment of the present application can be implemented as a server. The following describes an exemplary application when the electronic device is implemented as a server.

[0076] See also Figure 1 , Figure 1is a schematic diagram of the structure of the access request processing system of the zero-trust network provided in the embodiment of the present application, such as Figure 1 As shown, terminal 400 is a terminal associated with a user, and an application 410, a zero-trust network agent 402, and a zero-trust network client 403 are running on terminal 400, wherein application 410 can be various types of applications, such as video playback applications, online conference applications, live broadcast applications, news applications, and instant messaging applications, etc. It should be noted that application 410 refers to an application that is authorized by the zero-trust network server 200 and can access the internal business system (such as the business server 500).

[0077] The zero-trust network agent 402 is used to hijack the access request sent by the application 410. When the zero-trust network agent 402 hijacks the data access request sent by the application 410, it first initiates an authentication request to the zero-trust network client 403 (that is, the zero-trust network agent 402 applies for the credentials of this access request from the zero-trust network client 403). After receiving the authentication request sent by the zero-trust network agent 402, the zero-trust network client 403 sends compliance check data to the zero-trust network server 200. The zero-trust network server 200 receives the compliance check data, matches the compliance check data with the dynamic compliance detection policy of the zero-trust network, and obtains the abnormal dynamic assessment factor representing the abnormal data access request in the dynamic compliance detection policy. When the abnormal dynamic assessment factor meets the dynamic verification condition, the zero-trust network server 200 initiates dynamic verification of the corresponding dynamic compliance detection policy to the zero-trust network client 403. According to the result of the dynamic verification, the zero-trust network server 200 performs operations that comply with the dynamic compliance detection policy on the data access request.

[0078] In some embodiments, the zero-trust network server 200 and the business server 500 can be independent physical servers, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal 400 can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited to this. The terminal 400 can be directly or indirectly connected to the zero-trust network server 200 and the business server 500 through wired or wireless communication, which is not limited in the embodiments of the present application.

[0079] See also Figure 2 , Figure 2 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application, Figure 2The server 200 shown includes: at least one processor 210, a memory 250, at least one network interface 220 and a user interface 230. The various components in the server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 240 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 240 is not described in detail. Figure 2 Various buses are labeled as bus system 240 .

[0080] The processor 210 may be an integrated circuit chip having signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor may be a microprocessor or any conventional processor, etc.

[0081] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices that are physically remote from the processor 210.

[0082] The memory 250 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 250 described in the embodiment of the present application is intended to include any suitable type of memory.

[0083] In some embodiments, memory 250 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0084] Operating system 251, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing tasks based on hardware;

[0085] The network communication module 252 is used to reach other computing devices via one or more (wired or wireless) network interfaces 220. Exemplary network interfaces 220 include: Bluetooth, Wireless LAN (WiFi), and Universal Serial Bus (USB).

[0086] In some embodiments, the access request processing device of the zero-trust network provided by the embodiments of the present application may be implemented in software. Figure 2 Shown is an access request processing device 255 of a zero-trust network stored in a memory 250, which may be software in the form of a program and a plug-in, etc., including the following software modules: a receiving module 2551, a matching module 2552, a verification module 2553, and a response module 2554. These modules are logical, so they can be combined arbitrarily or further split according to the functions implemented.

[0087] The access request processing method of the zero-trust network provided by the embodiments of the present application will be described in combination with an exemplary application and implementation of a server 200 provided by the embodiments of the present application.

[0088] See Figure 3A , Figure 3A is a flowchart of the access request processing method of the zero-trust network provided by the embodiments of the present application, and will be described in combination with Figure 3A the steps shown.

[0089] In step 101, compliance check data is received.

[0090] As an example, the compliance check data is generated based on a data access request for a zero-trust network.

[0091] As an example, the data access request includes two cases. The first case is an identity login data access request, and the second case is a data access request when accessing a certain business system after login.

[0092] In some embodiments, see Figure 3B , Figure 3B is a flowchart of the access request processing method of the zero-trust network provided by the embodiments of the present application. Receiving the compliance check data in step 101 can be implemented through steps 1011 - 1012.

[0093] In step 1011, when the data access request is a login request for a zero-trust network client, the hardware attributes of the terminal installed with the zero-trust network client are received and used as compliance check data.

[0094] As an example, taking the login identity as an example, the IOA client collects the hardware attributes of the terminal where the IOA client is located through a driver service and sends them to the IOA server. The hardware attributes of the terminal include the basic input / output system, the system disk serial number, the universal unique identifier, the asset number, the device identifier, and so on.

[0095] In step 1012, when the data access request is an access request for the target service address, receive the login information, user location, hardware attributes, ticket information corresponding to the access request, and application information corresponding to the target service address of the zero-trust network client, and use them as compliance check data.

[0096] As an example, take the data access request when accessing a certain business system after logging in. Each time the IOA client executes the zero-trust network access function, the IOA client component collects the logged-in user information, network location (user location), hardware attributes of the terminal, identity ticket, and access application information. Thus, the IOA server receives the compliance check data including the logged-in user information, network location, hardware attributes of the terminal, identity ticket, and access application information.

[0097] In step 102, match the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy.

[0098] In some embodiments, refer to Figure 3C , Figure 3C is a schematic flowchart of the access request processing method for the zero-trust network provided by the embodiments of the present application. Before step 102 where the compliance check data is matched with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy, execute steps 105 - 106.

[0099] In step 105, in response to a configuration operation for at least one dynamic evaluation factor, obtain the priority and abnormal conditions of each dynamic evaluation factor.

[0100] In step 106, determine the priority and abnormal conditions of at least one dynamic evaluation factor as the dynamic compliance detection policy.

[0101] As an example, the IOA server provides an administrator with a configuration function for dynamic evaluation factors. The configured dynamic evaluation factors are determined as the dynamic compliance detection policy. The dynamic evaluation factors include devices, user access behaviors, applications, user locations, etc. Each dynamic evaluation factor has a default priority. The administrator can adjust the priorities of each dynamic evaluation factor according to enterprise requirements. At the same time, the administrator can combine multiple dynamic evaluation factors to form a dynamic compliance detection policy applicable to different scenarios. For example, the dynamic compliance detection policy includes a combination of the user access behavior factor and the user location factor, and the priority of the user access behavior factor is higher than that of the user location factor. The higher the priority, the more important the result of the corresponding dynamic verification is, that is, the importance of the result of the dynamic verification is positively correlated with the priority of the corresponding dynamic evaluation factor.

[0102] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is the user location factor. In step 102, the compliance check data is matched with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request. The following technical solutions can be adopted: Obtain the user location of the data access request; match the user location with the abnormal location conditions of the user location factor; when the matching result indicates that the user location meets the abnormal location conditions of the user location factor, determine the user location factor as the abnormal dynamic evaluation factor representing the abnormal data access request; wherein, the abnormal location conditions include at least one of the following: Multiple user locations corresponding to the data access request are queried; the distance between the user location corresponding to the data access request and the historical reference location is greater than the distance threshold.

[0103] As an example, when obtaining the user location of the data access request, when the end user accesses enterprise resources at different network locations simultaneously or when the location of accessing enterprise resources this time is different from the network location (historical reference location) with high historical frequency of access, the user location meets the abnormal location conditions of the user location factor, and the user location factor is determined as the abnormal dynamic evaluation factor representing the abnormal data access request. The change in the network location where the user is located when accessing enterprise resources is an important reference factor for the access security of the zero-trust network.

[0104] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is the application factor. In step 102, the compliance check data is matched with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request. The following technical solutions can be adopted: Obtain the process data corresponding to the data access request; match the process data with the abnormal process conditions of the application factor; when the matching result indicates that the process data meets the abnormal process conditions of the application factor, determine the application factor as the abnormal dynamic evaluation factor representing the abnormal data access request; wherein, the abnormal process conditions include at least one of the following: The application process of the business application client corresponding to the data access request is detected to be abnormal; the component process of the zero-trust network client corresponding to the data access request is detected to be abnormal.

[0105] As an example, the abnormal process condition for the application factor involves the application process accessing the enterprise business system through the zero-trust network function and the component process of the IOA client, obtaining the process data corresponding to the data access request. When the application for accessing enterprise resources by the end user is found to be abnormal after inspection or the component of the IOA client is found to have abnormal loading modules or abnormal thread execution during detection, the process data meets the abnormal process condition of the application factor, and the application factor is determined as the abnormal dynamic evaluation factor representing the abnormal data access request. The compliance detection service of the IOA server needs to identify and intervene in a timely manner.

[0106] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is the access behavior factor. In step 102, the compliance check data is matched with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy. This can be achieved through the following technical solutions: obtaining the access behavior data of the data access request; matching the access behavior data with the abnormal behavior conditions of the access behavior factor; when the matching result indicates that the access behavior data meets the abnormal behavior conditions of the access behavior factor, determining the access behavior factor as the abnormal dynamic evaluation factor representing the abnormal data access request; where the abnormal behavior conditions include at least one of the following: the first time interval between the time of the data access request and the historical reference time is greater than the first time interval threshold; the network address corresponding to the data access request is different from the historical network address; for the user account of the data access request, determining the second time interval between the data access request and the most recent historical data access request of the user account for the network address, and the second time interval is less than the second time interval threshold.

[0107] As an example, when obtaining the access behavior data of the data access request, if the time when the end user accesses enterprise resources is significantly different from the daily habit (the first time interval between the time of the data access request and the historical reference time is greater than the first time interval threshold, such as accessing enterprise resources in the early morning), or the business system accessed is significantly different from the user's historical records (the network address corresponding to the data access request is different from the historical network address), or the access frequency of the business system is significantly different from the user's historical records (for the user account of the data access request, determining the second time interval between the data access request and the most recent historical data access request of the user account for the network address, and the second time interval is less than the second time interval threshold), it is considered that there is a possibility of account theft, the access behavior data meets the abnormal behavior conditions of the access behavior factor, and the access behavior factor is determined as the abnormal dynamic evaluation factor representing the abnormal data access request.

[0108] As an example, for the user account of the data access request, determine the second time interval between the data access request and the most recent historical data access request of the user account for the network address, that is, obtain the historical time when the user account last accessed the network address, and calculate the second time interval between the historical time and the current time. That the second time interval is less than the second time interval threshold indicates that the access frequency of the business system is greater than the historical record of this user.

[0109] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is the terminal factor. In step 102, the compliance check data is matched with the dynamic compliance detection policy of the zero trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy, which can be implemented through the following technical solutions: obtain the terminal data of the data access request; match the terminal data with the abnormal terminal conditions of the terminal factor; when the matching result indicates that the terminal data meets the abnormal terminal conditions of the terminal factor, determine the terminal factor as the abnormal dynamic evaluation factor representing the abnormal data access request; where the abnormal terminal conditions include at least one of the following: the user account initiating the data access request is logged in on multiple terminals at the same time; the terminal information corresponding to the data access request does not match the active terminal information.

[0110] As an example, obtain the terminal data of the data access request. When the terminal data indicates that the user account is logged in on different devices at the same time, or the device information uploaded when applying for a bill is not in the existing active device list, or the device information is in the active device list but the key information does not match, the terminal data meets the abnormal terminal conditions of the terminal factor, and the terminal factor is determined as the abnormal dynamic evaluation factor representing the abnormal data access request.

[0111] In step 103, when the abnormal dynamic evaluation factor meets the dynamic verification condition, initiate the dynamic verification of the corresponding dynamic compliance detection policy.

[0112] As an example, the dynamic verification condition is a constraint on the abnormal dynamic evaluation factor. For example, when the abnormal dynamic evaluation factor is the user location factor, the user location corresponding to the data access request does not belong to the historical user location, but the distance between the user location and the historical user location is within the distance threshold, then it is determined that the abnormal dynamic evaluation factor meets the dynamic verification condition and initiate the dynamic verification of the corresponding dynamic compliance detection policy. When the user location corresponding to the data access request does not belong to the historical user location and the distance between the user location and the historical user location is outside the distance threshold, it is determined that the abnormal dynamic evaluation factor meets the restricted response condition, and the dynamic verification can be skipped and the corresponding restriction can be directly performed.

[0113] In some embodiments, in some embodiments, see Figure 3D , Figure 3DIt is a schematic flowchart of a method for processing access requests in a zero-trust network provided by an embodiment of the present application. Before initiating dynamic verification corresponding to a dynamic compliance detection policy in step 103, steps 107-109 are executed.

[0114] In step 107, in response to a configuration operation for dynamic verification, obtain the fixed dynamic verification rules and non-fixed dynamic verification rules corresponding to the dynamic verification.

[0115] In step 108, encapsulate the fixed dynamic verification rules and non-fixed dynamic verification rules corresponding to the dynamic verification into a dynamic compliance detection policy, and send the dynamic compliance detection policy to the zero-trust network client that receives the data access request.

[0116] As an example, the dynamic verification rules built into the zero-trust network client include fixed dynamic verification rules and rules based on a set template. Among them, the fixed dynamic verification rules include: terminal hardware attribute detection, random sampling detection of IOA client components, critical service running detection, critical thread detection, and device authenticity detection, etc. The fixed dynamic verification rules include: terminal hardware attribute detection. The IOA client collects the hardware attributes of the terminal, such as the basic input / output system, system disk serial number, universal unique identifier, asset number, device identifier, etc. The fixed dynamic verification rules include: random sampling detection of IOA client components. The IOA server instructs the IOA client to randomly collect the signature information, hash (md5 or SHA256) value, file size, version information, etc. of at least one binary file in the installation directory. The fixed dynamic verification rules include: critical service running detection. The IOA server instructs the IOA client to randomly collect the running status information of the critical services of the IOA client. The running status information includes service running status, service liveness detection information, executable file detection information corresponding to the service, service loaded module information, etc. The fixed dynamic verification rules include: critical thread detection. The IOA client builds a logic in the critical component to traverse and collect all thread information in this process, including thread start function name, module where the thread is located, thread stack information, etc. The fixed dynamic verification rules include: device authenticity detection. The IOA server sends device authenticity detection to the specified terminal, forces the terminal to send heartbeat information, and at the same time reports several calculation data according to the protocol agreed with the IOA server.

[0117] In step 109, obtain the reference data that matches the fixed dynamic verification rules, where the reference data is used as the verification basis during the dynamic verification process.

[0118] In some embodiments, the acquisition of reference data that matches the fixed dynamic verification rules can be achieved through the following technical solutions: when the fixed dynamic verification rule is the hardware attribute of a terminal installed with a zero-trust network client, at least one of the following reference data is acquired: the device identifier of the terminal, the asset number of the terminal, the serial number of the system disk of the terminal, the version of the basic input / output system of the terminal; when the fixed dynamic verification rule is the software attribute of the corresponding zero-trust network client, at least one of the following reference data is acquired: the signature information of the binary file of the zero-trust network client, the hash information of the binary file of the zero-trust network client, the memory information of the binary file of the zero-trust network client, the version information of the binary file of the zero-trust network client; when the fixed dynamic verification rule is the key service of the zero-trust network client, at least one of the following reference data is acquired: the running state of the key service, the activity of the key service, the executable file corresponding to the key service, the loaded components of the key service; when the fixed dynamic verification rule is the key thread of the zero-trust network client, at least one of the following reference data is acquired: the thread start function of the key thread, the components of the key thread, the stack information of the key thread; when the fixed dynamic verification rule is the authenticity data of the terminal of the zero-trust network client, at least one of the following reference data is acquired: the protocol data configured by the zero-trust network client and the corresponding zero-trust network server, the historical heartbeat data sent by the zero-trust network client to the zero-trust network server.

[0119] As an example, for the hardware attribute, the source of the reference data for the dynamic verification of the IOA server is the hardware attribute reported by the end user to the IOA server when logging in to obtain an identity ticket, or the hardware attribute reported by the device standardization function to the IOA server when the device standardization function is enabled. For the software attribute, key service, and key thread, the source of the reference data for the dynamic verification of the IOA server is the information generated by code scanning during the compilation and packaging of the IOA version in the CI system; for the authenticity data of the terminal, the source of the reference data for the dynamic verification of the IOA server is the protocol data agreed upon by the IOA front and back ends, and the device and process information reported by historical heartbeats.

[0120] In some embodiments, when the abnormal dynamic evaluation factor meets the dynamic verification condition in step 103, the dynamic verification of the corresponding dynamic compliance detection policy can be initiated through the following technical solutions: when the abnormal dynamic evaluation factor is a terminal factor, a first dynamic verification request based on hardware attributes is sent to the terminal corresponding to the data access request; when the hardware attribute response data returned by the terminal within the first dynamic verification time threshold for responding to the first dynamic verification request is the same as the reference hardware data corresponding to the first dynamic verification request, and when each terminal receives the hardware attribute response data once for each first dynamic verification request, it is determined that the first dynamic verification corresponding to the first dynamic verification request passes, and the data access request is continued to be responded to; when the hardware attribute response data returned by the terminal within the first dynamic verification time threshold for responding to the first dynamic verification request is different from the reference hardware data corresponding to the first dynamic verification request, or when each terminal receives the hardware attribute response data multiple times for each first dynamic verification request, it is determined that the first dynamic verification corresponding to the first dynamic verification request fails.

[0121] As an example, when the abnormal dynamic evaluation factor is a terminal factor, a first dynamic verification request based on hardware attributes is sent to the terminal corresponding to the data access request. If there are at least two information collections and data reports in a single verification task, the verification task is considered abnormal (verification fails). The terminal responds to the server's dynamic verification, but the response content needs to be consistent with the reference data. If there are multiple verification tasks and the response content is the same, only then is the dynamic verification considered successful. If a terminal's verification task has equal to or more than two information collections and data reports, the verification task is abnormal, and the terminal is prohibited from connecting to enterprise resources. If a terminal's verification results are inconsistent for two consecutive verification tasks, or if the terminal's software and hardware verification results are different from the reference data each time, the verification task is also considered abnormal, and the account authentication and network access of the corresponding terminal are terminated.

[0122] In some embodiments, when the abnormal dynamic evaluation factor is a terminal factor, a first dynamic verification request based on hardware attributes is sent to the terminal corresponding to the data access request. It is detected that the response content of multiple first dynamic verification requests is consistent with the reference data and the multiple response contents are the same, and only then is the dynamic verification considered successful; otherwise, the dynamic verification fails, and the identity authentication and network access are restricted. If there are multiple terminals, for the terminals with unresponsive or incorrect response content, the compliance detection service of the IOA server adds a verification random number when issuing the first dynamic verification request, and synchronizes it to the ticket service in the zero-trust business service of the IOA server. When the terminal initiates a network access and applies to the server for a network access ticket, it carries the verification random number in the first dynamic verification request. If the ticket service detects that the random numbers are inconsistent, the terminal verification is considered untrusted, and the small ticket application is rejected. Therefore, such unresponsive or incorrect-response devices will be automatically isolated by the zero-trust network.

[0123] In some embodiments, when the abnormal dynamic evaluation factor meets the dynamic verification condition in step 103, the dynamic verification of the corresponding dynamic compliance detection policy can be initiated through the following technical solutions: when the abnormal dynamic evaluation factor is an access behavior factor or a user location factor, a second dynamic verification request for identity attributes based on multiple dimensions is sent to the terminal corresponding to the data access request; when, within the second dynamic verification time threshold, the identity attribute response data in multiple dimensions returned by the terminal is the same as the reference identity data corresponding to the second dynamic verification request, it is determined that the second dynamic verification corresponding to the second dynamic verification request is passed, and the data access request is continued to be responded to, where the identity attribute response data in multiple dimensions is used to respond to the second dynamic verification; when, within the second dynamic verification time threshold, the identity attribute response data in at least one dimension returned by the terminal is not the same as the reference identity data corresponding to the second dynamic verification request, it is determined that the second dynamic verification corresponding to the second dynamic verification request fails, where the identity attribute response data in at least one dimension is used to respond to the second dynamic verification.

[0124] As an example, when the end user accesses enterprise resources at different network locations simultaneously, or when the location of accessing enterprise resources this time is different from the network location of historical high-frequency access, the IOA server immediately interrupts the zero-trust network access of the corresponding device, temporarily blacklists the device, temporarily prohibits identity authentication and network access, and sends a second dynamic verification request for identity attributes based on multiple dimensions to the terminal corresponding to the data access request, that is, initiates multi-factor identity authentication and simultaneously conducts terminal dynamic verification. If multi-factor identity authentication (such as token login, face recognition, employee mobile phone SMS verification code, etc.) cannot be successfully completed within the specified time or specified number of times, it is considered that the verification fails.

[0125] As an example, when the time when the end user accesses enterprise resources is quite different from the daily habit (such as accessing enterprise resources in the early morning), and the business system accessed and the frequency of accessing the business system are quite different from the user's historical records, the IOA server can immediately issue a forced logout instruction and send a second dynamic verification request for identity attributes based on multiple dimensions to the terminal corresponding to the data access request, that is, forcefully issue multi-factor authentication for identity verification. If multi-factor identity authentication (such as token login, face recognition, employee mobile phone SMS verification code, etc.) cannot be successfully completed within the specified time or specified number of times, it is considered that the verification fails.

[0126] In some embodiments, when the abnormal dynamic evaluation factor meets the dynamic verification condition in step 103, the dynamic verification of the corresponding dynamic compliance detection policy can be implemented through the following technical solutions: when the abnormal dynamic evaluation factor is an application factor, a third dynamic verification request based on process data is sent to the terminal corresponding to the data access request; when within the third dynamic verification time threshold, the process response data for responding to the third dynamic verification returned by the terminal is the same as the reference process data corresponding to the third dynamic verification request, it is determined that the third dynamic verification corresponding to the third dynamic verification request is passed and the data access request is continued to be responded to; when within the third dynamic verification time threshold, the process response data for responding to the third dynamic verification returned by the terminal is different from the reference process data corresponding to the third dynamic verification request, it is determined that the third dynamic verification corresponding to the third dynamic verification request fails.

[0127] As an example, the core of the third dynamic verification request is the application process information of the end user accessing enterprise resources through a third-party application and the process information of the IOA core component, including the module information loaded by the component and the thread information collected in real time. A third dynamic verification request based on process data is sent to the terminal corresponding to the data access request. The client responds to the dynamic verification instruction of the server, collects the application process name, process path, recent modification time of the process file, MD5 of the process file, version number of the process file, SHA256 of the process file, copyright information, and process signature information that frequently access the business system, and initiates centralized submission for inspection to the threat cloud query service. When the process response data for responding to the third dynamic verification returned by the terminal is different from the reference process data corresponding to the third dynamic verification request, it is determined that there is an abnormality, and it is determined that the third dynamic verification corresponding to the third dynamic verification request fails. After inspection, if the abnormality rate is lower than the device parameter, the zero-trust network access interruption processing of the abnormal process is executed; if the abnormality rate is higher than the set parameter, the zero-trust network access disconnection processing at the device level is executed.

[0128] In some embodiments, when the abnormal dynamic evaluation factor meets the dynamic verification condition in step 103, the dynamic verification of the corresponding dynamic compliance detection policy can be implemented through the following technical solutions: a fourth dynamic verification request carrying ciphertext is sent to the terminal corresponding to the data access request; when within the fourth dynamic verification time threshold, the plaintext corresponding to the ciphertext for responding to the fourth dynamic verification returned by the terminal is the same as the reference plaintext corresponding to the fourth dynamic verification request, it is determined that the fourth dynamic verification corresponding to the fourth dynamic verification request is passed, and the data access request is continued to be responded to; wherein, the plaintext is obtained based on the decryption key of the terminal, and the decryption key is generated by the terminal based on the encryption and decryption mapping table; when within the fourth dynamic verification time threshold, the plaintext corresponding to the ciphertext for responding to the fourth dynamic verification returned by the terminal is different from the reference plaintext corresponding to the fourth dynamic verification request, it is determined that the fourth dynamic verification corresponding to the fourth dynamic verification request fails.

[0129] As an example, the IOA server provides an algorithm for generating encryption and decryption keys based on the encryption and decryption mapping table of the corresponding IOA version, sends a fourth dynamic verification request carrying ciphertext to the terminal of the corresponding data access request, and attaches a random ciphertext information, requiring the IOA client to generate an encryption and decryption key based on the encryption and decryption mapping table of the corresponding IOA version, decrypt the random ciphertext, and attach the decrypted plaintext of the ciphertext in the data sent to the server in a specified format. Within the fourth dynamic verification time threshold, if the plaintext corresponding to the ciphertext returned by the terminal to respond to the fourth dynamic verification request is different from the baseline plaintext corresponding to the fourth dynamic verification request, it is determined that the fourth dynamic verification corresponding to the fourth dynamic verification request has failed.

[0130] In step 104, based on the result of the dynamic verification, an operation that complies with the dynamic compliance detection policy is performed on the data access request.

[0131] In some embodiments, when the abnormal dynamic assessment factor meets the restricted response condition, the response restriction operation corresponding to the abnormal dynamic assessment factor is queried from the dynamic compliance detection policy, and the response restriction operation is performed on the data access request; wherein the response restriction operation includes at least one of the following: shielding the terminal corresponding to the response data access request; shielding the user account corresponding to the response data access request; shielding the response data access request; wherein the risk level of the abnormal dynamic assessment factor corresponding to the restricted response condition is higher than the risk level of the abnormal dynamic assessment factor corresponding to the dynamic verification condition.

[0132] As an example, after a risky behavior is identified based on a dynamic compliance detection policy, a graded process is performed based on the dynamic compliance detection policy. For risky behaviors of a set level (serious or requiring forced intervention), a network disconnection is performed, and a restriction operation instruction is issued at the same time. Zero-trust network access is not allowed until the terminal user removes the risky behavior. For example, if the same login ticket appears on at least two different devices at the same time, it is considered a high-risk scenario (identity ticket theft), and the zero-trust network access of the corresponding device is immediately interrupted, and the device is blacklisted to prohibit identity authentication and network access. In the embodiment of the present application, for normal operations of terminal users that may trigger rules, the IOA server initiates dynamic verification of terminals, users, and main processes, and automatically issues multi-factor authentication and terminal authentication to actively collect the user's security status, thereby preventing the spread of threatening behaviors. For abnormal scenarios, the IOA server can automatically disconnect or force logout the specified terminal to interrupt the zero-trust network access function.

[0133] In some embodiments, the operation that complies with the dynamic compliance detection policy for the data access request in step 104 can be implemented through the following technical solution: query the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy, and execute the response restriction operation for the data access request; wherein, the response restriction operation includes at least one of the following: blocking the terminal corresponding to the response data access request; blocking the user account corresponding to the response data access request; blocking the response data access request.

[0134] As an example, refer to Figure 10 , Figure 10 which is a schematic diagram of the architecture of the access processing system for the zero-trust network provided by the embodiments of the present application. Figure 10 There are parts identical to those in Figure 7 , and the description for Figure 7 can be directly referred to. When the dynamic verification initiated by the IOA server for the IOA client fails, corresponding blocking measures are issued according to the compliance detection policy. As shown in Figure 10 , the compliance detection service of the IOA server issues a blocking instruction (step 1 shown in the figure), and at the same time interacts with the zero-trust business service of the IOA server to execute the device blacklisting and service blocking tasks, that is, not to issue a response ticket to the specified device, reject subsequent ticket verifications, and prohibit the device from logging in again for identity authentication, etc. (such as steps 2 and 3 in Figure 10 ). After receiving the blocking instruction, on the one hand, the IOA client rejects the local ticket application request of the proxy client (such as steps 4 and 5 in Figure 10 ), on the other hand, the IOA server refuses to issue a network application ticket to the IOA client of the specified device (such as steps 6 and 7 in Figure 10 ), and at the same time the IOA server rejects the ticket verification of the intelligent gateway (such as steps 8 and 9 in Figure 10 ). Until the abnormal items are repaired by the IOA client and verified by the compliance detection service, the device is rejected by the IOA server outside the zero-trust compliant device list, and the zero-trust network access function is prohibited.

[0135] Next, the exemplary application of the embodiments of the present application in an actual application scenario will be described.

[0136] In some embodiments, refer to Figure 4A , Figure 4A which is a schematic diagram of the compliance detection interface provided by the embodiments of the present application. During the use of the zero-trust network, the user will be prompted to perform regular detections to ensure the security of the office environment. In response to the trigger operation for the control, the compliance detection starts. Refer to Figure 4B , Figure 4BIt is a schematic diagram of the compliance detection interface provided by an embodiment of the present application. For the terminal to initiate compliance detection, the office environment will be detected during the compliance detection, software security baseline detection will be performed, detection of illegal processes will be carried out, and detection of illegal services will be carried out. Refer to Figure 4C , Figure 4C It is a schematic diagram of the compliance detection interface provided by an embodiment of the present application. Figure 4C It shows the results of compliance detection risks, indicating that 1 compliance detection risk is found. It is detected that there is an illegal process on the terminal during the detection of illegal processes. The compliance detection is dynamically configurable. Administrators can customize security reinforcement policies at the management end to configure security reinforcement policies on the zero-trust network server. Refer to Figure 4D , Figure 4D It is a schematic diagram of the compliance detection interface provided by an embodiment of the present application. Figure 4D It shows that the device fails to pass the compliance detection and temporarily cannot access the intranet resources, and a pop-up window is displayed to prompt for device environment security protection through security reinforcement policies. Refer to Figure 4E , Figure 4E It is a schematic diagram of the compliance detection interface provided by an embodiment of the present application. Figure 4E It shows that the device fails to pass the compliance detection and temporarily cannot access the intranet resources, and a pop-up window is displayed to prompt the user for abnormal items and provide repair suggestions. Refer to Figure 4F , Figure 4F It is a schematic diagram of the compliance detection interface provided by an embodiment of the present application. Figure 4F It shows that the device fails to pass the compliance detection and temporarily cannot access the intranet resources, and it prompts the user that before the abnormal items are repaired, the user is not allowed to log in to the zero-trust network and use the zero-trust network access function. In response to the trigger operation for the control, the risk is repaired.

[0137] For example, refer to Figure 5 , Figure 5 It is a schematic diagram of the access process of the zero-trust network provided by an embodiment of the present application. As Figure 5 shown, the zero-trust network client (such as the IOA client) acts as the provider of zero-trust network security services, and provides a unified entry for the access subject to request access to the resources of the object through the zero-trust network proxy and the zero-trust network gateway (such as the intelligent gateway). The IOA client provides an authentication operation for the unified entry. Only the network requests that pass the authentication can be forwarded by the zero-trust network proxy to the intelligent gateway to proxy the access to the actual business system through the intelligent gateway.

[0138] For example, refer to Figure 6 , Figure 6 It is a schematic diagram of the architecture of the access processing system of the zero-trust network provided by an embodiment of the present application. As Figure 6As shown in the figure, the core modules of the access processing system for the zero-trust network mainly include: the zero-trust network client (such as the IOA client), the zero-trust network server (such as the IOA server), the zero-trust network proxy (such as the full-traffic proxy), and the zero-trust network gateway (such as the intelligent gateway), which will be described separately below.

[0139] The IOA client is a security agent installed on the working devices of access users (such as company employees), responsible for verifying the trusted identity of the users on the device, verifying whether the device is trusted, and whether the application is trusted; at the same time, it is also used to apply for process inspection of unknown processes to the IOA server.

[0140] The zero-trust network proxy (proxy) is mainly used to hijack device traffic (such as access requests sent by application programs) through the TUN / TAP virtual network card, and is responsible for forwarding the network requests sent by the application to the intelligent gateway after authentication by the IOA client. If the authentication fails, it will go through direct connection or interrupt the connection.

[0141] The intelligent gateway is deployed at the entrance of enterprise application programs and data resources, and is responsible for verifying, authorizing, and forwarding each session request for accessing enterprise resources.

[0142] The IOA server is mainly used to perform security scheduling on business traffic through the policy control engine, and perform authorization according to the granularity of person-device-business system-application. Among them, the identity authentication module included in the IOA server is used to verify the identity of access users; the device trust module is used to verify the hardware information and security information of the device; the application detection module is used to detect whether the application process is secure, such as whether there are vulnerabilities, whether there are virus trojans, etc. In addition, the IOA server will regularly initiate file inspection to the threat intelligence cloud search service Anzhi or the antivirus engine (such as the TAV antivirus engine). When a malicious process is identified, an asynchronous blocking operation will be performed through the client.

[0143] The overall process is as follows: When the access subject initiates a network access request for the access object through the application, in step 1, the IOA client first hijacks the network access request (pid-url) initiated by the application through the zero-trust network proxy. In step 2, the zero-trust network proxy initiates an authentication request to the IOA client (that is, the zero-trust network proxy requests a credential for this network access request from the IOA client). Among them, the request parameters include the source IP or domain name, source port, destination IP or domain name, destination port, and the process identifier (PID, Process IDentification) corresponding to the application. In step 3, the IOA client obtains the process characteristics. In step 4, the IOA client collects the MD5, process path, process last modification time, copyright information, signature information, etc. of the process through the PID sent by the zero-trust network proxy, and together with the source IP or domain name, source port, destination IP or domain name, and destination port carried in the network access request sent by the zero-trust network proxy, applies for ticket replacement to the IOA server. In step 5, the IOA client sends the process characteristics to the IOA server for process inspection. If the ticket application is successful, in step 6, the IOA client returns the ticket, the maximum number of uses of the ticket, and the valid time of the ticket as a response to the zero-trust network proxy. In step 7, the zero-trust network proxy can initiate an Https request to the intelligent gateway, and the network request credential (i.e., the ticket) returned by the IOA client is carried in the Authorization header field of the request. In step 8, after receiving the Https request sent by the zero-trust network proxy, the intelligent gateway parses the ticket in the header field and requests the IOA server to verify the ticket. If the verification is successful, then in step 9, a connection is successfully established between the intelligent gateway and the zero-trust network proxy. The intelligent gateway receives the verification result returned by the IOA server. Subsequently, the zero-trust network proxy can send the hijacked network access request initiated by the application to the intelligent gateway. In step 10, the intelligent gateway forwards the request to the corresponding business server to proxy the actual application network access. In step 11, the business server returns the response result to the intelligent gateway. In step 12, the intelligent gateway returns the response result to the zero-trust network proxy. In step 13, the zero-trust network proxy returns the response result to the application; if the IOA server fails to verify the ticket, the connection between the zero-trust network proxy and the intelligent gateway is interrupted. For the traffic of applications accessing specific sites outside the access control policy, a network access request is initiated to the target business server through the zero-trust network proxy to achieve direct connection access.

[0144] The granularity of the access control policy for the zero-trust network is at the end-user level. Based on the access control policy configured by the management console, IOA can distribute different types of access control policies to specified enterprise groups, departments, organizations, or individuals (the smallest granularity is at the user level). The zero-trust access control policy includes the domain name (or network protocol address) of the business system that the end user can access, the port of the business system that the end user can access, and the restricted applications for accessing the business system. The business system supports fuzzy matching and IP segment settings. The following is an example of the access control policy and the description of the fields (the content after / / in the following represents the explanation of the field on the left):

[0145] {

[0146] "accessiblearea": [ / / Configuration node for the reachable area in the policy

[0147] {

[0148] "areamodule": "1", / / Name of the module where the reachable area is located

[0149] "connaddr": "*.com", / / Represents the access object; can be a specific access object or multiple access objects represented by wildcards

[0150] "connport": "", / / Represents the port number of the access object

[0151] "filterport": "0", / / Indicates whether to filter ports

[0152] "name": "Full.com", / / Name of the reachable area

[0153] "type": "domain", / / Indicates whether the "connaddr" item represents a domain name or an IP. If the value is "domain", it means "connaddr" is a domain name; if the value is "IP", it means the value of the "connaddr" item is an IP address

[0154] },

[0155] {

[0156] "areamodule": "1", / / Name of the module where the reachable area is located

[0157] "connaddr": "*.cn", / / Represents the access object; can be a specific access object or multiple access objects represented by wildcards

[0158] "connport": "", / / Indicates the port number of the accessed object

[0159] "filterport": "0", / / Indicates whether to filter ports

[0160] "name": "Full volume.cn", / / Name of the reachable area

[0161] "type": "domain", / / Indicates whether the "connaddr" item represents a domain name or an IP. If the value is "domain", it means "connaddr" is a domain name; if the value is "IP", it means the value of the "connaddr" item is an IP address

[0162] }

[0163] ,

[0164] "module": "policy_ngncloud", / / Name of the access control policy

[0165] "switch": "1", / / Indicates whether to enable this policy. If the value is "1", it means enabled; if the value is "0", it means disabled

[0166] "trustedapp": [ / / Trusted application

[0167] {

[0168] "appname": "Any application", / / Name of the application

[0169] "appversion": "", / / Version number

[0170] "category_serialnum": 1, / / Serial number of the category to which the application belongs

[0171] "categoryname": "Any application", / / Name of the category to which the application belongs

[0172] "corp": "", / / Copyright information of the application

[0173] "procname": "Any application", / / Process name of the application

[0174] "signature": "", / / Signature information

[0175] }

[0177] }

[0178] See​Figure 4G , Figure 4G is a schematic diagram of the compliance detection interface provided by the embodiments of the present application. First, the enterprise administrator fully releases the zero-trust policy on the management side, that is, allows users to access any address through any application. The zero-trust network client reports application information to the zero-trust network server through asynchronous submission for inspection. The security of the application is detected through the submission service to achieve the purpose of initially screening applications and forming a set of trusted applications. The administrator can select applications that comply with the regulations of the enterprise from the set of trusted applications to automatically generate zero-trust access control policies for specific users. The interface is the corresponding interface when the administrator logs in to the zero-trust network client (such as the IOA client) based on the administrator's account. The administrator can configure access control policies associated with the trusted applications in the trusted application configuration area presented on the interface; of course, the administrator can also configure access control policies associated with the business system in the business system configuration area presented on the interface. When the end user accesses a URL through an application, the zero-trust network client collects process information, the target resource being accessed, device information, and login user information, and sends this information to the zero-trust network server through asynchronous submission for inspection. The zero-trust network server retrieves application information from the application library, calls the cloud interface for submission through the submission service, saves the submission result after the submission is completed, identifies the data set, and forms an application library for the administrator to use. The administrator checks several dimensions from it, including the process file path, process version, process MD5, process SHA256, signature information, etc., to automatically generate the trusted application information in the zero-trust policy and send it to the terminal environment of the specified logged-in user.

[0179] See Figure 7 , Figure 7 is a schematic diagram of the architecture of the access processing system of the zero-trust network provided by the embodiments of the present application. A dynamic compliance detection scheme is introduced through the linkage between the server and the terminal. Figure 7 There are parts in Figure 6 that are the same as those in Figure 6 and can be directly referred to the description for Figure 7As shown, when the access subject initiates a network access request for the access object through the application, in step 1, the IOA client first hijacks the network access request (pid-url) initiated by the application through the zero-trust network proxy. In step 2, the zero-trust network proxy sends an authentication request to the IOA client (i.e., the zero-trust network proxy requests a credential for this network access request from the IOA client). Among them, the request parameters include the source IP or domain name, source port, destination IP or domain name, destination port, and the process identifier (PID, Process IDentification) corresponding to the application. In step 3, the IOA client obtains the process characteristics. In step 4, the IOA client collects the MD5, process path, last modification time of the process, copyright information, signature information, etc. of the process through the PID sent by the zero-trust network proxy, and together with the source IP or domain name, source port, destination IP or domain name, and destination port carried in the network access request sent by the zero-trust network proxy, applies to the IOA server for ticket replacement. In step 5, the IOA client sends the process characteristics to the IOA server for process inspection. If the ticket application is successful, in step 6, the IOA client returns the ticket, the maximum number of uses of the ticket, and the valid time of the ticket as a response to the zero-trust network proxy.In step 7, the zero-trust network proxy can initiate an Https request to the intelligent gateway, and carry the network request credentials (i.e., ticket) returned by the IOA client in the Authorization header field of the request. In step 8, after receiving the Https request sent by the zero-trust network proxy, the intelligent gateway parses the ticket in the header field and requests the IOA server to verify the ticket. If the verification is successful, then in step 9, a connection is successfully established between the intelligent gateway and the zero-trust network proxy. The intelligent gateway receives the verification result returned by the IOA server. Subsequently, the zero-trust network proxy can send the hijacked network access request initiated by the application to the intelligent gateway. In step 10, the intelligent gateway forwards the request to the corresponding business server to proxy the actual application network access. In step 11, the business server returns the response result to the intelligent gateway. In step 12, the intelligent gateway returns the response result to the zero-trust network proxy. In step 13, the zero-trust network proxy returns the response result to the application. In addition to the normal zero-trust access process from step 1 to step 13, the access processing system of the IOA zero-trust network introduces an IOA compliance detection service. The IOA compliance detection service and the IOA zero-trust business service are two core components of the IOA server. Among them, the purpose of the IOA zero-trust business service is to implement business functions and cooperate with the IOA client and the intelligent gateway to achieve the zero-trust network access function. The IOA zero-trust business service includes core functions such as account authentication, ticket center, submission service, and policy center, and performs secure scheduling of business traffic through the policy control engine. The IOA compliance detection service can implement the dynamic compliance detection scheme proposed in this embodiment of the application, and continuously and dynamically evaluate the behavior of the end user during the period when the zero-trust network access function is enabled, including device dynamic evaluation, process (IOA terminal-related processes and application processes used for network access in the user environment) dynamic evaluation, user behavior dynamic evaluation, and business system dynamic evaluation. Further, it also includes dynamic evaluation based on dynamic verification rules, issues dynamic verification (based on fixed rules or rules based on specific templates) to the terminal, and collects the processing results reported by the terminal within the set time threshold. On the one hand, it receives the data reported by the IOA client (step 14), issues dynamic verification or other instructions to the IOA client after identifying abnormal behavior (step 15). On the other hand, it interacts with the IOA zero-trust business service to query and update data related to the zero-trust network function (steps 16 and 17). The related data includes active devices associated with the user, ticket information, compliance detection results, and IOA client component information, etc.

[0180] In addition to performing necessary software installations, vulnerability patching, closing high-risk services and ports, and checking for the installation of antivirus or security management software on device terminals through the embodiments of this application, administrators can dynamically configure risk factors and classify and handle them to customize appropriate compliance security detection policies. When the IOA client reports data for login or access requests, after identifying risk behaviors according to the compliance security detection policy, the IOA server performs hierarchical processing based on the risk level. For example, for risk behaviors at a set level (severe or mandatory intervention required), network disconnection is performed, and at the same time, a restricted operation instruction is issued. Before the end-user eliminates the risk behavior, zero-trust network access is not allowed. For example, for normal operations of end-users that may trigger rules (corresponding to a set level), the server initiates dynamic verification of the terminal, user, and main processes, automatically issues verification requests for multi-factor authentication and device authentication, thereby actively collecting the security status of the user and preventing the spread of threat behaviors. For abnormal behavior scenarios, the IOA server can automatically perform network disconnection or forced logout on the specified device, interrupting the zero-trust network access function.

[0181] As an example, dynamic verification refers to an active detection form by the IOA server for the IOA client. By issuing fixed dynamic verification rules or rules based on specific templates to the terminal and collecting the processing results reported by the terminal within a set time threshold, if the reported result of the terminal matches the expectation (specifically, the information reported by the client compared with the baseline data source for the server's dynamic verification), the verification is successful, and the IOA server normally provides services to the IOA client. If the verification fails or no information is reported by the IOA client within the specified time, the verification fails, and the IOA server executes relevant instructions according to the set algorithm, such as alarming, issuing a forced upgrade, or forcing the terminal to log out and prohibiting login, etc.

[0182] As an example, the methods, timing, and frequencies of the IOA server's dynamic verification can be set on the management side. According to established rules, verification can be automatically initiated for device terminals that may be abnormal, or by controlling the verification timing and frequency, ensuring that each device can be verified. The IOA server supports administrators to manually force dynamic verification of a certain device on the management side.

[0183] The following elaborates on the dynamic compliance detection solution in detail.

[0184] First, the client builds in a response mechanism for fixed dynamic verification rules and a response mechanism for dynamic verification rules based on set templates.

[0185] The dynamic verification rules built into the client include fixed dynamic verification rules and rules based on set templates. Among them, the fixed dynamic verification rules include: terminal hardware attribute detection, random sampling detection of IOA client components, critical service running detection, critical thread detection, and device authenticity detection, etc.

[0186] The fixed dynamic verification rules include: terminal hardware attribute detection. The IOA client collects the hardware attributes of the terminal, such as the basic input / output system, system disk serial number, universal unique identifier, asset number, device identifier, etc. The benchmark data source for the dynamic verification of the IOA server is the hardware attributes reported by the terminal user to the IOA server when logging in to obtain an identity ticket, or the hardware attributes reported by the device standardization function to the IOA server when the device standardization function is enabled.

[0187] The fixed dynamic verification rules include: random sampling detection of IOA client components. The IOA server instructs the IOA client to randomly collect the signature information, hash (md5 or SHA256) value, file size, version information, etc. of at least one binary file in the installation directory. After the IOA client collects this information, it reports the information to the IOA server for comparison. The benchmark data source for the dynamic verification of the IOA server is the data generated when the IOA version is compiled and packaged in the CI system.

[0188] The fixed dynamic verification rules include: critical service running detection. The IOA server instructs the IOA client to randomly collect the running status information of the critical services of the IOA client. The running status information includes service running status, service probing information, executable file detection information corresponding to the service (to prevent forgery), service loading module information (such as dynamic link libraries, detecting whether these files are system files or IOA components, detecting signature information, hash list), etc. After the IOA client collects this information, it reports the information to the IOA server for comparison. The benchmark data source for the dynamic verification of the IOA server is the data generated when the IOA version is compiled and packaged in the CI system and the information historically reported by the IOA client to the IOA server.

[0189] The fixed dynamic verification rules include: critical thread detection. The IOA client builds the logic of traversing and collecting all thread information in this process in the critical components. When receiving the dynamic verification instruction from the IOA server, the IOA client triggers the logic of collecting thread information. After collecting the thread start function name, the module where the thread is located, and the thread stack information, it reports the information to the IOA server for comparison. The benchmark data source for the dynamic verification of the IOA server is the information generated by code scanning when the IOA version is compiled and packaged in the CI system.

[0190] The fixed dynamic verification rules include: device authenticity detection. The IOA server sends device authenticity detection to the specified terminal, forces the terminal to send heartbeat information, and at the same time reports several calculation data according to the protocol agreed with the IOA server. The benchmark data source for the dynamic verification of the IOA server is the protocol data agreed between the front and back ends of the IOA and the device and process information reported by historical heartbeats.

[0191] The dynamic verification rules built into the client include rules based on set templates. To enrich the data types of dynamic verification and increase the difficulty of hacker debugging and cracking, the IOA server can initiate dynamic verification based on set templates. For example, the IOA server generates an algorithm for generating encryption and decryption keys based on the encryption and decryption mapping table of the IOA client version installed in the device and the device hardware attributes for a specific device, and attaches random ciphertext information. It requires the IOA client to generate encryption and decryption keys based on the encryption and decryption mapping table of the corresponding IOA version and the device hardware attribute information, decrypt the random ciphertext, and attach the plaintext decrypted from the ciphertext in a specified format in the data sent to the IOA server. Since only specific devices with the specified version of the IOA component installed can successfully decrypt the ciphertext randomly generated by the IOA server and pass the verification, it can be verified that the IOA client components in specific devices are compliant and not forged.

[0192] As an example, when compiling and packaging, data such as the client component list (name, portable executable file, hash value, etc.) and thread information with key markers (module, thread name) are collected through tools such as code scanning to generate data as the server benchmark data. See Figure 8 , Figure 8 is the compilation and packaging flowchart provided by the embodiment of the present application. After manually or automatically triggering the automatic compilation and packaging process of the CI system, before performing a full-scale code compilation, in step 801, the pre-step of the CI system compilation project is executed. For example, network inspection and parameter inspection are performed. In step 802, the thread information marked by the code scanning tool for the IOA client components is scanned as the source of the key thread detection benchmark data for the server dynamic verification. In step 803, the static white box mapping table generation tool is automatically called to generate the encryption and decryption mapping table. During compilation, modules or components related to encryption and decryption will be built with the encryption and decryption mapping table, so that the encryption and decryption mapping tables (white box libraries) of each different version of the IOA component are different. Figure 8The white-box encryption and decryption mapping table shown is automatically generated when the product is compiled and packaged in the CI system. The CI system can ensure that different versions of the IOA product correspond to different mapping tables. The IOA server stores the correspondence between the version and the mapping table. In step 804, a full-scale code compilation is performed. The CI system builds the full-scale server code compilation process with the built-in white-box key mapping table. The IOA clients of each platform version use the white-box encryption and decryption mapping table to perform the full-scale client code compilation and build process. The white-box encryption and decryption mapping table is then packaged into the relevant service components of the IOA server and the binary files of the IOA clients of each platform version. Before archiving the clients of each platform version, in step 805, the hash information of the client components is automatically collected and archived. In step 806, the mapping table is built into the binary file of the installation package, the binary file after automatic compilation and signature is scanned, and the hash information of the components is collected, so as to package and generate the default data. The correspondence between the IOA version and the hash information of the client components is stored in the server deployment package as the reference data to provide a basis for the subsequent verification of the IOA client components. The archived IOA server and IOA clients form the IOA installation and deployment package. After passing the test and acceptance and gradually gray-scaling, it can be deployed to the enterprise for formal use.

[0193] Second, provide the function for the administrator to classify and combine the dynamic evaluation factors, and issue the dynamic compliance detection policy to the IOA client after the configuration is completed.

[0194] The IOA server provides the administrator with dynamic evaluation factors, so as to flexibly issue the dynamic compliance detection policy for continuous risk assessment, so as to evaluate the user access behavior in real time and the device risk assessment of real-time device changes. The dynamic evaluation factors include devices, user access behavior, applications, user locations, etc. Each dynamic evaluation factor has a default priority. The administrator can adjust the priority of each dynamic evaluation factor according to the enterprise's needs. At the same time, the administrator can combine multiple dynamic evaluation factors to form a dynamic compliance detection policy applicable to different scenarios.

[0195] As an example, the user location factor refers to the egress IP of the network where the user is located when performing zero-trust network access, which is obtained through the following steps: First, the IOA server maintains the business service configuration. The configuration is completed in response to the operations of enterprise administrators, and the configuration content includes the server IPs corresponding to each IP segment, the domain name list, and the business service information deployed on the servers. Second, the IOA client regularly pulls the business service configuration from the IOA server. When the business service configuration in the IOA server changes, it actively pushes the changes to the IOA client to trigger the IOA client to pull the latest configuration from the IOA server. Third, the IOA server enables the IP address query service to receive requests from the IOA client to query its own egress IP, obtains the egress IP from the HTTP Header, and sends the egress IP as the main body of the response to the IOA client. Fourth, configure the cycle frequency. The IOA client regularly sends requests for the device IP address query service to the IOA server. After querying the egress IP, the IOA client performs cache processing. The operating system can use application programming interfaces such as NotifyRouteChange and NotifyAddrChange to monitor changes in the network environment. Once the IP routing table changes, a network card is disabled, or the address of a network card changes, it immediately triggers the IOA client to send a request for the device IP address query service to the IOA server to obtain the latest egress IP. If the location where the user initiates zero-trust network access frequently changes and the change frequency is high (higher than the frequency domain threshold), the compliance detection service in the IOA server considers the access abnormal, initiates an alarm, restricts network access behavior, and notifies the administrator for verification.

[0196] As an example, the terminal factor mainly refers to the terminal hardware attributes and terminal software information. Among them, the terminal hardware attributes include the basic input / output system, the system disk serial number, the universal unique identifier, the asset number, the device identifier, etc., and the terminal software information includes the operating system version number, the system software, the enterprise-required essential software (such as a certain type of management or internal real-time communication software that enterprises require employees to install), etc.

[0197] As an example, the user access behavior factor mainly refers to the user's daily access time, the business systems accessed daily, and the frequency of accessing business systems. Introducing this factor is mainly for dynamic detection of this weak point of users (users are the most vulnerable factor in the zero-trust architecture). When formulating zero-trust access policies, different enterprise resource access policies can be formulated for enterprise employees at different positions and levels. When the system identifies that the user accesses enterprise resources at a time point inconsistent with the user's access habits, or frequently accesses business systems that do not conform to the zero-trust access policy (although there will be no response, such abnormal accesses will still be recorded), or the frequency of accessing business systems varies greatly from the user's habits, the compliance detection service of the IOA server considers this an abnormal behavior and it is necessary to initiate dynamic verification of specific devices to verify the authenticity of the devices and whether they are compliant accesses of enterprise employees.

[0198] As an example, the application factor mainly includes the application process of the user accessing enterprise resources and the IOA client component information. When the IOA client initiates a ticket application to the IOA server, it obtains the process name of the network access, the process path, the most recent modification time of the process file, the MD5 of the process file, the version number of the process file, the SHA256 of the process file, the copyright information, and the process signature information through asynchronous detection. The IOA client component information includes whether the module information loaded by the component executable file is compliant (whether it contains a normal signature, whether the MD5 is detected as normal, etc.) and whether there are abnormal threads. Because if malicious code steals sensitive information, conducts network illegal access, or sabotage activities without the user's awareness by injecting into the IOA core component, it often does so by creating threads, otherwise it will affect the execution of the normal functions of the IOA. If abnormal threads are found by comparing the threads of the key components of the network access collected in real time with the benchmark data, it is considered that there is malicious code injection or interference. The compliance detection service of the IOA server considers this an abnormal behavior and it is necessary to initiate dynamic verification of specific devices.

[0199] In some embodiments, each dynamic evaluation factor has a default priority. In response to the administrator's configuration operation, the priorities of the factors can be adjusted according to the actual needs of the enterprise. At the same time, in response to the administrator's configuration operation, multiple dynamic evaluation factors can be combined to form a dynamic compliance detection strategy applicable to different scenarios.

[0200] The following gives several scenarios as examples to illustrate the combination of evaluation factors and the configuration of different priorities.

[0201] In some embodiments, the dynamic compliance detection policy includes a combination of user behavior factors, user location factors, and terminal factors. Among them, the change in the network location where the user is located and the priority setting of the scope of the business system accessed are the highest. In such a scenario, when the user's location changes or the business system accessed exceeds the access policy of the zero-trust network, the IOA server automatically performs dynamic verification on the device or executes the logout and network disconnection process.

[0202] In some embodiments, the dynamic compliance detection policy includes a combination of terminal factors and application factors. Among them, the terminal factor has the highest priority setting. When applying for a ticket, if there are multiple devices of the same user online at the same time, or the newly connected device is not in the existing active device list, the IOA server issues dynamic verification for the relevant devices, which will automatically trigger dynamic authentication and multi-factor identity authentication (for example, token login, face recognition, SMS verification code verification). At the same time, it continuously verifies the legality of the IOA component loading module, and also checks whether there are abnormal threads, and initiates continuous asynchronous verification for the application accessing enterprise resources to strengthen the verification.

[0203] The following will gradually describe the process of the server's dynamic verification of relevant devices.

[0204] The first step: The client reports the compliance check data to the compliance detection service of the IOA server, and the zero-trust business service and intelligent gateway of the IOA server report the updated data to the compliance detection service of the IOA server.

[0205] See Figure 7 , when the IOA client starts the identity authentication during login, the IOA client collects the hardware attributes of the device where the IOA client is located through the driver service and sends them to the IOA server. Each time the IOA client executes the zero-trust network access function, the IOA client component collects the login user information, network location, device information, identity ticket, and access application information, and initiates a ticket replacement (identity ticket replacement network access ticket) to the IOA server. The IOA server forwards the request parameters of the IOA client to the compliance detection service. The data reported by the intelligent gateway and the zero-trust business service of the IOA server to the compliance detection service are the active devices associated with the user, ticket information, compliance detection results, and IOA component information, etc. These data are different from the data related to the current access request reported by the IOA client when triggering the compliance detection service, but are used as reference data subsequently.

[0206] The second step: According to the dynamic compliance detection policy (including at least one dynamic evaluation factor) issued by the IOA server, identify whether the user's identity authentication or ticket application is abnormal.

[0207] In some embodiments, the compliance detection service of the IOA server is based on the dynamic compliance detection policy issued by the administrator at the management end. It identifies risks for access requests based on dynamic evaluation factors (such as devices, user access behaviors, applications, user locations, etc.). The scenarios where the behaviors are determined to be abnormal are described below.

[0208] As an example, regarding the terminal factor, if the same user logs in on different devices simultaneously, the device information uploaded by the user when logging in or applying for a ticket is not in the existing active device list, or the device information uploaded by the user when logging in or applying for a ticket is in the active device list but the key information does not match, these situations are all determined to be abnormal by the IOA compliance detection service, and dynamic verification is initiated. If the same login ticket appears on at least two different devices simultaneously, it is considered a high-risk scenario (identity ticket theft), and the zero-trust network access of the corresponding device is immediately interrupted, and the device is blacklisted to prohibit identity authentication and network access.

[0209] As an example, regarding the user access behavior factor, if the time when the end-user accesses enterprise resources is significantly different from the daily habit (such as accessing enterprise resources in the early morning), or the business systems accessed and the frequency of accessing business systems are significantly different from the user's historical records, this situation is considered to have the possibility of account theft.

[0210] As an example, regarding the user location factor, if the end-user accesses enterprise resources from different network locations simultaneously, or the location of accessing enterprise resources this time is different from the network location with high historical access frequency. The change in the network location where the user is located when accessing enterprise resources is an important reference factor for the security of zero-trust network access, and it can be used to detect the scenario where the account is logged in remotely.

[0211] As an example, regarding the application factor, it involves the application process accessing the enterprise business system through the zero-trust network function and the component process of the IOA client. Abnormal scenarios of the application factor include that the application accessed by the end-user to enterprise resources is found to be abnormal after inspection, or there are abnormal loading modules or abnormal thread executions in the IOA zero-trust network access components detected. The compliance detection service of the server needs to identify and intervene in a timely manner.

[0212] Step 3: For the access behavior that may be abnormal, the IOA server automatically initiates dynamic verification for the terminal.

[0213] As an example, the dynamic verification process for terminal factors is as follows. The verification initiated for terminal factors occurs in scenarios where an attacker uses an unregistered device to access the zero-trust network or the identity ticket of an enterprise employee is stolen. The same user logs in on different devices simultaneously, the device information uploaded when the user logs in or applies for a ticket is not in the existing active device list, or the device information uploaded when the user logs in or applies for a ticket is in the active device list but the key information does not match. In these cases, the compliance detection service of the IOA server will initiate dynamic verification for the device that logs in or applies for a ticket. If the compliance detection service detects that the same login ticket appears on at least two different devices within the validity period of the ticket, it is considered a high-risk scenario (identity ticket theft), and the access to the zero-trust network of the corresponding device will be immediately interrupted, and the device will be blacklisted, and identity authentication and network access will be prohibited. The machines identified as abnormal after dynamic verification will be removed from the active device list, and subsequent access to the zero-trust network will be prohibited.

[0214] In Scenario 1, the same user has at least two active devices, and both respond to the server's dynamic verification within the specified time range. At least two device software and hardware information verification tasks are issued for the active devices. The output of each verification task is expected to be the same, and each verification task can only be reported once. That is, if there are at least two information collections and data reports for a single verification task, the verification task is considered abnormal. The device responds to the server's dynamic verification, but the response content needs to be consistent with the reference data, and the response content of multiple verifications is the same. Only in this way is the dynamic verification considered successful. If there are two or more information collections and data reports for the verification task of a certain device, the verification task is abnormal, and the device is prohibited from connecting to enterprise resources. If the results of two consecutive verification tasks of a certain device are inconsistent, or the results of each device software and hardware verification are different from the reference data, the verification task is also considered abnormal, and the account authentication and network access of the corresponding device are terminated.

[0215] In Scenario 2, the same user is active on at least two devices. Some of these devices respond to dynamic verification content, while some do not respond or respond with incorrect verification content. For the devices that respond to the dynamic verification content, a processing procedure similar to that in Scenario 1 is adopted. It is detected that the response content of multiple dynamic verifications is consistent with the reference data and the response contents of multiple verifications are the same. Only in this way is the dynamic verification considered successful; otherwise, the dynamic verification fails, and the device is restricted from performing identity authentication and network access. For the devices that do not respond to the verification content or respond with incorrect verification content, when the compliance detection service of the IOA server issues a verification task, a verification random number is added and sent to the terminal, and at the same time, it is synchronized to the ticket service in the zero-trust business service of the IOA server. When the terminal initiates a network access and applies to the server for a network access ticket, it carries the verification random number in the verification task. If the ticket service detects that the random numbers are inconsistent, it is considered that the terminal verification is untrusted, and the ticket application is rejected. Therefore, such devices that do not respond or respond with incorrect content will be automatically isolated by the zero-trust network.

[0216] As an example, the dynamic verification process for the user access behavior factor is as follows: For the situation where the time when the end-user accesses enterprise resources is significantly different from the daily habit (such as accessing enterprise resources in the early morning), and the business system accessed and the frequency of accessing the business system are significantly different from the user's historical records, the server immediately issues a forced logout instruction and forcibly issues multi-factor authentication for identity verification. If multi-factor identity authentication (such as token, face recognition, employee mobile phone SMS verification code, etc.) cannot be successfully completed within the specified time or specified number of attempts, the verification is considered to have failed.

[0217] As an example, the dynamic verification process for the user location factor is as follows: The end-user accesses enterprise resources from different network locations simultaneously, or the location where the enterprise resources are accessed this time is different from the network location of historical high-frequency access. According to the parameters set in the policy, the server immediately interrupts the zero-trust network access of the corresponding device, blacklists the device, and prohibits identity authentication and network access. At the same time, multi-factor identity authentication is initiated, and terminal dynamic verification is also carried out. If multi-factor identity authentication (such as token, face recognition, employee mobile phone SMS verification code, etc.) cannot be successfully completed within the specified time or specified number of attempts, the verification is considered to have failed.

[0218] As an example, the dynamic verification process for application factors is as follows: it involves application processes that access enterprise business systems through zero-trust network functions and component processes of IOA clients. The server issues dynamic verification for terminal applications. The goal of dynamic verification is the application process information of terminal users accessing enterprise resources through third-party applications and the process information of IOA core components, including module information loaded by components and thread information collected in real time. The client responds to the server's dynamic verification instructions, collects the names of application processes that frequently access business systems, process paths, the most recent modification time of process files, process file MD5, process file version number, process file SHA256, copyright information and process signature information, and initiates centralized inspection to the threat cloud check service. After inspection, if the abnormal rate is lower than the device parameters, the zero-trust network access interruption processing of the abnormal process is executed. If it is higher than the set parameters, the device-level zero-trust network access disconnection processing is executed.

[0219] At the same time, after receiving the dynamic verification of the server for the detection of IOA key components, the client triggers the operation of the module loading and thread information collection logic in the key components. On the one hand, the information of the modules loaded by the service (including the module binary file path, module file md5, signature information, module file copyright information, process file SHA256, etc.) is collected and sent to the inspection service for inspection. On the other hand, the thread information is collected during the execution of the ticket application and the ticket transfer with the proxy client, and the thread information is sent to the benchmark data comparison of the security detection service. If it is detected that the IOA zero-trust network access component has abnormal loading modules or abnormal thread execution, the zero-trust network access of the corresponding device will be immediately interrupted, and the device will be blacklisted, and identity authentication and network access will be prohibited. Access to internal enterprise resources will not be allowed until the problem is fixed, so as to effectively identify the injection operation of malicious processes against IOA core components (through module injection or malicious code injection), the theft of sensitive information or "free ride" to illegally access enterprise resources.

[0220] As an example, the IOA server can also initiate dynamic verification of a set template. For example, the server provides an algorithm for generating encryption and decryption keys based on the encryption and decryption mapping table of the corresponding IOA version, and attaches a random ciphertext information, requiring the client to generate encryption and decryption keys based on the encryption and decryption mapping table of the corresponding IOA version, decrypt the random ciphertext, and attach the plaintext decrypted from the ciphertext in the specified format in the data sent to the server. This enriches the data type for verification and increases the difficulty for hackers to debug and crack.

[0221] Fourth, based on the dynamic verification results, high-risk behaviors are identified, so that the IOA server triggers the zero-trust network to execute access denial and login prohibition instructions.

[0222] In some embodiments, see Figure 10When the dynamic verification initiated by the IOA server for the IOA client fails, corresponding blocking measures are issued according to the compliance detection policy, such as Figure 10 As shown, the compliance detection service of the IOA server issues a blocking instruction (step 1 in the figure), and at the same time interacts with the zero-trust business service of the IOA server to execute the device blacklisting and service blocking tasks, that is, not responding with tickets to the specified device, rejecting subsequent ticket verifications, and prohibiting the device from logging in again for identity authentication, etc. (such as Figure 10 Steps 2 and 3 in). After receiving the blocking instruction, on the one hand, the IOA client rejects the local ticket application request of the proxy client (such as Figure 10 Steps 4 and 5 in), on the other hand, the IOA server refuses to respond with network application tickets to the IOA client of the specified device (such as Figure 10 Steps 6 and 7 in), and at the same time the IOA server refuses the ticket verification of the intelligent gateway (such as Figure 10 Steps 8 and 9 in), until the IOA client repairs the abnormal items and passes the verification of the compliance detection service, the device is rejected by the IOA server outside the zero-trust compliant device list, and the zero-trust network access function is prohibited.

[0223] In the embodiment of the present application, by combining the storage and use of sensitive information by the IOA server and the IOA client, the attack cost of crackers can be increased while timely identifying and repairing problems such as theft of sensitive information, enhancing the availability and security of the zero-trust network control system. In the zero-trust network architecture of the embodiment of the present application, a dynamic compliance detection scheme is introduced through the linkage of the IOA server and the IOA client. In addition to static compliance detections such as installing necessary software, patching vulnerabilities, closing high-risk services and ports, and whether anti-virus or security management software is installed on the device terminal, a compliance detection policy is obtained by dynamically configuring and hierarchically disposing of dynamic evaluation factors. After a risk behavior is identified based on the compliance detection policy, the IOA server initiates dynamic verification for a specific device, and performs hierarchical processing based on the compliance detection security policy according to the results of the dynamic verification. For risk behaviors at the set level (severe or mandatory intervention), network disconnection disposal is performed, and at the same time, a restricted operation instruction is issued. Before the end user eliminates the risk behavior, zero-trust network access is not allowed. In the embodiment of the present application, for normal operations that may trigger rules by end users, the server initiates dynamic verification of the terminal, user, and main processes, automatically issues multi-factor authentication and device authentication, and actively collects the security status of users, so as to prevent the spread of threat behaviors. For abnormal scenarios, the IOA server can automatically perform network disconnection or forced logout processing on the specified device, interrupting the zero-trust network access function.

[0224] In the embodiments of the present application, by continuously detecting abnormal behaviors that pose threats to enterprise security and preventing the spread of malicious attack behaviors within the enterprise scope, compared with the method of periodically waiting for the IOA client to report data and then making a security status determination, it is possible to increase the attacker's attack cost while detecting the occurrence of abnormal behaviors in a timely manner, improving the efficiency and accuracy of discovering abnormal behaviors; it is also possible to actively trigger the active verification of some devices based on the classification principle, reducing the occupation of enterprise bandwidth by excessive and frequent full-scale security detections while improving the recognition accuracy of threat attacks; and it is possible to effectively repair problems such as the theft of sensitive information while increasing the attacker's attack cost, enhancing the usability and security of the zero-trust network control system.

[0225] Next, the implementation of the access request processing device 255 of the zero-trust network provided by the embodiments of the present application as a software module will be further described. In some embodiments, as Figure 2 shown, the software module stored in the access request processing device 255 of the zero-trust network in the memory 250 may include: a receiving module 2551, configured to receive compliance check data, where the compliance check data is generated based on a data access request for the zero-trust network; a matching module 2552, configured to perform a matching process on the compliance check data and the dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor representing an abnormal data access request in the dynamic compliance detection policy; a verification module 2553, configured to initiate a dynamic verification of the corresponding dynamic compliance detection policy when the abnormal dynamic evaluation factor meets the dynamic verification condition; and a response module 2554, configured to perform an operation that complies with the dynamic compliance detection policy for the data access request according to the result of the dynamic verification.

[0226] In some embodiments, before the matching module 2552 performs a matching process on the compliance check data and the dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor representing an abnormal data access request in the dynamic compliance detection policy, in response to a configuration operation for at least one dynamic evaluation factor, the priority and abnormal conditions of each dynamic evaluation factor are obtained; the priority and abnormal conditions of at least one dynamic evaluation factor are determined as the dynamic compliance detection policy.

[0227] In some embodiments, before the verification module 2553 initiates a dynamic verification of the corresponding dynamic compliance detection policy, in response to a configuration operation for the dynamic verification, the fixed dynamic verification rule and the non-fixed dynamic verification rule corresponding to the dynamic verification are obtained; the fixed dynamic verification rule and the non-fixed dynamic verification rule corresponding to the dynamic verification are encapsulated into the dynamic compliance detection policy, and the dynamic compliance detection policy is sent to the zero-trust network client that receives the data access request; reference data that matches the fixed dynamic verification rule is obtained, where the reference data is used as a verification basis during the dynamic verification process.

[0228] In some embodiments, the verification module 2553 is further configured to, when the fixed dynamic verification rule is the hardware attribute of the terminal installed with the zero-trust network client, obtain at least one of the following reference data: the device identifier of the terminal, the asset number of the terminal, the serial number of the system disk of the terminal, the version of the basic input / output system of the terminal; when the fixed dynamic verification rule is the software attribute of the corresponding zero-trust network client, obtain at least one of the following reference data: the signature information of the binary file of the zero-trust network client, the hash information of the binary file of the zero-trust network client, the memory information of the binary file of the zero-trust network client, the version information of the binary file of the zero-trust network client; when the fixed dynamic verification rule is the key service of the zero-trust network client, obtain at least one of the following reference data: the running status of the key service, the activity of the key service, the executable file corresponding to the key service, the loaded components of the key service; when the fixed dynamic verification rule is the key thread of the zero-trust network client, obtain at least one of the following reference data: the thread start function of the key thread, the components of the key thread, the stack information of the key thread; when the fixed dynamic verification rule is the authenticity data of the terminal of the zero-trust network client, obtain at least one of the following reference data: the protocol data configured by the zero-trust network client and the corresponding zero-trust network server, the historical heartbeat data sent by the zero-trust network client to the zero-trust network server.

[0229] In some embodiments, the receiving module 2551 is further configured to: when the data access request is a login request for the zero-trust network client, receive the hardware attribute of the terminal installed with the zero-trust network client and use it as compliance check data; when the data access request is an access request for the target service address, receive the login information of the zero-trust network client, the user location, the hardware attribute, the ticket information corresponding to the access request, and the application information corresponding to the target service address, and use them as compliance check data.

[0230] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is the user location factor. The matching module 2552 is further configured to: obtain the user location of the data access request; perform a matching process on the user location and the abnormal location condition of the user location factor; when the matching result indicates that the user location meets the abnormal location condition of the user location factor, determine the user location factor as the abnormal dynamic evaluation factor characterizing the abnormal data access request; where the abnormal location condition includes at least one of the following: multiple user locations corresponding to the data access request are queried; the distance between the user location corresponding to the data access request and the historical reference location is greater than the distance threshold.

[0231] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is an application factor. The matching module 2552 is further configured to: obtain the process data corresponding to the data access request; perform a matching process on the process data and the abnormal process conditions of the application factor; when the matching result indicates that the process data meets the abnormal process conditions of the application factor, determine the application factor as the abnormal dynamic evaluation factor representing the abnormal data access request; wherein the abnormal process conditions include at least one of the following: the application process of the business application client corresponding to the data access request is detected to be abnormal; the component process of the zero-trust network client corresponding to the data access request is detected to be abnormal.

[0232] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is an access behavior factor. The matching module 2552 is further configured to: obtain the access behavior data of the data access request; perform a matching process on the access behavior data and the abnormal behavior conditions of the access behavior factor; when the matching result indicates that the access behavior data meets the abnormal behavior conditions of the access behavior factor, determine the access behavior factor as the abnormal dynamic evaluation factor representing the abnormal data access request; wherein the abnormal behavior conditions include at least one of the following: the first time interval between the time of the data access request and the historical reference time is greater than the first time interval threshold; the network address corresponding to the data access request is different from the historical network address; for the user account of the data access request, determine the second time interval between the data access request and the most recent historical data access request of the user account for the network address, and the second time interval is less than the second time interval threshold.

[0233] In some embodiments, the dynamic evaluation factor configured in the dynamic compliance detection policy is a terminal factor. The matching module 2552 is further configured to: obtain the terminal data of the data access request; perform a matching process on the terminal data and the abnormal terminal conditions of the terminal factor; when the matching result indicates that the terminal data meets the abnormal terminal conditions of the terminal factor, determine the terminal factor as the abnormal dynamic evaluation factor representing the abnormal data access request; wherein the abnormal terminal conditions include at least one of the following: the user account initiating the data access request is logged in simultaneously on multiple terminals; the terminal information corresponding to the data access request does not match the active terminal information.

[0234] In some embodiments, the verification module 2553 is further configured to: when the abnormal dynamic evaluation factor is a terminal factor, send a first dynamic verification request based on hardware attributes to the terminal corresponding to the data access request; when the hardware attribute response data for responding to the first dynamic verification request returned by the terminal within the first dynamic verification time threshold is the same as the reference hardware data corresponding to the first dynamic verification request, and each terminal receives the hardware attribute response data once for each first dynamic verification request, determine that the first dynamic verification corresponding to the first dynamic verification request passes, and continue to respond to the data access request; when the hardware attribute response data for responding to the first dynamic verification request returned by the terminal within the first dynamic verification time threshold is different from the reference hardware data corresponding to the first dynamic verification request, or when each terminal receives the hardware attribute response data multiple times for each first dynamic verification request, determine that the first dynamic verification corresponding to the first dynamic verification request fails.

[0235] In some embodiments, the verification module 2553 is further configured to: when the abnormal dynamic evaluation factor is an access behavior factor or a user location factor, send a second dynamic verification request for identity attributes based on multiple dimensions to the terminal corresponding to the data access request; when the identity attribute response data of multiple dimensions returned by the terminal within the second dynamic verification time threshold is the same as the reference identity data corresponding to the second dynamic verification request, determine that the second dynamic verification corresponding to the second dynamic verification request passes, and continue to respond to the data access request, where the identity attribute response data of multiple dimensions is used to respond to the second dynamic verification; when at least one dimension of the identity attribute response data returned by the terminal within the second dynamic verification time threshold is different from the reference identity data corresponding to the second dynamic verification request, determine that the second dynamic verification corresponding to the second dynamic verification request fails, where at least one dimension of the identity attribute response data is used to respond to the second dynamic verification.

[0236] In some embodiments, the verification module 2553 is further configured to: when the abnormal dynamic evaluation factor is an application factor, send a third dynamic verification request based on process data to the terminal corresponding to the data access request; when the process response data for responding to the third dynamic verification returned by the terminal within the third dynamic verification time threshold is the same as the reference process data corresponding to the third dynamic verification request, determine that the third dynamic verification corresponding to the third dynamic verification request passes and continue to respond to the data access request; when the process response data for responding to the third dynamic verification returned by the terminal within the third dynamic verification time threshold is different from the reference process data corresponding to the third dynamic verification request, determine that the third dynamic verification corresponding to the third dynamic verification request fails.

[0237] In some embodiments, the verification module 2553 is further configured to: when the abnormal dynamic evaluation factor is an application factor, send a fourth dynamic verification request carrying ciphertext to the terminal corresponding to the data access request; when, within the fourth dynamic verification time threshold, the plaintext returned by the terminal for responding to the fourth dynamic verification request is the same as the reference plaintext corresponding to the fourth dynamic verification request, determine that the fourth dynamic verification corresponding to the fourth dynamic verification request passes, and continue to respond to the data access request; wherein, the plaintext is obtained based on the decryption key of the terminal, and the decryption key is generated by the terminal based on the encryption and decryption mapping table; when, within the fourth dynamic verification time threshold, the plaintext returned by the terminal for responding to the fourth dynamic verification request is different from the reference plaintext corresponding to the fourth dynamic verification request, determine that the fourth dynamic verification corresponding to the fourth dynamic verification request fails.

[0238] In some embodiments, the response module 2554 is further configured to: when the abnormal dynamic evaluation factor meets the response restriction condition, query the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy, and perform the response restriction operation on the data access request; wherein, the response restriction operation includes at least one of the following: blocking the terminal corresponding to the data access request response; blocking the user account corresponding to the data access request response; blocking the data access request response; wherein, the risk level of the abnormal dynamic evaluation factor corresponding to the response restriction condition is higher than the risk level of the abnormal dynamic evaluation factor corresponding to the dynamic verification condition.

[0239] In some embodiments, the response module 2554 is further configured to: query the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy, and perform the response restriction operation on the data access request; wherein, the response restriction operation includes at least one of the following: blocking the terminal corresponding to the data access request response; blocking the user account corresponding to the data access request response; blocking the data access request response.

[0240] The embodiments of the present application provide a computer program product or a computer program, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the access request processing method of the zero-trust network in the embodiments of the present application.

[0241] The embodiments of the present application provide a computer-readable storage medium storing executable instructions, wherein the executable instructions are stored, and when the executable instructions are executed by a processor, the processor will be caused to execute the access request processing method of the zero-trust network provided by the embodiments of the present application, for example, as Figures 3A - 3D shown in the access request processing method of the zero-trust network.

[0242] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0243] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0244] As an example, the executable instructions may or may not correspond to files in a file system, may be stored as part of a file that stores other programs or data, for example, stored in one or more scripts in a Hyper Text Markup Language (HTML) document, stored in a single file dedicated to the program under discussion, or stored in multiple cooperating files (for example, files that store one or more modules, subroutines, or code portions).

[0245] As an example, the executable instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed at multiple locations and interconnected by a communication network.

[0246] In summary, through the embodiments of the present application, an abnormal access behavior is identified and a corresponding verification is initiated triggered by a data access request, so as to actively detect the occurrence of the abnormal access behavior, improve the efficiency and accuracy of abnormal behavior discovery, and perform active verification only when the dynamic verification conditions are met, which can reduce the bandwidth occupation caused by excessive and frequent full-scale security detections, and can also improve the accuracy of security protection, enhancing the usability and security of the zero-trust network.

[0247] The above are only the embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A method for processing access requests in a zero-trust network, characterized in that, Including: Receiving compliance check data, where the compliance check data is generated based on a data access request for a zero-trust network; Matching the compliance check data with a dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor in the dynamic compliance detection policy that characterizes an abnormal data access request, where the abnormal dynamic evaluation factor includes at least one of the following: a terminal factor, an access behavior factor, a user location factor, and an application factor; When the abnormal dynamic evaluation factor meets a dynamic verification condition, initiating dynamic verification corresponding to the dynamic compliance detection policy; According to the result of the dynamic verification, querying a response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy and executing the response restriction operation for the data access request, where, in response to a configuration operation for the dynamic verification, obtaining a fixed dynamic verification rule and a non-fixed dynamic verification rule corresponding to the dynamic verification; Encapsulating the fixed dynamic verification rule and the non-fixed dynamic verification rule corresponding to the dynamic verification into the dynamic compliance detection policy and sending the dynamic compliance detection policy to a zero-trust network client that receives the data access request; Obtaining reference data that matches the fixed dynamic verification rule, where the reference data is used as a verification basis during the dynamic verification.

2. The method according to claim 1, wherein Before matching the compliance check data with a dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor in the dynamic compliance detection policy that characterizes an abnormal data access request, the method further includes: In response to a configuration operation for at least one dynamic evaluation factor, obtaining the priority and abnormal conditions of each dynamic evaluation factor; Determining the priority and abnormal conditions of at least one dynamic evaluation factor as the dynamic compliance detection policy.

3. The method according to claim 1, wherein The receiving the compliance check data includes: When the data access request is a login request for a zero-trust network client, receiving the hardware attributes of the terminal installed with the zero-trust network client and using them as the compliance check data; When the data access request is an access request for a target service address, receiving the login information of the zero-trust network client, the user location, the hardware attributes, the ticket information corresponding to the access request, and the application information corresponding to the target service address and using them as the compliance check data.

4. The method according to claim 1, characterized in that, When the dynamic evaluation factor configured in the dynamic compliance detection policy is the user location factor, the matching the compliance check data with a dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor in the dynamic compliance detection policy that characterizes an abnormal data access request includes: Obtaining the user location of the data access request; Matching the user location with the abnormal location conditions of the user location factor; When the matching result indicates that the user location meets the abnormal location conditions of the user location factor, determining the user location factor as the abnormal dynamic evaluation factor that characterizes an abnormal data access request; Where the abnormal location conditions include at least one of the following: Multiple user locations corresponding to the data access request are queried; The distance between the user location corresponding to the data access request and the historical reference location is greater than the distance threshold.

5. The method according to claim 1, wherein The dynamic evaluation factor configured in the dynamic compliance detection policy is the application factor. The process of matching the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy includes: Obtain the process data corresponding to the data access request; Match the process data with the abnormal process conditions of the application factor; When the matching result indicates that the process data meets the abnormal process conditions of the application factor, determine the application factor as the abnormal dynamic evaluation factor representing the abnormal data access request; Among them, the abnormal process conditions include at least one of the following: The application process of the business application client corresponding to the data access request is detected to be abnormal; The component process of the zero-trust network client corresponding to the data access request is detected to be abnormal.

6. The method according to claim 1, wherein The dynamic evaluation factor configured in the dynamic compliance detection policy is the access behavior factor. The process of matching the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy includes: Obtain the access behavior data of the data access request; Match the access behavior data with the abnormal behavior conditions of the access behavior factor; When the matching result indicates that the access behavior data meets the abnormal behavior conditions of the access behavior factor, determine the access behavior factor as the abnormal dynamic evaluation factor representing the abnormal data access request; Among them, the abnormal behavior conditions include at least one of the following: The first time interval between the time of the data access request and the historical reference time is greater than the first time interval threshold; The network address corresponding to the data access request is different from the historical network address; For the user account of the data access request, determine the second time interval between the data access request and the most recent historical data access request of the user account for the network address, and the second time interval is less than the second time interval threshold.

7. The method according to claim 1, wherein The dynamic evaluation factor configured in the dynamic compliance detection policy is the terminal factor. The process of matching the compliance check data with the dynamic compliance detection policy of the zero-trust network to obtain the abnormal dynamic evaluation factor representing the abnormal data access request in the dynamic compliance detection policy includes: Obtain the terminal data of the data access request; Match the terminal data with the abnormal terminal conditions of the terminal factor; When the matching result indicates that the terminal data meets the abnormal terminal conditions of the terminal factor, determine the terminal factor as the abnormal dynamic evaluation factor representing the abnormal data access request; Among them, the abnormal terminal conditions include at least one of the following: The user account initiating the data access request is logged in simultaneously on multiple terminals; The terminal information corresponding to the data access request does not match the active terminal information.

8. The method according to claim 1, wherein When the abnormal dynamic evaluation factor meets the dynamic verification condition, initiate the dynamic verification corresponding to the dynamic compliance detection policy, including: When the abnormal dynamic evaluation factor is a terminal factor, send a first dynamic verification request based on hardware attributes to the terminal corresponding to the data access request; The method further includes: When the hardware attribute response data returned by the terminal within the first dynamic verification time threshold for responding to the first dynamic verification request is the same as the reference hardware data corresponding to the first dynamic verification request, and for each first dynamic verification request, each terminal receives the hardware attribute response data once, determine that the first dynamic verification corresponding to the first dynamic verification request passes, and continue to respond to the data access request; When the hardware attribute response data returned by the terminal within the first dynamic verification time threshold for responding to the first dynamic verification request is different from the reference hardware data corresponding to the first dynamic verification request, or for each first dynamic verification request, when each terminal receives the hardware attribute response data multiple times, determine that the first dynamic verification corresponding to the first dynamic verification request fails.

9. The method according to claim 1, wherein When the abnormal dynamic evaluation factor meets the dynamic verification condition, initiate the dynamic verification corresponding to the dynamic compliance detection policy, including: When the abnormal dynamic evaluation factor is an access behavior factor or a user location factor, send a second dynamic verification request for identity attributes based on multiple dimensions to the terminal corresponding to the data access request; The method further includes: When, within the second dynamic verification time threshold, the identity attribute response data of multiple dimensions returned by the terminal is the same as the reference identity data corresponding to the second dynamic verification request, determine that the second dynamic verification corresponding to the second dynamic verification request passes, and continue to respond to the data access request, where the identity attribute response data of multiple dimensions is used to respond to the second dynamic verification; When, within the second dynamic verification time threshold, at least one dimension of the identity attribute response data returned by the terminal is different from the reference identity data corresponding to the second dynamic verification request, determine that the second dynamic verification corresponding to the second dynamic verification request fails, where the at least one dimension of the identity attribute response data is used to respond to the second dynamic verification.

10. The method according to claim 1, wherein When the abnormal dynamic evaluation factor meets the dynamic verification condition, initiate the dynamic verification corresponding to the dynamic compliance detection policy, including: When the abnormal dynamic evaluation factor is an application factor, send a third dynamic verification request based on process data to the terminal corresponding to the data access request; The method further includes: When, within the third dynamic verification time threshold, the process response data returned by the terminal for responding to the third dynamic verification is the same as the reference process data corresponding to the third dynamic verification request, determine that the third dynamic verification corresponding to the third dynamic verification request passes and continue to respond to the data access request; When, within the third dynamic verification time threshold, the process response data returned by the terminal for responding to the third dynamic verification is different from the reference process data corresponding to the third dynamic verification request, it is determined that the third dynamic verification corresponding to the third dynamic verification request fails.

11. The method according to claim 1, wherein When the abnormal dynamic evaluation factor meets the dynamic verification condition, initiating the dynamic verification corresponding to the dynamic compliance detection policy includes: Sending a fourth dynamic verification request carrying ciphertext to the terminal corresponding to the data access request; The method further includes: When, within the fourth dynamic verification time threshold, the plaintext returned by the terminal for responding to the fourth dynamic verification request is the same as the reference plaintext corresponding to the fourth dynamic verification request, it is determined that the fourth dynamic verification corresponding to the fourth dynamic verification request passes, and the data access request is continuously responded to; Wherein, the plaintext is obtained based on the decryption key of the terminal, and the decryption key is generated by the terminal based on the encryption and decryption mapping table; When, within the fourth dynamic verification time threshold, the plaintext returned by the terminal for responding to the fourth dynamic verification request is different from the reference plaintext corresponding to the fourth dynamic verification request, it is determined that the fourth dynamic verification corresponding to the fourth dynamic verification request fails.

12. The method according to any one of claims 1-11, characterized in that, Querying the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy and performing the response restriction operation on the data access request includes: When the abnormal dynamic evaluation factor meets the restricted response condition, querying the response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy and performing the response restriction operation on the data access request; Wherein, the risk level of the abnormal dynamic evaluation factor corresponding to the restricted response condition is higher than the risk level of the abnormal dynamic evaluation factor corresponding to the dynamic verification condition.

13. The method according to any one of claims 1 to 11, characterized in that, The response restriction operation includes at least one of the following: Blocking the terminal corresponding to the data access request response; Blocking the user account corresponding to the data access request response; Blocking the response to the data access request.

14. An access request processing device for a zero-trust network, characterized in that, Including: A receiving module, configured to receive compliance check data, wherein the compliance check data is generated based on a data access request for a zero-trust network; A matching module, configured to perform a matching process on the compliance check data and the dynamic compliance detection policy of the zero-trust network to obtain an abnormal dynamic evaluation factor representing an abnormal data access request in the dynamic compliance detection policy, and the abnormal dynamic evaluation factor includes at least one of the following: a terminal factor, an access behavior factor, a user location factor, and an application factor; A verification module, configured to initiate dynamic verification corresponding to the dynamic compliance detection policy when the abnormal dynamic evaluation factor meets the dynamic verification condition. In response to a configuration operation for the dynamic verification, a fixed dynamic verification rule and a non-fixed dynamic verification rule corresponding to the dynamic verification are obtained; the fixed dynamic verification rule and the non-fixed dynamic verification rule corresponding to the dynamic verification are encapsulated into the dynamic compliance detection policy, and the dynamic compliance detection policy is sent to a zero-trust network client that receives the data access request; reference data matching the fixed dynamic verification rule is obtained, where the reference data is used as a verification basis during the dynamic verification. A response module, configured to query a response restriction operation corresponding to the abnormal dynamic evaluation factor from the dynamic compliance detection policy according to the result of the dynamic verification, and execute the response restriction operation for the data access request.

15. A computer program product comprising computer-executable instructions, characterized in that, When the computer-executable instructions are executed by a processor, the method for processing an access request of the zero-trust network according to any one of claims 1 to 13 is implemented.

Images