CN118802149A - Access processing method and device based on zero-trust network, electronic device, and medium - Google Patents

Abstract

The embodiments of the present application disclose access processing methods and devices, electronic devices, and media based on a zero-trust network. The method applied to a zero-trust terminal includes: obtaining login configuration information from a zero-trust service end, the login configuration information is generated after detecting an abnormality in the login service in the zero-trust network, and the login configuration information includes pseudo-login execution condition information; determining whether the zero-trust terminal has the conditions for pseudo-login based on the login configuration information; when the zero-trust terminal has the conditions for executing pseudo-login, generating a local access ticket, and sending the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing the verification of the local access ticket. The present application can ensure normal user network access in the event of abnormal login service, and can improve the availability of the zero-trust network architecture.

Description

Access processing method and device based on zero-trust network, electronic device, and medium

Technical Field

The present application relates to the field of network security technology, and specifically to an access processing method and device based on a zero-trust network, an electronic device, and a computer-readable storage medium.

Background Art

With the continuous rise of emerging technologies such as cloud computing, big data, and the Internet of Things, enterprise Internet architecture is changing from "bounded" to "borderless", and the traditional firewall-based security boundaries are gradually disintegrating. At the same time, zero-trust security has gradually entered people's field of vision and become a new concept and new architecture for solving network security problems in the new era. In a zero-trust network, every request for network resources must come from an authenticated and authorized user.

In the existing zero-trust network access architecture, when a user's network access is interrupted due to actual environmental reasons or problems with dependent services or components, the default login service between the zero-trust terminal and the zero-trust server is normal, and the default zero-trust gateway cluster is healthy. By generating virtual tickets on the zero-trust terminal side, automatically releasing the zero-trust server, and generating tickets by the security terminal, it is possible to securely send traffic to the zero-trust gateway in abnormal scenarios, and forward traffic to the business server normally through the zero-trust gateway to ensure the sustainable use of enterprise network access. However, in the scenario where the login service between the zero-trust terminal and the zero-trust server is abnormal, it will directly affect the user's network access, resulting in low availability of the zero-trust network access architecture.

Summary of the invention

To solve the above technical problems, the embodiments of the present application respectively provide an access processing method based on a zero-trust network, an access processing device based on a zero-trust network, an electronic device, a computer-readable storage medium, and a computer program product.

In the first aspect, an embodiment of the present application provides an access processing method based on a zero-trust network, which is applied to a zero-trust terminal, and the method includes: obtaining login configuration information from a zero-trust server, the login configuration information being generated after an abnormality is detected in the login service in the zero-trust network, and the login configuration information including pseudo-login execution condition information; determining whether the zero-trust terminal has the conditions for a pseudo-login based on the login configuration information; when the zero-trust terminal has the conditions for executing a pseudo-login, generating a local access ticket, and sending the access session traffic and the local access ticket to a zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to a business server after independently performing verification of the local access ticket.

In the second aspect, an embodiment of the present application provides an access processing device based on a zero-trust network, which is configured on a zero-trust terminal, and the device includes: an acquisition module, configured to obtain login configuration information from a zero-trust server, the login configuration information is generated after an abnormality is detected in the login service in the zero-trust network, and the login configuration information includes pseudo-login execution condition information; a determination module, configured to determine whether the zero-trust terminal has the conditions for executing a pseudo-login based on the login configuration information; a first processing module, configured to generate a local access ticket if the zero-trust terminal has the conditions for executing a pseudo-login, and send the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing verification of the local access ticket.

In the third aspect, an embodiment of the present application provides another access processing method based on a zero-trust network, which is applied to a zero-trust service end, and the method includes: receiving indication information sent by a zero-trust management end, the indication information being used to indicate that an abnormality has occurred in the login service in the zero-trust network; in response to the indication information, notifying the zero-trust gateway to enter an independent ticket verification state; after receiving the response information returned by the zero-trust gateway, sending login configuration information to the zero-trust terminal, the login configuration information including pseudo-login execution condition information, so that the zero-trust terminal sends the access session traffic and the local access ticket to the zero-trust gateway based on the login configuration information, and the zero-trust gateway forwards the access session traffic to the business server after independently performing the verification of the local access ticket.

In a fourth aspect, an embodiment of the present application provides another access processing device based on a zero-trust network, which is configured on a zero-trust service end, and the device includes: a first receiving module, configured to receive indication information sent by a zero-trust management end, and the indication information is used to indicate that an abnormality has occurred in the login service in the zero-trust network; a notification module, configured to respond to the indication information and notify the zero-trust gateway to enter an independent ticket verification state; a second processing module, configured to send login configuration information to a zero-trust terminal after receiving a response information returned by the zero-trust gateway, and the login configuration information includes pseudo-login execution condition information, so that the zero-trust terminal sends the access session traffic and the local access ticket to the zero-trust gateway based on the login configuration information, and the zero-trust gateway forwards the access session traffic to the business server after independently performing the verification of the local access ticket.

In a fifth aspect, an embodiment of the present application provides another access processing method based on a zero-trust network, which is applied to a zero-trust gateway, and the method includes: in response to a first notification message sent by a zero-trust server, entering a ticket independent verification state, and sending a response message to the zero-trust server; receiving access session traffic and a local access ticket sent by a zero-trust terminal, wherein the local access ticket is generated after the zero-trust terminal determines that it has the conditions to perform a pseudo-login based on the login configuration information sent by the zero-trust server, and the login configuration information includes pseudo-login execution condition information; independently performing verification of the local access ticket, and forwarding the access session traffic to the business server after the verification passes.

In a sixth aspect, an embodiment of the present application provides another access processing device based on a zero-trust network, which is configured on a zero-trust gateway, and the device includes: a response module, configured to respond to a first notification message sent by a zero-trust server, enter a ticket independent verification state, and send a response message to the zero-trust server; a second receiving module, configured to receive access session traffic and local access tickets sent by a zero-trust terminal, the local access ticket is generated after the zero-trust terminal determines that the conditions for executing a pseudo-login are met based on the login configuration information sent by the zero-trust server, and the login configuration information includes pseudo-login execution condition information; a third processing module, configured to independently execute verification of the local access ticket, and forward the access session traffic to the business server after the verification passes.

In the seventh aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the steps in the access processing method based on a zero-trust network as described in any of the preceding items.

In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium having computer-readable instructions stored thereon. When the computer-readable instructions are executed by a processor of a computer, the computer executes the steps in the access processing method based on a zero-trust network as described in any one of the above items.

In a ninth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps in the access processing method based on a zero-trust network as described in any one of the above items.

In the technical solution provided in the embodiments of the present application, in the case of an abnormal login service, login configuration information containing pseudo-login execution condition information is sent to the zero-trust terminal through the zero-trust server, so that the zero-trust terminal determines whether it has the conditions for executing pseudo-login required by the zero-trust server according to the login configuration information, and sends the access session traffic and the generated local access ticket to the zero-trust gateway if the conditions are met, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing the verification of the local access ticket. This is equivalent to sending a special switch to the zero-trust terminal and the zero-trust gateway through a special channel, allowing the zero-trust terminal to enter a pseudo-login state, and linking the zero-trust gateway to enter a state of independent ticket verification, so that the zero-trust terminal can still transmit the access session traffic to the zero-trust gateway, and the zero-trust gateway can also transmit the access session traffic to the business server, thereby ensuring normal user network access and improving the availability of the zero-trust network architecture.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of an exemplary application scenario based on a zero-trust network;

FIG2 is a schematic diagram showing an exemplary architecture of a zero-trust network;

FIG3 illustrates a schematic diagram of an exemplary zero-trust gateway configuration interface;

FIG4 is a schematic diagram showing an exemplary policy management configuration interface;

FIG5 is a schematic diagram showing an exemplary accessible business system configuration interface;

FIG6 illustrates a schematic diagram of an exemplary configuration interface of a trusted application in a zero-trust network;

FIG7 illustrates a schematic diagram of an exemplary zero-trust client login interface;

FIG8 is a flowchart of an access processing method based on a zero-trust network shown in an exemplary embodiment of the present application;

FIG9 is a flowchart of an access processing method based on a zero-trust network further proposed on the basis of the embodiment shown in FIG8 ;

