Equipment configuration compliance self-checking method and device, equipment and storage medium

Abstract

The invention relates to the technical field of system operation and maintenance, in particular to an equipment configuration compliance self-checking method and device, equipment and a storage medium. The method comprises the following steps of: performing parameter-level configuration anomaly detection on residual configuration items through an anomaly detection model, performing confidence analysis on global configuration compliance by fusing two types of anomaly detection results, finally generating a comprehensive analysis report about target equipment, and realizing closed-loop management of automatic repair-shadow verification-safe rollback by linking a repair system. According to the scheme, through rule and AI model cooperative detection and a closed-loop repair mechanism, the configuration check efficiency and accuracy are remarkably improved, the labor cost and the business risk are reduced, meanwhile, the dynamic adaptive capacity is achieved, and the method is suitable for automatic compliance management of large-scale IT infrastructures.

Description

Technical Field

[0001] This invention relates to the field of system operation and maintenance technology, and in particular to a method, apparatus, device, and storage medium for self-testing equipment configuration compliance. Background Technology

[0002] With the rapid evolution of modern information technology, the scale and complexity of IT infrastructure have increased significantly. The number of servers, network devices, and middleware in enterprises has increased dramatically, and configuration management models have gradually evolved from decentralized to centralized and automated. However, traditional operation and maintenance methods are struggling to cope with the demands of large-scale deployments, and problems such as configuration errors and policy conflicts occur frequently, directly impacting system stability, security, and operational efficiency.

[0003] Existing configuration management solutions primarily employ rule-based checks and monitoring. While these can identify some explicit issues, their detection capabilities are significantly insufficient when dealing with implicit dependencies between parameters, dynamic environment adaptations, and compatibility issues with heterogeneous devices. Furthermore, the introduction of AI-powered intelligent detection technology still faces challenges such as poor model generalization and high false alarm rates. Additionally, the black-box nature of these models means that remediation decisions lack reliable basis. Moreover, the remediation process after anomaly detection often relies on manual intervention, increasing the operational burden and reducing fault recovery efficiency.

[0004] Therefore, how to achieve compliance detection of configuration data in complex IT environments has become a technical problem that urgently needs to be solved in this industry. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for self-testing device configuration compliance, aiming to solve the technical problem of how to achieve compliance testing of configuration data in a complex IT environment in the prior art.

[0006] To achieve the above objectives, the present invention provides a self-test method for device configuration compliance, the method comprising the following steps: Construct a configuration map based on the operating parameters of the target equipment; Based on a preset compliance benchmark rule base, the configuration graph is subjected to compliance detection to obtain a set of rule-level abnormal configuration items; Based on the anomaly detection model, abnormal parameters are detected for configuration items that have not triggered rule-level anomalies, resulting in a set of parameter-level abnormal configuration items. A confidence analysis is performed on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items. Based on the confidence analysis results, the configuration compliance detection results of the target device are obtained.

[0007] Optionally, the configuration graph is subjected to compliance checks based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items, including: Based on the preset compliance benchmark rules for each configuration item in the configuration graph, match whether each current configuration item is defined in the compliance benchmark rule library; For configuration items that are not matched in the compliance benchmark rule base, the configuration items are classified into the set of illegally existing configuration items; For configuration items that exist in the compliance benchmark rule base but have no actual value configured, these configuration items are classified into the set of necessary missing configuration items; Conflict detection is performed between the set of illegally existing configuration items and the set of necessary missing configuration items to obtain a set of rule exception items after conflict correction, and the set of rule exception items after conflict correction is used as the set of rule-level exception configuration items.

[0008] Optionally, the step of performing compliance checks on the configuration graph based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items further includes: Based on the configuration map, a set of parameter key-value pairs for device configuration parameters is obtained; The set of parameter key-value pairs is matched one by one with the rule entries in the compliance benchmark rule base to identify abnormal key-value pairs that are not within the preset parameter range. The abnormal key-value pairs are subjected to compliance analysis to obtain rule-level abnormal metadata; The rule-level exception metadata is aggregated to generate the rule-level exception configuration item set.

[0009] Optionally, the step of performing compliance analysis on the abnormal key-value pairs to obtain rule-level abnormal metadata includes: Obtain the configuration item identifier and exception parameters of the abnormal key-value pair; Query the compliance benchmark rule base to obtain the standard value range of the abnormal parameter; Calculate the degree of deviation between the abnormal parameter and the standard value based on the standard range of the abnormal parameter; The configuration item identifier, violation parameter, deviation level, and violation type are marked as rule-level anomalous metadata.

[0010] Optionally, the step of performing abnormal parameter detection on configuration items that have not triggered rule-level anomalies according to the anomaly detection model to obtain a set of parameter-level abnormal configuration items, including: Based on the configuration items that did not trigger rule-level anomalies, a parameter-level detection candidate set is generated; The environmental features, topological association features, and historical baseline features of each configuration item in the parameter-level detection candidate set are extracted to obtain an anomaly feature vector set; The abnormal feature vector set is input into the abnormal detection model to obtain the abnormal probability value of each configuration item; Based on the abnormal probability value of the configuration item, a set of parameter-level abnormal configuration items is obtained.

[0011] Optionally, after obtaining the configuration compliance detection result of the target device based on the confidence analysis result, the method further includes: Based on the configuration compliance test results, determine the configuration items to be repaired and the repair priority of each configuration item to be repaired; Based on the configuration items to be repaired and the repair priority of each configuration item, a repair strategy decision tree is constructed; The branching conditions of the repair strategy decision tree are matched with the repair operations in the preset atomic operation library to obtain an initial set of repair operations; Based on the device type and version constraints of the target device, feasible operation items are selected from the initial repair operation set, and tiered repair operations are performed.

