A gateway system and method for authenticating a single-domain IP multi-tuple of a trusted cloud native intranet

Abstract

This invention relates to the fields of network security and cloud-native computing, and discloses a gateway system and method for trusted cloud-native intranet single-domain IP tuple verification. The method includes collecting behavioral characteristics and business risks of each access device within a single domain, constructing a device behavior matrix, dividing logical security domains according to device characteristics, and generating a multi-dimensional hierarchical mapping structure; deploying hierarchical gateways at the access points of each logical security domain to form a preliminary policy execution topology; generating access state sequences and policy execution logs based on the preliminary policy execution topology and policy execution access control; reporting anomalies by logical security domain members, and the overall processing mechanism performing policy correction based on multi-domain consensus and anomaly weighting algorithms to generate cross-domain anomaly handling results; optimizing and aggregating access policies for each level of security domain; and constructing an end-to-end verifiable access control and adaptive security mechanism. This invention has the advantage of improving lateral penetration protection.

Description

Technical Field

[0001] This invention relates to the fields of network security and cloud-native computing, specifically to a gateway system and method for trusted cloud-native intranet single-domain IP tuple authentication. Background Technology

[0002] Traditional enterprise intranet security models often suffer from a "hard shell, soft core" security problem. Specifically, enterprises typically rely on perimeter firewalls and intrusion detection systems for external protection. Once attackers breach these defenses and enter the intranet, they can use techniques like IP spoofing and lateral movement to access internal network resources and steal core assets or sensitive information. This internal "trust gap" is prevalent in most enterprise intranets, leading to a significant decrease in internal security capabilities once the perimeter is breached. With the increasing adoption of cloud-native architectures and zero-trust security concepts, the industry has begun exploring more refined internal network security mechanisms, namely "micro-segmentation." Micro-segmentation enables fine-grained network isolation of different applications, containers, or nodes, achieving internal access control and lateral movement protection. However, in large-scale, dynamic... In cloud-native environments, achieving effective micro-segmentation faces two major technical challenges: First, the lack of a unified intra-domain trust root: Traditional networks lack hardware-anchored trusted root nodes, making it impossible to guarantee the integrity of policy execution and allowing network access control policies to be easily tampered with or bypassed. Second, the lack of a standardized isolation capability model: Different vendors or products have significantly different intranet isolation capabilities, making it difficult for users to conduct unified assessments and deploy on demand, while also hindering the formation of an evolvable and scalable isolation capability system. Furthermore, in large-scale network environments, relying on point-to-point policy definitions can lead to an O(N²) increase in the number of policies, resulting in explosive policy management complexity, unsustainable network governance, and increased operational difficulty and security risks. Therefore, designing a gateway system and method for trusted cloud-native intranet single-domain IP tuple authentication to improve lateral penetration protection is essential. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a gateway system and method for trusted cloud-native intranet single-domain IP tuple authentication, which has the advantage of improving lateral penetration protection and solves the problems mentioned in the background technology.

[0004] To achieve the aforementioned goal of improving lateral movement protection, this invention provides the following technical solution: a gateway method for trusted cloud-native intranet single-domain IP tuple authentication, comprising the following steps:

[0005] Collect the behavioral characteristics and business risks of each access device within a single domain, construct a device behavior matrix, divide logical security domains according to device characteristics, assign a corresponding network isolation level to each logical security domain, and generate a multi-dimensional level mapping structure.

[0006] Based on the multi-dimensional hierarchical mapping structure, a hierarchical gateway is deployed at the access point of each logical security domain. Hardware binding and hierarchical authorization are performed based on the single domain root of trust. The hierarchical policies of each domain are distributed to the gateway data execution end to form a preliminary policy execution topology.

[0007] Based on the initial policy execution topology and policy execution access control, low-level execution is based on IP address pairs for access control, medium-level execution is based on 5-tuples for access control, and high-level execution is based on dynamic hash admission control based on specific fields of the IPv6 extension header, generating access state sequences and policy execution logs.

[0008] The access state sequence and policy execution log are synchronized to the central processing mechanism. Logical security domain members report anomalies. The central processing mechanism performs policy correction based on multi-domain consensus and anomaly weight algorithm, and generates cross-domain anomaly handling results.

[0009] Based on the results of cross-domain anomaly handling, the logical security domain division, gateway level configuration, and policy parameters are dynamically adjusted, and the access policies of each security domain level are optimized and aggregated to build an end-to-end verifiable access control and adaptive security mechanism.

[0010] Preferably, the process of dividing logical security domains based on device characteristics is as follows:

[0011] Collect network communication behavior, port usage, protocol type, data traffic patterns, and application access characteristics of each device;

[0012] Record the device's service type, data sensitivity level, and historical access logs;

[0013] The collected behavioral features and business risks are mapped into multi-dimensional device vectors to construct a device behavior matrix, which contains the behavior vector and risk value of each device.

[0014] Devices are clustered based on device behavior matrices to form multiple logical security domains.

[0015] Preferably, the process of generating a multi-dimensional hierarchical mapping structure is as follows:

[0016] Assess the sensitivity of devices and services within multiple logical security domains to determine network access control requirements;

[0017] Assign appropriate network isolation levels and determine the granularity of access control policies for each level;

[0018] Establish a mapping relationship between logical security domains and levels to form a multi-dimensional level mapping structure, including domain identifiers, level identifiers, policy references, and member device lists.

[0019] Preferably, the process of hardware binding and hierarchical authorization based on a single-domain root of trust is as follows:

