Trusted cloud level computing system

Abstract

The invention belongs to the technical field of credible cloud level management, and provides a credible cloud level computing system, which comprises a theory and model library module for solidifying a credible cloud computing theory and a credible cloud unit hierarchical model operated by a storage system to ensure that the computing is consistent and verifiable; the hierarchical calculation module is used for adaptively selecting and executing hierarchical calculation logic according to the architecture data and component relationship of the target system, outputting a quantitative security level and generating a security report; the trusted cloud level management module is used for continuously monitoring the real-time running state of the TCCUN, automatically calling the level calculation module to carry out dynamic recalculation and respond to an external proving request when the state changes, outputting a dynamic security level and a security report, and converting the traditional static compliance check into the traditional static compliance check; and the dynamic trust evaluation and proving capability which runs through the whole life cycle of the system and is driven by data is realized.

Description

Technical Field

[0001] This invention belongs to the field of trusted cloud level management technology, specifically a trusted cloud level calculation system. Background Technology

[0002] In the field of cloud computing, ensuring its continuous trustworthiness and security is a core challenge. Existing security assessment methods mainly rely on periodic, policy-list-based static compliance checks and configuration audits. These methods only generate a "snapshot" of the system's security state at a specific moment, failing to reflect in real-time and dynamic changes in the actual trust level caused by configuration changes, attacks, or component failures during system operation. Furthermore, the complex and multi-layered structure of cloud systems lacks a unified computing model that deeply binds the axioms of trusted computing theory to specific hardware and software architectures. This makes it difficult to quantify, recursively aggregate, and verify the security level from a single chip to the entire cloud platform, resulting in a lack of a solid engineering foundation for overall security assessment.

[0003] Furthermore, security probes and log collection systems deployed for runtime monitoring typically employ fixed and uniform strategies, making it difficult to intelligently differentiate monitoring granularity and dynamically allocate resources based on the actual risks and characteristics of different types of security events (such as hardware tampering, kernel intrusion, and privilege abuse). This "one-size-fits-all" monitoring model may not only lead to missed or delayed responses to high-priority threats, but also waste resources and increase operational burden by collecting large amounts of low-value data, thus hindering the accuracy and efficiency of security situation awareness.

[0004] To address this, the present invention provides a trusted cloud rating calculation system. Summary of the Invention

[0005] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0006] The technical solution adopted by this invention to solve its technical problem is: a trusted cloud level computing system, comprising the following modules: Theory and Model Library Module: Solidifies the trusted cloud computing theory for the operation of the storage system and the hierarchical model of trusted cloud units to ensure computational consistency and verifiability; Hierarchical calculation module: Based on the target system's architecture data and component relationships, it adaptively selects and executes hierarchical calculation logic, outputs a quantified security level, and generates a security report; Trusted Cloud Level Management Module: Continuously monitors the real-time operating status of TCCUN, and automatically calls the level calculation module to perform dynamic recalculation and respond to external proof requests when the status changes, outputting dynamic security level and security report.

[0007] As a further technical solution of the present invention, the trusted cloud level calculation system also includes the following modules: The module for identifying incompatible event types: Based on the current monitoring granularity of the monitoring system for different types of level-related events, it extracts historical event monitoring data with the same monitoring granularity. Through the analysis of the monitoring accuracy of historical events, it identifies level-related event types that are incompatible with the current monitoring granularity of the monitoring system. Event monitoring adjustment and evaluation module: Based on the level-related event types that are not compatible with the current granularity of the monitoring system, the module analyzes the proportion of event types and combines the results of monitoring accuracy analysis to determine whether the monitoring granularity of the monitoring system needs to be optimized and adjusted. Monitoring granularity correlation analysis module: If necessary, it will analyze the correlation between monitoring granularity and monitoring accuracy under different types and levels of correlated events through historical event monitoring data, and build a monitoring correlation model; Event monitoring granularity adjustment module: This module optimizes the monitoring granularity of the monitoring system for different types and levels of related events by adjusting the monitoring correlation model.

[0008] As a further technical solution of the present invention, the theory and model library module includes a structured knowledge base of axioms, definitions and theorems in the trusted cloud computing theory, which is used to unambiguously define and reason about trust in the cloud; the trusted cloud unit hierarchical model is a trust tree data structure that structures cloud entities into a tree root, trunk, branches and leaves, which is used to define the propagation path of hierarchical calculation.

