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

Abstract

Embodiments of the present application disclose a zero-trust network-based access processing method and device, an electronic device, and a medium. The method applied to a zero-trust terminal comprises: obtaining login configuration information from a zero-trust server, the login configuration information being generated after detecting that a login service in the zero-trust network is abnormal, the login configuration information comprising pseudo-login execution condition information; determining whether the zero-trust terminal has the condition for pseudo-login based on the login configuration information; when the zero-trust terminal has the condition for executing pseudo-login, generating a local access ticket, and sending 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 service server after independently executing verification of the local access ticket. The present application can guarantee normal user network access in the case of login service exception, and can improve the availability of the zero-trust network architecture.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically to an access processing method and apparatus, electronic device, and computer-readable storage medium based on a zero-trust network. Background Technology

[0002] With the rise of emerging technologies such as cloud computing, big data, and the Internet of Things, enterprise internet architecture is shifting from "bounded" to "boundaryless," and traditional firewall-based security boundaries are gradually crumbling. At the same time, zero-trust security is gaining attention as a new concept and architecture for solving cybersecurity problems in the new era. In a zero-trust network, every request for network resources must originate from an authenticated and authorized user.

[0003] 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 login service between the zero-trust terminal and the zero-trust server is assumed to be normal, and the zero-trust gateway cluster is assumed to be healthy. By generating virtual tickets on the zero-trust terminal side, automatically allowing access on the zero-trust server side, and generating tickets by the secure terminal side, traffic is securely sent to the zero-trust gateway in abnormal scenarios. The zero-trust gateway then forwards the traffic to the business server normally, ensuring the continuous use of enterprise network access. However, in scenarios 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

[0004] To address the aforementioned technical problems, embodiments of this application provide access processing methods, access processing devices, electronic devices, computer-readable storage media, and computer program products based on zero-trust networks.

[0005] In a first aspect, embodiments of this application provide an access processing method based on a zero-trust network, applied to a zero-trust terminal. The method includes: obtaining login configuration information from a zero-trust server, wherein the login configuration information is generated after detecting an anomaly 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; and when the zero-trust terminal has the conditions for performing 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, after independently performing the verification of the local access ticket, forwards the access session traffic to the business server.

[0006] Secondly, embodiments of this application provide an access processing device based on a zero-trust network, configured on a zero-trust terminal. The device includes: an acquisition module configured to acquire login configuration information from a zero-trust server, wherein the login configuration information is generated after detecting an anomaly in the login service within the zero-trust network, and the login configuration information includes pseudo-login execution condition information; a determination module configured to determine, based on the login configuration information, whether the zero-trust terminal has the conditions to perform pseudo-login; and a first processing module configured to, if the zero-trust terminal has the conditions to perform pseudo-login, generate a local access ticket and send the access session traffic and the local access ticket to a zero-trust gateway, so that the zero-trust gateway, after independently performing verification of the local access ticket, forwards the access session traffic to a business server.

[0007] Thirdly, this application provides another access processing method based on a zero-trust network, applied to a zero-trust server. The method includes: receiving an indication message sent by a zero-trust management terminal, the indication message indicating an anomaly in the login service within the zero-trust network; responding to the indication message, notifying a zero-trust gateway to enter an independent ticket verification state; and after receiving a response message from the zero-trust gateway, sending login configuration information to a zero-trust terminal, the login configuration information including pseudo-login execution condition information, so that the zero-trust terminal sends access session traffic and local access tickets to the zero-trust gateway based on the login configuration information; and after independently performing verification of the local access tickets, the zero-trust gateway forwards the access session traffic to the business server.

[0008] Fourthly, this application provides another access processing device based on a zero-trust network, configured on a zero-trust server. The device includes: a first receiving module configured to receive indication information sent by a zero-trust management terminal, the indication information indicating an anomaly in the login service within the zero-trust network; a notification module configured to, in response to the indication information, notify the zero-trust gateway to enter an independent ticket verification state; and a second processing module configured to, upon receiving a response from the zero-trust gateway, send login configuration information to a zero-trust terminal, the login configuration information including pseudo-login execution condition information, so that the zero-trust terminal sends access session traffic and local access tickets to the zero-trust gateway based on the login configuration information, and the zero-trust gateway, after independently verifying the local access tickets, forwards the access session traffic to the business server.

[0009] Fifthly, this application provides another access processing method based on a zero-trust network, applied to a zero-trust gateway. The method includes: responding to a first notification message sent by a zero-trust server, entering an independent ticket 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 by the zero-trust terminal after determining that it has the conditions to perform a pseudo-login based on login configuration information sent by the zero-trust server, and the login configuration information includes pseudo-login execution condition information; independently performing the verification of the local access ticket, and forwarding the access session traffic to the business server after successful verification.

[0010] Sixthly, embodiments of this application provide another access processing device based on a zero-trust network, configured on a zero-trust gateway. This device includes: a response module configured to respond to a first notification message sent by a zero-trust server, enter an independent ticket verification state, and send response information to the zero-trust server; a second receiving module configured to receive access session traffic and a local access ticket sent by a zero-trust terminal, wherein the local access ticket is generated by the zero-trust terminal after determining that it meets the conditions for performing a pseudo-login based on login configuration information sent by the zero-trust server, and the login configuration information includes pseudo-login execution condition information; and a third processing module configured to independently perform verification of the local access ticket and, after successful verification, forward the access session traffic to a business server.

[0011] In a seventh aspect, embodiments of this application provide an electronic device, including: one or more processors; and a memory for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the steps in the access processing method based on a zero-trust network as described in any of the preceding claims.

[0012] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer-readable instructions that, when executed by a computer's processor, cause the computer to perform the steps of the access processing method based on a zero-trust network as described in any of the preceding claims.

[0013] Ninthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the access processing method based on a zero-trust network as described in any of the preceding claims.

[0014] In the technical solution provided by the embodiments of this application, in the event of an abnormal login service, the zero-trust server sends login configuration information containing pseudo-login execution condition information to the zero-trust terminal. This allows the zero-trust terminal to determine whether it meets the conditions for performing pseudo-login as required by the zero-trust server based on the login configuration information. If the conditions are met, the terminal sends the access session traffic and the generated local access ticket to the zero-trust gateway. After independently verifying the local access ticket, the zero-trust gateway forwards the access session traffic to the business server. 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 the pseudo-login state and triggering the zero-trust gateway to enter the independent ticket verification state. This ensures that the zero-trust terminal can still transmit access session traffic to the zero-trust gateway, and the zero-trust gateway can also transmit access session traffic to the business server, thereby guaranteeing normal user network access and improving the availability of the zero-trust network architecture.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0016] Figure 1 This is an example of an application scenario based on a zero-trust network.

[0017] Figure 2 This diagram illustrates an exemplary zero-trust network architecture.

[0018] Figure 3 This diagram illustrates an exemplary zero-trust gateway configuration interface.

[0019] Figure 4 This diagram illustrates an exemplary policy management configuration interface.

[0020] Figure 5 This diagram illustrates an exemplary accessible business system configuration interface.

[0021] Figure 6 This diagram illustrates a configuration interface for a trusted application in an exemplary zero-trust network.

