Openstack block storage implementation system and method based on non-invasive mimicry defense

Abstract

The present application relates to the technical field of data processing, in particular to an openstack block storage implementation system and method based on non-invasive quasimodo defense, which integrates quasimodo user side brackets, negative feedback control system, running state sensing module, execution body monitoring and decision-making and other quasimodo components into the block storage of openstck, places the cinder-api request service component in the quasimodo protection area, sends the request to one of the cinder-api request service components, observes and collects underlying sensitive events according to the needs of the user state and the kernel state of various mounting points, so as to complete threat analysis and processing. The present application can give the block storage service the ability to resist unknown vulnerability attacks while retaining the original low latency and high throughput business performance of OpenStack block storage to the greatest extent, so that it has the ability to resist network attack behaviors initiated from the operating system, runtime and application service.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an OpenStack block storage implementation system and method based on non-intrusive mimicry defense. Background Technology

[0002] OpenStack block storage (Cinder) implements dynamic management of virtual machine disks through a layered architecture. Its block storage service consists of three major components: cinder-api, cinder-scheduler, and cinder-volume, forming a three-level structure of "request-scheduling-execution" to abstract and pool storage resources, and complete the creation and allocation of volumes through the collaborative work of API, scheduler, and driver layer.

[0003] In the application of mimicry defense transformation and security protection for OpenStack block storage services, existing methods, whether for full-scenario mimicry construction of cloud services or specific hardening for Cinder services, require deep customization of the source code of core OpenStack block storage components to adapt to mimicry defense mechanisms such as mimicry adjudication, multi-executor scheduling, and request distribution. This transformation model not only disrupts the original business logic of the block storage service, leading to difficulties in OpenStack version upgrades and frequent compatibility failures of upstream and downstream components, but also requires customized development for different OpenStack distributions and deployment architectures, resulting in extremely high R&D and maintenance costs. It fails to achieve non-intrusive security hardening of existing OpenStack block storage systems, making large-scale deployment difficult. Furthermore, it commonly includes all components of the Cinder service—cinder-api, cinder-scheduler, and cinder-volume—in the mimicry protection zone, deploying multiple heterogeneous redundant execution entities for each component. Core business processes such as block storage volume creation, snapshot management, and backup and recovery require multiple rounds of parallel processing by multiple execution entities and result consistency adjudication processes. Especially in scenarios where there are a large number of database interactions and remote calls to the storage backend, the time difference in processing by multiple execution entities can cause request blocking and an exponential increase in response latency. At the same time, the continuous operation of multiple redundant execution entities will consume a large amount of computing, storage, and network resources, significantly increasing the system deployment and operation costs. It is impossible to meet the core performance requirements of low latency and high throughput for block storage services while ensuring mimicry security capabilities. Summary of the Invention

[0004] To address the issues of poor adaptability and feasibility of OpenStack block storage service mimicry defense, and its inability to balance security protection with high-performance business requirements, this invention provides an OpenStack block storage implementation system and method based on non-intrusive mimicry defense. The system places the Cinder-API request service component within a mimicry protection zone, sending requests to one of these components. It then observes various mount points in user space and kernel space as needed, collecting underlying sensitive events to perform threat analysis and processing. This requires no modifications to the block storage source code, enabling it to resist network attacks originating from the operating system, runtime, and application service levels.

[0005] According to the design scheme provided by this invention, on one hand, an OpenStack block storage implementation system based on non-intrusive mimicry defense is provided. The OpenStack platform based on mimicry defense includes: a user-side proxy adjudication module, a Cinder request service execution module, a Cinder scheduling service component, a Cinder execution service component, a threat analysis module, and a threat response module. The Cinder request service execution module includes: heterogeneous request service execution units formed by replicating the Cinder request service component and deploying it on heterogeneous physical servers; and a running status awareness module deployed on physical servers using eBPF technology to monitor the running status of the corresponding request service execution units on the physical servers in real time. There are N heterogeneous request service execution units, and N≥3.

[0006] The user-side proxy adjudication module is used to receive user requests and forward them to one of the request service execution bodies according to a preset scheduling mode.

[0007] The request service executor is used to receive user requests and verify the volume information in the user requests. If the verification passes, it generates a volume operation request based on the volume information and sends it to the Cinder scheduling service component.