[0009] As a further technical solution of the present invention, the hierarchical calculation module includes: The architecture data receiving unit is used to receive and parse the configuration description file of the target system, and build a structured, traversable TCCUN trust tree object model in memory. The hierarchical engine and the final level calculation engine are used to traverse the trust tree and calculate the data security level for each node in the tree through a bottom-up recursive calculation method, where the level of the root node is used as the final security level of the entire system.

[0010] As a further technical solution of the present invention, the calculation process performed by the hierarchical engine and the final hierarchical calculation engine includes: Assign an initial data security level to the lowest-level technical mechanism represented by the leaf nodes; Identify the combination patterns of all child nodes for a non-leaf node, including cooperation patterns, overlay patterns, or strategy selection patterns. The corresponding computational logic is selected based on the identified combination pattern to calculate the data security level of the non-leaf node. The collaboration mode adopts the barrel effect logic, the superposition mode adopts the enhancement function logic, and the strategy selection mode adopts the dynamic selection function. The calculation is performed recursively until the final security level of the root node is obtained.

[0011] As a further technical solution of the present invention, the state change in the Trusted Cloud Level Management Module includes configuration change, state abnormality or performance index abnormality; the dynamic recalculation triggers local subtree recalculation or full tree recalculation according to the impact range of level-related events, wherein high-priority events trigger recalculation immediately, and low-priority events trigger recalculation during the evaluation period.

[0012] As a further technical solution of the present invention, when the Trusted Cloud Level Management Module responds to an external verification request, after verifying the requester's permissions, it triggers the Level Calculation Module to perform a fast level recalculation based on the latest status, digitally signs the generated security report, and returns it to the requester.

[0013] As a further technical solution of the present invention, the process of identifying the type of incompatible event associated with the mismatch level in the monitoring and identification module includes: For any type of hierarchical related event, its monitoring error value is calculated based on historical event monitoring data; The monitoring error value is the sum of the missed judgment value and the downgrade misjudgment value; The missed detection performance value is the ratio of the number of times this type of event was judged as a normal event by the monitoring system in historical monitoring to the total number of monitoring times; The downgrade misjudgment performance value is the ratio of the number of times that such an event was actually a high-priority event but was judged as a low-priority event by the monitoring system in historical monitoring to the total number of times that such an event was actually a high-priority event. The calculated monitoring error value is compared with the preset monitoring error threshold. If the monitoring error value is greater than or equal to the monitoring error threshold, it is determined that the event type is not compatible with the current monitoring granularity.

[0014] As a further technical solution of the present invention, the process of analyzing and determining whether monitoring granularity optimization adjustment is needed in the event monitoring adjustment evaluation module includes: Calculate the percentage of level-related event types that are not compatible with the current monitoring granularity to obtain the mismatch percentage; For each mismatch event type, calculate the ratio of the absolute difference between its monitoring error value and the monitoring error threshold, and average the ratio of the difference for all mismatch event types to obtain the degree of mismatch value. The mismatch value is obtained by summing the mismatch percentage and the mismatch degree value. The monitoring mismatch value is compared with a preset monitoring mismatch threshold. If it is greater than the monitoring mismatch threshold, it is determined that the monitoring granularity of the monitoring system needs to be optimized and adjusted.

[0015] As a further technical solution of the present invention, the process of constructing the monitoring correlation model in the monitoring granularity correlation analysis module includes: For type-level related events that need optimization, obtain the sequence of monitoring error values ​​at different monitoring granularities based on historical data; Calculate the Pearson correlation coefficient between the monitoring granularity sequence and the monitoring error value sequence, and determine whether the correlation type is linear or nonlinear based on the correlation coefficient; Based on the determined association type, the corresponding linear or nonlinear fitting method is used to fit the two sequences to obtain the monitoring association model; The event monitoring granularity adjustment module inputs the preset monitoring error threshold into the monitoring association model to obtain the target monitoring granularity, and optimizes and adjusts the monitoring granularity of the monitoring system accordingly.

