Multi-tenant adaptive collaborative defense method and system in hybrid cloud scenario

Abstract

The application discloses a multi-tenant adaptive cooperative defense method and system in a hybrid cloud scene, comprising the following steps: obtaining a remote trusted proof of hardware, verifying the trustworthiness of a tenant agent and the code integrity based on the remote trusted proof, and granting a mark; detecting cloud information to generate a machine-readable portrait containing key parameters; collecting tenant local multi-modal log data to encode embedded vectors, after privacy processing, a local model calculates an abnormal confidence exceeding a threshold value to trigger flow limiting or blocking; a layered federal architecture containing a tenant local node, a regional cloud and a global control plane is constructed, on the premise that log data does not go out of the domain, encrypted aggregated parameters are generated to generate a cross-tenant attack identification global model and issue each tenant. The application verifies the integrity of the security agent on the tenant side through a trusted access mechanism, and constructs a tenant portrait based on a trusted mark, realizes real and verifiable cooperative defense capabilities among multiple tenants, and makes the cooperation process reliable.

Description

Technical Field

[0001] This invention relates to the fields of network security and cloud computing technology, specifically to a multi-tenant adaptive collaborative defense method and system in a hybrid cloud scenario. Background Technology

[0002] With the rapid development of cloud computing technology, enterprise IT architecture is gradually evolving from a single data center to a hybrid cloud architecture that combines public cloud, private cloud, and edge cloud. This architecture fully leverages the elastic computing capabilities of public cloud, the data security of private cloud, and the low latency of edge cloud. In a hybrid cloud environment, multi-tenancy has become the mainstream, where multiple tenants share the underlying physical hosts, virtual networks, storage resources, and container runtime.

[0003] While hybrid cloud brings improved resource utilization and business flexibility, its complex heterogeneous environment and dynamically changing resource attributes also pose significant challenges to network security defense. Existing traditional security defense systems typically rely on single-point defense tools such as firewalls, web application firewalls, and endpoint detection and response. These tools show obvious limitations when dealing with advanced persistent threats and complex attack chains in hybrid cloud environments.

[0004] Specifically, existing technologies have the following main technical problems in hybrid cloud and multi-tenant security defense:

[0005] First, in hybrid cloud scenarios, enterprises often use services from different vendors such as AWS, Alibaba Cloud, and Huawei Cloud simultaneously. These cloud vendors exhibit significant differences in their security capabilities, log formats, API standards, and policy management mechanisms. This heterogeneity makes it difficult to unify security policies, result in inconsistent attack event formats, and hinder collaboration between defense systems across clouds. For example, attack signatures detected on the public cloud cannot be synchronized to the private cloud in real time, allowing the same attacker to easily move between different cloud domains by exploiting information asymmetry.

[0006] Second, in a multi-tenant environment, due to shared CPU, bandwidth, storage, and container runtime, an attack on one tenant can easily spread to other tenants in the same physical environment. Existing security isolation mechanisms are insufficient to prevent container escape, physical machine intrusion, and side-channel-based data leakage attacks. Furthermore, current technologies struggle to achieve real-time monitoring of tenant-level resource isolation and cannot effectively prevent "neighbor interference" caused by an attack on one tenant.

[0007] Third, attackers often employ "roundabout" tactics, such as first compromising edge nodes, then moving laterally into the private cloud via tunnels, and finally using tenant privileges to access core public cloud resources. Existing defense systems often lack cross-cloud log aggregation capabilities and cross-tenant behavior modeling capabilities, making it impossible to build a unified attack path view. This results in defenders only seeing scattered alerts and being unable to identify the complete cross-domain attack chain.

[0008] Fourth, hybrid cloud resources are highly dynamic, with dynamic scaling of Pods, elastic expansion of virtual machines, and dynamic allocation of IP addresses being commonplace. Traditional firewall rules and IDS policies based on static IPs or fixed assets cannot adapt to this change: newly added instances may not be bound to security policies in a timely manner, while residual policies after scaling down may lead to security vulnerabilities. Existing technologies lack an adaptive security policy update mechanism that can automatically adjust in real time to follow resource changes.

[0009] Fifth, cloud environment logs are massive and come from diverse sources, with significant differences in business behavior among tenants. Traditional IDS / IPS struggle to effectively monitor east-west traffic in the cloud, and general detection rules often fail to adapt to the specific business characteristics of individual tenants, resulting in a persistently high false positive rate. Furthermore, due to the dynamic changes in resources, AI models trained on fixed samples struggle to continuously learn and update effectively across different tenants.

[0010] Sixth, current cloud security defenses are mostly single-point operations, lacking cross-tenant threat intelligence sharing and coordinated blocking capabilities. When a cloud node or tenant is compromised, attack signatures cannot be automatically shared with other tenants, preventing the defense system from forming a cohesive force. However, achieving collaborative defense presents significant compliance and privacy challenges: data between tenants must be strictly isolated. How to achieve threat signature sharing and joint modeling (such as federated learning) without leaking tenants' original data (such as business logs and user privacy) is a problem that current technologies have not yet effectively solved.

[0011] Seventh, existing automated response mechanisms often rely on pre-defined scripts for execution, lacking rigorous verification of the current business status and the consequences of policy execution. In a multi-tenant environment, an incorrect blocking policy may inadvertently disrupt normal business operations or even render the core services of the entire tenant unavailable. Existing technologies lack an intent-driven and formally validated policy execution mechanism, failing to ensure business continuity and policy rollback while guaranteeing security. Therefore, this paper proposes a multi-tenant adaptive collaborative defense method and system for hybrid cloud scenarios. Summary of the Invention

[0012] The purpose of this invention is to provide a multi-tenant adaptive collaborative defense method and system in a hybrid cloud scenario, which realizes the automated execution from the trust measurement of node access to the final security policy.

[0013] Firstly, to achieve the above objectives, this application adopts a technical solution: a multi-tenant adaptive collaborative defense method in a hybrid cloud scenario, comprising the following steps:

[0014] Obtain remote trusted proof of hardware, verify the trustworthiness and code integrity of tenant agent based on the remote trusted proof and grant a tag, and detect cloud information to generate a machine-readable profile containing key parameters;

[0015] Collect tenant's local multimodal log data, encode and embed vectors, and after privacy processing, calculate the abnormal confidence level in the local model. If the value exceeds the threshold, trigger rate limiting or blocking.