FIG10 is a flowchart of an access processing method based on a zero-trust network further proposed based on the embodiment shown in FIG8 ;

FIG11 is a flowchart of an access processing method based on a zero-trust network shown in another exemplary embodiment of the present application;

FIG12 is a flowchart of an access processing method based on a zero-trust network shown in another exemplary embodiment of the present application;

FIG13 illustrates an access processing interaction flow chart based on a zero-trust network;

FIG14 is a schematic diagram of a process for a zero-trust terminal to initiate zero-trust network access;

FIG15 is a block diagram of an access processing device based on a zero-trust network according to an exemplary embodiment of the present application, wherein the device is configured on a zero-trust terminal;

FIG16 is a block diagram of an access processing device based on a zero-trust network shown in an exemplary embodiment of the present application, wherein the device is configured on a zero-trust server;

FIG17 is a block diagram of an access processing device based on a zero-trust network according to an exemplary embodiment of the present application, wherein the device is configured on a zero-trust gateway;

FIG. 18 shows a schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application.

DETAILED DESCRIPTION

Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations/steps, nor must they be executed in the order described. For example, some operations/steps can be decomposed, and some operations/steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

The term "multiple" as used in this application refers to two or more than two. "And/or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character "/" generally indicates that the related objects are in an "or" relationship.

The terms "first", "second", "third" and "fourth" etc. in the specification and claims of the present application and the drawings are used to distinguish different objects, rather than to describe a specific order. The terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units inherent to these processes, methods, products or devices.

As described in the background technology, with the continuous rise of emerging technologies such as cloud computing, big data, and the Internet of Things, the enterprise IT (Internet Technology) architecture is changing from "bounded" to "borderless", and the traditional security boundaries are gradually disintegrating. With the continuous advancement of new infrastructure represented by 5G (fifth-generation communication technology) and industrial Internet, the evolution of "borderless" will be further accelerated. At the same time, zero-trust security has gradually entered people's field of vision and become a new concept and new architecture for solving network security problems in the new era.

Zero trust refers to a network security protection concept, the key of which is to break the default "trust". In simple terms, it is "continuous verification, never trust". The core idea of zero trust is that by default, anyone, anything, or anything inside or outside the enterprise is untrustworthy, and anyone, anything, or anything that attempts to access the network and network resources should be verified before authorization.

It is easy to understand that zero trust recognizes the shortcomings of traditional perimeter security architecture in the network environment, and believes that hosts, no matter where they are in the network, should be regarded as Internet hosts, and the networks they are in, whether they are the Internet or internal networks, must be regarded as dangerous networks full of threats. Based on this, the zero trust network defaults to not trusting any person, device, or system inside or outside the enterprise network, and rebuilds the trust foundation of access control based on identity authentication and authorization, thereby ensuring that identities, devices, applications, and links are trusted.

Figure 1 is a schematic diagram of an exemplary application scenario based on a zero-trust network, which includes a zero-trust network security service provider, an access subject, and an access object. Among them, the access subject refers to the party that initiates access in the network, which is a digital entity composed of a single or combined combination of factors such as personnel, equipment, applications, and services. The access object refers to the party being accessed in the network. The zero-trust network security service provider provides a unified entrance for the access subject to request access to the object's resources through the network, and provides authentication operations for the unified entrance. Only network requests that pass the authentication can be forwarded by the proxy client to the zero-trust gateway, and the access to the actual business system is proxied through the zero-trust gateway.

Figure 2 shows a schematic diagram of the architecture of a zero-trust network, including a zero-trust management terminal 210, a zero-trust server 220, a zero-trust terminal 230 and a zero-trust gateway 240, wherein the zero-trust terminal 230 is deployed with trusted applications, zero-trust clients and proxy clients, and the zero-trust server 220 is deployed with service processes such as policy services, inspection services, ticket centers, and authentication services.

It should be understood that the zero-trust management terminal 210 provides an interface for configuring the zero-trust network, which is used to configure the zero-trust network, such as configuring the zero-trust access control policy, configuring the zero-trust gateway 240, etc. It can be understood that the zero-trust access control policy is composed of process information that can be used by users (i.e., trusted applications, which are application carriers that can access business resources from terminals authorized by the zero-trust management terminal, and can be identified by information such as application name, application MD5, signature information, etc.) and accessible business sites (i.e., reachable areas). When permissions are enabled, users can access any reachable area through any trusted application. Therefore, the granularity of the zero-trust access control policy is the logged-in user, which can be understood as the zero-trust access control policy formulating different zero-trust policies for different logged-in users.

For example, in the zero-trust gateway configuration interface shown in Figure 3, you can query, add, or batch delete zero-trust gateways in the zero-trust network. The addition of zero-trust gateways includes the gateway name, gateway setting information, information on the IP (Internet Protocol) field that prioritizes access to the zero-trust gateway, and creation time information, etc.

For another example, in the policy management configuration interface shown in FIG4 , trusted application configuration and business system configuration can be performed for different user accounts. Among them, the trusted application configuration can select the operating system that the configurable application is adapted to, and also provides convenient configuration items for selecting any application that can adapt to the current configuration; the business system configuration is the same, and also provides convenient configuration items for selecting all URLs (Uniform Resource Locator) that can adapt to the current configuration.

For another example, in the accessible business system configuration interface shown in Figure 5, it is supported to add accessible business systems in the zero-trust network by adding IP segments or domain names, and the added accessible business systems support adapting all ports or specified ports. The administrator can also configure different zero-trust gateways for each accessible business system, for example, after configuring the intranet resources in the business system, the accessible zero-trust gateway is also configured.

Figure 6 illustrates the configuration interface of a trusted application in a zero-trust network. It can be seen that the configuration of a trusted application includes the process name, signature information, version, process MD5, and sha256 content configuration.

Based on the configuration interface shown above, it can be seen that in the configuration of the zero-trust access control policy, traffic filtering is implemented based on the combined policy control of user account-trusted application-target business system, supporting wildcard domain names, IP segments, and multiple ports, and providing the user organizational structure for inheritance and expansion.

Zero Trust Server 220 uses the policy control engine to securely schedule business traffic and authorize it at the granularity of user-zero trust terminal-zero trust client-trusted application. Zero Trust Server 220 is responsible for verifying the user's identity, verifying the hardware information and device security status of Zero Trust Terminal 230, and testing the security of trusted applications. Zero Trust Server 220 can also regularly send files to the Cloud Check Service Center for inspection. If the Cloud Check Service Center identifies a malicious process, it will notify the Zero Trust Client to perform an asynchronous blocking operation.

The zero-trust client is a security application installed on the zero-trust terminal 230, which is responsible for verifying the trusted identity of the user on the zero-trust terminal 230, verifying whether the zero-trust terminal 230 is trustworthy, and verifying whether the application initiating the access is trustworthy. If the application process initiating the access is an untrusted application process, that is, an unknown application process, then an application is submitted to the zero-trust server 220 for inspection.

FIG7 shows a schematic diagram of an exemplary zero-trust client login interface. It can be seen that in the application scenario of enabling zero-trust office, the terminal user can log in to the zero-trust client by scanning a code or logging in with an account to implement the zero-trust office function. After logging in, the terminal user can see the details of the trusted application configured and issued by the zero-trust management end. According to the user-level policy issued by the zero-trust management end, the terminal user can access the business system configured by the administrator through the specified trusted application.

The proxy client refers to a terminal agent deployed on a controlled device that initiates secure access. It is responsible for initiating a request for trusted identity authentication of the access subject. If the verified identity is credible, it can establish an encrypted access connection with the zero-trust gateway 240. It is also the execution point of access policy control. The proxy client can hijack the business traffic of the zero-trust terminal 230 through a virtual network card, and forward the access request to the zero-trust gateway 240 after authentication by the zero-trust client.

The zero-trust gateway 240 is deployed at the entrance of applications and data resources, and is responsible for verifying and forwarding each session request to access resources.

It should be understood that the zero-trust terminal 230 can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch and other devices, but is not limited to this. The zero-trust server 220 can be a server, which can be an independent server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

