A cloud security data to situational awareness forwarding method

Abstract

This invention discloses a method for forwarding cloud security data to a situational awareness platform, applied to a security resource pool in a multi-tenant cloud environment. The security resource pool deploys several security components. The method includes the following steps: S1: Tenant Tag Association Step: Assign a unique tenant identifier (Tenant_ID) to each tenant and establish a mapping relationship between the tenant identifier and all cloud resources and security components within the tenant in the security resource pool; S2: Data Acquisition and Tag Injection Step: Collect raw security data through security components deployed within the tenant's virtual network to generate tagged security data; S3: Data Standardization and Forwarding Step: Standardize the tagged security data according to a preset data format and forward it to the situational awareness platform through an external data transmission channel. This invention solves the alarm confusion problem caused by overlapping IP addresses during security data forwarding in a multi-tenant cloud environment, while reducing the resource consumption of the security resource pool and improving the analysis accuracy of the situational awareness platform.

Description

Technical Field

[0001] This invention relates to the field of cloud security data processing technology, specifically a method for forwarding cloud security data to situational awareness. Background Technology

[0002] With the deepening of enterprise digital transformation, cloud computing technology has been widely adopted. In a multi-tenant cloud environment, multiple tenants share underlying computing, storage, and network resources. The cloud platform provides isolated virtualized environments for different tenants, hosting their respective business systems. To ensure the security of cloud-based businesses, cloud platforms typically deploy security resource pools, providing tenants with various security capabilities such as cloud firewalls, cloud web application firewalls, cloud bastion hosts, cloud database auditing, and cloud APT detection through virtualization technology. Simultaneously, enterprises typically build a unified network situational awareness security operations platform to centrally monitor, analyze, and respond to various information systems. This platform aggregates alarm logs and traffic data from various security devices, performs correlation analysis and situational assessment, and achieves real-time awareness of the overall network security situation.

[0003] However, in a multi-tenant cloud environment, effectively forwarding security data generated by the security resource pool to the situational awareness platform faces several technical challenges. First, in a multi-tenant cloud environment, virtual networks of different tenants typically use private IP addresses, and these IP addresses may overlap. When the security resource pool directly forwards security data from multiple tenants to the situational awareness platform, if the data is not identified by tenant affiliation, the situational awareness platform will merge alarms from the same IP address of different tenants into the same asset, causing alarm paradigm confusion and distorted threat analysis. Second, the security resource pool is deployed in the cloud, and its computing and storage resources are limited. If a large amount of security data is cached and processed locally, it will affect the normal operation performance of security components, leading to a decrease in security protection capabilities.

[0004] Furthermore, most existing security data forwarding methods are designed for single-system or single-tenant scenarios, lacking tagging, differentiated forwarding, and dynamic management mechanisms for multi-tenant cloud environments. Different tenants have different real-time requirements for security monitoring, and traditional forwarding methods cannot perform differentiated scheduling based on tenant priorities. At the same time, as the number of tenants changes dynamically, how to achieve automated management and situation assessment of new tenants is also a problem that needs to be solved in existing technologies. Therefore, there is an urgent need for a method that can efficiently and accurately forward security data to the situation awareness platform in a multi-tenant cloud environment. Summary of the Invention

[0005] This invention addresses the shortcomings of existing technologies by providing a method for forwarding cloud security data to situational awareness, aiming to solve the alarm confusion caused by overlapping IP addresses during security data forwarding in a multi-tenant cloud environment, while reducing the resource consumption of the security resource pool and improving the analysis accuracy of the situational awareness platform.