[0016] The beneficial effects of this invention are as follows: 1. By combining Trusted Computing Theory (TCCT) with a specific cloud system architecture (TCCUN model), and utilizing a "tree of trust" data structure, this system achieves bottom-up, recursive quantitative calculation of security levels from the lowest-level technical components to the entire cloud system. This system not only performs initial security assessments based on static configurations and generates detailed reports including vulnerabilities, but more importantly, it achieves dynamic management of security levels through a continuous monitoring module. When operational events such as configuration changes or integrity breaches are detected, the system automatically triggers local or global recalculations to ensure that the security level reflects the current system state in real time. It can also respond to external requests by providing digitally signed, verifiable, real-time security proofs. This transforms traditional static compliance checks into a data-driven, dynamic trust assessment and proof capability that spans the entire system lifecycle.

[0017] 2. By analyzing historical monitoring data, the system intelligently identifies event types (such as specific hardware or access control events) that are mismatched with the current monitoring deployment granularity (e.g., probe coverage intensity) and prone to missed or false alarms. The system then assesses the overall impact of these "mismatched" events to determine whether optimization is necessary. When optimization is required, the system constructs a correlation model (linear or non-linear) between the monitoring granularity and the monitoring error rate for different event types, and uses this model to deduce the target monitoring granularity required to achieve an acceptable monitoring error threshold. Ultimately, this enables refined and differentiated adjustments to the monitoring intensity for various events. This allows the monitoring system to allocate limited resources more intelligently, significantly improving the accuracy and timeliness of capturing critical security events, transforming from a "one-size-fits-all" monitoring approach to data-driven, continuously self-optimizing, and precise monitoring. Attached Figure Description

[0018] The invention will now be further described with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart of the Trusted Cloud Level Calculation System described in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the steps of trusted cloud level computing management in the trusted cloud level computing system described in this embodiment of the invention. Figure 3 This is a flowchart illustrating the steps of optimizing the level-related event monitoring mechanism in the trusted cloud level calculation system described in this embodiment of the invention. Detailed Implementation

[0020] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0021] Example 1: Please see Figures 1-2 As shown in the embodiment of the present invention, the trusted cloud level computing system includes the following modules: Theory and Model Library Module: Solidifies the trusted cloud computing theory for the operation of the storage system and the hierarchical model of trusted cloud units to ensure computational consistency and verifiability; In the theory and model library module, the Trusted Cloud Computing Theory (TCCT) typically exists as a structured knowledge base (such as XML, JSON, or dedicated database tables). Each axiom, definition, and theorem is a record, labeled with its unique ID, content, type, and logical dependencies with other entries. Specifically, it includes, but is not limited to: axioms (such as the C-A1 primitive reliability axiom), the C-A3 integrity measurement axiom, the C-A5 access control effectiveness axiom, definitions (such as the C-D1 root of trust), and theorems (such as the C-T1 secure boot theorem), used to unambiguously define and reason about "trust in the cloud." For example, the C-A1 primitive reliability axiom means that, in computation, when evaluating an encryption algorithm (such as AES-256), the system can assume that its mathematical principles are reliable, thus directly assigning it a basic security level (e.g., DSL4). The computation engine no longer needs to question whether "AES-256 itself is secure"; C-A3 Integrity Measurement Axiom & C-A5 Access Control Effectiveness Axiom: These two axioms directly require that when evaluating a component, the system must check whether it possesses measurable integrity and whether access control is enforced. This translates into specific evaluation dimensions in the rating calculation. If a component cannot be measured, its rating in that dimension may be 0; In the theory and model library module, the Trusted Cloud Unit (TCCUN) hierarchical model is represented as: a unified abstract model that structures cloud entities (such as servers, virtual machines, and applications) into a "tree of trust" data structure, including: Root Trust Tree (TCCR): This is typically the hardware root of trust (such as TPM or secure boot chip). It is the starting point of trust for the entire tree, and its level is of paramount importance.

[0022] The trunk (TCCINFRA): represents the physical or logical infrastructure such as data centers, server rooms, and racks. It supports the branches and leaves.

[0023] Tree branch (TCDDEV): Represents a specific computing device, such as a physical server, network switch, or storage array.

[0024] Tree Leaf (TCDSU): Represents the finest-grained functional unit, such as a virtual machine, a container, a database instance, or an API service.

