Service access management method and system based on VPC network

Abstract

The invention discloses a service access management method and system based on a VPC network. According to the method, quintuple information and a service attribute label are extracted after network flow data of service access are received, a quintuple can define two communication ends and a protocol port, the service attribute label can endow flow service semantics, an IP is mapped to a specific service, and the limitation that only the IP is relied traditionally is broken through; then access validity verification is performed according to a configured network strategy, so that fine control can be realized, for example, based on a quintuple and label combination strategy, illegal access can be accurately intercepted, dynamic adjustment is supported to adapt to a micro-service architecture, and compliance audit and risk traceability are provided at the same time; and intercepting or releasing according to a verification result, and dynamically managing and controlling traffic and optimizing resources. According to the method, the traditional IP limitation is broken through, the security and dynamic adaptability of service access are improved, and a comprehensive, efficient and safe management scheme is provided for service access under the VPC network.

Description

Technical Field

[0001] The present application relates to the field of private cloud management technology, and in particular to a service access management method and system based on a VPC network. Background Art

[0002] In the context of multi-tenant cloud computing, cross-subnet and cross-VPC (Virtual Private Cloud) network access scenarios are becoming increasingly complex. Traditional VPC peering connections require manual configuration of routing tables, security group rules, and port-by-port mapping, resulting in complex port management. Access control based on NAT gateways cannot identify service identities and relies solely on IP / port rules, making them easily bypassed by forged requests. Microservice API gateways deployed in public subnets pose a single point of failure risk, and cross-VPC communication relies on traditional tunneling technology. Cloud vendor security group policies are scattered across different VPCs, requiring multiple policy synchronizations for cross-region service calls, which can easily lead to rule conflicts. Existing technologies also suffer from complex port mapping, generalized security policies, performance bottlenecks, and poor dynamic adaptability.

[0003] Therefore, how to adapt to sudden traffic or attack scenarios in complex business scenarios such as cross-subnet and cross-VPC, and dynamically meet business security isolation requirements, is an urgent problem that technicians in this field need to solve. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the existing technology, it is desired to provide a service access management method and system based on a VPC network, which can solve the security isolation problem in complex scenarios.

[0005] In a first aspect, an embodiment of the present application provides a service access management method based on a VPC network, including:

[0006] After receiving the network traffic data of the service access, extract the traffic five-tuple information and business attribute labels;

[0007] Perform access validity verification on the five-tuple information and the service attribute tag according to the configured network policy, and generate a verification result;

[0008] Access is intercepted or released based on the verification result.

[0009] In one embodiment, the performing access validity verification on the quintuple information and the service attribute tag according to the configured network policy includes:

[0010] Check whether the business attribute labels of the accessing party and the accessed party conform to the preset allowed access groups;

[0011] Verify whether the accessing party and the accessed party are in the permitted access links recorded by the platform;

[0012] Confirm whether the destination port and protocol of the traffic are consistent with the preset policy;

[0013] If all verifications are passed, a verification result with valid access is generated;

[0014] If at least one verification fails, an access invalid verification result is generated.

[0015] In one embodiment, the VPC network-based service access management method further includes:

[0016] Receive configuration requests for network policies;

[0017] Get the configuration information of the policy;

[0018] Distribute the configuration information to each VPC and network device; wherein the network policy includes: cross-region, cross-VPC and cross-subnet service access policy.

[0019] In one embodiment, before acquiring the configuration information of the policy, the method further includes:

[0020] Determining whether the configuration request is a policy configuration request within the same area;

[0021] If the policy configuration request is for the same zone, the ACL policy template is output so that the user can add the configuration information of the release policy.

[0022] If the request is for cross-zone policy configuration, the deny ACL policy template is output so that the user can add the configuration information of the deny policy.

[0023] In one embodiment, the configuration information of the acquisition strategy includes:

[0024] Outputting an access link graph through a user interaction interface;

[0025] The policy editing operations of the user on each link in the access link graph are collected to generate configuration information.

[0026] In one embodiment, the VPC network-based service access management method further includes:

[0027] Receive registration requests for services;

[0028] Configuring a business attribute tag for the service;

[0029] The access link of the service is recorded and updated to the access link map.

[0030] In one embodiment, the VPC network-based service access management method further includes:

[0031] Real-time capture of raw traffic through lightweight probes deployed at each VPC border node and subnet;

[0032] Extracting quintuple information and context labels from the original traffic to generate a feature vector;

[0033] Identify abnormal traffic based on the feature vector and generate an abnormal score;

[0034] Performing a threshold determination on the anomaly score and generating a corresponding dynamic network strategy;

[0035] The dynamic network policy configuration is distributed to each VPC and network device.

[0036] In one embodiment, performing a threshold determination on the anomaly score and generating a corresponding dynamic network policy includes:

[0037] If the anomaly score falls within a serious deviation range, it is marked as high risk and a long-term interception network strategy is generated;

[0038] If the anomaly score falls within the medium deviation range, it is marked as a temporary anomaly and a short-term interception network strategy is generated;

[0039] If the anomaly score falls within the normal deviation range, it is marked as normal and a long-term release network policy is generated.

[0040] In one embodiment, identifying abnormal traffic based on the feature vector includes:

[0041] The degree of deviation of the flow characteristics of the feature vector from the normal flow pattern is calculated using the isolation forest algorithm.

[0042] In a second aspect, an embodiment of the present application provides a service access management system based on a VPC network, including:

[0043] The service management platform is used to extract the five-tuple information and business attribute tags of the traffic after receiving the network traffic data of the service access; verify the access validity of the five-tuple information and the business attribute tags according to the network policy issued by the policy management platform, and generate a verification result; intercept or release the access according to the verification result.

[0044] The policy management platform is used to store and manage network policies for service access.

[0045] The service access management method based on VPC network provided in this application extracts quintuple information and business attribute labels after receiving network traffic data of service access. The quintuple can clearly identify the two ends of communication and the protocol port, while the business attribute label can give traffic business semantics, map the IP to the specific service, break through the limitation of traditional reliance on IP, and provide multi-dimensional data support for subsequent policy verification; then, access validity is verified according to the configured network policy, which can achieve refined control. For example, based on the quintuple and label combination strategy, illegal access can be accurately intercepted, and dynamic adjustment to adapt to the microservice architecture is supported, while providing compliance auditing and risk tracing capabilities; interception or release is performed based on the verification results, and traffic is dynamically controlled to optimize resources. This method breaks through the traditional IP restrictions, improves the security and dynamic adaptability of service access, and provides a comprehensive, efficient and secure management solution for service access under the VPC network.

[0046] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0048] Figure 1 A flow chart of a VPC network-based service access management method provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0049] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0050] It should be noted that, in the absence of conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments. Although the embodiments of the present application provide the method operation instruction steps shown in the following embodiments or drawings, more or fewer operation instruction steps may be included in the method based on routine or no creative labor. In steps where there is no necessary causal relationship logically, the execution order of these steps is not limited to the execution order provided in the embodiments of the present application. During the actual processing process or when the device is executed, the method may be executed in the order of the methods shown in the embodiments or drawings or in parallel.

[0051] Example 1:

[0052] This embodiment proposes a service access management method based on VPC network, please refer to Figure 1 , Figure 1 FIG. 1 shows a flow chart of a service access management method based on a VPC network provided in this embodiment. Figure 1 As shown, the method includes:

[0053] S101, after receiving the network traffic data of the service access, extract the five-tuple information of the traffic and the business attribute label;

[0054] In computer networks, after acquiring traffic data generated by service calls between clients and servers, the system extracts the five-tuple information and service attribute tags of this traffic data in real time. The five-tuple information is the basic identifier of network traffic and the basic unit for traffic routing and firewall rule matching. Specifically, it includes the source IP address, destination IP address, source port, destination port, and protocol type.

[0055] Business attribute tags refer to the static business attribute tags of services. They are preset by the administrator or the system when the service is registered. They are static tags that identify its business attributes and are used for basic permission control. They mainly include static attributes such as the service name and environment (such as prod / test).

[0056] The quintuple provides a physical fingerprint of network communications, while the business attribute tag binds network traffic to upper-layer business logic, giving the traffic business semantics. This step extracts information from both simultaneously, evolving network security policies from static IP-based fences to dynamic protection nets based on service semantics. This approach is suitable for the elastic security needs of microservices and containerized environments.

[0057] S102: Verify access validity of the five-tuple information and the service attribute tag according to the configured network policy and generate a verification result;

[0058] Based on predefined network policies, the system performs rule matching on the five-tuple information of traffic (source IP, source port, destination IP, destination port, protocol) and business attribute tags (such as service name, business line, user role) to determine whether the access meets security or management requirements, and ultimately outputs verification results such as allow / reject or risk level.

[0059] Traditional network security relies on edge devices such as firewalls and WAFs, but they fail in the following scenarios: Internal threats: Malicious programs that have infiltrated the intranet access core services through legitimate IP addresses; Microservice architecture: East-west traffic (service calls) lacks fine-grained control. Once a service is compromised, attackers can move laterally.

[0060] This step implements full-dimensional access control from the network layer to the business layer through dual verification of the five-tuple + label. It not only meets the fine-grained requirements of zero-trust security, but also adapts to the dynamic changes of services in the cloud-native environment. In microservices and hybrid cloud architectures, it provides enterprises with secure, compliant, and efficient network traffic management capabilities.

