Sis interface machine multi-module isolated safe sandbox operation system and method
By constructing a multi-module isolated security sandbox operating system, the problems of existing SIS interface machines due to architectural coupling, lack of module-level protection and self-healing capabilities are solved. This achieves isolation between modules and rapid fault recovery, ensuring the stability and security of industrial control systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUANENG POWER INT CO LTD RIZHAO POWER PLANT
- Filing Date
- 2026-02-28
- Publication Date
- 2026-06-05
AI Technical Summary
Existing SIS interface machines suffer from coupled architecture, lack of module-level protection and self-healing capabilities, which makes it easy for a single module failure to cause the entire system to be interrupted. There is also a risk of module tampering, making it difficult to ensure the long-term stable and continuous operation of industrial control systems.
A multi-module isolated security sandbox operating system is constructed, including a module scheduling manager, module communication agent, trusted measurement unit, anomaly detection and self-healing unit, and policy control center. Through independent security sandboxes, hash verification, and anomaly detection and self-healing mechanisms, isolation between modules and rapid fault recovery are achieved.
It achieves physical isolation between modules, prevents tampering, quickly identifies and recovers from module faults, and ensures the long-term stable and continuous operation of the industrial control system.
Smart Images
Figure CN122151746A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of industrial control system operation safety technology, and in particular to a multi-module isolated safety sandbox operation system and method for SIS interface machines. Background Technology
[0002] With the rapid iteration and upgrading of industrial automation and intelligent manufacturing industries, the Linux system, with its open-source and stable characteristics, has been widely and deeply applied in the field of industrial control. As the core hub for human-equipment interaction in industrial control systems, the SIS interface machine undertakes multiple key tasks, including data acquisition, communication forwarding, equipment status monitoring, system log recording, and security policy execution. To balance system operating efficiency and real-time data interaction, existing SIS interface machines generally adopt a multi-module parallel operation architecture, with each functional module processing various business instructions through multi-threaded or multi-process collaborative modes.
[0003] Because existing SIS interface machines employ a multi-module coupled parallel operation architecture and lack module-level isolation protection, trusted verification mechanisms, and refined self-healing systems, relying solely on program-level system protection mechanisms for overall monitoring, they suffer from technical problems such as inability to achieve module-level isolation protection, trusted verification, and fault self-healing. A single module failure can easily trigger a system-wide outage, and modules are susceptible to tampering, making it difficult to ensure the long-term stable and continuous operation of industrial control systems. Specifically, there are no independent operating boundaries between modules; a single module crash, deadlock, or abnormal exit directly terminates the entire SIS interface machine process, potentially leading to resource contention, memory leaks, and unauthorized access. The lack of file integrity verification during module loading creates vulnerabilities for malicious tampering or replacement. Traditional protection mechanisms like systemd and watchdog can only achieve program-level status monitoring and cannot perform module-level fault identification and self-healing. In long-term industrial scenarios, the difficulty in quickly recovering from module failures undermines the stability and security of production processes.
[0004] To address the technical problem that existing SIS interface machines, due to their coupled architecture and lack of module-level protection and self-healing capabilities, cannot guarantee the long-term stable and continuous operation of industrial control systems, this application proposes a multi-module isolated security sandbox operation system and method for SIS interface machines. Summary of the Invention
[0005] To address the technical problem that existing SIS interface machines, due to their coupled architecture and lack of module-level protection and self-healing capabilities, cannot guarantee the long-term stable and continuous operation of industrial control systems, this application provides a multi-module isolated security sandbox operation system for SIS interface machines, including a module scheduling manager unit, a module communication agent unit, a trust measurement unit, an anomaly detection and self-healing unit, and a strategy control center unit, with each unit interconnected.
[0006] The module scheduling manager unit is used to read the system configuration file, parse the module list, dependencies, and running parameters, create an isolated security sandbox for each module to achieve resource and permission isolation between modules, and schedule the startup, registration, running status detection, and anomaly recovery of each module; the module communication proxy unit is used to realize secure communication and data interaction between security sandboxes; the trust measurement unit is used to complete the trust verification of module files before each module is loaded to prevent modules from being tampered with or replaced; the anomaly detection and self-healing unit is used to detect the module running status, heartbeat information, and resource usage status, and send sandbox destruction and restart commands to the module scheduling manager unit when a module crashes, becomes unresponsive for a long time, or has abnormal resource usage; the policy control center unit is used to configure the resource limits, permission boundaries, and system call whitelists of each module to limit the safe operating scope of each module.
[0007] The SIS interface machine multi-module isolated security sandbox operation system provided in this application is fundamentally based on building a multi-unit collaborative SIS interface machine module security operation system. This solution uses an independent security sandbox as the basic operating environment. The core scheduling component parses the system configuration, clarifies the module list, dependencies, and operating parameters, and then builds a dedicated isolated space for each module. This achieves independent allocation of file systems, network namespaces, user permissions, and resource quotas, physically preventing mutual interference between modules. Simultaneously, a dedicated communication proxy component provides a standardized data interaction channel for cross-sandbox modules, ensuring secure and standardized communication during module collaboration. During module access, a trusted verification component verifies the integrity and authenticity of module files, preventing tampered or replaced modules from entering the operating environment. During operation, an anomaly monitoring and self-healing component continuously tracks the module's operating status, heartbeat signals, and resource usage, accurately identifying faults and triggering a closed-loop process of sandbox destruction and module restart. Furthermore, a policy control component constrains module behavior throughout the process by pre-setting resource limits, permission boundaries, and system call whitelists, while also coordinating log collection and auditing to ensure traceability and controllability of the operation process.
[0008] First, an independent security sandbox is constructed, allowing each functional module to run independently in a dedicated isolated environment. This completely eliminates mutual interference between modules, confining single-module crashes and deadlocks to their own scope and preventing them from affecting the entire system. This addresses the operational risks caused by architectural coupling at their root. Second, hash verification prevents modules from being tampered with or replaced. Finally, a linkage mechanism between anomaly detection and scheduling management enables rapid identification and automatic restart of module faults, achieving local self-healing without manual intervention. This overcomes the shortcomings of traditional program-level protection mechanisms in achieving module-level fault recovery. Through the above multi-dimensional collaborative design, the technical solution of this application successfully solves the technical problem of difficulty in ensuring the long-term stable and continuous operation of industrial control systems due to architectural coupling and the lack of module-level protection and self-healing capabilities.
[0009] Optionally, the module scheduling manager unit creates an isolated security sandbox based on the Linux system's namespace, cgroup, chroot, or AppArmor mechanisms.
[0010] Optionally, the security sandbox has mutually isolated file systems, network namespaces and user permissions, and uses a cgroup mechanism to allocate fixed CPU and memory quotas to modules within each sandbox, so as to avoid a single module from excessively occupying system resources and affecting the normal operation of other modules and the overall system.
[0011] Optionally, after receiving the sandbox destruction and restart command sent by the anomaly detection and self-healing unit, the module scheduling manager unit immediately executes the destruction operation of the corresponding security sandbox, and then recreates the security sandbox and loads the target module.
[0012] Optionally, the module communication proxy unit adopts one or more of the following communication mechanisms: shared memory, message queue, or local socket, to achieve secure communication and data interaction between different security sandboxes and to unify message scheduling rules and data transmission formats.
[0013] Optionally, the trusted measurement unit is used to calculate the hash value of the module file using the SHA256 hash algorithm before each functional module is loaded, and compare the calculated hash value with the standard hash value in the signature file pre-stored during deployment; if the two are inconsistent, it is determined that the module file is at risk of being tampered with or replaced. At this time, the trusted measurement unit will prevent the module from being loaded into the corresponding security sandbox and generate a corresponding alarm log to record the abnormal information.
[0014] Optionally, the policy control center unit is used to uniformly collect and summarize the independent operation logs and event records of each module in the security sandbox, and to audit the operation logs and event records.
[0015] This application also provides a method for operating a multi-module isolated security sandbox on a SIS interface machine, which applies the above system and includes: S1: After the system starts, the module scheduling manager unit first reads the preset system configuration file, parses it to obtain the list of modules to be run, the dependencies between modules and the running parameters of each module; and creates an isolated security sandbox with an independent file system, network namespace and user permissions for each module to complete the sandbox environment setup. S2: For each module to be loaded, the trust measurement unit first executes the file trust verification process. After verification, it sends a verification result signal to the module scheduling manager unit. The module scheduling manager unit responds to the verification result signal. If the verification result signal is a verification pass signal, the module is loaded into the corresponding security sandbox and started according to the resolved dependency relationship. After starting, the module registration information is synchronized to the system monitoring table, and the module enters the module running stage. If the verification result signal is a verification failure signal, the module is refused to be loaded. S3: During module operation, modules in different security sandboxes interact with each other through the module communication proxy unit, using one or more of the following mechanisms: shared memory, message queue, or local socket, and following unified message scheduling rules and data transmission format to complete secure communication; at the same time, the policy control center unit manages the operation of each module in real time based on preset resource limits, permission boundaries, and system call whitelists. S4: The anomaly detection and self-healing unit monitors the running status, heartbeat information and resource usage status of each module in real time, and continuously judges whether there are any anomalies in the modules; if an anomaly is detected, it immediately sends a sandbox destruction and restart command containing the anomaly module identifier to the module scheduling manager unit; if no anomaly is detected, it maintains the current running status of each module and sandbox. S5: Throughout the entire operation, the policy control center unit continuously collects the independent operation logs and event records of each module in the security sandbox, performs unified aggregation and auditing, and realizes traceability of module operation behavior.
[0016] Optionally, step S2 specifically involves: the trusted measurement unit using the SHA256 hash algorithm to calculate the real-time hash value of the module file to be loaded, calling the signature file pre-stored during deployment, and extracting the standard hash value from it; comparing the real-time hash value with the standard hash value for consistency; if the two are inconsistent, it is determined that the module file has a risk of being tampered with or replaced, and the trusted measurement unit sends a verification failure signal to the module scheduling manager unit, while generating an alarm log to record the abnormal information; the module scheduling manager unit responds to the verification failure signal and refuses to load the module; if the two are consistent, it is determined that the module file is trusted, and the trusted measurement unit sends a verification pass signal to the module scheduling manager unit; when the module scheduling manager unit responds to the verification pass signal, it executes subsequent module loading and startup operations.
[0017] Optionally, step S4 specifically involves: when the anomaly detection and self-healing unit detects that a module has crashed, is unresponsive for a long time, or its resource usage exceeds the preset quota, it immediately sends a sandbox destruction and restart command containing the anomaly module identifier to the module scheduling manager unit; after receiving the sandbox destruction and restart command containing the anomaly module identifier, the module scheduling manager unit first locates the security sandbox corresponding to the anomaly module, performs the destruction operation, and then recreates the security sandbox for the anomaly module to achieve module-level local self-healing.
[0018] This application provides a multi-module isolated security sandbox operation system for SIS interface machines. The system comprises five interconnected units: a module scheduling manager, a module communication agent, a trust measurement unit, an anomaly detection and self-healing unit, and a policy control center. The module scheduling manager creates isolated security sandboxes for each module, scheduling module startup, registration, and anomaly recovery. The module communication agent enables secure communication and data interaction between sandboxes. The trust measurement unit performs file trust verification before module loading. Upon detecting a module anomaly, the anomaly detection and self-healing unit sends a sandbox destruction and restart command to the scheduling manager. The policy control center limits the safe operating range of modules. The system provided in this application solves the technical problem that existing SIS interface machines, due to their coupled architecture and lack of module-level protection and self-healing capabilities, cannot guarantee the long-term stable and continuous operation of industrial control systems. This application also provides a method for applying the above system. Attached Figure Description
[0019] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a schematic diagram of the operation method of the multi-module isolated safety sandbox for the SIS interface machine. Specific implementation methods The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with the present invention. They are merely examples of systems and methods consistent with some aspects of the invention as detailed in the claims.
[0021] To address the technical problem that existing SIS interface machines, due to their coupled architecture and lack of module-level protection and self-healing capabilities, cannot guarantee the long-term stable and continuous operation of industrial control systems, this application provides a multi-module isolated security sandbox operation system for SIS interface machines, including a module scheduling manager unit, a module communication agent unit, a trust measurement unit, an anomaly detection and self-healing unit, and a strategy control center unit, with each unit interconnected.
[0022] The module scheduling manager unit is used to read the system configuration file, parse the module list, dependencies, and running parameters, create an isolated security sandbox for each module to achieve resource and permission isolation between modules, and schedule the startup, registration, running status detection, and anomaly recovery of each module; the module communication proxy unit is used to realize secure communication and data interaction between security sandboxes; the trust measurement unit is used to complete the trust verification of module files before each module is loaded to prevent modules from being tampered with or replaced; the anomaly detection and self-healing unit is used to detect the module running status, heartbeat information, and resource usage status, and send sandbox destruction and restart commands to the module scheduling manager unit when a module crashes, becomes unresponsive for a long time, or has abnormal resource usage; the policy control center unit is used to configure the resource limits, permission boundaries, and system call whitelists of each module to limit the safe operating scope of each module. The SIS interface machine multi-module isolated security sandbox operation system provided in this application is fundamentally based on building a multi-unit collaborative SIS interface machine module security operation system. This solution uses an independent security sandbox as the basic operating environment. The core scheduling component parses the system configuration, clarifies the module list, dependencies, and operating parameters, and then builds a dedicated isolated space for each module. This achieves independent allocation of file systems, network namespaces, user permissions, and resource quotas, physically preventing mutual interference between modules. Simultaneously, a dedicated communication proxy component provides a standardized data interaction channel for cross-sandbox modules, ensuring secure and standardized communication during module collaboration. During module access, a trusted verification component verifies the integrity and authenticity of module files, preventing tampered or replaced modules from entering the operating environment. During operation, an anomaly monitoring and self-healing component continuously tracks the module's operating status, heartbeat signals, and resource usage, accurately identifying faults and triggering a closed-loop process of sandbox destruction and module restart. Furthermore, a policy control component constrains module behavior throughout the process by pre-setting resource limits, permission boundaries, and system call whitelists, while also coordinating log collection and auditing to ensure traceability and controllability of the operation process.
[0023] First, an independent security sandbox is constructed, allowing each functional module to run independently in a dedicated isolated environment. This completely eliminates mutual interference between modules, confining single-module crashes and deadlocks to their own scope and preventing them from affecting the entire system. This addresses the operational risks caused by architectural coupling at their root. Second, hash verification prevents modules from being tampered with or replaced. Finally, a linkage mechanism between anomaly detection and scheduling management enables rapid identification and automatic restart of module faults, achieving local self-healing without manual intervention. This overcomes the shortcomings of traditional program-level protection mechanisms in achieving module-level fault recovery. Through the above multi-dimensional collaborative design, the technical solution of this application successfully solves the technical problem of ensuring the long-term stable and continuous operation of industrial control systems due to architectural coupling and the lack of module-level protection and self-healing capabilities.
[0024] In some embodiments, the module scheduling manager unit creates an isolated security sandbox based on the Linux system's namespace, cgroup, chroot, or AppArmor mechanisms.
[0025] In some embodiments, the security sandbox has mutually isolated file systems, network namespaces and user permissions, and uses a cgroup mechanism to allocate fixed CPU and memory quotas to modules within each sandbox, so as to avoid a single module from excessively occupying system resources and affecting the normal operation of other modules and the overall system.
[0026] Linux's namespace mechanism allows for the creation of independent network and user namespaces for each security sandbox, preventing modules within different sandboxes from directly accessing each other's namespace resources and achieving isolation between the network environment and user permissions. The cgroup mechanism provides fine-grained control over sandbox resources such as CPU usage and memory consumption, preventing excessive resource consumption by a single module. The chroot mechanism creates an independent root file system for each sandbox, restricting modules to accessing only files within that root file system and preventing unauthorized access to system-wide files. The AppArmor mechanism enforces access control policies, limiting module system call permissions and file access scope. The module scheduling manager unit can flexibly select a single mechanism or combine multiple mechanisms to create security sandboxes based on the security requirements and resource configuration of the actual application scenario.
[0027] The independent file system of the security sandbox ensures that each module can only operate on files within its own sandbox, preventing file read / write conflicts or accidental operations from affecting the file integrity of other modules. An independent network namespace gives each module its own dedicated network configuration and communication link, avoiding network port conflicts and unauthorized network access between modules. Independent user permissions limit the operational boundaries of modules, preventing them from exceeding their privileges to perform system operations. Furthermore, a cgroup mechanism allocates fixed CPU and memory quotas to each sandbox, clearly defining the resource usage limit for each module. When a module experiences an abnormal surge in resource usage, its resource usage will be restricted within the quota, preventing it from encroaching on the operating resources of other modules and the overall system, ensuring the effectiveness and adaptability of sandbox isolation.
[0028] Meanwhile, the technical solution of this application implements core functions based on the native Linux mechanism, without relying on virtualization technology or third-party container engines, has high deployment compatibility, can be adapted to domestic industrial system platforms, and meets the diverse deployment needs in industrial scenarios. In some embodiments, after receiving the sandbox destruction and restart command sent by the anomaly detection and self-healing unit, the module scheduling manager unit immediately executes the destruction operation of the corresponding security sandbox, and then recreates the security sandbox and loads the target module.
[0029] In some embodiments, the module communication proxy unit adopts one or more of the following communication mechanisms: shared memory, message queue, or local socket, to achieve secure communication and data interaction between different security sandboxes and to unify message scheduling rules and data transmission formats.
[0030] In some embodiments, the trust measurement unit is used to calculate the hash value of the module file using the SHA256 hash algorithm before each functional module is loaded, and compare the calculated hash value with the standard hash value in the signature file pre-stored during deployment; if the two are inconsistent, it is determined that the module file is at risk of being tampered with or replaced. At this time, the trust measurement unit will prevent the module from being loaded into the corresponding security sandbox and generate a corresponding alarm log to record the abnormal information.
[0031] The SHA256 hash algorithm boasts strong collision resistance and irreversibility, generating a unique hash value identifier for each module file. During module deployment, the system performs a hash calculation on the original module file and stores the resulting standard hash value in the signature file. Before loading the module, the trusted measurement unit reads the binary data of the module file to be loaded and calculates the real-time hash value using the same SHA256 hash algorithm. Subsequently, the trusted measurement unit decrypts the signature file and extracts the standard hash value, comparing the real-time hash value with the standard hash value bit by bit. If the comparison results are inconsistent, it indicates that the module file may have been maliciously tampered with or replaced. In this case, the trusted measurement unit immediately blocks the module from loading and generates an alarm log containing information such as the module identifier, verification time, and hash value difference, allowing maintenance personnel to promptly investigate security risks. If the comparison results are consistent, the module file is deemed trustworthy and allowed to be loaded into the corresponding security sandbox for operation.
[0032] In some embodiments, the policy control center unit is used to uniformly collect and summarize the independent operation logs and event records of each module in the security sandbox, and to audit the operation logs and event records.
[0033] This application also provides a method for operating a multi-module isolated security sandbox on a SIS interface machine. Applying the above system, such as... Figure 1 The diagram shows a flowchart of the operation method for a multi-module isolated security sandbox on a SIS interface machine. The method includes: S1: After the system starts, the module scheduling manager unit first reads the preset system configuration file, parses it to obtain the list of modules to be run, the dependencies between modules and the running parameters of each module; and creates an isolated security sandbox with an independent file system, network namespace and user permissions for each module to complete the sandbox environment setup. S2: For each module to be loaded, the trust measurement unit first executes the file trust verification process. After verification, it sends a verification result signal to the module scheduling manager unit. The module scheduling manager unit responds to the verification result signal. If the verification result signal is a verification pass signal, the module is loaded into the corresponding security sandbox and started according to the resolved dependency relationship. After starting, the module registration information is synchronized to the system monitoring table, and the module enters the module running stage. If the verification result signal is a verification failure signal, the module is refused to be loaded. S3: During module operation, modules in different security sandboxes interact with each other through the module communication proxy unit, using one or more of the following mechanisms: shared memory, message queue, or local socket, and following unified message scheduling rules and data transmission format to complete secure communication; at the same time, the policy control center unit manages the operation of each module in real time based on preset resource limits, permission boundaries, and system call whitelists. S4: The anomaly detection and self-healing unit monitors the running status, heartbeat information and resource usage status of each module in real time, and continuously judges whether there are any anomalies in the modules; if an anomaly is detected, it immediately sends a sandbox destruction and restart command containing the anomaly module identifier to the module scheduling manager unit; if no anomaly is detected, it maintains the current running status of each module and sandbox. S5: Throughout the entire operation, the policy control center unit continuously collects the independent operation logs and event records of each module in the security sandbox, performs unified aggregation and auditing, and realizes traceability of module operation behavior.
[0034] In some embodiments, step S2 specifically involves: the trust measurement unit calculating the real-time hash value of the module file to be loaded using the SHA256 hash algorithm, calling the signature file pre-stored during deployment, and extracting the standard hash value therein; comparing the real-time hash value with the standard hash value for consistency; if the two are inconsistent, it is determined that the module file has a risk of being tampered with or replaced, and the trust measurement unit sends a verification failure signal to the module scheduling manager unit, while generating an alarm log to record the abnormal information; the module scheduling manager unit responds to the verification failure signal and refuses to load the module; if the two are consistent, it is determined that the module file is trustworthy, and the trust measurement unit sends a verification pass signal to the module scheduling manager unit; when the module scheduling manager unit responds to the verification pass signal, it executes subsequent module loading and startup operations.
[0035] In some embodiments, step S4 specifically involves: when the anomaly detection and self-healing unit detects that a module has crashed, is unresponsive for a long time, or its resource usage exceeds a preset quota, it immediately sends a sandbox destruction and restart instruction containing the anomaly module identifier to the module scheduling manager unit; after receiving the sandbox destruction and restart instruction containing the anomaly module identifier, the module scheduling manager unit first locates the security sandbox corresponding to the anomaly module, performs the destruction operation, and then recreates the security sandbox for the anomaly module to achieve module-level local self-healing.
[0036] In some embodiments, firstly, after system startup, the module scheduling manager unit reads the preset system configuration file, parses it to obtain the list of modules to be run, the dependencies between modules, and the running parameters of each module, creates an isolated security sandbox with an independent file system, network namespace, and user permissions for each module, and allocates fixed CPU and memory quotas to each sandbox through the cgroup mechanism to complete the sandbox environment setup; secondly, for each module to be loaded, the trust measurement unit first uses the SHA256 hash algorithm to calculate the real-time hash value of the module file and compares it with the standard hash value in the signature file pre-stored during deployment. If the two are inconsistent, it is determined that the module file has a risk of tampering or replacement, an alarm log is generated, and the module is refused to be loaded; if the two are consistent, a verification pass signal is sent to the module scheduling manager unit, and the module scheduling manager unit loads the modules into the corresponding sandboxes for startup according to their dependencies, and synchronizes the registration information to the system monitoring table, entering the module running stage. Then, during module operation, modules in different sandboxes communicate securely through the module communication proxy unit, following unified message scheduling rules and data transmission formats. Simultaneously, the policy control center unit manages the operational behavior of each module in real time based on preset resource limits, permission boundaries, and system call whitelists. During this process, the anomaly detection and self-healing unit continuously monitors the operational status, heartbeat information, and resource usage status of each module. If a module crashes, becomes unresponsive for an extended period, or exceeds its preset resource usage quota, it immediately sends a sandbox destruction and restart command containing the anomaly module identifier to the module scheduling manager unit. Upon receiving the command, the module scheduling manager unit first locates the corresponding sandbox, performs the destruction operation, then recreates the sandbox and loads the target module to achieve local self-healing. If no anomaly is detected, the current operational status is maintained. Finally, throughout the entire operation, the policy control center unit continuously collects the independent operational logs and event records of each module within the sandbox, performs unified aggregation and auditing, and ensures the traceability of module operational behavior.
[0037] This application provides a multi-module isolated security sandbox operation system for SIS interface machines. The system comprises five interconnected units: a module scheduling manager, a module communication agent, a trust measurement unit, an anomaly detection and self-healing unit, and a policy control center. The module scheduling manager creates isolated security sandboxes for each module, scheduling module startup, registration, and anomaly recovery. The module communication agent enables secure communication and data exchange between sandboxes. The trust measurement unit performs file trust verification before module loading. Upon detecting a module anomaly, the anomaly detection and self-healing unit sends a sandbox destruction and restart command to the scheduling manager. The policy control center limits the safe operating range of modules. The system provided in this application solves the technical problem that existing SIS interface machines, due to their coupled architecture and lack of module-level protection and self-healing capabilities, cannot guarantee the long-term stable and continuous operation of industrial control systems. This application also provides a method for applying the above system. Similar parts between the embodiments provided in this invention can be referred to mutually. The specific embodiments provided above are merely examples under the overall concept of this invention and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other embodiments extended from the solution of this invention without creative effort are within the scope of protection of this invention.
Claims
1. A multi-module isolated safety sandbox operation system for SIS interface machines, characterized in that, It includes a module scheduling manager unit, a module communication agent unit, a trust measurement unit, an anomaly detection and self-healing unit, and a policy control center unit, and the units are interconnected. The module scheduling manager unit is used to read the system configuration file, parse the module list, dependencies and running parameters, create an isolated security sandbox for each module to achieve resource and permission isolation between modules, and schedule the startup, registration, running status detection and anomaly recovery of each module; The module communication proxy unit is used to realize secure communication and data interaction between security sandboxes; The trust measurement unit is used to complete the trust verification of the module files before each module is loaded, so as to prevent the modules from being tampered with or replaced. The anomaly detection and self-healing unit is used to detect the module's operating status, heartbeat information, and resource usage status. When the module crashes, becomes unresponsive for a long time, or has abnormal resource usage, it sends sandbox destruction and restart commands to the module scheduling manager unit. The policy control center unit is used to configure resource limits, permission boundaries, and system call whitelists for each module, thereby limiting the secure operating scope of each module.
2. The system according to claim 1, characterized in that, The module scheduling manager unit creates an isolated security sandbox based on the Linux system's namespace, cgroup, chroot, or AppArmor mechanisms.
3. The system according to claim 2, characterized in that, The security sandbox has isolated file systems, network namespaces and user permissions, and uses a cgroup mechanism to allocate fixed CPU and memory quotas to modules within each sandbox, preventing a single module from excessively consuming system resources and affecting the normal operation of other modules and the overall system.
4. The system according to claim 3, characterized in that, After receiving the sandbox destruction and restart command sent by the anomaly detection and self-healing unit, the module scheduling manager unit immediately executes the destruction operation of the corresponding security sandbox, and then recreates the security sandbox and loads the target module.
5. The system according to claim 4, characterized in that, The module communication proxy unit adopts one or more of the following communication mechanisms: shared memory, message queue, or local socket, to achieve secure communication and data interaction between different security sandboxes and to unify message scheduling rules and data transmission formats.
6. The system according to claim 5, characterized in that, The trusted measurement unit is used to calculate the hash value of the module file using the SHA256 hash algorithm before each functional module is loaded, and compare the calculated hash value with the standard hash value in the signature file pre-stored during deployment. If the two are inconsistent, it is determined that the module file is at risk of being tampered with or replaced. At this time, the trusted measurement unit will prevent the module from being loaded into the corresponding security sandbox and generate a corresponding alarm log to record the abnormal information.
7. The system according to claim 6, characterized in that, The policy control center unit is used to uniformly collect and summarize the independent operation logs and event records of each module in the security sandbox, and to audit the operation logs and event records.
8. A method for operating a multi-module isolated security sandbox for a SIS interface machine, using the system described in any one of claims 1-7, characterized in that, include: S1: After the system starts, the module scheduling manager unit first reads the preset system configuration file, parses it to obtain the list of modules to be run, the dependencies between modules and the running parameters of each module; and creates an isolated security sandbox with an independent file system, network namespace and user permissions for each module to complete the sandbox environment setup. S2: For each module to be loaded, the trust measurement unit first executes the file trust verification process. After verification, it sends a verification result signal to the module scheduling manager unit. The module scheduling manager unit responds to the verification result signal. If the verification result signal is a verification pass signal, the module is loaded into the corresponding security sandbox and started according to the resolved dependency relationship. After starting, the module registration information is synchronized to the system monitoring table, and the module enters the module running stage. If the verification result signal is a verification failure signal, the module is refused to be loaded. S3: During module operation, modules in different security sandboxes interact with each other through the module communication proxy unit, using one or more of the following mechanisms: shared memory, message queue, or local socket, and following unified message scheduling rules and data transmission format to complete secure communication; at the same time, the policy control center unit manages the operation of each module in real time based on preset resource limits, permission boundaries, and system call whitelists. S4: The anomaly detection and self-healing unit monitors the running status, heartbeat information and resource usage status of each module in real time, and continuously judges whether there are any anomalies in the module; If an anomaly is detected, immediately send a sandbox destruction and restart command containing the anomaly module identifier to the module scheduling manager unit; if no anomaly is detected, maintain the current running state of each module and sandbox. S5: Throughout the entire operation, the policy control center unit continuously collects the independent operation logs and event records of each module in the security sandbox, performs unified aggregation and auditing, and realizes traceability of module operation behavior.
9. The method according to claim 8, characterized in that, Step S2 is as follows: The Trust Measurement Unit uses the SHA256 hash algorithm to calculate the real-time hash value of the module file to be loaded, calls the signature file pre-stored during deployment, and extracts the standard hash value from it; the real-time hash value is compared with the standard hash value for consistency. If the two are inconsistent, it is determined that the module file has the risk of being tampered with or replaced. The Trust Measurement Unit sends a verification failure signal to the module scheduling manager unit and generates an alarm log to record the abnormal information. The module scheduling manager unit responds to the verification failure signal and refuses to load the module. If the two are consistent, the module file is determined to be trustworthy. The trustworthiness measurement unit sends a verification pass signal to the module scheduling manager unit. When the module scheduling manager unit responds to the verification pass signal, it performs subsequent module loading and startup operations.
10. The method according to claim 9, characterized in that, Step S4 is as follows: When the anomaly detection and self-healing unit detects that a module has crashed, is unresponsive for a long time, or has exceeded the preset quota for resource usage, it immediately sends a sandbox destruction and restart command containing the anomaly module identifier to the module scheduling manager unit. After receiving the sandbox destruction and restart command containing the anomaly module identifier, the module scheduling manager unit first locates the security sandbox corresponding to the anomaly module, performs the destruction operation, and then recreates the security sandbox for the anomaly module to achieve module-level local self-healing.