[0012] Optionally, after performing the graded repair operation, the method further includes: After the repair is complete, run both the old and new configurations in shadow mode to obtain system performance metrics data during the runtime of the two configurations. The system performance metrics data includes at least one of resource performance metrics, business performance metrics, and security performance metrics. Based on the system performance index data, the performance index differences after the configuration update are obtained; If the performance metric difference exceeds a preset threshold, a configuration version rollback operation is triggered and the self-check and repair failure information is uploaded to the administrator for manual review.

[0013] Furthermore, to achieve the above objectives, the present invention also proposes a device for self-testing equipment configuration compliance, the device comprising: The configuration map construction module is used to construct a configuration map based on the operating parameters of the target device. An anomaly detection module is configured to perform compliance detection on the configuration graph based on a preset compliance benchmark rule base, and obtain a set of rule-level abnormal configuration items. The configuration anomaly detection module is also used to perform anomaly parameter detection on configuration items that have not triggered rule-level anomalies according to the anomaly detection model, and obtain a set of parameter-level anomaly configuration items; The compliance judgment module is used to perform confidence analysis on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items, and obtain the configuration compliance detection result of the target device based on the confidence analysis result.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a device configuration compliance self-testing device, which includes: a memory, a processor, and a device configuration compliance self-testing program stored in the memory and executable on the processor. The device configuration compliance self-testing program is configured to implement the steps of the device configuration compliance self-testing method described above.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a device configuration compliance self-test program, wherein when the device configuration compliance self-test program is executed by a processor, it implements the steps of the device configuration compliance self-test method described above.

[0016] The proposed technical solutions in this application, including one or more, possess at least the following technical effects: In the detection phase, this solution employs a combination of a rule engine and an anomaly configuration detection model to achieve differentiated detection. Combined with a dynamic weight adjustment algorithm, it enables dual detection at both the rule and parameter levels. First, explicit violations are accurately captured using a compliance benchmark rule base. Then, hidden risks are uncovered using an anomaly model. False positives are eliminated through confidence arbitration, resulting in a low false alarm rate for configuration defects. Combined with a remediation decision tree, atomic operations are automatically matched and executed hierarchically. A shadow mode verifies changes under real load, and anomalies are immediately rolled back, ensuring that business continuity and security baselines are improved simultaneously. The entire process requires no manual intervention, reducing operational costs and enhancing the real-time performance, reliability, and scalability of compliance governance. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the first embodiment of the device configuration compliance self-test method of the present invention; Figure 2 A flowchart illustrating the second embodiment of the device configuration compliance self-test method of the present invention; Figure 3 A structural block diagram of the first embodiment of the compliance self-testing device configured for the device of the present invention; Figure 4 This is a schematic diagram of the structure of the device configuration compliance self-testing device for the hardware operating environment involved in the embodiments of the present invention.

[0020] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: A configuration graph is constructed based on the operating parameters of the target device; compliance checks are performed on the configuration graph based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items; abnormal parameter detection is performed on configuration items that have not triggered rule-level anomalies according to an anomaly detection model to obtain a set of parameter-level abnormal configuration items; confidence analysis is performed on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items, and the configuration compliance detection result of the target device is obtained based on the confidence analysis result.

[0024] Currently, existing configuration management solutions primarily employ rule-based checks and monitoring. While these can identify some explicit issues, their detection capabilities are significantly insufficient when dealing with implicit dependencies between parameters, dynamic environment adaptations, and compatibility issues with heterogeneous devices. Furthermore, the introduction of AI-powered intelligent detection technology still faces challenges such as poor model generalization and high false positive rates. Additionally, the black-box nature of these models means that remediation decisions lack reliable basis. Moreover, the remediation process after anomaly detection often relies on manual intervention, increasing the operational burden and reducing fault recovery efficiency. Therefore, how to achieve compliance detection of configuration data in complex IT environments is a pressing technical problem that needs to be solved.

[0025] This application achieves differentiated detection through the linkage of a rule engine and an anomaly configuration detection model in the detection phase. Combined with a dynamic weight adjustment algorithm, it enables dual detection at both the rule and parameter levels. First, explicit violations are accurately captured using a compliance benchmark rule base. Then, hidden risks are uncovered using an anomaly model. False positives are eliminated through confidence arbitration, resulting in a low false alarm rate for configuration defects. Combined with a remediation decision tree, atomic operations are automatically matched and executed hierarchically. A shadow mode verifies changes under real load, and anomalies are immediately rolled back, ensuring that business continuity and security baselines are improved simultaneously. The entire process requires no manual intervention, reducing operational costs and enhancing the real-time performance, reliability, and scalability of compliance governance.

[0026] It should be noted that the executing entity of this invention can be a device configuration compliance self-testing device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a thermal management device capable of performing the above-mentioned functions as a device configuration compliance self-testing device. This embodiment does not specifically limit this. The following uses a device configuration compliance self-testing device as the executing entity as an example to describe this embodiment and the following embodiments.

[0027] Based on this, this application provides a method for self-checking device configuration compliance, referring to... Figure 1 , Figure 1 A flowchart illustrating the first embodiment of the compliance self-testing method for configuring equipment in this application.

[0028] In this embodiment, the device configuration compliance self-test method includes steps S10 to S40: Step S10: Construct a configuration map based on the operating parameters of the target device.