[0016] Construct a hierarchical federated architecture that includes tenant local nodes, regional clouds, and a global control plane. Under the premise that log data does not leave the domain, encrypt and aggregate parameters to generate a global model for cross-tenant attack identification and distribute it to each tenant.

[0017] Based on multi-tenant behavior embedding and event sequence relationship, a causal attack graph containing entities and event nodes is constructed. After causal inference and graph transformer reasoning, the probability of propagation risk, root cause, and hub node are output.

[0018] A unified score is obtained by integrating local anomalies, global models, propagation risks, and threat intelligence matching, and the alarm threshold is dynamically adjusted based on the criticality of tenant business and attack situation.

[0019] The high-level defense intent is to synthesize a cross-cloud execution plan, which is formally verified to not violate the tenant's service level agreement. The defense actions are executed in transaction mode, and reversible actions are matched with compensation rollback to restore the system.

[0020] In one possible implementation, obtaining remote trusted proof of hardware, verifying tenant agent trustworthiness and code integrity based on the remote trusted proof and assigning a tag, and probing cloud information to generate a machine-readable profile containing key parameters specifically includes:

[0021] In response to performing hardware-based remote trust verification on each tenant's agent or connector, the system grants a corresponding trusted execution node tag after verifying the trustworthiness of its runtime environment and the integrity of its code. At the same time, it automatically detects the cloud platform type, interface permissions, and resource constraints on the tenant's side, and generates a machine-readable tenant profile that includes business criticality, maximum acceptable damage threshold, and automatic response level.

[0022] The remote trusted proof includes:

[0023] The agent program generates a proof token containing an environmental metric hash value, a binary hash value, and a random number inside the trusted hardware, and digitally signs the proof token using the hardware's built-in private key.

[0024] Upon receiving the proof token, the verification service in the control plane verifies the digital signature and compares the environmental metric hash value with the whitelist. If the verification is successful, the node is marked as a trusted execution node.

[0025] In one possible implementation, the collected tenant's local multimodal log data is encoded into an embedding vector. After privacy processing, the local model calculates an anomaly confidence level exceeding a threshold to trigger rate limiting or blocking. Specifically, this includes:

[0026] Based on multimodal log data collected locally by the tenant, the log data is encoded into behavior embedding vectors using a self-supervised learning model, and differential privacy noise addition or secure quantization compression processing is performed on the behavior embedding vectors in a trusted execution environment; then, the local deployed micro-model is used to calculate the anomaly confidence level, and local rate limiting or blocking is triggered when the confidence level exceeds the threshold.

[0027] The behavior embedding vector generation process includes:

[0028] For time-series log data, a time-series transformer model is used for encoding.

[0029] For call chain and process tree structure data, a graph torrent algorithm is used for encoding.

[0030] The self-supervised learning model generates representation vectors with generalization capabilities through contrastive learning techniques.

[0031] In one possible implementation, the construction of a hierarchical federated architecture including tenant local nodes, regional clouds, and a global control plane, while ensuring that log data does not leave the domain, involves encrypting and aggregating parameters to generate a global model for cross-tenant attack identification and distributing it to each tenant. Specifically, this includes:

[0032] Construct a hierarchical federated learning architecture that includes tenant local nodes, regional cloud aggregators, and global control plane aggregators; while keeping the original log data from leaving the domain, use a secure encrypted aggregation protocol to aggregate the encrypted gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant.

[0033] The hierarchical federated learning architecture also includes a split learning mechanism:

[0034] For data containing sensitive features, the model is split into a front-end network and a back-end network. The tenant only trains and uploads the activation values ​​of the intermediate layers of the front-end network of the model. These intermediate layer activation values ​​are mathematically irreversible and cannot be restored to the original input data.

[0035] The control plane is responsible for training the model's backend network.

[0036] The hierarchical federated learning architecture also includes a split learning mechanism:

[0037] For data containing sensitive features, the model is split into a front-end network and a back-end network. The tenant only trains and uploads the activation values ​​of the intermediate layers of the front-end network of the model. These intermediate layer activation values ​​are mathematically irreversible and cannot be restored to the original input data.

[0038] The control plane is responsible for training the model's backend network.

[0039] In one possible implementation, the secure encryption aggregation protocol specifically includes:

[0040] Tenant nodes encrypt the gradients and upload them to the regional aggregator. The regional aggregator calculates the regional model and uploads it to the global aggregator for aggregation.

[0041] The aggregation process of the global aggregator adopts a secure multi-party computation protocol to ensure that no single-point aggregator can parse the plaintext gradient value of a single tenant.

[0042] Furthermore, all weight update operations are recorded in a chained hash log for auditing purposes.

[0043] In one possible implementation, the causal attack graph containing entities and event nodes is constructed based on multi-tenant behavior embedding and event sequence relationships. Through causal inference and graph transformer reasoning, the propagation risk probability, root causes, and hub nodes are output, specifically including:

[0044] Construct a causal attack graph and perform graph transformer inference; based on the behavior embedding vectors of multi-tenants and the temporal relationship of events, construct a causal attack graph containing entity nodes and event nodes; use causal inference methods to identify causal edges between events, and use the graph transformer model to infer the attack graph, outputting the propagation risk probability of each node and the root cause node and hub node in the attack chain.

[0045] The method of identifying causal edges between events using causal inference specifically includes:

[0046] By comprehensively utilizing Granger causality tests, time-point processes, and structural causality models, and based on the temporal sequence of events, behavioral similarities, and contextual environment, it is determined whether the first event is a potential cause of the second event, and directional causal edges are established in the causal attack graph.

[0047] The unified score is obtained by weighting the matching degree of local anomalies, global models, propagation risks, and threat intelligence. This score is then dynamically adjusted based on the tenant's business criticality and attack posture. Specifically, this includes:

[0048] In response to the integration of local anomaly detection scores, global model scores, propagation risk values ​​derived from causal graphs, and threat intelligence matching degrees, a unified threat score is generated through weighted calculation; and the alarm threshold used to determine the threat level is dynamically adjusted based on the business criticality in the tenant profile and the current overall attack situation.