[0006] A method for forwarding cloud security data to situational awareness, applied to a security resource pool in a multi-tenant cloud environment, wherein several security components are deployed in the security resource pool, the method includes the following steps: S1: Tenant Tag Association Steps: Assign a unique tenant identifier (Tenant_ID) to each tenant and establish a mapping relationship between the tenant identifier and all cloud resources and security components within the tenant in the security resource pool; S2: Data collection and tag injection steps: Collect raw security data through security components deployed in the tenant's virtual network, inject the tenant identifier of the corresponding tenant into the raw security data, and generate tagged security data; S3: Data standardization and forwarding steps: Standardize the tagged security data according to the preset data format, and forward it to the situation awareness platform through the data outbound channel. The situation awareness platform distinguishes and analyzes the security data from different tenants based on the tenant identifier. When cloud resources from different tenants have overlapping IP addresses, the situational awareness platform distinguishes alarm logs belonging to different tenants based on tenant identifiers, thus avoiding alarm merging confusion caused by overlapping IP addresses.

[0007] Preferably, in step S2, the raw security data includes security component alarm logs and system logs of the operating system and middleware within the tenant.

[0008] Preferably, in step S3, the data transmission channel supports the KAFKA and Syslog protocols, and supports load balancing processing for multiple transmissions and transmissions to multiple addresses.

[0009] Preferably, in step S2, the security resource pool only performs tag injection processing on the collected security data, and does not store the complete tagged security data locally in the security resource pool to avoid resource consumption.

[0010] Preferably, in step S3, the situational awareness platform constructs a multi-tenant log index based on the tenant identifier. The security logs of each tenant are stored in buckets according to the format of "tenant identifier_timestamp". The bucket allocation strategy satisfies the following relationship:

[0011] in, Index for log storage buckets, The hash value that identifies the tenant. This represents the total number of storage buckets.

[0012] Preferably, in step S3, when the situational awareness platform performs alarm paradigm processing on tagged security data, it uses the tenant identifier as one of the primary keys for alarm association. When two alarms have the same source IP address but different tenant identifiers, they are determined to be independent alarm events of different tenants.

[0013] Preferably, in step S3, a log aggregation system is established between the security resource pool and the situational awareness platform. This system caches and preprocesses tagged security data. The preprocessing priority strategy is as follows: the data outgoing queue weight for high-priority tenants is higher than that for low-priority tenants. The queue weight allocation satisfies the following conditions:

[0014] in, For tenants Data outgoing queue weight, For tenants Service quality rating coefficient This represents the total number of tenants.

[0015] Preferably, the security components include a cloud APT device and a cloud database auditing device. The cloud APT device collects east-west traffic data of the tenant's virtual machine, and the cloud database auditing device collects access traffic data of the tenant's database.

[0016] Preferably, it also includes S4: Dynamic tenant management step: When the security resource pool detects a new tenant, it automatically assigns a tenant identifier to the new tenant and establishes a mapping relationship, and synchronizes the tenant identifier to the tenant management module of the situation awareness platform to realize the dynamic management of the tenant.

[0017] Preferably, when the situational awareness platform performs security situation assessment based on tenant identifiers, it constructs a multi-tenant situational assessment matrix based on a knowledge graph, and the elements of the assessment matrix... Let represent the situational score of tenant i in the j-th security dimension. The overall situational score of tenant i is:

[0018] in, Let j be the weight coefficient of the j-th security dimension. =1, K is the total number of security dimensions.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention assigns a unique tenant identifier to each tenant in step S1 and injects a tenant tag at the source of security data collection in step S2. This enables the situational awareness platform to accurately distinguish the tenant affiliation of alarms based on the tenant identifier in step S3, even if different tenants use the same private IP address for their cloud resources. This solves the problem of chaotic security data alarms caused by overlapping IP addresses in a multi-tenant cloud environment.

[0020] 2. In step S2 of this invention, the security resource pool only performs tag injection processing on the collected security data, without additionally storing the complete tagged security data locally. This avoids the computational and storage resource overhead caused by local data caching. Compared with the existing technology, which requires a large amount of data preprocessing and local persistence on the security resource pool side, this invention transfers the pressure of data storage and in-depth analysis to the situational awareness platform side. This allows the computing resources of the security resource pool to focus on the core protection functions of the security components, ensuring that the cloud security protection capability is not weakened by data forwarding tasks.