[0020] The boundaries of each logical security domain are determined based on the multi-dimensional hierarchical mapping structure, and the required gateway level type for each boundary is determined.

[0021] Deploy gateways of the corresponding level at the access points of each logical security domain, including ingress and egress locations;

[0022] The deployed gateway is hardware-bound to a single-domain root of trust, and the device's unique identifier and cryptographic credentials are loaded.

[0023] Configure hierarchical authorization information for each gateway, including access policies for different security levels, policy execution permissions, and the scope of operation and management.

[0024] Preferably, the process of forming the initial strategy execution topology is as follows:

[0025] Obtain logical security domain access policies from the management unit, including access permission or denial, ports, protocols, and flow rules;

[0026] The obtained policies are parsed and transformed, and combined with the level and hierarchical authorization information of each gateway, the policies are mapped into a rule format that can be recognized and executed by the corresponding gateway.

[0027] At each gateway, an initial policy execution path is generated based on policies and authorization permissions, including intra-domain traffic paths and cross-domain traffic paths;

[0028] The rules are sent to the corresponding gateways, and the policy cache and path information are initialized on the gateway side. At the same time, the consistency between the policy execution permissions and the hierarchical authorization is verified.

[0029] By aggregating the rules and path information of each gateway, a preliminary overall policy execution topology is formed.

[0030] Preferably, the process of generating access state sequences and policy execution logs is as follows:

[0031] Execute the topology according to the initial strategy, and apply access control policies to the gateways according to their security levels;

[0032] Lower-level gateways perform access control based on source and destination addresses and verify communication traffic;

[0033] Intermediate-level gateways implement access control based on source address, source port, destination address, destination port, and protocol;

[0034] High-level gateways implement deep access control based on packet extension header fields, generating access state sequences and policy execution logs.

[0035] Preferably, the process for generating cross-domain anomaly handling results is as follows:

[0036] The access status sequence and policy execution log of each logical security domain are synchronized to the central processing mechanism in real time.

[0037] The aggregated abnormal data is standardized, and the abnormal events are mapped to a multi-dimensional security indicator space.

[0038] Based on a preset anomaly weighting algorithm, the impact range, potential risk level, and associated logical security domain of anomaly events are quantitatively assessed.

[0039] For abnormal events involving multiple logical security domains, a multi-domain consensus mechanism is used to determine the credibility and processing priority of the abnormal event.

[0040] Based on the anomaly analysis results, policy modification suggestions are generated, including a list of affected devices, abnormal access paths, the logical security domains involved, and recommended access control adjustment measures.

[0041] The results of anomaly analysis are integrated with the suggestions for strategy correction to form cross-domain anomaly handling results.

[0042] Preferably, the process of dynamically adjusting the logical security domain division, gateway level configuration, and policy parameters is as follows:

[0043] Based on the results of cross-domain anomaly handling, the behavioral characteristics and business risk levels of members in each logical security domain are reassessed.

[0044] Based on the assessment results, the devices are re-clustered, and the logical security domain division and member list are updated.

[0045] Adjust the gateway level configuration of each domain according to the updated logical security domain division;

[0046] Update access rules, traffic limits, and tiered authorization information, and synchronize the updated policies to each gateway execution end.

[0047] Preferably, the process of constructing an end-to-end verifiable access control and adaptive security mechanism is as follows:

[0048] After completing the logical security domain division adjustment, gateway level configuration update and policy parameter modification, the access policies, execution logs and policy change history of each domain will be summarized.

[0049] The aggregated strategies are structured and optimized to remove redundancy, adjust priorities, and aggregate to generate a unified strategy library, while maintaining the policy granularity that can be mapped to gateways at all levels.

[0050] The aggregation policy is distributed to gateways at all levels to establish an end-to-end policy execution path and ensure that policy version control, execution order and consistency are traceable.

[0051] The policy is adjusted in real time according to changes in logical security domain or gateway configuration, thus completing the construction of end-to-end verifiable access control and adaptive security mechanisms.

[0052] A trusted cloud-native intranet single-domain IP tuple authentication gateway system includes:

[0053] Feature segmentation module: responsible for collecting device behavior and business risks, constructing a device matrix and dividing logical security domains, and generating a multi-dimensional hierarchical mapping structure;

[0054] Policy delivery module: Delivers the level policies of logical security domains to the gateway execution end, and completes gateway deployment and hardware binding authorization to form a policy execution topology;

[0055] Access control module: Implements hierarchical access control for different levels based on the policy topology, and generates access status sequences and policy execution logs;

[0056] Exception handling module: collects access status and logs, processes exceptions reported by logical security domains, adjusts strategies through multi-domain consensus, and generates cross-domain exception handling results;

[0057] Policy optimization module: Based on the results of cross-domain exception handling, dynamically adjust the logical security domain and gateway level, optimize and aggregate access policies, and build an end-to-end verifiable access control and adaptive security mechanism.

[0058] Compared with existing technologies, this invention provides a gateway system and method for trusted cloud-native intranet single-domain IP tuple authentication, which has the following beneficial effects:

[0059] This invention constructs a unified, hardware-anchored single-domain trust root to implement hierarchical control of access gateways, achieving authoritative IP-identity binding and tamper-proof policy execution. This fundamentally eliminates the possibility of internal network IP spoofing. Simultaneously, it standardizes and ranks network isolation capabilities, mapping abstract network isolation capabilities to multiple technical levels such as tuples, quintuples, and IPv6 extended header hashes, and binding them to the TCDNIS grading system. This provides a unified benchmark for evaluating and comparing the true capabilities of different network security products. Through TCDNMU's regional planning and policy dimensionality reduction methods, the exponentially growing point-to-point policies are reduced to inter-domain policies based on logical security domains, significantly alleviating the policy explosion problem in large-scale micro-segmentation environments. By combining the collection and analysis of behavioral characteristics and business risks of each access device within a single domain, a device behavior matrix is ​​constructed and logical security domains are divided to form hierarchical network isolation and policy distribution. With the cooperation of hierarchical access control, anomaly reporting and multi-domain consensus correction mechanisms, dynamic adjustment and optimization iteration of policies can be achieved. Capabilities at each level can be deployed on DPU / SPU hardware acceleration execution to provide line-speed processing capabilities, making internal network protection both refined and high-performance. This effectively prevents lateral penetration and IP spoofing, improves access control credibility, solves the security weakness of traditional enterprise internal networks with a hard shell and a soft kernel, and significantly enhances the executability, traceability and adaptive adjustment capabilities of internal network policies, realizing the technological progress from static protection to intelligent, full-domain closed-loop protection. Attached Figure Description

[0060] Figure 1 This is a schematic diagram of the method of the present invention;

[0061] Figure 2 This is a schematic diagram of the structure of the present invention. Detailed Implementation

[0062] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0063] Example 1: Please refer to Figure 1 As shown in the embodiment of the present invention, a gateway method for trusted cloud-native intranet single-domain IP tuple authentication includes the following steps:

[0064] S1: Collect the behavioral characteristics and business risks of each access device within a single domain, construct a device behavior matrix, divide logical security domains according to device characteristics, assign a corresponding network isolation level to each logical security domain, and generate a multi-dimensional level mapping structure.

[0065] The process of dividing logical security domains based on device characteristics in S1 is as follows:

[0066] Collect network communication behavior, port usage, protocol type, data traffic patterns, and application access characteristics of each device;

[0067] By deploying network probes, switch port mirroring, or traffic acquisition devices within a single domain, each device connected to the gateway is continuously monitored, and network communication behavior data is collected. The collected communication behavior includes source IP address, destination IP address, communication time period, communication frequency, and communication session duration. Port usage involves the open source and destination ports of the device. Protocol types include TCP, UDP, ICMP, and application layer protocols such as HTTP, HTTPS, and MQTT. Data traffic patterns record the packet size, transmission rate, peak traffic, and average traffic for each session. Application access characteristics collect the specific application service types accessed by the device, access frequency, and service port combinations. Through this multi-dimensional data, the communication characteristics and behavior patterns of each device in the network can be comprehensively characterized, providing a data foundation for logical security domain segmentation.

[0068] Record the device's service type, data sensitivity level, and historical access logs;

[0069] The system collects the business attributes and historical access information of each device. Each device is labeled with its business type, such as database server, office terminal, IoT sensor, etc. The data sensitivity level records the data category processed by the device, such as low sensitivity (logs, monitoring data), medium sensitivity (user information, internal documents), and high sensitivity (transaction data, authentication information). Historical access logs include network resources accessed by the device in the past, abnormal access records, and permission change information. By combining the business type and data sensitivity level with the access logs, business risk assessment indicators can be established for each device, so that the security attributes of the device are directly related to the security impact it may have in the intranet, providing a basis for clustering and policy division.

[0070] The collected behavioral features and business risks are mapped into multi-dimensional device vectors to construct a device behavior matrix, which contains the behavior vector and risk value of each device.

[0071] The original features are uniformly quantified, integrating the network behavior characteristics, port usage patterns, protocol types, traffic patterns, application access characteristics, and business risk indicators of each device into a multi-dimensional vector. To maintain data comparability, standardization or normalization methods are used to map each feature to a unified numerical range. Categorical variables such as protocol type and business type are then encoded into computable vector forms. Finally, the vectors of all devices are combined row-wise to form a device behavior matrix. Each row of the matrix represents the comprehensive behavior and risk characteristics of a device, and each column corresponds to a feature dimension or risk indicator. By constructing the device behavior matrix, the similarity and differences between devices can be mathematically quantified, providing a direct basis for the clustering and partitioning of logical security domains.

[0072] Devices are clustered based on device behavior matrices to form multiple logical security domains;

[0073] By analyzing the device behavior matrix using clustering algorithms, devices with similar characteristics and similar business risk levels are grouped into multiple logical security domains. Each logical security domain contains a set of devices with similar behavioral patterns and related risk characteristics, which can reflect their potential security associations within the network. During the clustering process, the number of clusters or clustering thresholds can be set according to security policy requirements to balance network isolation granularity and management complexity. The resulting logical security domains not only provide a structured foundation for the subsequent distribution of hierarchical gateway policies, but also closely link network isolation, access control, and policy optimization with actual device behavior and business risks, realizing an operable mapping from device behavior characteristics to security domain division.

[0074] The process of generating the multidimensional hierarchical mapping structure in S1 is as follows:

[0075] Assess the sensitivity of devices and services within multiple logical security domains to determine network access control requirements;

