Network access method, device, system, equipment and storage medium

Abstract

The embodiments of the present application provide a network access method, device, system, equipment and storage medium, which relate to the fields of cloud technology and security. The method includes: when a network access request sent by any application is intercepted, the terminal obtains the process characteristic information corresponding to the network access request; generates a ticket application according to the process characteristic information, and sends the ticket application to the server; when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, a virtual access credential is generated according to the access information corresponding to the network access request; the network access request and the virtual access credential are sent to the server, so that the server authenticates the network access request according to the virtual access credential. Through this application, terminal users can obtain a continuous, stable and high-quality network access experience, and improve the stability and availability of the security management system.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of Internet technology, and relate to but are not limited to a network access method, apparatus, system, device and storage medium. Background Art

[0002] The zero-trust security management system (iOA) is a new "4A office" approach that grants access rights based on trusted identities, trusted devices, trusted applications, and trusted links, and enforces that all access must be authenticated, authorized, and encrypted. It helps enterprises securely access authorized resources to handle any business at any time, regardless of the location and device used.

[0003] At present, in any security management system including the iOA system, for each network access request by the user, a ticket will be synchronously applied to the server through the network, that is, the server will be requested to return the network request credential.

[0004] However, each network access request requires synchronous application of tickets to the server through the network. Before the application actually accesses the business site, it needs to synchronously wait for the server to generate and respond to the ticket. In the case of unstable or weak network quality, ticket acquisition timeout or failure is prone to occur, resulting in frequent failures in network access, poor availability, and high network latency. Summary of the invention

[0005] The embodiments of the present application provide a network access method, device, system, equipment and storage medium, which relate to the fields of cloud technology and security. When a network request credential is not successfully received, a virtual access credential is generated, and the network access request is authenticated using the virtual access credential. Thus, on the basis of taking security into consideration, the introduction of the virtual access credential allows the terminal user to obtain a continuous, stable and high-quality network access experience, thereby improving the stability and availability of the security management system.

[0006] The technical solution of the embodiment of the present application is implemented as follows:

[0007] The present invention provides a network access method, which includes:

[0008] When a network access request sent by any application is intercepted, the terminal obtains process feature information corresponding to the network access request;

[0009] Generate a ticket application according to the process characteristic information, and send the ticket application to a server;

[0010] When the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, generating a virtual access credential according to the access information corresponding to the network access request;

[0011] The network access request and the virtual access credential are sent to the server, so that the server authenticates the network access request according to the virtual access credential and implements a network access response to the network access request.

[0012] The embodiment of the present application provides a network access system, the system comprising: a business processing client, a management client, a server and an access gateway; wherein:

[0013] The business processing client is used to intercept a network access request sent by any application, and send an authentication request to the management client in response to the network access request;

[0014] The management client is used to respond to the authentication request, obtain the process characteristic information corresponding to the network access request; and generate a ticket application according to the process characteristic information, and send the ticket application to the server;

[0015] The server is configured to generate a network request credential in response to the ticket application;

[0016] The business processing client is further used to generate a virtual access credential according to the access information corresponding to the network access request when the network request credential returned by the server is not successfully received within a preset time period; and send the network access request and the virtual access credential to the access gateway;

[0017] The access gateway is used to send the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential and implements a network access response to the network access request.

[0018] The present application provides a network access device, the device comprising:

[0019] An acquisition module, used for acquiring process characteristic information corresponding to a network access request sent by any application when the network access request is intercepted;

[0020] A first generating module, configured to generate a ticket application according to the process characteristic information, and send the ticket application to a server;

[0021] A second generating module, when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, generates a virtual access credential according to the access information corresponding to the network access request;

[0022] The sending module is used to send the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential to implement a network access response to the network access request.

[0023] An embodiment of the present application provides a computer program product or a computer program, wherein the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; wherein a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor is used to execute the computer instructions to implement the above-mentioned network access method.

[0024] An embodiment of the present application provides a network access device, including: a memory, used to store executable instructions; a processor, used to implement the above-mentioned network access method when executing the executable instructions stored in the memory.

[0025] An embodiment of the present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute the executable instructions to implement the above-mentioned network access method.

[0026] The embodiments of the present application have the following beneficial effects: when a network access request sent by any application is intercepted, the terminal obtains process characteristic information corresponding to the network access request; and generates a ticket application based on the process characteristic information to apply for a network request credential; when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, a virtual access credential is generated based on the access information corresponding to the network access request; and the virtual access credential is used to authenticate the network access request of the application. In this way, while taking security into consideration, the introduction of virtual access credentials allows terminal users to obtain a continuous, stable and high-quality network access experience, thereby improving the stability and availability of the security management system. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a schematic diagram of an application scenario of the network access method provided in an embodiment of the present application;

[0028] Figure 2 This is an optional architecture diagram of a network access system provided in an embodiment of the present application;

[0029] Figure 3 is a schematic diagram of the structure of a network access device provided in an embodiment of the present application;

[0030] Figure 4 This is an optional flowchart of the network access method provided in the embodiment of the present application;

[0031] Figure 5This is an optional flowchart of the network access method provided in the embodiment of the present application;

[0032] Figure 6 This is an optional flowchart of the network access method provided in the embodiment of the present application;

[0033] Figure 7 is a configuration interface diagram of the iOA system provided in an embodiment of the present application;

[0034] Figure 8 This is a diagram of a business system configuration interface provided by an embodiment of the present application;

[0035] Fig. 9 This is a diagram of a trusted application configuration interface provided by an embodiment of the present application;

[0036] Fig.10 This is a login interface diagram provided in an embodiment of the present application;

[0037] Fig.11 This is a protection strategy and trusted software details interface diagram provided in an embodiment of the present application;

[0038] Fig.12 This is a diagram of a business system interface configured by an administrator provided in an embodiment of the present application;

[0039] Fig.13 It is a schematic diagram of an iOA providing authentication operation for a unified entrance provided by an embodiment of the present application;

[0040] Fig.14 It is a schematic diagram of the overall flow of the network access method provided in the embodiment of the present application;

[0041] Fig.15 This is a schematic diagram of the user login process provided by an embodiment of the present application;

[0042] Fig.16 It is a schematic diagram of the strategy synchronization process provided by an embodiment of the present application;

[0043] Fig.17 It is a schematic diagram of a process in which a client and a server jointly authenticate a single network access request provided by an embodiment of the present application;

[0044] Fig.18 It is a timing diagram of the client and the server jointly performing authentication on the network access request provided by the embodiment of the present application;

[0045] Fig.19 It is a schematic diagram of the process of locally generating and adjusting a process feature library in a terminal provided in an embodiment of the present application;

[0046] Fig. 20 It is a schematic diagram of the generation and verification process of the virtual access credential provided in the embodiment of the present application;

[0047] Fig.21 It is a schematic diagram of the structure of a virtual bill provided in an embodiment of the present application;

[0048] Fig. 22 It is a flow chart of scheme 3 provided in the embodiment of the present application;

[0049] Fig.23 It is a flow chart of Strategy 3 provided in the embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0051] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meaning as those commonly understood by those skilled in the art of the technical field of the embodiments of the present application. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0052] Before explaining the embodiments of the present application, the nouns and key terms involved in the present application are first explained:

[0053] 1) Trusted application: refers to the application carrier that is authorized by the management end and can be accessed by the terminal to the internal business system, including the application name, application MD5 and signature information.

[0054] 2) Reachable zone: refers to the list of internal sites set up by the enterprise that end users can access through the zero-trust network.

[0055] 3) Login credentials: refers to an encrypted string specified by the management server in the security management system (for example, it can be the iOA server in the iOA system) for the user after the user successfully logs in to the management client (the management client here refers to the management client in the security management system, for example, it can be the iOA client in the iOA system), which represents the user's login authorization information, including user information and authorization validity period. The login credentials are encrypted and stored on the client, which can be called a big ticket.

[0056] 4) Network request credential: refers to the authorization information issued by the management server for a single network request, which is used to identify the authorization status of the network request and can be called a receipt or ticket.

[0057] 5) Virtual access credentials: refers to access tickets that are not generated by the server but by the business processing client side. They are designed to improve the stability of end-user network access while taking security into consideration. They can be called virtual tickets or virtual receipts.

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

[0059] 7) Zero Trust Gateway: It is deployed at the entrance of enterprise applications and data resources, responsible for verifying and forwarding each session request to access enterprise resources.

[0060] 8) Business processing client: It is an access agent or proxy client, that is, a terminal access agent, which is deployed on the controlled device to initiate secure access. It is mainly responsible for initiating access requests for trusted identity authentication of the subject. When the identity is verified to be trustworthy, it can establish an encrypted access connection with the access gateway. It is also the policy execution point for access control.

[0061] 9) Access subject: refers to the party that initiates access in the network, the person / device / application that accesses intranet business resources.

[0062] 10) Access object: refers to the party being accessed in the network, namely the enterprise's intranet business resources, data, development and testing environment, operation and maintenance environment, etc.