It is also important to understand that cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or a local area network to achieve data computing, storage, processing, and sharing. Cloud computing is a computing model that distributes computing tasks across a resource pool consisting of a large number of computers, allowing various application systems to obtain computing power, storage space, and information services as needed. The network that provides resources is called a "cloud." From the user's perspective, the resources in the "cloud" are infinitely expandable and can be obtained at any time, used on demand, and expanded at any time.

Still referring to Figure 2, under the zero-trust network architecture, the overall process of a zero-trust terminal accessing a business site is as follows:

The access subject initiates a network request for the access object through a trusted application. After the zero-trust client hijacks the network request through the proxy client, it initiates an authentication request to the zero-trust client. That is, the proxy client applies to the zero-trust client for the credentials of the current network request. The request parameters include, for example, the source IP or domain name, source port, destination IP or domain name, destination port, and the process PID (Process Identification) corresponding to the trusted application.

The zero-trust client collects the MD5, process path, last modified time, copyright information, signature information, etc. of the trusted application process through the process PID sent by the proxy client, and applies for a ticket from the zero-trust server together with the source IP or domain name, source port, destination IP or domain name, and destination port of the network request passed by the proxy client. If the application is successful, the ticket, the maximum number of times the ticket is used, and the validity period of the ticket are sent to the proxy client as a response. It should be noted that the ticket can be understood as the authorization information issued by the zero-trust server for a single network request, which is used to identify the authorization status of this network request. When the login service is normal, each network request needs to be authorized by the zero-trust server.

The proxy client sends an Https request to the zero-trust gateway, in which the network request credentials (i.e., ticket) passed by the zero-trust client are included in the Authorization header field. After receiving the request, the zero-trust gateway parses the ticket in the header field and requests the zero-trust server to verify the ticket. If the verification is successful, the zero-trust gateway and the proxy client successfully establish a connection. After that, the proxy client sends the original network request to the zero-trust gateway, which forwards it to the corresponding business server and proxies the actual application network access. If the verification fails, the connection between the proxy client and the zero-trust gateway is interrupted. For traffic from applications outside the zero-trust policy to access specific sites, the proxy client directly initiates a network access request to the target business server to achieve a direct connection.

It can be seen from the above process that in a zero-trust network, every request for network resources must come from an authenticated and authorized user.

In the existing zero-trust network access architecture, when a user's network access is interrupted due to actual environmental reasons or problems with dependent services or components, such as zero-trust server downtime, IAM (Identity and Access Management) service or login service abnormality in the zero-trust server, the login service between the default zero-trust terminal and the zero-trust server is normal, and the default zero-trust gateway cluster is healthy. By generating virtual tickets on the zero-trust terminal side, automatically releasing the zero-trust server, and generating tickets by the security terminal, the traffic can be securely sent to the zero-trust gateway in abnormal scenarios, and the traffic can be forwarded to the business server normally through the zero-trust gateway to ensure the sustainable use of user network access. However, in the scenario where the login service between the zero-trust terminal and the zero-trust server is abnormal, it will directly affect the user's network access, resulting in low availability of the zero-trust network access architecture.

In order to solve the above technical problems, the embodiments of the present application provide an access processing method based on a zero-trust network, an access processing device based on a zero-trust network, an electronic device, and a computer storage medium based on a computer program product. These embodiments will be described in detail below.

Please refer to FIG. 8 , which is a flowchart of an access processing method based on a zero-trust network shown in an exemplary embodiment of the present application.

It should be noted that this embodiment does not improve the architecture of the zero-trust network. The zero-trust network mentioned in this embodiment can refer to the network architecture shown in Figure 2. It should also be noted that the method mentioned in this embodiment is specifically executed by a zero-trust terminal in the zero-trust network, such as the zero-trust terminal 230 shown in Figure 2, which is also a user terminal, and the zero-trust terminal is configured with a trusted application, a zero-trust client, and a proxy client.

As shown in FIG8 , the method applied to the zero-trust terminal includes S810-S830, which are described in detail as follows:

S810, obtaining login configuration information from a zero-trust server, where the login configuration information is generated after detecting an abnormality in a login service in a zero-trust network, and the login configuration information includes pseudo-login execution condition information.

Abnormalities in the login service in the zero-trust network will cause user network access failures. Therefore, when user network access failures are detected in the zero-trust network, further detection can be made as to whether the login service is abnormal. For example, zero-trust server downtime, IAM service or login service abnormalities in the zero-trust server will all lead to login service abnormalities in the zero-trust network.

When an abnormality is detected in the login service in the zero-trust network, it means that network access firefighting needs to be initiated to ensure the sustainable use of network access. Specifically, the zero-trust server sends login configuration information to the zero-trust terminal, and the login configuration information includes pseudo-login execution condition information, so that the zero-trust terminal enters the pseudo-login state under the conditions required by the zero-trust server.

It can be understood that pseudo login refers to a login state of a user in a zero-trust terminal, which is different from the normal login state. Specifically, the normal login state is illustrated in the process shown in Figure 2. After each network access initiated by a trusted application in a zero-trust terminal is hijacked by a zero-trust client, the proxy client initiates an authentication request to the zero-trust client to obtain the access ticket applied for by the zero-trust client to the zero-trust server, and then sends an Https request to the zero-trust gateway, carrying the access ticket in the Authorization header field. The zero-trust gateway requests the zero-trust server to verify the access ticket. If the verification is successful, the zero-trust gateway successfully establishes a connection with the proxy client, and then the proxy client sends the original network request to the zero-trust gateway, which is forwarded to the corresponding business server by the zero-trust gateway to proxy the actual application network access; if the verification fails, the connection between the proxy client and the zero-trust gateway is interrupted. For traffic from applications outside the zero-trust policy to access specific sites, a network access request is directly initiated to the target business server through the proxy client to achieve direct connection.

In this embodiment, the pseudo-login state means that when a user who has logged into a zero-trust client encounters an abnormality in the login service, the user uses a locally generated local access ticket instead of the access ticket applied for from the zero-trust server. After sending the local access ticket to the zero-trust gateway, zero-trust no longer requests the zero-trust server to verify the ticket, but independently performs the verification of the local access ticket, thereby not using the login service function of the zero-trust server. Therefore, in the scenario where there is an abnormality in the login service in the zero-trust network, the zero-trust terminal is put into a pseudo-login state, and the zero-trust gateway is linked to put it in a state of ignoring ticket verification (i.e., independently verifying the local access ticket of the zero-trust terminal). This ensures that the access traffic is transmitted to the zero-trust gateway, and the access traffic is forwarded normally to the business server through the zero-trust gateway, ensuring the sustainable use of the zero-trust function and improving the overall availability of the zero-trust network.

The way in which the zero-trust server detects abnormalities in the login service in the zero-trust network includes automatic detection or manual detection. Automatic detection means that the zero-trust server recognizes abnormalities in the login service through a preset program, such as detecting that it has crashed, or detecting that its own login service process has been suspended for more than a preset period of time, etc., which are not restricted here. Manual detection means that the zero-trust server receives notification information sent by the zero-trust management end. The notification information is sent by the zero-trust management end to the zero-trust server based on the detection results of the login service when it determines that the login service is abnormal.

The way that the zero trust server obtains the login configuration information from the zero trust server includes active acquisition or passive acquisition. Automatic acquisition means that the zero trust terminal pulls the pseudo login configuration information from the zero trust server before logging into the user account. The user account is understood as the login account of the user of the zero trust terminal using the zero trust client. Passive acquisition means that the zero trust server pushes the login configuration information to the zero trust terminal.

S820, determine whether the zero-trust terminal has the conditions for performing a pseudo login based on the login configuration information.

Since the login configuration information obtained by the zero-trust terminal includes pseudo-login execution condition information, the zero-trust terminal can determine whether it has the conditions to execute pseudo-login based on the login configuration information. If it is determined that the conditions to execute pseudo-login are met, it enters the pseudo-login state. If it is determined that the conditions to execute pseudo-login are not met, it means that in the current login service abnormal scenario, the sustainable use of the zero-trust function cannot be guaranteed.