[0029] It should be noted that the target device's operating parameters refer to the core data generated during device operation that reflects its configuration and status, such as network device port status, routing table, ACL rules, system service status, hardware resource utilization (CPU, memory, disk), software version, etc. The configuration graph is a unified data representation that abstracts these parameters and their interrelationships, such as dependencies, couplings, and causality, using a graph structure as a logical model. It serves as the foundational view for subsequent analysis.

[0030] As can be understood, the basic unit of a configuration graph is the configuration item. A configuration item refers to an independently configurable unit in the system, such as a server port, database parameters, firewall rules, or process configuration. Configuration item attributes are key-value pairs that describe the characteristics of the configuration item, generally divided into two categories: static attributes, which are the inherent configurations of the configuration item, such as IP address, port number, software version, and configuration file path; and dynamic attributes, which are the runtime status of the configuration item, such as CPU utilization, memory usage, number of connections, and response time. The configuration graph realizes the logical or physical relationships between configuration items through the topological structure between the units.

[0031] It should be understood that the configuration map is built dynamically and in real-time, automatically updating based on changes in the operating parameters of the target devices. This dynamic update mechanism ensures that the configuration map always reflects the actual operating status of the devices, thus providing accurate foundational data for subsequent anomaly detection and compliance analysis.

[0032] Step S20: Based on the preset compliance benchmark rule base, perform compliance detection on the configuration graph to obtain a set of rule-level abnormal configuration items.

[0033] It should be noted that the compliance benchmark rule base contains predefined, explicit compliance requirements, such as security baseline requirements, preferred practice standards, organizational internal norms, and structured rules derived from industry regulatory regulations.

[0034] Understandably, configuration errors can be broadly categorized into three types: invalid attribute values ​​for valid configuration items, meaning the configuration item itself is necessary, but the specific attribute value violates security policies or operational constraints; illegal activation of redundant configuration items, meaning enabling components (services / ports / modules) that have no business requirements in the system, creating additional vulnerability entry points; and failure to configure legitimate configuration items, meaning there are configuration items that should be configured but have not been configured or the configuration process has failed.

[0035] It should be understood that among the three types of configuration errors mentioned above, the illegal activation of redundant configuration items and the failure to configure valid configuration items are rule-level configuration errors, which cannot be eliminated by adjusting specific configuration parameters. However, the invalid attribute values ​​of valid configuration items are parameter-level configuration errors, which can be eliminated by adjusting only specific configuration parameters.

[0036] Step S30: Based on the anomaly detection model, perform anomaly parameter detection on configuration items that have not triggered rule-level anomalies to obtain a set of parameter-level anomaly configuration items.

[0037] It's important to clarify that anomaly detection models are models trained using machine learning or unsupervised learning algorithms (such as clustering, isolated forests, autoencoders, and time series analysis) to identify specific configuration parameters or combinations that deviate from their historical normal baseline or the normal pattern of a group. Parameter-level anomaly detection focuses on the reasonableness of individual parameter values ​​or abnormal fluctuations in implicit patterns among multiple parameters. The parameter-level anomalous configuration item set is the output of the model after processing, containing configuration items that, while not violating explicit rules, have behavioral patterns that the model determines significantly deviate from normal / expected behavior.

[0038] Understandably, anomaly detection models, through learning from extensive historical data, can establish a baseline for normal behavior and identify anomalies where configuration parameters deviate from this baseline. These anomalies may manifest as abnormal fluctuations in a single parameter value or abnormalities in the complex relationships between multiple parameters. The anomaly detection model can predict based on the original configuration parameters, identifying potential configuration parameters that could cause operational failures in advance. This detection method can uncover hidden problems that might not have been missed by rule-based checks, thus providing a deeper level of assurance for comprehensive compliance checks of device configurations.

[0039] It should be understood that, following the aforementioned rule-level anomaly detection, the detection of parameter-level anomaly configuration items in this step provides a basis for subsequent configuration item repair strategies, enabling the entire self-testing method to more comprehensively assess the configuration compliance of the device.

[0040] Step S40: Perform confidence analysis on the rule-level abnormal configuration item set and the parameter-level abnormal configuration item set, and obtain the configuration compliance detection result of the target device based on the confidence analysis result.

[0041] It's important to note that the core of this step lies in dynamically adjusting the credibility of the initial repair strategy. Since the initial analysis may be limited by data integrity or rule bias, the system needs to introduce a multi-layered confidence assessment mechanism: for each operation to be executed, its matching probability based on the target device's real-world environment is calculated, and low-confidence repair items are automatically eliminated. Simultaneously, operations that may introduce side effects (such as restarting critical services) undergo additional impact surface simulation prediction; if the expected failure rate exceeds a threshold, manual review is triggered.

[0042] Understandably, the system first verifies whether the rules apply to the current device type, and then checks whether the actual operating values ​​of the parameters are indeed in violation. For configuration items with ambiguous boundaries, it will refer to common settings of similar devices for auxiliary judgment. During execution, high-reliability results are automatically marked, and a secondary verification process is initiated for questionable items, such as manual review or simulation testing. The entire process records the judgment basis in real time, and finally generates a detection report with a confidence rating. Different confidence results correspond to different follow-up processing strategies.

[0043] It should be understood that a dynamic balance between detection accuracy and efficiency is needed during processing to avoid over-verification impacting performance. Special attention should be paid to configuration items that may trigger cascading effects; parameters involving system security or core services must be rigorously verified. Rules that repeatedly exhibit low confidence levels should trigger a knowledge base optimization process. Implementation must ensure that confidence assessment standards are transparent and traceable to avoid becoming black-box decisions. Simultaneously, a channel for manual intervention should be maintained to prevent business interruptions caused by automated misjudgments.