[0063] 11) Service addressing: refers to the process of finding the server connection address where the backend services of different business modules of the client are deployed in a distributed cascade deployment mode, where different businesses are deployed in different servers.

[0064] The embodiment of the present application provides a network access method, which can solve the network usage problems of terminal users in scenarios such as weak network, abnormal management client, inability to respond to the request of business processing client in time, or inability to respond to the client's ticket application request in time due to network reasons and abnormal management server ticket service. In a general environment, the terminal and the server jointly authenticate the network request, and in combination with the zero-trust access control strategy, the authentication is performed for the device credibility, the destination address of the access, the process characteristics and the permission of the application to access the site. Only after the authentication is successful can the internal site set by the enterprise be accessed. When the terminal fails to apply for a ticket due to network reasons or a server ticket service failure, or when the management client is abnormal and cannot respond to the request of the business processing client in time, the business processing client can create a virtual credential and send it to the access gateway, and the access gateway initiates a ticket verification to the management server. The server implements a safe and efficient ticket verification logic through the virtual ticket verification strategy. When some services fail or the network jitters, it can ensure the normal progress of network access and achieve high-availability network access. On the basis of taking into account security, the sustainable, stable and high-quality network access experience of the terminal user is obtained through service adjustment.

[0065] The network access method provided in the embodiment of the present application is applied to a network access device (the network access device can be any type of terminal, and the network access device includes a business processing client and a management client). First, when a network access request sent by any application is intercepted, the terminal obtains the process characteristic information corresponding to the network access request; generates a ticket application based on the process characteristic information, and sends the ticket application to the server; then, when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, a virtual access credential is generated according to the access information corresponding to the network access request; finally, the network access request and the virtual access credential are sent to the server, so that the server authenticates the network access request according to the virtual access credential, and implements a network access response to the network access request. In the embodiment of the present application, a virtual access credential is used to authenticate the network access request of the application. In this way, on the basis of taking security into consideration, the introduction of the virtual access credential allows the terminal user to obtain a continuous, stable and high-quality network access experience, thereby improving the stability and availability of the security management system.

[0066] The following describes an exemplary application of the network access device of the embodiment of the present application. In one implementation, the network access device provided by the embodiment of the present application can be implemented as any terminal with computing functions, such as a laptop, a tablet computer, a desktop computer, a mobile device (e.g., a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, a portable gaming device), an intelligent robot, etc. In another implementation, the network access device provided by the embodiment of the present application can also be implemented as a server. The following describes an exemplary application when the network access device is implemented as a server.

[0067] See also Figure 1 , Figure 1 1 is a schematic diagram of an application scenario of the network access method provided in an embodiment of the present application. In order to realize the network access response to the network access request, the application scenario 10 corresponding to the network access method in the embodiment of the present application at least includes a terminal 11, a security management system 12 and a target business server 13. The user initiates a network access request through any application on the terminal 100, and the client in the security management system 12 (i.e., the network access system) intercepts the network access request and performs an authentication process for the network access request. In the authentication process, first, the process feature information corresponding to the network access request is obtained; a ticket application is generated according to the process feature information, and the ticket application is sent to the management server; when the network request credential returned by the management server based on the ticket application is not successfully received within a preset time period, a virtual access credential is generated according to the access information corresponding to the network access request; the network access request and the virtual access credential are sent to the management server, so that the management server authenticates the network access request according to the virtual access credential. If the management server authenticates the network access request, the network access request is forwarded to the target business server 13 to realize the network access response to the network access request.

[0068] The network access system provided by the embodiment of the present application is described below. Figure 2 , Figure 2It is an optional architecture diagram of a network access system provided by an embodiment of the present application, wherein the network access system includes: a business processing client 121, a management client 122, a server 123 and an access gateway 124. The business processing client 121 is used to intercept a network access request sent by any application, and send an authentication request to the management client 122 in response to the network access request; the management client 122 is used to obtain process feature information corresponding to the network access request in response to the authentication request; and generate a ticket application according to the process feature information, and send the ticket application to the server; the server 123 is used to generate a network request credential in response to the ticket application; the business processing client 121 is also used to generate a virtual access credential according to the access information corresponding to the network access request when the network request credential returned by the server is not successfully received within a preset time period; and send the network access request and the virtual access credential to the access gateway; the access gateway 124 is used to send the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential to achieve a network access response to the network access request. In some embodiments, the management client 122 may be an iOA client in an iOA system, and the server 123 may be an iOA server in the iOA system.

[0069] The network access method provided in the embodiment of the present application can also be implemented based on a cloud platform and through cloud technology. For example, the server can be a cloud server. Alternatively, a cloud storage can be provided to store access requests, access information, and service configuration information during the network access process in the cloud storage, so that the corresponding information can be directly obtained from the cloud storage during the authentication or verification process.

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

[0071] Figure 3 is a schematic diagram of the structure of a network access device provided in an embodiment of the present application, Figure 3 The network access device shown includes: at least one processor 310, a memory 350, at least one network interface 320 and a user interface 330. The various components in the network access device are coupled together through a bus system 340. It is understood that the bus system 340 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 340 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 340 is not described in detail. Figure 3 Various buses are labeled as bus system 340 .

[0072] The processor 310 can be an integrated circuit chip with 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., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0073] The user interface 330 includes one or more output devices 331 that enable presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 330 also includes one or more input devices 332, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0074] The memory 350 may be removable, non-removable or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drive, optical disk drive, etc. The memory 350 may optionally include one or more storage devices physically away from the processor 310. The memory 350 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 350 described in the embodiment of the present application is intended to include any suitable type of memory. In some embodiments, the memory 350 can store data to support various operations, and examples of these data include programs, modules, and data structures or subsets or supersets thereof, as exemplarily described below.

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

[0076] A network communication module 352, for reaching other computing devices via one or more (wired or wireless) network interfaces 320, exemplary network interfaces 320 include: Bluetooth, Wireless Compatibility Authentication (WiFi), and Universal Serial Bus (USB);

[0077] The input processing module 353 is used to detect one or more user inputs or interactions from one of the one or more input devices 332 and translate the detected inputs or interactions.

[0078] In some embodiments, the device provided in the embodiments of the present application can be implemented in software. Figure 3 A network access device 354 stored in the memory 350 is shown. The network access device 354 may be a network access device in a network access device, which may be software in the form of a program or a plug-in, and includes the following software modules: an acquisition module 3541, a first generation module 3542, a second generation module 3543, and a sending module 3544. These modules are logical, and therefore may be arbitrarily combined or further split according to the functions implemented. The functions of each module will be described below.

[0079] In other embodiments, the device provided in the embodiments of the present application can be implemented in hardware. As an example, the device provided in the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the network access method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs) or other electronic components.

[0080] The network access method provided by the embodiment of the present application will be described below in conjunction with the exemplary application and implementation of the network access device provided by the embodiment of the present application, wherein the network access device may be a terminal in a network access system, wherein the terminal includes a business processing client and a management client, wherein the management client is a client corresponding to the security management system installed on the terminal, and is used to interact with the management server in the security management system to implement access authorization based on a trusted identity, a trusted device, a trusted application, and a trusted link for the network access request on the terminal, thereby achieving secure network access. The server in the embodiment of the present application may be a management server in a security management system.

[0081] Below, the network access method of the embodiment of the present application will be described by taking the security management system as an iOA system as an example, wherein the management client may be an iOA client, the management server may be an iOA server, and the business processing client, the iOA client and the iOA server together form a network access system. Figure 4 , Figure 4 This is an optional flow chart of the network access method provided in the embodiment of the present application. Figure 4 The steps shown are explained.

[0082] Step S401: When a network access request sent by any application is intercepted, the terminal obtains process feature information corresponding to the network access request.

[0083] Here, when the iOA system is installed on the terminal, security management and control can be performed on the applications on the terminal based on the iOA system. Therefore, when the application sends a network access request through the application client to request network access to the target network, the client in the iOA system will intercept the network access request sent by the application to authenticate the network access request and determine whether the network access request can be forwarded to the target business server of the target network.

[0084] In an embodiment of the present application, when the terminal intercepts a network access request sent by any application, the terminal obtains the process characteristic information corresponding to the network access request, where the process characteristic information includes but is not limited to at least one of the following: the last modification time of the process file, MD5, SHA256, copyright information, process signature information (including digest algorithm, root certificate information, intermediate certificate information, signature certificate information, signer name, signature status), etc.

[0085] Step S402: Generate a ticket application based on the process characteristic information, and send the ticket application to the server.

[0086] Here, after obtaining the process characteristic information, a ticket application is generated by taking the target site information, current device information, and logged-in user information requested by the network access request to request the server to generate a network request credential (ie, ticket) for this network access request.

[0087] Step S403, when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, a virtual access credential is generated according to the access information corresponding to the network access request.