[0049] In one possible implementation, the high-level defense intent is synthesized into a cross-cloud execution plan, formally verified to not violate the tenant's service level agreement, and defensive actions are executed in transaction mode. Reversible actions are coupled with compensatory rollbacks to restore the system, specifically including:

[0050] Based on automatically synthesizing high-level defense intentions into specific cross-cloud execution plans, and using formal verification methods to verify whether the execution plan violates the tenant's service level agreement before execution; the defense actions in the execution plan are executed in transaction mode, and corresponding compensation rollback operations are configured for each reversible action to support the recovery of system state in case of misjudgment or abnormality;

[0051] The step of verifying whether the execution plan violates the tenant's service level agreement using formal verification methods before execution specifically includes:

[0052] Using a satisfiability model theory solver or bounded model checking technique, verify whether the system state after the execution plan is implemented meets the minimum service replica limit, service reachability requirements, and business continuity threshold set in the tenant profile;

[0053] The execution of the defensive actions in the execution plan is carried out in transaction mode, and corresponding compensation rollback operations are configured for each reversible action. Specifically, this includes:

[0054] The transaction mode is executed using a compensatory transaction mechanism.

[0055] The execution plan is broken down into a series of ordered sub-operations, including blocking traffic, restricting access, generating snapshots, and isolating containers;

[0056] If any sub-operation fails or a rollback instruction is received, the system automatically triggers the corresponding compensation operation to roll back the environment state to the state before the sub-operation was executed.

[0057] Secondly, to address the aforementioned technical problems, another technical solution adopted in this application is: a multi-tenant adaptive collaborative defense system in a hybrid cloud scenario, comprising:

[0058] The Trusted Profiling Module is configured to perform hardware-based remote trust verification on each tenant's agent or connector, and grant the corresponding trusted execution node tag after verifying the trustworthiness of its runtime environment and code integrity; at the same time, it automatically detects the tenant's cloud platform type, interface permissions and resource restrictions, and generates a machine-readable tenant profile that includes business criticality, maximum acceptable damage threshold and automatic response level.

[0059] The local anomaly detection module is configured to collect multimodal log data locally on the tenant's premises, encode the log data into behavior embedding vectors using a self-supervised learning model, and perform differential privacy noise addition or secure quantization compression processing on the behavior embedding vectors within a trusted execution environment; then, it uses a locally deployed micro-model to calculate the anomaly confidence level, and triggers local rate limiting or blocking when the confidence level exceeds a threshold.

[0060] The federated aggregation module is configured to build a hierarchical federated learning architecture that includes tenant local nodes, regional cloud aggregators, and global control plane aggregators. While keeping the original log data from leaving the domain, it uses a secure encrypted aggregation protocol to aggregate the encrypted gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant.

[0061] The graph reasoning module is configured to construct a causal attack graph and perform graph transformer reasoning; based on the behavior embedding vectors of multi-tenants and the event sequence relationship, a causal attack graph containing entity nodes and event nodes is constructed; causal inference methods are used to identify causal edges between events, and the attack graph is reasoned through the graph transformer model to output the propagation risk probability of each node and the root cause node and hub node in the attack chain.

[0062] The scoring and threshold adjustment module is configured to generate a unified threat score by weighted calculation in response to the fusion of local anomaly detection score, global model score, propagation risk value derived from causal graph inference, and threat intelligence matching degree; and dynamically adjust the alarm threshold used to determine the threat level based on the business criticality in the tenant profile and the current overall attack situation.

[0063] The verification and rollback module is configured to automatically synthesize high-level defense intentions into specific cross-cloud execution plans, and to verify whether the execution plan violates the tenant's service level agreement using formal verification methods before execution; to execute the defense actions in the execution plan in transaction mode, and to configure corresponding compensation rollback operations for each reversible action to support the recovery of the system state in case of misjudgment or abnormality.

[0064] A third aspect of this disclosure is as follows: To solve the above-mentioned technical problems, another technical solution adopted by this application is: an electronic device, including a processor, a memory, and a communication interface, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the multi-tenant adaptive collaborative defense method in any hybrid cloud scenario as described above.

[0065] A fourth aspect of this disclosure is as follows: To solve the above-mentioned technical problems, another technical solution adopted by this application is: a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario as described above.

[0066] Compared with the prior art, the present invention has the following advantages:

[0067] 1. This invention performs integrity verification on the tenant-side security agent through a trusted access mechanism and constructs a tenant profile based on trusted tags, thereby realizing real and verifiable collaborative defense capabilities among multiple tenants and making the collaboration process reliable.

[0068] 2. This invention enables tenants to participate in collaborative training without exposing the original data through privacy preprocessing and encrypted aggregation technologies.

[0069] 3. By constructing a multi-dimensional correlation graph that includes events, hosts, users, images, and attack behaviors, this invention can identify the propagation path of attacks in different tenants and different cloud environments, breaking through the limitation of traditional single-tenant IDS that can only see "partial fragments".

[0070] 4. This invention integrates multiple sources of data, including local anomaly detection results, collaborative model output, attack graph inference results, and external threat intelligence, to generate a unified and traceable threat score, significantly reducing false positives and false negatives.

[0071] 5. This invention dynamically selects collaborative defense strategies based on threat scores and tenants' personalized risk preferences, and introduces strategy consistency verification and rollback mechanisms to achieve automated and controllable collaborative defense execution.

[0072] 6. This invention verifies the impact on business continuity before executing defensive actions and ensures that business status can be quickly restored in the event of misjudgment or policy error through a rollback mechanism, thereby improving the overall availability of the hybrid cloud environment. Attached Figure Description

[0073] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0074] Figure 1 This is a flowchart illustrating the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario according to the present invention.

[0075] Figure 2 This is a block diagram of the multi-tenant adaptive collaborative defense system in a hybrid cloud scenario according to the present invention;

[0076] Figure 3 This is a schematic diagram of the structure of an electronic device according to the present invention. Detailed Implementation

[0077] 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.

[0078] Figure 1 This is a flowchart illustrating the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario according to an embodiment of the present invention. It should be noted that if substantially the same result is achieved, the method of this application is not necessarily identical. Figure 1 The sequence of processes shown is limited.

[0079] Example 1:

[0080] like Figure 1 The multi-tenant adaptive collaborative defense method for hybrid cloud scenarios shown in this invention includes the following steps:

[0081] Step 1: Obtain remote trusted proof of hardware, verify the trustworthiness and code integrity of tenant agent based on the remote trusted proof and grant a tag, and detect cloud information to generate a machine-readable profile containing key parameters;

[0082] In response to performing hardware-based remote trust verification on each tenant's agent or connector, the system grants a corresponding trusted execution node tag after verifying the trustworthiness of its runtime environment and the integrity of its code. At the same time, it automatically detects the cloud platform type, interface permissions, and resource constraints on the tenant's side, and generates a machine-readable tenant profile that includes business criticality, maximum acceptable damage threshold, and automatic response level.

[0083] In this embodiment of the disclosure, the remote trusted proof includes:

[0084] The agent program generates a proof token containing an environmental metric hash value, a binary hash value, and a random number inside the trusted hardware, and digitally signs the proof token using the hardware's built-in private key.

[0085] Upon receiving the proof token, the verification service in the control plane verifies the digital signature and compares the environmental metric hash value with the whitelist. If the verification is successful, the node is marked as a trusted execution node.

[0086] This disclosure addresses the issue of "zero-trust" access in cloud-native environments. Its core objective is to ensure that every node joining the system (i.e., the tenant-side agent or connector) runs in a real and trusted environment, its permission scope is verifiable, and its security attributes and execution capabilities are quantifiable. The system will automatically generate machine-readable tenant profiles for subsequent collaborative training and policy enforcement.

[0087] When the agent program starts, the system uses a trusted execution environment (such as Intel Software Protection Extensions SGX, AMD Secure Encryption Virtualization SEV, or Trust Zone technology) to perform a remote trust verification process.

[0088] The proxy program generates, within the trusted hardware, the hash value of the environment metric (i.e., the measurement value after the code and initial data are loaded into memory), the binary hash value of the proxy program, and a random number issued by the management platform. Then, it digitally signs the above data using the hardware's built-in private key. Upon receiving this proof token, the verification service in the control plane verifies the signature, compares it to whether the metric is on the whitelist, and marks the node as a trusted execution node if the verification is successful.

[0089] The connector component automatically detects and reports the current environment's permissions and resource status. This includes detecting executable application interface permissions, such as whether there are permissions to modify security group rules, isolate containers, or take snapshots of the host; detecting restricted resource status, such as whether only read-only permissions are available; and identifying the underlying cloud platform type, such as Amazon Web Services, Google Cloud, Microsoft Azure, or a private cloud environment. Based on the detection results, the system generates a capability certificate and writes it into the tenant profile.

[0090] The system generates a risk profile based on the business attributes filled in by the tenant. First, the business criticality is determined and categorized into four levels: critical, high, medium, and low. Second, a maximum acceptable damage threshold is set, such as the maximum percentage of containers allowed to be isolated and dismantled. Finally, automatic response levels are set, including different tiers such as alarm-only, rate limiting, and isolation.

[0091] For example: Suppose there are two tenants, tenant A and tenant B, who both access this security system at the same time.

[0092] Tenant A's scenario: Tenant A's agent program runs inside a virtual machine supporting AMD's secure encrypted virtualization technology. The hardware signature generated upon agent startup passes control plane verification. The system marks it as a trusted node and confirms its full execution permissions in its capability certificate. Therefore, the system allows automatic isolation operations to be performed on this tenant's resources.

[0093] Tenant B's scenario: Tenant B's agent program runs in a regular virtual machine without a trusted execution environment. Because it cannot provide hardware-level trusted proof, the system marks it as a not fully trusted node and restricts its entry into "observation mode." In subsequent step six, even if a threat is detected, the system is prohibited from performing any destructive blocking actions against Tenant B to prevent the agent program from being hijacked and subsequently disrupting business operations.

[0094] Step 2: Collect tenant's local multimodal log data, encode and embed vectors, and after privacy processing, the local model calculates the anomaly confidence level. If the threshold is exceeded, rate limiting or blocking is triggered.

[0095] Based on multimodal log data collected locally by the tenant, the log data is encoded into behavior embedding vectors using a self-supervised learning model, and differential privacy noise addition or secure quantization compression processing is performed on the behavior embedding vectors in a trusted execution environment; then, the local deployed micro-model is used to calculate the anomaly confidence level, and local rate limiting or blocking is triggered when the confidence level exceeds the threshold.

[0096] In this embodiment of the disclosure, the behavior embedding vector generation process includes the following:

[0097] For time-series log data, a time-series transformer model is used for encoding.

[0098] For call chain and process tree structure data, a graph torrent algorithm is used for encoding.

[0099] The self-supervised learning model generates representation vectors with generalization capabilities through contrastive learning techniques.

[0100] In this embodiment of the disclosure, massive logs generated by hosts, containers, and networks are transformed into high-quality, privacy-preserving vector representations that can participate in federated training.

[0101] The system collects data from multiple sources locally, including network traffic data containing quintuples and statistics, system call traces in system audit logs, process tree structures, events from container orchestration systems, and image fingerprint information.

[0102] The collected raw data is fed into a self-supervised learning model for encoding. For time-series logs, the system uses a time-series transformer model for processing; for call chains and process tree structures, a graph-to-vector algorithm is used for encoding. Through contrastive learning techniques, the system generates representation vectors with generalization capabilities, namely behavioral embedding vectors, whose dimensions are typically between 64 and 256.

[0103] To protect data privacy, all processing is performed within a trusted execution environment. The system employs differential privacy technology, adding minute differential noise to the generated vector to prevent attackers from reconstructing the original log content. Simultaneously, secure quantization technology is used to compress the vector, reducing the risk of attackers reconstructing the data. The processed vector is then encrypted before being uploaded to the cloud.

[0104] Deploy a lightweight micro-model locally. This model takes an embedding vector as input and outputs anomaly confidence (a value between zero and one). When the confidence is high, it can be used to trigger local rate limiting or blocking measures in advance.

[0105] For example, a series of execution sequences occur within a container: first, the curl tool is used to download a file; then, the file is decompressed; next, the file permissions are changed to executable and the script is run; finally, an outgoing network connection is initiated.

[0106] Vectorization and privacy handling: This sequence is encoded by the transformer model to generate a 128-dimensional vector. In the trusted execution environment, the system adds weak noise to this vector, transforming the original value (e.g., 0.12) into a noisy value (e.g., 0.12 plus noise).