[0076] A comprehensive assessment is conducted on the devices within each logical security domain defined in the previous step. This assessment includes the device's behavioral characteristics, communication patterns, port and protocol usage, as well as its business type and data sensitivity level. Business sensitivity reflects the importance and confidentiality of the data processed by the device or service, such as low sensitivity, general sensitivity, and high sensitivity levels. During the assessment process, the device's behavioral characteristics are combined with the business sensitivity, and a risk quantification algorithm is used to calculate the comprehensive risk value of each security domain. Based on this, the network access control requirements are analyzed, including the scope of access objects, access frequency restrictions, traffic priority, and isolation granularity.

[0077] Assign appropriate network isolation levels and determine the granularity of access control policies for each level;

[0078] After assessing the risks and access control requirements of each logical security domain, a corresponding level is assigned to each security domain according to a predefined network isolation level system. Each level not only represents the security strength but also corresponds to different access control policy granularities. Low-level domains implement coarse-grained access control based on IP address pairs, medium-level domains implement fine-grained access control, and high-level domains implement deep verification and admission control based on IPv6 extension header hash values. By binding the granularity of access control policies with levels, policy standardization and hierarchicalization are achieved.

[0079] Establish a mapping relationship between logical security domains and levels to form a multi-dimensional level mapping structure, including domain identifiers, level identifiers, policy references, and member device lists;

[0080] Each logical security domain is associated with its assigned network isolation level, access policy, and member devices to construct a multi-dimensional level mapping structure. Each security domain corresponds to a unique domain identifier, recording its assigned level identifier, the set of access policies it references, and a list of all devices within the domain and their corresponding identity binding information. The multi-dimensional level mapping structure can be stored in the TCDNMU's management database and synchronized to each gateway execution point via API to ensure the traceability and executability of policy issuance, providing clear data basis for policy execution and anomaly handling.

[0081] S2: Based on the multi-dimensional hierarchical mapping structure, deploy hierarchical gateways at the access points of each logical security domain, rely on single-domain trust roots for hardware binding and hierarchical authorization, and distribute the hierarchical policies of each domain to the gateway data execution end to form a preliminary policy execution topology.

[0082] The process of hardware binding and hierarchical authorization based on a single-domain root of trust in S2 is as follows:

[0083] The boundaries of each logical security domain are determined based on the multi-dimensional hierarchical mapping structure, and the required gateway level type for each boundary is determined.

[0084] The multi-dimensional hierarchical mapping structure generated in the previous step is read, which contains the domain identifier, allocation level, policy reference, and member device list of each logical security domain. By analyzing the number of member devices, business sensitivity, and access control policy granularity of each security domain, the boundary location of each security domain is determined, including data flow in / out points and key connection nodes. Based on the network isolation level assigned to each security domain, the gateway level type to be deployed at the boundary is determined. For example, a gateway supporting tuple access control is deployed in a low-level domain, a gateway supporting quintuple access control is deployed in a medium-level domain, and a gateway supporting IPv6 extension header hash deep verification is deployed in a high-level domain. In this way, the physical and logical deployment of security domain boundaries is directly associated with the policy level, ensuring the accuracy and controllability of subsequent policy execution.

[0085] Deploy gateways of the corresponding level at the access points of each logical security domain, including ingress and egress locations;

[0086] Gateways are deployed at the access points of each logical security domain. The ingress gateway is responsible for monitoring and controlling all traffic entering the security domain, while the egress gateway is responsible for monitoring and controlling traffic leaving the security domain, so as to achieve bidirectional access control.

[0087] The deployed gateway is hardware-bound to a single-domain root of trust, and the device's unique identifier and cryptographic credentials are loaded.

[0088] Each gateway is hardware-bound to a single-domain root of trust. During the hardware binding process, the gateway loads a unique device identifier and cryptographically signed credentials to ensure that the identity and policies are tamper-proof. The single-domain root of trust serves as the trust anchor point for the entire intranet, storing and managing the gateway's identity information and authorization credentials, ensuring that all issued policies can only be executed by the legitimately bound gateway.

[0089] Configure hierarchical authorization information for each gateway, including access policies for different security levels, policy execution permissions, and the scope of operation and management;

[0090] Furthermore, hierarchical authorization information is loaded into each gateway. This hierarchical authorization information includes the set of access policies corresponding to the level, policy execution permissions, and the scope of operation and management. Based on the level of the gateway, high-level policies are distributed to high-level gateways, and low-level policies are distributed to low-level gateways, thus achieving matching between policies and gateway levels. At the same time, the authorization information is protected by cryptographic signature and timestamp mechanisms to ensure that policy execution permissions cannot be modified without authorization during runtime.

[0091] The process of forming the initial strategy execution topology in S2 is as follows:

[0092] Obtain logical security domain access policies from the management unit, including access permission or denial, ports, protocols, and flow rules;

[0093] The gateway of each logical security domain first obtains the corresponding set of access policies through the security management unit. The access policies include information such as allowed or denied traffic rules, source / destination ports, protocol types, and flow paths. Through the policy interface API or control plane communication protocol, the policy data is structured into a parsable format, such as JSON or YAML, to ensure that the policy content is complete and machine readable.

[0094] The obtained policies are parsed and transformed, and combined with the level and hierarchical authorization information of each gateway, the policies are mapped into a rule format that can be recognized and executed by the corresponding gateway.

[0095] The policy is parsed, converting the abstract policy at the logical security domain level into a rule format that can be executed by each gateway. During the parsing process, the policy is determined by combining the low, medium, and high level information and hierarchical authorization information of each gateway to determine which policy items are applicable to that gateway and how to map protocol, port, and flow rules. For example, a high-level gateway may need to extend the policy into a deep admission rule based on IPv6 extended header hash, a medium-level gateway may parse it into a five-tuple rule, and a low-level gateway may parse it into a two-tuple rule.