[0025] It should be noted that the tree structure of the trust tree defines the propagation path of hierarchy calculation. Hierarchy calculation is a bottom-up, recursive process from leaves to roots. The hierarchy of a parent node is calculated from the hierarchies of all its child nodes through a specific combination pattern. It's also important to clarify the runtime form of the "Tree of Trust": after the architecture data receiving unit parses the configuration file, what's formed in the system isn't a graph, but a massive tree-like data structure composed of thousands of such node objects linked together by pointers or references. The level calculation process is essentially traversing this tree and assigning a value to the currently calculated Data Security Level (DSL) attribute of each node. The value range of DSL (Data Security Level) is defined as follows: DSL is not a continuous value, but a discrete, well-defined level scale. For example: DSL0: No protection or protection failure; DSL1: Basic software protection; DSL2: Controlled administrator access; DSL3: Hardware-based isolation and authentication; DSL4: High-guarantee security for formal verification.

[0026] Hierarchical calculation module: Based on the target system's architecture data and component relationships, it adaptively selects and executes hierarchical calculation logic, outputs a quantified security level, and generates a security report; In the hierarchical calculation module, the hierarchical calculation module includes an architecture data receiving unit and a hierarchical engine & final level calculation engine. The architecture data receiving unit is used to output a structured TCCUN tree to be calculated and the attribute data of each node in the tree according to the configuration description file of the target system. The hierarchical engine & final level calculation engine is used to calculate and output the quantified security level. Specifically, the operation and processing of the data receiving unit of the architecture is as follows: Input: The configuration description file for the target system. This file must conform to the TCCUN model, describing all entities and their relationships in the system in a "tree of trust" structure.

[0027] Processing: The unit parses the file and constructs a traversable "tree of trust" object model in system memory.

[0028] Output: A structured TCCUN tree to be computed, and attribute data for each node in the tree; The operational process of the architecture data receiving unit is illustrated by the following example: Input: A structured data file (such as YAML or JSON); deal with: Syntax and schema validation: First, validate whether the input file conforms to the predefined TCCUN Schema (e.g., an Infra node must exist under a root node). Object instantiation: Parse the file and create a corresponding node object for each discovered entity (e.g., if a server tag is discovered, create a TCDDEV node object). Relationship building: Based on the nesting or reference relationships in the file, assign values ​​to the ParentID and ChildrenList properties of the node objects to build a complete tree structure in memory; Output: A living, programmable, and operable "trust tree" root node and the attribute data of each node; The operation and processing of the hierarchical engine and the final level calculation engine are as follows: A1: The engine traverses to the leaf nodes of the tree, evaluates each technical mechanism, assigns values ​​to the most basic security technologies, and assesses the level of the lowest-level technical mechanism (TCCTSM). A2 applies the "barrel effect (min function)" to aggregate underlying technologies and calculates the levels of the five core security domains, namely the levels of the Computation Core Security Mechanism (TCCSM). A3, once again applying the "barrel effect (min function)" to converge the five core mechanisms, to obtain the overall level of the Trusted Cloud Unit, that is, to calculate the final level of the Trusted Cloud Unit (TCCUN); The following is an illustrative explanation of the operational process of the aforementioned hierarchical engine and final level calculation engine: Step 1: Assigning levels to leaf nodes (technical mechanism layer); Objective: To assign an initial DSL to the lowest-level nodes in the tree that have no child security components (i.e., various TCCTSMs).

[0029] Operation: The engine traverses to the leaf node (e.g., a TCDTPM node).

[0030] Calculation method: Combination patterns are not involved here. The level is determined using a lookup table or a rule engine, specifically: Lookup table method: The system has a built-in knowledge base that maps common technical configurations to DSL levels. For example: TPM2.0+ security configuration A -> DSL4.

[0031] Rule engine: Executes a set of evaluation scripts based on the TCCT axioms; Step 2: Calculation of the hierarchy of internal nodes (core mechanism layer and unit layer). Objective: Calculate the rank of non-leaf nodes (such as TCDKN, TCDDEV).

[0032] Operation: Once the levels of all child nodes of a node have been calculated, begin calculating the level of that node itself.

[0033] Sub-step 2.1: Combination pattern recognition; Input: Metadata (type, function description, dependencies) of the node and all its child nodes.

[0034] Recognition logic: Collaboration Mode: If child nodes have strong functional dependencies, they collectively constitute the complete functionality of a parent node. For example, the five sub-mechanisms of TCDKN (TPM, TEE, SE...) collectively constitute "kernel security," and none can be omitted. Key words: dependency, collaboration, indispensable.