[0088] In some embodiments, when the server is able to successfully receive the ticket application, a network request credential is generated in response to the ticket application. The network request credential is the authorization information sent for the network access request and is used to identify the authorization status of the network access request. When the server cannot successfully receive the ticket application, that is, the client fails to apply for the ticket from the server, or the client is abnormal and cannot normally receive the network request credential returned by the server, or the server is abnormal and cannot effectively respond to the ticket application, or the response times out due to network reasons, etc., then within a preset time period, the client cannot successfully receive the network request credential returned by the server based on the ticket application. Therefore, in order to ensure that the network access request can continue to be effectively accessed, the client can generate a virtual access credential. The virtual access credential is generated by the client and is intended to be an access ticket that improves the stability of the terminal user's network access while taking into account security. The virtual access credential can only be applied to this network access request.

[0089] Step S404: sending the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential, and implements a network access response to the network access request.

[0090] In the embodiment of the present application, after the client generates a virtual access credential, the virtual access credential can be sent to the server for access authentication. The server authenticates the network access request based on the virtual access credential to determine whether the network access request is legal. If it is legal, the network access to the network access request is responded to normally. When responding to the network access request, the network access request can be forwarded to the corresponding target business server through the access gateway in the iOA system, and the network access request is responded to by the target business server.

[0091] In some embodiments, the virtual access credential includes at least a ticket header and a ticket body; the ticket body is in an encrypted state, wherein the key for encrypting the ticket body may be a login credential (i.e., a login ticket). Thus, since the login credential is also stored in the server, the server may decrypt the encrypted ticket body based on the login credential. Step S404 may be to send the network access request and the virtual access credential to the server, so that the server identifies the virtual access credential based on the ticket header, and parses the encrypted ticket body, and verifies the virtual access credential through the device identification or MD5 value in the parsing result, thereby authenticating the network access request.

[0092] Here, the server identifies the virtual access credential based on the ticket header, and then parses the encrypted ticket body, and the parsing result includes at least the device identification and the MD5 value of the process. When the parsing result includes the device identification, the process of verifying the virtual access credential can be: the server first obtains the login ticket of the device based on the device identification, and uses the login ticket as key information (key), the number of times the virtual access credential corresponding to the login ticket is used as the value, a key-value pair is formed by the login ticket and the number of times, the number of times the virtual access credential is used in the login ticket is maintained, and the number of times the virtual access credential is used is checked whether it exceeds the set value. If it exceeds, the verification fails, and if it does not exceed the set value, the verification passes.

[0093] When the parsing result includes an MD5 value, the process of verifying the virtual access credential may be: obtaining the MD5 value of the process, searching from the process cache and security detection service of the server whether the process is a risky application, if not, the verification passes, if yes, the verification fails.

[0094] The network access method provided in the embodiment of the present application, when a network access request sent by any application is intercepted, the terminal obtains the process characteristic information corresponding to the network access request; and generates a ticket application based on the process characteristic information to apply for a network request credential; when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, a virtual access credential is generated according to the access information corresponding to the network access request; and the virtual access credential is used to authenticate the network access request of the application. In this way, on the basis of taking security into consideration, by introducing the virtual access credential, the terminal user can obtain a continuous, stable and high-quality network access experience, thereby improving the stability and availability of the security management system.

[0095] In some embodiments, when a security management system is installed on the user's terminal, the network access system used to implement the network access method of the embodiment of the present application may include a business processing client, a management client in the security management system, a management server in the security management system, and an access gateway. Therefore, for the user's network access request, security authentication will be performed through the security management system to determine whether network access can be performed within the security management system. Below, based on the security management system provided in the embodiment of the present application, the network access method of the embodiment of the present application is described.

[0096] Figure 5 is an optional flow chart of the network access method provided in the embodiment of the present application, such as Figure 5 As shown, the method comprises the following steps:

[0097] Step S501: When a user sends a network access request through any application, the service processing client intercepts the network access request.

[0098] Step S502: When the service processing client intercepts the network access request, it sends an authentication request to the management client in response to the network access request.

[0099] Here, the authentication request is used to request authentication of the network access request, thereby implementing a network access response to the network access request.

[0100] Step S503: the management client obtains process characteristic information corresponding to the network access request in response to the authentication request.

[0101] Step S504: the management client generates a ticket application according to the process characteristic information.

[0102] Here, after obtaining the process characteristic information, the target site information, current device information, and logged-in user information requested by the network access request can be brought to generate a ticket application.

[0103] Step S505: The management client sends the ticket application to the management server.

[0104] Step S506: The management server generates a network request credential in response to the ticket application.

[0105] Step S507: The management server sends the generated network request credential to the management client.

[0106] Step S508: The management client returns the network request credential to the business processing client.

[0107] When any of the above steps S504 to S508 is abnormal, the business processing client will not be able to successfully receive the network request credential returned by the server based on the ticket application. Therefore, the method further includes the following steps:

[0108] Step S509, the business processing client determines whether the network request credential returned by the server based on the ticket application is successfully received within a preset time period. If the determination result is no, step S510 is executed, and if the determination result is yes, step S516 is executed.

[0109] Step S510: The service processing client generates a virtual access credential according to the access information corresponding to the network access request.

[0110] In the embodiment of the present application, in order to ensure that the network access request can continue to be effectively accessed, the business processing client can generate a virtual access credential. The virtual access credential is generated by the business processing client and is an access ticket that aims to improve the stability of the terminal user's network access on the basis of taking into account security. The virtual access credential can be only applicable to this network access request, or the virtual access credential has a certain number of uses or a certain period of use, and the virtual access credential is valid within the number of uses or the period of use.

[0111] In some embodiments, the process of sending the network access request and the virtual access credential to the server so that the server authenticates the network access request according to the virtual access credential can be implemented by the following steps S511 to S515:

[0112] Step S511: The service processing client sends a network access request and a virtual access credential to an access gateway.

[0113] Step S512: The access gateway sends the virtual access credential to the management server for ticket verification.

[0114] Step S513: the management server verifies the virtual access credential and determines whether the verification is successful.

[0115] If the verification passes, execute step S514; if the verification fails, execute step S515.

[0116] Step S514: the access gateway forwards the network access request to the target service server, so that the target service server responds to the network access request.

[0117] Step S515: The connection between the access gateway and the service processing client is interrupted.

[0118] In the embodiment of the present application, when the network request credential returned by the server is successfully received within a preset time period, the network request credential is sent to the access gateway, so that the access gateway sends a ticket verification request to the server, and when the server responds to the ticket verification request and the network request credential verification is passed, the client and the access gateway establish a connection channel; the business processing client sends the network access request to the access gateway through the connection channel, so that the access gateway forwards the network access request to the target business server; when the management server responds to the ticket verification request and the network request credential verification fails, the control client and the access gateway are disconnected. Please continue to refer to Figure 5 , the steps performed when the network request credentials returned by the server are successfully received within the preset time period can be implemented by the following steps S516 to S520:

[0119] Step S516: The business processing client sends the network access request and the network request credential to the access gateway.

[0120] Step S517: The access gateway sends the network request credential to the management server for ticket verification.

[0121] Step S518: The management server verifies the network request credentials and determines whether the verification is successful.

[0122] If the verification passes, execute step S519; if the verification fails, execute step S520.

[0123] Step S519: the access gateway forwards the network access request to the target service server, so that the target service server responds to the network access request.

[0124] Step S520: The connection between the access gateway and the service processing client is interrupted.

[0125] In some embodiments, a network access control policy is configured in the security management system, and the network access control policy can be a pre-configured policy or a real-time updated policy, wherein the network access control policy includes at least one of the following: trusted users, trusted applications, and trusted business systems; trusted users are used to define which users in the security management system are trusted and can initiate network access requests; trusted applications are used to define which applications in the security management system are trusted and can initiate network access requests through or to the application; trusted business systems are used to define which business systems in the security management system are trusted and can initiate network access requests to the business systems.

[0126] based on Figure 4 , Figure 6An optional flow chart of a network access method provided in an embodiment of the present application is as follows: Figure 6 As shown, when a network access request sent by any application is intercepted, the method further includes the following steps:

[0127] Step S601: when a network access request sent by any application is intercepted, a pre-configured network access control policy or a currently updated network access control policy is obtained.

[0128] It should be noted that, in the security management system, the policy can be pre-configured before the security management system is used to form a pre-configured network access control policy, and during the use of the security management system, the policy of the security management system can also be configured and updated at any time to form an updated network access control policy. When the network access control policy is updated, the updated network access control policy is obtained, and the updated network access control policy is used to control the security management system.

[0129] Step S602: determine whether the network access request complies with the network access control policy.

[0130] When the judgment result is yes, the step of obtaining the process characteristic information corresponding to the network access request in step S401 is executed, and when the judgment result is no, step S603 is executed.

[0131] Step S603: the application client of the terminal control application is directly connected to the target service server to respond to the network access request.

[0132] In some embodiments, while the terminal sends a ticket application to the server, the network access request of the application can be verified to determine whether the process corresponding to the network access request is a malicious process, including the following steps:

[0133] Step S11, identifying the process corresponding to the network access request through a preset risk process library according to the process feature information.