[0107] Local detection and upload: The local mini-model calculates anomaly confidence of 0.82 for this behavior. Based on this high confidence, the system immediately triggers a local rate-limiting policy, restricting the bandwidth of this container to 30%, while uploading the noisy vector for subsequent federated aggregation.

[0108] Step 3: Construct a hierarchical federated architecture that includes tenant local nodes, regional clouds, and a global control plane. Under the premise that log data does not leave the domain, encrypt and aggregate parameters to generate a global model for cross-tenant attack identification and distribute it to each tenant.

[0109] Construct a hierarchical federated learning architecture that includes tenant local nodes, regional cloud aggregators, and global control plane aggregators; while keeping the original log data from leaving the domain, use a secure encrypted aggregation protocol to aggregate the encrypted gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant.

[0110] In this embodiment of the disclosure, the hierarchical federated learning architecture further includes a split learning mechanism:

[0111] For data containing sensitive features, the model is split into a front-end network and a back-end network. The tenant only trains and uploads the activation values ​​of the intermediate layers of the front-end network of the model. These intermediate layer activation values ​​are mathematically irreversible and cannot be restored to the original input data.

[0112] The control plane is responsible for training the model's backend network.

[0113] The secure encryption aggregation protocol specifically includes:

[0114] Tenant nodes encrypt the gradients and upload them to the regional aggregator. The regional aggregator calculates the regional model and uploads it to the global aggregator for aggregation.

[0115] The aggregation process employs a secure multi-party computation protocol to ensure that no single-point aggregator can parse the plaintext gradient value of a single tenant.

[0116] Furthermore, all weight update operations are recorded in a chained hash log for auditing purposes.

[0117] In this embodiment of the disclosure, multiple tenants are allowed to jointly train the global attack detection model, while ensuring that the original logs are not exposed, privacy is not leaked, and unauthorized access to other tenants' data is not allowed.

[0118] The system adopts a layered structure, including tenant-local nodes, regional cloud data center aggregators, and a global control plane aggregator. This architecture reduces network bandwidth consumption, improves system fault tolerance, and allows for localized training in advance.

[0119] During model updates, tenants first encrypt their gradients, then upload them to the regional aggregator, and finally the global aggregator aggregates them. Throughout this process, no single aggregator can see the plaintext gradient values ​​of any individual tenant. The system employs secure aggregation protocols such as Google's or secure multi-party computation (such as Shamir secret sharing or Paillier homomorphic encryption) to achieve this goal.

[0120] For certain particularly sensitive features (such as authentication tokens or user behavior data), the system employs a split learning technique. The tenant only trains the first few layers of the model, while the control plane trains the last few layers. The tenant uploads only the activation values ​​of the intermediate layers, which are mathematically irreversible to be restored to the original input.

[0121] All weight update operations are recorded in a chained hash log to ensure the traceability and auditability of the model training process.

[0122] For example: Suppose there are three tenants participating in collaborative training. Every thirty minutes, each tenant encrypts and uploads the gradients generated during local training.

[0123] After receiving the encryption gradient, the regional aggregator calculates the regional model; the global aggregator further merges the regional models to obtain the updated global model.

[0124] The updated global model was distributed to all tenants. Through this process, all tenants gained the ability to identify cross-tenant attack patterns (such as supply chain attacks), even if some tenants had never encountered such attacks before.

[0125] Step 4: Based on multi-tenant behavior embedding and event sequence relationship, construct a causal attack graph containing entities and event nodes. After causal inference and graph transformer reasoning, output the propagation risk probability, root cause, and hub node.

[0126] Construct a causal attack graph and perform graph transformer inference; based on the behavior embedding vectors of multi-tenants and the temporal relationship of events, construct a causal attack graph containing entity nodes and event nodes; use causal inference methods to identify causal edges between events, and use the graph transformer model to infer the attack graph, outputting the propagation risk probability of each node and the root cause node and hub node in the attack chain.

[0127] In this embodiment of the disclosure, the method of identifying causal edges between events using causal inference specifically includes:

[0128] By comprehensively utilizing Granger causality tests, time-point processes, and structural causality models, and based on the temporal sequence of events, behavioral similarities, and contextual environment, it is determined whether the first event is a potential cause of the second event, and directional causal edges are established in the causal attack graph.

[0129] In this embodiment of the disclosure, it is not only necessary to identify the similarity between events, but also to determine the causal relationship between events, and to find the root cause node of the attack and potential propagation links.

[0130] The system constructs a graph containing two types of nodes: event nodes (such as login, image pulling, and process execution) and entity nodes (such as hosts, IP addresses, users, and images). Edges in the graph represent different types of relationships: time edges represent associations based on time order; similarity edges represent associations based on the cosine distance of embedding vectors; and causal edges represent the logical relationship where event A leads to event B.

[0131] The system uses Granger causality tests, time-point processes, and structural causal models to comprehensively consider time sequence, behavioral similarity, and context to determine whether event A is a potential cause of event B.

[0132] The system uses a graph transformer model to reason about the constructed attack graph and outputs the propagation risk probability of each node and the hub nodes in the attack path.

[0133] The system also outputs explanations for judging causal relationships, such as "same mirror hash", "time interval within a specific range", or "call chain similarity higher than the threshold".

[0134] For example: A code hosting platform's continuous integration process pushed an image, and then the same malicious process suddenly appeared in the multi-tenant environment.

[0135] The system constructs a graph and analyzes and outputs the causal chain: the continuous integration push that occurred at time point one led to the mirror deployment at time point two, which in turn led to the process abnormality at time point three.

[0136] The graph transformer inference determined that the propagation risk of the attack was 0.87. Simultaneously, the system identified the continuous integration pipeline as the root cause of the attack.

[0137] Step 5: Integrate local anomalies, global models, propagation risks, and threat intelligence matching to obtain a unified score, and dynamically adjust the alarm threshold based on the tenant's business criticality and attack situation;

[0138] In response to the fusion of local anomaly detection scores, global model scores, propagation risk values ​​derived from causal graphs, and threat intelligence matching degrees, a unified threat score is generated through weighted calculation; and the alarm threshold used to determine the threat level is dynamically adjusted based on the business criticality in the tenant profile and the current overall attack situation.