[0022] Figure 7 This diagram illustrates an exemplary login interface for a zero-trust client.

[0023] Figure 8 This is a flowchart illustrating an exemplary embodiment of the access processing method based on a zero-trust network in this application;

[0024] Figure 9 Is Figure 8A flowchart of an access processing method based on a zero-trust network, further proposed based on the illustrated embodiment;

[0025] Figure 10 Based on Figure 8 The illustrated embodiment further presents a flowchart of an access processing method based on a zero-trust network;

[0026] Figure 11 This is a flowchart illustrating an access processing method based on a zero-trust network, as shown in another exemplary embodiment of this application;

[0027] Figure 12 This is a flowchart illustrating an access processing method based on a zero-trust network, as shown in another exemplary embodiment of this application;

[0028] Figure 13 This diagram illustrates an access processing interaction flow based on a zero-trust network.

[0029] Figure 14 This is a flowchart illustrating the process of a zero-trust terminal initiating zero-trust network access.

[0030] Figure 15 This is a block diagram illustrating an access processing apparatus based on a zero-trust network, configured on a zero-trust terminal, as shown in an exemplary embodiment of this application.

[0031] Figure 16 This is a block diagram illustrating an access processing apparatus based on a zero-trust network, configured on a zero-trust server, as shown in an exemplary embodiment of this application.

[0032] Figure 17 This is a block diagram illustrating an access processing apparatus based on a zero-trust network, configured on a zero-trust gateway, as shown in an exemplary embodiment of this application.

[0033] Figure 18 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0034] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0035] 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 can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0036] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0037] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0038] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. The terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0039] As described in the background section, with the continuous rise of emerging technologies such as cloud computing, big data, and the Internet of Things, enterprise IT (Internet Technology) architecture is transforming from "bounded" to "boundaryless," and traditional security boundaries are gradually disintegrating. The ongoing advancement of new infrastructure represented by 5G (fifth-generation communication technology) and the Industrial Internet will further accelerate this "boundaryless" evolution. Simultaneously, zero-trust security is gradually entering the public eye, becoming a new concept and architecture for solving cybersecurity problems in the new era.

[0040] Zero Trust is a cybersecurity protection concept that breaks the default "trust." In simple terms, it means "continuous verification, never trust." The core idea of ​​Zero Trust is that, by default, no person, thing, or event inside or outside the enterprise is trustworthy. Any person, thing, or event attempting to access the network and its resources should be verified before authorization.

[0041] To put it simply, Zero Trust acknowledges the shortcomings of traditional perimeter security architectures in network environments. It considers all hosts, regardless of their location on the network, to be internet hosts, and the network they reside on, whether the internet or an internal network, to be a dangerous network fraught with threats. Based on this, Zero Trust networks, by default, distrust any person, device, or system inside or outside the enterprise network. It rebuilds the trust foundation of access control based on identity authentication and authorization, thereby ensuring trustworthy identities, devices, applications, and links.

[0042] Figure 1 This is an exemplary application scenario diagram based on zero-trust networks. This scenario includes a zero-trust network security service provider, an access subject, and an access object. The access subject refers to the party initiating access in the network; it is a digital entity composed of a single or combined element such as a person, device, application, or service. The access object refers to the party being accessed in the network. The zero-trust network security service provider provides a unified entry point for access subjects to request resources from the access object through the network, and provides authentication operations for this unified entry point. Only network requests that pass authentication can be forwarded by the proxy client to the zero-trust gateway, which then proxies access to the actual business system.

[0043] Figure 2 The diagram illustrates 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. The zero-trust terminal 230 is equipped with trusted applications, zero-trust clients, and proxy clients, while the zero-trust server 220 is equipped with service processes such as policy services, inspection services, invoice centers, and authentication services.

[0044] It's important to understand that the Zero Trust Management Terminal 210 provides an interface for configuring the Zero Trust network, such as configuring Zero Trust access control policies and the Zero Trust Gateway 240. A Zero Trust access control policy consists of information about processes accessible to the user (i.e., trusted applications, which are application carriers of business resources accessible to terminals authorized by the Zero Trust Management Terminal, identified by application name, application MD5, signature information, etc.) and accessible business sites (i.e., reachable areas). With permissions granted, a user can access any reachable area through any trusted application. Therefore, the granularity of the Zero Trust access control policy is the logged-in user; it can be understood that the Zero Trust access control policy sets different Zero Trust policies for different logged-in users.

[0045] For example in Figure 3The Zero Trust Gateway configuration interface shows how to query, add, or delete Zero Trust Gateways in a Zero Trust Network. When adding a Zero Trust Gateway, information such as the gateway name, gateway settings, the IP address (Internet Protocol) field that prioritizes access to the Zero Trust Gateway, and the creation time are provided.

[0046] For example, in Figure 4 The policy management configuration interface, as shown, allows for separate configuration of trusted applications and business systems for different user accounts. The trusted application configuration allows you to select the operating system to which the application is compatible, and also provides convenient configuration options to choose from projects that can be adapted to any application. Similarly, the business system configuration also provides convenient configuration options to choose from projects that can be adapted to all URLs (Uniform Resource Locators).

[0047] For example, in Figure 5 The interface for configuring accessible business systems shows that you can add accessible business systems in the zero-trust network by adding IP ranges or domain names. The added accessible business systems can adapt to all ports or specified ports. Administrators can also configure different zero-trust gateways for each accessible business system; for example, after configuring the internal network resources of the business system, they can also configure the accessible zero-trust gateway.

[0048] Figure 6 The diagram illustrates the configuration interface for trusted applications in a zero-trust network. It shows that the configuration of trusted applications includes the process name, signature information, version, and the contents of the process MD5 and SHA256 hashes.

[0049] As shown in the configuration interface above, the zero-trust access control policy configuration uses a combination of user account, trusted application, and target business system to achieve traffic filtering. It supports wildcard domains, IP ranges, and multiple ports, and allows users to inherit and extend their organizational structure.

[0050] The Zero Trust server 220 uses a policy control engine to securely schedule business traffic, authorizing at a granular level of user-zero trust terminal-zero trust client-trusted application. The Zero Trust server 220 is responsible for verifying user identity, verifying the hardware information and device security status of the Zero Trust terminal 230, and detecting the security of trusted applications. The Zero Trust server 220 can also periodically send files for inspection to the cloud inspection service center. If the cloud inspection service center identifies a malicious process, it will notify the Zero Trust client to perform asynchronous blocking operations.

[0051] The Zero Trust client is a security application installed on the Zero Trust terminal 230. It 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, it requests inspection from the Zero Trust server 220.

[0052] Figure 7 The diagram illustrates an example login interface for a zero-trust client. It shows that in a zero-trust office application scenario, end users can log in to the zero-trust client via QR code or account login to access zero-trust office functions. After logging in, end users can view details of trusted applications configured and issued by the zero-trust management terminal. Based on user-level policies issued by the zero-trust management terminal, end users can access the business systems configured by the administrator through specified trusted applications.

[0053] A proxy client is a terminal agent deployed on a controlled device that initiates secure access. It is responsible for initiating requests for trusted authentication of the access subject. If the identity is verified as trustworthy, an encrypted access connection can be established with the zero-trust gateway 240. It also serves as the enforcement point for access policy control. The proxy client can hijack the service traffic of the zero-trust terminal 230 through a virtual network interface card and, after authentication by the zero-trust client, forward the access request to the zero-trust gateway 240.