[0096] At each gateway, an initial policy execution path is generated based on policies and authorization permissions, including intra-domain traffic paths and cross-domain traffic paths;

[0097] Each gateway generates an initial policy execution path based on local policies and hierarchical authorization. The path includes intra-domain traffic paths and cross-domain traffic paths, which clarifies the processing order and forwarding rules of data packets between gateways. Using the gateway's built-in flow tables or policy cache, the parsed rules are loaded into the data plane, and access control decision logic is established, enabling the gateway to make real-time decisions based on the path rules when traffic arrives, thereby achieving policy enforcement.

[0098] The rules are sent to the corresponding gateways, and the policy cache and path information are initialized on the gateway side. At the same time, the consistency between the policy execution permissions and the hierarchical authorization is verified.

[0099] The parsed and mapped policy rules are sent to the corresponding gateway through a secure communication channel. At the same time, the policy cache and path information are initialized on the gateway. During the initialization process, the gateway verifies whether the rules are consistent with its hierarchical authorization information, including policy execution permissions, allowed operation types, and manageable traffic range, to ensure that each policy does not exceed the gateway's permissions when executed, thereby preventing policy execution failure or security vulnerabilities due to permission mismatch.

[0100] The rules and path information of each gateway are aggregated to form an overall preliminary policy execution topology;

[0101] After completing the policy deployment and cache initialization at the gateway, the management unit summarizes the rule information and traffic paths of each gateway to generate an overall preliminary policy execution topology. This topology clarifies the traffic paths between logical security domains, the distribution of gateway levels, and the application of policies, providing a unified reference for policy optimization, anomaly detection, and dynamic adjustment.

[0102] S3: Based on the initial policy execution topology and policy execution access control, low-level execution is based on IP address pairs for access control, medium-level execution is based on 5-tuples for access control, and high-level execution is based on dynamic hash admission control based on specific fields of the IPv6 extension header, generating access state sequences and policy execution logs.

[0103] The process of generating access state sequences and policy execution logs in S3 is as follows:

[0104] Execute the topology according to the initial strategy, and apply access control policies to the gateways according to their security levels;

[0105] Based on the initial strategy, the topology is executed, and access control policies are applied to gateways in each logical security domain according to their security levels. Each gateway reads the corresponding policy rules from its local cache, including allowed or denied traffic, port numbers, protocol types, and flow paths. The security control module performs real-time checks on data packets to ensure that the policies are consistent with the gateway level and hierarchical authorization information.

[0106] Lower-level gateways perform access control based on source and destination addresses and verify communication traffic;

[0107] In low-level gateways, the policy enforcement engine checks the source and destination IP addresses of incoming and outgoing data packets, matches the source / destination IPs of the data packets with policy rules and local device binding tables, verifies the legitimacy of the traffic, rejects or drops unauthorized communication traffic, and records it in the policy enforcement log, providing initial protection for micro-segmented network environments and preventing simple IP spoofing and unauthorized access.

[0108] Intermediate-level gateways implement access control based on source address, source port, destination address, destination port, and protocol;

[0109] In a mid-level gateway, the policy enforcement engine parses the five-tuple information of data packets, including source IP, source port, destination IP, destination port, and transport protocol. It compares the five-tuple information with policy rules and security authorizations to determine whether traffic should be allowed to pass. Data packets that match are forwarded normally, while data packets that do not match are blocked. At the same time, detailed access status entries and policy enforcement logs are generated. Through five-tuple-level control, the mid-level gateway can achieve micro-segmentation at the port and protocol levels, improve policy granularity, make network isolation more accurate, and adapt to complex application scenarios.

[0110] The high-level gateway performs deep access control based on packet extension header fields, generating access state sequences and policy execution logs;

[0111] In high-level gateways, the policy enforcement engine parses the extension header fields of IPv6 packets or other protocols that support extension headers, calculates the hash value of specific fields, and compares them with the policy library in real time. This calculation is performed at the hardware level to ensure line-speed processing. At the same time, it generates access state sequences and policy enforcement logs. The access state sequences record the decision status of each traffic flow during the gateway's processing, including allow, deny, or anomaly marking. The policy enforcement logs record rule matching results, processing timestamps, packet identifiers, and execution paths, achieving a high level of deep verification to ensure that sensitive traffic is strictly controlled. It also provides traceable and auditable data records, providing a basis for policy optimization and dynamic adjustment.

[0112] S4: Synchronize the access state sequence and policy execution log to the main processing mechanism. Logical security domain members report anomalies. The main processing mechanism executes policy correction based on multi-domain consensus and anomaly weight algorithm, and generates cross-domain anomaly handling results.

[0113] The process of generating cross-domain exception handling results in S4 is as follows:

[0114] The access status sequence and policy execution log of each logical security domain are synchronized to the central processing mechanism in real time.

[0115] Gateways within each logical security domain will upload the generated access status sequence and policy execution logs to the central processing mechanism in real time, according to security level and time sequence. The integrity and tamper-proof nature of data transmission are ensured through a secure communication channel. At the same time, preliminary data verification and deduplication are performed at the receiving end, providing a complete and comparable data foundation for cross-domain anomaly detection, and ensuring that subsequent anomaly analysis covers access behavior in all security domains.

[0116] The aggregated abnormal data is standardized, and the abnormal events are mapped to a multi-dimensional security indicator space.