[0021] 3. In step S3, this invention introduces a log aggregation system and executes a priority forwarding strategy. For tenants carrying critical information infrastructure such as government affairs, finance, and energy, their security data can be guaranteed to be transmitted with priority, ensuring that high-risk security incidents can be detected and dealt with in the first instance, thus meeting the rigid requirements of industry compliance supervision for the real-time security monitoring of critical businesses.

[0022] 4. Through step S4, when the security resource pool detects a new tenant, the present invention automatically assigns a tenant identifier to the new tenant and establishes a mapping relationship, while synchronizing the tenant identifier to the tenant management module of the situation awareness platform. Compared with the traditional approach that requires manual tenant configuration on both the security resource pool and the situation awareness platform, the present invention achieves end-to-end automation of tenant management, eliminating the operational delays and error risks caused by manual configuration, and is especially suitable for cloud-native dynamic scenarios where tenants are frequently created and destroyed. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall system architecture of the present invention; Figure 2 This is a schematic diagram of the deployment architecture of the present invention. Detailed Implementation

[0024] Experimental environment description: The following embodiments and comparative examples are all verified based on the same multi-tenant cloud environment test platform, which includes 3 tenants (tenant A, tenant B, and tenant C). Each tenant has deployed two security components: cloud APT and cloud database audit. The security resource pool of the test platform is deployed in the Huawei Cloud environment, and the situational awareness platform is deployed in the enterprise's local data center. The security resource pool and the situational awareness platform are interconnected via a dedicated line. Each tenant has an internal server with the IP address 192.168.1.1 to simulate an IP address overlap scenario. During the test, simulated attack traffic was launched to the 192.168.1.1 server of each tenant to verify the situational awareness platform's ability to distinguish alarms from each tenant.

[0025] Example 1: Basic Tag Injection Scheme – Applicable Environment: Small to medium-sized multi-tenant cloud environment, with ≤10 tenants, where each tenant has similar real-time requirements for security monitoring and no special priority requirements. In this embodiment, the security resource pool executes S1 to assign a unique tenant identifier (Tenant_ID) to each tenant, where tenant A's identifier is T001, tenant B's identifier is T002, and tenant C's identifier is T003. Executing S2, the security component collects raw security data and injects the tenant identifier field into the data header to generate tagged security data. Executing S3, the data is sent to the situation awareness platform via the Syslog protocol. After receiving the data, the situation awareness platform parses the tenant identifier field, stores the alarm logs of different tenants in different storage areas, and performs normalization processing using the tenant identifier as one of the primary keys for alarm association.

[0026] Example 2: Tag Injection + Bucketed Storage Scheme – Applicable Environment: Large-scale multi-tenant cloud environment, number of tenants ≥ 50, huge amount of security log data, and high requirements for alarm query response efficiency. This embodiment, based on embodiment 1, further implements the bucketed storage strategy in S3; the security logs of each tenant are stored in buckets according to the format "tenant identifier_timestamp", and the bucket allocation strategy is as follows: There are 10 storage buckets in total. Each tenant is assigned to the corresponding storage bucket based on the hash value of their tenant identifier modulo 10. When the situational awareness platform performs alarm normalization, it uses the tenant identifier and the source IP address as the primary key for alarm association. Only when both the tenant identifier and the source IP address are the same will the alarm be determined to be for the same asset.

[0027] Example 3: Tag Injection + Dynamic Priority Forwarding Scheme – Applicable Environment: Hybrid business-oriented multi-tenant cloud environment, where different tenants carry business systems of different importance levels, such as the coexistence of core production systems and development and testing systems in government clouds and financial clouds. This embodiment, based on embodiment 2, sets up a log aggregation system between the security resource pool and the situational awareness platform, executing the priority forwarding strategy in S3. The log aggregation system caches and preprocesses tagged security data. QoS levels are set according to the importance of tenant services: Tenant A (core production service, QoS=3, high priority), Tenant B (general service, QoS=2, medium priority), and Tenant C (development and testing service, QoS=1, low priority). Queue weight allocation satisfies: That is, the queue weight of tenant A is 3 / (3+2+1)=0.5, and that of tenant B is 2 / 6≈0.167; the log aggregation system allocates outgoing bandwidth resources according to the weight.