[0044] In a feasible embodiment, after obtaining the configuration compliance detection result of the target device based on the confidence analysis result, the method further includes: steps A10 to A40.

[0045] Step A10: Based on the configuration compliance test results, determine the configuration items to be repaired and the repair priority of each configuration item to be repaired.

[0046] It should be noted that the system categorizes detected issues based on their anomaly risk level and business impact. For example, critical parameter out-of-bounds errors are marked as urgent, while items that can be optimized later are classified as routine remediation tasks, ensuring that high-threat vulnerabilities are addressed first. Since the remediation priority setting is directly related to the urgency of security risks, this setting can prevent business losses due to delays in handling important vulnerabilities; it also facilitates resource allocation, allowing maintenance personnel to focus on the most urgent configuration error rectification.

[0047] Step A20: Construct a repair strategy decision tree based on the configuration items to be repaired and the repair priority of each configuration item to be repaired.

[0048] It should be noted that the core principle of decision tree construction lies in abstracting complex repair scenarios into a multi-layered logical judgment structure. Repair priority is used as the root node to drive branching, each child node corresponds to a specific configuration item type, and the terminal leaf nodes are bound to repair actions. High-priority items are the main branches and are expanded first. Multiple anomalies at the same level are assigned to sub-branches according to device modules. Configuration items with dependencies (such as those that require stopping the service before changing parameters) are serialized by enforcing the execution path serialization through the order of parent and child nodes.

[0049] Understandably, tree topology is essentially a pre-modeling of the repair process. Its decision path must encompass three logical layers: device status pre-inspection, atomic operation execution, and change result verification, ensuring that each operation can be traced back to the upstream node status. The generation of each node in the tree relies on a pre-built knowledge graph. For example, the network firewall policy modification node is automatically associated with two sub-verification nodes: port scanning and connection count detection. This structured decomposition avoids the blindness of manual decision-making.

[0050] It should be understood that in the specific implementation, the system automatically calls the configuration item feature extraction engine during execution: First, it extracts the risk label (such as data leakage index), impact scope, and repair time requirements of the item to be repaired, and generates a priority score through a weight matrix. Based on the score range, the configuration item is assigned to a preset level in the decision tree, which includes an emergency level, an important level, and a routine level. For each level, a second branch is formed according to the configuration item's functional attributes—for example, abnormal operating system kernel parameters are uniformly assigned to the kernel tuning branch, and abnormal database configurations are assigned to the storage engine branch.

[0051] Step A30: Match the branch conditions of the repair strategy decision tree with the repair operations in the preset atomic operation library to obtain an initial set of repair operations.

[0052] It's important to note that this process essentially maps abstract repair logic into concrete, executable commands. Based on the problem characteristics annotated by the tree nodes of the decision tree, the system retrieves standard operation templates from the atomic operation library that meet specific filtering criteria. For example, if the "insufficient password policy strength" node is detected, it will automatically match the standard script group for "modifying password complexity parameters." The operation library employs a three-level index structure to ensure rapid location of the corresponding repair solution.

[0053] Understandably, the matching process needs to consider the dynamic adaptation of operation parameters. The system will automatically fill variables based on the additional attributes of the current node. If the decision tree requires modification of the port but does not specify a specific value, the preset value will be obtained from the device security baseline and the command will be injected. In addition, attention should be paid to possible operation conflicts to ensure that the same resource configuration item is not bound to contradictory operation instructions.

[0054] It should be understood that the initial set of operations only completes the theoretical feasibility matching. Before actual execution, it needs to undergo environment adaptation verification, such as filtering instruction versions that are not supported by the filtering device. The operation order must strictly follow the decision tree node path, and cross-level calls are prohibited to prevent state disorder. All operations must retain the original decision tree node association log for version rollback.

[0055] Step A40: Based on the device type and version constraints of the target device, select feasible operation items from the initial repair operation set and perform hierarchical repair operations.

[0056] In one embodiment, after performing the graded repair operation, the method further includes: after the repair is completed, starting shadow mode to run both the old and new configurations, obtaining system performance index data during the dual-version configuration runtime, wherein the system performance index data includes at least one of resource performance indexes, business performance indexes, and security performance indexes; based on the system performance index data, obtaining the performance index difference after the configuration update; if the performance index difference exceeds a preset threshold, triggering a configuration version rollback operation and uploading self-check repair failure information to the administrator for manual review.

[0057] It's important to note that this mechanism runs both the old and new configurations in shadow mode to ensure the reliability of the remediation operation. Both configurations take effect simultaneously, but only the new configuration is output as business data, and the system continuously compares the performance metrics of the two. Resource, business, and security metrics are comprehensively evaluated to assess the impact of the update, avoiding misjudgments based on a single dimension. Automatic rollback occurs when the difference exceeds a threshold to prevent secondary issues caused by the remediation. This approach both verifies the remediation effect and ensures business stability.

[0058] Understandably, after the repair is complete, the system maintains the new configuration while simulating the old configuration environment in the background, and collects key metrics such as CPU, memory, and request success rate in real time. A time-window rolling algorithm is used to calculate the difference rate; when a key metric deviates beyond limits (e.g., latency increases by 20%), the system immediately rolls back automatically and records the repair failure log. The entire process requires no manual intervention, but any abnormal results must be reported to the operations and maintenance platform for secondary confirmation.