[0061] S103. Intercept or release access based on the verification result.

[0062] Based on the results of access validity verification (such as allowing or denying access), the final control action is performed on network traffic, converting the logical decision of policy verification into physical control:

[0063] Release: Allows traffic to pass through the network boundary (such as VPC gateway, firewall) or service interface, enabling communication between the source and destination.

[0064] Intercept: Prevent traffic transmission, interrupt communication connections, or return an error response (such as HTTP 403 Forbidden).

[0065] Based on the above introduction, the service access management method for the VPC network provided in this embodiment extracts the five-tuple information and business attribute labels after receiving the network traffic data of the service access. The five-tuple can clearly identify the two ends of communication and the protocol port, while the business attribute label can give the traffic business semantics, map the IP to the specific service, break through the traditional limitation of relying only on the IP, and provide multi-dimensional data support for subsequent policy verification; then, access validity verification is performed according to the configured network policy, which can achieve refined control. For example, based on the five-tuple and label combination strategy, illegal access can be accurately intercepted, and dynamic adjustment to adapt to the microservice architecture is also supported, while providing compliance auditing and risk tracing capabilities; interception or release is performed based on the verification results, and traffic is dynamically controlled to optimize resources. This method breaks through the traditional IP restrictions, improves the security and dynamic adaptability of service access, and provides a comprehensive, efficient, and secure management solution for service access under the VPC network.

[0066] Example 2:

[0067] The above embodiments do not limit the specific configuration of network policies and the corresponding validity verification methods. The corresponding policies can be configured according to the needs of actual application scenarios. To defend against multi-dimensional attack scenarios and adapt to the characteristics of cloud-native service architecture, this embodiment proposes a validity verification method that cross-checks the legitimacy of traffic through multiple layers of rules.

[0068] Specifically, the process of verifying the access validity of the five-tuple information and the service attribute tag according to the configured network policy in step S102 can be performed according to the following steps:

[0069] Step S21: Check whether the service attribute tags of the visiting party and the visited party conform to the preset allowed access group;

[0070] Services are grouped by labels based on business attributes (such as payment services, user centers, and test environments), and only services within the same group or across preset groups (such as front-end group → back-end group) are allowed to access each other.

[0071] For example, if the accessing party is labeled as a test environment and the accessed party is labeled as a production database, it is directly determined to be an illegal cross-group access.

[0072] Step S22: Verify whether the accessing party and the accessed party are in the allowed access links recorded by the platform;

[0073] The platform pre-records legal service call links, such as API gateway → user service → database, to verify whether the traffic is within the whitelist link.

[0074] For example, if the traffic path is client → database, bypassing the API gateway, even if the tag is legal, it will be intercepted because it is not in the preset link.

[0075] Step S23: confirm whether the destination port and protocol of the traffic are consistent with the preset policy;

[0076] Check whether the destination port (such as MySQL port 3306) and protocol (TCP / UDP) used by the traffic are consistent with the range allowed by the policy.

[0077] For example, if the policy only allows HTTP protocol (TCP port 80 / 443) to access the web service, and traffic uses UDP protocol to access port 53 (DNS service), verification fails.

[0078] Step S24: If all verifications are successful, a verification result indicating that the access is valid is generated;

[0079] Step S25: If at least one verification fails, generate a verification result indicating invalid access.

[0080] In the validity verification method provided in this embodiment, label grouping can prevent unauthorized business access, link verification can block illegal paths, port protocols can limit service abuse, and multi-layer rules complement each other to defend against multi-dimensional attack scenarios; at the same time, there are multi-hop calls between microservices. In this method, link verification is used to ensure the compliance of the call path, avoiding the security threats to validity verification caused by the complexity of the call link. Therefore, this method not only adapts to the characteristics of dynamic changes in services in a cloud-native environment, but also improves attack defense capabilities through a combination of multi-dimensional rules, while reducing the complexity of policy maintenance, and building a more flexible, secure, and auditable service access management system for enterprises.

[0081] It should be noted that this embodiment only takes the above validity access method as an example for introduction. The configuration of other strategies and verification methods can refer to the introduction of this embodiment and will not be repeated here.

[0082] Example 3:

[0083] To achieve closed-loop management of network policies from configuration to distribution to effectiveness, based on the above embodiment, this embodiment further proposes a method for configuring network policies. In addition to the above access request response step, the following steps can be further performed:

[0084] Step S104: receiving a network policy configuration request;

[0085] Administrators submit policy configuration instructions through the console, API, or automated tools, such as allowing subnet 1 of VPC-A in the East China region to access the database service in subnet 2 of VPC-B in the North China region.