[0134] Here, the process corresponding to the network access request is filtered through the preset risk process library. When filtering, it can be filtered according to the process feature information to determine whether the process feature information is the same as the risky feature information stored in the preset risk process library. If they are the same, it indicates that the process corresponding to the network access request is a malicious process.

[0135] Step S12: when the identification result indicates that the process corresponding to the network access request is a malicious process, disconnect the network access connection established with the malicious process.

[0136] In other embodiments, while the terminal sends the ticket application to the server, the application may also be verified to determine whether the application is a high-risk application, including the following steps:

[0137] Step S13: Generate an asynchronous inspection request according to the process feature information, where the asynchronous inspection request is used to request the server to detect whether the application is a high-risk application.

[0138] Step S14, receiving the test result returned by the server in response to the asynchronous test request.

[0139] Step S15: When the detection result shows that the application is not a high-risk application, the server responds to the ticket application normally.

[0140] In some embodiments, for some newly created processes, the process feature information of the process can also be matched from a preset process feature library. If a match can be found, there is no need to obtain the process feature information of the process, and the matched process feature information can be directly used. In this case, in step S401, the client obtains the process feature information corresponding to the network access request, which can be achieved by the following steps:

[0141] Step S21: When the process corresponding to the network access request is a newly created process, the creation information of the process is obtained. Here, the creation information includes the ID and the name of the process.

[0142] Step S22, determining the absolute path of the process and the modification time of the process executable file according to the creation information. Here, the absolute path of the process and the latest modification time of the process executable file can be calculated according to the ID of the process.

[0143] Step S23, using the absolute path and modification time as matching information, matching cache items from a preset process feature library.

[0144] The matching process here may be to determine, based on the absolute path and the modification time, whether a cache item corresponding to the absolute path and the modification time is stored in the preset process feature library.

[0145] Step S24: when a cache item can be matched from the preset process feature library, the matched cache item is determined as the process feature information.

[0146] Here, the process characteristics in the cache item can be used as the process characteristic information of the process, wherein the process characteristics in the cache item include but are not limited to at least one of the following: the version number of the process, the description information of the process executable file, the size of the process executable file, the version information, the MD5 of the process executable file and the signature information, etc.

[0147] Step S25: When no cache item is matched from the preset process feature library, feature information of the process is collected in parallel.

[0148] Step S26: Cache the collected feature information as process feature information in a preset process feature library.

[0149] Step S27, after collecting the feature information of the process, the feature information is asynchronously sent to the server, so that the server pushes the feature information to the security detection service, so as to realize the security identification of the process through the security detection service.

[0150] Here, the security detection service may be services such as Anzhi and TAV.

[0151] Step S28: When the security identification result indicates that the process corresponding to the feature information is a malicious process, the client stores the malicious process in a preset risk process library.

[0152] It should be noted that the preset process feature library and the preset risk process library are databases stored in encrypted form locally on the terminal. The encryption key of the database consists of the local hardware code, hard disk serial number, and additional salted data, to ensure that the keys of each device are different, thereby enhancing security.

[0153] Below, an exemplary application of the embodiment of the present application in an actual application scenario will be described. The embodiment of the present application provides a network access method, which is a solution for achieving high-availability network access by introducing virtual access credentials, which solves the problem that the terminal user cannot access the business site in the scenario where the network request credential acquisition fails, while taking into account security. In the context of the iOA product as a zero-trust network access capability, the business processing client hijacks the access traffic and applies for a ticket to the IOA client. In a normal scenario, the iOA client and the server (i.e., the iOA server) in the iOA system jointly perform authentication on the network access request. In a weak network environment, unstable service on the server side, a failure occurs, or an abnormality occurs in the iOA client, due to the failure to apply for a ticket (i.e., a network request credential) from the server side, the terminal user will be interrupted in the process of using the application software to access the business site. After the ticket cannot be applied for from the server side, or the business processing client cannot obtain the authentication result from the iOA client, a virtual access credential can be introduced on the business processing client side to solve the authentication problem of network access. In this way, highly available network access is achieved, while taking into account security management and control, the stability and availability of the system are improved.

[0154] The terminal machine installs the business processing client and iOA client, and the server deploys the iOA background service and access gateway. In normal scenarios, when the business processing client hijacks the traffic of the application access site, the business processing client initiates an authentication request to the iOA client through local communication, that is, requests the iOA client to perform security identification on the network behavior of the current process accessing the current site, and judges whether the request behavior complies with the zero-trust network access policy and whether the process accessing the site is a malicious process. When the iOA client receives the authentication request from the business processing client, it collects the process feature information that initiates network access, brings the destination site information, current device information, and login user information, and initiates a ticket application to the iOA server. After the iOA server successfully responds to the ticket, the iOA client sends the ticket to the business processing client through process communication, and the business processing client initiates verification with the access gateway. The access gateway initiates a ticket check to the iOA server to verify the validity of the ticket sent by the business processing client. After the verification is passed, the business processing client will forward the traffic of the network access request to the access gateway, and the access gateway will actually proxy the application's site access. In this case, the network request credential is completed by the iOA client and the server. When iOA performs authentication for network access, it will automatically create a local encryption process feature library and risk process library for the terminal application, which will serve as an important basis for subsequent network request credential generation and verification.

[0155] Each time the client successfully accesses the network, it will asynchronously report the network access behavior to the server, which will automatically identify abnormal access behavior. Once abnormal access behavior is identified, it will be pushed to the terminal, and the terminal will generate and update the local risk application library.

[0156] In a weak network environment, when the ticket service on the server is unstable or fails, the iOA client fails to apply for a ticket from the iOA server through the network, or when the iOA client is abnormal and cannot respond to the ticket application of the business processing client in time or the response time exceeds the set threshold, the business processing client automatically generates a virtual credential for the current network access unit (a certain application process accesses a certain site) based on device information, login user information, process information, destination site and other information, which is used as a credential for the network access request. The business processing client brings the virtual access credential to the access gateway, and the access gateway sends the virtual access credential to the iOA server for ticket verification. The iOA server recognizes the virtual access credential issued by the business processing client and verifies whether the credential is valid according to a reasonable virtual access credential verification strategy. This solves the problem of processing network access authentication in the scenario where the network access ticket application fails. On the basis of taking security into consideration, the introduction of virtual access credentials allows end users to obtain a continuous, stable and high-quality network access experience.

[0157] The network access method of the embodiment of the present application solves the network usage problem of terminal users in scenarios such as weak network, abnormality of iOA client, inability to respond to the request of business processing client in time, or inability to respond to the client's ticket application request in time due to network reasons and abnormality of iOA server-side ticket service. In a general environment, the terminal and the server jointly authenticate the network request, and in combination with the zero-trust access control strategy, the authentication is performed for the device credibility, the destination address of the access, the process characteristics and the permission of the application to access the site. Only after the authentication is successful can the internal site set by the enterprise be accessed. When the terminal fails to apply for a ticket due to network reasons or a failure of the server-side ticket service, or when the iOA client is abnormal and cannot respond to the request of the business processing client in time, the business processing client can create a virtual access credential and send it to the access gateway, and the access gateway initiates a ticket verification to the iOA server. The server implements a safe and efficient ticket verification logic through the strategy of virtual access credential verification. When some services fail or the network jitters, it can ensure the normal progress of network access and achieve high-availability network access.

[0158] On the product side, the network access method of the embodiment of the present application can be applied to the iOA system. The iOA system can ensure an efficient and stable remote collaborative office experience and promote the application of zero-trust technology in the digital industry.

[0159] like Figure 7 As shown in FIG. 701 , the configuration interface diagram of the iOA system provided in the embodiment of the present application is shown. The administrator can configure information on the configuration interface 701 of the iOA system to implement policy management and form a network access control policy. In the process of configuring the network access control policy, Figure 7 As shown, network-wide account configuration 702, trusted application configuration 703 and business system configuration 704 may be performed to configure trusted users, trusted applications and trusted business systems.

[0160] The combined policy control based on person (i.e. user identity) - application - target business system in the embodiment of the present application implements traffic filtering, supports wildcard domain names, IP segments, and multiple ports, and can be inherited and expanded based on the user organizational structure. Among them, the business system configuration, i.e. the business site configuration, such as Figure 8 As shown, in the business system configuration interface 801, it includes the business system, category (domain name or IP), domain name (supports wildcards, for example, "*" means all, "*.baidu.com" means that all pages under the second-level domain name "baidu.com" can be accessed), port (you can specify a partial port list or all ports), a list of gateways that can access the office system, etc.

[0161] Trusted application configuration such as Fig. 9 As shown, in the trusted application configuration interface 901, the process name, application name, operating system, manufacturer, signature, inspection result, version, process MD5 and sha256, etc. may be included.

[0162] In the embodiment of the present application, when zero-trust office is enabled, the terminal user can log in to iOA to implement the zero-trust office function, such as Fig.10 The login interface shown is where the user can log in.