[0035] Overlay Mode: If child nodes are functionally independent, they collectively provide redundancy or enhancement capabilities to the parent node. For example, an authentication gateway might have child nodes for "Password Authentication" and "Biometric Authentication." Key identification terms: independent, redundant, multi-factor, enhanced.

[0036] Policy selection mode: If the child nodes are mutually exclusive options, the parent node will only enable one of them at any given time. For example, a cryptographic service with child nodes "AES-128" and "AES-256". Key words to identify: mutually exclusive, policy, selection.

[0037] Sub-step 2.2: Calculate the logic selection; Collaboration mode -> Barrel effect logic (min function); Overlay mode -> Enhanced function logic (custom function, result >= max(child node level)); Strategy selection mode -> Dynamic selection function (output = level of the currently active child node); Sub-step 2.3: Perform the calculation; Collaboration mode: Parent node DSL = min(child node 1.DSL, child node 2.DSL, ...); Overlay mode: Parent node DSL = Enhance(child node 1.DSL, child node 2.DSL, ...); Strategy selection mode: Parent node DSL = currently active child node.DSL; Step 3: The engine backtracks to the parent node of the current node and repeats Step 2 until the level of the root node (TCCR) of the entire tree is calculated. The level of this root node is the final security level of the entire target system. In the hierarchical calculation module, the process of generating a security report is as follows: Input: The entire "trust tree" after calculation, where each node contains the calculated data security level; deal with: Weakness analysis: The system traverses the tree to find all nodes whose level is equal to the level of their parent node. These nodes are the "weak links" that cause the higher-level node to be of low level.

[0038] Report generation: Serialize the tree structure and information on weaknesses into a structured report (such as JSON or PDF).

[0039] Output: Includes the final security level, a list of all component levels, and a security report that clearly identifies the paths to vulnerabilities; Trusted Cloud Level Management Module: Continuously monitors the real-time operating status of TCCUN, and automatically calls the level calculation module to perform dynamic recalculation and respond to external proof requests when the status changes, outputting dynamic security level and security report; The Trusted Cloud Level Management module continuously monitors the real-time operational status of TCCUN, specifically including: Configuration changes: For example, security policies are modified, or a service is shut down; Abnormal status: For example, integrity measurement failure, intrusion detection system alarm; Performance metrics: For example, a timeout in the trust chain metric may indicate an attack. The specific monitoring methods are as follows: data is collected in real time through a lightweight agent deployed on the TCCUN node or by calling the cloud platform's own API (such as AWS CloudTrail, Azure Monitor); In the Trusted Cloud Level Management module, the trigger condition for automatically calling the Level Calculation Module for dynamic recalculation when the status changes is: The monitoring system detected predefined level-related events, which include high-priority events and low-priority events. It should be noted that high-priority events and low-priority events are just classifications of level-related events in terms of priority. For example, high-priority events (triggered immediately) include trust root metric failures and critical security service outages. The system will immediately force the DSL of the affected node to be set to 0 and trigger a local recalculation starting from that node. Understandably, for the sake of efficiency, the Trusted Cloud Level Management module does not always recalculate the entire tree. Instead, it can recalculate only the affected subtree (all nodes on the path from the event occurrence node to the root node) based on the scope of the impact of level-related events. Low-priority events (timed or delayed triggers): such as log configuration changes. The system may mark the node as "pending re-evaluation" and update its level in the next evaluation cycle; In the Trusted Cloud Level Management module, the process of outputting dynamic security levels and security reports is as follows: The verifier sends a request with their identity credentials. After verifying that the requester is entitled to the proof report, the Trusted Cloud Level Management Module immediately performs a fast level recalculation based on the latest status through the level calculation module and generates a security report. The Trusted Cloud Level Management Module uses a private key to digitally sign the generated security report and then returns the signed report to the requester. In this implementation plan, it is understood that by combining Trusted Computing Theory (TCCT) with a specific cloud system architecture (TCCUN model), and through a "tree of trust" data structure, a bottom-up, recursive quantitative calculation of security levels is achieved from the lowest-level technical components to the entire cloud system. This system not only performs initial security assessments based on static configurations and generates detailed reports containing vulnerabilities, but more importantly, it achieves dynamic management of security levels through a continuous monitoring module. When operational events such as configuration changes or integrity breaches are detected, the system can automatically trigger local or global recalculations to ensure that the security level reflects the current system state in real time, and can respond to external requests by providing digitally signed, verifiable, real-time security proofs. This transforms traditional static compliance checks into a data-driven, dynamic trust assessment and proof capability that spans the entire system lifecycle.