[0008] The Cinder scheduling service component is used to select the storage node for creating the volume based on the volume operation request information.

[0009] The Cinder execution service component is used to perform volume operations on storage nodes;

[0010] The threat analysis module is used to receive the request service execution status information collected by each operation status awareness module and judge network anomalies based on sensitive events;

[0011] The threat response module is used to handle and respond to network anomaly assessments.

[0012] As an implementation system of OpenStack block storage based on non-intrusive mimicry defense in this invention, the heterogeneous physical servers are physical servers with different CPU architectures and / or operating systems.

[0013] As an OpenStack block storage implementation system based on non-intrusive mimicry defense, the present invention further includes the following: the runtime status awareness module comprises an event probe unit, an event communication unit, and a configuration management unit, wherein...

[0014] The event probe unit is based on eBPF technology and sets the mount driver and mount function on the corresponding mount points in user mode and kernel mode, so as to perceive the state of the mount point by calling the API interface of the mount driver and mount function.

[0015] The event communication unit reports the perception status data of the corresponding event type to the threat analysis module according to the threat analysis requirements;

[0016] The configuration management unit manages the configuration of the event probe unit and the event communication unit according to the threat analysis requirements.

[0017] As an OpenStack block storage implementation system based on non-intrusive mimicry defense, the threat analysis module further includes: an intrinsic security analysis unit, a cloud-native security analysis unit, and a decision-making unit, wherein...

[0018] The intrinsic security analysis unit extracts the behavioral characteristics of the executor based on the executor's operating status and uses intrinsic security analysis methods, and monitors and adjudicates the behavioral characteristics. The intrinsic security analysis methods are ATT&CK threat analysis and detection methods or artificial intelligence threat analysis and detection methods.

[0019] The cloud-native security analysis unit detects the security of the entire cloud-native process based on the execution status and through image security analysis, runtime event security analysis, and microservice security analysis. Specifically, image security analysis determines whether the image has abnormal behavior by driving the image to run in a sandbox, runtime event security analysis detects abnormal behavior of the runtime events of the host machine and containers, and microservice security analysis detects abnormal behavior of microservices by establishing a process call association tree.

[0020] The decision-making unit integrates the behavioral feature monitoring and adjudication results, the mirror abnormal behavior judgment results, the runtime event abnormal behavior detection results, and the microservice abnormal behavior detection results to determine network anomalies.

[0021] As an implementation system of OpenStack block storage based on non-intrusive mimicry defense in this invention, the threat response module further includes a negative feedback control threat response unit and a cloud-native threat response unit, wherein...

[0022] The negative feedback control threat response unit responds to intrinsic security threats by processing abnormal request service executors.

[0023] The cloud-native threat response unit responds to cloud-native security threats through behavior alerts, behavior auditing, and blocking.

[0024] Furthermore, this invention also provides an OpenStack block storage implementation method based on non-intrusive mimicry defense, which, based on the above-mentioned system implementation, includes:

[0025] Receive user requests and forward them to one of the request service execution entities according to the preset scheduling mode;

[0026] The request service executor verifies the volume information in the user request, and generates a volume operation request based on the volume information if the verification passes.

[0027] Select the storage node for creating the volume based on the volume operation request information;

[0028] Perform volume operations on the storage node;

[0029] In the process of verifying volume information and generating volume operation requests, the system monitors the running status of the request service execution body in real time, judges network anomalies based on sensitive events, and handles and responds according to the judgment results.

[0030] As a further step in the OpenStack block storage implementation method based on non-intrusive mimicry defense of this invention, the method further includes forwarding user requests to one of the request service execution bodies according to a preset scheduling mode, comprising:

[0031] User requests are forwarded to one of the request service execution entities through a polling mechanism or the least number of connections principle.

[0032] As a further implementation of the OpenStack block storage method based on non-intrusive mimicry defense in this invention, the real-time sensing of the running status of the request service execution body includes:

[0033] Non-sensitive system events during the execution of the request service execution body are filtered according to pre-configured event filtering rules, and sensitive system events are captured. The event filtering rules are configured at the full mount point in kernel mode and user mode based on eBPF technology.

[0034] The beneficial effects of this invention are:

[0035] 1. This invention is highly adaptable and non-intrusive, significantly reducing the threshold for implementation and the overall cost. It requires no modification to the native source code of OpenStack block storage, is fully compatible with the native business logic of the Cinder service, and will not affect OpenStack version upgrades or the adaptation of upstream and downstream components. It can be quickly adapted to various existing OpenStack clusters. At the same time, it only performs mimicry deployment on the core attack surface component cinder-api, without the need for redundant modification of all components in the entire chain. This greatly reduces the R&D investment, deployment difficulty, and operation and maintenance complexity of the mimicry solution, and has a strong ability to be deployed at scale.

[0036] 2. This invention's lightweight mimicry architecture minimizes performance overhead, addressing the industry pain point of the trade-off between security and performance. Only the cinder-api is included in the mimicry protection zone, while the core backend business components retain their native operating mode. This completely avoids performance issues such as multi-round adjudication, database interaction blocking, and surges in request latency caused by full component mimicry. At the same time, based on eBPF technology, runtime status awareness completes event collection and filtering in kernel space, with minimal impact on business process performance. While providing block storage services with mimicry defense capabilities against unknown vulnerability attacks, it maximizes the preservation of OpenStack block storage's native low latency and high throughput performance.

[0037] 3. This invention provides full-scenario attack protection coverage, achieving a significant upgrade in security protection capabilities. It integrates intrinsic security and cloud-native security dual-dimensional protection capabilities. It effectively defends against unknown network attacks based on unknown vulnerabilities and backdoors through the dynamic, heterogeneous, and redundant core characteristics of mimicry defense, filling the core gap that traditional security solutions cannot defend against unknown threats. Furthermore, through cloud-native security detection throughout the entire process of images, runtime, and microservices, it fully covers mainstream known attack scenarios such as viruses, Trojans, container escape, and lateral movement, achieving full-scenario protection against both known and unknown threats and significantly expanding the security protection boundaries of block storage systems.

[0038] 4. This invention employs a tiered and precise response mechanism, balancing security loop security with continuous and stable business operations. Targeting different types and levels of security threats, it utilizes a dual-track tiered response mechanism. For attacks on core execution entities, it achieves rapid closure through mimicry dynamic scheduling. For non-core cloud-native security risks, it achieves precise handling through isolation, auditing, and tracing, without interrupting normal business operations. This ensures rapid handling of attack events, preventing the attack scope from expanding, while also eliminating the business interruption problems caused by the "one-size-fits-all" approach of traditional solutions. It maximizes the continuous and stable operation of block storage services while ensuring ultimate security protection. Attached Figure Description

[0039] Figure 1This is a schematic diagram of the OpenStack block storage system architecture based on non-intrusive mimicry defense in the embodiment.

[0040] Figure 2 This is a schematic diagram of the OpenStack block storage operation process based on non-intrusive mimicry defense in the embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this invention clearer and more understandable, the invention will be further described in detail below with reference to the accompanying drawings and technical solutions.

[0042] To address the issue of mimicry defense in OpenStack block storage services, this invention provides an OpenStack block storage implementation system based on non-intrusive mimicry defense. The OpenStack platform based on mimicry defense includes: a user-side proxy adjudication module, a Cinder request service execution module, a Cinder scheduling service component, a Cinder execution service component, a threat analysis module, and a threat response module. The Cinder request service execution module comprises: heterogeneous request service execution units formed by replicating and deploying the Cinder request service component on heterogeneous physical servers; and a runtime status awareness module deployed on physical servers using eBPF technology to monitor the real-time runtime status of the corresponding request service execution units on the physical servers. There are N heterogeneous request service execution units, where N≥3.

[0043] The user-side proxy adjudication module is used to receive user requests and forward them to one of the request service execution bodies according to a preset scheduling mode.

[0044] The request service executor is used to receive user requests and verify the volume information in the user requests. If the verification passes, it generates a volume operation request based on the volume information and sends it to the Cinder scheduling service component.

[0045] The Cinder scheduling service component is used to select the storage node for creating the volume based on the volume operation request information.

[0046] The Cinder execution service component is used to perform volume operations on storage nodes;

[0047] The threat analysis module is used to receive the request service execution status information collected by each operation status awareness module and judge network anomalies based on sensitive events;

[0048] The threat response module is used to handle and respond to network anomaly assessments.