[0054] The Zero Trust Gateway 240 is deployed at the entry point for applications and data resources, responsible for verifying and forwarding every session request that accesses resources.

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

[0056] It's also important to understand that cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to enable data computation, storage, processing, and sharing. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of numerous computers, allowing various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" appear infinitely scalable and can be accessed, used on demand, and expanded at any time.

[0057] Still refer to Figure 2 Under a zero-trust network architecture, the overall process for a zero-trust terminal to access a service site is as follows:

[0058] The accessing entity initiates a network request for the accessing object through a trusted application. After the zero-trust client intercepts the network request through the proxy client, it sends an authentication request to the zero-trust client. That is, the proxy client requests the credentials for the current network request from the zero-trust client. The request parameters include, for example, the source IP or domain name, the source port, the destination IP or domain name, the destination port, and the process PID (Process Identification) of the trusted application.

[0059] The Zero Trust client collects the MD5 hash, process path, last modified time, copyright information, and signature information of the trusted application's process by sending the process PID via the proxy client. This, along with the source IP or domain name, source port, destination IP or domain name, and destination port of the network request transmitted by the proxy client, is then sent to the Zero Trust server to request a ticket. If the request is successful, the server sends the ticket, the maximum number of times the ticket can be used, and the ticket's validity period as a response to the proxy client. It should be noted that this ticket can be understood as authorization information issued by the Zero Trust server for a single network request, used to identify the authorization status of this network request. Under normal login service conditions, each network request requires authorization from the Zero Trust server.

[0060] The proxy client sends an HTTPS request to the Zero Trust gateway, including the network request credentials (ticket) passed by the Zero Trust client in the Authorization header field. Upon receiving the request, the Zero Trust gateway parses the ticket from the header field and requests ticket verification from the Zero Trust server. If verification is successful, the Zero Trust gateway and the proxy client successfully establish a connection. The proxy client then sends the original network request to the Zero Trust gateway, which forwards it to the corresponding business server, proxying the actual application network access. If verification fails, the connection between the proxy client and the Zero Trust gateway is interrupted. For traffic from applications outside the Zero Trust policy accessing specific sites, the proxy client directly initiates a network access request to the target business server to achieve a direct connection.

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

[0062] 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 a zero-trust server crashing, or an anomaly in the IAM (Identity and Access Management) or login service within the zero-trust server, the login service between the zero-trust terminal and the zero-trust server is assumed to be normal, and the zero-trust gateway cluster is assumed to be healthy. By generating virtual tickets on the zero-trust terminal side, automatically allowing access on the zero-trust server, or generating tickets by the secure terminal, traffic is securely sent to the zero-trust gateway in abnormal scenarios. The zero-trust gateway then forwards the traffic to the business server normally, ensuring the continuous use of the user's network access. However, in scenarios 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.

[0063] To address the above-mentioned technical problems, embodiments of this application provide access processing methods, devices, electronic devices, computer storage media, and computer program products based on zero-trust networks. These embodiments will be described in detail below.

[0064] Please see Figure 8 , Figure 8 This is a flowchart illustrating an exemplary embodiment of the access processing method based on a zero-trust network.

[0065] 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 be found in [reference needed]. Figure 2The network architecture is shown. It should also be noted that the method mentioned in this embodiment is specifically executed by a zero-trust terminal in a zero-trust network, for example... Figure 2 The zero-trust terminal 230 shown in the figure refers to the user terminal, which is configured with trusted applications, zero-trust clients and proxy clients.

[0066] like Figure 8 As shown, the method applied to zero-trust terminals includes S810-S830, which are described in detail below:

[0067] S810, obtain login configuration information from the zero trust server. This login configuration information is generated after an anomaly is detected in the login service in the zero trust network. This login configuration information includes pseudo login execution condition information.

[0068] An error in the login service within a zero-trust network can cause user network access failures. Therefore, when a user network access failure is detected in a zero-trust network, it is possible to further investigate whether the login service is experiencing an error. For example, a zero-trust server outage, or an error in the IAM service or login service within the zero-trust server, can all lead to login service errors in a zero-trust network.

[0069] When an anomaly is detected in the login service within the zero-trust network, network access remediation needs to be initiated to ensure the continued availability of network access. Specifically, the zero-trust server sends login configuration information to the zero-trust terminal. This login configuration information includes pseudo-login execution conditions, enabling the zero-trust terminal to enter a pseudo-login state under the conditions required by the zero-trust server.

[0070] Understandably, pseudo-login refers to a user's login state in a zero-trust terminal, which differs from the normal login state. Specifically, the normal login state is as follows: Figure 2 As illustrated in the process diagram, each network access initiated by a trusted application in a zero-trust terminal is intercepted by the zero-trust client. The proxy client then sends an authentication request to the zero-trust client to obtain the access ticket that the zero-trust client requested from the zero-trust server. It then sends an HTTPS request to the zero-trust gateway, carrying the access ticket in the Authorization header field. The zero-trust gateway requests verification of the access ticket from the zero-trust server. If verification is successful, the zero-trust gateway and the proxy client successfully establish a connection. The proxy client then sends the original network request to the zero-trust gateway, which forwards it to the corresponding business server, proxying the actual application network access. If verification fails, the connection between the proxy client and the zero-trust gateway is interrupted. For traffic from applications outside the zero-trust policy accessing specific sites, the proxy client directly initiates a network access request to the target business server to achieve a direct connection.

[0071] In this embodiment, the pseudo-login state refers to a situation where a user who has previously logged into the Zero Trust client, in the event of a login service anomaly, uses a locally generated local access ticket instead of the access ticket requested from the Zero Trust server. After sending the local access ticket to the Zero Trust gateway, Zero Trust no longer requests ticket verification from the Zero Trust server but performs independent verification of the local access ticket, thus not using the login service function of the Zero Trust server. Therefore, in scenarios where there is a login service anomaly in the Zero Trust network, putting the Zero Trust terminal into a pseudo-login state, and simultaneously coordinating with the Zero Trust gateway to place it in a state of ignoring ticket verification (i.e., independently verifying the local access ticket of the Zero Trust terminal), ensures that access traffic is transmitted to the Zero Trust gateway and then forwarded normally to the business server through the Zero Trust gateway, guaranteeing the continuous use of the Zero Trust function and improving the overall availability of the Zero Trust network.

[0072] Zero-trust servers detect login service anomalies in a zero-trust network through either automatic or manual detection. Automatic detection refers to the zero-trust server identifying login service anomalies using pre-defined procedures, such as detecting its own downtime or that its login service process has been suspended for an extended period. No restrictions are placed on this. Manual detection involves the zero-trust server receiving notifications from the zero-trust management system. These notifications are sent by the management system based on the login service detection results and when an anomaly is determined to have occurred.

[0073] The Zero Trust server obtains login configuration information from the Zero Trust server in two ways: actively and passively. Active acquisition means that the Zero Trust terminal pulls pseudo-login configuration information from the Zero Trust server before logging in with a user account. This user account is understood to be the login account used by the user on the Zero Trust terminal to log in with the Zero Trust client. Passive acquisition means that the Zero Trust server pushes login configuration information to the Zero Trust terminal.