[0040] Example 2: Please see Figure 1 , Figure 2 as well as Figure 3 As shown, the Trusted Cloud Level Calculation System described in this embodiment of the invention mainly focuses on monitoring and optimizing level-related events in the Trusted Cloud Level Management module, and specifically includes the following modules: The module for identifying incompatible event types: Based on the current monitoring granularity of the monitoring system for different types of level-related events, it extracts historical event monitoring data with the same monitoring granularity. Through the analysis of the monitoring accuracy of historical events, it identifies level-related event types that are incompatible with the current monitoring granularity of the monitoring system. In the module for monitoring and identifying incompatible event types, the different types of associated events include, but are not limited to: hardware and firmware layer events, system and kernel layer events, and access control and authentication events. In the module for identifying incompatible event types, the monitoring granularity refers to the deployment ratio (coverage intensity) of monitoring probes when the monitoring system monitors events. In the module for identifying non-adaptive event types, the historical event monitoring data includes the monitoring results of the monitoring system for different historical events and the actual monitoring results of the historical events. For example, the monitoring system identifies a historical event as a normal event, while the actual monitoring results of the historical event are classified as a hierarchical event and a high-priority event. In the module for identifying incompatible event types, the process of identifying event types that are not compatible with the current monitoring granularity of the monitoring system is as follows: Based on any type of hierarchical association event; The percentage of times that a hierarchically related event was identified as a normal event by the monitoring system in historical monitoring is used to obtain the missed detection value of hierarchically related events; The percentage of times a hierarchical related event was actually a high-priority event but was identified as a low-priority event by the monitoring system in historical monitoring is used to obtain the downgrade misjudgment performance value of hierarchical related events; The sum of the missed detection performance value and the downgraded misjudgment performance value of the graded related event is obtained to obtain the monitoring error value of the graded related event; In this implementation scheme, the monitoring error value is compared with the monitoring error threshold; If the monitoring error value is greater than or equal to the monitoring error threshold, it indicates that the event type associated with this level is not compatible with the current monitoring granularity of the monitoring system. If the monitoring error value is less than the monitoring error threshold, it means that the event type associated with this level is compatible with the current monitoring granularity of the monitoring system; Event monitoring adjustment and evaluation module: Based on the level-related event types that are not compatible with the current granularity of the monitoring system, the module analyzes the proportion of event types and combines the results of monitoring accuracy analysis to determine whether the monitoring granularity of the monitoring system needs to be optimized and adjusted. In the event monitoring adjustment and evaluation module, the process of analyzing and determining whether the monitoring system needs to be optimized and adjusted in terms of monitoring granularity is as follows: The percentage of hierarchical association event types whose granularity is currently mismatched with the statistical and monitoring system is obtained as the mismatch percentage among all hierarchical association event types. Based on any level-related event type that is not compatible with the current granularity of the monitoring system, calculate the ratio of the absolute difference between the monitoring error value and the monitoring error threshold to obtain the monitoring error over-limit value of the level-related event type that is not compatible with the current granularity of the monitoring system. Then, average the monitoring error over-limit values ​​of all level-related event types that are not compatible with the current granularity of the monitoring system to obtain the degree of mismatch value. The sum of the misfit percentage and the misfit degree value is calculated to obtain the monitoring mismatch value; In this implementation scheme, the monitored mismatch value is compared with the monitored mismatch threshold; If the monitoring mismatch value is less than or equal to the monitoring mismatch threshold, it means that no optimization adjustment of the monitoring granularity of the monitoring system is required. If the monitoring mismatch value is greater than the monitoring mismatch threshold, it indicates that the monitoring granularity of the monitoring system needs to be optimized and adjusted. Monitoring granularity correlation analysis module: If necessary, it will analyze the correlation between monitoring granularity and monitoring accuracy under different types and levels of correlated events through historical event monitoring data, and build a monitoring correlation model; In the monitoring granularity correlation analysis module, the process of constructing the monitoring correlation model is as follows: Based on any type of hierarchical association event; Based on historical event monitoring data, the monitoring error values ​​of graded events at different monitoring granularities are obtained, and the different monitoring granularities are integrated into a monitoring granularity sequence, and the monitoring error values ​​at different monitoring granularities are integrated into a monitoring error value sequence. Calculate the Pearson correlation coefficient between the monitoring granularity sequence and the monitoring error value sequence, and then absolutize it to obtain the monitoring correlation value; In this implementation plan, the correlation type between monitoring granularity and monitoring accuracy is determined by monitoring correlation values, specifically as follows: If the monitoring correlation value is greater than or equal to the monitoring correlation threshold, it indicates that there is a linear correlation between monitoring granularity and monitoring accuracy. If the monitoring correlation value is less than the monitoring correlation threshold, it indicates that there is a non-linear correlation between monitoring granularity and monitoring accuracy. If there is a linear correlation, the least squares method is used to linearly fit the monitoring granularity sequence and the monitoring error value sequence, and the resulting fitted model is the monitoring correlation model. If there is a nonlinear correlation, the monitoring granularity sequence and the monitoring error value sequence are nonlinearly fitted, and the fitting model with the highest goodness of fit is selected as the monitoring correlation model. The nonlinear fitting method includes, but is not limited to, exponential function fitting, power function fitting, etc. Event monitoring granularity adjustment module: Optimizes the monitoring granularity of different types and levels of related events by adjusting the monitoring correlation model; In the event monitoring granularity adjustment module, the process of optimizing the monitoring granularity of the monitoring system for different types and levels of related events through the monitoring correlation model is as follows: Based on any type of hierarchical association event; The monitoring error threshold of hierarchical correlation events is used as input and substituted into the monitoring correlation model to obtain the target monitoring granularity of hierarchical correlation events. The monitoring granularity of hierarchical correlation events is then optimized and adjusted according to the target monitoring granularity. In this implementation plan, it is understood that, based on the dynamic monitoring capabilities of Example 1, the accuracy and adaptability of its event monitoring mechanism are further optimized. Its core effect is to intelligently identify event types (such as specific hardware or access control events) that are mismatched with the current monitoring deployment granularity (e.g., probe coverage intensity) and prone to missed or false detections through analysis of historical monitoring data. The system then assesses the overall impact of such "mismatched" events to decide whether optimization is necessary. When optimization is required, the system constructs a correlation model (linear or non-linear) between the monitoring granularity and the monitoring error rate for different types of events, and uses this to deduce the target monitoring granularity required to achieve an acceptable monitoring error threshold. Ultimately, this achieves refined and differentiated adjustments to the monitoring intensity of various events. This enables the monitoring system to more intelligently allocate limited resources, significantly improving the accuracy and timeliness of capturing critical security events, transforming from a "one-size-fits-all" monitoring approach to data-driven, continuously self-optimizing, and precise monitoring.