[0059] It should be understood that rollback operations must guarantee atomicity to prevent intermediate states from causing service anomalies. The evaluation period for security metrics should be longer than that for resource metrics (e.g., vulnerability scanning can take several hours), and conclusions should be delayed. Administrators should make comprehensive decisions based on discrepancies in data and business priorities during review.

[0060] This embodiment uses a configuration graph built based on real-time device operating parameters as the foundation for analysis. It employs a rule-based system to detect explicit violations at the rule level, and combines this with a machine learning model to detect implicit risks at the parameter level. A comprehensive evaluation based on confidence analysis then generates a compliance result. Subsequently, a remediation decision tree is constructed according to the risk level, and an executable solution is generated by matching it with an atomic operation library. Finally, the system is verified and remediated in a tiered manner using a shadow mode. The system achieves full automation from anomaly detection and prioritization to secure remediation, and features a dual-version operation and metric difference monitoring mechanism to ensure the reliability of the remediation operation.

[0061] In summary, this technical solution addresses the limitations of traditional manual inspections in terms of coverage and the difficulty in identifying hidden risks through dynamic configuration graph construction and a two-level anomaly detection mechanism. Automatic generation of remediation strategies based on decision trees and atomic operation matching reduces the cost of manual intervention, while priority ranking ensures that critical risks are addressed first. Combined with atomic-level node rollback operations, this forms a closed-loop, self-verifying configuration governance system that meets the stringent requirements of industry compliance audits while adapting to the rapid iteration needs of configuration items in complex IT environments, providing underlying assurance for business continuity.

[0062] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S20 in the device configuration compliance self-test method includes steps S201-204: Step S201: Based on the configuration map, obtain the set of parameter key-value pairs for the device configuration parameters.

[0063] It should be noted that during the rule-level anomaly detection process, the configuration graph, as a knowledge representation model, is parsed by the system to extract the attributes of all configuration items, such as host settings or service policies. Each attribute is converted into a standardized parameter key-value pair format to ensure that the configuration data can be efficiently processed by the downstream rule base.

[0064] Understandably, this parameter key-value pair extraction process aims to simplify complex topological relationships and provide a unified input for subsequent matching operations, such as obtaining database connection counts or port status from the graph as key-value data. During rule-level anomaly detection, the system comprehensively scans the configuration graph based on a pre-defined compliance benchmark rule base, focusing on identifying three typical configuration errors. First, for invalid attribute values ​​of valid configuration items, the system compares them to security thresholds or legal value ranges defined in the rule base; for example, it marks an anomaly when the number of database connections exceeds a preset limit. Simultaneously, the system checks for redundant configuration items, such as high-risk services or ports enabled without meeting business requirements—these errors directly violate prohibited security rules. Furthermore, the system verifies whether critical security policies are missing, such as unconfigured password complexity policies or the lack of firewall protection nodes for critical business links.

[0065] It should be understood that full coverage of the key-value pair set is the core guarantee of detection accuracy. Any missing configuration item or conversion error may result in key errors not being identified, affecting the integrity of the overall compliance analysis.

[0066] Step S202: Match the set of parameter key-value pairs with each rule entry in the compliance benchmark rule base to identify abnormal key-value pairs that are not within the preset parameter range.

[0067] It should be noted that the system compares each parameter key-value pair with the standard range in the compliance benchmark rule base, filtering out abnormal key-value pairs that do not meet the preset threshold. For example, when an SSH timeout parameter is detected to be below the minimum security requirement, the key-value pair will be marked as abnormal, and the specific violation value will be recorded.

[0068] Understandably, this system uses automated algorithms to compare each extracted key-value pair with a preset range in the rule base. For example, it checks whether the port number is within the safe allowable range; if it is outside, it is considered an anomaly, thus accurately locating invalid attribute values. This matching process uses the baseline values ​​of the rule base as a verification benchmark, ensuring that the detection focuses on violations at the parameter level, improving the efficiency of rule application, and preventing external interference factors from being included in the anomaly list.

[0069] Step S203: Perform compliance analysis on the abnormal key-value pairs to obtain rule-level abnormal metadata.

[0070] It should be noted that for abnormal key-value pairs, the system further analyzes the rule categories they violate, forming rule-level abnormal metadata. This process must clearly record the violation type, risk level, and associated security policies to facilitate the generation of actionable remediation suggestions later.

[0071] It should be understood that generating rule-level anomaly metadata involves more than just simple classification and labeling; it also requires correlation analysis based on the topological relationships of configuration items and their impact on business operations. For example, parameter anomalies on critical paths may have a higher priority for remediation than similar issues with ordinary configuration items.

[0072] Understandably, after completing the scan, the system generates a structured set of rule-level abnormal configuration items, where each abnormality clearly indicates the error type and the basis for the triggering rule. For invalid attribute value errors, the set records the configuration item name, the violating attribute, and the expected valid value; for redundant configuration items, it indicates the disabled rule that it violates; and in the case of missing security policies, it lists in detail the specific content that should be configured but is missing and its location in the topology. This structured output provides clear guidance for subsequent remediation work, enabling operations and maintenance personnel to take appropriate measures for different types of errors, such as adjusting parameters, disabling redundant functions, or supplementing missing policies, thereby achieving closed-loop management of security configurations.

[0073] In one embodiment, the step of performing compliance analysis on the abnormal key-value pairs to obtain rule-level abnormal metadata includes: obtaining the configuration item identifier and abnormal parameter of the abnormal key-value pairs; querying the compliance benchmark rule base to obtain the standard value range of the abnormal parameter; calculating the degree of deviation between the abnormal parameter and the standard value based on the standard value range of the abnormal parameter; and marking the configuration item identifier, violation parameter, degree of deviation, and violation type as rule-level abnormal metadata.