[0074] S820 determines whether a zero-trust terminal has the conditions to perform a fake login based on login configuration information.

[0075] Since the login configuration information obtained by the zero-trust terminal includes information on the conditions for performing a fake login, the zero-trust terminal can determine whether it has the conditions to perform a fake login based on this login configuration information. If it determines that it has the conditions to perform a fake login, it enters the fake login state. If it determines that it does not have the conditions to perform a fake login, it means that in the current scenario of abnormal login service, the continuous use of the zero-trust function cannot be guaranteed.

[0076] For example, the conditions for a zero-trust terminal to perform a fake login include that the user initiating the current network access is a user who has previously logged in to the zero-trust terminal. In other words, only users who have previously logged into the zero-trust terminal can enter the fake login state; otherwise, they cannot. This ensures network security after the zero-trust terminal enters the fake login state. Based on this, the zero-trust terminal searches for historical login information and compares the found historical login information with the received login configuration information. If the historical login information meets the conditions for performing a fake login contained in the login configuration information, then the zero-trust terminal is determined to have the conditions to perform a fake login.

[0077] When the zero-trust terminal has the conditions to perform a pseudo login, the S830 generates a local access ticket and sends the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway can forward the access session traffic to the business server after independently performing the verification of the local access ticket.

[0078] When a zero-trust terminal has the conditions to perform a pseudo login, the zero-trust terminal enters the pseudo login state. The specific operation is as follows: first, a local access ticket is generated, and then the access session traffic and the local access ticket are sent to the zero-trust gateway so that the zero-trust gateway can independently perform the verification of the local access ticket. After the verification is successful, the access session traffic is forwarded to the corresponding business server.

[0079] Since local access tickets are generated locally on the zero-trust terminal without the involvement of the zero-trust server, the generation of local access tickets is not affected even if the login service in the zero-trust network is abnormal. Furthermore, for the zero-trust gateway, the verification of local access tickets does not require the involvement of the zero-trust server, thus it can also adapt to situations where the login service is abnormal in the zero-trust network. For example, a local access ticket includes at least one of the following: a unique user identifier, an application process hash, the local generation time of the ticket, and the ticket validity period; these are not limited here.

[0080] Access session traffic refers to traffic data related to access to business resources on a business server initiated by a zero-trust terminal through a trusted application. Therefore, after forwarding access session traffic to the corresponding business server, the zero-trust gateway can obtain a response from the business server, which may include, for example, the business resources accessed by the zero-trust terminal. The gateway then returns this response to the zero-trust terminal, thereby ensuring normal network access for users even in scenarios where login service is abnormal.

[0081] It should be noted that the zero-trust terminal sends access session traffic and local access tickets to the zero-trust gateway through the proxy client process after it is started.

[0082] As can be seen from the above, 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, so that the zero-trust terminal enters the pseudo-login state and the zero-trust gateway enters the independent ticket verification state. This allows the zero-trust terminal to still transmit access session traffic to the zero-trust gateway, and the zero-trust gateway to transmit access session traffic to the business server, thereby ensuring normal user network access and improving the availability of the zero-trust network architecture.

[0083] In one exemplary embodiment, the process of generating a local access ticket includes the following steps:

[0084] Generate a ticket payload and a ticket signature based on the ticket content information. The ticket generation information includes at least one of the following: user unique identifier, ticket generation time, ticket validity period, and trusted application ciphertext. Generate a local access ticket based on the ticket version identifier, ticket payload, and ticket signature.

[0085] 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 for transmitting claims between web application environments. It specifies the structure of data transmission; a complete JWT consists of three segments, each connected by a period (.). Therefore, the typical 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 three-segment, including a ticket version identifier, a ticket payload, and a ticket signature.

[0086] The ticket version identifier needs to be distinguished from the version identifier of access tickets in normal login service scenarios, in order to indicate that this is an access ticket generated in a network firefighting scenario and is verified independently by the zero-trust gateway.

[0087] The bill payload, also known as the bill content, is generated based on the bill content information. For example, it can be generated using the user's unique identifier, trusted application ciphertext, bill generation time, and bill validity period. The bill validity period can be set to a default value. The process of generating the bill payload can be expressed as follows:

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

[0089] In the above formula, uid represents the user's unique identifier, 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.

[0090] The ticket signature is used to verify whether the local access ticket has been altered during 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. Then, the encoded ticket content information is encrypted using the key to obtain ciphertext content. Finally, the ciphertext content is encoded using the preset encoding method to obtain the ticket signature. The process of generating a ticket signature can be represented by the following formula:

[0091] Base64UrlEncode(hmac_sha256(Base64UrlEncode(ticket content information), key))

[0092] In the above formula, the document content information is also the content information needed to generate the document payload. Therefore, the encoded document content (Base64UrlEncode) can be understood as the document payload. Using the hmac_sha256 encryption algorithm and a key to encrypt the encoded document content to obtain ciphertext, the ciphertext is then encoded using Base64UrlEncode to obtain the document signature.

[0093] For example, the key agreed upon between the zero-trust terminal and the zero-trust gateway can be generated using the key derivation function PBKDF2. Understandably, PBKDF2 primarily derives the key through a pseudo-random function. The length of the derived key is essentially unlimited, but it can be configured to undergo multiple calculations, using plaintext and a salt value as parameters to finally generate the key. Understandably, adding salt to the generated key increases its resistance to attacks. The parameters and salt value used in the iterations of PBKDF2 must be negotiated in advance by both the zero-trust terminal and the zero-trust gateway.

[0094] Corresponding to the aforementioned local access ticket generation process, the zero-trust gateway independently executes the local access ticket verification logic as follows:

[0095] First, using the first two segments of information from the local access ticket—the ticket version identifier and the ticket payload—a signature value is calculated using the same algorithm and key. This signature value is then compared to the third segment of information from the local access ticket—the ticket signature. If they match, the verification passes, indicating that the local access ticket was not altered during transmission to the zero-trust gateway, and the zero-trust network is secure. The access session traffic is then forwarded to the corresponding business server. Conversely, if they do not match, the verification fails, indicating that the local access ticket was altered during transmission to the zero-trust gateway, posing a security risk to the zero-trust network. Therefore, the zero-trust gateway will not forward the access session to the business server to ensure the security of business resources within the zero-trust network.

[0096] Figure 9 Is Figure 8 A flowchart of an access processing method based on a zero-trust network, further proposed based on the illustrated embodiment, is shown. Figure 9 As shown, the process of determining whether a zero-trust terminal has the conditions to perform a fake login based on login configuration information includes S821-S822, and the method also includes S840, which are described in detail below:

[0097] S821, detect the pseudo login execution switch information contained in the login configuration information. This 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.

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

[0099] It is important to understand that enabling the pseudo login function in a zero-trust network requires the zero-trust server 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 must 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.

[0100] S822, if the pseudo login execution switch information indicates that pseudo login is enabled, then 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 they do, then determine that the zero-trust terminal has the conditions to perform pseudo login.