Exemplarily, the conditions for a zero-trust terminal to perform a pseudo-login include that the user who initiated the current network access is a user who has logged in to the zero-trust terminal in the past, that is, only users who have logged in to the zero-trust terminal can enter the pseudo-login state, otherwise they cannot enter the pseudo-login state, thereby ensuring network security after the zero-trust terminal enters the pseudo-login state. Based on this, the zero-trust terminal searches for historical login information and compares the historical login information found with the received login configuration information. If the historical login information obtained meets the conditions for executing a pseudo-login contained in the login configuration information, it is determined that the zero-trust terminal has the conditions for executing a pseudo-login.

S830, when the zero-trust terminal has the conditions to perform a pseudo login, a local access ticket is generated, and the access session traffic and the local access ticket are sent to the zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing verification of the local access ticket.

When the zero-trust terminal has the conditions to perform a pseudo-login, the zero-trust terminal enters a pseudo-login state. The specific operations are: first generate a local access ticket, then send the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway independently performs the verification of the local access ticket, and after the verification passes, forwards the access session traffic to the corresponding business server.

Since the local access ticket is generated locally on the zero-trust terminal without the participation of the zero-trust server, even if the login service in the zero-trust network is abnormal, it will not affect the generation of the local access ticket. In addition, for the zero-trust gateway, the verification of the local access ticket does not require the participation of the zero-trust server, so it can also adapt to the situation where the login service in the zero-trust network is abnormal. Exemplarily, the local access ticket includes at least one of the user's unique identifier, the application process hash, the local generation time of the ticket, and the validity period of the ticket, which is not limited here.

Access session traffic refers to traffic data related to access to business resources in business servers initiated by zero-trust terminals through trusted applications. Therefore, after forwarding the access session traffic to the corresponding business server, the zero-trust gateway can obtain a response from the business server, which includes, for example, the business resources accessed by the zero-trust terminal, and then return the response to the zero-trust terminal, thereby ensuring normal network access for users in scenarios where the login service is abnormal.

It should be noted that the zero-trust terminal sends the access session traffic and local access tickets to the zero-trust gateway through the proxy client process after starting the proxy client process.

It can be seen from the above that the method provided in this embodiment is equivalent to sending a special switch to the zero-trust terminal and the zero-trust gateway through a special channel, allowing the zero-trust terminal to enter a pseudo-login state, and linking the zero-trust gateway to enter a state of independent ticket verification, so that the zero-trust terminal can still transmit the access session traffic to the zero-trust gateway, and the zero-trust gateway can also transmit the access session traffic to the business server, thereby ensuring normal user network access and improving the availability of the zero-trust network architecture.

In an exemplary embodiment, the process of generating a local access ticket includes the following steps:

Generate a ticket payload and a ticket signature based on the ticket content information, where the ticket generation information includes at least one of a user unique identifier, a ticket generation time, a ticket validity period, and a trusted application ciphertext; generate a local access ticket based on the ticket version identifier, the ticket payload, and the ticket signature.

In this embodiment, the local access ticket can be generated in a JWT (Json Web Token) format. It can be understood that the JWT format is an open standard based on Json that is implemented to transmit statements between network application environments. It specifies the structure of data transmission, that is, a complete JWT string consists of three paragraphs, each of which is connected by an English period (.), so the conventional JWT content format is a three-segment format similar to AAA.BBB.CCC. Based on this, the content format of the local access ticket is also a three-segment format, including a ticket version identifier, a ticket payload, and a ticket signature.

The ticket version identifier needs to be distinguished from the version identifier of the access ticket in the scenario where the login service is normal, to indicate that this is an access ticket generated in a network firefighting scenario and is verified solely by the zero-trust gateway.

The ticket payload also refers to the ticket content. The ticket payload needs to be generated based on the ticket content information. For example, the ticket payload can be generated based on the user's unique identifier, the trusted application ciphertext, the ticket generation time, and the ticket validity period. The ticket validity period can be set to a default value. The process of generating the ticket payload can be expressed as follows:

Base64UrlEncode(uid+application process md5+ticket generation time+ticket validity period)

In the above formula, uid represents the user's unique identifier, application process md5 represents the trusted application ciphertext, and Base64UrlEncode represents a preset encoding method, which is an encoding method suitable for network data. The local access ticket in this embodiment is encoded using this method, which can facilitate the transmission of local access tickets in a zero-trust network.

The ticket signature is used to verify whether the local access ticket has been changed during the transmission to the zero-trust gateway. The ticket signature also needs to be generated based on the ticket content information shown above. For example, by obtaining the key agreed upon between the zero-trust terminal and the zero-trust gateway, the ticket content information is encoded using a preset encoding method, and the encoded ticket content information is encrypted based on the key to obtain the ciphertext content. Finally, the ciphertext content is encoded based on the preset encoding method to obtain the ticket signature. The process of generating a ticket signature can be expressed as follows:

Base64UrlEncode(hmac_sha256(Base64UrlEncode(ticket content information), key))

In the above formula, the bill content information is also the content information required to generate the bill payload, so the encoded bill content Base64UrlEncode (bill content information) can be understood as the bill payload. After using the hmac_sha256 confidentiality algorithm and using the key to encrypt the encoded bill content to obtain the ciphertext content, the ciphertext content is also encoded using the Base64UrlEncode method to obtain the bill signature.

Exemplarily, the key agreed upon between the zero-trust terminal and the zero-trust gateway can be generated using the key derivation function PBKDF2. It is understandable that PBKDF2 mainly derives the key through a pseudo-random function. The length of the derived key is essentially unlimited, but it can be set to perform multiple calculations, taking the plaintext and a salt value as parameters, and finally generating the key. It is understandable that the key generated after adding salt can increase the ability to resist attacks. The iterative parameters and salt values in PBKDF2 need to be negotiated in advance by both the zero-trust terminal and the zero-trust gateway.

Corresponding to the above-mentioned local access ticket generation process, the zero-trust gateway independently executes the local access ticket verification logic as follows:

First, the first two pieces of information in the local access ticket, namely the ticket version identifier and the ticket payload, are used to calculate the signature value using the same algorithm and key. Then, the signature value is compared with the third piece of information in the local access ticket, namely the ticket signature. If they are the same, the verification is passed, indicating that the local access ticket has not been changed during transmission to the zero-trust gateway, and the zero-trust network is secure, thereby forwarding the access session traffic to the corresponding business server; otherwise, the verification fails, indicating that the local access ticket has been changed during transmission to the zero-trust gateway, and there are security risks in the zero-trust network. Therefore, the zero-trust gateway will not forward the access session process to the business server to ensure the security of business resources in the zero-trust network.

FIG9 is a flowchart of an access processing method based on a zero-trust network further proposed on the basis of the embodiment shown in FIG8. As shown in FIG9, the process of determining whether a zero-trust terminal has the conditions for performing a pseudo-login based on the login configuration information includes S821-S822, and the method also includes S840, which is described in detail as follows:

S821, detect the pseudo login execution switch information contained in the login configuration information, where the pseudo login execution switch information is generated by the zero trust server after notifying the zero trust gateway to enter the ticket independent verification state.

The login configuration information mentioned in this embodiment includes not only pseudo-login execution condition information, but also pseudo-login execution switch information, which is used to indicate whether the function of executing pseudo-login has been enabled in the zero-trust network.

It should be understood that in order to enable the function of executing pseudo login in a zero-trust network, the zero-trust server needs to notify the zero-trust gateway to enter the independent ticket verification state. In other words, the condition for enabling the pseudo login function is that the zero-trust gateway needs to enter the independent ticket verification state. Therefore, the pseudo-login execution switch information is generated by the zero-trust server after notifying the zero-trust gateway to enter the independent ticket verification state.

S822, if the pseudo login execution switch information indicates to turn on the pseudo login execution, determine whether the login condition parameters in the zero trust terminal meet the pseudo login execution condition information contained in the login configuration information. If so, determine that the zero trust terminal has the conditions to execute the pseudo login.

If the pseudo login execution switch information indicates that the pseudo login is turned on, it means that the zero trust network has turned on the pseudo login function. Therefore, it is necessary to further determine whether the login condition parameters in the zero trust terminal meet the pseudo login execution condition information contained in the login configuration information. Only when the conditions are met can it be determined that the zero trust terminal has the conditions to execute the pseudo login.

