A multi-tenant zero trust network access control method, system and medium

Abstract

The application discloses a multi-tenant zero-trust network access control method, system and medium, relates to the technical field of network security, and is used for solving the technical problems of large delay and the like in the prior art. The method comprises the following steps: accessing a terminal to a target AP according to a pre-shared key (PPSK); reporting terminal access information to a local controller by using the target AP; obtaining network information corresponding to the terminal by interacting with a unified identity management system by using the local controller; determining whether the terminal triggers a zero-trust network access (ZTNA) process by performing policy arrangement on the network information by using a cloud management platform; if it is determined that the terminal triggers the ZTNA process, establishing a secure tunnel between the local controller and an original controller by using a zero-trust access gateway when the terminal roams across controllers; and performing identity authentication and access control on the terminal by using the secure tunnel. Therefore, the application can reduce delay and overhead and the like by using the technical solutions of the three-layer controller architecture and the ZTNA process.

Description

Technical Field

[0001] This application relates to the field of network security technology, and provides a method, system and medium for multi-tenant zero-trust network access control. Background Technology

[0002] Currently, in existing Multiple Dwelling Unit (MDU) scenarios, multi-tenant shared wireless networks have become the mainstream deployment mode. Its core architecture is usually based on tenant isolation authentication with pre-shared keys PPSK / sPSK, unified management by a centralized controller, and data transmission through CAPWAP tunnels to meet the flexibility and isolation requirements of multi-tenants for network access.

[0003] However, the existing MDU multi-tenant wireless network access and roaming architecture has the following problems: (1) The lack of dynamic identity re-verification mechanism in the cross-controller roaming process poses a security risk of terminal hijacking and illegal impersonation for cross-domain roaming; in addition, the incomplete trust chain between controllers leads to redundant roaming authentication and increased average latency. (2) In multi-tenant and multi-VLAN deployment scenarios, due to the lack of a lateral access control mechanism for terminals within the tenant in the existing architecture, malicious terminals may use VLAN vulnerabilities or ARP spoofing to break through the isolation boundary, resulting in lateral access risks between or within tenants. (3) Traditional solutions adhere to the security logic of "access is trust", lack session-level and continuous zero-trust access control, cannot dynamically adjust access permissions according to terminal behavior status, and are difficult to cope with constantly changing network threats. (4) The current authentication system generally uses the terminal MAC address as the ID for authentication. However, MAC addresses are easily forged and tampered with, which allows unauthorized terminals to bypass the authentication mechanism and access the network by forging legitimate MAC addresses, posing a serious threat to the security isolation and data confidentiality of multi-tenant networks.

[0004] Therefore, there is an urgent need to provide a lightweight, cross-controller, and compatible zero-trust network access control method that is compatible with existing wireless architectures. Summary of the Invention

[0005] This application provides a multi-tenant zero-trust network access control method, system, and medium to solve technical problems such as high latency in existing technologies.

[0006] On the one hand, a method for access control in a multi-tenant zero-trust network is provided, the method comprising: Connect the terminal to the target AP based on the pre-shared key PPSK; The target AP reports the terminal access information to the local controller; The local controller interacts with the unified identity management system to obtain the network information corresponding to the terminal; wherein, the network information includes the tenant, role and original controller information of the terminal; A cloud management platform is used to orchestrate the network information to determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process. If it is determined that the terminal triggers the Zero Trust Network Access (ZTNA) process, then when it is determined that the terminal is roaming across controllers, a secure tunnel is established between the local controller and the original controller through the Zero Trust Access Gateway. The secure tunnel is used to perform authentication and access control on the terminal.

[0007] Optionally, the step of using the secure tunnel to perform authentication and access control on the terminal includes: Using the aforementioned secure tunnel, the terminal undergoes Zero Trust Network Access (ZTNA) chain verification to obtain verification results. The ZTNA chain verification process is based on a three-tier controller architecture, which divides the network topology into domain controllers, tenant controllers, and local controllers. The ZTNA chain verification sequentially verifies the local controller, tenant controller, and domain controller. Based on the verification results, access control is applied to the terminal. Optionally, the step of using the secure tunnel to perform Zero Trust Network Access (ZTNA) chained verification on the terminal and obtaining the verification result includes: Using the aforementioned secure tunnel, the local identity information reported by the target AP is sent to the local controller for local-level verification, generating a local token; wherein, the local identity information includes MAC address, location, SSID, PPSK credential, and device fingerprint; The local token is verified at the tenant level using a tenant controller to generate a signed local token. The domain controller is used to perform domain-level verification on the signed local token, generating a verification result that includes a global trust token.

[0008] Optionally, the step of performing access control on the terminal based on the verification result includes: If the verification result indicates that the verification is successful, the zero-trust access gateway will issue an access control policy to the local controller. According to the access control policy, the local controller issues the application network policy to the target AP; According to the application network policy, the target AP is used to grant network access permissions to the terminal.