[0117] The overall processing mechanism standardizes the aggregated access state sequences and policy execution logs, unifying the log formats generated by different gateways, unifying timestamps and event codes, and extracting key anomaly information, such as unauthorized access, policy violations, and abnormal traffic paths. Subsequently, the abnormal events are mapped to a multi-dimensional security indicator space, including event type, source device identity, target device or service, access path, trigger policy level, and time characteristics. Through standardization and multi-dimensional mapping, anomalies from different sources and in different formats can be uniformly quantified, providing structured input for anomaly risk assessment.

[0118] Based on a preset anomaly weighting algorithm, the impact range, potential risk level, and associated logical security domain of anomaly events are quantitatively assessed.

[0119] In the multidimensional security indicator space, each abnormal event is quantitatively evaluated based on the preset abnormal weight algorithm. The algorithm considers the type, frequency, importance of the equipment involved, sensitivity level of the logical security domain, and potential impact range of the abnormality. It calculates the risk score and potential hazard level of each abnormality, enabling the management unit to scientifically judge the severity and handling priority of the abnormality and provide a quantitative basis for multi-domain coordination.

[0120] For abnormal events involving multiple logical security domains, a multi-domain consensus mechanism is used to determine the credibility and processing priority of the abnormal event.

[0121] By cross-referencing the access status sequences and policy execution logs of each security domain, it is confirmed whether the abnormal event is recorded in multiple domains, and the credibility of the event is calculated. Based on the credibility and potential risk level, a processing priority is generated to ensure that cross-domain anomalies are not misjudged due to data anomalies in a single domain. At the same time, the policy correction order of each domain is coordinated to achieve unified and authoritative anomaly handling decisions.

[0122] Based on the anomaly analysis results, policy modification suggestions are generated, including a list of affected devices, abnormal access paths, the logical security domains involved, and recommended access control adjustment measures.

[0123] Based on the anomaly analysis results, the overall processing mechanism generates policy modification suggestions, including a list of affected devices, abnormal access paths, the logical security domains involved, and recommended access control adjustment measures, such as blocking specific traffic, adjusting access permissions, or updating policy rules.

[0124] The results of anomaly analysis are integrated with the suggestions for strategy correction to form cross-domain anomaly handling results;

[0125] Integrate policy modification suggestions with anomaly analysis results to form a structured cross-domain anomaly handling result document or dataset, recording anomaly type, processing priority, related domain, and affected devices, providing an executable basis for issuing policy adjustments and dynamic optimizations.

[0126] S5: Based on the cross-domain exception handling results, dynamically adjust the logical security domain division, gateway level configuration and policy parameters, and optimize and aggregate the access policies of each security domain level to build an end-to-end verifiable access control and adaptive security mechanism.

[0127] The process of dynamically adjusting logical security domain division, gateway level configuration, and policy parameters in S5 is as follows:

[0128] Based on the results of cross-domain anomaly handling, the behavioral characteristics and business risk levels of members in each logical security domain are reassessed.

[0129] Behavioral data such as traffic patterns, access frequency, number of communication anomalies, protocol usage, and port access characteristics of each device are extracted from access state sequences and policy execution logs. Then, combined with the device's business type, data sensitivity level, and historical access logs, these behaviors are mapped to risk indicators into a unified multi-dimensional risk vector. By quantifying and normalizing the anomaly indicators, the latest risk assessment value for each device is generated, providing a data foundation for the re-division of logical security domains.

[0130] Based on the assessment results, the devices are re-clustered, and the logical security domain division and member list are updated.

[0131] Based on the device risk assessment value and behavioral feature vector, the devices within the domain are re-clustered. The clustering algorithm can adopt unsupervised learning methods such as hierarchical clustering or K-means. Devices with similar behaviors and similar risk levels are grouped into the same logical security domain. First, the multidimensional risk vector is reduced in dimensionality to reduce the impact of noise. Then, the similarity or distance matrix between devices is calculated. According to the set threshold and the optimal number of clusters, the devices are divided into several new logical security domains, and a list of member devices, domain identifier and corresponding risk level of each domain are generated, so that the network isolation and access control policies are always consistent with the actual risk status.

[0132] Adjust the gateway level configuration of each domain according to the updated logical security domain division;

[0133] For high-risk or sensitive business domains, deploy high-level gateways with deep traffic analysis and IPv6 extended header hash verification capabilities. For medium-risk domains, deploy medium-level gateways that support five-tuple access control. For low-risk domains, configure basic two-tuple verification gateways. Use automated configuration tools to distribute the updated gateway level information to the gateway devices at the boundaries of each logical security domain, and initialize new level identifiers and policy caches at the gateway end to ensure that the policy enforcement capabilities of each domain match its risk level, thereby achieving hierarchical protection and policy enforcement.

[0134] Update access rules, traffic limits, and tiered authorization information, and synchronize the updated policies to each gateway execution terminal.

[0135] Based on the newly defined logical security domains and member device list, access permission or denial rules are generated for each domain and across domains. The policy table is updated to record the correspondence between devices and access policies. Traffic limit parameters are adjusted to prevent abnormal access or resource abuse. At the same time, hierarchical authorization information is updated, including the gateway's constraints on policy execution permissions and the scope of management operations. Policy data is transmitted to the gateway device through a secure distribution channel. The policy cache, path information, and authorization verification module are updated on the gateway to ensure that the device can perform access control according to the latest policies when processing actual traffic.