The login condition parameters can be understood as the relevant parameters obtained from the historical login information of the zero-trust terminal in accordance with the pseudo-login execution condition information. For example, the pseudo-login execution condition information requires that the login time of the last valid login is before the specified time, and the corresponding login condition parameters obtained include the login time of the last valid login of the same user in the zero-trust terminal. The pseudo-login execution condition information also requires that the login-related information of the last valid login has been backed up in the encrypted persistence library local to the zero-trust terminal, and the corresponding login condition parameters include the information related to the user's last valid login stored in the encrypted persistence library local to the zero-trust terminal.

Exemplarily, the login-related information of the user's most recent valid login includes the user's unique identifier, user name, login ticket, etc., which are not limited here. The login ticket is understood to be an encrypted string assigned to the user by the zero-trust server after the user successfully logs in to the zero-trust client, which represents the user's login authorization information, such as user information and authorization validity period. The persistent library is understood to be a storage medium converted from a data structure or object model in the memory in a disk file or data file stored locally on the zero-trust terminal, which can be implemented using encrypted files, embedded databases, etc.

In an exemplary implementation, the following process may be used to determine whether the login condition parameters in the zero-trust terminal satisfy the pseudo login execution condition information contained in the login configuration information:

Obtain historical login information from zero-trust terminals;

If it is determined based on historical login information that the login time of the most recent valid login is before the time specified by the pseudo login condition, and the login-related information of the most recent valid login has been persistently stored locally, then it is determined that the login condition parameters in the zero-trust terminal meet the pseudo login execution condition information contained in the login configuration information.

As mentioned above, in order to ensure the security of the zero-trust network when executing a pseudo-login, the user who initiates the current network access must be a user who has logged in historically in the zero-trust client. The zero-trust server has already performed identity authorization for the user when the user logged in historically, so it is necessary to obtain the historical login information in the zero-trust terminal, and use the historical login information as the login condition parameter in the zero-trust terminal to determine whether the current user is a user who has logged in before based on the historical login information. If the login time of the most recent valid login is determined to be before the time specified by the pseudo-login condition based on the historical login information, and the login-related information of the most recent valid login has been persistently stored locally, it is determined that the login condition parameters in the zero-trust terminal meet the pseudo-login execution condition information contained in the login configuration information, and therefore it is determined that the zero-trust terminal has the conditions to execute a pseudo-login.

To put it simply, the conditions for a zero-trust terminal to perform a pseudo login are: the pseudo login switch sent by the zero-trust server is turned on, and a user has logged in to the zero-trust terminal before, and the last login time is before the specified time, and login-related information, such as the user's unique identifier, user name, login ticket, etc., has been backed up in the terminal's local encrypted persistence library. If these conditions are met, the zero-trust terminal directly enters the pseudo login state.

S840, when the zero-trust terminal does not have the conditions to perform a pseudo login, perform a regular login; if the regular login is successful, store the user information and login ticket of this login, and enter the regular login state.

If the zero-trust terminal does not have the conditions to perform a pseudo login, it means that the zero-trust terminal cannot enter the pseudo login state. At this time, a regular login is performed to determine whether the login service in the zero-trust network has been restored. If the regular login is successful, the user information and login ticket of this login are stored, and the regular login state is entered. If the regular login fails, it means that the network access cannot be achieved this time, and a notification information indicating network abnormality can be generated.

It can be understood that regular login refers to the user login method performed when the login service is normal. Regular login can include, for example, scanning code login, multi-factor login, or account password login. During regular login, when the user successfully logs in to the zero-trust client, the zero-trust server will specify an encrypted string (i.e., login credentials) for the user, indicating the user's login authorization information, that is, the zero-trust server has authorized the user to log in to the zero-trust terminal. After the regular login is successful, the user information and login ticket for this login are stored locally on the zero-trust terminal.

It should be noted that the network access process of the zero-trust terminal in the normal login state can be found in the process shown in Figure 2, which will not be repeated here.

It can be seen from the above that in the method provided in this embodiment, on the one hand, by including pseudo-login execution switch information in the login configuration information, and setting the pseudo-login execution switch information to be generated by the zero-trust server after notifying the zero-trust gateway to enter the ticket independent verification state, it can be ensured that when the zero-trust terminal obtains the login configuration information, the zero-trust network has prepared the conditions for the zero-trust terminal to execute the pseudo-login, thereby ensuring that the zero-trust terminal can smoothly enter the pseudo-login state; on the other hand, when the login condition parameters in the zero-trust terminal do not meet the pseudo-login execution condition information in the login configuration information, a regular login is executed instead, and when the login is successful, the user information and login ticket of this login are stored, and a regular login is attempted to ensure that when the login service is restored, the regular network access process can be restored in time, and the availability of the zero-trust network can be further improved.

Fig. 10 is a flowchart of a method for access processing based on a zero-trust network further proposed based on the embodiment shown in Fig. 8. As shown in Fig. 10, the method further includes S850 based on the process shown in Fig. 8, which is described in detail as follows:

S850, after receiving the notification sent by the zero trust server instructing to exit the pseudo login, stop executing S830 to exit the pseudo login state; or, if it is detected that the duration of the pseudo login state exceeds the maximum duration of the pseudo login contained in the login configuration information, automatically log out of the login account and clear the local access ticket to exit the pseudo login state.

Considering that if the zero-trust terminal remains in a pseudo-login state for a long time, it may cause security risks in the zero-trust network. Therefore, this embodiment further provides a solution for the zero-trust terminal to exit the pseudo-login state, thereby ensuring the security of the zero-trust network.

One solution is that after detecting that the login service has been restored, the zero-trust server sends a notification to the zero-trust terminal instructing it to exit the pseudo-login. For example, the zero-trust server first notifies the zero-trust gateway to cancel the ticket independent verification state, and after returning to the normal ticket verification state, it sends a notification to the zero-trust terminal instructing it to exit the pseudo-login, which is equivalent to sending a switch information instructing it to exit the pseudo-login to the zero-trust terminal. After receiving the notification, the zero-trust terminal stops executing the steps of generating a local access ticket and forwarding the local access ticket and access session traffic to the zero-trust gateway, thereby exiting the pseudo-login state.

Another solution is that the login configuration information sent by the zero trust server to the zero trust terminal includes not only the pseudo login execution condition information and the pseudo login execution switch information, but also the maximum duration of the pseudo login, which is used to stipulate the maximum duration of the zero trust terminal's pseudo login state. Therefore, if the zero trust terminal detects that the duration of its own pseudo login state exceeds the maximum duration of the pseudo login, it will automatically log out of the login account and clear the local access ticket to exit the pseudo login state.

After the zero-trust terminal exits the pseudo-login state, if it still needs to use the zero-trust capability of the zero-trust network to access business resources, it must first perform a regular login. After the regular login is successful, according to the access processing flow shown in Figure 2, apply to the zero-trust server for the access ticket required for each access. The access ticket needs to be verified by the zero-trust gateway before it can access business resources normally, thereby ensuring that the zero-trust function of the zero-trust network can be used sustainably in actual application scenarios.

FIG11 is a flowchart of an access processing method based on a zero-trust network shown in another exemplary embodiment of the present application. It should be noted that this embodiment does not improve the architecture of the zero-trust network, and the zero-trust network mentioned in this embodiment still refers to the network architecture shown in FIG2. It should also be noted that the method mentioned in this embodiment is specifically executed by a zero-trust server in the zero-trust network, such as the zero-trust server 220 shown in FIG2.

As shown in FIG11 , the access processing method based on the zero-trust network includes the following steps:

S1110, receiving indication information sent by the zero trust management terminal, where the indication information is used to indicate that an abnormality occurs in a login service in the zero trust network;

S1120, in response to the instruction information, notifying the zero trust gateway to enter the ticket independent verification state;

S1130, after receiving the response information returned by the zero trust gateway, sends login configuration information to the zero trust terminal, the login configuration information includes pseudo login execution condition information, so that the zero trust terminal sends the access session traffic and local access ticket to the zero trust gateway based on the login configuration information. After the zero trust gateway independently performs the verification of the local access ticket, it forwards the access session traffic to the business server.