[0086] Enterprise services may be deployed in different regions (e.g., front-end deployment in East China and data centers in North China), in different VPCs (separating production and test environments), or in different subnets (layered deployment of application, data, and interface layers). Region refers to a logical zone, such as production, test, or control. Each logical zone can have different subnets within different VPCs. To adapt to the complexity of multi-cloud / hybrid cloud architectures and provide comprehensive access control, network policies include cross-region, cross-VPC, and cross-subnet service access policies. Regional isolation can block unauthorized cross-region access, such as unauthorized access from servers in an overseas region to a domestic data center. VPC-level isolation can be applied to VPCs within the same region by default, restricting only necessary access through policies. For example, an e-commerce platform's user center VPC and payment VPC can only allow communication between specific interfaces, though this is not limited to these. Subnet-level fine-grained control divides subnets within the same VPC by business tier (front-end / back-end / database). This can restrict cross-tier access paths, such as prohibiting direct access from a front-end subnet to a database subnet. Multi-dimensional isolation is achieved across regions, VPCs, and subnets.

[0087] Configuration requests can be triggered manually or automatically. Manual triggering, for example, involves the administrator filling in policy parameters (such as source / destination regions, VPC, subnet, service tags, etc.) in the operation and maintenance platform; automatic triggering, for example, involves linkage through the CMDB (configuration management database), automatically generating corresponding access policy requests when a new service goes online.

[0088] Step S105: Obtain policy configuration information;

[0089] Parse the specific policy content in the request and store it in a structured manner as executable rule data.

[0090] Step S106: Distribute the configuration information to each VPC and network device;

[0091] Synchronize policy rules to all relevant network nodes to ensure uniform implementation across the entire network. Specifically, this includes VPC components and network devices. VPC components include network ACLs (access control lists), security groups, and NAT gateways within the VPC; network devices include inter-region load balancers, VPN gateways, dedicated line devices, and ServiceMesh proxies in cloud-native environments, such as Istio Sidecar.

[0092] Once the administrator has configured a policy, they can simply click a single button to automatically distribute the policy to network devices across all VPCs and regions, eliminating the need for frequent manual operations. Reliable communication protocols and secure encryption mechanisms are used to distribute policy configuration information, ensuring the integrity and confidentiality of the policy during transmission. Upon receiving the policy, the network device automatically loads and executes the corresponding policy, achieving precise control of network traffic.

[0093] This method implements closed-loop management of network policies from "configuration-distribution-effectiveness", extending network access control from a single VPC to the entire network across regions and levels. It not only meets the multi-dimensional isolation requirements under complex architectures, but also reduces operation and maintenance costs through automation and template capabilities, while ensuring the consistency and compliance of the entire network policy, and building a definable, scalable, and auditable network service access management system for enterprises.

[0094] In order to further improve the automation capability of policy configuration, before obtaining the policy configuration information in step S105, the following steps may be performed:

[0095] Determine whether the configuration request is a policy configuration request within the same area. If so, output the allow ACL policy template so that the user can add configuration information for the allow policy. If it is a cross-area policy configuration request, output the deny ACL policy template so that the user can add configuration information for the deny policy.

[0096] The system first identifies whether the network policy configuration request submitted by the user is for the same region or across regions. Same-region refers to policy configuration between VPCs, subnets, or devices within the same geographic region, such as resource access within the same data center; cross-region refers to resource access policy configuration between different geographic regions, such as the Beijing and Shanghai data centers. If the request is for the same region, the system outputs an allow ACL policy template. The user can add policies to allow access within the template. The default is to allow access, and explicit allow rules are required. If the request is for a cross-region, the system outputs a deny ACL policy template. The user must add policies to deny access. The default is to deny access, and only explicitly configured rules are allowed.

[0097] Internal resources typically belong to the same security domain, with frequent business interactions. Defaulting to "allow" reduces duplication of configuration and improves management efficiency. Users only need to add rules for the few scenarios that require prohibition. Network links between different regions may involve public network transmission or cross-security domain access, which poses a higher security risk. Therefore, all cross-region access is denied by default, and users must explicitly configure "allow" rules to prevent unauthorized access. Templates pre-set default logic lowers the user configuration threshold. Frequent configuration of basic "allow" rules within the same region is unnecessary, while cross-region access forces users to clearly define security requirements, reducing policy configuration errors.

[0098] This method distinguishes between policy configuration requests within the same region and across regions, and outputs different ACL (access control list) policy templates. The templated design reduces repetitive operations. Users do not need to manually write basic rules (such as allowing communication within the same region), but only need to focus on special scenarios (such as prohibiting certain types of traffic), reducing operation and maintenance costs. At the same time, it supports differentiated processing of same-region and cross-region scenarios, and adapts to complex network architectures of multiple regions and multiple VPCs. It can not only ensure flexible interaction of internal businesses, but also strengthen security protection across regional boundaries.

