Device configuration compliance self-checking method, apparatus, device, and storage medium

Abstract

The present application relates to the technical field of system operation and maintenance, and more particularly to a device configuration compliance self-checking method, device, equipment and storage medium, the present application constructs a configuration atlas containing a topological relationship, uses a rule engine to identify rule-level configuration abnormalities in configuration items, then detects parameter-level configuration abnormalities in the remaining configuration items through an abnormality detection model, then fuses the two types of abnormality detection results to analyze the confidence of global configuration compliance, finally generates a comprehensive analysis report about the target device, and links a repair system to realize closed-loop management of automatic repair-shadow verification-safety rollback. The scheme significantly improves the configuration checking efficiency and accuracy through the cooperative detection of rules and AI models and the closed-loop repair mechanism, reduces the labor cost and business risk, and at the same time has dynamic adaptability, and is suitable for the automatic compliance management of large-scale IT infrastructure.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system operation and maintenance, and particularly relates to a device configuration compliance self-checking method and device, equipment and a storage medium. BACKGROUND

[0002] With the rapid evolution of modern information technology, the scale and complexity of IT infrastructure have significantly increased. The number of servers, network devices and middleware of enterprises has increased dramatically, and the configuration management mode has gradually evolved from decentralization to centralization and automation. However, traditional operation and maintenance methods cannot meet the needs of large-scale deployment, and configuration errors and policy conflicts occur frequently, which directly affects the stability, security and efficiency of the system.

[0003] The existing configuration management scheme mainly uses rule checking and monitoring means, which can identify some explicit problems, but in the face of implicit dependencies between parameters, dynamic environment adaptation and heterogeneous device compatibility, the detection capability is obviously insufficient. At the same time, the introduction of AI intelligent detection technology still faces problems such as poor model generalization, high false alarm rate, and the black box nature of the model determines that the repair decision lacks reliable basis. In addition, the repair process after abnormality discovery often relies on manual intervention, which not only increases the operation and maintenance burden, but also reduces the fault recovery efficiency.

[0004] Therefore, how to realize the compliance detection of configuration data in a complex IT environment has become a technical problem that needs to be solved in the industry. SUMMARY

[0005] The main purpose of the present application is to provide a device configuration compliance self-checking method, device, equipment and storage medium, which aims to solve the technical problem of how to realize the compliance detection of configuration data in a complex IT environment in the prior art.

[0006] To achieve the above purpose, the present application provides a device configuration compliance self-checking method, which comprises the following steps:

[0007] According to the operating parameters of the target device, a configuration graph is constructed;

[0008] Based on a preset compliance benchmark rule library, the configuration graph is subjected to compliance detection to obtain a rule-level abnormal configuration item set;

[0009] According to an abnormality detection model, abnormal parameter detection is performed on the configuration items that do not trigger rule-level abnormalities to obtain a parameter-level abnormal configuration item set;

[0010] The rule-level abnormal configuration item set and the parameter-level abnormal configuration item set are subjected to confidence analysis, and according to the confidence analysis result, a configuration compliance detection result of the target device is obtained.

[0011] Optionally, the compliance detection on the configuration graph based on the preset compliance benchmark rule library obtains a rule-level abnormal configuration item set, including:

[0012] According to the preset compliance benchmark rule of each configuration item in the configuration graph, it is matched whether each current configuration item exists in the compliance benchmark rule library;

[0013] For the configuration item that is not matched in the compliance benchmark rule library, the configuration item is classified into a set of illegal existing configuration items;

[0014] For the configuration item existing in the compliance benchmark rule library but not configured with an actual value, the configuration item is classified into a set of necessary configuration missing items;

[0015] According to the conflict detection of the set of illegal existing configuration items and the set of necessary configuration missing items, a rule abnormal item set after conflict correction is obtained, and the rule abnormal item set after conflict correction is taken as the rule-level abnormal configuration item set.

[0016] Optionally, the compliance detection on the configuration graph based on the preset compliance benchmark rule library obtains a rule-level abnormal configuration item set, and further includes:

[0017] According to the configuration graph, a parameter key-value pair set of device configuration parameters is obtained;

[0018] The parameter key-value pair set and the rule entries in the compliance benchmark rule library are matched one by one to determine abnormal key-value pairs not in a preset parameter range;

[0019] The abnormal key-value pairs are analyzed for compliance to obtain rule-level abnormal metadata;

[0020] According to the rule-level abnormal metadata, the rule-level abnormal configuration item set is generated.

[0021] Optionally, the compliance analysis on the abnormal key-value pairs to obtain rule-level abnormal metadata includes:

[0022] Obtain the configuration item identifier and the abnormal parameter of the abnormal key-value pair;

[0023] Query the compliance benchmark rule library to obtain the standard value range of the abnormal parameter;

[0024] According to the standard value range of the abnormal parameter, the deviation degree of the abnormal parameter and the standard value is calculated;

[0025] The configuration item identifier, the illegal parameter, the deviation degree and the illegal type are marked as rule-level abnormal metadata.

[0026] Optionally, the abnormal parameter detection of the configuration item not triggering the rule-level abnormality is performed according to the abnormality detection model, and a parameter-level abnormal configuration item set is obtained, comprising:

[0027] The parameter-level detection candidate set is generated according to the configuration item not triggering the rule-level abnormality;