[0028] Comparison Example 1: Traditional forwarding scheme without label injection – Applicable comparison environment: Traditional single-tenant or cloud environment that does not consider the IP overlap problem of multi-tenant. In this comparative example, after the security resource pool collects security data from each tenant, it does not execute the label injection step in S2, but directly forwards the raw security data to the situation awareness platform via the Syslog protocol. The situation awareness platform uses the source IP address as the primary key for alarm association and performs normalization processing without distinguishing the source of the tenant. All three tenants have a server with the IP address 192.168.1.1, and the source IP of the alarms generated by the attack traffic is 192.168.1.1.

[0029] Comparative Example 2: Tag Injection without Bucketing Storage Solution – Applicable Comparison Environment: Cloud environment that only solves IP overlap identification but ignores large-scale storage query efficiency. In this comparative example, the security resource pool executes S1 and S2 to inject tenant identifiers into each tenant, but the situational awareness platform does not execute the bucketed storage strategy and stores all tenant logs in the same storage area. In S3, when alarm normalization is performed, although the situational awareness platform can identify and distinguish tenant identifiers, the query needs to scan the entire data because the storage is not isolated. When the amount of security data is large, the query performance deteriorates significantly.

[0030] Experimental process Within a 10-minute test window, 500 simulated attack events were launched against the 192.168.1.1 servers of tenants A, B, and C respectively using automated attack scripts, for a total of 1500 attacks. Secure data forwarding and situational awareness processing were performed using the methods of Examples 1-3 and Comparative Examples 1-2 respectively. The following experimental indicators were recorded: (1) Alarm correct differentiation rate - the proportion of alarms that the situational awareness platform can correctly distinguish as belonging to a tenant; (2) Alarm paradigm accuracy rate - the proportion of alarms that are correctly merged according to "tenant + asset"; (3) Average alarm entry delay - the average time from the occurrence of the attack to the display of the alarm on the situational awareness platform; (4) Alarm query response time - the average response time for querying all alarms of a specified tenant.

[0031] The experimental results are shown in Table 1 below:

[0032] Table 1 The experimental results are analyzed as follows: The experimental results show that, due to the implementation of the tenant identifier injection step in S2, the alarm correct differentiation rate of Examples 1-3 all reached 100%, which is significantly better than Comparative Example 1 (only 33.3%). In Comparative Example 1, since the alarm source IPs of different tenants are all 192.168.1.1, the situational awareness platform incorrectly merged the alarms of the three tenants into the same asset, resulting in an alarm paradigm accuracy of only 33.3% - it cannot correctly distinguish the alarms in scenarios where only the source IPs are the same and the tenant identifiers are not differentiated, thus verifying the necessity of the S2 tag injection step.

[0033] Compared to Example 1, Example 2, due to the implementation of the bucketed storage strategy, reduced the alarm query response time from 1.8s to 0.4s, improving query efficiency by 78%. At the same time, the alarm normalization accuracy increased to 99.2%, demonstrating the performance advantages of bucketed storage in large-scale scenarios. Example 3 achieved low-latency forwarding of 0.9s for high-priority tenants, ensuring the real-time security monitoring of critical businesses. However, the data entry latency for low-priority tenants increased, reflecting the effectiveness of the priority scheduling mechanism in differentiated services. Although Comparative Example 2 had an alarm differentiation rate of 100%, the query response time increased to 3.2s due to the unified storage of all tenant logs, resulting in significant performance degradation in large-scale multi-tenant scenarios.

[0034] In summary, this invention effectively solves the problem of chaotic security data alarms caused by overlapping IP addresses in a multi-tenant cloud environment through tenant identifier injection, tagging processing, and standardized forwarding steps in S1-S3. Combined with bucketed storage and priority scheduling mechanisms, it can optimize query response performance and differentiated service capabilities while ensuring the accuracy of alarm differentiation.