[0074] It's important to note that, using a predefined compliance benchmark rule base, the system can detect when a key-value pair deviates from a preset standard. Further analysis of the nature and extent of this deviation is needed, rather than simply labeling it as "abnormal." This mechanism aims to account for the complexity of real-world operational scenarios. For example, some parameters might be allowed to exceed limits temporarily in certain business environments, but long-term deviations could still pose security risks. Therefore, the generation of abnormal metadata not only focuses on transient violations but also requires a comprehensive evaluation combining industry standards and historical baselines. This refined design in principle effectively improves the scientific nature of compliance management and reduces misjudgments caused by rigid rules.

[0075] Understandably, the system extracts key parameters from the configuration graph and categorizes them according to preset identifiers (such as service names, port numbers, or security policy IDs). This ensures that each configuration item is accurately matched to the corresponding entry in the compliance rule base during the detection process. When the system detects a parameter exceeding the standard range, it immediately performs deeper compliance calculations, including querying the parameter's legal upper and lower limits, industry-recommended values, and specific internal policy constraints. Subsequently, the system calculates the relative deviation rate based on the difference between the current value and the standard range, such as exceeding the upper limit by 10% or falling below the minimum standard by 30%, and quantifies this as a comparable risk indicator. Finally, the system encapsulates the identifier of the violating parameter, the measured value, the degree of deviation, and the type of rule violated into machine-readable structured metadata for subsequent aggregation analysis and remediation decisions.

[0076] It should be understood that while the entire process emphasizes automation, a secondary manual review mechanism will still be introduced for monitoring key business parameters to avoid erroneous operations caused by algorithm misjudgments.

[0077] Step S204: Aggregate the rule-level exception metadata to generate the rule-level exception configuration item set.

[0078] Understandably, the aggregation process must pay special attention to the specificity of key configuration items to avoid over-aggregation that dilutes security risks. Anomalies in core business parameters should be reported independently and are not suitable for routine aggregation. Simultaneously, the aggregation algorithm needs to be dynamically adjustable, automatically optimizing the aggregation strategy based on changes in business scenarios. To ensure traceability, the mapping relationship between each aggregation result and the original anomaly must be fully recorded.

[0079] In a feasible embodiment, the step of performing compliance checks on the configuration graph based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items further includes: matching whether each current configuration item exists in the compliance benchmark rule base according to the preset compliance benchmark rules of each configuration item in the configuration graph; classifying configuration items not matched in the compliance benchmark rule base into a set of illegally existing configuration items; classifying configuration items existing in the compliance benchmark rule base but without configured actual values ​​into a set of necessary missing configuration items; performing conflict detection between the set of illegally existing configuration items and the set of necessary missing configuration items to obtain a set of rule-level abnormal configuration items after conflict correction, and using the set of rule-level abnormal configuration items after conflict correction as the set of rule-level abnormal configuration items.

[0080] In this embodiment, the device's configuration parameters are converted into a standardized set of key-value pairs and matched against a compliance benchmark rule base to identify three typical errors: invalid attribute values, redundant configuration items, and missing configurations. Then, each key-value pair is compared against preset rules to mark abnormal key-value pairs. Subsequently, rule-level abnormal metadata is generated by analyzing the degree of deviation of the abnormal parameters. During the metadata aggregation stage, scattered abnormal items are intelligently categorized according to anomaly type, risk level, and topological relationship to form a structured set of rule-level abnormal configuration items.

[0081] In summary, this embodiment significantly improves the efficiency of configuration compliance management through automated rule matching and intelligent aggregation, increasing the accuracy of anomaly detection and reducing false positives, while fully preserving the anomaly tracing path. Overall, this solution automates the entire chain from anomaly discovery to classification output, ensuring comprehensive detection while significantly reducing the complexity of remediation through structured output, making it particularly suitable for the efficient management of massive configuration items in cloud environments or distributed systems. Furthermore, the conflict correction mechanism effectively avoids misjudgments, and the dynamic adjustment feature adapts to the needs of different security level scenarios, forming a scalable configuration compliance management paradigm.

[0082] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the self-testing method for equipment configuration compliance of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0083] This application also provides a device for self-testing equipment configuration compliance; please refer to [reference needed]. Figure 3 The equipment configuration compliance self-testing device includes: Configuration map construction module 10 is used to construct a configuration map based on the operating parameters of the target device; The configuration anomaly detection module 20 is used to perform compliance detection on the configuration graph based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items. The configuration anomaly detection module 20 is also used to perform anomaly parameter detection on configuration items that have not triggered rule-level anomalies according to the anomaly detection model, and obtain a set of parameter-level anomaly configuration items; The compliance judgment module 30 is used to perform confidence analysis on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items, and obtain the configuration compliance detection result of the target device based on the confidence analysis result.

[0084] In one embodiment, the configuration anomaly detection module 20 is further configured to: match whether each current configuration item exists in the compliance benchmark rule library according to the preset compliance benchmark rules of each configuration item in the configuration graph; classify the configuration item that is not matched in the compliance benchmark rule library into the illegal existence configuration item set; classify the configuration item that exists in the compliance benchmark rule library but has no configured actual value into the necessary configuration missing item set; perform conflict detection based on the illegal existence configuration item set and the necessary configuration missing item set to obtain a conflict-corrected rule anomaly item set, and use the conflict-corrected rule anomaly item set as the rule-level anomaly configuration item set.

