Network access method and device for zero trust network architecture, equipment and medium
By employing a triple dynamic verification mechanism of UDP authentication, TCP request authentication, and credit assessment in a zero-trust network architecture, the problem of authentication failure under network latency is solved, thereby improving the authentication success rate and network access security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HANGZHOU DPTECH TECH
- Filing Date
- 2026-04-03
- Publication Date
- 2026-06-19
AI Technical Summary
In a zero-trust network architecture, under network latency conditions, the zero-trust security client may fail to receive the authentication response within the specified timeout period, resulting in authentication failure. Furthermore, the existing adaptive retransmission mechanism cannot identify network congestion, which can easily trigger a broadcast storm effect and pose a risk of a broken trust chain.
A triple dynamic verification mechanism of UDP authentication, TCP request authentication and credit assessment is adopted. The authentication information is carried through the UDP authentication request, the security policy check information is sent after the TCP connection is established, and the authentication is performed after receiving the authorization results from the controller and the gateway, so as to realize identity verification and security policy verification.
It improves the authentication success rate, prevents the chain of trust from breaking, and enhances the security and reliability of network access.
Smart Images
Figure CN122247719A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security technology, and in particular to a network access method, apparatus, device and medium for zero-trust network architecture. Background Technology
[0002] In a zero-trust network architecture, the Zero Trust Security Client (ZTS-C) needs to interact with the Zero Trust Security Management (ZTS-M) for authentication by sending User Datagram Protocol (UDP) requests. In unstable or delayed network environments, the ZTS-C may fail to receive the ZTS-M authentication response within the specified timeout period, resulting in authentication failure.
[0003] Currently, adaptive retransmission control mechanisms can be used for zero-trust high-latency scenarios. When a zero-trust secure client does not receive a response message from the controller within a preset timeout period, it triggers a connection retry sequence controlled by the Exponential Backoff Algorithm (EBA), initiating multiple reconnection requests at incremental time intervals. This ensures communication reliability while preventing network congestion from worsening. However, the fixed backoff algorithm cannot identify the true network congestion state, easily triggering the Broadcast Storm Effect (BSE). Furthermore, this retransmission mechanism only guarantees transmission connectivity and does not simultaneously verify security status. During the reconnection interval, the device may be implanted with malicious programs, posing a risk of a broken trust chain. Summary of the Invention
[0004] In view of this, this application provides a network access method, apparatus, device and medium for zero-trust network architecture, which can improve the authentication success rate and security of network access.
[0005] According to a first aspect of this application, a network access method for a zero-trust network architecture is provided, applied to a client of a zero-trust network architecture, the method comprising: Send a User Datagram Protocol (UDP) authentication request to the controller, the UDP authentication request carrying the client's authentication information; Upon receiving a first verification result indicating that the verification has passed from the controller, a TCP connection is established with the controller based on the TCP port opened by the controller; Send a first TCP request to the controller, the first TCP request carrying security policy check information; The controller receives the first authorization result sent by the controller and sends a client authorization message to the gateway; the first authorization result is generated after the controller sends a controller authorization message to the gateway. Upon receiving the second authorization result sent by the gateway, a communication connection is established with the gateway, and an authentication result is sent to the controller; the second authorization result is generated by the gateway based on the controller authorization message sent by the controller and the client authorization message, and the controller authorization message is generated based on the credit assessment result.
[0006] In some possible embodiments, the method further includes: Send a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; The system receives multi-factor authentication result information sent by the controller; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0007] In some possible embodiments, the method further includes: Upon receiving a second verification result indicating that the verification failed from the controller, the system sends the UDP authentication request to the controller at preset time intervals until a preset number of times is reached.
[0008] In some possible embodiments, the client authorization message includes at least one of the following: Client serial number, media access control address, unique request number, public Internet Protocol address.
[0009] According to a second aspect of this application, a network access method for a zero-trust network architecture is provided, applied to a controller of the zero-trust network architecture, the method comprising: The system receives a UDP authentication request sent by a client, carrying the client's authentication information, and verifies the authentication information to obtain a verification result. The verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. If the verification result is the first verification result, the first verification result is sent to the client, and a TCP connection is established with the client by opening the TCP port. Receive the first TCP request sent by the client carrying security policy inspection information, and generate a credit assessment result based on the security policy inspection information; A controller authorization message is generated based on the credit assessment result and sent to the gateway. The first authorization result is also sent to the client. The controller authorization message is used by the gateway to verify the client authorization message in order to generate a second authorization result. The system receives the authentication result sent by the client and controls the client to access the network based on the authentication result; the authentication result is generated by the client based on the second authorization result sent by the gateway.
[0010] In some possible embodiments, the TCP port remains open for a preset time, which is less than a preset time threshold.
[0011] In some possible embodiments, the method further includes: Receive a second TCP request sent by the client, carrying multi-factor authentication query information; Send multi-factor authentication result information to the client; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0012] In some possible embodiments, the method further includes: If the verification result is the second verification result, the second verification result is sent to the client; The system receives at least one UDP authentication request sent by the client at preset time intervals, performs verification, and obtains the verification result.
[0013] In some possible embodiments, the controller authorization message includes at least one of the following: Client serial number, media access control address, unique request number, public Internet Protocol address.
[0014] According to a third aspect of this application, a network access method for a zero-trust network architecture is provided, applied to a zero-trust network architecture including a client, a controller, and a gateway; the method includes: The client sends a UDP authentication request to the controller, the UDP authentication request carrying the client's authentication information; The controller verifies the authentication information and obtains a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. If the verification result is the first verification result, the controller sends the first verification result to the client and opens the TCP port; Based on the first verification result, the client establishes a TCP connection with the controller through the TCP port; The client sends a first TCP request to the controller, the first TCP request carrying security policy check information; The controller generates a credit assessment result based on the security policy check information, sends the controller authorization message to the gateway based on the credit assessment result, and sends a first authorization result to the client. Based on the first authorization result, the client sends a client authorization message to the gateway; The gateway verifies the client authorization message based on the controller authorization message, generates a second authorization result, and sends the second authorization result to the client. The client establishes a communication connection with the gateway based on the second authorization result and sends the authentication result to the controller; The controller controls the client to access the network based on the authentication result.
[0015] In some possible embodiments, the method further includes: The client sends a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; The controller generates multi-factor authentication result information based on the multi-factor authentication query information and sends the multi-factor authentication result information to the client.
[0016] In some possible embodiments, the method further includes: If the verification result is the second verification result, the controller sends the second verification result to the client; Based on the second verification result, the client sends the UDP authentication request to the controller at preset time intervals until the preset number of times is reached.
[0017] According to a fourth aspect of this application, a network access device for a zero-trust network architecture is provided, applied to a client of a zero-trust network architecture, the device comprising: An authentication request sending module is used to send a UDP authentication request to the controller, wherein the UDP authentication request carries the client's authentication information; The TCP connection establishment module is used to establish a TCP connection with the controller based on the TCP port opened by the controller when the controller sends a first verification result indicating that the verification has passed. The TCP request sending module is used to send a first TCP request to the controller, wherein the first TCP request carries security policy check information; The client authorization message sending module is used to receive the first authorization result sent by the controller and send a client authorization message to the gateway; the first authorization result is generated after the controller sends a controller authorization message to the gateway. The authentication result sending module is used to establish a communication connection with the gateway and send the authentication result to the controller upon receiving the second authorization result sent by the gateway; the second authorization result is generated by the gateway based on the controller authorization message and the client authorization message sent by the controller, and the controller authorization message is generated based on the credit assessment result.
[0018] In some possible embodiments, the TCP request sending module is further configured to: Send a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; The system receives multi-factor authentication result information sent by the controller; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0019] In some possible embodiments, the authentication request sending module is further configured to: Upon receiving a second verification result indicating that the verification failed from the controller, the system sends the UDP authentication request to the controller at preset time intervals until a preset number of times is reached.
[0020] In some possible embodiments, the client authorization message includes at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0021] According to a fifth aspect of this application, a network access device for a zero-trust network architecture is provided, which is applied to a controller in a zero-trust network architecture, the device comprising: An authentication request receiving module is used to receive a UDP authentication request sent by a client carrying the client's authentication information, and to verify the authentication information to obtain a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. The verification result sending module is used to send the first verification result to the client when the verification result is the first verification result, and to open the Transmission Control Protocol (TCP) port to establish a TCP connection with the client. The TCP request receiving module is used to receive the first TCP request carrying security policy inspection information sent by the client, and generate a credit assessment result based on the security policy inspection information. The controller authorization message sending module is used to generate a controller authorization message based on the credit assessment result, send the controller authorization message to the gateway, and send the first authorization result to the client. The controller authorization message is used by the gateway to verify the client authorization message in order to generate a second authorization result. The authentication result receiving module is used to receive the authentication result sent by the client and control the client to access the network based on the authentication result; the authentication result is generated by the client based on the second authorization result sent by the gateway.
[0022] In some possible embodiments, the TCP port remains open for a preset time, which is less than a preset time threshold.
[0023] In some possible embodiments, the TCP request receiving module is further configured to: Receive a second TCP request sent by the client, carrying multi-factor authentication query information; Send multi-factor authentication result information to the client; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0024] In some possible embodiments, the verification result sending module is further configured to: If the verification result is the second verification result, the second verification result is sent to the client; The system receives at least one UDP authentication request sent by the client at preset time intervals, performs verification, and obtains the verification result.
[0025] In some possible embodiments, the controller authorization message includes at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0026] According to a sixth aspect of this application, a computer device is provided, comprising: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the computer device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the network access method for a zero-trust network architecture described in any possible embodiment of the first or second aspect is executed.
[0027] According to a seventh aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, performs the network access method for a zero-trust network architecture as described in any possible embodiment of the first or second aspect above.
[0028] This application provides a network access method, apparatus, computer device, and storage medium for a zero-trust network architecture. The client first sends a UDP authentication request carrying the client's authentication information to the controller for identity verification. After the controller verifies the identity, a TCP connection is established with the client. Then, a first TCP request carrying security policy check information is sent. The controller performs a credit assessment on the security policy check information and sends a controller authorization message to the gateway based on the credit assessment result. After authorizing the gateway, the controller sends a first authorization result to the client. The client sends a client authorization message to the gateway based on the first authorization result, and upon receiving a second authorization result from the gateway, sends an authentication result to the controller. In other words, this application employs a triple dynamic verification mechanism of UDP authentication, TCP request authentication, and credit assessment, which not only improves the authentication success rate but also effectively prevents the risk of a broken trust chain, thus enhancing the security of network access.
[0029] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0030] Figure 1 This illustration shows a topology diagram of a zero-trust network architecture provided in an embodiment of this application.
[0031] Figure 2 A flowchart of a network access method for a zero-trust network architecture provided in an embodiment of this application is shown.
[0032] Figure 3 A flowchart is shown for another network access method for a zero-trust network architecture provided by an embodiment of this application.
[0033] Figure 4 A flowchart is shown for another network access method for a zero-trust network architecture provided by an embodiment of this application.
[0034] Figure 5 This illustration shows an interactive process diagram of a network access method for a zero-trust network architecture provided in an embodiment of this application.
[0035] Figure 6 This paper presents a schematic diagram of the structure of a network access device for a zero-trust network architecture provided in an embodiment of this application.
[0036] Figure 7 This paper presents a schematic diagram of another network access device for a zero-trust network architecture provided in an embodiment of this application.
[0037] Figure 8A schematic diagram of the structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation
[0038] 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.
[0039] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.
[0040] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."
[0041] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0042] The Zero Trust Security Model, also known as the Zero Trust Architecture, describes a methodology for designing and implementing information technology (IT) systems. The core concept of the Zero Trust Security Model is "never trust, always verify," meaning that no device should be trusted by default, even if it is connected to a licensed network and has previously been verified.
[0043] Currently, most enterprise networks have complex architectures, encompassing numerous interconnected regions, cloud services, and infrastructure, as well as connections to remote and mobile environments and unconventional information technology (IT) connections (such as IoT devices). The Zero Trust principle addresses the inadequacy of traditional methods (such as trusting devices within a nominal "corporate perimeter" or connecting devices via VPNs) due to the complexity of enterprise network environments. Zero Trust advocates for mutual authentication, including checking device identity and integrity regardless of location, and authenticating users based on confidence levels regarding device identity and condition, granting access to applications and services.
[0044] Research has revealed that in a zero-trust network architecture, the Zero Trust Security Client (ZTS-C) needs to interact with the Zero Trust Security Management (ZTS-M) for authentication by sending User Datagram Protocol (UDP) requests. In real-world network environments, especially in scenarios involving cross-border access, satellite communication, and long-distance transmission, network latency can occur. Under unstable or delayed network conditions, the ZTS-C may fail to receive the ZTS-M authentication response within the specified timeout period, leading to authentication failure.
[0045] Currently, for zero-trust high-latency scenarios, an adaptive retransmission control mechanism can be used. When a zero-trust secure client does not receive a response message from the controller within a preset timeout period, it triggers a connection retry sequence controlled by the Exponential Backoff Algorithm (EBA), initiating multiple reconnection requests at incremental time intervals. This ensures communication reliability while preventing network congestion from worsening. However, the fixed backoff algorithm cannot identify the true network congestion state, easily triggering the Broadcast Storm Effect (BSE). Furthermore, this retransmission mechanism only guarantees transmission connectivity and does not simultaneously verify security status. During the reconnection interval, the device may be implanted with malicious programs, posing a risk of a broken trust chain.
[0046] Based on the above research, this application provides a network access method for zero-trust network architecture. First, it verifies identity by carrying the client's authentication information via a UDP authentication request. After successful identity verification, a TCP connection is established to send security policy check information. Then, upon receiving secondary authorization results from the controller and gateway, the authentication result is sent to the controller. In other words, this application employs a triple dynamic verification mechanism of UDP authentication, TCP request authentication, and credit assessment, which not only improves the authentication success rate but also effectively prevents the risk of trust chain breakage, thereby enhancing network access security.
[0047] The network access method for zero-trust network architecture provided in the embodiments of this application will be described below with reference to the accompanying drawings.
[0048] First, the zero-trust network framework provided in the embodiments of this application will be described.
[0049] See Figure 1 As shown, Figure 1 This is a schematic diagram of the topology of an exemplary zero-trust network architecture provided in an embodiment of this application. The zero-trust network architecture 100 includes a client 10, a controller 20, a gateway 30, a switch 40, and internal network resources 50. The controller 20 can perform identity authentication, permission verification, and security policy checks on the client 10. The gateway 30 can be used to isolate the internal and external networks, allowing only authenticated and authorized traffic. The switch 40 is responsible for basic network connectivity.
[0050] For example, client 10 includes, but is not limited to, mobile phones, laptops, tablets, etc. Controller 20 includes, but is not limited to, authentication controllers, access controllers, security management platforms, etc. Gateway 30 includes, but is not limited to, authentication gateways, data security gateways, security gateways, etc. Switch 40 includes, but is not limited to, access switches, aggregation switches, core switches, etc. Internal network resources 50 include, but are not limited to, financial systems, business platforms, databases, etc.
[0051] See Figure 2 The diagram shows a flowchart of a network access method for a zero-trust network architecture provided in this disclosure embodiment. This method is applied to a client in a zero-trust network architecture (such as...). Figure 1 (Client 10 in the middle), the method includes steps S201~S205: S201: Send a User Datagram Protocol (UDP) authentication request to the controller, the UDP authentication request carrying the client's authentication information.
[0052] For example, a client can send a UDP authentication request to the controller, which carries authentication information indicating the client's identity. This authentication information may include, for example, the client's identity ID, client key, network identifier, and device identifier.
[0053] S202: Upon receiving a first verification result indicating that the verification has passed from the controller, establish a TCP connection with the controller based on the TCP port opened by the controller.
[0054] Here, after receiving a UDP authentication request from the client, the controller verifies the identity information. If the verification passes, a first verification result is generated. The controller then sends the first verification result to the client and opens the TCP port. If the verification fails, a second verification result is generated and sent to the client.
[0055] Therefore, in one optional implementation, the method further includes: If the client receives a second verification result indicating that the verification failed from the controller, it sends the UDP authentication request to the controller at preset time intervals until the preset number of times is reached.
[0056] In this embodiment, the preset time interval is 500 milliseconds. In other embodiments, the preset time interval can be 200 milliseconds, 400 milliseconds, 600 milliseconds, 800 milliseconds, etc., depending on actual needs. Furthermore, the preset number of times is not limited. For example, the preset number of times can be 3, 4, 5, etc., depending on actual needs.
[0057] In this embodiment of the application, if the client receives the second verification result, a retry mechanism is implemented, which can improve the authentication success rate.
[0058] S203: Send a first TCP request to the controller, the first TCP request carrying security policy check information.
[0059] Here, after the controller opens the TCP port, if the client receives the first verification result, it can send a TCP authentication request to the controller. This TCP request carries security policy check information. This security policy check information is used by the controller to verify the client's security compliance. For example, this security policy check information may include a list of processes that award points, a list of processes that deduct points, a list of software that awards points, a list of software that deducts points, a list of open TCP ports that deduct points, a list of open UDP ports that deduct points, system patches, firewalls, prohibited software, system configurations, etc.
[0060] S204: Receive the first authorization result sent by the controller and send a client authorization message to the gateway; the first authorization result is generated after the controller sends a controller authorization message to the gateway.
[0061] Here, the controller can generate a credit assessment result based on the security policy check information, and send a controller authorization message to the gateway based on the credit assessment result. After sending the controller authorization message to the gateway, it sends a first authorization result to the client. Specifically, the controller can verify the security policy check information and send a controller authorization message to the gateway after the verification is passed.
[0062] In one optional implementation, the controller authorization message may include at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0063] For example, after the client receives the first authorization result sent by the controller, it can send a client authorization message to the gateway.
[0064] In one optional implementation, the client authorization message includes at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0065] For example, the client serial number is a unique hardware identifier for the terminal device, used for identification and verification of the client device in a zero-trust architecture. The Media Access Control Address (MAC) is the hardware MAC address of the client's physical network interface card (NIC), serving as a device identification characteristic and used for zero-trust terminal identification and security verification. The unique request number is a random number generated by the client to prevent malicious replay attacks after the client's request is captured by packet sniffing tools. The public Internet Protocol address refers to the IP address of a public network.
[0066] S205: Upon receiving the second authorization result sent by the gateway, establish a communication connection with the gateway and send the authentication result to the controller; the second authorization result is generated by the gateway based on the controller authorization message sent by the controller and the client authorization message, and the controller authorization message is generated based on the credit assessment result.
[0067] Here, the gateway can verify the controller authorization message and the client authorization message, generate a second authorization result, and send the second authorization result to the client. For example, if the gateway verifies both the controller authorization message and the client authorization message and obtains a successful verification result, it can then send the second authorization result to the client.
[0068] For example, the client can establish a communication connection with the gateway using an architecture that separates the control channel and the data channel.
[0069] In an optional implementation, the method further includes the following (1) to (2): (1) Send a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; (2) Receive the multi-factor authentication result information sent by the controller; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0070] For example, after step S202, the client may send a second TCP request to the controller. The client then responds with multi-factor authentication result information based on this request. Multi-factor authentication query information is a computer access control method that requires users to verify their identity using two or more different types of authentication factors to improve account security. For example, the authentication factors in this multi-factor authentication query information may include passwords, fingerprints, SMS verification codes, smart cards, etc.
[0071] See Figure 3 The diagram shows a flowchart of another network access method for a zero-trust network architecture provided in this disclosure embodiment. This method is applied to a controller (such as...). Figure 1 The method may include the following steps S301-S305: (controller 20 in the controller) S301: Receive a UDP authentication request sent by the client carrying the client's authentication information, and verify the authentication information to obtain a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed.
[0072] Here, the controller can receive UDP authentication requests sent by the client, verify the authentication information carried by the request, and obtain a first verification result indicating that the verification passed or a second verification result indicating that the verification failed.
[0073] For example, the UDP authentication request can be a UDP message. After receiving the UDP message, the controller can decrypt the message information and verify the authentication information in the message to obtain a first verification result or a second verification result.
[0074] In some embodiments, the first and second verification results can be generated using a specific message format. For example, the message format can be a Type-Length-Value (TLV) format. Taking the status code "401003001" as an example, the first three digits "401" indicate "result returned," and in the last six digits "003001," the last three digits represent "success (verification passed)" and "002" represent "processing (verification failed)." "Success" can be one form of the first verification result, and "processing" can be one form of the second verification result. Understandably, in other embodiments, the first and second verification results can also be in other forms, without specific limitations.
[0075] S302: If the verification result is the first verification result, send the first verification result to the client and open the TCP port to establish a TCP connection with the client.
[0076] In an optional implementation, the method further includes: If the verification result is the second verification result, the controller will send the second verification result to the client; The system receives at least one UDP authentication request sent by the client at preset time intervals, performs verification, and obtains the verification result.
[0077] Here, if the controller receives the second verification result, it sends the second result to the client. The client can resend the UDP request, allowing the controller to verify the resent UDP request. Multiple verifications can improve the authentication success rate.
[0078] In one optional implementation, the TCP port remains open for a preset time, which is less than a preset time threshold. Here, compared to the traditional approach of continuously opening the TCP port, a strategy of opening the TCP port on demand is adopted, opening the port only briefly after successful authentication. This strictly adheres to the core principle of zero-trust architecture—"never trust, always verify"—and achieves dynamic attack surface convergence.
[0079] In this embodiment, the preset time threshold is 30 seconds. In other embodiments, the preset time interval can be 20 seconds, 40 seconds, 50 seconds, 60 seconds, etc., and is not limited to any specific value. It can be determined according to actual needs.
[0080] S303: Receive the first TCP request sent by the client carrying security policy check information, and generate a credit assessment result based on the security policy check information.
[0081] Here, upon receiving the initial verification result, the client can establish a TCP connection with the controller via the TCP port and send a first TCP request carrying security policy check information. The controller can then perform a credit assessment on the security policy check information to obtain a credit assessment result. For example, the controller might perform addition or subtraction operations based on the security policy detection information to generate a credit assessment result (e.g., 98 points).
[0082] Specifically, the controller can pre-set the correspondence between credit assessment results and access permissions. For example, the correspondence could include: a credit score of 90–100 allows access to 100 resources, a score of 80–89 allows access to 50 resources, and a score of 70–79 allows access to 30 resources. A credit score of 98 would correspond to access to 100 resources.
[0083] S304: Generate a controller authorization message based on the credit assessment result, send the controller authorization message to the gateway, and send the first authorization result to the client. The controller authorization message is used by the gateway to verify the client authorization message in order to generate a second authorization result.
[0084] Here, the controller can generate a controller authorization message based on the credit assessment result and send the controller authorization message to the gateway. After sending the controller authorization message to the gateway, a first authorization result is generated. After receiving the first authorization result, the client can send a client authorization message to the gateway. The gateway can verify the client authorization message based on the controller authorization message and generate a second authorization result.
[0085] In one optional implementation, the controller authorization message includes at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0086] S305: Receive the authentication result sent by the client, and control the client to access the network based on the authentication result; the authentication result is generated by the client based on the second authorization result sent by the gateway.
[0087] Here, the gateway verifies both the controller's authorization message and the client's authorization message. If the verification passes, it sends a second authorization result to the client. The client can then establish a communication connection with the gateway based on this second authorization result and send the authentication result to the controller.
[0088] In some embodiments, the method further includes: The system receives a second TCP request from the client carrying multi-factor authentication query information and sends multi-factor authentication result information to the client; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0089] See Figure 4 The diagram shows a flowchart of another network access method for a zero-trust network architecture provided in this disclosure embodiment, the method including the following steps S401~S410: S401: The client sends a UDP authentication request to the controller, the UDP authentication request carrying the client's authentication information.
[0090] S402: The controller verifies the authentication information and obtains a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed.
[0091] S403: If the verification result is the first verification result, the controller sends the first verification result to the client and opens the TCP port.
[0092] S404: Based on the first verification result, the client establishes a TCP connection with the controller through the TCP port.
[0093] S405: The client sends a first TCP request to the controller, the first TCP request carrying security policy check information.
[0094] S406: The controller generates a credit assessment result based on the security policy check information, and sends the controller authorization message to the gateway based on the credit assessment result, and sends a first authorization result to the client.
[0095] S407: Based on the first authorization result, the client sends a client authorization message to the gateway.
[0096] S408: The gateway verifies the client authorization message based on the controller authorization message, generates a second authorization result, and sends the second authorization result to the client.
[0097] S409: The client establishes a communication connection with the gateway based on the second authorization result and sends the authentication result to the controller.
[0098] S410: The controller controls the client to access the network based on the authentication result.
[0099] Please refer to the following: Figure 5In some embodiments, the method further includes the following steps S411-S412: S411: If the verification result is the second verification result, the controller sends the second verification result to the client; S412: Based on the second verification result, the client sends the UDP authentication request to the controller at preset time intervals until the preset number of times is reached.
[0100] In some embodiments, the method further includes the following steps S413-S414: S413: The client sends a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; S414: The controller generates multi-factor authentication result information based on the multi-factor authentication query information and sends the multi-factor authentication result information to the client.
[0101] The network access method for a zero-trust network architecture provided in this application embodiment involves the client first sending a UDP authentication request carrying the client's authentication information to the controller for identity verification. After the controller verifies the identity, a TCP connection is established with the controller. Then, a first TCP request carrying security policy check information is sent. The controller performs a credit assessment on the security policy check information and sends a controller authorization message to the gateway based on the credit assessment result. After authorizing the gateway, the controller sends a first authorization result to the client. The client sends a client authorization message to the gateway based on the first authorization result, and upon receiving a second authorization result from the gateway, sends an authentication result to the controller. In other words, this application employs a triple dynamic verification mechanism of UDP authentication, TCP request authentication, and credit assessment, which not only improves the authentication success rate but also effectively prevents the risk of a broken trust chain, thereby enhancing the security of network access.
[0102] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.
[0103] Based on the same technical concept, this disclosure also provides a network access device for a zero-trust network architecture corresponding to the network access method for a zero-trust network architecture. Since the principle of the device in this disclosure for solving the problem is similar to the network access method for a zero-trust network architecture described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0104] Reference Figure 6The diagram shown is a schematic representation of a network access device for a zero-trust network architecture provided in an embodiment of this disclosure. The device is applied to a client, and the network access device 600 includes: The authentication request sending module 601 is used to send a UDP authentication request to the controller, wherein the UDP authentication request carries the client's authentication information; TCP connection establishment module 602 is used to establish a TCP connection with the controller based on the TCP port opened by the controller when the controller sends a first verification result indicating that the verification has passed. TCP request sending module 603 is used to send a first TCP request to the controller, wherein the first TCP request carries security policy check information; The client authorization message sending module 604 is used to receive the first authorization result sent by the controller and send a client authorization message to the gateway; the first authorization result is generated after the controller sends a controller authorization message to the gateway. The authentication result sending module 605 is used to establish a communication connection with the gateway and send the authentication result to the controller upon receiving the second authorization result sent by the gateway; the second authorization result is generated by the gateway based on the controller authorization message and the client authorization message sent by the controller, and the controller authorization message is generated based on the credit assessment result.
[0105] In some possible embodiments, the TCP request sending module 603 is further configured to: Send a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; The system receives multi-factor authentication result information sent by the controller; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0106] In some possible embodiments, the authentication request sending module 601 is further configured to: Upon receiving a second verification result indicating that the verification failed from the controller, the system sends the UDP authentication request to the controller at preset time intervals until a preset number of times is reached.
[0107] In some possible embodiments, the client authorization message includes at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0108] Reference Figure 7 The diagram shown is a schematic representation of a network access device for a zero-trust network architecture provided in an embodiment of this disclosure. The device is applied to a controller, and the network access device 700 includes: The authentication request receiving module 701 is used to receive a UDP authentication request sent by the client carrying the client's authentication information, and to verify the authentication information to obtain a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. The verification result sending module 702 is used to send the first verification result to the client when the verification result is the first verification result, and to open the Transmission Control Protocol (TCP) port to establish a TCP connection with the client. TCP request receiving module 703 is used to receive a first TCP request carrying security policy inspection information sent by the client, and generate a credit assessment result based on the security policy inspection information; The controller authorization message sending module 704 is used to generate a controller authorization message based on the credit assessment result, send the controller authorization message to the gateway, and send the first authorization result to the client. The controller authorization message is used by the gateway to verify the client authorization message in order to generate a second authorization result. The authentication result receiving module 705 is used to receive the authentication result sent by the client and control the client to access the network based on the authentication result; the authentication result is generated by the client based on the second authorization result sent by the gateway.
[0109] In some possible embodiments, the TCP port remains open for a preset time, which is less than a preset time threshold.
[0110] In some possible embodiments, the TCP request receiving module 703 is further configured to: Receive a second TCP request sent by the client, carrying multi-factor authentication query information; Send multi-factor authentication result information to the client; the multi-factor authentication result information is used to indicate the authentication method required by the client.
[0111] In some possible embodiments, the verification result sending module 702 is further configured to: If the verification result is the second verification result, the second verification result is sent to the client; The system receives at least one UDP authentication request sent by the client at preset time intervals, performs verification, and obtains the verification result.
[0112] In some possible embodiments, the controller authorization message includes at least one of the following: client serial number, media access control address, unique request number, and public Internet Protocol (IP) address.
[0113] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.
[0114] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0115] Corresponding to the network access method for zero-trust network architecture described above, embodiments of this disclosure also provide a computer device, such as... Figure 8 The diagram shown is a structural schematic of a computer device provided in an embodiment of this disclosure, including: Computer device 800 includes a processor 810, an internal bus 820, memory 830, a network interface 840, and non-volatile memory 850, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 810 reads the corresponding computer program from the non-volatile memory 850 into the memory 830 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.
[0116] Both the main memory 830 and the non-volatile memory 850 can be regarded as memory. The main memory 830, also known as internal memory, is used to temporarily store the computational data in the processor 810, as well as the data exchanged with the non-volatile memory 850 such as the hard disk. The processor 810 exchanges data with the non-volatile memory 850 through the main memory 830.
[0117] In this embodiment, memory 830 is specifically used to store application code that executes the solution of this application, and its execution is controlled by processor 810. That is, when the computer device is running, processor 810 communicates with network interface 840, memory 830 and non-volatile memory 850 through internal bus 820, so that processor 810 executes the application code stored in memory 830 and non-volatile memory 850, thereby executing the network access method for zero-trust network architecture described in the above method embodiment.
[0118] Processor 810 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.
[0119] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the computer device 800. In other embodiments of this application, the computer device 800 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
[0120] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.
[0121] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of a network access method for a zero-trust network architecture as described in the above-described method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.
[0122] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of a network access method for a zero-trust network architecture in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.
[0123] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.
[0124] Furthermore, embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.
[0125] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by dedicated logic circuitry—such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the device can also be implemented as dedicated logic circuitry.
[0126] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.
[0127] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.
[0128] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.
[0129] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
[0130] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.
[0131] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A network access method for a zero-trust network architecture, characterized in that, The method, applied to a client in a zero-trust network architecture, includes: Send a User Datagram Protocol (UDP) authentication request to the controller, the UDP authentication request carrying the client's authentication information; Upon receiving a first verification result indicating that the verification has passed from the controller, a TCP connection is established with the controller based on the TCP port opened by the controller; Send a first TCP request to the controller, the first TCP request carrying security policy check information; The controller receives the first authorization result sent by the controller and sends a client authorization message to the gateway; the first authorization result is generated after the controller sends a controller authorization message to the gateway. Upon receiving the second authorization result sent by the gateway, a communication connection is established with the gateway, and an authentication result is sent to the controller; the second authorization result is generated by the gateway based on the controller authorization message sent by the controller and the client authorization message, and the controller authorization message is generated based on the credit assessment result.
2. The method according to claim 1, characterized in that, The method further includes: Send a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; The system receives multi-factor authentication result information sent by the controller; the multi-factor authentication result information is used to indicate the authentication method required by the client.
3. The method according to claim 1, characterized in that, The method further includes: Upon receiving a second verification result indicating that the verification failed from the controller, the system sends the UDP authentication request to the controller at preset time intervals until a preset number of times is reached.
4. The method according to claim 1, characterized in that, The client authorization message includes at least one of the following: Client serial number, media access control address, unique request number, public Internet Protocol address.
5. A network access method for a zero-trust network architecture, characterized in that, A controller applied to a zero-trust network architecture, the method comprising: The system receives a UDP authentication request sent by a client, carrying the client's authentication information, and verifies the authentication information to obtain a verification result. The verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. If the verification result is the first verification result, the first verification result is sent to the client, and a TCP connection is established with the client by opening the TCP port. Receive the first TCP request sent by the client carrying security policy inspection information, and generate a credit assessment result based on the security policy inspection information; A controller authorization message is generated based on the credit assessment result and sent to the gateway. The first authorization result is also sent to the client. The controller authorization message is used by the gateway to verify the client authorization message in order to generate a second authorization result. The system receives the authentication result sent by the client and controls the client to access the network based on the authentication result; the authentication result is generated by the client based on the second authorization result sent by the gateway.
6. The method according to claim 5, characterized in that, The TCP port is kept open for a preset time, which is less than a preset time threshold.
7. The method according to claim 5, characterized in that, The method further includes: Receive a second TCP request sent by the client, carrying multi-factor authentication query information; Send multi-factor authentication result information to the client; the multi-factor authentication result information is used to indicate the authentication method required by the client.
8. The method according to claim 5, characterized in that, The method further includes: If the verification result is the second verification result, the second verification result is sent to the client; The system receives at least one UDP authentication request sent by the client at preset time intervals, performs verification, and obtains the verification result.
9. The method according to claim 5, characterized in that, The controller authorization message includes at least one of the following: Client serial number, media access control address, unique request number, public Internet Protocol address.
10. A network access method for a zero-trust network architecture, characterized in that, Applied to a zero-trust network architecture, the zero-trust network architecture including a client, a controller, and a gateway; the method includes: The client sends a UDP authentication request to the controller, the UDP authentication request carrying the client's authentication information; The controller verifies the authentication information and obtains a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. If the verification result is the first verification result, the controller sends the first verification result to the client and opens the TCP port; Based on the first verification result, the client establishes a TCP connection with the controller through the TCP port; The client sends a first TCP request to the controller, the first TCP request carrying security policy check information; The controller generates a credit assessment result based on the security policy check information, sends the controller authorization message to the gateway based on the credit assessment result, and sends a first authorization result to the client. Based on the first authorization result, the client sends a client authorization message to the gateway; The gateway verifies the client authorization message based on the controller authorization message, generates a second authorization result, and sends the second authorization result to the client. The client establishes a communication connection with the gateway based on the second authorization result and sends the authentication result to the controller; The controller controls the client to access the network based on the authentication result.
11. The method according to claim 10, characterized in that, The method further includes: The client sends a second TCP request to the controller, the second TCP request carrying multi-factor authentication query information; The controller generates multi-factor authentication result information based on the multi-factor authentication query information and sends the multi-factor authentication result information to the client.
12. The method according to claim 10, characterized in that, The method further includes: If the verification result is the second verification result, the controller sends the second verification result to the client; Based on the second verification result, the client sends the UDP authentication request to the controller at preset time intervals until the preset number of times is reached.
13. A network access device for a zero-trust network architecture, characterized in that, A client-side application for a zero-trust network architecture, the device comprising: An authentication request sending module is used to send a UDP authentication request to the controller, wherein the UDP authentication request carries the client's authentication information; The TCP connection establishment module is used to establish a TCP connection with the controller based on the TCP port opened by the controller when the controller sends a first verification result indicating that the verification has passed. The TCP request sending module is used to send a first TCP request to the controller, wherein the first TCP request carries security policy check information; The client authorization message sending module is used to receive the first authorization result sent by the controller and send a client authorization message to the gateway; the first authorization result is generated after the controller sends a controller authorization message to the gateway. The authentication result sending module is used to establish a communication connection with the gateway and send the authentication result to the controller upon receiving the second authorization result sent by the gateway; the second authorization result is generated by the gateway based on the controller authorization message and the client authorization message sent by the controller, and the controller authorization message is generated based on the credit assessment result.
14. A network access device for a zero-trust network architecture, characterized in that, A controller applied to a zero-trust network architecture, the device comprising: An authentication request receiving module is used to receive a UDP authentication request sent by a client carrying the client's authentication information, and to verify the authentication information to obtain a verification result; the verification result includes a first verification result indicating that the verification passed, or a second verification result indicating that the verification failed. The verification result sending module is used to send the first verification result to the client when the verification result is the first verification result, and to open the Transmission Control Protocol (TCP) port to establish a TCP connection with the client. The TCP request receiving module is used to receive the first TCP request carrying security policy inspection information sent by the client, and generate a credit assessment result based on the security policy inspection information. The controller authorization message sending module is used to generate a controller authorization message based on the credit assessment result, send the controller authorization message to the gateway, and send the first authorization result to the client. The controller authorization message is used by the gateway to verify the client authorization message in order to generate a second authorization result. The authentication result receiving module is used to receive the authentication result sent by the client and control the client to access the network based on the authentication result; the authentication result is generated by the client based on the second authorization result sent by the gateway.
15. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the network access method for a zero-trust network architecture as described in any one of claims 1-4 or 5-9.
16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the network access method for a zero-trust network architecture as described in any one of claims 1-4 or 5-9.