Claims

1. A method for forwarding cloud security data to situational awareness, characterized in that, A security resource pool is applied in a multi-tenant cloud environment. The security resource pool deploys several security components. The method includes the following steps: S1: Tenant Tag Association Steps: Assign a unique tenant identifier (Tenant_ID) to each tenant and establish a mapping relationship between the tenant identifier and all cloud resources and security components within the tenant in the security resource pool; S2: Data collection and tag injection steps: Collect raw security data through security components deployed in the tenant's virtual network, inject the tenant identifier of the corresponding tenant into the raw security data, and generate tagged security data; S3: Data standardization and forwarding steps: Standardize the tagged security data according to the preset data format, and forward it to the situation awareness platform through the data outbound channel. The situation awareness platform distinguishes and analyzes the security data from different tenants based on the tenant identifier. When cloud resources from different tenants have overlapping IP addresses, the situational awareness platform distinguishes alarm logs belonging to different tenants based on tenant identifiers, thus avoiding alarm merging confusion caused by overlapping IP addresses.

2. The cloud security data forwarding method to situational awareness as described in claim 1, characterized in that, In step S2, the raw security data includes security component alarm logs and system logs of the operating system and middleware within the tenant.

3. The cloud security data forwarding method to situational awareness as described in claim 1, characterized in that, In step S3, the data transmission channel supports the KAFKA and Syslog protocols, and supports load balancing for multiple transmissions and transmissions to multiple addresses.

4. The cloud security data forwarding method to situational awareness as described in claim 1, characterized in that, In step S2, the security resource pool only performs tag injection processing on the collected security data, and does not store the complete tagged security data locally in the security resource pool to avoid resource consumption.

5. The cloud security data forwarding method to situational awareness as described in claim 1, characterized in that, In step S3, the situational awareness platform constructs a multi-tenant log index based on tenant identifiers. The security logs of each tenant are stored in buckets according to the format "tenant identifier_timestamp". The bucket allocation strategy satisfies the following relationship: in, Index for log storage buckets, The hash value that identifies the tenant. This represents the total number of storage buckets.

6. The cloud security data forwarding method to situational awareness as described in claim 1, characterized in that, In step S3, when the situational awareness platform performs alarm paradigm processing on tagged security data, it uses the tenant identifier as one of the primary keys for alarm association. When two alarms have the same source IP address but different tenant identifiers, they are determined to be independent alarm events of different tenants.

7. The cloud security data forwarding method to situational awareness as described in claim 1, characterized in that, In step S3, a log aggregation system is established between the security resource pool and the situational awareness platform. This system caches and preprocesses tagged security data. The priority strategy for preprocessing is as follows: the data outgoing queue weight for high-priority tenants is higher than that for low-priority tenants. The queue weight allocation satisfies the following conditions: in, For tenants Data outgoing queue weight, For tenants Service quality rating coefficient This represents the total number of tenants.

8. The cloud security data forwarding method to situational awareness according to claim 1, characterized in that, The security components include cloud APT devices and cloud database auditing devices. The cloud APT devices collect east-west traffic data of tenant virtual machines, and the cloud database auditing devices collect access traffic data of tenant databases.

9. A method for forwarding cloud security data to situational awareness according to claim 1, characterized in that, It also includes S4: Dynamic Tenant Management Step: When the security resource pool detects a new tenant, it automatically assigns a tenant identifier to the new tenant and establishes a mapping relationship, and synchronizes the tenant identifier to the tenant management module of the situation awareness platform to realize the dynamic management of tenants.

10. A method for forwarding cloud security data to situational awareness according to claim 1, characterized in that, When the situational awareness platform performs security situation assessment based on tenant identifiers, it constructs a multi-tenant situational assessment matrix based on a knowledge graph. The elements of the assessment matrix... Let represent the situational score of tenant i in the j-th security dimension. The overall situational score of tenant i is: in, Let j be the weight coefficient of the j-th security dimension. =1, K is the total number of security dimensions.

Images