[0085] In one embodiment, the configuration anomaly detection module 20 is further configured to: obtain a set of parameter key-value pairs of device configuration parameters based on the configuration map; match the set of parameter key-value pairs with each rule entry in the compliance benchmark rule base to determine abnormal key-value pairs that are not within the preset parameter range; perform compliance analysis on the abnormal key-value pairs to obtain rule-level abnormal metadata; and aggregate the rule-level abnormal metadata to generate the set of rule-level abnormal configuration items.

[0086] In one embodiment, the configuration anomaly detection module 20 is further configured to obtain the configuration item identifier and anomaly parameter of the anomaly key-value pair; query the compliance benchmark rule base to obtain the standard value range of the anomaly parameter; calculate the degree of deviation between the anomaly parameter and the standard value based on the standard value range of the anomaly parameter; and mark the configuration item identifier, violation parameter, degree of deviation, and violation type as rule-level anomaly metadata.

[0087] In one embodiment, the configuration anomaly detection module 20 is further configured to generate a parameter-level detection candidate set based on the configuration items that have not triggered rule-level anomalies; extract environmental features, topological association features, and historical baseline features of each configuration item in the parameter-level detection candidate set to obtain an anomaly feature vector set; input the anomaly feature vector set into the anomaly detection model to obtain an anomaly probability value for each configuration item; and perform hierarchical judgment based on the anomaly probability value of the configuration item to obtain a parameter-level anomaly configuration item set.

[0088] In one embodiment, the compliance judgment module 30 is further configured to determine the configuration items to be repaired and the repair priority of each configuration item to be repaired based on the configuration compliance detection result; construct a repair strategy decision tree based on the configuration items to be repaired and the repair priority of each configuration item to be repaired; match the branch conditions of the repair strategy decision tree with the repair operations in the preset atomic operation library to obtain an initial repair operation set; and filter the feasible operation items in the initial repair operation set according to the device type and version constraints of the target device, and perform hierarchical repair operations.

[0089] In one embodiment, the compliance judgment module 30 is further configured to, after the repair is completed, start shadow mode to run both the old and new configurations, obtain system performance index data during the dual-version configuration runtime, the system performance index data including at least one of resource performance indexes, business performance indexes, and security performance indexes; based on the system performance index data, obtain the performance index difference after the configuration update; if the performance index difference exceeds a preset threshold, trigger a configuration version rollback operation and upload self-check repair failure information to the administrator for manual review.

[0090] This embodiment achieves differentiated detection through the linkage of a rule engine and an anomaly configuration detection model during the detection phase. Combined with a dynamic weight adjustment algorithm, it enables dual detection at both the rule and parameter levels. First, explicit violations are accurately captured using a compliance baseline rule base. Then, hidden risks are uncovered using an anomaly model. False positives are eliminated through confidence arbitration, resulting in a low false alarm rate for configuration defects. Combined with a remediation decision tree, atomic operations are automatically matched and executed hierarchically. Shadow mode verifies changes under real load, and anomalies are immediately rolled back, ensuring that business continuity and security baselines are improved simultaneously. The entire process requires no manual intervention, reducing operational costs and enhancing the real-time performance, reliability, and scalability of compliance governance.

[0091] The device configuration compliance self-testing device provided in this application, employing the device configuration compliance self-testing method described in the above embodiments, can solve the technical problem of how to achieve compliance detection of configuration data in a complex IT environment. Compared with the prior art, the beneficial effects of the device configuration compliance self-testing device provided in this application are the same as those of the device configuration compliance self-testing method described in the above embodiments, and other technical features in the device configuration compliance self-testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0092] This application provides a device configuration compliance self-testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the device configuration compliance self-testing method in the above embodiment 1.

[0093] Reference below Figure 4The diagram illustrates a structural schematic suitable for implementing a device configuration compliance self-testing device in the embodiments of this application. The device configuration compliance self-testing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The device configuration compliance self-test device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0094] like Figure 4 As shown, the device configuration compliance self-test device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the device configuration compliance self-test device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the device configuration compliance self-test device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a device configuration compliance self-test device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented alternatively.

[0095] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0096] The device configuration compliance self-testing device provided in this application, employing the device configuration compliance self-testing method described in the above embodiments, can solve the technical problem of how to achieve compliance detection of configuration data in a complex IT environment. Compared with the prior art, the beneficial effects of the device configuration compliance self-testing device provided in this application are the same as those of the device configuration compliance self-testing method provided in the above embodiments, and other technical features of this device configuration compliance self-testing device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0097] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0099] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the device configuration compliance self-test method described in the above embodiments.

[0100] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0101] The aforementioned computer-readable storage medium may be included in the device configuration compliance self-testing device; or it may exist independently and not be assembled into the device configuration compliance self-testing device.

[0102] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the device configuration compliance self-testing device, the device configuration compliance self-testing device performs the following: constructs a configuration graph based on the target device's operating parameters; performs compliance testing on the configuration graph based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items; performs abnormal parameter detection on configuration items that have not triggered rule-level anomalies based on an anomaly detection model to obtain a set of parameter-level abnormal configuration items; performs confidence analysis on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items, and obtains the configuration compliance test result of the target device based on the confidence analysis results.

[0103] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0105] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0106] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described device configuration compliance self-testing method, thereby solving the technical problem of how to implement compliance testing of configuration data in a complex IT environment. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the device configuration compliance self-testing method provided in the above embodiments, and will not be repeated here.

[0107] The computer program product provided in this application can solve the technical problem of self-testing device configuration compliance. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the device configuration compliance self-testing method provided in the above embodiments, and will not be repeated here.