[0009] Optionally, the step of performing access control on the terminal based on the verification result includes: If the terminal is determined to be a privileged user, then a corresponding Management VLAN is dynamically assigned to the terminal; If the terminal is determined to be a visitor, then a corresponding Guest VLAN is dynamically assigned to the terminal; If the terminal is determined to be a regular user, then a corresponding User VLAN is dynamically assigned to the terminal; If the terminal is determined to be an IoT device, then a corresponding IoT VLAN is dynamically assigned to the terminal.

[0010] Optionally, the step of performing Zero Trust Network Access (ZTNA) chain verification on the terminal to obtain the verification result includes: For a token generated at any level in the three-layer controller architecture, determine whether the expiration rate of the token is greater than a first preset threshold. If the expiration rate of the token is determined to be greater than a first preset threshold, a preset smart model is triggered to perform re-verification.

[0011] Optionally, the step of triggering the preset intelligent model to perform re-verification includes: The terminal's behavioral characteristics, device status, location changes, time factors, authentication frequency, and threat intelligence are input into a preset intelligent model for re-verification to obtain a trust score. The target trust level of the terminal is determined based on the trust score and trust level mapping table. Based on the target trust level, perform the operation corresponding to the target trust level.

[0012] Optionally, after using the secure tunnel to authenticate and control access to the terminal, the method further includes: If the terminal traffic is public network traffic, then the local controller will be used for local traffic offloading; If the terminal traffic is internal network traffic, then a secure tunnel generated by zero-trust access is used for traffic backhaul.

[0013] Optionally, after performing Zero Trust Network Access (ZTNA) chain verification on the terminal and obtaining the verification result, the method further includes: A preset intelligent model is used to perform Keep-Alive detection on the secure tunnel to determine whether the link attenuation value of the WireGuard tunnel is greater than the preset attenuation threshold. If the link attenuation value of the secure tunnel is determined to be greater than the preset attenuation threshold, the system will automatically switch to the backup domestic tunnel for data transmission.

[0014] On the one hand, a multi-tenant zero-trust network access control system is provided, the system comprising: The terminal is used to access the target AP based on the pre-shared key sPSK; The target AP is used to report local identity information to the local controller; A unified identity management system is used to interact with the local controller and provide network information corresponding to the terminal; wherein, the network information includes the tenant, role and original controller information of the terminal; The cloud management platform is used to orchestrate the network information and determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process. A zero-trust access gateway is used to establish a secure tunnel between the local controller and the original controller when it is determined that the terminal triggers the zero-trust network access (ZTNA) process and cross-controller roaming occurs. The local controller is used to perform local-level verification on the local identity information reported by the target AP and generate a local token; wherein, the local identity information includes MAC address, location, SSID, PPSK credential and device fingerprint; The tenant controller is used to perform tenant-level verification on the local token and generate a signed local token. The domain controller is used to perform domain-level verification on the signed local token and generate a verification result containing a global trust token.

[0015] On the one hand, a storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement any of the methods described above.

[0016] Compared with the prior art, the beneficial effects of this application are as follows: In this application, when performing multi-tenant network access control, firstly, the terminal can be connected to the target AP based on the pre-shared key PPSK; then, the target AP can report the terminal access information to the local controller; next, the local controller can interact with the unified identity management system to obtain the network information corresponding to the terminal; wherein, the network information includes the tenant, role, and original controller information of the terminal; then, the cloud management platform can perform policy orchestration on the network information to determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process; if it is determined that the terminal triggers the ZTNA process, when it is determined that the terminal roams across controllers, a secure tunnel is established between the local controller and the original controller through the zero trust access gateway; finally, the secure tunnel can be used to perform authentication and access control on the terminal.

[0017] Based on this, in this application, since the Zero Trust Network Access (ZTNA) process is triggered during network access control, compared with the prior art, this application not only enables secure access and dynamic trust adaptation, but also improves the resistance to quantum attacks. In addition, since a terminal can quickly establish a secure tunnel through the Zero Trust Access Gateway when roaming across controller domains for subsequent authentication and access control, compared with the prior art, this application does not require repeated access configuration or authentication, achieving "uninterrupted roaming and seamless access", and solving the problems of roaming lag and cumbersome reconnection in multi-controller deployment scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A schematic diagram of an architecture for a multi-tenant zero-trust network access control system provided in an embodiment of this application; Figure 2 A flowchart illustrating a multi-tenant zero-trust network access control method provided in an embodiment of this application; Figure 3 A logical diagram illustrating micro-segmentation access control based on terminal roles provided in an embodiment of this application; Figure 4 A logical diagram illustrating the dynamic trust scoring provided in this application embodiment; Figure 5 A logical diagram illustrating multi-path traffic splitting and forwarding provided in an embodiment of this application; Figure 6 A schematic diagram illustrating the acquisition of tenant location information provided in an embodiment of this application; Figure 7 This is a schematic diagram of a hierarchical and domain-based ZTNA chain trust verification process provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0021] Currently, in existing Multiple Dwelling Unit (MDU) scenarios, multi-tenant shared wireless networks have become the mainstream deployment mode. Its core architecture is usually based on tenant isolation authentication with pre-shared keys PPSK / sPSK, unified management by a centralized controller, and data transmission through CAPWAP tunnels to meet the flexibility and isolation requirements of multi-tenants for network access.