[0028] The environment features, topology correlation features and historical baseline features of each configuration item in the parameter-level detection candidate set are extracted to obtain an abnormal feature vector set;

[0029] The abnormal feature vector set is input into the abnormality detection model to obtain an abnormal probability value of each configuration item;

[0030] The parameter-level abnormal configuration item set is obtained according to the hierarchical judgment of the abnormal probability value of the configuration item.

[0031] Optionally, after the configuration compliance detection result of the target device is obtained according to the confidence analysis result, the method further comprises:

[0032] According to the configuration compliance detection result, the configuration items to be repaired and the repair priorities of each configuration item to be repaired are determined;

[0033] According to the configuration items to be repaired and the repair priorities of each configuration item to be repaired, a repair strategy decision tree is constructed;

[0034] The branch conditions of the repair strategy decision tree are matched with the repair operations in the preset atomic operation library to obtain an initial repair operation set;

[0035] According to the device type and version constraint conditions of the target device, the feasible operation items in the initial repair operation set are screened, and hierarchical repair operations are performed.

[0036] Optionally, after the hierarchical repair operations are performed, the method further comprises:

[0037] After the repair is completed, the new and old configuration dual versions are run in a shadow mode, system performance index data in a dual-version configuration runtime are obtained, and the system performance index data comprise at least one of resource class performance index, business class performance index and security class performance index:

[0038] According to the system performance index data, a performance index difference after the configuration is updated is obtained;

[0039] If the performance index difference exceeds a preset threshold, a configuration version rollback operation is triggered, and self-check repair failure information is uploaded to an administrator for manual review.

[0040] In addition, in order to achieve the above-mentioned purpose, the application further provides a device configuration compliance self-check device, which comprises:

[0041] The configuration graph construction module is configured to construct a configuration graph according to the operating parameters of the target device.

[0042] The configuration anomaly detection module is configured to perform compliance detection on the configuration graph based on a preset compliance benchmark rule library to obtain a rule-level abnormal configuration item set.

[0043] The configuration anomaly detection module is further configured to perform abnormal parameter detection on the configuration items that do not trigger rule-level anomalies according to an anomaly detection model to obtain a parameter-level abnormal configuration item set.

[0044] The compliance judgment module is configured to perform confidence analysis on the rule-level abnormal configuration item set and the parameter-level abnormal configuration item set, and obtain a configuration compliance detection result of the target device according to the confidence analysis result.

[0045] In addition, to achieve the above-mentioned purpose, the present application further provides a device configuration compliance self-checking device, which comprises a memory, a processor, and a device configuration compliance self-checking program stored in the memory and executable on the processor, and the device configuration compliance self-checking program is configured to implement the steps of the device configuration compliance self-checking method as described above.

[0046] In addition, to achieve the above-mentioned purpose, the present application further provides a storage medium having a device configuration compliance self-checking program stored thereon, and the device configuration compliance self-checking program implements the steps of the device configuration compliance self-checking method as described above when executed by a processor.

[0047] The one or more technical solutions provided in the present application have at least the following technical effects: in the detection link, the present application adopts the linkage of the rule engine and the abnormal configuration detection model to realize differentiated detection, and in combination with the dynamic weight adjustment algorithm, the present application can realize double detection at the rule level and the parameter level, first accurately captures explicit violations with the compliance benchmark rule library, then excavates implicit risks with the anomaly model, eliminates false positives through confidence arbitration, realizes low false positive rate of configuration defects, automatically matches atomic operations in combination with the repair decision tree and executes them in stages, verifies changes in the shadow mode under real load, rolls back abnormalities immediately, and ensures business continuity and synchronous improvement of security baseline. The whole process does not require manual intervention, reduces operation and maintenance costs, and enhances the real-time performance, reliability and scalability of compliance governance. BRIEF DESCRIPTION OF DRAWINGS

[0048] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application.

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, for those of ordinary skill in the art, the other drawings can also be obtained based on these drawings without any creative work.

[0050] Figure 1 The flowchart of the first embodiment of the compliance self-checking method for the device configuration of the present application is shown in the figure.

[0051] Figure 2 The flowchart of the second embodiment of the compliance self-checking method for the device configuration of the present application is shown in the figure.

[0052] Figure 3 The structural block diagram of the first embodiment of the compliance self-checking device for the device configuration of the present application is shown in the figure.

[0053] Figure 4 The structural diagram of the compliance self-checking device for the device configuration of the present application is shown in the figure.

[0054] The implementation of the object of the present application, the functional features and the advantages will be further described with reference to the accompanying drawings. DETAILED DESCRIPTION

[0055] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application, and are not used to limit the present application.

[0056] In order to better understand the technical solutions of the present application, the following will be described in detail with reference to the accompanying drawings and specific embodiments.

[0057] The main solution of the embodiments of the present application is: according to the running parameters of the target device, a configuration atlas is constructed; based on a preset compliance benchmark rule library, the configuration atlas is detected for compliance to obtain a rule-level abnormal configuration item set; according to an abnormal detection model, the configuration items that do not trigger rule-level abnormality are detected for abnormal parameters to obtain a parameter-level abnormal configuration item set; the rule-level abnormal configuration item set and the parameter-level abnormal configuration item set are analyzed for confidence, and according to the confidence analysis result, a configuration compliance detection result of the target device is obtained.