[0163] After logging in, users can see the protection policies and trusted software details configured by the administrator, such as Fig.11 As shown, the current interface displays protection policies and trusted software details 1101. According to the user-level policy issued by the administrator, the terminal user can access the business system configured by the specified trusted application access administrator, such as Fig.12 shown.

[0164] In the embodiment of the present application, iOA acts as a zero-trust network security service provider, and provides a unified entrance for the access subject to access the object's resources through the network request through the zero-trust agent and the access gateway. The iOA system provides authentication operations for the unified entrance. Only the network request that passes the authentication can be forwarded by the zero-trust agent to the access gateway, and the access to the actual business system is proxied by the access gateway. Fig.13 As shown, it is a schematic diagram of the iOA provided by an embodiment of the present application providing authentication operations for a unified entrance. The zero-trust network security service provider 1301 (i.e., the zero-trust agent) provides authentication operations for the unified entrance 1302, and the access subject 1303 can access the access object 1304 through the unified entrance 1302.

[0165] During the implementation process, the core modules mainly include business processing client, iOA client, iOA server and access gateway.

[0166] iOA client: It is a security agent installed on employees' work devices. It is responsible for verifying the user's trusted identity on the device, verifying whether the device is trustworthy, and verifying whether the application is trustworthy; and submitting unknown processes to the server for inspection.

[0167] Business processing client: that is, the access agent, which can hijack device traffic through the TUN / TAP virtual network card, and is responsible for forwarding the request to the access gateway after authentication by the iOA client. If the authentication fails, it will connect directly or terminate the connection.

[0168] Access Gateway: Deployed at the entrance of enterprise applications and data resources, responsible for the authentication, authorization, and forwarding of each session request to access enterprise resources.

[0169] iOA server: Through the policy control engine, the business traffic is securely scheduled and authorized according to the granularity of people-device-software-application. Among them, the identity authentication module verifies the user's identity, the device trust module verifies the device hardware information and device security status, and the application detection module detects whether the application process is safe, such as whether there are loopholes, viruses, Trojans, etc. The iOA server regularly sends files to the threat intelligence cloud check service for inspection, and notifies the client to perform asynchronous blocking operations when malicious processes are identified.

[0170] The overall process of the network access method in the embodiment of the present application is as follows: Fig.14 As shown, the following steps are included:

[0171] Step S1: Any application sends a network access request to a business processing client through an application client.

[0172] The network access request may be a process ID-Uniform Resource Locator (PID-URL) request based on a Uniform Resource Locator (URL) system.

[0173] Step S2: The business processing client sends a ticket application to the iOA client to request a ticket.

[0174] Step S3: the iOA client obtains process feature information of the application.

[0175] Step S4: the iOA client and the iOA server exchange the bills.

[0176] Step S5: the iOA client sends a process inspection request to the iOA server, requesting risk detection of the process corresponding to the network access request to implement process inspection.

[0177] Step S6: the iOA client sends a ticket response result to the business processing client.

[0178] Step S7: The business processing client sends a ticket and a network access request to the access gateway.

[0179] Step S8: The access gateway requests the iOA server to verify the ticket and form a ticket verification result.

[0180] Step S9: The iOA server returns the ticket verification result to the access gateway.

[0181] Step S10: The access gateway forwards the network access request to the target business server based on the ticket verification result.

[0182] Step S11: The target service server (which may be any one of service servers A, B or C) returns a response result of the network access request to the access gateway.

[0183] Step S12: The access gateway returns the response result to the business processing client.

[0184] Step S13: The business processing client returns the response result to the application client.

[0185] In the embodiment of the present application, when the terminal user successfully logs in, the server will return a login ticket (i.e., a big ticket) and store it in the client. Fig.15 FIG. 1 is a schematic diagram of a user login process provided in an embodiment of the present application, comprising the following steps:

[0186] Step S151, the terminal submits the device ID and machine information to the server to request login.

[0187] Step S152: the server verifies the information submitted by the terminal.

[0188] Step S153: The server returns the ticket and user information based on the verification result.

[0189] In the embodiment of the present application, the client pulls the zero-trust network access control policy (i.e., network access control policy) corresponding to the currently logged-in user ID from the server. If the zero-trust network access control policy of the server changes, it will be synchronized to the terminal in a timely manner. Fig.16 FIG. 1 is a schematic diagram of a policy synchronization process provided by an embodiment of the present application, comprising the following steps:

[0190] Step S161: The terminal submits user information to the server to request to obtain a zero-trust network access control policy.

[0191] Step S162: The server issues a zero-trust network access control policy.

[0192] Step S163: The server returns the zero-trust network access control policy to the terminal.

[0193] In an embodiment of the present application, the access subject initiates a network access request for the access object through an application, the client hijacks the network request through a business processing client, and the business processing client initiates an authentication request to the iOA client (that is, the agent applies to the iOA client for the credentials of the current network access request), and the request parameters include the source IP or domain name, source port, destination IP or domain name, destination port, and the process ID (PID, process ID) corresponding to the application.

[0194] After the iOA client receives the authentication request sent by the proxy client, it collects the process PE file information (for example, the full path of the process file, MD5, signature information, process modification time, etc.), operating system information, URL access information, device information, iOA user login information agent, login ticket and other related information of the requester who initiated the network access request, together with the source IP or domain name, source port, destination IP or domain name, destination port of the network access request passed by the business processing client, and applies for a ticket from the iOA server. If the application is successful, the ticket, the maximum number of times the ticket is used, and the ticket validity period are sent as a response to the business processing client. The business processing client first initiates an Https request authorization authentication to the access gateway, in which the network request credential (i.e., ticket) passed by the iOA client is brought in the header field of the authorization information. After receiving the verification request from the business processing client, the access gateway parses the ticket in the header field and verifies the ticket to the iOA server. If the verification is successful, the access gateway successfully establishes a connection with the business processing client, and then the business processing client sends the original network access request to the access gateway, which is forwarded by the access gateway to the corresponding target business server, and the target business server acts as an agent for the actual application network access. If the access gateway fails to verify the ticket, the connection between the business processing client and the access gateway is interrupted. For traffic from other applications outside the zero-trust network access control policy accessing specific sites, a direct connection is achieved by initiating a network access request directly to the target business server through the application client.

[0195] In some embodiments, while synchronously applying for a ticket, the iOA client initiates an asynchronous inspection request to the server based on the feature information of the process that actually performs network access. The asynchronous inspection request sent includes the most recent modification time of the process file, MD5, SHA256, copyright information, process signature information (including digest algorithm, root certificate information, intermediate certificate information, signature certificate information, signer name, signature status), etc. If the server detects that the process is a malicious process, it pushes it to the client and disconnects the network access established by the malicious process.

[0196] Fig.17 is a schematic diagram of a process in which a client and a server jointly authenticate a single network access request provided by an embodiment of the present application, such as Fig.17 As shown, the authentication process includes the following steps:

[0197] Step S1701: The terminal application sends a network access request.

[0198] Step S1702: The terminal collects process feature information corresponding to the network access request.

[0199] Step S1703: The terminal performs local black process filtering according to the process feature information.

[0200] Step S1704: the terminal determines whether the process feature information passes the filter.

[0201] If the judgment result is yes, execute step S1705, if the judgment result is no, disconnect the network.

[0202] Step S1705: The business processing client applies for a ticket from the server.

[0203] Step S1706: The server determines whether the software signature, MD5 and local signature verification results comply with the specified rules based on the process feature information.

[0204] If the judgment result is yes, execute step S1709, if the judgment result is no, execute step S1707.

[0205] Step S1707: The server determines that the terminal application is a high-risk application.

[0206] Step S1708: The server refuses to respond to the ticket application.

[0207] Step S1709: The server determines whether the terminal application is a trusted application or an unknown application.

[0208] Step S1710: If the server determines that the device is trustworthy, it performs an authority determination.

[0209] Step S1711, after authority determination, returns the ticket.

[0210] In the embodiment of the present application, when the application is to initiate network access, the iOA client synchronously collects process feature information, and performs a filter according to the local black process library. If the process corresponding to the network access request is identified as a malicious process according to the local black process library, the access is interrupted. If not, the iOA client synchronously collects process information, including local verification results, signature information of process executable files, process feature information, login credentials, URL, device, login credentials (i.e., big tickets), and initiates a ticket application to the iOA server (i.e., server). The iOA server detects whether the application is a high-risk application. If it is a high-risk application, it refuses to respond to the ticket. If it is not a high-risk application, it determines that the application is a trusted application or an unknown application, so it continues to judge whether the current device is a trusted device. When a trusted device is detected and the application has the authority to access the current URL, the iOA server responds to the ticket to the iOA client normally. The iOA client sends the ticket responded by the iOA server to the business processing client through local process communication.