[0101] If the pseudo login execution switch information indicates that pseudo login is enabled, it means that the zero-trust network has enabled 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 if the conditions are met can it be determined that the zero-trust terminal has the conditions to execute pseudo login.

[0102] Login condition parameters can be understood as relevant parameters obtained from the historical login information of the zero-trust terminal in accordance with the pseudo-login execution condition information. For example, if the pseudo-login execution condition information requires that the most recent valid login time is before a specified time, the corresponding login condition parameters would include the login time of the most recent valid login of the same user on the zero-trust terminal. The pseudo-login execution condition information also requires that the login-related information of the most recent valid login has been backed up in the encrypted persistent database on the zero-trust terminal's local machine; the corresponding login condition parameters would include the information related to the user's most recent valid login stored in the encrypted persistent database on the zero-trust terminal's local machine.

[0103] For example, login-related information from a user's most recent valid login includes the user's unique identifier, username, login ticket, etc., without further restrictions. This login ticket is understood as an encrypted string assigned to the user by the Zero Trust server after successful login to the Zero Trust client, representing the user's login authorization information, such as user information and authorization validity period. The persistent library is understood as a storage medium stored on the local disk or data files of the Zero Trust terminal, converted from in-memory data structures or object models, and can be implemented using encrypted files, embedded databases, etc.

[0104] In one exemplary implementation, the pseudo-login execution condition information contained in the login configuration information can be determined by the following process:

[0105] Retrieve historical login information from zero-trust terminals;

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

[0107] As mentioned earlier, to ensure security in the zero-trust network during pseudo-login, the user initiating the current network access must be a user who has previously logged in on the zero-trust client. The zero-trust server has already authorized the user's identity during previous logins. Therefore, it needs to obtain the historical login information from the zero-trust terminal and use this information as a login condition parameter to determine whether the current user has previously logged in. If the most recent valid login time is determined to be before the time specified in the pseudo-login conditions, and the login information for the most recent valid login is persistently stored locally, then the login condition parameters in the zero-trust terminal meet the pseudo-login execution condition information included in the login configuration information. Therefore, the zero-trust terminal is deemed capable of performing pseudo-login.

[0108] To put it simply, a zero-trust terminal is capable of performing a fake login if: the fake login switch issued by the zero-trust server is turned on; a user has previously logged into the zero-trust terminal; the last login occurred before a specified time; and login-related information, such as the user's unique identifier, username, and login ticket, has been backed up in the terminal's local encrypted persistent database. If these conditions are met, the zero-trust terminal directly enters the fake login state.

[0109] S840 performs regular login when the zero-trust terminal does not have the conditions to perform fake login; if regular login is successful, it stores the user information and login ticket of this login and enters the regular login state.

[0110] If a zero-trust terminal lacks the conditions to perform a fake login, it means the terminal cannot enter the fake login state. In this case, a regular login is performed to determine if the login service in the zero-trust network has been restored. If the regular login is successful, the user information and login ticket are stored, and the terminal enters the regular login state. If the regular login fails, it indicates that network access cannot be achieved, and a notification message indicating a network anomaly can be generated.

[0111] Understandably, regular login refers to the user login method performed under normal login service conditions. Regular login may include, for example, QR code login, multi-factor login, or account password login. During regular login, after a user successfully logs into the Zero Trust client, the Zero Trust server assigns an encrypted string (i.e., login credential) to the user, representing the user's login authorization information. In other words, the Zero Trust server has authorized the user to log in to the Zero Trust terminal. After a successful regular login, the user information and login ticket for this login are stored locally on the Zero Trust terminal.

[0112] It should be noted that the network access process for zero-trust terminals in normal login mode is described in the following article. Figure 2 The process illustrated will not be repeated here.

[0113] As can be seen from the above, 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 independent ticket verification state, it can be ensured that when the zero-trust terminal obtains the login configuration information, the zero-trust network has already prepared the conditions for the zero-trust terminal to execute pseudo login, thereby ensuring that the zero-trust terminal can successfully 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, it switches to executing regular login, and when the login is successful, by storing the user information and login ticket of this login, and by attempting to perform regular login, it can ensure that the normal network access process can be restored in a timely manner when the login service is restored, and can also further improve the availability of the zero-trust network.

[0114] Figure 10 Based on Figure 8 The illustrated embodiment further presents a flowchart of an access processing method based on a zero-trust network. (See flowchart for example.) Figure 10 As shown, the method is in Figure 8 The process shown also includes the S850, which is detailed below:

[0115] S850, upon receiving a notification from the zero-trust server instructing it to exit the fake login, stops executing S830 to exit the fake login state; or, if it detects that the duration of the fake login state exceeds the maximum duration of the fake login contained in the login configuration information, it exits the fake login state by automatically logging out the login account and clearing the local access ticket.

[0116] Considering that if a zero-trust terminal remains in a fake login state for an extended period of time, it may pose a security risk to the zero-trust network. Therefore, this embodiment further provides a solution for the zero-trust terminal to exit the fake login state, thereby ensuring the security of the zero-trust network.

[0117] One approach is for the zero-trust server to send a notification to the zero-trust terminal instructing it to exit the pseudo-login state after detecting that the login service has resumed. For example, the zero-trust server first notifies the zero-trust gateway to cancel the independent ticket verification state, and then, after restoring the normal ticket verification state, sends a notification to the zero-trust terminal instructing it to exit the pseudo-login state. This is equivalent to sending a switch message to the zero-trust terminal instructing it to exit the pseudo-login state. Upon receiving this notification, the zero-trust terminal stops generating a local access ticket and forwards the local access ticket and access session traffic to the zero-trust gateway, thereby exiting the pseudo-login state.

[0118] Another approach 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 pseudo-login execution switch information, but also information on the maximum duration of pseudo-login. This information is used to specify the maximum duration of the continuous pseudo-login state of the zero-trust terminal. Therefore, if the zero-trust terminal detects that the duration of its continuous pseudo-login state exceeds the maximum duration of pseudo-login, it will automatically log out of the login account and clear the local access ticket to exit the pseudo-login state.

[0119] After exiting the pseudo-login state, if a zero-trust terminal still needs to use the zero-trust capabilities of the zero-trust network to access business resources, it must first perform a regular login. And after a successful regular login, it should then proceed according to... Figure 2 The example access processing flow requests the access ticket required for each access from the Zero Trust server, and the access ticket must be verified by the Zero Trust gateway before normal access to business resources can be granted. This ensures that the Zero Trust function of the Zero Trust network can be used sustainably in real-world application scenarios.

[0120] Figure 11 This is a flowchart illustrating an access processing method based on a zero-trust network, as shown in another exemplary embodiment of this 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 still refers to... Figure 2 The network architecture is shown. It should also be noted that the method mentioned in this embodiment is specifically executed by a zero-trust server in a zero-trust network, for example... Figure 2 The diagram shows a zero-trust server, 220.

[0121] like Figure 11 As shown, the access processing method based on zero-trust networks includes the following steps:

[0122] S1110, Receive indication information sent by the zero trust management terminal, which is used to indicate that the login service in the zero trust network is abnormal;

[0123] S1120, in response to the instruction message, notifies the zero-trust gateway to enter the independent ticket verification state;