[0058] Currently, the existing configuration management scheme mainly adopts rule checking and monitoring means, although it can identify some explicit problems, but in the face of implicit dependence between parameters, dynamic environment adaptation and heterogeneous device compatibility, the detection ability is obviously insufficient. At the same time, the introduction of AI intelligent detection technology still faces the problems of poor model generalization, high false alarm rate, in addition, the black box nature of the model determines that the repair decision lacks reliable basis. In addition, the repair process after the abnormality is found often relies on manual intervention, which not only increases the operation and maintenance burden, but also reduces the fault recovery efficiency. Therefore, how to realize the compliance detection of configuration data in a complex IT environment is a technical problem that needs to be solved at present.

[0059] The application realizes differentiated detection by using the linkage of rule engine and abnormal configuration detection model in the detection link, realizes double detection of rule level and parameter level by combining dynamic weight adjustment algorithm, accurately captures explicit violations with compliance benchmark rule library first, then excavates implicit risks with abnormal model, eliminates false positives through confidence arbitration, realizes low false alarm rate of configuration defects, combines repair decision tree to automatically match atomic operations and executes in stages, shadow mode verifies changes under real load, abnormality is rolled back immediately, ensures business continuity and synchronous improvement of security baseline. The whole process does not need manual intervention, reduces operation and maintenance cost, enhances the real-time performance, reliability and scalability of compliance governance.

[0060] It should be noted that the execution subject of the application can be a device configuration compliance self-checking device, or a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or a device configuration compliance self-checking device capable of realizing the above functions, etc. The present embodiment does not make specific limitation hereon. The following takes the device configuration compliance self-checking device as the execution subject as an example to illustrate the present embodiment and the following embodiments.

[0061] Based on this, the application embodiment provides a device configuration compliance self-checking method, referring to Figure 1 , Figure 1 The flowchart of the first embodiment of the device configuration compliance self-checking method of the application is shown in the figure.

[0062] In the present embodiment, the device configuration compliance self-checking method comprises steps S10-S40:

[0063] Step S10: Constructing a configuration map according to the operating parameters of the target device.

[0064] It should be noted that the operating parameters of the target device refer to core data reflecting the configuration and state of the device when it is running, such as the port state, routing table, ACL rule, system service state, hardware resource usage (CPU, memory, disk), software version, etc. of the network device. The configuration graph is a unified data representation of these parameters and their mutual relationships, such as dependency, coupling, causality, which is abstracted based on a graph structure as a logical model, and is a basic view for subsequent analysis.

[0065] It can be understood that the basic unit of the configuration graph is the configuration item, which refers to a unit that can be independently configured in the system, such as a server port, a database parameter, a firewall rule, and a process configuration. The configuration item attribute is a key-value pair that describes the characteristics of the configuration item, which is generally divided into two categories: static attributes, that is, inherent configurations of the configuration item, such as IP address, port number, software version, configuration file path, etc.; dynamic attributes, that is, runtime state of the configuration item, such as CPU usage, memory usage, connection number, response time. The configuration graph realizes the logical or physical association between configuration items through the topology structure between units.

[0066] It should be understood that the construction process of the configuration graph is dynamic and real-time, and can be automatically updated according to the changes in the operating parameters of the target device. This dynamic updating mechanism ensures that the configuration graph always reflects the real running state of the device, thereby providing accurate basic data for subsequent anomaly detection and compliance analysis.

[0067] Step S20: Based on the preset compliance benchmark rule library, the compliance of the configuration graph is detected to obtain a rule-level abnormal configuration item set.

[0068] It should be noted that the compliance benchmark rule library contains pre-defined and explicit compliance requirements, such as security baseline requirements, preferred practice standards, organizational internal specifications, and structured rules converted from industry regulatory regulations.

[0069] It can be understood that the configuration error in a broad sense can be divided into three categories: invalid attribute value of valid configuration item, that is, the configuration item itself is necessary, but the specific attribute value violates the security policy or the running constraint; illegal activation of redundant configuration item, that is, enabling a component (service / port / module) without business demand in the system, forming an additional vulnerability entry; and non-configuration of a legal configuration item, that is, there is a configuration item that should be configured but is not configured or the configuration process is invalid.

[0070] It should be understood that among the above-mentioned three configuration errors, illegal activation of redundant configuration item and non-configuration of legal configuration item are rule-level configuration errors, which cannot be eliminated by adjusting specific configuration parameters, while invalid attribute value of valid configuration item is a parameter-level configuration error, which can be eliminated by adjusting only specific configuration parameters.

[0071] Step S30: According to the anomaly detection model, the configuration items that do not trigger rule-level anomalies are subjected to parameter-level anomaly detection, and a parameter-level anomaly configuration item set is obtained.

[0072] It should be noted that the anomaly detection model refers to a model trained based on machine learning or unsupervised learning algorithm (such as clustering, isolation forest, autoencoder, time series analysis), which is used to discover that a specific configuration parameter or parameter combination deviates from its historical normal baseline or normal pattern of the group. Parameter-level anomaly detection focuses on the rationality of a single parameter value or abnormal fluctuations in the implicit pattern of multiple parameters. The parameter-level anomaly configuration item set is the output of the model after processing, which contains those configuration items that do not violate the explicit rules, but their behavior patterns are judged by the model to be significantly deviated from the normal / expected.