[0022] However, the existing MDU multi-tenant wireless network access and roaming architecture has the following problems: (1) The lack of dynamic identity re-verification mechanism in the cross-controller roaming process poses a security risk of terminal hijacking and illegal impersonation for cross-domain roaming; in addition, the incomplete trust chain between controllers leads to redundant roaming authentication and increased average latency. (2) In multi-tenant and multi-VLAN deployment scenarios, due to the lack of a lateral access control mechanism for terminals within the tenant in the existing architecture, malicious terminals may use VLAN vulnerabilities or ARP spoofing to break through the isolation boundary, resulting in lateral access risks between or within tenants. (3) Traditional solutions adhere to the security logic of "access is trust", lack session-level and continuous zero-trust access control, cannot dynamically adjust access permissions according to terminal behavior status, and are difficult to cope with constantly changing network threats. (4) The current authentication system generally uses the terminal MAC address as the ID for authentication. However, MAC addresses are easily forged and tampered with, which allows unauthorized terminals to bypass the authentication mechanism and access the network by forging legitimate MAC addresses, posing a serious threat to the security isolation and data confidentiality of multi-tenant networks.

[0023] It is worth noting that terminal roaming across controllers in the MDU scenario is similar in security semantics to the access reconstruction process of Bring Your Own Device (BYOD) terminals in different network domains—both are essentially "redistributing access policies based on existing identity information at a new access point." Unlike traditional ZTNA (which typically relies on UE client installation for enterprise remote access), the ZTNA mechanism of this invention is more inclined towards a clientless MDU zero-trust access model: it is compatible with the traditional UE client installation method (achieving multi-factor authentication and effectively solving the security risks of single MAC address authentication), and can also combine PPSK / terminal characteristics (such as MAC address, device fingerprint, SSID, etc.) in the MDU scenario to achieve clientless identity recognition, thereby introducing zero-trust access control capabilities without changing the existing wireless access architecture.

[0024] Based on this, this application provides a multi-tenant zero-trust network access control method. In this method, firstly, a terminal can be connected to a target AP based on a pre-shared key (PPSK). Then, the target AP can report the terminal access information to the local controller. Next, the local controller can interact with a unified identity management system to obtain network information corresponding to the terminal. This network information includes the terminal's tenant, role, and original controller information. Then, a cloud management platform can orchestrate policies on the network information to determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process. If the terminal triggers the ZTNA process, when the terminal is determined to be roaming across controllers, a secure tunnel is established between the local controller and the original controller through a zero-trust access gateway. Finally, the secure tunnel can be used to authenticate and control the terminal's access. Based on this, in this application, since the Zero Trust Network Access (ZTNA) process is triggered during network access control, compared with the prior art, this application not only enables secure access and dynamic trust adaptation, but also improves the resistance to quantum attacks. In addition, since a terminal can quickly establish a secure tunnel through the Zero Trust Access Gateway when roaming across controller domains for subsequent authentication and access control, compared with the prior art, this application does not require repeated access configuration or authentication, achieving "uninterrupted roaming and seamless access", and solving the problems of roaming lag and cumbersome reconnection in multi-controller deployment scenarios.

[0025] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0026] like Figure 1 The diagram shown is an architectural schematic of a multi-tenant zero-trust network access control system provided in this application embodiment. The system includes a terminal, a target AP, a unified identity management system, a cloud management platform, a zero-trust access gateway, a local controller, a tenant controller, and a domain controller.

[0027] Specifically, the terminal can be used to access the target AP and perform initial authentication with the target AP based on the shared pre-shared key (sPSK).

[0028] The target AP is used to report local identity information to the local controller.

[0029] A unified identity management system is used to interact with the local controller and provide network information corresponding to the terminal; wherein, the network information includes the tenant, role and original controller information of the terminal; The cloud management platform is used to orchestrate the network information and determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process. A zero-trust access gateway is used to establish a secure tunnel between the local controller and the original controller when it is determined that the terminal triggers the zero-trust network access (ZTNA) process and cross-controller roaming occurs. The local controller is used to perform local-level verification on the local identity information reported by the target AP and generate a local token; wherein, the local identity information includes MAC address, location, SSID, PPSK credential and device fingerprint.

[0030] The tenant controller performs tenant-level verification on the local token and generates a signed local token. For example, it can perform a secondary signature on the local token based on a personalized pre-shared key PPSK / sPSK credential and the terminal's attitude data (e.g., terminal attitude data obtained through domestic EDR telemetry) to generate a signed local token. Furthermore, the tenant controller can also handle VLAN isolation or vTenant isolation.