From the above, it can be seen that after receiving the message sent by the zero trust management end indicating that the login service in the zero trust network is abnormal, the zero trust server responds to the indication information and notifies the zero trust gateway to enter the ticket independent verification state. After receiving the response information returned by the zero trust gateway, it indicates that the zero trust network is ready to perform a pseudo login. Therefore, the login configuration information is sent to the zero trust terminal, so that the zero trust terminal determines that it has the conditions to perform a pseudo login according to the pseudo login execution condition information contained in the login configuration, and then sends the access session traffic and the local access ticket to the zero trust gateway. After the zero trust gateway independently performs the verification of the local access ticket, it forwards the access session traffic to the business server, so that in the scenario of abnormal login service, the sustainable use of the zero trust function can be guaranteed, thereby improving the overall availability of the zero trust network.

In another exemplary embodiment, based on the embodiment shown in FIG. 11 , the access processing method based on the zero-trust network further includes the following steps:

S1140, after receiving the specified notification message sent by the zero trust management terminal, notify the zero trust gateway to cancel the independent verification status of the ticket;

S1150, after receiving the response information returned by the zero-trust gateway, send a notification message instructing to exit the pseudo-login to the zero-trust terminal, so that the zero-trust terminal exits the pseudo-login state.

From the above, it can be seen that after receiving the specified notification message sent by the zero trust management end, the zero trust server first notifies the zero trust gateway to cancel the independent verification status of the ticket, and after receiving the response information returned by the zero trust gateway, it sends a notification message instructing the zero trust terminal to exit the pseudo login state, so that the zero trust terminal exits the pseudo login state, thereby providing a solution for the zero trust terminal to exit the pseudo login state, so as to avoid the security risks that may arise when the zero trust terminal is in the pseudo login state for a long time.

It should be noted that the details of the zero-trust server executing the access processing method based on the zero-trust network have been recorded in detail in the previous embodiment of the zero-trust terminal executing the access processing method based on the zero-trust network, and will not be repeated here.

FIG12 is a flowchart of an access processing method based on a zero-trust network shown in another exemplary embodiment of the present application. It should be noted that this embodiment still does not improve the architecture of the zero-trust network, and the zero-trust network mentioned in this embodiment still refers to the network architecture shown in FIG2. It should also be noted that the method mentioned in this embodiment is specifically executed by a zero-trust gateway in the zero-trust network, such as the zero-trust gateway 240 shown in FIG2.

As shown in FIG12 , the access processing method based on the zero-trust network includes the following steps:

S1210, in response to the first notification information sent by the zero trust server, entering the ticket independent verification state, and sending a response information to the zero trust server;

S1220, receiving access session traffic and a local access ticket sent by the zero-trust terminal, where the local access ticket is generated after the zero-trust terminal determines that it has conditions for executing a pseudo-login based on the login configuration information sent by the zero-trust server, where the login configuration information includes pseudo-login execution condition information;

S1230, independently perform verification of the local access ticket, and forward the access session traffic to the business server after the verification passes.

As can be seen from the above, after the zero-trust gateway receives the first notification information sent by the zero-trust server, it responds to the first notification information, enters the ticket independent verification state, and returns the response information to the zero-trust server. After the zero-trust server receives the response information returned by the zero-trust gateway, it sends the login configuration information to the zero-trust terminal, so that the zero-trust terminal determines that it has the conditions to execute the pseudo-login according to the pseudo-login execution condition information contained in the login configuration, and then sends the access session traffic and the local access ticket to the zero-trust gateway. After the zero-trust gateway receives the access session traffic and local access ticket sent by the zero-trust terminal, it independently performs the verification of the local access ticket, and forwards the access session traffic to the corresponding business server after the verification passes, so that in the scenario of abnormal login service, the zero-trust terminal can still access business resources normally, thereby ensuring the sustainable use of the zero-trust function and improving the overall availability of the zero-trust network.

In another exemplary embodiment, based on the embodiment shown in FIG. 12 , the access processing method based on the zero-trust network further includes the following steps:

S1240, in response to the second notification information sent by the zero trust server, exit the ticket independent verification state, and send a response information to the zero trust server;

S1250, receiving access session traffic and an access ticket sent by the zero-trust terminal, where the access ticket is obtained by the zero-trust terminal applying to the zero-trust server;

S1260, apply to the zero trust server to verify the access ticket, and forward the access session traffic to the business server after the verification passes.

As can be seen from the above, after receiving the designated notification message sent by the zero trust management end, the zero trust server notifies the zero trust gateway to cancel the ticket independent verification state. In response to the second notification message sent by the zero trust server, the zero trust gateway exits the ticket independent verification state and sends a response message to the zero trust server. After receiving the response message returned by the zero trust gateway, the zero trust server sends a notification message indicating the exit of the pseudo login to the zero trust terminal, so that the zero trust terminal exits the pseudo login state. If the zero trust gateway still receives the access session traffic and access ticket sent by the zero trust terminal in the future, it means that this is a normal zero trust access performed by the zero trust terminal. The access ticket is obtained by the zero trust terminal from the zero trust server for this network access. Therefore, the zero trust gateway applies to the zero trust server for verification of the access ticket, and forwards the access session traffic to the business server after the verification is passed, thereby providing a solution for the zero trust terminal to exit the pseudo login state, so as to avoid the potential security risks that may arise when the zero trust terminal is in the pseudo login state for a long time, and can switch to normal zero trust access after the pseudo login is exited.

It should also be noted that the details of the zero-trust gateway executing the access processing method based on the zero-trust network have been recorded in detail in the previous embodiment of the zero-trust terminal executing the access processing method based on the zero-trust network, and will not be repeated here.

In order to further understand the contents described in the above embodiment, FIG13 illustrates an access processing interaction flow chart based on a zero-trust network.

As shown in Figure 13, the zero trust management terminal first sends an indication message to the zero trust server to indicate that a login service anomaly has been detected. The zero trust server responds normally and then notifies the zero trust gateway to enter the ticket independent verification state. After entering the ticket independent verification state, the zero trust gateway returns a response to the zero trust server. Subsequently, the zero trust server turns on the pseudo login switch and generates login configuration information. The premise for the zero trust terminal to initiate network access is that the user has logged in. Before logging in, the zero trust terminal pulls the login configuration information from the zero trust server. The zero trust server responds to this and sends the login configuration information to the zero trust terminal. After the zero trust terminal determines that it has entered the pseudo login state based on the login configuration information, it generates a local access ticket and sends the access session traffic and the local access ticket to the zero trust gateway. Since the zero trust gateway enters the ticket independent verification state, the zero trust gateway directly forwards the access session process to the corresponding business server in the business system after verifying the local access ticket. The business system responds and returns the business resources that the zero trust terminal wants to access.

When the login service is restored, the Zero Trust Management sends a specified notification message to the Zero Trust Server to notify that the login service has been restored. The Zero Trust Server responds normally and then notifies the Zero Trust Gateway to cancel the independent verification status of the ticket. After canceling the independent verification status of the ticket, the Zero Trust Gateway returns a response to the Zero Trust Server. Subsequently, the Zero Trust Server turns off the pseudo login switch. If the Zero Trust Terminal detects that the duration of the pseudo login it performs exceeds the maximum duration set in the login configuration information, it automatically logs out of the current login account and clears the last login ticket.

The next time the zero-trust terminal accesses the network, it needs to log in again and before logging in, it needs to re-pull the instruction information from the zero-trust server whether to perform a fake login. The zero-trust service will respond with an instruction not to perform a fake login. The zero-trust terminal sends the original session traffic and access ticket for network access to the zero-trust gateway. Since the access ticket is applied for by the zero-trust terminal from the zero-trust server based on the normal zero-trust access process, the zero-trust gateway needs to apply to the zero-trust server to verify the access ticket, and forward the original session traffic to the corresponding business server in the business system after the verification is passed.

FIG14 is a flow chart of a zero-trust terminal starting zero-trust network access. As shown in FIG14, after the zero-trust management terminal issues the pseudo-login switch, that is, after the zero-trust management terminal instructs the zero-trust server to turn on the pseudo-login switch as shown in FIG13, the zero-trust terminal will be enabled to access the network in a pseudo-login state. Specifically, the zero-trust terminal pulls the login configuration information from the zero-trust server before logging in. If it is determined that the pull is successful and the zero-trust terminal is instructed to enter the pseudo-login state, it is determined whether the conditions for executing the pseudo-login are met based on the historical login information, that is, whether the pseudo-login can be performed.