[0073] It can be understood that the anomaly detection model can establish a normal behavior baseline by learning a large amount of historical data, and identify abnormal items in the configuration parameters of the current device that deviate from this baseline. These abnormal items may manifest as abnormal fluctuations in a single parameter value in actual application, or abnormal complex relationships between multiple parameters, and the anomaly detection model can make predictions based on the original configuration parameters to identify configuration parameters that may cause operational failure in advance. This detection method can discover implicit problems that may not be missed by rule-level detection, thereby providing a deeper guarantee for the overall compliance check of device configuration.

[0074] It should be understood that after the aforementioned rule-level anomaly detection, in combination with the detection of parameter-level anomaly configuration items in this step, a basis is provided for subsequent configuration item repair strategies, so that the entire self-checking method can more comprehensively evaluate the configuration compliance of the device.

[0075] Step S40: Confidence analysis is performed on the rule-level anomaly configuration item set and the parameter-level anomaly configuration item set, and a configuration compliance detection result of the target device is obtained according to the confidence analysis result.

[0076] It should be noted that the core of this step is to dynamically correct the credibility of the initial repair strategy. Since the early analysis may be limited by data integrity or rule bias, the system needs to introduce a multi-layer confidence evaluation mechanism: for each operation to be performed, calculate its matching probability based on the real environment of the target device, and automatically eliminate low-confidence repair items. At the same time, additional impact surface simulation prediction is performed on operations that may introduce side effects (such as restarting critical services), and if the expected failure rate exceeds the threshold, manual review is triggered.

[0077] It can be understood that the system first verifies whether the rule is applicable to the current device type, and then checks whether the actual running value of the parameter is indeed a violation. For configuration items with ambiguous boundaries, reference is made to common settings of similar devices for auxiliary judgment. High-reliability results are automatically marked during execution, and secondary inspection processes such as manual review or simulation testing are started for suspicious items. The entire process records the judgment basis in real time, and finally generates a detection report with a confidence rating, and different confidence results correspond to different subsequent processing strategies.

[0078] It should be understood that during processing, the detection accuracy and efficiency need to be dynamically balanced to avoid excessive verification affecting performance. Focus on configuration items that may trigger a chain reaction, such as parameters related to system security or core services, which must be strictly verified. Rules with repeated low confidence should trigger knowledge base optimization processes. When implementing, it is necessary to ensure that the confidence evaluation standard is transparent and traceable to avoid becoming a black box decision. At the same time, manual intervention channels are reserved to prevent business interruption caused by automated misjudgment.

[0079] In a feasible embodiment, after obtaining the configuration compliance detection result of the target device according to the confidence analysis result, the method further comprises steps A10-A40.

[0080] Step A10: According to the configuration compliance detection result, determine the configuration items to be repaired and the repair priority of each configuration item to be repaired.

[0081] It should be noted that the system classifies the problems detected according to the abnormal risk level and business impact, for example, critical parameter out-of-range is marked as an urgent handling item, while the items that can be delayed for optimization are classified as regular repair tasks, ensuring that high-threat vulnerabilities are handled first. Since the setting of repair priority is directly related to the urgency of security risk, this setting can avoid business losses caused by processing delays for important hidden dangers; at the same time, it is convenient for resource allocation, so that the operation and maintenance forces are concentrated on the most urgent configuration error rectification.

[0082] Step A20: According to the configuration items to be repaired and the repair priority of each configuration item to be repaired, a repair strategy decision tree is constructed.

[0083] It should be noted that the core principle of decision tree construction is to abstract complex repair scenarios into a multi-layer logical judgment structure. Take the repair priority as the root node to drive the branch derivation, each sub-node corresponds to a specific configuration item type, the end leaf node binds the repair action, and the high-priority item is expanded as the main branch; multiple abnormal items in the same level are split into sub-branches according to the device module; configuration items with dependency relationships (such as stopping services before changing parameters) are forced to execute path serialization through parent-child node order.

[0084] It can be understood that the tree topology is essentially a pre- performance modeling of the repair process, and its decision path must cover the three logical layers of device state pre-check, atomic operation execution, and change result verification, ensuring that each operation can be traced back to the upstream node state. The generation of each node in the tree depends on the pre- set knowledge graph, for example, the network firewall policy modification node automatically associates the port scanning and connection number detection two sub- verification nodes, and through this structured decomposition, the blindness of manual decision is avoided.

[0085] It should be understood that in a specific implementation, the system automatically calls the configuration item feature extraction engine when executing: first extract the risk label (such as the data leakage index) of the item to be repaired, the influence range, and the repair time limit requirement, and generate a priority score through weight matrix calculation. According to the score interval, the configuration item is classified into the preset level of the decision tree, and the preset level includes the emergency layer, the important layer, and the routine layer. For each level, the configuration item function attribute is further divided into branches, for example, the abnormal kernel parameter of the operating system is uniformly classified into the kernel tuning branch, and the database configuration exception is classified into the storage engine branch.

[0086] 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 repair operation set.

[0087] It should be noted that this process is essentially a process of mapping abstract repair logic into concrete executable commands. Based on the problem features labeled by the leaf nodes of the decision tree, the system retrieves standard operation templates that meet the specific filtering conditions from the atomic operation library, for example, detecting the "password policy strength is insufficient" node will automatically match the standard script group of "modify password complexity parameter". The operation library adopts a three- layer index structure to ensure fast positioning of the corresponding repair scheme.