[0049] like Figure 1As shown in the diagram, the green part represents the functional modules of the mimicry service, and the blue part represents the functional modules of the Cinder service in the OpenStack cloud platform. The Cinder service mainly includes three sub-modules: Cinder-api, Cinder-scheduler, and Cinder-volume. Since the Cinder-api sub-module directly interacts with the user, it is most vulnerable to network attacks. To comprehensively consider network security and overall service costs, in this embodiment, only the Cinder-api sub-module is placed in the mimicry protection zone, while the Cinder-scheduler and Cinder-volume sub-modules are placed outside the mimicry protection zone. The Cinder-api sub-module is replicated multiple times, for example, up to three times, and these replicated Cinder-api copies are deployed on physical servers with different CPU architectures and operating systems to achieve heterogeneous execution entities and realize redundancy and heterogeneity in mimicry defense technology.

[0050] Only the cinder-api submodule, which directly interacts with users and has the largest attack surface, is included in the mimicry protection zone. Multiple sets of heterogeneous redundant execution entities are deployed across CPU architectures and operating systems. Backend business components such as cinder-scheduler and cinder-volume retain their native deployment mode. No modifications are required to the OpenStack block storage source code throughout the process. It is fully compatible with native business logic and version iterations, achieving non-intrusive and lightweight security hardening of existing block storage systems.

[0051] The operational status awareness module can be designed to include: an event probe unit, an event communication unit, and a configuration management unit, wherein...

[0052] The event probe unit is based on eBPF technology and sets the mount driver and mount function on the corresponding mount points in user mode and kernel mode, so as to perceive the state of the mount point by calling the API interface of the mount driver and mount function.

[0053] The event communication unit reports the perception status data of the corresponding event type to the threat analysis module according to the threat analysis requirements;

[0054] The configuration management unit manages the configuration of the event probe unit and the event communication unit according to the threat analysis requirements.

[0055] The event probe unit, based on eBPF technology, integrates mount drivers and functions for various mount points in user space and kernel space, and provides an API interface, allowing users to easily perceive the status of mount points by calling the API. The event communication unit can report various events as needed by the attack analysis response end. Finally, the configuration management unit is responsible for configuring and managing the built-in rules of the event probe unit and the event communication unit. The runtime status awareness modules on multiple physical servers will transmit the collected monitoring information to the threat analysis module in real time.

[0056] Based on eBPF technology, event collection is achieved at all mount points in kernel and user modes. Without the need to embed points in business code, all system events during the execution of the cinder-api execution body can be captured non-intrusively. Through scalable memory management and event filtering rules, non-sensitive normal events can be quickly filtered, and sensitive system events can be accurately selected and reported, providing a full-dimensional, low-performance data source for threat detection.

[0057] The threat analysis module can be designed to include: an intrinsic security analysis unit, a cloud-native security analysis unit, and a decision-making unit.

[0058] The intrinsic security analysis unit extracts the behavioral characteristics of the executor based on the executor's operating status and uses intrinsic security analysis methods, and monitors and adjudicates the behavioral characteristics. The intrinsic security analysis methods are ATT&CK threat analysis and detection methods or artificial intelligence threat analysis and detection methods.

[0059] The cloud-native security analysis unit detects the security of the entire cloud-native process based on the execution status and through image security analysis, runtime event security analysis, and microservice security analysis. Specifically, image security analysis determines whether the image has abnormal behavior by driving the image to run in a sandbox, runtime event security analysis detects abnormal behavior of the runtime events of the host machine and containers, and microservice security analysis detects abnormal behavior of microservices by establishing a process call association tree.

[0060] The decision-making unit integrates the behavioral feature monitoring and adjudication results, the mirror abnormal behavior judgment results, the runtime event abnormal behavior detection results, and the microservice abnormal behavior detection results to determine network anomalies.