[0031] A domain controller (e.g., a domestic cloud platform) is used to perform domain-level verification on the signed local token, generating a verification result containing a global trust token. For example, it can be used to perform multi-level aggregate signing on the signed local token based on the SM9 public-key cryptography algorithm, generating a verification result containing a global trust token (i.e., a Global Trust Token); this global trust token can drive a WireGuard / VXLAN domestic security tunnel to establish cross-domain backhaul. Furthermore, the domain controller can also manage global trust anchors.

[0032] In one possible implementation, each node corresponding to the local controller, tenant controller, and domain controller can also maintain a domain-specific trust chain and a local policy set, which are compatible with domestic EasyMesh and cloud-edge collaborative architectures. Domain-level nodes integrate distributed trust logs to ensure tamper-proof auditing, complying with the requirements of the Cybersecurity Law.

[0033] In one possible implementation, the system may further include a traffic splitting and self-healing access module, wherein the traffic splitting and self-healing access module can be used to perform Keep-Alive detection on the WireGuard tunnel using a preset intelligent model (e.g., the GenAI model) to determine whether the link attenuation of the WireGuard tunnel is greater than a preset attenuation threshold; if it is determined that the link attenuation of the WireGuard tunnel is greater than the preset attenuation threshold, the system will automatically switch to a backup domestic tunnel for data transmission.

[0034] In addition, this traffic offloading and self-healing access module can also be used for local traffic offloading for public network traffic; and for internal network resources, it can use a secure tunnel generated by ZTNA chain verification for backhaul.

[0035] In one possible implementation, the multi-tenant zero-trust network access control system of this application can also integrate domestic EMS and SASE gateways, be compatible with domestic EasyMesh and cloud platforms, and be extended to AIoT through "BeiDou + LoRa" bridging, with lightweight token protection for edge devices.

[0036] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1 The application scenarios shown can also be used in other possible scenarios, and this application embodiment does not impose any limitations. Figure 1 The functions that the various devices in the application scenarios shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here. Below, the methods of the embodiments of this application will be described in conjunction with the accompanying drawings.

[0037] like Figure 2The diagram shown is a flowchart of a multi-tenant zero-trust network access control method provided in this application embodiment. This method is applicable to MDU, 5G edge campus, smart park, and enterprise multi-controller / multi-domain hybrid wireless network environments. It is compatible with SASE (Secure Access Service Edge) and AIoT (AI+IoT) scenarios, supports 2025 security enhancements and preset intelligent-driven adaptive trust calculations, and can optimize for the needs of multi-tenant wireless networks in my country. Furthermore, it can also be achieved through… Figure 1 This method is implemented using a multi-tenant zero-trust network access control system. The specific process is described below.

[0038] Step 201: Connect the terminal to the target AP according to the pre-shared key PPSK.

[0039] In this application, as Figure 2 As shown, the terminal can access the target AP / Edge Node based on the pre-shared key PPSK / terminal fingerprint information.

[0040] Step 202: Use the target AP to report the terminal access information to the local controller.

[0041] The terminal access information includes context such as the MAC address, location, and time when the terminal accesses the network.

[0042] Step 203: Interact with the unified identity management system using the local controller to obtain the network information corresponding to the terminal.

[0043] The network information includes the tenant, role, and original controller information of the terminal.

[0044] In this application, in addition to interacting with the Unified Identity Management System (UIMS) to obtain the network information corresponding to the terminal, the local controller can also interact with the basic communication support system of Authentication Authorization and Accounting (AAA) to obtain the network information corresponding to the terminal, thereby achieving the purpose of querying tenant / ownership information and verifying device fingerprints.

[0045] Step 204: Use a cloud management platform to orchestrate network information policies and determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process.

[0046] In this application, in addition to using a cloud management platform (CMP) for policy orchestration, a policy orchestrator (PO) can also be used for policy orchestration.

[0047] Specifically, based on the tenant, role, and original controller information of the terminal in the network information, the cloud management platform can perform policy matching from the preset policy rule base. For example, if the tenant to which the terminal belongs is an unregistered tenant ID, then the terminal is determined to trigger the Zero Trust Network Access (ZTNA) process; if the terminal role is a temporary visitor, then the terminal is also determined to trigger the ZTNA process; if the terminal is a fixed terminal within the tenant (such as an office PC), the terminal security status is normal, and the terminal roams across controllers, then the terminal is determined not to trigger the ZTNA process.

[0048] In one possible implementation, such as Figure 2 As shown, if the multi-tenant zero-trust network access control system does not have a unified identity management system / AAA, then the cloud management platform can be used to orchestrate the terminal access information reported by the target AP to determine whether the terminal triggers the zero-trust network access (ZTNA) process.