[0136] The process of building end-to-end verifiable access control and adaptive security mechanisms in S5 is as follows:

[0137] After completing the logical security domain division adjustment, gateway level configuration update and policy parameter modification, the access policies, execution logs and policy change history of each domain will be summarized.

[0138] After completing the logical security domain division and adjustment, gateway level configuration update, and policy parameter modification, the access policies, policy execution logs, and historical policy change records within each logical security domain are centrally summarized. The access policies include intra-domain and cross-domain permission or denial rules, ports, protocols, and traffic control information. The execution logs record the actual execution time, execution status, and abnormal events of the policies. The policy change history saves the version number of the policy update, the reason for the modification, and the distribution path. By summarizing this information, a complete policy management dataset can be formed, providing a data foundation for end-to-end policy analysis and verifiable execution, while ensuring the transparency and traceability of the policy update process.

[0139] The aggregated strategies are structured and optimized to remove redundancy, adjust priorities, and aggregate to generate a unified strategy library, while maintaining the policy granularity that can be mapped to gateways at all levels.

[0140] The policy table is parsed, mapping the policies corresponding to each logical security domain and gateway level to a unified data structure. Then, the algorithm analyzes conflicting rules, duplicate rules, and inconsistencies in priority to automatically generate an optimized unified policy library. During this process, the policy granularity remains mappable to gateways of all levels, ensuring that high-level gateways can execute deep access control, medium-level gateways execute 5-tuple access control, and low-level gateways execute 2-tuple access control. This ensures that the optimized policies maintain integrity while improving execution efficiency and reducing policy conflicts and execution latency.

[0141] The aggregation policy is distributed to gateways at all levels to establish an end-to-end policy execution path and ensure that policy version control, execution order and consistency are traceable.

[0142] The policy is distributed according to logical security domains and gateway levels, and the policy cache and access control module of the gateway are updated. At the same time, the policy version number and distribution time are recorded to ensure that the policy execution order and version are traceable. After distribution, an end-to-end policy execution path is established on the logical security domain boundary and cross-domain path, so that the access of data packets from the source device to the target device always follows a unified policy and the policy execution status of each link can be verified, so that the entire network access control forms a continuous and verifiable closed loop, ensuring the enforcement and consistency of the policy.

[0143] The policy is adjusted in real time according to changes in logical security domain or gateway configuration, thus completing the construction of end-to-end verifiable access control and adaptive security mechanisms.

[0144] When the configuration of a logical security domain or gateway changes, policies are adjusted in real time to adapt to the new network structure and risk conditions. The behavior characteristics, abnormal events, and business risk levels of logical security domain members are monitored. Combining policy change history and policy execution logs, relevant rules are added, deleted, priority adjusted, and traffic limits modified through an automated policy generation and distribution mechanism. At the same time, the end-to-end execution path, version information, and policy cache are updated to ensure that all gateways execute the latest policies synchronously. This enables policies to automatically adapt to network changes and security events, forming a complete adaptive security mechanism.

[0145] Example 2: As Figure 2 As shown, a trusted cloud-native intranet single-domain IP tuple authentication gateway system includes:

[0146] Feature segmentation module: responsible for collecting device behavior and business risks, constructing a device matrix and dividing logical security domains, and generating a multi-dimensional hierarchical mapping structure;

[0147] Policy delivery module: Delivers the level policies of logical security domains to the gateway execution end, and completes gateway deployment and hardware binding authorization to form a policy execution topology;

[0148] Access control module: Implements hierarchical access control for different levels based on the policy topology, and generates access status sequences and policy execution logs;

[0149] Exception handling module: collects access status and logs, processes exceptions reported by logical security domains, adjusts strategies through multi-domain consensus, and generates cross-domain exception handling results;

[0150] Policy optimization module: Based on the results of cross-domain exception handling, dynamically adjust the logical security domain and gateway level, optimize and aggregate access policies, and build an end-to-end verifiable access control and adaptive security mechanism.

[0151] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0152] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A gateway method for trusted cloud native intranet single domain IP multi-tuple verification, characterized in that, The method comprises the following steps: Collecting the behavior characteristics and business risks of each access device in a single domain, constructing a device behavior matrix, dividing logical security domains according to device characteristics, assigning corresponding network isolation levels to each logical security domain, and generating a multi-dimensional level mapping structure; According to the multi-dimensional level mapping structure, deploying level gateways at the access points of each logical security domain, relying on the single-domain trust root for hardware binding and hierarchical authorization, issuing the level policies of each domain to the gateway data execution end, and forming a preliminary policy execution topology structure; Based on the preliminary policy execution topology structure and policy execution access control, low-level access control is based on IP address pairs, medium-level access control is based on five-tuple, and high-level access control is based on dynamic hash access control based on IPv6 extension header specific fields, generating an access state sequence and a policy execution log; Synchronizing the access state sequence and the policy execution log to the total processing mechanism, reporting exceptions by the logical security domain members, executing policy correction based on multi-domain consensus and exception weight algorithm by the total processing mechanism, and generating cross-domain exception handling results; According to the cross-domain exception handling results, dynamically adjusting the logical security domain division, gateway level configuration and policy parameters, and optimizing and aggregating the access policies of each level security domain, constructing an end-to-end verifiable access control and adaptive security mechanism.