[0099] Traditional policy configuration requires manual writing of rules such as IP segments and ports, such as allowing 192.168.1.0 / 24 to access port 443 of 10.0.0.1. This places high demands on operation and maintenance personnel. To further reduce the difficulty of user-side policy configuration, step S105 of obtaining policy configuration information can be specifically implemented through the following steps:

[0100] Step S51: outputting an access link graph through a user interaction interface;

[0101] The system automatically generates a visual service access link topology diagram, showing potential communication paths between regions, VPCs, subnets, and services.

[0102] Step S52: Collect the user's policy editing operations on each link in the access link graph and generate configuration information.

[0103] Users directly operate the link diagram through the graphical interface (such as clicking on links and dragging nodes). The system captures the operation behavior in real time and converts it into executable policy configuration.

[0104] This method assists users in configuring network policies through a visual access link diagram, transforming abstract policy rules into graphical operations and transforming complex network policy configuration from text-based rule writing to graphical topology operations. This lowers the technical barrier to entry and improves configuration efficiency. It also ensures that rules align with the actual network architecture through real-time topology-policy linkage. This mechanism is particularly well-suited for complex cloud architectures with multiple regions and VPCs, helping enterprises achieve visual, automated, and compliant policy management while ensuring network security.

[0105] Example 4:

[0106] In order to facilitate access management of various services, this embodiment proposes a unified service registration mechanism to prevent unauthorized access of illegal services. Specifically, in addition to the above embodiment, the following steps can be further performed:

[0107] Step S107: receiving a service registration request;

[0108] When a new service is connected to the VPC network, the system needs to receive its registration request and submit basic service information (such as service name, IP address, port, etc.) through a standardized interface (such as API) so that the system can identify and include it in the management scope.

[0109] The registration mechanism is the basis for all subsequent access control, ensuring that only authenticated services can enter the network environment and preventing unauthorized access by illegal services.

[0110] Step S108: Configure a business attribute tag for the service;

[0111] Business attribute tags logically categorize services, such as by business type (payment, logistics, user center), security level (core business, non-core business), and department (finance, e-commerce). For example, payment services can be labeled as core business - high security level, while logging services can be labeled as non-core business - medium security level.

[0112] Through label-based management, network policies can be formulated based on business attributes rather than simply IP addresses. When the service IP changes or expands, the policy does not need to be frequently modified, which improves management flexibility. At the same time, labels can be used as logical conditions for access control, such as only allowing services with core business labels to access each other, achieving more precise permission isolation.

[0113] Step S109: Record the access link of the service and update it into the access link map.

[0114] An access link is the call path between services, for example, client → API gateway → order service → database. The system maps the call relationships between services into a link diagram through automatic discovery (such as traffic monitoring) or manual entry. Each time a service is registered or a link changes, the link diagram is updated in real time, forming a dynamic and visual network topology.

[0115] The method provided in this embodiment combines labels and links, enabling policies to accurately match who can access whom and through what paths, avoiding the crude release of IP segments. Furthermore, when services are added or iterated, only labels and links need to be updated, without the need to restructure network policies, thus reducing operation and maintenance costs.

[0116] Embodiment 5:

[0117] In order to further solve the rigidity problem of static policies and reduce manual maintenance costs, in addition to the above embodiment, the following steps can be further performed:

[0118] Step S110: Capture original traffic in real time by deploying lightweight probes at each VPC boundary node and subnet;

[0119] Deploy probes at each VPC border node (such as border routers and load balancers) and subnet ingress and egress, similar to setting up monitoring points at each network "gateway," to capture all incoming and outgoing raw traffic in real time. Extract five-tuple information (source IP, destination IP, protocol, source port, destination port) and context tags (such as service identity and user role) from the traffic.

[0120] Raw traffic refers to the underlying data packets of network communication data that have not undergone any preprocessing, filtering, or parsing. It contains the original data from each layer of the OSI model, such as the link layer: MAC address, frame check sequence (FCS); the network layer: IP header (source / destination IP, protocol number, TTL, etc.); the transport layer: TCP / UDP header (source / destination port, sequence number, flags, etc.); and the application layer: unparsed raw payload (such as HTTP request binary data, SQL statement byte stream). Unlike cleaned traffic that has been filtered by a firewall, cleaned by a WAF, or parsed at the application layer, raw traffic retains all the original bit streams during the communication process, including abnormal data that may be discarded by conventional security devices.