[0049] Step 205: If it is determined that the terminal triggers the Zero Trust Network Access (ZTNA) process, then when it is determined that the terminal is roaming across controllers, a secure tunnel is established between the local controller and the original controller through the Zero Trust Access Gateway.

[0050] Step 206: Use a secure tunnel to authenticate and control the terminal.

[0051] Specifically, firstly, a secure tunnel can be used to perform Zero Trust Network Access (ZTNA) chain verification on the terminal to obtain verification results; wherein, the ZTNA chain verification process is based on a three-layer controller architecture; the three-layer controller architecture divides the network topology into domain controllers, tenant controllers, and local controllers; the ZTNA chain verification is performed sequentially using the local controller, tenant controller, and domain controller; Then, access control can be directly applied to the terminal based on the verification results.

[0052] In one possible implementation, when using a secure tunnel to perform Zero Trust Network Access (ZTNA) chain verification on the terminal to obtain the verification result, firstly, a secure tunnel can be used to send the local identity information reported by the target AP to the local controller for local-level verification based on the SM2 domestic cryptographic algorithm to generate a local token; wherein, the local identity information includes MAC address, location, SSID, PPSK credential and device fingerprint.

[0053] Then, based on the personalized pre-shared key PPSK and the terminal's attitude data, the tenant controller can perform tenant-level verification on the local token (e.g., verifying tenant affiliation, role mapping, and local policy detection) to generate a signed local token. Finally, based on the SM9 public-key cryptography algorithm, a domain controller can be used to perform domain-level verification on the signed local token (e.g., global authentication, central policy library, cross-domain identity federation) to generate a verification result containing a global trust token.

[0054] Based on this, since the SM2 domestic cryptographic algorithm can be used for lightweight edge node signatures and the SM9 public key cryptographic algorithm can be used for global trust anchor generation, this application can further reduce the latency of cross-domain signatures by combining the two.

[0055] In one possible implementation, when performing access control on the terminal based on the verification result, such as Figure 2 As shown, if the verification result indicates that the verification is successful, the zero-trust access gateway sends an access control policy to the local controller. Then, according to the access control policy, the local controller sends an application network policy to the target AP. Finally, according to the application network policy, the target AP grants network access permissions to the terminal, thereby enabling the terminal to securely and continuously access the original tenant network resources in the new access domain.

[0056] In another possible implementation, when performing access control on the terminal based on the verification result, "micro-segmentation access control based on terminal role" can also be performed, such as... Figure 3 The diagram shown is a logical schematic of micro-segmentation access control based on terminal roles provided in an embodiment of this application.

[0057] Specifically, after identity verification, the role of the terminal can be determined. If the terminal is determined to be a privileged user, a corresponding Management VLAN can be dynamically assigned to the terminal; if the terminal is determined to be a visitor, a corresponding Guest VLAN can be dynamically assigned to the terminal; if the terminal is determined to be a regular user, a corresponding User VLAN can be dynamically assigned to the terminal; and if the terminal is determined to be an IoT device, a corresponding IoT VLAN can be dynamically assigned to the terminal.

[0058] In other words, in this application, the local controller can distinguish the terminal as a user terminal or an Internet of Things (IoT) device based on the terminal's identity information, and dynamically allocate the corresponding virtual local area network (VLAN) accordingly, and generate an access control list (ACL) based on the terminal role. Thus, when the terminals are located in the same VLAN or there is a need for cross-VLAN communication, fine-grained access restrictions can be implemented through the ACL to prevent lateral access between different tenants or different types of terminals.

[0059] Furthermore, such as Figure 3 As shown, when generating an ACL based on terminal roles, a corresponding Quality of Service (QoS) policy can be generated. Then, based on the dynamically allocated VLAN, the QoS policy is issued to the wireless access point (AP) / local controller. Next, the AP / local controller can perform verification and auditing based on the QoS policy. Then, based on the verification and auditing results, the terminal behavior can be monitored to determine whether the terminal access is compliant. If the terminal access is determined to be compliant, the terminal must maintain the current policy. Conversely, if the terminal access is determined to be non-compliant and constitutes abnormal behavior, the terminal will trigger a policy update and re-identify the terminal based on PPSK / certificate / MAC / terminal device fingerprint.

[0060] As can be seen, this application can achieve fine-grained micro-segmentation and zero-trust access control in multi-tenant and IoT scenarios without changing the existing wireless forwarding architecture.

[0061] In one possible implementation, when performing Zero Trust Network Access (ZTNA) chain verification on the terminal and obtaining the verification result, a "dynamic relay threshold" can be introduced for the token generated at any level in the three-layer controller architecture to avoid the problems of high latency and low access success rate that exist in static chaining.

[0062] Specifically, first, it can be determined whether the token's expiration rate is greater than a first preset threshold (e.g., 5%). Then, if the token's expiration rate is greater than the first preset threshold, a preset smart model can be triggered to re-verify the token. Conversely, if the token's expiration rate is not greater than the first preset threshold (i.e., the token has not expired), there is no need to continue signing the token.