[0088] It can be understood that the matching process needs to consider operation parameter dynamic adaptation, and the system will automatically fill in the variables according to the additional attributes of the current node. If the decision tree requires modifying the port but does not specify the specific value, the preset value is obtained from the device security baseline and injected into the command. In addition, attention should be paid to the possible operation conflicts to ensure that the same resource configuration item is not bound to mutually contradictory operation instructions.

[0089] It should be understood that the initial operation set only completes the theoretical feasibility matching, and needs to pass through environment adaptation verification before actual execution, for example, filtering the instruction versions not supported by the device, the operation sorting needs to strictly follow the decision tree node path, and cross- level calling is prohibited to prevent state disorder, and all operations must retain the original decision tree node association log for version rollback.

[0090] Step A40: According to the device type and version constraint conditions of the target device, filter the feasible operation items in the initial repair operation set, and execute the hierarchical repair operation.

[0091] In an embodiment, after the performing the hierarchical repair operation, the method further comprises: after the repair is completed, starting the shadow mode to run the new and old configuration double versions, obtaining system performance index data of the double version configuration running, the system performance index data comprising at least one of resource class performance index, service class performance index and security class performance index; obtaining a performance index difference after the configuration is updated according to the system performance index data; if the performance index difference exceeds a preset threshold, triggering a configuration version rollback operation and uploading self-repair failure information to an administrator for manual review.

[0092] It should be noted that the mechanism ensures the reliability of the repair operation by running the new and old configuration double versions in the shadow mode. The new and old configurations are simultaneously effective, but only the new configuration outputs service data, and the system continuously compares the performance index difference between the two. The resource class, service class and security class indexes are comprehensively evaluated to update the influence, avoiding single-dimensional misjudgment. When the difference exceeds the threshold, it is automatically rolled back to prevent secondary problems caused by repair. This way verifies the repair effect and guarantees the business stability.

[0093] It can be understood that after the repair is completed, the system keeps the new configuration running while simulating the old configuration environment in the background and collecting core index data such as CPU, memory and request success rate in real time. The time window rolling algorithm is used to calculate the difference rate, and when the key indicators deviate beyond the limit (such as a 20% increase in delay), it is automatically rolled back immediately, and repair failure logs are recorded. The whole process does not require manual intervention, but abnormal results must be pushed to the operation and maintenance platform for secondary confirmation.

[0094] It should be understood that the rollback operation must ensure atomicity to prevent intermediate states from causing service abnormalities. The evaluation period of the security class index should be longer than that of the resource class index (such as several hours for vulnerability scanning), and the conclusion should be delayed. The administrator needs to make a comprehensive decision based on the difference data and business priority when reviewing.

[0095] The embodiment constructs a configuration graph based on real-time running parameters of the device as an analysis basic view, identifies explicit violation configurations through rule-based rule-level anomaly detection, finds implicit risks through a machine learning model for parameter-level anomaly detection, and generates compliance results through comprehensive evaluation of confidence analysis; then a repair decision tree is constructed according to the risk level, an executable scheme is generated by matching an atomic operation library, and finally the repair is verified and implemented hierarchically through the shadow mode. The system realizes the full-process automation from anomaly discovery, priority sorting to security repair, and especially designs a double version running and index difference monitoring mechanism to ensure the reliability of the repair operation.

[0096] In summary, the technical scheme solves the problems of limited coverage of traditional manual inspection and difficulty in finding hidden risks by configuring a dynamic construction of a graph and a two-stage abnormality detection mechanism; the automatic generation of a repair strategy based on a decision tree and the matching of atomic operations reduce the cost of manual intervention, and the priority sorting ensures that critical risks are disposed of in priority. In combination with the atomic-level node rollback operation, a closed-loop and self-verification configuration management system is formed, which not only meets the strictness requirement of industry compliance audit, but also adapts to the rapid iteration demand of configuration items in a complex IT environment, and provides bottom-layer guarantee for business continuity.

[0097] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as the above-mentioned first embodiment can be referred to the above introduction, and will not be described in detail. On this basis, please refer to Figure 2 , the step S20 of the device configuration compliance self-checking method comprises steps S201-204:

[0098] Step S201: obtaining a parameter key-value pair set of the device configuration parameter according to the configuration graph.

[0099] It should be noted that in the process of rule-level abnormality detection, the configuration graph is parsed by the system to extract the attributes of all configuration items, such as host settings or service policies, and 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 library.

[0100] It can be understood that the extraction process of such parameter key-value pairs aims to simplify the complex topology relationship and provide a unified input for subsequent matching operations, such as obtaining the database connection number or port state from the graph as key-value data. In the rule-level abnormality detection process, the system performs a comprehensive scan of the configuration graph according to the pre-set compliance benchmark rule library, and focuses on identifying three typical configuration errors. First, for invalid attribute values of valid configuration items, the system compares the safety threshold or legal value range defined in the rule library, such as detecting that the database connection number exceeds the pre-set upper limit and marking it as abnormal; at the same time, the system also checks whether there are redundant configuration items, such as high-risk services or ports that are enabled without business demand, which directly violate the disabled safety rules; in addition, the system also verifies whether the key security policy is missing, such as the password complexity policy is not configured or the key business link lacks firewall protection nodes.