[0121] By deploying lightweight probes at the VPC boundary nodes and subnets to capture the original traffic in real time, at the security defense level, it can identify abnormal behaviors that are easily overlooked by traditional devices based on the underlying data packets, such as DNS tunneling, TCP synchronization packet flooding, etc., generate dynamic interception rules in real time, and break through IP / port restrictions, extracting service identities from the payload to achieve fine-grained access control. In terms of traffic management, the timing, fragmentation and other information retained by the original traffic can be used for full-link tracing and locating faults such as MTU mismatches. At the same time, indicators such as throughput and latency are collected to support dynamic bandwidth adjustment. In a multi-tenant environment, micro-segmentation can be achieved through subnet boundary traffic characteristics to avoid the lag of cloud vendors' security groups. It can also automatically extract endpoint information from service registration traffic, link business systems to achieve service discovery and dynamic routing, and automatically connect network policies as services go online, reducing manual configuration and improving dynamic security protection and operation and maintenance efficiency in the cloud environment in a data-driven manner.

[0122] Step S111: extract quintuple information and context labels from the original traffic to generate a feature vector;

[0123] Extract features that can reflect network behavior patterns from network traffic data. Specifically, it is necessary to extract quintuple information and context labels. Quintuple information refers to source IP / port, destination IP / port, and protocol. Context labels refer to dynamic labels extracted from network traffic that reflect access behavior characteristics, including user roles (user role labels (such as role=admin), which come from authentication information in the traffic), Payload Hash (the hash value of the HTTP request body or TCP payload, used to identify attack characteristics), access timestamp (the time when the traffic is generated (implicit in the feature vector), used to analyze access frequency anomalies), and other dynamic features. They refer to dynamic labels extracted from network traffic that reflect access behavior characteristics.

[0124] Convert the quintuple and label into a numerical vector (such as [source IP segment, target service label, traffic size, access frequency]) to facilitate machine learning analysis by the algorithm model. A feature vector is as follows:

[0125] F={Src IP,Dst IP,Protocol,Pay load Hash,User Role,Service Tag}

[0126] Payload Hash: Calculates the SHA-256 hash value of the HTTP request body or TCP payload to identify known attack signatures (such as hash value comparison of SQL injection statements).

[0127] Service Tag: service identity tag (such as service = payment, env = prod), obtained from the service management and control platform.

[0128] Step S112: Identify abnormal traffic based on the feature vector and generate an abnormality score;

[0129] Normal business patterns are learned from historical traffic data. For example, if a service has an average daily visit volume of 100,000, with a peak between 9:00 and 18:00, the current traffic feature vector is compared with the baseline and an anomaly score is calculated. For example, the score soars when burst traffic exceeds the baseline by 200%.

[0130] In this embodiment, there is no limitation on the specific abnormal traffic identification algorithm and the scoring rule for the abnormal score, which can be set according to the requirements of the actual application scenario.

[0131] Step S113: Perform threshold determination on the anomaly score and generate a corresponding dynamic network strategy;

[0132] Different level thresholds are preset, such as anomaly scores > 80 triggering a high-risk strategy, and 50-80 triggering a medium-risk strategy, and corresponding interception rules are automatically generated, such as limiting traffic rate, blocking connections, etc.

[0133] Step S114: Send the dynamic network policy configuration to each VPC and network device.

[0134] Dynamic policies are synchronized to firewalls, load balancers, switches, and other devices in each VPC through API interfaces to ensure policy consistency across the entire network.

[0135] It should be noted that the response method when the dynamic network policy conflicts with the configured static network policy is not limited in this embodiment. Generally, the dynamic network policy can be set to high priority and the static network policy to low priority to dynamically adapt to different traffic scenarios and realize intelligent regulation.

[0136] This method monitors the sources of traffic across subnets and regions within the VPC in real time and automatically generates dynamic ACL rules, solving the rigidity of static policies, reducing manual maintenance costs, and improving flexibility in responding to attacks and business emergencies.

[0137] Example 6:

[0138] The dynamic network policy management method provided in Example 5 does not limit the specific identification algorithm for abnormal process identification. In order to reduce the cost of data annotation and efficiently process high-dimensional data, this embodiment proposes that the isolation forest algorithm can be used to calculate the degree of deviation between the traffic characteristics of the feature vector and the normal traffic pattern. The degree of deviation is used as the abnormal traffic identification result. The higher the degree of deviation, the higher the degree of abnormality.

[0139] The Isolation Forest algorithm recursively partitions the traffic feature vector space by constructing a random binary tree. Normal traffic with similar behavior patterns is assigned to the deeper layers of the tree (where paths are longer), while abnormal traffic with unique characteristics is quickly isolated to the shallower layers (where paths are shorter). The anomaly score quantifies the degree of deviation in path length, reflecting the likelihood of traffic anomaly. A higher score indicates a higher probability of abnormal traffic.

[0140] Specifically, taking the feature vector set {F1, F2, ..., Fn} as an example, we randomly select features and split values, recursively split the data space until all samples are isolated, and construct random trees. We calculate the path length h(x) of sample x in each tree, that is, the number of edges from the root node to the leaf nodes.

[0141] A formula for calculating anomaly score is as follows:

[0142]

[0143] Where, E(h(x)): the average path length of sample x in all trees.

[0144] c(n): normalization factor,

[0145] H(k) is the harmonic number, H(k)=ln(k)+0.5772

[0146] The abnormal traffic identification method provided in this embodiment determines anomalies based on the length of the isolation path. It only needs to randomly sample some features to build a model, and can efficiently process high-dimensional data. At the same time, this method belongs to unsupervised learning, and only normal traffic data is needed to train the model, which can reduce the team's data labeling costs.

[0147] Embodiment seven:

[0148] In order to implement hierarchical configuration of dynamic network policies, step S113 in the above embodiment performs threshold determination on the anomaly score and generates the corresponding dynamic network policy, which can be specifically performed according to the following steps:

[0149] If the anomaly score falls within the serious deviation range, it is marked as high risk and a long-term interception network strategy is generated to continuously block the risk source and avoid persistent threats.

[0150] If the anomaly score falls within the medium deviation range, it is marked as a temporary anomaly and a short-term interception network policy is generated to temporarily block and observe to avoid accidentally blocking normal business traffic.

[0151] If the anomaly score falls within the normal deviation range, it is marked as normal and a long-term release network policy is generated to maintain normal communication and reduce the interference of the policy on the business.

[0152] Specifically, if the anomaly score is continuously higher than the threshold, such as s≥0.9 for 10 consecutive detections, and the traffic characteristics conform to known attack patterns, such as the same source IP scanning 100+ different ports in a short period of time, it is judged as high risk and a long-term interception strategy is generated. The time limit can be set from several hours to permanent. This method can deal with continuous ransomware attack traffic and block access to known malicious IPs (such as dark web proxy servers).

[0153] If the anomaly score occasionally exceeds the medium threshold (such as a single s=0.7) but does not pose a sustained threat, the traffic characteristics may be due to misoperation, such as temporary access by operations and maintenance personnel to unauthorized ports. In this case, it is determined to be a temporary anomaly and a short-term interception strategy is generated. The time limit can be set to several minutes to several hours. This method can intercept sudden port scans, such as security test errors, and temporarily block abnormal login attempts, such as 10 incorrect passwords for the same account within 5 minutes.

[0154] If the anomaly score is always lower than the threshold (such as s < 0.3) and the traffic characteristics match the historical baseline, such as office system access between 8:00 and 18:00 every day, it is judged as normal, and a long-term release policy is generated and continuously effective. This method can release daily access traffic to the enterprise OA system and maintain normal call links between microservices.

[0155] To deepen understanding, a threshold setting for threshold determination and the corresponding dynamic network strategy are as follows:

[0156] If the Anomaly Score is ≥ 0.8, it is marked as high risk and a long-term interception rule (TTL = 3600 seconds) is generated.

[0157] If 0.7≤Anomaly Score<0.8, it is marked as low risk and a short-term rule (TTL=300 seconds) is generated.

[0158] If the Anomaly Score is less than 0.7, it is considered normal traffic and the corresponding release rule is generated based on the five-tuple information of the traffic.

[0159] Policy configuration is issued based on the generated rules.

[0160] The threshold determination and dynamic network policy generation method provided in this embodiment maps anomaly scores to three risk levels. The system can implement high-intensity blocking of high-risk traffic to strengthen security defenses, implement flexible control of temporary anomalies to reduce business disruptions, and maintain an efficient flow mechanism for normal traffic to ensure business continuity. This mechanism is like embedding an intelligent control device into the network system: when encountering high-risk attack traffic, a full-scale blocking strategy is immediately activated; when facing temporary anomaly traffic, a phased buffering control is implemented; and for normal business traffic, an unblocked flow state is maintained, ultimately achieving a dynamic and coordinated balance between security protection and business operations.

[0161] Embodiment 8:

[0162] This embodiment provides a service access management system based on a VPC network. The system adopts a layered design of a service management platform and a policy management platform to achieve the decoupling of network traffic processing and policy control.

[0163] Among them, the service management platform is used to extract the five-tuple information and business attribute tags of the traffic after receiving the network traffic data of the service access; verify the access validity of the five-tuple information and business attribute tags according to the network policy issued by the policy management platform, and generate a verification result; intercept or release the access according to the verification result.

[0164] The policy management platform is used to store and manage network policies for service access. The core functions of the policy management platform include:

[0165] Policy storage: Centrally stores all network policies (such as cross-region, cross-VPC, and cross-subnet access rules) and supports adding, deleting, modifying, and querying rules.

[0166] Policy distribution: Push configured policies to the service management platform to ensure policy consistency across the entire network;

[0167] Policy lifecycle management: records metadata such as policy version, effective time, and associated services, and supports policy auditing and backtracking.