[0108] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for self-inspecting equipment configuration compliance, characterized in that, The device configuration compliance self-check method includes: Construct a configuration map based on the operating parameters of the target equipment; Based on a preset compliance benchmark rule base, the configuration graph is subjected to compliance detection to obtain a set of rule-level abnormal configuration items; Based on the anomaly detection model, abnormal parameters are detected for configuration items that have not triggered rule-level anomalies, resulting in a set of parameter-level abnormal configuration items. A confidence analysis is performed on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items. Based on the confidence analysis results, the configuration compliance detection results of the target device are obtained.

2. The equipment configuration compliance self-inspection method according to claim 1, characterized in that, The configuration graph is subjected to compliance checks based on a preset compliance benchmark rule base to obtain a set of rule-level abnormal configuration items, including: Based on the preset compliance benchmark rules for each configuration item in the configuration graph, match whether each current configuration item is defined in the compliance benchmark rule library; For configuration items that are not matched in the compliance benchmark rule base, the configuration items are classified into the set of illegally existing configuration items; For configuration items that exist in the compliance benchmark rule base but have no actual value configured, these configuration items are classified into the set of necessary missing configuration items; Conflict detection is performed between the set of illegally existing configuration items and the set of necessary missing configuration items to obtain a set of rule exception items after conflict correction, and the set of rule exception items after conflict correction is used as the set of rule-level exception configuration items.

3. The equipment configuration compliance self-inspection method according to claim 1, characterized in that, The system, based on a preset compliance benchmark rule base, performs compliance checks on the configuration graph to obtain a set of rule-level abnormal configuration items, and also includes: Based on the configuration map, a set of parameter key-value pairs for device configuration parameters is obtained; The set of parameter key-value pairs is matched one by one with the rule entries in the compliance benchmark rule base to identify abnormal key-value pairs that are not within the preset parameter range. The abnormal key-value pairs are subjected to compliance analysis to obtain rule-level abnormal metadata; The rule-level exception metadata is aggregated to generate the rule-level exception configuration item set.

4. The equipment configuration compliance self-inspection method according to claim 3, characterized in that, The compliance analysis of the abnormal key-value pairs to obtain rule-level abnormal metadata includes: Obtain the configuration item identifier and exception parameters of the abnormal key-value pair; Query the compliance benchmark rule base to obtain the standard value range of the abnormal parameter; Calculate the degree of deviation between the abnormal parameter and the standard value based on the standard range of the abnormal parameter; The configuration item identifier, violation parameter, deviation level, and violation type are marked as rule-level anomalous metadata.

5. The equipment configuration compliance self-inspection method according to claim 1, characterized in that, The method involves using an anomaly detection model to perform anomaly parameter detection on configuration items that have not triggered rule-level anomalies, resulting in a set of parameter-level anomaly configuration items, including: Based on the configuration items that did not trigger rule-level anomalies, a parameter-level detection candidate set is generated; The environmental features, topological association features, and historical baseline features of each configuration item in the parameter-level detection candidate set are extracted to obtain an anomaly feature vector set; The abnormal feature vector set is input into the abnormal detection model to obtain the abnormal probability value of each configuration item; Based on the abnormal probability value of the configuration item, a set of parameter-level abnormal configuration items is obtained.

6. The equipment configuration compliance self-inspection method according to claim 1, characterized in that, After obtaining the configuration compliance detection result of the target device based on the confidence analysis result, the process further includes: Based on the configuration compliance test results, determine the configuration items to be repaired and the repair priority of each configuration item to be repaired; Based on the configuration items to be repaired and the repair priority of each configuration item, a repair strategy decision tree is constructed; The branching conditions of the repair strategy decision tree are matched with the repair operations in the preset atomic operation library to obtain an initial set of repair operations; Based on the device type and version constraints of the target device, feasible operation items are selected from the initial repair operation set, and tiered repair operations are performed.

7. The equipment configuration compliance self-inspection method according to claim 6, characterized in that, After performing the graded repair operation, the following is also included: After the repair is complete, run both the old and new configurations in shadow mode to obtain system performance metrics data during the runtime of the two configurations. The system performance metrics data includes at least one of resource performance metrics, business performance metrics, and security performance metrics. Based on the system performance index data, the performance index differences after the configuration update are obtained; If the performance metric difference exceeds a preset threshold, a configuration version rollback operation is triggered and the self-check and repair failure information is uploaded to the administrator for manual review.

8. A self-testing device for equipment configuration compliance, characterized in that, The equipment is equipped with a compliance self-testing device, including: The configuration map construction module is used to construct a configuration map based on the operating parameters of the target device. An anomaly detection module is configured to perform compliance detection on the configuration graph based on a preset compliance benchmark rule base, and obtain a set of rule-level abnormal configuration items. The configuration anomaly detection module is also used to perform anomaly parameter detection on configuration items that have not triggered rule-level anomalies according to the anomaly detection model, and obtain a set of parameter-level anomaly configuration items; The compliance judgment module is used to perform confidence analysis on the set of rule-level abnormal configuration items and the set of parameter-level abnormal configuration items, and obtain the configuration compliance detection result of the target device based on the confidence analysis result.

9. A device for self-testing equipment configuration compliance, characterized in that, The device configuration compliance self-testing device includes: a memory, a processor, and a device configuration compliance self-testing program stored on the memory and executable on the processor. The device configuration compliance self-testing program is configured to implement the steps of the device configuration compliance self-testing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a device configuration compliance self-test program, which, when executed by a processor, implements the steps of the device configuration compliance self-test method as described in any one of claims 1 to 7.

Images