[0041] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A trusted cloud level computing system, characterized by: The system comprises the following modules: Theoretical and model library module: solidify the running theory of trusted cloud computing and the hierarchical model of trusted cloud unit, to ensure consistent and verifiable computation; Hierarchical computation module: according to the architecture data and component relationship of the target system, adaptively select and execute hierarchical computation logic, output quantitative security level, and generate security report; Trusted cloud level management module: continuously monitor the real-time running state of TCCUN, and automatically call the hierarchical computation module for dynamic recalculation when the state changes, and respond to external proof requests, output dynamic security level and security report. 2.The trusted cloud level computing system of claim 1, wherein: The trusted cloud level computation system further comprises the following modules: Monitoring non-adaptive event type identification module: according to the monitoring granularity of the monitoring system for different types of level-related events, extract historical event monitoring data of the same monitoring granularity, identify the type of level-related events that are not adaptive to the current monitoring granularity of the monitoring system through monitoring accuracy analysis of historical events; Event monitoring adjustment evaluation module: according to the type of level-related events that are not adaptive to the current granularity of the monitoring system, analyze and judge whether the monitoring granularity of the monitoring system needs to be optimized and adjusted through event type proportion analysis and combined with monitoring accuracy analysis results; Monitoring granularity correlation analysis module: if needed, analyze the correlation type between monitoring granularity and monitoring accuracy under different types of level-related events through historical event monitoring data analysis, and build a monitoring correlation model; Event monitoring granularity adjustment module: optimize and adjust the monitoring granularity of the monitoring system for different types of level-related events through the monitoring correlation model. 3.The trusted cloud level computing system of claim 1, wherein: In the theoretical and model library module, the trusted cloud computing theory includes a structured knowledge base of axioms, definitions and theorems, which is used to define and reason about trust in the cloud without ambiguity; The hierarchical model of trusted cloud unit is a trust tree data structure that structures the cloud entity into a tree root, trunk, branch and leaf, which is used to define the propagation path of level calculation.