[0101] It should be understood that the full coverage of the key-value pair set is the core guarantee of detection accuracy, and any missing or conversion error of configuration items may lead to the failure to identify key errors, affecting the integrity of the overall compliance analysis.

[0102] Step S202: Match the parameter key-value pair set with each rule entry in the compliance benchmark rule library to determine abnormal key-value pairs that are not within the preset parameter range.

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

[0104] It can be understood that the system compares each extracted key-value pair with the preset range in the rule library through an automated algorithm, such as checking whether the port number is within the safe allowed interval. If it exceeds, it is abnormal, thereby accurately locating the invalid attribute value error. This matching process uses the benchmark value of the rule library as a verification scale to ensure that the detection focuses on parameter-level violation issues, improves the efficiency of rule application, and avoids interference factors outside the rules from being included in the abnormality.

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

[0106] It should be noted that for abnormal key-value pairs, the system further analyzes the rule categories that are violated to form rule-level abnormal metadata. This process needs to clearly record the violation type, risk level, and associated security policy to generate executable repair recommendations later.

[0107] It should be understood that the generation of rule-level abnormal metadata is not only a simple classification and labeling, but also requires associated analysis of the topology relationship and business impact of the configuration item. For example, parameter abnormalities on the critical path may have higher repair priorities than similar problems in ordinary configuration items.

[0108] It can be understood that after the scanning is completed, the system generates a structured rule-level abnormal configuration item set, in which each abnormality is clearly labeled with the error type and the basis for triggering the rule. For invalid attribute value errors, the set records the configuration item name, violation attribute, and expected legal value; for redundant configuration items, it indicates the disabled rules that are violated; and in the case of missing security policies, it lists the specific content that should be configured but is missing and its position in the topology. Such structured output provides clear guidance for subsequent repair work, enabling operations personnel to take appropriate measures such as adjusting parameters, disabling redundant functions, or supplementing missing policies for different types of errors, thereby achieving closed-loop management of security configurations.

[0109] In an embodiment, the compliance analysis on the abnormal key-value pair to obtain rule-level abnormal metadata comprises: obtaining the configuration item identifier and abnormal parameter of the abnormal key-value pair; querying a compliance benchmark rule library to obtain the standard value range of the abnormal parameter; calculating the deviation degree of the abnormal parameter from the standard value according to the standard value range of the abnormal parameter; and marking the configuration item identifier, the abnormal parameter, the deviation degree, and the violation type as rule-level abnormal metadata.

[0110] It should be noted that through the pre-defined compliance benchmark rule library, the system can detect that the value of a certain key-value pair deviates from the preset standard, and further analyze the nature and degree of the deviation at this time, rather than simply marking it as "abnormal". The purpose of this mechanism is to consider the complexity of the actual operation and maintenance scene. For example, some parameters may be allowed to exceed the standard for a short time in individual business environments, but their long-term deviation may still pose a security risk. Therefore, the generation of abnormal metadata not only focuses on transient violations, but also needs to be comprehensively evaluated in combination with industry standards and historical baselines. This fine design in principle can effectively improve the scientific nature of compliance management and reduce false positives caused by rigid rules.

[0111] It can be understood that the system extracts key parameters from the configuration graph and classifies the parameters according to pre-defined identifiers (such as service name, port number, or security policy ID) to ensure that each configuration item can be accurately matched to the corresponding item in the compliance rule library during the detection process. When the system finds that a parameter exceeds the standard range, it will immediately perform a deeper compliance calculation, which specifically includes querying the legal upper and lower limits of the parameter, industry recommended values, and special policy constraints within the enterprise. Subsequently, the system will calculate the relative deviation rate according to the difference between the current value and the standard range, such as exceeding the upper limit by 10% or being lower than the minimum standard by 30%, and quantify it as a comparable risk indicator. Finally, the system will encapsulate the identifier of the violating parameter, the measured value, the deviation degree, and the type of violated rule into machine-readable structured metadata for subsequent aggregation analysis and repair decisions.

[0112] It should be understood that the entire process emphasizes automated processing, but the monitoring of key business parameters still introduces a secondary manual review mechanism to avoid algorithmic misjudgment causing misoperation.

[0113] Step S204: aggregating according to the rule-level abnormal metadata to generate a rule-level abnormal configuration item set.

[0114] It can be understood that the aggregation process pays special attention to the specificity of key configuration items, avoids excessive aggregation that dilutes security risks. Abnormalities of core business parameters should be reported independently and are not suitable for regular aggregation processing. At the same time, the aggregation algorithm needs to have dynamic adjustment capability, which can automatically optimize the aggregation strategy according to the change of business scene. In order to guarantee traceability, the mapping relationship between each aggregation result and the original abnormality must be recorded completely.

[0115] In a feasible embodiment, based on the preset compliance benchmark rule library, the compliance of the configuration graph is detected to obtain a rule-level abnormal configuration item set, further comprising: according to the preset compliance benchmark rule of each configuration item in the configuration graph, matching whether the current each configuration item exists in the compliance benchmark rule library; for the configuration items that are not matched in the compliance benchmark rule library, the configuration items are classified into an illegal existing configuration item set; for the configuration items existing in the compliance benchmark rule library but without actual value, the configuration items are classified into a necessary configuration missing item set; according to the conflict detection of the illegal existing configuration item set and the necessary configuration missing item set, a rule abnormal item set after conflict correction is obtained, and the rule abnormal item set after conflict correction is taken as the rule-level abnormal configuration item set.