[0124] S1130: After receiving the response information returned by the zero-trust gateway, the zero-trust terminal 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 access session traffic and local access ticket to the zero-trust gateway based on the login configuration information. After independently performing the verification of the local access ticket, the zero-trust gateway forwards the access session traffic to the business server.

[0125] As can be seen from the above, after receiving the indication from the Zero Trust Management Terminal that the login service in the Zero Trust network is abnormal, the Zero Trust server responds to the indication by notifying the Zero Trust Gateway to enter the independent ticket verification state. After receiving the response information returned by the Zero Trust Gateway, it indicates that the Zero Trust network has the conditions to perform pseudo login. Therefore, it sends login configuration information to the Zero Trust terminal so that the Zero Trust terminal can determine that it has the conditions to perform pseudo login based on the pseudo login execution condition information contained in the login configuration. Then, it sends the access session traffic and 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. This ensures the continuous use of the Zero Trust function even in the case of login service abnormality, and improves the overall availability of the Zero Trust network.

[0126] In another exemplary embodiment, in Figure 11 Based on the illustrated embodiment, the access processing method based on a zero-trust network further includes the following steps:

[0127] 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;

[0128] S1150, after receiving the response information returned by the zero-trust gateway, sends a notification information to the zero-trust terminal instructing it to exit the fake login state, so that the zero-trust terminal exits the fake login state.

[0129] As can be seen from the above, after receiving the specified notification message sent by the Zero Trust management terminal, the Zero Trust server first notifies the Zero Trust gateway to cancel the independent ticket verification state. After receiving the response information returned by the Zero Trust gateway, it sends a notification message to the Zero Trust terminal instructing it to exit the pseudo login state, thereby enabling the Zero Trust terminal to exit the pseudo login state. This provides a solution to enable the Zero Trust terminal to exit the pseudo login state, thus avoiding the security risks that may occur if the Zero Trust terminal remains in the pseudo login state for a long time.

[0130] 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 described 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.

[0131] Figure 12 This is a flowchart illustrating an access processing method based on a zero-trust network, as shown in another exemplary embodiment of this 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 still refers to... Figure 2 The network architecture is shown. It should also be noted that the method mentioned in this embodiment is specifically executed by a zero-trust gateway in a zero-trust network, for example... Figure 2 The diagram shows a zero-trust gateway 240.

[0132] like Figure 12 As shown, the access processing method based on zero-trust networks includes the following steps:

[0133] S1210, in response to the first notification message sent by the zero-trust server, enter the independent verification state of the ticket and send a response message to the zero-trust server;

[0134] S1220, Receive access session traffic and local access ticket sent by the zero-trust terminal. The local access ticket is generated by the zero-trust terminal after determining that it has the conditions to perform pseudo login based on the login configuration information sent by the zero-trust server. The login configuration information includes pseudo login execution condition information.

[0135] S1230 independently performs local access ticket verification and forwards access session traffic to the business server after successful verification.

[0136] As can be seen from the above, after receiving the first notification information sent by the Zero Trust server, the Zero Trust gateway responds by entering an independent ticket verification state and returns a response information to the Zero Trust server. Upon receiving the response information from the Zero Trust gateway, the Zero Trust server sends login configuration information to the Zero Trust terminal. This allows the Zero Trust terminal to determine if it meets the conditions for performing a fake login based on the fake login execution conditions contained in the login configuration, and then sends its access session traffic and local access ticket to the Zero Trust gateway. Upon receiving the access session traffic and local access ticket from the Zero Trust terminal, the Zero Trust gateway independently performs the verification of the local access ticket. After successful verification, it forwards the access session traffic to the corresponding business server. This ensures that even in scenarios where the login service is abnormal, the Zero Trust terminal can still access business resources normally, thereby guaranteeing the sustainable use of the Zero Trust function and improving the overall availability of the Zero Trust network.

[0137] In another exemplary embodiment, in Figure 12 Based on the illustrated embodiment, the access processing method based on a zero-trust network further includes the following steps:

[0138] S1240, in response to the second notification message sent by the zero-trust server, exit the independent verification state of the ticket and send a response message to the zero-trust server;

[0139] S1250, receives access session traffic and access ticket sent by the zero-trust terminal, the access ticket being obtained by the zero-trust terminal from the zero-trust server;

[0140] S1260 requests the zero-trust server to verify the access ticket, and forwards the access session traffic to the business server after the verification is successful.

[0141] As can be seen from the above, after receiving the specified notification message sent by the Zero Trust management terminal, the Zero Trust server notifies the Zero Trust gateway to cancel the independent ticket verification state. The Zero Trust gateway responds to the second notification message sent by the Zero Trust server, exits the independent ticket verification state, and sends a response message to the Zero Trust server. Upon receiving the response message from the Zero Trust gateway, the Zero Trust server sends a notification message to the Zero Trust terminal instructing it to exit the pseudo-login state. If the Zero Trust gateway subsequently receives access session traffic and access tickets from the Zero Trust terminal, it indicates that the Zero Trust terminal is performing normal Zero Trust access. This access ticket was obtained by the Zero Trust terminal from the Zero Trust server for this network access. Therefore, the Zero Trust gateway requests verification of the access ticket from the Zero Trust server, and after successful verification, forwards the access session traffic to the business server. This provides a solution to exit the pseudo-login state for the Zero Trust terminal, avoiding potential security risks caused by the Zero Trust terminal remaining in a pseudo-login state for an extended period, while also allowing switching to normal Zero Trust access after exiting the pseudo-login state.

[0142] 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 described 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.

[0143] To further understand the content described in the above embodiments, Figure 13 This diagram illustrates an access processing interaction flow based on a zero-trust network.

[0144] like Figure 13As shown, the Zero Trust management terminal first sends an instruction to the Zero Trust server to indicate that an abnormal login service has been detected. The Zero Trust server responds normally and then notifies the Zero Trust gateway to enter the independent ticket verification state. After entering the independent ticket verification state, the Zero Trust gateway returns a response to the Zero Trust server. Subsequently, the Zero Trust server enables the pseudo-login switch and generates login configuration information. A prerequisite for a Zero Trust terminal to initiate network access is that a user has already logged in. Before logging in, the Zero Trust terminal retrieves the login configuration information from the Zero Trust server, which responds by sending the login configuration information back to the Zero Trust terminal. Based on the login configuration information, the Zero Trust terminal determines that it has entered the pseudo-login state, 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 is in the independent ticket verification state, after the local access ticket is verified and passes verification, the Zero Trust gateway directly forwards the access session flow to the corresponding business server in the business system. The business system responds by returning the business resources that the Zero Trust terminal wants to access.

[0145] When the login service is restored, the Zero Trust management terminal sends a specified notification message to the Zero Trust server to inform it that the login service has been restored. The Zero Trust server responds normally and then notifies the Zero Trust gateway to cancel the independent ticket verification status. After canceling the independent ticket verification status, the Zero Trust gateway returns a response to the Zero Trust server. Subsequently, the Zero Trust server disables the fake login switch. If a Zero Trust terminal detects that the duration of its own fake login exceeds the maximum duration set in the login configuration information, it automatically logs out the current login account and clears the previous login ticket.