[0168] The VPC network-based service access management system provided in this embodiment and the VPC network-based service access management method provided in the above embodiments may refer to each other, and the repeated parts will not be repeated in this embodiment.

[0169] In one embodiment, the policy management platform includes a user interaction interface, a request processor, and a policy storage. The user interaction interface provides an intuitive and convenient operation interface for administrators, through which administrators can manage VPC subnets under the region and manage access policies between regions. The request processor is responsible for processing user configuration requests, parsing, verifying, and integrating regional management and policies. The policy storage is used to store various regional information, policy information, network topology information, and user permission information. In one application scenario, for an application system that spans multiple VPCs and regions, the network administrator can configure access policies between various VPCs and between different regions at one time on the policy management platform. When subnets are added or deleted under a region, the policy management platform can automatically coordinate the policies based on the regional network topology to ensure the consistency and effectiveness of the policies, ensure default mutual access within the same region, and release cross-regions on demand.

[0170] In one embodiment, the service management platform supports a visual policy editing function, and administrators can quickly formulate complex policies through operations such as dragging and clicking, and network administrators can uniformly plan and configure network policies for different areas.

[0171] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operating instructions of the system and method according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the aforementioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than the order marked in the accompanying drawings. For example, the boxes represented by two connections can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified function or operating instruction, or can be implemented by a combination of dedicated hardware and computer instructions.

[0172] The units or modules involved in the embodiments described in this application may be implemented in software or hardware. The units or modules described may also be provided in a processor. The names of these units or modules do not, in certain circumstances, constitute limitations on the units or modules themselves.

[0173] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the aforementioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A service access management method based on a VPC network, characterized in that: include: After receiving the network traffic data of the service access, extract the traffic five-tuple information and business attribute labels; Perform access validity verification on the five-tuple information and the service attribute tag according to the configured network policy, and generate a verification result; Access is intercepted or released based on the verification result.

2. The method according to claim 1, wherein The performing access validity verification on the five-tuple information and the service attribute tag according to the configured network policy includes: Check whether the business attribute labels of the accessing party and the accessed party conform to the preset allowed access groups; Verify whether the accessing party and the accessed party are in the permitted access links recorded by the platform; Confirm whether the destination port and protocol of the traffic are consistent with the preset policy; If all verifications are passed, a verification result with valid access is generated; If at least one verification fails, an access invalid verification result is generated.

3. The method according to claim 1, wherein Also includes: Receive configuration requests for network policies; Get the configuration information of the policy; Distribute the configuration information to each VPC and network device; wherein the network policy includes: cross-region, cross-VPC and cross-subnet service access policy.

4. The method according to claim 3, wherein Before obtaining the configuration information of the policy, the method further includes: Determining whether the configuration request is a policy configuration request within the same area; If the policy configuration request is for the same zone, the ACL policy template is output so that the user can add the configuration information of the release policy. If the request is for cross-zone policy configuration, the deny ACL policy template is output so that the user can add the configuration information of the deny policy.

5. The method according to claim 3, wherein The configuration information of the acquisition strategy includes: Outputting an access link graph through a user interaction interface; The policy editing operations of the user on each link in the access link graph are collected to generate configuration information.

6. The method according to claim 1, wherein Also includes: Receive registration requests for services; Configuring a business attribute tag for the service; The access link of the service is recorded and updated to the access link map.

7. The method according to any one of claims 1 to 6, wherein: Also includes: Real-time capture of raw traffic through lightweight probes deployed at each VPC border node and subnet; Extracting quintuple information and context labels from the original traffic to generate a feature vector; Identify abnormal traffic based on the feature vector and generate an abnormal score; Performing a threshold determination on the anomaly score and generating a corresponding dynamic network strategy; The dynamic network policy configuration is distributed to each VPC and network device.

8. The method according to claim 7, wherein A threshold is determined for the anomaly score to generate a corresponding dynamic network strategy, including: If the anomaly score falls within a serious deviation range, it is marked as high risk and a long-term interception network strategy is generated; If the anomaly score falls within the medium deviation range, it is marked as a temporary anomaly and a short-term interception network strategy is generated; If the anomaly score falls within the normal deviation range, it is marked as normal and a long-term release network policy is generated.

9. The method according to claim 7, wherein Abnormal traffic is identified based on the feature vector, including: The degree of deviation of the flow characteristics of the feature vector from the normal flow pattern is calculated using the isolation forest algorithm.

10. A service access management system based on a VPC network, characterized in that: include: The service management platform is used to extract the traffic five-tuple information and business attribute tags after receiving the network traffic data of service access; Perform access validity verification on the five-tuple information and the service attribute tag according to the network policy issued by the policy management platform, and generate a verification result; Intercept or release access based on the verification results; The policy management platform is used to store and manage network policies for service access.

Images