[0116] In this embodiment, by converting the configuration parameters of the device into a standardized key-value pair set, and matching with the compliance benchmark rule library, three typical errors of invalid attribute value, redundant configuration item and missing configuration are identified, and then the preset rules are compared piece by piece to mark the abnormal key-value pair. Subsequently, rule-level abnormal metadata is generated by analyzing the deviation degree of abnormal parameters. In the metadata aggregation stage, the dispersed abnormal items are intelligently classified according to the abnormal type, risk level and topological relationship to form a structured rule-level abnormal configuration item set.

[0117] In summary, the embodiment significantly improves the configuration compliance management efficiency through automatic rule matching and intelligent aggregation, can improve the accuracy of abnormal detection, and reduce the false positive rate, while the abnormal traceability path is completely retained. Overall, the scheme covers the complete link from abnormal discovery to classification output in an automated manner, while ensuring comprehensive detection, and greatly reduces the complexity of repair through structured output, which is especially suitable for efficient management of massive configuration items in cloud environment or distributed system. In addition, the conflict correction mechanism effectively avoids misjudgment, and the dynamic adjustment characteristic adapts to the needs of different security level scenes, forming an extensible configuration compliance management paradigm.

[0118] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the device configuration compliance self-checking method of the present application. More forms of simple transformation based on this technical concept are within the protection scope of the present application.

[0119] The application also provides a device configuration compliance self-checking device, which comprises Figure 3 , and the device configuration compliance self-checking device comprises:

[0120] a configuration graph construction module 10, configured to construct a configuration graph according to operating parameters of a target device;

[0121] a configuration anomaly detection module 20, configured to perform compliance detection on the configuration graph based on a preset compliance benchmark rule library to obtain a rule-level abnormal configuration item set;

[0122] The configuration anomaly detection module 20 is further configured to perform abnormal parameter detection on configuration items that do not trigger rule-level abnormalities according to an anomaly detection model to obtain a parameter-level abnormal configuration item set.

[0123] a compliance judgment module 30, configured to perform confidence analysis on the rule-level abnormal configuration item set and the parameter-level abnormal configuration item set, and obtain a configuration compliance detection result of the target device according to a confidence analysis result.

[0124] In an embodiment, the configuration anomaly detection module 20 is further configured to match, according to preset compliance benchmark rules of each configuration item in the configuration graph, whether each current configuration item is defined in the compliance benchmark rule library; classify configuration items that are not matched in the compliance benchmark rule library into an illegal existing configuration item set; classify configuration items that exist in the compliance benchmark rule library but do not have actual values into a necessary configuration missing item set; perform conflict detection on the illegal existing configuration item set and the necessary configuration missing item set to obtain a rule abnormal item set after conflict correction, and take the rule abnormal item set after conflict correction as the rule-level abnormal configuration item set.

[0125] In an embodiment, the configuration anomaly detection module 20 is further configured to obtain a parameter key-value pair set of device configuration parameters according to the configuration graph; match the parameter key-value pair set with rule entries in the compliance benchmark rule library one by one to determine abnormal key-value pairs that are not in a 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 rule-level abnormal configuration item set.

[0126] In an embodiment, the configuration anomaly detection module 20 is further configured to obtain a configuration item identifier and an abnormal parameter of the abnormal key-value pair; query the compliance benchmark rule library to obtain a standard value range of the abnormal parameter; calculate a deviation degree of the abnormal parameter from the standard value according to the standard value range of the abnormal parameter; and mark the configuration item identifier, the abnormal parameter, the deviation degree, and a violation type as rule-level abnormal metadata.

[0127] In an embodiment, the configuration anomaly detection module 20 is further configured to generate a parameter-level detection candidate set according to the configuration items of the non-triggered rule-level anomaly; extract the environment features, topology correlation 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 of each configuration item; and perform hierarchical judgment according to the anomaly probability value of the configuration item to obtain a parameter-level anomaly configuration item set.

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

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

[0130] The embodiment can realize differentiated detection by using the linkage of the rule engine and the abnormal configuration detection model in the detection link, can realize dual detection at the rule level and the parameter level by combining a dynamic weight adjustment algorithm, can accurately capture explicit violations by the compliance benchmark rule library first, can then mine implicit risks by the anomaly model, can eliminate false positives by confidence arbitration, can realize low false alarm rate of configuration defects, can automatically match atomic operations and perform hierarchical execution by combining a repair decision tree, can verify changes under real load by the shadow mode, can roll back anomalies immediately, and can ensure business continuity and synchronous improvement of security baseline. The whole process does not need manual intervention, reduces operation and maintenance cost, and enhances real-time performance, reliability and scalability of compliance governance.

[0131] The device configuration compliance self-checking apparatus provided in the present application adopts the device configuration compliance self-checking method in the above embodiments, and can solve the technical problem of how to realize compliance detection of configuration data in a complex IT environment. Compared with the prior art, the device configuration compliance self-checking apparatus provided in the present application has the same beneficial effects as the device configuration compliance self-checking method provided in the above embodiments, and other technical features in the device configuration compliance self-checking apparatus are the same as the features disclosed in the above embodiments, which will not be repeated here.