[0146] When a zero-trust terminal attempts to access the network again, it needs to log in again and request instructions from the zero-trust server before logging in, indicating whether to perform a fake login. The zero-trust service responds by indicating that a fake login should not be performed. The zero-trust terminal then sends the raw session traffic and access ticket to the zero-trust gateway. Since the access ticket is obtained by the zero-trust terminal from the zero-trust server based on the normal zero-trust access process, the zero-trust gateway needs to request verification of the access ticket from the zero-trust server. After successful verification, the gateway forwards the raw session traffic to the corresponding business server in the business system.

[0147] Figure 14 This is a flowchart illustrating the process of a zero-trust terminal initiating zero-trust network access. For example... Figure 14 As shown, after the zero-trust management terminal issues the fake login switch, that is, as... Figure 13The Zero Trust management terminal, as shown, instructs the Zero Trust server to enable the pseudo-login switch, which will enable Zero Trust terminals to access the network in a pseudo-login state. Specifically, before logging in, the Zero Trust terminal retrieves login configuration information from the Zero Trust server. If the retrieval is successful and the Zero Trust terminal is instructed to enter the pseudo-login state, the server will determine whether the conditions for performing pseudo-login are met based on historical login information, i.e., whether pseudo-login is possible.

[0148] If the retrieved login configuration information does not indicate a fake login, or if the historical login information of the zero-trust terminal indicates that a fake login is not possible, then a regular login is executed. If the regular login fails, it means that the zero-trust network access function cannot be used, and therefore the entire access process ends. If the regular login is successful, the login ticket needs to be stored, and zero-trust network access is initiated, in which case the zero-trust network access is executed using the regular process. If the historical login information indicates that a fake login is possible, zero-trust network access is also initiated, in which case the zero-trust network access is executed using the fake login process.

[0149] based on Figure 13 and Figure 14 As can be seen, in the event of an abnormal login service, 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. At the same time, it links the zero-trust gateway to put it into a state of ignoring ticket verification, i.e., a state of independent ticket verification. This ensures that even under extremely harsh conditions, the zero-trust terminal can securely transmit session traffic to the zero-trust gateway, and the zero-trust gateway can also forward session traffic to the business server normally, ensuring the continuous use of the zero-trust function and improving the overall availability of the zero-trust network.

[0150] Figure 15 This is a block diagram illustrating an access processing apparatus based on a zero-trust network, which is configured on a zero-trust terminal and includes an acquisition module 1510, a determination module 1520, and a first processing module 1530.

[0151] The module 1510 is configured to obtain login configuration information from the zero-trust server. The login configuration information is generated after an anomaly is detected in the login service in the zero-trust network. The login configuration information includes pseudo-login execution condition information.

[0152] The module 1520 is configured to determine whether a zero-trust terminal has the conditions to perform a fake login based on the login configuration information.

[0153] The first processing module 1530 is configured to generate a local access ticket if the zero-trust terminal has the conditions to perform 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 can forward the access session traffic to the business server after independently performing the verification of the local access ticket.

[0154] In another exemplary embodiment, the determining module 1520 is further configured to perform the following steps:

[0155] The system detects the fake login execution switch information contained in the login configuration information. This fake login execution switch information is generated by the Zero Trust server after it notifies the Zero Trust gateway to enter the independent ticket verification state.

[0156] If the pseudo login execution switch information indicates that pseudo login is enabled, then 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 they do, then it is determined that the zero-trust terminal has the conditions to execute pseudo login.

[0157] In another exemplary embodiment, the determining module 1520 is further configured to perform the following steps:

[0158] Retrieve historical login information from zero-trust terminals;

[0159] If the login time of the most recent valid login is determined to be before the time specified in the pseudo-login execution condition information based on historical login information, and the login-related information of the most recent valid login has been persistently stored locally, then the login condition parameters in the zero-trust terminal are determined to satisfy the pseudo-login execution condition information contained in the login configuration information.

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

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

[0162] The bill payload and bill signature are generated based on the bill content information. The bill generation information includes at least one of the following: user unique identifier, bill generation time, bill validity period, and trusted application ciphertext.

[0163] A local access ticket is generated based on the ticket version identifier, ticket payload, and ticket signature.

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

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

[0166] The content information of the ticket is encoded using a preset encoding method, and the encoded content information is then encrypted using a key to obtain ciphertext content.

[0167] The encrypted content is encoded using a preset encoding method to obtain the ticket signature.

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

[0169] In another exemplary embodiment, the apparatus further includes an exit module 1550, which is configured to, upon receiving a notification from the zero-trust server indicating that the pseudo-login should be exited, 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 to exit the pseudo-login state; or, if it is detected that the duration of the pseudo-login state exceeds the maximum duration of pseudo-login contained in the login configuration information, exit the pseudo-login state by automatically logging out the login account and clearing the local access ticket.

[0170] Figure 16 This is a block diagram illustrating an access processing apparatus based on a zero-trust network, which is configured on a zero-trust server and includes a first receiving module 1610, a notification module 1620, and a second processing module 1630.

[0171] The first receiving module 1610 is configured to receive indication information sent by the zero trust management terminal. The indication information is used to indicate that the login service in the zero trust network is abnormal.

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

[0173] 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 access session traffic and local access tickets to the zero-trust gateway based on the login configuration information. After independently performing the verification of the local access tickets, the zero-trust gateway forwards the access session traffic to the business server.

[0174] In another exemplary embodiment, the device further includes an exit indication module 1640, which is configured to notify the zero trust gateway to cancel the independent ticket verification state after receiving a specified notification message sent by the zero trust management terminal, and to send a notification message indicating exit from 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.

[0175] Figure 17 This is a block diagram illustrating an access processing apparatus based on a zero-trust network, which is configured on a zero-trust gateway and includes a response module 1710, a second receiving module 1720, and a third processing module 1730.

[0176] The response module 1710 is configured to respond to the first notification information sent by the zero-trust server, enter the independent verification state of the ticket, and send response information to the zero-trust server.

[0177] 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 by the zero-trust terminal after determining that the conditions for performing 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.

[0178] The third processing module 1730 is configured to independently perform the verification of local access tickets and forward the access session traffic to the business server after the verification is successful.

[0179] In another exemplary embodiment, the device further includes a recovery processing module 1740, which is configured to exit the independent ticket verification state in response to a second notification message sent by the zero-trust server, send a response message to the zero-trust server, receive access session traffic and access ticket sent by the zero-trust terminal, wherein the access ticket is obtained by the zero-trust terminal from the zero-trust server, request the zero-trust server to perform verification on the access ticket, and forward the access session traffic to the business server after the verification is passed.

[0180] It should be noted that the access processing device based on zero-trust networks provided in the above embodiments and the access processing method based on zero-trust networks provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the access processing device based on zero-trust networks provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above, and this is not a limitation here.

[0181] Embodiments of this application also provide an electronic device, including: one or more processors; and a memory for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the access processing method based on a zero-trust network provided in the above embodiments.

[0182] Figure 18 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 18 The computer system 1800 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0183] like Figure 18 As shown, the computer system 1800 includes a Central Processing Unit (CPU) 1801, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1802 or programs loaded from storage portion 1808 into Random Access Memory (RAM) 1803, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1803. The CPU 1801, ROM 1802, and RAM 1803 are interconnected via bus 1804. An Input / Output (I / O) interface 1805 is also connected to bus 1804.