[0139] In this embodiment of the disclosure, scores from different sources are merged to provide a unified, credible, and interpretable risk score.

[0140] The final threat score is calculated using a weighted average and consists of: local detection score, global model score, causal propagation risk value, and threat intelligence matching degree.

[0141] The system outputs the percentage of each component in the final score, clearly indicating how much score each of local detection, global model, causal propagation, and threat intelligence matching contributed.

[0142] The system automatically adjusts the judgment threshold based on the business criticality generated in step one and the current overall attack situation. For example, in critical business scenarios or during periods of high attack activity, the threshold will be automatically adjusted to meet security requirements.

[0143] Based on the scoring results, the system provides tiered action suggestions: when the score is higher than 0.95, automatic isolation is recommended; when the score is between 0.7 and 0.95, manual review is recommended; when the score is lower than 0.7, monitoring is recommended.

[0144] For example, the system receives scores from the following sources: local detection score of 0.8, global model score of 0.6, propagation risk score of 0.9, and threat intelligence matching degree of 1 (i.e., a perfect match).

[0145] After weighted fusion, the final threat score calculated by the system is 0.84.

[0146] Since the score is between 0.7 and 0.95, the system recommends "semi-automatic isolation," which means that isolation is recommended, but tenant authorization is required.

[0147] Step 6: Synthesize the high-level defense intent into a cross-cloud execution plan, formally verify that it does not violate the tenant's service level agreement, execute the defense actions in transaction mode, and perform reversible actions with compensation rollback to restore the system.

[0148] Based on automatically synthesizing high-level defense intentions into specific cross-cloud execution plans, and using formal verification methods to verify whether the execution plan violates the tenant's service level agreement before execution; the defense actions in the execution plan are executed in transaction mode, and corresponding compensation rollback operations are configured for each reversible action to support the recovery of system state in case of misjudgment or abnormality.

[0149] In this embodiment of the disclosure, the step of verifying whether the execution plan violates the tenant's service level agreement using a formal verification method before execution specifically includes:

[0150] Using a satisfiability model theory solver or bounded model checking technique, verify whether the system state after the execution plan is implemented meets the minimum service replica limit, service reachability requirements, and business continuity threshold set in the tenant profile;

[0151] The execution of the defensive actions in the execution plan is carried out in transaction mode, and corresponding compensation rollback operations are configured for each reversible action. Specifically, this includes:

[0152] The transaction mode is executed using a compensatory transaction mechanism.

[0153] The execution plan is broken down into a series of ordered sub-operations, including blocking traffic, restricting access, generating snapshots, and isolating containers;

[0154] If any sub-operation fails or a rollback instruction is received, the system automatically triggers the corresponding compensation operation to roll back the environment state to the state before the sub-operation was executed.

[0155] In this embodiment of the disclosure, the risk score generated in the previous step is transformed into a safe, reliable, and rollback-capable collaborative action.

[0156] Users do not need to write complex low-level rules; they only need to express high-level intents, such as "isolate suspicious containers while keeping evidence accessible." The system will automatically synthesize this intent into specific operation instructions, such as modifying security group rules, adjusting service mesh flow control policies, generating system snapshots, and tagging evidence.

[0157] Before the strategy is executed, the system performs formal verification using a satisfiability modular theory solver or bounded model checking techniques. The purpose of verification is to ensure that the generated execution plan does not violate the tenant's service level agreement, such as the minimum number of container replicas, service reachability requirements, and business continuity thresholds.

[0158] The system employs a transactional execution strategy to ensure the atomicity and reversibility of operations. The rollback capability of the execution chain ensures extremely low costs for false positives in case of misjudgment.

[0159] For example: Based on the extremely high threat score of 0.96 obtained in step 5, the system receives the intent instruction to "isolate the container and preserve the scene".

[0160] The system first verifies the service level agreement to confirm that the number of remaining replicas after isolating the container meets the requirement of at least three replicas. After successful verification, the system executes the generated policy plan.

[0161] All actions are recorded in a chained hash log. If a false alarm or a failure is found after the operation, the administrator can issue a rollback command, and the system will automatically roll back the environment state to the state before the traffic blocking was executed (i.e., the state in step 2).

[0162] Example 2:

[0163] like Figure 2 As shown, to solve the above-mentioned technical problems, based on Embodiment 1, another technical solution adopted in this application is: a multi-tenant adaptive collaborative defense system in a hybrid cloud scenario, comprising:

[0164] The Trusted Profiling Module is configured to perform hardware-based remote trust verification on each tenant's agent or connector, and grant the corresponding trusted execution node tag after verifying the trustworthiness of its runtime environment and code integrity; at the same time, it automatically detects the tenant's cloud platform type, interface permissions and resource restrictions, and generates a machine-readable tenant profile that includes business criticality, maximum acceptable damage threshold and automatic response level.

[0165] The local anomaly detection module is configured to collect multimodal log data locally on the tenant's premises, encode the log data into behavior embedding vectors using a self-supervised learning model, and perform differential privacy noise addition or secure quantization compression processing on the behavior embedding vectors within a trusted execution environment; then, it uses a locally deployed micro-model to calculate the anomaly confidence level, and triggers local rate limiting or blocking when the confidence level exceeds a threshold.

[0166] The federated aggregation module is configured to build a hierarchical federated learning architecture that includes tenant local nodes, regional cloud aggregators, and global control plane aggregators. While keeping the original log data from leaving the domain, it uses a secure encrypted aggregation protocol to aggregate the encrypted gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant.

[0167] The graph reasoning module is configured to construct a causal attack graph and perform graph transformer reasoning; based on the behavior embedding vectors of multi-tenants and the event sequence relationship, a causal attack graph containing entity nodes and event nodes is constructed; causal inference methods are used to identify causal edges between events, and the attack graph is reasoned through the graph transformer model to output the propagation risk probability of each node and the root cause node and hub node in the attack chain.

[0168] The scoring and threshold adjustment module is configured to generate a unified threat score by weighted calculation in response to the fusion of local anomaly detection score, global model score, propagation risk value derived from causal graph inference, and threat intelligence matching degree; and dynamically adjust the alarm threshold used to determine the threat level based on the business criticality in the tenant profile and the current overall attack situation.