[0063] In addition, to improve the efficiency of roaming re-verification, a "chain trust caching mechanism" can be added to this application, that is, the token is cached between different level controllers.

[0064] Furthermore, to improve prediction accuracy and access success rate, this application can also "perform a trust assessment of the terminal" when triggering a pre-set intelligent model for re-verification. For example... Figure 4 The diagram shown is a logical illustration of a dynamic trust scoring method provided in an embodiment of this application. The evaluation can employ... Figure 1 The preset intelligent model in the preset intelligent dynamic trust scoring engine is used for calculation, and each layer controller evaluates the trust score (0-100 points) through its own integrated domestic preset intelligent model (which is based on the open source PaddlePaddle framework).

[0065] Specifically, firstly, the terminal's behavioral characteristics (obtained through network behavior analysis), device status (obtained through security status detection), location changes (obtained through geographic anomaly detection), time factors (obtained through access period compliance), authentication frequency (obtained through authentication history assessment), and threat intelligence (obtained through implementation threat data) can be input into a preset intelligent model for re-verification to obtain a trust score. In this application, the scoring formula is as follows:

[0066] in, Rate trust; The weights can be obtained adaptively. Behavioral characteristics; Device status; For positional changes; Due to the time factor; For authentication frequency; For threat intelligence.

[0067] Then, the target trust level of the terminal can be determined according to the trust score and trust level mapping table. As shown in Table 1, this is a schematic table of a trust level mapping table provided in an embodiment of this application.

[0068] Table 1

[0069] Finally, based on the target trust level determined in Table 1 above, the operation corresponding to the target trust level can be executed.

[0070] Furthermore, in this application, the preset intelligent model is trained based on a certain Security Brain 2025 dataset, which can simulate domestic attack scenarios and has a prediction accuracy of over 98%.

[0071] In one possible implementation, to improve network utilization, enhance reliability, and achieve load balancing, this application, after employing the secure tunnel to authenticate and control the terminal, can also perform "multi-path traffic splitting and forwarding," such as... Figure 5 The diagram shown is a logical schematic of multi-path traffic splitting and forwarding provided in an embodiment of this application.

[0072] Specifically, firstly, the UE (User Equipment) traffic can be sent to the AP (Access Point); then, the AP can forward the user terminal traffic to the local controller (or gateway); subsequently, the local controller will determine the type of the user terminal traffic; if the terminal traffic is public network traffic (i.e., Internet traffic), the local controller can perform local traffic offloading, thereby forwarding the public network traffic to the Internet, with latency reduced to less than 10ms; if the terminal traffic is internal network resource (i.e., private traffic, such as home IoT), a secure tunnel generated by zero-trust access can be used for traffic backhaul, thereby forwarding the public network traffic to the original controller / original network.

[0073] As can be seen, in this application, internet traffic destined for the public network can be directly forwarded through the local egress point, while access traffic destined for the tenant's private network or original home network can be routed back to the original controller domain through the established secure tunnel. This traffic splitting mechanism makes decisions on the local controller or AP side, and is an access control routing based on identity and policy, rather than traditional SD-WAN routing based on link performance.

[0074] In one possible implementation, in order to improve bandwidth efficiency, after performing Zero Trust Network Access (ZTNA) chain verification on the terminal and obtaining the verification result, "self-healing access" can also be performed.

[0075] Specifically, a preset intelligent model can be used to perform Keep-Alive detection on the secure tunnel to determine whether the link attenuation value of the secure tunnel is greater than a preset attenuation threshold. The link attenuation value can be SLA indicators such as round-trip time (RTT), latency, packet loss rate, and bandwidth. If it is determined that the link attenuation value of the secure tunnel is greater than the preset attenuation threshold (e.g., 20%), the system will automatically switch to a backup domestic tunnel for data transmission to ensure session continuity.

[0076] In this application, self-healing access can optimize my country’s high-density MDU scenario (which has at least 1,000 UEs / APs) by supporting 5G NR edge integration.

[0077] In one possible implementation, before performing Zero Trust Network Access (ZTNA) chain verification on the terminal and obtaining the verification result, this application may also "set a policy layering mechanism".

[0078] The policy layering mechanism includes, in sequence, domain-level basic policies (e.g., SM4 encryption algorithm, SM9 public-key cryptography algorithm), tenant-level access policies (e.g., policies determined based on vTenant VLAN), and session-level real-time policies (e.g., policies generated by a pre-defined intelligent model). Furthermore, the policy layering mechanism employs a directed acyclic graph (DAG) model to implement policy inheritance, which uses a layer-by-layer overlay or overriding approach. For example, tenant-level access policies cover 80% of the domain-level basic policy rules. Consequently, management efficiency can be improved by deploying incremental ACLs and integrating AI tag suggestions.