[0211] When the iOA client applies for a ticket from the iOA server, in order to fully verify whether the process is a malicious process, the iOA client will initiate an asynchronous process inspection request to the iOA server. The request parameters include the destination URL to be accessed, process MD5, hash value (HASH), process path, certificate chain details, etc. Among them, the certificate chain details include: digest algorithm, root certificate name, root certificate serial number, root certificate expiration time, intermediate certificate name, intermediate certificate serial number, intermediate certificate expiration time, signature certificate name, signature certificate serial number, signature certificate expiration time, signature status, signer name, timestamp, signature verification error information, etc. After receiving this information, the iOA server regularly initiates file inspection requests to the security detection service (for example, Anzhi or tav, etc.). If the security detection service detects that the file is a malicious process file, the iOA server will notify the iOA client to interrupt the existing access link.

[0212] Fig.18 : is a timing diagram of the client and the server jointly performing authentication on the network access request provided by the embodiment of the present application, such as Fig.18 As shown in the figure, in normal scenarios, the client and the server jointly authenticate the network access request, including the proxy access stage and the process submission and asynchronous blocking stage:

[0213] During the proxy access phase, it includes:

[0214] Step S1801: The business processing client sends a configuration information request to the iOA client to request configuration information.

[0215] Step S1802: the iOA client returns relevant configuration information to the business processing client.

[0216] Step S1803: The business processing client applies for a receipt from the iOA client.

[0217] Step S1804, the iOA client submits the invoice to the iOA server and requests a business invoice (ie, a network request voucher).

[0218] Step S1805: the iOA server returns a receipt to the iOA client. It should be noted that, in order to reduce network latency, multiple receipts may be returned at one time.

[0219] Step S1806: The iOA client returns a receipt to the business processing client.

[0220] Step S1807: The business processing client sends a business request (ie, a network access request) and a receipt to the access gateway.

[0221] Step S1808: The access gateway requests the iOA server to perform ticket verification on the receipt.

[0222] Step S1809: The iOA server returns the verification result to the access gateway.

[0223] Step S1810: The access gateway forwards the service request to the target service server according to the verification result.

[0224] Step S1811, the target service server vectors the service request and returns a response result to the access gateway.

[0225] Step S1812: The access gateway returns the response result to the business processing client.

[0226] During the process inspection and asynchronous blocking phase, it includes:

[0227] Step S1813: The business processing client sends the process PID and port to the iOA client.

[0228] Step S1814: the iOA client collects process information.

[0229] Step S1815: the iOA client sends the MD5, signature information and certificate chain in the process information to the iOA server.

[0230] Step S1816: the iOA server performs process determination.

[0231] Step S1817: Based on the determination result, the process information of the process that needs to block the connection is returned to the iOA client.

[0232] Step S1818: The iOA client sends the link information that needs to be blocked to the business processing client.

[0233] Step S1819: The business processing client blocks the connection.

[0234] The following describes the construction and adjustment process of the locally encrypted process feature library (ie, the preset process feature library) and the risk process library (ie, the preset risk process library, the black process library) in the embodiment of the present application.

[0235] When using the iOA system for zero-trust network access, the terminal generates and adjusts the process signature library locally as follows: Fig.19As shown, the system detects the process creation process through PsSetCreateProcessNotifyRoutine at the ring0 layer. When a new process is created, the ring3 layer obtains the process creation information, such as the process ID and process name. Then, the iOA client will calculate the absolute path (procpath) of the process and the last modification time (updatetime) of the process executable file based on the process PID. Then, the iOA client will use the absolute path and last modification time of the process as the key to find out whether the cache item exists in the local encrypted process feature library. If the search is successful, the process features in the cache item are directly used as the features of the process, including the version number (filever) of the process executable file, the description information (filedesc) of the process executable file, the file size (filesize) of the process executable file, the version information (copyright), the MD5 of the process executable file, and the signature information, etc. If the search fails, the feature information of the process is actually collected according to the absolute path (procpath) of the process, and the version number (filever) of the process, the description information (filedesc) of the process executable file, the size (filesize) and version information (copyright) of the process executable file are obtained. At the same time, the MD5 of the process, the signer name (sign_issuer) in the digital signature of the process executable file, and the local signature verification result (sign_check_rst) are calculated in parallel according to the absolute path (procpath) of the process. After the process features are actually obtained, these actually collected process features will be added to the process feature library. Because the calculation of the MD5 and signature information of the executable file corresponding to the process is time-consuming, the collection time can be shortened by collecting process features (for example, MD5, signature information) in parallel.

[0236] When the executable file path corresponding to the process has not changed, but the last modification time has changed, it means that the process has been updated. The iOA client will actually calculate the feature information of the process file and adjust the feature value of the process feature library accordingly.

[0237] In summary, the construction and adjustment logic of process feature library 1901 is: introduce process feature cache, try to hit the cache first, and avoid frequent feature collection. If the cache is successfully hit, the cache item is used as the feature set of the current process; if the cache is not successfully hit, the collection time is shortened by collecting process MD5 and process signature information in parallel, and after the collection is completed, a new cache item is added or the value of the existing cache item is refreshed.

[0238] By default, all processes are considered unknown applications and are not included. Fig.19The risk process library 1902 in the iOA server. When a process is detected to be created, the iOA client collects the feature information of the process through the above steps, and then asynchronously sends the feature information of the process to the iOA server. The iOA server pushes the feature information of the process to any security detection service to detect the security of the process information through the security detection service. If it is identified as a malicious process, the security detection service responds to the iOA server, and the iOA server pushes the list of malicious processes to the client. After receiving the list of malicious processes, the iOA client stores the feature information of the malicious process in the risk process library 1902.

[0239] The process signature library 1901 and the risk process library 1902 are encrypted and stored locally on the terminal. The encryption key is composed of the local hardware code, the hard disk serial number, and additional salt data, so as to ensure that the key of each device is different and enhance security.

[0240] The following describes the generation and verification process of the virtual access credential (ie, virtual ticket).

[0241] When the business processing client hijacks the application traffic, it sends a ticket request to the iOA client. The iOA client first checks whether the destination site accessed by the application complies with the zero-trust network access control policy. If not, the iOA client responds to the business processing client with a direct connection result. After receiving the direct connection result, the business processing client directly forwards the traffic to the target business site that the application needs to connect to. If the target site accessed by the application complies with the zero-trust access control policy, the business processing client expects the iOA client to respond with a ticket.

[0242] After the iOA client detects that the application access to the target site complies with the zero-trust access control policy, it first collects the PID of the process (the ticket request sent by the business processing client includes the process PID, process name, source IP, source port, target IP and target port), obtains the absolute path of the executable file corresponding to the process, and collects the latest modification time of the executable file corresponding to the process. After the collection is completed, try to find out whether there is a corresponding cache item in the locally encrypted process feature library. If it exists, the matching cache item is used as the process feature. If it does not exist, the process features are collected in parallel. Then, with the feature information of the process, the target address and port to be accessed, the device ID and the user login information, a ticket application is initiated to the server. If the ticket application fails due to network problems, or the server does not respond to the ticket within the set time due to a failure in the server ticket service, the iOA client responds with an empty ticket and the corresponding error code to the business processing client, indicating that the ticket application failed due to network problems or because the server did not respond to the ticket in time. After the business processing client receives the empty ticket and the corresponding error code responded by the iOA client, it will perform the virtual ticket generation and verification process according to the set plan. Fig. 20 FIG. 1 is a diagram showing a process for generating and verifying a virtual access credential provided by an embodiment of the present application, wherein the proxy access phase includes:

[0243] Step S2001: The business processing client sends a configuration information request to the iOA client to request configuration information.

[0244] Step S2002: the iOA client returns relevant configuration information to the business processing client.

[0245] Step S2003: The business processing client applies for a receipt from the iOA client.

[0246] Step S2004, the iOA client submits the invoice to the iOA server and requests a business invoice (ie, a network request voucher).

[0247] Step S2005: the iOA server returns a receipt to the iOA client. It should be noted that, in order to reduce network delay, multiple receipts may be returned at one time.

[0248] Step S2006: The iOA client returns an error code and an empty ticket to the business processing client.

[0249] Step S2007: The business processing client generates a virtual ticket.

[0250] Step S2008: The business processing client sends the virtual ticket to the access gateway.

[0251] Step S2009: the access gateway parses the virtual ticket.

[0252] Step S2010: The access gateway sends the virtual ticket to the iOA server.

[0253] Step S2011: the iOA server verifies the virtual ticket.

[0254] Step S2012: the iOA server returns the verification result to the access gateway.

[0255] Step S2013: The access gateway forwards the service request to the target service server.

[0256] Step S2014: the target service server responds to the service request and generates a response result, and sends the response result to the access gateway.

[0257] Step S2015: The access gateway returns the response result to the business processing client.