4. The trusted cloud level computing system of claim 3, wherein: The hierarchical computation module comprises: An architecture data receiving unit for receiving and parsing the configuration description file of the target system, and constructing a structured and traversable TCCUN trust tree object model in memory; A hierarchical engine and a final level calculation engine for traversing the trust tree and calculating the data security level for each node in the tree through a bottom-up recursive calculation method, wherein the level of the root node is the final security level of the entire system.

5. The trusted cloud level computing system of claim 4, wherein: The calculation process performed by the hierarchical engine and the final level calculation engine comprises: Assigning an initial data security level to the bottommost technical mechanism represented by the leaf node; Identifying the combination mode of all child nodes for non-leaf nodes, which includes cooperation mode, superposition mode or strategy selection mode; According to the identified combination mode, select the corresponding calculation logic to calculate the data security level of the non-leaf node, wherein the cooperation mode adopts the bucket effect logic, the superposition mode adopts the enhancement function logic, and the strategy selection mode adopts the dynamic selection function; Recursively calculate until the final security level of the tree root node is obtained.

6. The trusted cloud level computing system of claim 1, wherein: The state change includes configuration change, state anomaly or performance index anomaly; the dynamic recalculation triggers local subtree recalculation or whole tree recalculation according to the influence range of the level related event, wherein a high priority event triggers recalculation immediately, and a low priority event triggers recalculation in an evaluation period.

7. The trusted cloud level computing system of claim 1, wherein: When the trusted cloud level management module responds to an external proof request, after verifying the authority of the requester, the level calculation module is triggered to perform fast level recalculation based on the latest state, and a security report generated is digitally signed and returned to the requester.

8. The trusted cloud level computing system of claim 2, wherein: In the monitoring non-adaptive event type identification module, the process of identifying the non-adaptive level related event type includes: For any type of level related event, the monitoring error value is calculated based on historical event monitoring data; The monitoring error value is the sum of the missed judgment performance value and the downgrade misjudgment performance value; The missed judgment performance value is the ratio of the number of times that the event is judged as a normal event by the monitoring system to the total number of monitoring times in historical monitoring; The downgrade misjudgment performance value is the ratio of the number of times that the event is actually a high priority event but is judged as a low priority event by the monitoring system in historical monitoring to the total number of times that the event is actually a high priority event; The calculated monitoring error value is compared with the preset monitoring error threshold value, and if the monitoring error value is greater than or equal to the monitoring error threshold value, it is determined that the event type is not adaptive to the current monitoring granularity.

9. The trusted cloud level computing system of claim 8, wherein: In the event monitoring adjustment evaluation module, the process of analyzing and determining whether monitoring granularity optimization adjustment is needed includes: Calculate the proportion of the number of level related event types that are not adaptive to the current monitoring granularity, and obtain the non-adaptive proportion; For each non-adaptive event type, calculate the absolute difference value proportion of the monitoring error value and the monitoring error threshold value, and average the difference value proportions of all non-adaptive event types to obtain a non-adaptive degree value; Sum the non-adaptive proportion and the non-adaptive degree value to obtain a monitoring mismatch value; The monitoring mismatch value is compared with the preset monitoring mismatch threshold value, and if it is greater than the monitoring mismatch threshold value, it is determined that the monitoring system needs to be optimized and adjusted in monitoring granularity.

10. The trusted cloud level computing system of claim 9, wherein: In the monitoring granularity correlation analysis module, the process of constructing a monitoring correlation model includes: For the type of level related event that needs to be optimized, the monitoring error value sequence under different monitoring granularities is obtained based on historical data; Calculate the Pearson correlation coefficient between the monitoring granularity sequence and the monitoring error value sequence, and determine the correlation type as linear or nonlinear according to the correlation coefficient; According to the determined correlation type, a linear or nonlinear fitting method is used to fit the two sequences to obtain the monitoring correlation model; The event monitoring granularity adjustment module inputs the preset monitoring error threshold value into the monitoring correlation model to obtain a target monitoring granularity, and optimizes and adjusts the monitoring granularity of the monitoring system accordingly.

Images