[0079] In another possible implementation, the tenant-related data involved in this application (e.g., terminal posture data and tenant geographical location) are all obtained after obtaining the tenant's permission or consent; that is, when this application is applied to a specific product or technology, it is necessary to obtain the tenant's permission to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0080] For example, when it is necessary to obtain a tenant's current geographical location, a location acquisition prompt can be displayed on the tenant's terminal. After receiving confirmation from the tenant regarding the location acquisition prompt, the terminal can obtain the tenant's current geographical location, such as... Figure 6 The diagram shown is a schematic representation of obtaining tenant location information according to an embodiment of this application. Specific implementation examples: The following section provides a detailed introduction to "Hierarchical and Domain-Specific ZTNA Chained Trust Verification," such as... Figure 7The diagram shown is a flowchart of a hierarchical and domain-based ZTNA chain trust verification provided in this application embodiment, which is divided into three stages: "identity verification process", "policy distribution process" and "continuous verification and update".

[0082] Specifically, in the "identity verification process" phase, after the terminal identity is initially verified by the AP, the AP can first report local identity information (MAC address, location, SSID, PPSK, and device fingerprint, etc.) to the local controller for local verification. Then, after successful local verification, the local controller can send a tenant-level verification request to the tenant controller to verify tenant affiliation, role mapping, and local policy checks. Next, after successful tenant verification, the tenant controller can send a domain-level verification request to the domain controller for global authentication and cross-domain identity federation. Finally, after successful domain-level verification, the domain controller can return the verification results (global identity, security policy, compliance status, permission set, etc.) to the tenant controller.

[0083] During the "policy delivery process" phase, firstly, the tenant controller can deliver policy context (role policies, access control lists, QoS policies, session timeouts, etc.) to the local controller; then, the local controller can deliver access policies (VLAN allocation, ACL rules, rate limiting, forwarding rules, etc.) to the AP.

[0084] During the "Continuous Validation and Update" phase, firstly, the AP can send periodic status reports to the local controller; then, the local controller can periodically synchronize policies with the tenant controller; next, the tenant controller can update policies in real time with the domain controller; then, when policies change, the domain controller will send policy change notifications to the tenant controller; next, the tenant controller will dynamically adjust policies with the local controller; finally, the local controller will update access control with the AP.

[0085] The pseudocode for ZTNA chained trust verification is as follows: def chained_verify(ue_token, domain_id): local_sig = edge_sign(ue_token, sm2_key)# SM2 tenant_sig = tenant_merge(local_sig, posture_data)# GenAIpostureglobal_token = domain_aggregate(tenant_sig, sm9_key)# SM9 if genai_score(global_token)>threshold: establish_tunnel(global_token, vxlan_id) return global_token In addition, a pre-set intelligent enhanced dynamic trust scoring engine can be implemented in real time on a certain deep learning platform. For example, UE MAC, BeiDou location and traffic mode are input into the pre-set intelligent enhanced dynamic trust scoring engine, and a trust score S=95 is output. Therefore, Split-Tunnel needs to be enabled for acceleration.

[0086] When conducting roaming tests based on a certain telecommunications company, compared with traditional solutions, it reduced cross-controller latency and improved isolation rate.

[0087] In summary, this application proposes a multi-tenant zero-trust network access (ZTNA) control method. This method achieves cross-domain roaming network access control through a three-layer controller architecture (domain-level, tenant-level, and edge-level), an enhanced chained token relay mechanism, and micro-segmentation. Based on this, this application has the following advantages: (1) Through hierarchical autonomy and global unification, the overhead of cross-domain authentication is greatly reduced. (2) By pre-setting intelligent adaptive roaming, not only is the latency greatly reduced, but also 5G-MDU seamless switching is supported. (3) By enhancing the chain token relay mechanism, the ability to resist PQC attacks and the robustness of the trust chain are improved. (4) Through strategy layering and DAG model inheritance mechanism, not only is the management complexity greatly reduced, but it is also compatible with vTenant. (5) By using multi-path traffic splitting and self-healing access, not only has the SLA and bandwidth efficiency been improved, but it has also been adapted to my country's SASE ecosystem.

[0088] (6) Through micro-segmentation, fine-grained access restrictions are achieved, thereby preventing lateral access between different tenants or different types of terminals.

[0089] (7) Zero Trust Network Access (ZTNA) chain verification mechanism is compatible with the traditional UE client installation method, and can also be combined with PPSK / terminal features in MDU scenario to achieve clientless identification.

[0090] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. Alternatively, if the integrated units of this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of software products. These computer software products are stored in a storage medium and include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0091] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0092] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A multi-tenant zero-trust network access control method, characterized in that, The method includes: Connect the terminal to the target AP based on the pre-shared key PPSK; The target AP reports the terminal access information to the local controller; The local controller interacts with the unified identity management system to obtain the network information corresponding to the terminal; wherein, the network information includes the tenant, role and original controller information of the terminal; A cloud management platform is used to orchestrate the network information to determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process. If it is determined that the terminal triggers the Zero Trust Network Access (ZTNA) process, then when it is determined that the terminal is roaming across controllers, a secure tunnel is established between the local controller and the original controller through the Zero Trust Access Gateway. The secure tunnel is used to perform authentication and access control on the terminal.