2. The gateway method of claim 1, wherein, The process of dividing logical security domains according to device characteristics is as follows: Collecting the network communication behavior, port usage, protocol type, data flow mode and application access characteristics of each device; Recording the business type, data sensitivity level and historical access log of the device; Mapping the collected behavior characteristics and business risks into a multi-dimensional device vector to construct a device behavior matrix, which includes the behavior vector and risk value of each device; Based on the device behavior matrix, the devices are clustered to form multiple logical security domains.

3. The gateway method of claim 2, wherein, The process of generating a multi-dimensional level mapping structure is as follows: Evaluating the devices and business sensitivity in multiple logical security domains to determine the network access control requirements; Assigning corresponding network isolation levels and determining the access control policy granularity corresponding to each level; Establishing the mapping relationship between logical security domains and levels to form a multi-dimensional level mapping structure, including domain identifier, level identifier, policy reference and member device list.

4. The gateway method of claim 3, wherein, The process of relying on the single-domain trust root for hardware binding and hierarchical authorization is as follows: Determine the boundaries of each logical security domain according to the multi-dimensional level mapping structure, and determine the type of gateway to be deployed at each boundary; Deploying the corresponding level gateway at the access point of each logical security domain, including the entry and exit positions; Binding the deployed gateway with the single-domain trust root for hardware binding, loading the device unique identifier and cryptographic credentials; Configuring hierarchical authorization information for each gateway, including different security level access policies, policy execution permissions and operable management range.

5. The gateway method of claim 4, wherein, The process of forming a preliminary policy execution topology structure is as follows: Obtain the logical security domain access policy from the management unit, including access permission or denial, port, protocol and flow direction rules; Parse and convert the obtained policy, combine the level and hierarchical authorization information of each gateway, and map the policy into a rule format that can be recognized and executed by the corresponding gateway; At each gateway end, a preliminary policy execution path is generated according to the policy and authorization permission, including an intra-domain traffic path and a cross-domain traffic path; The rules are issued to the corresponding gateway, and the policy cache and path information are initialized at the gateway end, while the policy execution permission is verified for consistency with the hierarchical authorization; The rules and path information of each gateway are summarized to form the overall preliminary policy execution topology.

6. The gateway method of claim 5, wherein, The process of generating access state sequence and policy execution log is as follows: According to the preliminary policy execution topology, the access control policy is executed on the gateway according to the security level; The low-level gateway performs access control based on the source address and target address to verify the communication traffic; The medium-level gateway performs access control based on the source address, source port, target address, target port and protocol; The high-level gateway performs deep access control based on the packet extension header field to generate the access state sequence and the policy execution log.

7. The gateway method of claim 6, wherein, The process of generating cross-domain exception handling results is as follows: The access state sequence and policy execution log of each logical security domain are synchronized to the total processing mechanism in real time; The standardized processing is performed on the summarized exception data, and the exception event is mapped to the multi-dimensional security index space; According to the preset exception weight algorithm, the influence range, potential risk level and associated logical security domain of the exception event are quantitatively evaluated; For the exception event involving multiple logical security domains, a multi-domain consensus mechanism is adopted to determine the credibility and processing priority of the exception event; Based on the exception analysis result, a policy correction suggestion is generated, including the affected device list, the abnormal access path, the involved logical security domain and the recommended access control adjustment measures; The exception analysis result and the policy correction suggestion are integrated to form the cross-domain exception handling result.

8. The gateway method of claim 7, wherein, The process of dynamically adjusting the logical security domain division, gateway level configuration and policy parameters is as follows: Based on the cross-domain exception handling result, the behavior characteristics and business risk level of each logical security domain member are re-evaluated; According to the evaluation result, the devices are re-clustered, the logical security domain division and the member list are updated; According to the updated logical security domain division, the gateway level configuration of each domain is adjusted; The policy parameters such as access rules, traffic restrictions and hierarchical authorization information are updated, and the updated policy is synchronized to each gateway execution end.

9. The gateway method of claim 8, wherein, The process of constructing end-to-end verifiable access control and adaptive security mechanism is as follows: After completing the adjustment of logical security domain division, the update of gateway level configuration and the modification of policy parameters, the access policy, execution log and policy change history of each domain are summarized; The summarized policy is structurally analyzed and optimized to remove redundancy, adjust priority and aggregate to generate a unified policy library, while maintaining the policy granularity that can be mapped to each level gateway; The aggregated policy is issued to each level gateway to establish an end-to-end policy execution path, and to ensure that the policy version control, execution order and consistency are traceable; According to the logical security domain or gateway configuration change, the policy is adjusted in real time to complete the construction of end-to-end verifiable access control and adaptive security mechanism.

10. A gateway system for trusted cloud native intranet single domain IP multi-packet verification, applied to the method of any one of claims 1-9, characterized in that, It includes: Characteristic division module: responsible for collecting device behavior and business risk, constructing device matrix and dividing logical security domain, and generating multi-dimensional level mapping structure; The policy issuing module: the level policy of the logical security domain is issued to the gateway execution end, and the gateway deployment and hardware binding authorization are completed to form a policy execution topology structure; The access control module: according to the policy topology structure, hierarchical access control is performed on different levels, and an access state sequence and a policy execution log are generated; The exception handling module: collects the access state and the log, handles the logical security domain reported exception, adjusts the policy through multi-domain consensus, and generates a cross-domain exception handling result; The policy optimization module: according to the cross-domain exception handling result, the logical security domain and the gateway level are dynamically adjusted, the access policy is optimized and aggregated, and an end-to-end verifiable access control and adaptive security mechanism is constructed.

Images