[0258] In the embodiment of the present application, the virtual ticket is composed of a virtual ticket identification header (e.g., "DET_"), a version number, a current timestamp, a client error code (e.g., indicating that the server did not respond to the ticket within the specified time, the network is not connected, etc.), a device unique identifier, an iOA client version number, a process MD5, and the destination site and port visited. Fig.21 As shown, it is a structural diagram of a virtual ticket provided by an embodiment of the present application. The virtual ticket consists of a ticket header 2101 and a ticket body 2102. The ticket body 2102 is in an encrypted state. The ticket header 2101 consists of a virtual ticket fixed identifier (for example, "DET_"), a version number (Version shown in the figure), a ticket ID (UID), a current timestamp (Timestamp) and a ticket body length (BodyLen). The encrypted ticket body, namely CipherBody, consists of a client error code (ErrCode), a device unique identifier (DeviceID), an iOA client version number (iOAClientVersion), a process MD5 (ProcessMD5), a destination site and port (DestAddr) visited. The secret key for encrypting the ticket body is the login ticket (after the terminal user logs in to iOA, the client obtains the login ticket from the server and encrypts and stores it locally. The login ticket is valid within the time period set by the server, and the login ticket becomes invalid beyond the time period). It is stored on both the server and the iOA client. Therefore, the encrypted ticket body of the virtual ticket can be decrypted on the server.

[0259] In some embodiments, based on the policies and security levels established by the enterprise, the following solutions are provided for using virtual tickets on the business processing client side: Solution 1: Identify the cause of poor network quality or server-side ticket service failure based on the error code. If the server fails to successfully respond to the ticket within the set time, network access is denied, network access is interrupted, and operational data is recorded.

[0260] Solution 2: Based on the error code, the network quality is poor or the server ticket service failure is identified. The server fails to successfully respond to the ticket within the set time. The business processing client immediately generates a virtual ticket and responds to the business processing client.

[0261] Solution 3: Due to network reasons or failure of the server-side ticket service, the server fails to successfully respond to the ticket within the set time. The business processing client first collects the absolute path and the last modification time of the executable file corresponding to the process based on the process PID that initiated the network access, and then searches for features from the locally encrypted process feature library based on these two values. If found, the successfully cached item is used as the process feature item. If not found, the process features are collected in parallel. According to the process features, the local risk process library is searched to see if the application is a malicious process. If it is not a malicious process, the corresponding application is determined based on the terminal's zero-trust access policy to determine whether it has network access rights to the corresponding site. If there is corresponding access rights, a virtual ticket is generated immediately. If it is a malicious process or the application does not have corresponding site access rights, the iOA client directly denies network access, network access is interrupted, and operational data is recorded.

[0262] Among them, Solution 1 is more stringent, but it has high requirements for the stability of the network environment and the ticket service on the server side in the usage environment. Solution 2 ignores the process check and directly generates a virtual ticket. It is equivalent to a downgrade solution. In order to ensure the stability of the terminal user's network access, the business processing client temporarily creates the ticket instead of issuing the ticket by the server, and security is temporarily ignored. It can be used for site access with low security requirements, but it is not recommended for enterprises with high security requirements. Solution 3 takes security into consideration. The business processing client generates a virtual ticket based on checking the security of the process and the process's access to the site. At the same time, it avoids the disadvantage of Solution 1 that the terminal user is disconnected from the Internet when the network quality is poor or there is a problem with the ticket service on the server side. Therefore, this solution is recommended. Among them, the process of Solution 3 is as follows Fig. 22 As shown, including:

[0263] Step S221: The client fails to apply for a ticket from the server. Step S222: Determine the risky application based on the process feature information. Step S223: Determine the access rights based on the zero-trust access policy. Step S224: Determine whether the application is a risky application. Step S225: Generate a virtual ticket based on the determination result.

[0264] After the business processing client generates a virtual ticket, it sends the ticket to the access gateway. The access gateway sends the ticket to the iOA server for verification. After the server receives the virtual ticket sent by the access gateway, it can verify the ticket according to the strategy formulated by the enterprise. There are several strategies.

[0265] Strategy 1: The server identifies virtual tickets based on the ticket header and releases them without checking the number of times they have been used or the validity period.

[0266] Strategy 2: After the server receives the ticket sent by the gateway, it identifies the virtual ticket according to the Header, parses the device ID in the encrypted body, and first obtains the login ticket according to the device ID. The server uses the login ticket as the key information and the number of times the virtual ticket corresponding to the login ticket is used as the value. It maintains the number of times the virtual ticket is used in the login ticket. First, it checks whether the number of times the virtual ticket is used exceeds the set value. If it exceeds, the verification fails. If it does not exceed the set value, the verification passes. If both the number of times and the period of use are recorded, the access is rejected;

[0267] Strategy 3: The server identifies the virtual ticket, parses the encrypted body of the virtual ticket based on the login ticket, obtains the process MD5, and checks whether the process is a risky application from the server's process cache and security detection service. If not, the verification passes; otherwise, the verification fails.

[0268] Among them, Strategy 1 has a higher security risk. Strategy 2 decides whether to access the virtual ticket based on the number of times the login ticket is used. The verification result of the virtual ticket can be determined by combining the detection of the access user's behavior. If the login user's behavior shows abnormal access behavior after continuous detection, the number of times and the validity period of the virtual ticket corresponding to the user can be limited. Strategy 3 parses the encrypted body of the ticket, obtains the process MD5, and checks whether the process is a risky application from the process cache and security detection service on the server side. It checks whether the process is a malicious process, so the safety factor is relatively high. Strategy 3 is recommended. The overall process is as follows: Fig.23 As shown, including:

[0269] Step S231, the server receives a ticket verification request. Step S232, parse the ticket and identify the virtual ticket. Step S233, obtain the process MD5. Step S234, determine whether the application is a risky application. Step S235, return the ticket verification result according to the determination result.

[0270] In a general environment, the terminal and the server jointly authenticate the network request. Only after successful authentication can the internal site set by the enterprise be accessed. When the terminal fails to apply for a ticket due to network reasons or a failure in the ticket service of the server, or when an abnormality occurs in the iOA client and it cannot respond to the request of the business processing client in time, the business processing client side can create a virtual credential. The server side also provides verification for the virtual credential. On the basis of taking security into account, the service adjustment method is used to obtain a sustainable, stable and high-quality network access experience for the terminal user, avoiding network access congestion caused by time extension, and network access problems caused by the iOA client and the iOA background ticket application in a weak network environment or the iOA client's failure to respond to the business processing client in time.

[0271] The network access method provided in the embodiment of the present application realizes a high-availability network access solution by introducing a virtual ticket on the business processing client side, thereby solving the problem that the terminal user network cannot access the business site in the scenario where the network access credential acquisition fails, while taking security into consideration. After the business processing client hijacks the traffic, it applies for a ticket from the IOA client, and the iOA client and the server jointly perform authentication on the network request. While performing authentication for network access, iOA will automatically create a local encrypted process feature library and a risk process library for the terminal application, which will serve as an important basis for subsequent virtual ticket generation and verification. After a problem occurs with the asynchronous inspection service or ticket service on the server side, access to risky applications that have appeared can be identified and network access can be prohibited.

[0272] In a weak network environment, unstable or faulty server services, or abnormal iOA clients, the application access to the business site is interrupted because of the failure to apply for tickets from the server through the network. By introducing virtual credentials on the business processing client side, the problem of iOA clients not being able to respond to agent communication and failing to apply for tickets from the server can be solved. This highly available network access improves the stability and availability of the system while taking into account security control.

[0273] The following is a description of an exemplary structure of the network access device 354 provided in the embodiment of the present application implemented as a software module. In some embodiments, Figure 3 As shown, the software module stored in the network access device 354 of the memory 350 may be a network access device in a network access device, and the device includes:

[0274] An acquisition module is used to acquire process characteristic information corresponding to a network access request when a network access request sent by any application is intercepted; a first generation module is used to generate a ticket application according to the process characteristic information and send the ticket application to a server; a second generation module is used to generate a virtual access credential according to the access information corresponding to the network access request when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period; a sending module is used to send the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential and implements a network access response to the network access request.

[0275] In some embodiments, the acquisition module is also used for: when the business processing client intercepts a network access request sent by any application, sending an authentication request to the management client; the management client responds to the authentication request and obtains the process characteristic information corresponding to the network access request; the first generation module is also used for: the management client generates the ticket application according to the process characteristic information, and sends the ticket application to the server.

[0276] In some embodiments, the sending module is also used to: send the network access request and the virtual access credential to an access gateway, and the access gateway sends the network access request and the virtual access credential to a server, so that the server authenticates the network access request based on the virtual access credential.

[0277] In some embodiments, the device also includes: a policy acquisition module, used to obtain a pre-configured network access control policy or a currently updated network access control policy, wherein the network access control policy includes at least one of the following: a trusted user, a trusted application, and a trusted business system; a process characteristic information acquisition module, used to obtain the process characteristic information corresponding to the network access request when the network access request complies with the network access control policy; and a control module, used to control the application client of the application to directly connect to the target business server to respond to the network access request when the network access request does not comply with the network access control policy.