[0169] The verification and rollback module is configured to automatically synthesize high-level defense intentions into specific cross-cloud execution plans, and to verify whether the execution plan violates the tenant's service level agreement using formal verification methods before execution; to execute the defense actions in the execution plan in transaction mode, and to configure corresponding compensation rollback operations for each reversible action to support the recovery of the system state in case of misjudgment or abnormality.

[0170] For other details regarding the implementation techniques of each module in the system of the above embodiment one, please refer to the description in the multi-tenant adaptive collaborative defense method in the hybrid cloud scenario in the above embodiment, which will not be repeated here.

[0171] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system-type embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0172] Example 3:

[0173] like Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the electronic device in the embodiment of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0174] like Figure 3 As shown, an electronic device includes a processor, a memory, and a communication interface. The memory stores a computer program, and when the processor executes the computer program, it implements the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario described in the embodiments of this disclosure. The electronic device can exchange data with other devices or systems through the communication interface to achieve real-time updates and sharing of drug information.

[0175] The processor in the aforementioned electronic device serves as its core, responsible for executing the computer program stored in the memory to implement various functions of the paperless conference terminal intelligent defense method. The processor can employ a high-performance multi-core CPU or a dedicated chip to meet the demands of complex calculations and real-time processing. The memory stores the operating system, applications, data, and computer programs. In this embodiment, the memory stores the computer program implementing the paperless conference terminal intelligent defense method. The memory can be RAM, ROM, Flash memory, or other types of non-volatile memory. The communication interface connects the electronic device to other devices or networks, enabling data transmission and exchange. In this embodiment, the communication interface supports multiple communication protocols and interface standards, such as Wi-Fi, Bluetooth, USB, and Ethernet, to meet communication needs in different scenarios.

[0176] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0177] Example 4:

[0178] According to an embodiment of the present disclosure, a computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the functions of the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario described in the foregoing embodiments of the present disclosure.

[0179] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0180] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0181] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-tenant adaptive collaborative defense method in a hybrid cloud scenario, characterized in that, Includes the following steps: Obtain remote trusted proof of hardware, verify the trustworthiness and code integrity of tenant agent based on the remote trusted proof and grant a tag, and detect cloud information to generate a machine-readable profile containing key parameters; The system collects local multimodal log data from tenants, encodes and embeds the vectors, performs privacy processing, then uses a locally deployed micro-model to calculate the anomaly confidence level, and triggers local rate limiting or blocking when the confidence level exceeds a threshold. Construct a hierarchical federated architecture that includes tenant local nodes, regional clouds and a global control plane. Under the premise that log data does not leave the domain, use a secure encryption aggregation protocol to aggregate the encryption gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant. Based on the behavior embedding vectors of multi-tenants and the temporal relationship of events, a causal attack graph containing entities and event nodes is constructed. After causal inference and graph transformer reasoning, the probability of propagation risk, root cause, and hub node are output. A unified score is obtained by weighting the matching degree of local anomalies, global models, propagation risks, and threat intelligence. Based on the score results, the system provides graded action suggestions: when the score is higher than 0.95, automatic isolation is recommended; when the score is between 0.7 and 0.95, manual review is recommended; when the score is lower than 0.7, monitoring status is recommended; and the alarm threshold used to determine the threat level is dynamically adjusted in combination with the tenant's business criticality and attack posture. The high-level defense intent is automatically synthesized into a specific cross-cloud execution plan, and formal verification methods are used to verify whether the execution plan violates the tenant's service level agreement before execution. The defense actions in the execution plan are executed in transaction mode, and corresponding compensation rollback operations are configured for each reversible action to support the recovery of the system state in case of misjudgment or abnormality.

2. The defense method according to claim 1, characterized in that, The process of obtaining remote trusted proof of hardware, verifying tenant agent trustworthiness and code integrity based on the remote trusted proof and assigning a tag, and probing cloud information to generate a machine-readable profile containing key parameters specifically includes: In response to performing hardware-based remote trust verification on each tenant's agent or connector, the system grants a corresponding trusted execution node tag after verifying the trustworthiness of its runtime environment and the integrity of its code. At the same time, it automatically detects the cloud platform type, interface permissions, and resource constraints on the tenant's side, and generates a machine-readable tenant profile that includes business criticality, maximum acceptable damage threshold, and automatic response level. The remote trusted proof includes: The agent program generates a proof token containing an environmental metric hash value, a binary hash value, and a random number inside the trusted hardware, and digitally signs the proof token using the hardware's built-in private key. Upon receiving the proof token, the verification service in the control plane verifies the digital signature and compares the environmental metric hash value with the whitelist. If the verification is successful, the node is marked as a trusted execution node.

3. The defense method according to claim 1, characterized in that, The collected tenant's local multimodal log data is encoded and embedded into a vector. After privacy processing, the local model calculates anomaly confidence levels exceeding a threshold to trigger rate limiting or blocking. Specifically, this includes: Based on multimodal log data collected locally by the tenant, the log data is encoded into behavior embedding vectors using a self-supervised learning model, and differential privacy noise addition or secure quantization compression processing is performed on the behavior embedding vectors in a trusted execution environment; then, the local deployed micro-model is used to calculate the anomaly confidence level, and local rate limiting or blocking is triggered when the confidence level exceeds the threshold. The behavior embedding vector generation process includes: For time-series log data, a time-series transformer model is used for encoding. For call chain and process tree structure data, a graph torrent algorithm is used for encoding. The self-supervised learning model generates representation vectors with generalization capabilities through contrastive learning techniques.

4. The defense method according to claim 1, characterized in that, The construction of a hierarchical federated architecture, including tenant local nodes, regional clouds, and a global control plane, involves generating a global cross-tenant attack identification model by encrypting and aggregating parameters, and distributing it to each tenant, all while ensuring that log data does not leave the domain. Specifically, this includes: Construct a hierarchical federated learning architecture that includes tenant local nodes, regional cloud aggregators, and global control plane aggregators; while keeping the original log data from leaving the domain, use a secure encrypted aggregation protocol to aggregate the encrypted gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant. The hierarchical federated learning architecture also includes a split learning mechanism: For data containing sensitive features, the model is split into a front-end network and a back-end network. The tenant only trains and uploads the activation values ​​of the intermediate layers of the front-end network of the model. These intermediate layer activation values ​​are mathematically irreversible and cannot be restored to the original input data. The control plane is responsible for training the model's backend network.