[0061] The threat analysis module determines whether the system is under cyberattack based on monitoring information reported by the runtime status awareness module. From the perspective of attack behavior detection, it can be divided into intrinsic security measures and traditional security measures. Intrinsic security measures use abnormal metadata discovered by execution entity behavior monitoring and adjudication as the basis for judgment. In execution entity monitoring and adjudication, after normalizing heterogeneous events of the execution entity, behavioral characteristics of the execution entity are extracted based on methods such as ATT&CK and artificial intelligence, and these behavioral characteristics are monitored and adjudicated. Traditional security measures achieve full-process coverage of cloud-native security, including image security, runtime security, and microservice security. Image security drives the image to run in a sandbox and monitors its abnormal behavior to determine whether it poses a security threat; runtime security detects abnormal behavior in the runtime events of the host machine and containers to discover abnormal behavior; microservice security detects abnormal behavior of services by establishing a process call relationship tree. Finally, the decision layer combines the attack judgment results of the above multiple methods and integrates multi-dimensional information to conduct a comprehensive attack judgment. When the decision layer determines that a cyberattack has occurred, it sends this information to the threat response module.

[0062] Breaking away from the existing mimicry solutions that rely solely on the consistency of results across multiple executors, this approach achieves two key improvements. First, by monitoring and adjudicating executor behavior, it normalizes events from multiple heterogeneous executors and extracts behavioral features based on the ATT&CK framework and artificial intelligence technology to accurately identify unknown attacks based on unknown vulnerabilities and backdoors. Second, it integrates three cloud-native security detection capabilities: image security, runtime security, and microservice security. This provides comprehensive coverage of known attack scenarios such as viruses, Trojans, container escape, and abnormal service calls. Through the fusion and decision-making of multi-dimensional detection results, it significantly improves the accuracy and comprehensiveness of attack detection.

[0063] The threat response module can be designed to include a negative feedback control threat response unit and a cloud-native threat response unit, wherein...

[0064] The negative feedback control threat response unit responds to intrinsic security threats by processing abnormal request service executors.

[0065] The cloud-native threat response unit responds to cloud-native security threats through behavior alerts, behavior auditing, and blocking.

[0066] The negative feedback control threat response unit consists of algorithm adjudication, execution entity scheduling, and configuration management submodules, primarily responsible for handling security threats detected by intrinsic security measures. The configuration management submodule can pre-configure a mimicry adjudication algorithm. When the negative feedback control system receives information that an execution entity has been subjected to a cyberattack, it runs the control algorithm to determine the appropriate action. Then, it calls the execution entity scheduling module to perform operations such as bringing the attacked execution entity online, taking it offline, cleaning it up, and resetting it.

[0067] The Cloud-Native Security Threat Response Unit is primarily responsible for responding to attack threats detected by cloud-native security measures. Specific response measures include two main categories: behavioral alerts and behavioral auditing / blocking. The behavioral alerting function reports suspected attack behaviors and metadata, allowing security operations personnel to further determine the behavior and perform automated, comprehensive attack attribution analysis. Behavioral auditing / blocking isolates containers exhibiting suspected attack behaviors and collects their behavior data. This ensures that attacks within these containers cannot spread laterally across the cluster and also allows for further observation of the attacker's methods and actions.

[0068] Differentiated response chains are set up for different types of security threats: For core attack events where the execution unit is compromised as identified by intrinsic security measures, the threat response submodule is controlled by negative feedback to perform dynamic scheduling operations such as bringing the execution unit online, offline, cleaning, and resetting based on a preset adjudication algorithm, thus completing a mimicry defense closed loop; For events such as image risks, container anomalies, and microservice attacks identified by cloud-native security measures, the cloud-native security threat response submodule enables precise handling such as automated attack tracing, behavior alerts, security audits, and container isolation, avoiding business interruption caused by over-handling and preventing attack spread caused by insufficient handling.

[0069] Furthermore, based on the above system, embodiments of the present invention also provide an OpenStack block storage implementation method based on non-intrusive mimicry defense, comprising:

[0070] Receive user requests and forward them to one of the request service execution entities according to the preset scheduling mode;

[0071] The request service executor verifies the volume information in the user request, and generates a volume operation request based on the volume information if the verification passes.

[0072] Select the storage node for creating the volume based on the volume operation request information;

[0073] Perform volume operations on the storage node;

[0074] In the process of verifying volume information and generating volume operation requests, the system monitors the running status of the request service execution body in real time, judges network anomalies based on sensitive events, and handles and responds according to the judgment results.

[0075] In the real-time perception of the running status of the request service executor, non-sensitive system events during the running of the request service executor can be filtered according to pre-configured event filtering rules, and sensitive system events can be captured. The event filtering rules are configured at the full mount point in kernel mode and user mode based on eBPF technology.