[0278] In some embodiments, the device also includes: a second sending module, which is used to send the network request credential returned by the server to the access gateway when the network request credential is successfully received within the preset time period, so that the access gateway sends a ticket verification request to the server, and when the server responds to the ticket verification request and the network request credential is verified, a connection channel is established with the access gateway; the network access request is sent to the access gateway through the connection channel, so that the access gateway forwards the network access request to the target business server; when the server responds to the ticket verification request and the network request credential is verified but fails, the connection with the access gateway is controlled to be interrupted.

[0279] In some embodiments, the device also includes: a process identification module, which is used to identify the process corresponding to the network access request based on the process feature information and a preset risk process library while sending a ticket application to the server; and a disconnection module, which is used to disconnect the network access connection established with the malicious process when the identification result indicates that the process corresponding to the network access request is a malicious process.

[0280] In some embodiments, the device also includes: an asynchronous inspection request generation module, which is used to generate an asynchronous inspection request based on the process characteristic information while sending a ticket application to the server, and the asynchronous inspection request is used to request the server to detect whether the application is a high-risk application; a receiving module, which is used to receive the detection result returned by the server in response to the asynchronous inspection request; and a normal response module, which is used to respond normally to the ticket application when the detection result indicates that the application is not a high-risk application.

[0281] In some embodiments, the acquisition module is also used to: when the process corresponding to the network access request is a newly created process, obtain the creation information of the process; determine the absolute path of the process and the modification time of the process executable file based on the creation information; use the absolute path and the modification time as matching information to match cache items from a preset process feature library; when a cache item can be matched from the preset process feature library, determine the matched cache item as the process feature information.

[0282] In some embodiments, the device also includes: a parallel collection module, which is used to collect feature information of the process in parallel when no cache item is matched from the preset process feature library; and a cache module, which is used to cache the collected feature information as the process feature information in the preset process feature library.

[0283] In some embodiments, the device also includes: an asynchronous sending module, which is used to asynchronously send the characteristic information to the server after collecting the characteristic information of the process, so that the server pushes the characteristic information to the security detection service to achieve security identification of the process through the security detection service; a storage module, which is used to store the malicious process in a preset risk process library when the security identification result indicates that the process corresponding to the characteristic information is a malicious process.

[0284] In some embodiments, the virtual access credential includes at least a ticket header and a ticket body; the ticket body is in an encrypted state; the sending module is also used to: send the network access request and the virtual access credential to the server, so that the server identifies the virtual access credential based on the ticket header, and parses the ticket body in the encrypted state, and verifies the virtual access credential through the device identification or MD5 value in the parsing result to achieve authentication of the network access request.

[0285] It should be noted that the description of the device of the embodiment of the present application is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment, so it is not repeated. For technical details not disclosed in the embodiment of the device, please refer to the description of the method embodiment of the present application for understanding.

[0286] The embodiment of the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method described above in the embodiment of the present application.

[0287] The embodiment of the present application provides a storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the method provided by the embodiment of the present application, for example Figure 4 In some embodiments, the storage medium may be a computer-readable storage medium, for example, a ferroelectric memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, a charged erasable programmable read-only memory, a flash memory, a magnetic surface memory, an optical disk, or an optical disk read-only memory, etc.; or it may be various devices including one or any combination of the above memories.

[0288] In some embodiments, 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 as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0289] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file storing other programs or data, such as one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions). As an example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network.

[0290] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions 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 network access method, characterized in that: Applied to a terminal, the method comprises: When a network access request sent by any application is intercepted, process feature information corresponding to the network access request is obtained; Generate a ticket application according to the process characteristic information, and send the ticket application to a server; When the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, generating a virtual access credential according to the access information corresponding to the network access request; The network access request and the virtual access credential are sent to the server, so that the server authenticates the network access request according to the virtual access credential and implements a network access response to the network access request.

2. The method according to claim 1, characterized in that: The terminal includes a business processing client and a management client. When a network access request sent by any application is intercepted, the process feature information corresponding to the network access request is obtained, including: When the business processing client intercepts a network access request sent by any application, the business processing client sends an authentication request to the management client; The management client obtains process characteristic information corresponding to the network access request in response to the authentication request; The step of generating a ticket application according to the process characteristic information and sending the ticket application to a server includes: The management client generates the ticket application according to the process characteristic information, and sends the ticket application to the server.

3. The method according to claim 2, characterized in that The sending the network access request and the virtual access credential to the server so that the server authenticates the network access request according to the virtual access credential includes: The business processing client sends the network access request and the virtual access credential to the access gateway, and the access gateway sends the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential.

4. The method according to claim 1, characterized in that The method further comprises: Acquire a pre-configured network access control policy or a currently updated network access control policy, wherein the network access control policy includes at least one of the following: a trusted user, a trusted application, and a trusted business system; When the network access request complies with the network access control policy, obtaining process feature information corresponding to the network access request; When the network access request does not comply with the network access control policy, the application client of the application is controlled to directly connect to the target service server to respond to the network access request.

5. The method according to claim 1, characterized in that The method further comprises: When the network request credential returned by the server is successfully received within the preset time period, the network request credential is sent to the access gateway so that the access gateway sends a ticket verification request to the server, and When the server responds to the ticket verification request and passes the network request credential verification, the terminal establishes a connection channel with the access gateway; The terminal sends the network access request to the access gateway through the connection channel, so that the access gateway forwards the network access request to the target service server; When the server responds to the ticket verification request and fails to verify the network request credential, the connection between the terminal and the access gateway is controlled to be interrupted.

6. The method according to claim 1, characterized in that The method further comprises: When the terminal sends a ticket application to the server, the process corresponding to the network access request is identified according to the process feature information through a preset risk process library; When the identification result indicates that the process corresponding to the network access request is a malicious process, the network access connection established with the malicious process is disconnected.

7. The method according to claim 6, characterized in that The method further comprises: When the terminal sends a ticket application to the server, an asynchronous inspection request is generated according to the process characteristic information, and the asynchronous inspection request is used to request the server to detect whether the application is a high-risk application; Receiving the test result returned by the server in response to the asynchronous test request; When the detection result indicates that the application is not a high-risk application, the server responds to the ticket application normally.

8. The method according to claim 1, characterized in that: The obtaining process characteristic information corresponding to the network access request includes: When the process corresponding to the network access request is a newly created process, obtaining creation information of the process; Determine the absolute path of the process and the modification time of the process executable file according to the creation information; Using the absolute path and the modification time as matching information, matching cache items from a preset process feature library; When a cache item can be matched from the preset process feature library, the matched cache item is determined as the process feature information.

9. The method according to claim 8, characterized in that The method further comprises: When no cache item is matched from the preset process feature library, collecting feature information of the process in parallel; The collected feature information is cached in the preset process feature library as the process feature information.

10. The method according to claim 9, characterized in that The method further comprises: After collecting the characteristic information of the process, asynchronously sending the characteristic information to the server, so that the server pushes the characteristic information to the security detection service, so as to realize security identification of the process through the security detection service; When the security identification result indicates that the process corresponding to the characteristic information is a malicious process, the malicious process is stored in a preset risk process library.

11. The method according to any one of claims 1 to 10, characterized in that: The virtual access credential at least includes a ticket header and a ticket body; the ticket body is in an encrypted state; The sending the network access request and the virtual access credential to the server so that the server authenticates the network access request according to the virtual access credential includes: The network access request and the virtual access credential are sent to the server, so that the server identifies the virtual access credential based on the ticket header, and parses the ticket body in the encrypted state, and verifies the virtual access credential through the device identification or MD5 value in the parsing result to authenticate the network access request.

12. A network access system, characterized in that: The system includes: a business processing client, a management client, a server and an access gateway; wherein, The business processing client is used to intercept a network access request sent by any application, and send an authentication request to the management client in response to the network access request; The management client is used to respond to the authentication request, obtain the process characteristic information corresponding to the network access request; and generate a ticket application according to the process characteristic information, and send the ticket application to the server; The server is configured to generate a network request credential in response to the ticket application; The business processing client is further used to generate a virtual access credential according to the access information corresponding to the network access request when the network request credential returned by the server is not successfully received within a preset time period; and send the network access request and the virtual access credential to the access gateway; The access gateway is used to send the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential and implements a network access response to the network access request.

13. A network access device, characterized in that: The device comprises: An acquisition module, used for acquiring process characteristic information corresponding to a network access request sent by any application when the network access request is intercepted; A first generating module, configured to generate a ticket application according to the process characteristic information, and send the ticket application to a server; A second generating module, when the network request credential returned by the server based on the ticket application is not successfully received within a preset time period, generates a virtual access credential according to the access information corresponding to the network access request; The sending module is used to send the network access request and the virtual access credential to the server, so that the server authenticates the network access request according to the virtual access credential to implement a network access response to the network access request.

14. A network access device, characterized in that: include: A memory for storing executable instructions; A processor, configured to implement the network access method according to any one of claims 1 to 11 when executing the executable instructions stored in the memory.

15. A computer-readable storage medium, characterized in that: Executable instructions are stored, which are used to cause a processor to execute the executable instructions to implement the network access method described in any one of claims 1 to 11.

Images