[0132] The present application provides a device configuration compliance self-checking device, which comprises at least one processor and a memory connected with 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-checking method in the above embodiment one.

[0133] Reference will be made to the following description of the embodiments of the present application, taken in conjunction with the accompanying drawings, in which Figure 4 which shows a structural diagram of a device configuration compliance self-checking device suitable for implementing the embodiments of the present application. The device configuration compliance self-checking device in the embodiments of the present application can include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PADs (Portable Application Description), PMPs (Portable Media Player), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 4 The device configuration compliance self-checking device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0134] As Figure 4As shown, the device configuration compliance self-checking device can include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. In the RAM 1004, various programs and data required for the operation of the device configuration compliance self-checking device are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the device configuration compliance self-checking device to communicate with other devices wirelessly or by wire to exchange data. Although the device configuration compliance self-checking device with various systems is shown in the figure, it should be understood that all the shown systems are not required to be implemented or possessed. More or fewer systems can be alternatively implemented or possessed.

[0135] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are performed.

[0136] The device configuration compliance self-checking device provided by the present application adopts the device configuration compliance self-checking method in the above-mentioned embodiments, and can solve the technical problem of how to realize compliance detection of configuration data in a complex IT environment. Compared with the prior art, the device configuration compliance self-checking device provided by the present application has the same beneficial effects as the device configuration compliance self-checking method provided by the above-mentioned embodiments, and other technical features in the device configuration compliance self-checking device are the same as the features disclosed in the previous embodiment method, which will not be described here.

[0137] It should be understood that various aspects of the disclosure can be implemented in 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 appropriate manner in any one or more embodiments or examples.

[0138] The above description is merely illustrative of the application and is not intended to limit the scope of the application. Any variations and modifications that can be made by any person skilled in the art within the spirit and scope of the application are intended to be encompassed by the application. The scope of the application is defined by the appended claims.

[0139] The application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., a computer program) for performing the device configuration compliance self-checking method in the above embodiments.

[0140] The computer readable storage medium provided by the application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more conductive wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination thereof. In the present embodiment, the computer readable storage medium can be any tangible medium that contains or stores 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 can be transmitted in any appropriate medium, including but not limited to an electrical wire, an optical cable, an RF (Radio Frequency) cable, etc., or any appropriate combination thereof.

[0141] The above computer readable storage medium can be included in the device configuration compliance self-checking device; or can exist separately without being assembled into the device configuration compliance self-checking device.

[0142] The computer readable storage medium described above carries one or more programs, when the one or more programs are executed by the device configuration compliance self-checking device, cause the device configuration compliance self-checking device to: construct a configuration graph according to a running parameter of a target device; perform compliance detection on the configuration graph based on a preset compliance benchmark rule library, to obtain a rule-level abnormal configuration item set; perform abnormal parameter detection on a configuration item that does not trigger rule-level abnormality according to an abnormal detection model, to obtain a parameter-level abnormal configuration item set; and perform confidence analysis on the rule-level abnormal configuration item set and the parameter-level abnormal configuration item set, and obtain a configuration compliance detection result of the target device according to a confidence analysis result.

[0143] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0144] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the blocks can occur in a different order than that noted in the figures. For example, two blocks noted in succession can in fact be executed substantially concurrently or in the opposite order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flow diagrams, and combinations of blocks in the block diagrams and / or flow diagrams, can be implemented by dedicated hardware-based systems that perform the specified functions or operations, or can be implemented by a combination of dedicated hardware-based systems and computer instructions.

[0145] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the names of the modules do not constitute a limitation on the modules themselves.

[0146] The computer readable storage medium provided in the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., a computer program) for executing the device configuration compliance self-checking method described above, and can solve the technical problem of how to implement compliance detection of configuration data in a complex IT environment. Compared with the prior art, the computer readable storage medium provided in the present application has the same beneficial effects as the device configuration compliance self-checking method provided in the above embodiments, and will not be described here.

[0147] The computer program product provided in the present application can solve the technical problem of device configuration compliance self-checking. Compared with the prior art, the computer program product provided in the present application has the same beneficial effects as the device configuration compliance self-checking method provided in the above embodiments, and will not be described here.

[0148] The above only describes some embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields based on the technical concept of the present application, and the contents of the present application and the accompanying drawings are included in the patent protection scope of the present 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; 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. 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; Aggregate the rule-level exception metadata to generate the rule-level exception configuration item set; 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. 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 by hierarchical judgment. 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, 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.

3. The equipment configuration compliance self-inspection method according to claim 2, 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.

4. 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 further configured to: match whether each configuration item in the configuration graph is defined in the compliance benchmark rule library according to the preset compliance benchmark rules of each configuration item; classify configuration items not matched in the compliance benchmark rule library into the illegal configuration item set; classify configuration items that exist in the compliance benchmark rule library but have no configured actual value into the necessary configuration missing item set; perform conflict detection based on the illegal 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; The configuration anomaly detection module is further configured to: obtain a set of parameter key-value pairs of device configuration parameters based on the configuration graph; 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 anomaly metadata; and aggregate the rule-level anomaly metadata to generate the set of rule-level anomaly 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 configuration anomaly detection module 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 the anomaly probability value of 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. 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.

5. A self-testing device for 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 3.

6. 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 3.

Images