[0076] like Figure 2 As shown, a user sends a request to the block storage service in OpenStack, such as creating a volume, updating a volume, or creating a snapshot. The request first passes through the user-side proxy adjudication module, which sends the request to one of the Cinder-API executors according to a pre-set scheduling mode, such as round-robin or least connections.

[0077] Specifically, when using polling to send requests to executors, the first received request is sent to the first executor; the second received request is sent to the second executor, and so on.

[0078] After receiving the request, the cinder-api executor performs business processing. Once the processing is complete, it sends the request to services such as cinder-sheduler and cinder-volume for further business processing.

[0079] The runtime status awareness module and the Cinder-API executor run on the same physical server. During business processing, the Cinder-API typically generates a large number of system events. Similarly, network attacks can trigger sensitive system events. The runtime status awareness module supports scalable memory and event filtering via API configuration, enabling it to quickly capture a large number of system events and filter out non-sensitive, normal events. Sensitive system events are then analyzed and processed before being sent to the threat analysis module.

[0080] The image security submodule, runtime security submodule, microservice security submodule, and execution behavior monitoring and adjudication submodule in the threat analysis module will detect threat events from different dimensions based on the data perceived by eBPF technology.

[0081] When a Cinder-API executor is subjected to a network attack, the executor behavior monitoring and adjudication submodule can detect that the executor has been attacked by abstracting the events of multiple executors into behavioral characteristics and performing monitoring and adjudication. The events of the multiple executors are sensitive low-level system events observed by eBPF, such as file behaviors, like a sensitive file being opened or modified.

[0082] When an image contains a virus, the image security submodule can detect that the image carries a virus based on the malicious image judgment algorithm that runs in the sandbox.

[0083] When the container containing a certain executor is subjected to a network attack, the runtime security submodule uses an intelligent algorithm-based container abnormal behavior detection algorithm to detect that the container containing the executor has been subjected to a network attack.

[0084] When the Cinder-api microservice is subjected to a network attack, the microservice security submodule uses a call association tree-based microservice anomaly detection algorithm to detect that the Cinder-api microservice has been attacked. The threat analysis module then sends the network attack information to the threat response module for appropriate handling.

[0085] The threat response module's negative feedback control threat response submodule and cloud-native security threat response submodule respond to different types of network attacks. When information about a network attack on a Cinder-API executor is received, the negative feedback control threat response submodule processes the threat information according to a preset control algorithm and determines the necessary measures. Then, it calls the executor scheduling module to perform operations such as bringing the attacked executor online, taking it offline, cleaning it up, and resetting it.

[0086] When information is received that an image contains a virus, a container containing a certain executable has been attacked, or the Cinder-API microservice has been attacked, the cloud-native security threat response submodule responds promptly. First, the behavior alerting module performs automated comprehensive attack tracing analysis, then integrates the network attack information and issues alerts. Security operations personnel receive the alerts and make judgments and take further action. Simultaneously, the behavior auditing and blocking module securely isolates the attacked container, preventing the attack from moving laterally across the cluster and avoiding the expansion of the attack scope. Security operations personnel can also track the attacker's next moves and actions in real time, facilitating subsequent defensive measures.

[0087] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0088] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0089] The units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations are not considered to be beyond the scope of this invention.

[0090] Those skilled in the art will understand that all or part of the steps in the above methods can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. Optionally, all or part of the steps in the above embodiments can also be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiments can be implemented in hardware or as a software functional module. This invention is not limited to any particular combination of hardware and software.

[0091] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A block storage implementation system for OpenStack based on non-intrusive mimicry defense, implemented on the OpenStack platform based on mimicry defense, characterized in that, The OpenStack platform includes: a user-side proxy adjudication module, a Cinder request service execution module, a Cinder scheduling service component, a Cinder execution service component, a threat analysis module, and a threat response module. The Cinder request service execution module comprises: heterogeneous request service execution units formed by replicating the Cinder request service component and deploying it on heterogeneous physical servers; and a runtime status awareness module deployed on physical servers using eBPF technology to monitor the real-time running status of the corresponding request service execution units on the physical servers. There are N heterogeneous request service execution units, where N≥3. The user-side proxy adjudication module is used to receive user requests and forward them to one of the request service execution bodies according to a preset scheduling mode. The request service executor is used to receive user requests and verify the volume information in the user requests. If the verification passes, it generates a volume operation request based on the volume information and sends it to the Cinder scheduling service component. The Cinder scheduling service component is used to select the storage node for creating the volume based on the volume operation request information. The Cinder execution service component is used to perform volume operations on storage nodes; The threat analysis module is used to receive the request service execution status information collected by each operation status awareness module and judge network anomalies based on sensitive events; The threat response module is used to handle and respond to network anomaly assessments.