5. The defense method according to claim 4, characterized in that, The secure encryption aggregation protocol specifically includes: Tenant nodes encrypt the gradients and upload them to the regional aggregator. The regional aggregator calculates the regional model and uploads it to the global aggregator for aggregation. The aggregation process of the global aggregator adopts a secure multi-party computation protocol to ensure that no single-point aggregator can parse the plaintext gradient value of a single tenant. Furthermore, all weight update operations are recorded in a chained hash log for auditing purposes.

6. The defense method according to claim 2, characterized in that, The method constructs a causal attack graph containing entities and event nodes based on multi-tenant behavior embedding and event sequence relationships. Through causal inference and graph transformer reasoning, it outputs the propagation risk probability, root causes, and hub nodes, specifically including: Construct a causal attack graph and perform graph transformer inference; based on the behavior embedding vectors of multi-tenants and the temporal relationship of events, construct a causal attack graph containing entity nodes and event nodes; use causal inference methods to identify causal edges between events, and use the graph transformer model to infer the attack graph, outputting the propagation risk probability of each node and the root cause node and hub node in the attack chain. The method of identifying causal edges between events using causal inference specifically includes: By comprehensively utilizing Granger causality tests, time-point processes, and structural causality models, and based on the temporal sequence of events, behavioral similarities, and contextual environment, it is determined whether the first event is a potential cause of the second event, and directional causal edges are established in the causal attack graph. The unified score is obtained by weighting the matching degree of local anomalies, global models, propagation risks, and threat intelligence. This score is then dynamically adjusted based on the tenant's business criticality and attack posture. Specifically, this includes: In response to the integration of local anomaly detection scores, global model scores, propagation risk values ​​derived from causal graphs, and threat intelligence matching degrees, a unified threat score is generated through weighted calculation; and the alarm threshold used to determine the threat level is dynamically adjusted based on the business criticality in the tenant profile and the current overall attack situation.

7. The defense method according to claim 1, characterized in that, The aforementioned high-level defense intent is synthesized into a cross-cloud execution plan, which, after formal verification, does not violate the tenant's service level agreement. Defense actions are executed in transaction mode, and reversible actions are coupled with compensatory rollbacks to restore the system. Specifically, this includes: Based on automatically synthesizing high-level defense intentions into specific cross-cloud execution plans, and using formal verification methods to verify whether the execution plan violates the tenant's service level agreement before execution; the defense actions in the execution plan are executed in transaction mode, and corresponding compensation rollback operations are configured for each reversible action to support the recovery of system state in case of misjudgment or abnormality; The step of verifying whether the execution plan violates the tenant's service level agreement using formal verification methods before execution specifically includes: Using a satisfiability model theory solver or bounded model checking technique, verify whether the system state after the execution plan is implemented meets the minimum service replica limit, service reachability requirements, and business continuity threshold set in the tenant profile; The execution of the defensive actions in the execution plan is carried out in transaction mode, and corresponding compensation rollback operations are configured for each reversible action. Specifically, this includes: The transaction mode is executed using a compensatory transaction mechanism. The execution plan is broken down into a series of ordered sub-operations, including blocking traffic, restricting access, generating snapshots, and isolating containers; If any sub-operation fails or a rollback instruction is received, the system automatically triggers the corresponding compensation operation to roll back the environment state to the state before the sub-operation was executed.

8. A multi-tenant adaptive collaborative defense system for hybrid cloud scenarios, applied to the multi-tenant adaptive collaborative defense method for hybrid cloud scenarios as described in any one of claims 1-7, characterized in that, include: The Trusted Profiling Module is configured to perform hardware-based remote trust verification on each tenant's agent or connector, and grant the corresponding trusted execution node tag after verifying the trustworthiness of its runtime environment and code integrity; at the same time, it automatically detects the tenant's cloud platform type, interface permissions and resource restrictions, and generates a machine-readable tenant profile that includes business criticality, maximum acceptable damage threshold and automatic response level. The local anomaly detection module is configured to collect multimodal log data locally on the tenant's premises, encode the log data into behavior embedding vectors using a self-supervised learning model, and perform differential privacy noise addition or secure quantization compression processing on the behavior embedding vectors within a trusted execution environment. Then, the local deployed micro-model is used to calculate the anomaly confidence level, and local rate limiting or blocking is triggered when the confidence level exceeds the threshold. The federated aggregation module is configured to build a hierarchical federated learning architecture that includes tenant local nodes, regional cloud aggregators, and global control plane aggregators. While keeping the original log data from leaving the domain, it uses a secure encrypted aggregation protocol to aggregate the encrypted gradients or model parameters uploaded by each tenant layer by layer, generate a global model with cross-tenant attack pattern recognition capabilities, and distribute the updated global model to each tenant. The graph reasoning module is configured to construct a causal attack graph and perform graph transformer reasoning; based on the behavior embedding vectors of multi-tenants and the event sequence relationship, a causal attack graph containing entity nodes and event nodes is constructed; causal inference methods are used to identify causal edges between events, and the attack graph is reasoned through the graph transformer model to output the propagation risk probability of each node and the root cause node and hub node in the attack chain. The scoring and threshold adjustment module is configured to generate a unified threat score by weighting the local anomaly detection score, the global model score, the propagation risk value derived from the causal graph, and the threat intelligence matching degree. Based on the scoring results, the system provides tiered action suggestions: automatic isolation is recommended when the score is higher than 0.95; manual review is recommended when the score is between 0.7 and 0.95; and monitoring is recommended when the score is lower than 0.

7. The alarm threshold used to determine the threat level is dynamically adjusted based on the business criticality in the tenant profile and the current overall attack situation. The verification and rollback module is configured to automatically synthesize high-level defense intentions into specific cross-cloud execution plans, and to verify whether the execution plan violates the tenant's service level agreement using formal verification methods before execution; to execute the defense actions in the execution plan in transaction mode, and to configure corresponding compensation rollback operations for each reversible action to support the recovery of the system state in case of misjudgment or abnormality.

9. An electronic device, characterized in that, It includes a processor, a memory, and a communication interface. The memory stores a computer program. When the processor executes the computer program, it implements the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the multi-tenant adaptive collaborative defense method in a hybrid cloud scenario as described in any one of claims 1 to 7.

Images