If the pulled login configuration information does not indicate a pseudo login, or if it is determined that a pseudo login cannot be performed based on the historical login information of the zero-trust terminal, then a regular login is further performed. If the regular login fails, it means that the zero-trust network access function cannot be used, so the entire access process ends. If the regular login is successful, the login ticket for this time needs to be stored, and zero-trust network access is started. In this case, zero-trust network access is performed using the regular process. If it is determined that a pseudo login can be performed based on the historical login information, zero-trust network access is also started. In this case, zero-trust network access is performed using the pseudo login process.

Based on Figures 13 and 14, it can be seen that when the login service is abnormal, this application pushes a special switch to the zero-trust terminal and the zero-trust gateway through a special channel, allowing the zero-trust terminal to enter a pseudo-login state, and at the same time links the zero-trust gateway to put it in a state of ignoring ticket verification, that is, an independent ticket verification state, so that under extremely harsh conditions, the zero-trust terminal can also securely transmit session traffic to the zero-trust gateway, and the zero-trust gateway can also forward session traffic to the business server normally, thereby ensuring the sustainable use of the zero-trust function and improving the overall availability of the zero-trust network.

FIG15 is a block diagram of an access processing device based on a zero-trust network shown in an exemplary embodiment of the present application. The device is configured on a zero-trust terminal and includes an acquisition module 1510 , a determination module 1520 and a first processing module 1530 .

The acquisition module 1510 is configured to acquire login configuration information from the zero-trust server. The login configuration information is generated after an abnormality is detected in the login service in the zero-trust network. The login configuration information includes pseudo-login execution condition information.

The determination module 1520 is configured to determine whether the zero-trust terminal has the conditions to perform a pseudo login based on the login configuration information.

The first processing module 1530 is configured to generate a local access ticket if the zero-trust terminal meets the conditions for performing a pseudo login, and send the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing verification of the local access ticket.

In another exemplary embodiment, the determination module 1520 is further configured to perform the following steps:

Detect the pseudo login execution switch information contained in the login configuration information. The pseudo login execution switch information is generated by the zero trust server after notifying the zero trust gateway to enter the ticket independent verification state;

If the pseudo login execution switch information indicates to turn on the pseudo login, it is determined whether the login condition parameters in the zero-trust terminal meet the pseudo login execution condition information contained in the login configuration information. If so, it is determined that the zero-trust terminal has the conditions to execute the pseudo login.

In another exemplary embodiment, the determination module 1520 is further configured to perform the following steps:

Obtain historical login information from zero-trust terminals;

If it is determined based on historical login information that the login time of the most recent valid login is before the time specified in the pseudo login execution condition information, and the login-related information of the most recent valid login has been persistently stored locally, then it is determined that the login condition parameters in the zero-trust terminal meet the pseudo login execution condition information contained in the login configuration information.

In another exemplary embodiment, the device also includes a regular login module 1540, which is configured to perform a regular login when the zero-trust terminal does not have the conditions to perform a pseudo login; if the regular login is successful, the user information and login ticket of this login are stored, and the regular login state is entered.

In another exemplary embodiment, the first processing module 1530 is further configured to perform the following steps:

Generate a ticket payload and a ticket signature according to the ticket content information, where the ticket generation information includes at least one of a user unique identifier, a ticket generation time, a ticket validity period, and a trusted application ciphertext;

Generate a local access ticket based on the ticket version identifier, ticket payload, and ticket signature.

In another exemplary embodiment, the first processing module 1530 is further configured to perform the following steps:

Obtain the key agreed upon between the zero-trust terminal and the zero-trust gateway;

Encode the bill content information using a preset encoding method, and perform encryption operation on the encoded bill content information based on a key to obtain ciphertext content;

The ciphertext content is encoded based on the preset encoding method to obtain the bill signature.

In another exemplary embodiment, the first processing module 1530 is further configured to send the access session traffic and the local access ticket to the zero trust gateway through the proxy client process after starting the proxy client process configured in the zero trust terminal.

In another exemplary embodiment, the device also includes an exit module 1550, which is configured to stop executing the steps of generating a local access ticket and sending the access session traffic and the local access ticket to the zero trust gateway after receiving a notification sent by the zero trust server instructing to exit the pseudo login, so as to exit the pseudo login state; or, if it is detected that the duration of the pseudo login state exceeds the maximum duration of the pseudo login contained in the login configuration information, the login account is automatically logged out and the local access ticket is cleared to exit the pseudo login state.

Figure 16 is a block diagram of an access processing device based on a zero-trust network shown in an exemplary embodiment of the present application. The device is configured on a zero-trust server and includes a first receiving module 1610, a notification module 1620 and a second processing module 1630.

The first receiving module 1610 is configured to receive indication information sent by the zero-trust management terminal, where the indication information is used to indicate that an abnormality has occurred in the login service in the zero-trust network.

The notification module 1620 is configured to notify the zero-trust gateway to enter the ticket independent verification state in response to the indication information.

The second processing module 1630 is configured to send login configuration information to the zero trust terminal after receiving the response information returned by the zero trust gateway. The login configuration information includes pseudo login execution condition information, so that the zero trust terminal sends the access session traffic and local access ticket to the zero trust gateway based on the login configuration information. After the zero trust gateway independently performs the verification of the local access ticket, it forwards the access session traffic to the business server.

In another exemplary embodiment, the device also includes an exit indication module 1640, which is configured to notify the zero trust gateway to cancel the independent verification status of the ticket after receiving a specified notification message sent by the zero trust management terminal, and to send a notification message instructing to exit the pseudo login to the zero trust terminal after receiving a response message returned by the zero trust gateway, so that the zero trust terminal exits the pseudo login state.

Figure 17 is a block diagram of an access processing device based on a zero-trust network shown in an exemplary embodiment of the present application. The device is configured on a zero-trust gateway and includes a response module 1710, a second receiving module 1720 and a third processing module 1730.

The response module 1710 is configured to enter a ticket independent verification state in response to the first notification information sent by the zero trust server, and send a response message to the zero trust server.

The second receiving module 1720 is configured to receive access session traffic and local access tickets sent by the zero-trust terminal. The local access ticket is generated after the zero-trust terminal determines that the conditions for executing a pseudo-login are met based on the login configuration information sent by the zero-trust server. The login configuration information includes pseudo-login execution condition information.

The third processing module 1730 is configured to independently perform verification of the local access ticket, and forward the access session traffic to the business server after the verification passes.

In another exemplary embodiment, the device also includes a recovery processing module 1740, which is configured to respond to a second notification message sent by the zero trust server, exit the ticket independent verification state, send a response message to the zero trust server, receive the access session traffic and access ticket sent by the zero trust terminal, the access ticket is obtained by the zero trust terminal applying to the zero trust server, apply to the zero trust server for verification of the access ticket, and forward the access session traffic to the business server after the verification passes.

It should be noted that the access processing device based on zero-trust network provided in the above embodiment and the access processing method based on zero-trust network provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment, and will not be repeated here. In actual application, the access processing device based on zero-trust network provided in the above embodiment can distribute the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

An embodiment of the present application also provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs. When the one or more programs are executed by the one or more processors, the electronic device implements the access processing method based on the zero-trust network provided in the above-mentioned embodiments.

Fig. 18 shows a schematic diagram of a computer system of an electronic device suitable for implementing an embodiment of the present application. It should be noted that the computer system 1800 of the electronic device shown in Fig. 18 is only an example and should not bring any limitation to the functions and scope of use of the embodiment of the present application.

As shown in FIG. 18 , a computer system 1800 includes a central processing unit (CPU) 1801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1802 or a program loaded from a storage part 1808 to a random access memory (RAM) 1803, such as executing the method described in the above embodiment. Various programs and data required for system operation are also stored in RAM 1803. CPU 1801, ROM 1802, and RAM 1803 are connected to each other via a bus 1804. An input/output (I/O) interface 1805 is also connected to bus 1804.

The following components are connected to the I/O interface 1805: an input section 1806 including a keyboard, a mouse, etc.; an output section 1807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1808 including a hard disk, etc.; and a communication section 1809 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1809 performs communication processing via a network such as the Internet. A drive 1810 is also connected to the I/O interface 1805 as needed. A removable medium 1811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1810 as needed so that a computer program read therefrom is installed into the storage section 1808 as needed.