2. The method as described in claim 1, characterized in that, The steps of using the secure tunnel to perform authentication and access control on the terminal include: Using the aforementioned secure tunnel, the terminal undergoes Zero Trust Network Access (ZTNA) chain verification to obtain verification results. The ZTNA chain verification process is based on a three-tier controller architecture, which divides the network topology into domain controllers, tenant controllers, and local controllers. The ZTNA chain verification sequentially verifies the local controller, tenant controller, and domain controller. Based on the verification results, access control is applied to the terminal.

3. The method as described in claim 2, characterized in that, The step of using the secure tunnel to perform Zero Trust Network Access (ZTNA) chained verification on the terminal and obtaining the verification result includes: Using the aforementioned secure tunnel, the local identity information reported by the target AP is sent to the local controller for local-level verification, generating a local token; wherein, the local identity information includes MAC address, location, SSID, PPSK credential, and device fingerprint; The local token is verified at the tenant level using a tenant controller to generate a signed local token. The domain controller is used to perform domain-level verification on the signed local token, generating a verification result that includes a global trust token.

4. The method as described in claim 2, characterized in that, The step of performing access control on the terminal based on the verification result includes: If the verification result indicates that the verification is successful, the zero-trust access gateway will issue an access control policy to the local controller. According to the access control policy, the local controller issues the application network policy to the target AP; According to the application network policy, the target AP is used to grant network access permissions to the terminal.

5. The method as described in claim 2, characterized in that, The step of performing access control on the terminal based on the verification result includes: If the terminal is determined to be a privileged user, then a corresponding Management VLAN is dynamically assigned to the terminal; If the terminal is determined to be a visitor, then a corresponding Guest VLAN is dynamically assigned to the terminal; If the terminal is determined to be a regular user, then a corresponding User VLAN is dynamically assigned to the terminal; If the terminal is determined to be an IoT device, then a corresponding IoT VLAN is dynamically assigned to the terminal.

6. The method as described in claim 2, characterized in that, The step of performing Zero Trust Network Access (ZTNA) chain verification on the terminal to obtain the verification result includes: For a token generated at any level in the three-layer controller architecture, determine whether the expiration rate of the token is greater than a first preset threshold. If the expiration rate of the token is determined to be greater than a first preset threshold, a preset smart model is triggered to perform re-verification.

7. The method as described in claim 6, characterized in that, The step of triggering the preset intelligent model to perform re-verification includes: The terminal's behavioral characteristics, device status, location changes, time factors, authentication frequency, and threat intelligence are input into a preset intelligent model for re-verification to obtain a trust score. The target trust level of the terminal is determined based on the trust score and trust level mapping table. Based on the target trust level, perform the operation corresponding to the target trust level.

8. The method as described in claim 1, characterized in that, After using the secure tunnel to perform authentication and access control on the terminal, the method further includes: If the terminal traffic is public network traffic, then the local controller will be used for local traffic offloading; If the terminal traffic is internal network traffic, then a secure tunnel generated by zero-trust access is used for traffic backhaul.

9. The method as described in claim 2, characterized in that, After performing Zero Trust Network Access (ZTNA) chain verification on the terminal and obtaining the verification result, the method further includes: A preset intelligent model is used to perform Keep-Alive detection on the secure tunnel to determine whether the link attenuation value of the WireGuard tunnel is greater than the preset attenuation threshold. If the link attenuation value of the secure tunnel is determined to be greater than the preset attenuation threshold, the system will automatically switch to the backup domestic tunnel for data transmission.

10. A multi-tenant zero-trust network access control system, characterized in that, The system includes: The terminal is used to access the target AP based on the pre-shared key sPSK; The target AP is used to report local identity information to the local controller; A unified identity management system is used to interact with the local controller and provide network information corresponding to the terminal; wherein, the network information includes the tenant, role and original controller information of the terminal; The cloud management platform is used to orchestrate the network information and determine whether the terminal triggers the Zero Trust Network Access (ZTNA) process. A zero-trust access gateway is used to establish a secure tunnel between the local controller and the original controller when it is determined that the terminal triggers the zero-trust network access (ZTNA) process and cross-controller roaming occurs. The local controller is used to perform local-level verification on the local identity information reported by the target AP and generate a local token; wherein, the local identity information includes MAC address, location, SSID, PPSK credential and device fingerprint; The tenant controller is used to perform tenant-level verification on the local token and generate a signed local token. The domain controller is used to perform domain-level verification on the signed local token and generate a verification result containing a global trust token.

11. A computer-readable storage medium, characterized in that, The storage medium stores computer-executable instructions for causing a computer to perform the method described in any one of claims 1 to 9.

Images