2. The OpenStack block storage implementation system based on non-intrusive mimicry defense according to claim 1, characterized in that, Heterogeneous physical servers are physical servers with different CPU architectures and / or operating systems.

3. The OpenStack block storage implementation system based on non-intrusive mimicry defense according to claim 1, characterized in that, The operational status awareness module includes: an event probe unit, an event communication unit, and a configuration management unit, wherein... The event probe unit is based on eBPF technology and sets the mount driver and mount function on the corresponding mount points in user mode and kernel mode, so as to perceive the state of the mount point by calling the API interface of the mount driver and mount function. The event communication unit reports the perception status data of the corresponding event type to the threat analysis module according to the threat analysis requirements; The configuration management unit manages the configuration of the event probe unit and the event communication unit according to the threat analysis requirements.

4. The OpenStack block storage implementation system based on non-intrusive mimicry defense according to claim 1, characterized in that, The threat analysis module includes: an intrinsic security analysis unit, a cloud-native security analysis unit, and a decision-making unit, wherein... The intrinsic security analysis unit extracts the behavioral characteristics of the executor based on the executor's operating status and uses intrinsic security analysis methods, and monitors and adjudicates the behavioral characteristics. The intrinsic security analysis methods are ATT&CK threat analysis and detection methods or artificial intelligence threat analysis and detection methods. The cloud-native security analysis unit detects the security of the entire cloud-native process based on the execution status and through image security analysis, runtime event security analysis, and microservice security analysis. Specifically, image security analysis determines whether the image has abnormal behavior by driving the image to run in a sandbox, runtime event security analysis detects abnormal behavior of the runtime events of the host machine and containers, and microservice security analysis detects abnormal behavior of microservices by establishing a process call association tree. The decision-making unit integrates the behavioral feature monitoring and adjudication results, the mirror abnormal behavior judgment results, the runtime event abnormal behavior detection results, and the microservice abnormal behavior detection results to determine network anomalies.

5. The OpenStack block storage implementation system based on non-intrusive mimicry defense according to claim 1, characterized in that, The threat response module includes a negative feedback control threat response unit and a cloud-native threat response unit, wherein... The negative feedback control threat response unit responds to intrinsic security threats by processing abnormal request service executors. The cloud-native threat response unit responds to cloud-native security threats through behavior alerts, behavior auditing, and blocking.

6. A method for implementing OpenStack block storage based on non-intrusive mimicry defense, characterized in that, Based on the method described in claim 1, it includes: Receive user requests and forward them to one of the request service execution entities according to the preset scheduling mode; The request service executor verifies the volume information in the user request, and generates a volume operation request based on the volume information if the verification passes. Select the storage node for creating the volume based on the volume operation request information; Perform volume operations on the storage node; In the process of verifying volume information and generating volume operation requests, the system monitors the running status of the request service execution body in real time, judges network anomalies based on sensitive events, and handles and responds according to the judgment results.

7. The method for implementing OpenStack block storage based on non-intrusive mimicry defense according to claim 6, characterized in that, According to the preset scheduling mode, the user request is forwarded to one of the request service execution bodies, including: User requests are forwarded to one of the request service execution entities through a polling mechanism or the least number of connections principle.

8. The method for implementing OpenStack block storage based on non-intrusive mimicry defense according to claim 6, characterized in that, Real-time monitoring of the running status of the request service execution body, including: Non-sensitive system events during the execution of the request service execution body are filtered according to pre-configured event filtering rules, and sensitive system events are captured. The event filtering rules are configured at the full mount point in kernel mode and user mode based on eBPF technology.

9. An electronic device, characterized in that, include: At least one processor, and a memory coupled to said at least one processor; The memory stores a computer program that can be executed by the at least one processor to implement the method 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 that, when executed, enables the implementation of the method as described in any one of claims 1 to 7.

Images