In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1809, and/or installed from a removable medium 1811. When the computer program is executed by a central processing unit (CPU) 1801, various functions defined in the system of the present application are executed.

It should be noted that the computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer program contained in the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

Another aspect of the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the access processing method based on a zero-trust network as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

Another aspect of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the access processing method based on the zero-trust network provided in each of the above embodiments.

The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

It should also be noted that in the specific implementation of this application, related data such as login configuration information, historical login information, ticket content information, etc., when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

Claims (17)

1. An access processing method based on a zero-trust network, characterized in that it is applied to a zero-trust terminal, and the method includes: Acquire login configuration information from a zero-trust server, where the login configuration information is generated after detecting that a login service in the zero-trust network is abnormal, and the login configuration information includes pseudo-login execution condition information; Determining whether the zero-trust terminal has a pseudo-login condition based on the login configuration information; When the zero-trust terminal is qualified to perform a pseudo-login, a local access ticket is generated, and the access session traffic and the local access ticket are sent to the zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing verification of the local access ticket. 2. The method according to claim 1, wherein determining whether the zero-trust terminal has the conditions for performing a pseudo login based on the login configuration information comprises: Detecting pseudo login execution switch information included in the login configuration information, where the pseudo login execution switch information is generated by the zero trust server after notifying the zero trust gateway to enter a ticket independent verification state; If the pseudo-login execution switch information indicates to turn on the pseudo-login execution, it is determined whether the login condition parameters in the zero-trust terminal meet the pseudo-login execution condition information contained in the login configuration information. If so, it is determined that the zero-trust terminal has the conditions to execute the pseudo-login. 3. The method according to claim 2, characterized in that the step of determining whether the login condition parameters in the zero-trust terminal meet the pseudo-login execution condition information contained in the login configuration information comprises: Obtaining historical login information from the zero-trust terminal; If the login time of the most recent valid login is determined according to the historical login information to be before the time specified by the pseudo login execution condition information, and the login-related information of the most recent valid login has been persistently stored locally, then it is determined that the login condition parameters in the zero-trust terminal meet the pseudo login execution condition information contained in the login configuration information. 4. The method according to claim 1, characterized in that the method further comprises: Performing a regular login when the zero-trust terminal does not have a condition to perform a pseudo login; If the regular login is successful, the user information and login ticket of this login are stored, and the regular login state is entered. 5. The method according to claim 1, wherein generating a local access ticket comprises: Generate a ticket payload and a ticket signature according to the ticket content information, wherein the ticket generation information includes at least one of a user unique identifier, a ticket generation time, a ticket validity period, and a trusted application ciphertext; The local access ticket is generated based on the ticket version identifier, the ticket payload, and the ticket signature. 6. The method according to claim 5, characterized in that the step of generating a bill payload and a bill signature according to bill content information comprises: Obtaining a key agreed upon between the zero trust terminal and the zero trust gateway; Encoding the ticket content information using a preset encoding method, and performing encryption operation on the encoded ticket content information based on the key to obtain ciphertext content; The ciphertext content is encoded based on the preset encoding method to obtain the bill signature. 7. The method according to any one of claims 1 to 6, characterized in that the method further comprises: After receiving the notification sent by the zero-trust server indicating to exit the pseudo-login, stop executing the step of generating the local access ticket and sending the access session traffic and the local access ticket to the zero-trust gateway to exit the pseudo-login state; Alternatively, if it is detected that the duration of the pseudo login state exceeds the maximum pseudo login duration contained in the login configuration information, the pseudo login state is exited by automatically logging out of the login account and clearing the local access ticket. 8. The method according to any one of claims 1 to 6, wherein sending the access session traffic and the local access ticket to a zero trust gateway comprises: After starting the proxy client process configured in the zero-trust terminal, the access session traffic and the local access ticket are sent to the zero-trust gateway through the proxy client process. 9. An access processing method based on a zero-trust network, characterized in that it is applied to a zero-trust server, and the method includes: Receiving indication information sent by the zero-trust management terminal, wherein the indication information is used to indicate that an abnormality occurs in a login service in the zero-trust network; In response to the indication information, notifying the zero-trust gateway to enter a ticket independent verification state; After receiving the response information returned by the zero-trust gateway, login configuration information is sent to the zero-trust terminal, and the login configuration information includes pseudo-login execution condition information, so that the zero-trust terminal sends the access session traffic and the local access ticket to the zero-trust gateway based on the login configuration information. After the zero-trust gateway independently performs the verification of the local access ticket, it forwards the access session traffic to the business server. 10. The method according to claim 9, characterized in that the method further comprises: After receiving the specified notification message sent by the zero trust management terminal, notifying the zero trust gateway to cancel the ticket independent verification state; After receiving the response information returned by the zero-trust gateway, a notification message instructing to exit the pseudo-login is sent to the zero-trust terminal, so that the zero-trust terminal exits the pseudo-login state. 11. An access processing method based on a zero-trust network, characterized in that it is applied to a zero-trust gateway, and the method comprises: In response to the first notification information sent by the zero-trust server, enter the ticket independent verification state, and send a response information to the zero-trust server; Receive access session traffic and a local access ticket sent by the zero-trust terminal, where the local access ticket is generated after the zero-trust terminal determines that it has conditions for executing a pseudo-login based on the login configuration information sent by the zero-trust server, and the login configuration information includes pseudo-login execution condition information; The local access ticket verification is performed independently, and the access session traffic is forwarded to the service server after the verification passes. 12. The method according to claim 11, characterized in that the method further comprises: In response to the second notification information sent by the zero-trust server, exit the ticket independent verification state and send a response information to the zero-trust server; Receive access session traffic and access tickets sent by a zero-trust terminal, where the access tickets are obtained by the zero-trust terminal applying to the zero-trust server; Apply to the zero-trust server to verify the access ticket, and forward the access session traffic to the business server after the verification passes. 13. An access processing device based on a zero-trust network, characterized in that it is configured on a zero-trust terminal, and the device comprises: an acquisition module configured to acquire login configuration information from a zero-trust server, wherein the login configuration information is generated after detecting that an abnormality occurs in a login service in the zero-trust network, and the login configuration information includes pseudo-login execution condition information; A determination module configured to determine whether the zero-trust terminal has a condition for performing a pseudo login based on the login configuration information; The first processing module is configured to generate a local access ticket if the zero-trust terminal meets the conditions for performing a pseudo login, and send the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway forwards the access session traffic to the business server after independently performing verification of the local access ticket. 14. An access processing device based on a zero-trust network, characterized in that it is configured on a zero-trust server, and the device comprises: A first receiving module is configured to receive indication information sent by the zero-trust management terminal, where the indication information is used to indicate that an abnormality occurs in a login service in the zero-trust network; A notification module, configured to notify the zero-trust gateway to enter a ticket independent verification state in response to the indication information; The second processing module is configured to send login configuration information to the zero trust terminal after receiving the response information returned by the zero trust gateway, and the login configuration information includes pseudo login execution condition information, so that the zero trust terminal sends the access session traffic and the local access ticket to the zero trust gateway based on the login configuration information. After the zero trust gateway independently performs the verification of the local access ticket, it forwards the access session traffic to the business server. 15. An access processing device based on a zero-trust network, characterized in that it is configured on a zero-trust gateway, and the method includes: A response module, configured to enter a ticket independent verification state in response to a first notification message sent by the zero-trust server, and send a response message to the zero-trust server; A second receiving module is configured to receive access session traffic and a local access ticket sent by the zero-trust terminal, wherein the local access ticket is generated after the zero-trust terminal determines that a condition for executing a pseudo-login is met based on the login configuration information sent by the zero-trust server, and the login configuration information includes pseudo-login execution condition information; The third processing module is configured to independently perform verification of the local access ticket and forward the access session traffic to the business server after the verification passes. 16. An electronic device, comprising: one or more processors; A memory for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the access processing method based on a zero-trust network as described in any one of claims 1 to 12. 17. A computer-readable storage medium, characterized in that computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor of a computer, the computer executes the access processing method based on a zero-trust network as described in any one of claims 1 to 12.