[0184] The following components are connected to I / O interface 1805: an input section 1806 including a keyboard, mouse, etc.; an output section 1807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, 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, modem, etc. The communication section 1809 performs communication processing via a network such as the Internet. A drive 1810 is also connected to I / O interface 1805 as needed. Removable media 1811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1810 as needed so that computer programs read from them can be installed into storage section 1808 as needed.

[0185] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1809, and / or installed from removable medium 1811. When the computer program is executed by central processing unit (CPU) 1801, it performs various functions defined in the system of this application.

[0186] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. The computer program contained on 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.

[0187] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0188] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0189] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the access processing method based on a zero-trust network as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0190] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the access processing method based on a zero-trust network provided in the various embodiments above.

[0191] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

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

Claims

1. An access processing method based on a zero-trust network, characterized in that, Applied to zero-trust terminals, the method includes: Obtain login configuration information from the zero-trust server. The login configuration information is generated after an anomaly is detected in the login service in the zero-trust network. The login configuration information includes pseudo-login execution condition information. Based on the login configuration information, determine whether the zero-trust terminal has the conditions for fake login; When the zero-trust terminal has the conditions to perform a fake login, it generates a local access ticket and sends the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway can forward the access session traffic to the service server after independently performing the verification of the local access ticket.

2. The method according to claim 1, characterized in that, The step of determining whether the zero-trust terminal has the conditions to perform a fake login based on the login configuration information includes: The pseudo login execution switch information contained in the login configuration information is detected. 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 that pseudo login is enabled, then 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 they do, then it is determined that the zero-trust terminal has the conditions to perform pseudo login.

3. The method according to claim 2, characterized in that, Determining whether the login condition parameters in the zero-trust terminal satisfy the pseudo-login execution condition information contained in the login configuration information includes: Obtain historical login information from the zero-trust terminal; If the login time of the most recent valid login is determined to be before the time specified in the pseudo login execution condition information based on the historical login 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 satisfy 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 includes: Perform a regular login when the zero-trust terminal does not meet the conditions for performing a fake login; If a normal login is successful, the user information and login ticket for this login will be stored, and the user will enter the normal login state.

5. The method according to claim 1, characterized in that, The generation of local access tickets includes: Generate a bill payload and a bill signature based on the bill content information, wherein the bill content information includes at least one of the following: user unique identifier, bill generation time, bill validity period, and 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 process of generating the bill payload and bill signature based on the bill content information includes: Obtain the key agreed upon between the zero-trust terminal and the zero-trust gateway; The content information of the ticket is encoded using a preset encoding method, and the encoded content information of the ticket is encrypted using the key to obtain ciphertext content; The encrypted content is encoded based on the preset encoding method to obtain the ticket signature.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Upon receiving a notification from the Zero Trust server instructing the user to exit the pseudo-login state, the user stops 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, thereby exiting the pseudo-login state. Alternatively, if the duration of the fake login state exceeds the maximum duration of the fake login state contained in the login configuration information, the fake login state will be exited by automatically logging out the login account and clearing the local access ticket.

8. The method according to any one of claims 1-6, characterized in that, Sending the access session traffic and the local access ticket to the zero-trust gateway includes: 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, Applied to zero-trust servers, the method includes: Receive indication information sent by the zero trust management terminal, the indication information being used to indicate that the login service in the zero trust network is abnormal; In response to the indicated information, the zero-trust gateway is notified to enter the independent ticket verification state; After receiving the response information returned by the zero-trust gateway, login configuration information is sent to the zero-trust terminal. The login configuration information includes pseudo-login execution condition information, so that the zero-trust terminal sends access session traffic and local access tickets to the zero-trust gateway based on the login configuration information. After independently performing the verification of the local access tickets, the zero-trust gateway forwards the access session traffic to the business server.

10. The method according to claim 9, characterized in that, The method further includes: Upon receiving the specified notification message from the Zero Trust Management Terminal, the Zero Trust Gateway is notified to cancel the independent ticket verification status. After receiving the response information returned by the zero-trust gateway, a notification information instructing the zero-trust terminal to exit the fake login is sent to the zero-trust terminal so that the zero-trust terminal exits the fake login state.

11. An access processing method based on a zero-trust network, characterized in that, Applied to zero-trust gateways, the method includes: In response to the first notification message sent by the zero-trust server, the system enters the independent verification state of the invoice and sends a response message to the zero-trust server. The system receives access session traffic and local access tickets sent by a zero-trust terminal. The local access ticket is generated by the zero-trust terminal after it determines that it has the conditions to perform a pseudo login based on the login configuration information sent by the zero-trust server. The login configuration information includes pseudo login execution condition information. The local access ticket is validated independently, and the access session traffic is forwarded to the business server after the validation passes.

12. The method according to claim 11, characterized in that, The method further includes: In response to the second notification message sent by the zero-trust server, exit the independent verification state of the invoice and send a response message to the zero-trust server; Receive access session traffic and access tickets sent by the zero-trust terminal, wherein the access tickets are obtained by the zero-trust terminal from the zero-trust server; The system requests verification of the access ticket from the zero-trust server and forwards the access session traffic to the business server after the verification is successful.

13. An access processing device based on a zero-trust network, characterized in that, Configured on a zero-trust terminal, the device includes: The acquisition module is configured to acquire login configuration information from the zero-trust server. The login configuration information is generated after an anomaly is detected in the login service in the zero-trust network. The login configuration information includes pseudo-login execution condition information. The determination module is configured to determine whether the zero-trust terminal has the conditions to perform a fake login based on the login configuration information; The first processing module is configured to generate a local access ticket if the zero-trust terminal has the conditions to perform a fake login, and send the access session traffic and the local access ticket to the zero-trust gateway, so that the zero-trust gateway can forward the access session traffic to the business server after independently performing the verification of the local access ticket.

14. An access processing device based on a zero-trust network, characterized in that, Configured on a zero-trust server, the device includes: The first receiving module is configured to receive indication information sent by the zero trust management terminal, the indication information being used to indicate that the login service in the zero trust network is abnormal; The notification module is configured to, in response to the indication information, notify the zero-trust gateway to enter the independent ticket verification state; 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. The login configuration information includes pseudo-login execution condition information, so that the zero-trust terminal sends access session traffic and local access tickets to the zero-trust gateway based on the login configuration information. After independently performing the verification of the local access tickets, the zero-trust gateway forwards the access session traffic to the business server.

15. An access processing device based on a zero-trust network, characterized in that, Configured on a zero-trust gateway, the device includes: The response module is configured to respond to the first notification information sent by the zero-trust server, enter the independent verification state of the invoice, and send response information to the zero-trust server. The second receiving module is configured to receive access session traffic and local access tickets sent by the zero-trust terminal. The local access ticket is generated by the zero-trust terminal after determining that the conditions for performing 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 is configured to independently perform the verification of the local access ticket, and forward the access session traffic to the business server after the verification is successful.

16. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs that, when executed by one or more processors, cause 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, It stores computer-readable instructions that, when executed by the computer's processor, cause the computer to perform the access processing method based on a zero-trust network as described in any one of claims 1 to 12.

Images