Trusted cloud native security level treatment system and method

Abstract

The invention belongs to the technical field of cloud service security, and provides a trusted cloud native security level treatment system and method, and the method comprises the steps: defining a trusted cloud unit grading hardware anchoring standard through building a trusted cloud native security level calculation framework; analyzing user requirements and risk factors, and automatically matching a hardware anchor point and a security policy; verifying the integrity of the hardware anchor point based on real-time remote certification, and dynamically outputting a level certification and adjustment instruction; an anchor point state difference set is obtained through differentiation analysis, a dynamic mapping relation is constructed in combination with service load characteristics, and a migration execution benchmark is deduced; a hardware anchor point switching key execution point is tracked, a trust state sequence is constructed, an acceptance result is judged, and a delivery instruction is output or a rollback mechanism is triggered; the system is firstly applied to the method; according to the invention, stable operation of service loads with different security level requirements in a compliance hardware environment is realized, and the security controllability and reliability of cloud services are improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of cloud service security, and in particular relates to a trusted cloud native security level governance system and method. BACKGROUND

[0002] With the in-depth development of digital economy, cloud native technology has become a key infrastructure supporting various business systems due to its core advantages of elastic expansion and agile deployment. However, the security governance of the current cloud native environment faces core technical bottlenecks: there is a lack of standardized closed-loop mechanism for the adaptation of security levels to hardware capabilities, resulting in a disconnection between security requirements and actual protection effects, and it is difficult to achieve compliance protection and business continuity maintenance in coordination.

[0003] The existing technology lacks a hierarchical standard system, and there is a lack of unified basis for hardware anchoring. The cloud native environment includes multiple scenarios from lightweight business to financial-level high-sensitivity business, and the intensity requirements of different scenarios for security protection are significantly different. However, the existing technology has not established a hardware trusted capability grading standard that accurately binds with business security levels. Traditional security governance relies on software-defined protection strategies, ignores the security support role of underlying hardware anchors, or only performs simple adaptation of hardware resources, and does not form a gradient governance framework from basic security to full-process hardware anchoring, resulting in low-sensitivity businesses bearing redundant security costs, and high-security requirement businesses lacking rigid protection support such as hardware-level isolation and encryption.

[0004] Therefore, the application provides a trusted cloud native security level governance system and method. SUMMARY

[0005] In order to make up for the deficiencies of the prior art and solve at least one technical problem proposed in the background art.

[0006] The technical scheme adopted by the application to solve its technical problems is: A trusted cloud native security level governance method: comprising the following steps: Obtaining a trusted cloud unit level adjustment instruction, performing differential analysis on the current hardware running baseline of the target trusted cloud unit and the target level compliance characteristics, and obtaining an anchor state difference set; Collecting service load characteristics, constructing a dynamic mapping relationship between hardware resources and security load in combination with the anchor state difference set, and deriving a migration execution benchmark of the target node in the switching process according to the dynamic mapping relationship; Based on the migration execution benchmark, real-time tracking and processing resource scheduling and state migration in the hardware anchor switching process to obtain a key execution point; verifying the trust anchoring result of the key execution point, and constructing a trust state sequence based on the trust anchoring result; The execution verification is performed based on the trust state sequence and the dynamic mapping relationship, an execution consistency index is obtained, and it is determined whether the acceptance expectation is met; if yes, a safety level delivery confirmation instruction is output; if not, a rollback mechanism is triggered.

[0007] Further, the manner of obtaining the trusted cloud unit level adjustment instruction is: Based on the core principle of cloud service security, a level calculation framework of trusted cloud native security is established, and a hierarchical hardware anchoring standard of the cloud native environment is defined based on the level calculation framework; Based on the hierarchical standard, the trusted cloud native level management unit analyzes user demand and risk elements, automatically matches and forcibly configures corresponding hardware anchors and security policies; The trusted cloud native level management unit performs real-time remote proof based on the hardware anchors and security policies to verify the integrity of the hardware anchors, and dynamically outputs a trusted level proof and a trusted cloud unit level adjustment instruction based on the verification result.

[0008] Further, the manner of outputting the trusted level proof and the trusted cloud unit level adjustment instruction is: The trusted cloud native level management unit collects static information of each trusted cloud unit component inside; If the trusted cloud native level management unit receives a current security level request of the proof component, active verification of the static information is triggered; Based on the active verification result, a dynamic trusted report containing the trusted level proof and the level adjustment instruction are output.

[0009] Further, the manner of performing the differential analysis is: Based on the received trusted cloud unit level adjustment instruction, hardware running baseline data of the target trusted cloud unit is collected; The anchoring standard of the hierarchical hardware in the trusted cloud native security level calculation framework is obtained, the corresponding compliance level features of the target level are extracted, and a level compliance feature library is constructed; The current hardware running baseline is processed by dimension-by-dimension inspection using a feature matching algorithm to identify difference dimensions and non-difference dimensions; The numerical quantization results of the difference dimensions and the non-difference dimensions are multiplied by the corresponding weights to obtain a state feature vector; A compliance feature vector is constructed, and a similarity conversion analysis is performed on the compliance feature vector and the state feature vector to obtain a comprehensive difference degree; The priority score of each difference dimension is calculated by combining the weight corresponding to the difference dimension and the comprehensive difference degree, and different priorities are divided according to the priority score; The component ID, difference type, and comprehensive difference degree of the difference dimension are obtained and integrated to generate an anchor point state difference set.

[0010] Furthermore, the similarity transformation analysis is performed as follows: Calculate the cosine similarity between the state feature vector and the compliance feature vector; The cosine similarity is transformed by complementary mapping to obtain the comprehensive difference.

[0011] Furthermore, the target migration execution baseline is obtained as follows: Based on the target node determined by the dynamic mapping relationship and the difference content recorded by the anchor point state difference set, the Trusted Cloud Native Level Management Unit derives the specific service migration execution step sequence, i.e. the target migration execution benchmark.

[0012] Furthermore, the dynamic mapping relationship is established as follows: The Trusted Cloud Native Level Management Unit collects service load characteristics by combining static analysis and dynamic monitoring, and combines static requirements with dynamic indicators to form a multi-dimensional feature group of service load. Obtain the infrastructure resource pool and quantify the hardware capabilities of each schedulable node in the infrastructure resource pool into a resource supply vector; The multi-dimensional feature set is transformed into a security requirement vector. Based on the anchor point state difference set, the Trusted Cloud Native Level Management Unit selects all candidate nodes in the resource supply vector that meet the minimum hardware requirements of the target level and are schedulable. The Euclidean distance algorithm is used to calculate the Euclidean distance between the resource supply vector and the security demand vector of the service load for each candidate node. The candidate node with the smallest Euclidean distance is determined as the optimal matching target, i.e., the target node, thus realizing the establishment of a dynamic mapping relationship between hardware resources and security load.

[0013] Furthermore, the key execution points are obtained as follows: Based on the migration execution benchmark, the hardware anchor points are divided into core stages; Through the time-series data acquisition interface, resource scheduling time-series data and state transition progress data at each stage are collected in real time; Clustering algorithms are used to perform cluster analysis on the resource scheduling time series data and state transition progress data of each stage after processing. The time series nodes with the highest density in the cluster and the strongest correlation with the benchmark index are selected as the key execution points of each stage.

[0014] Furthermore, the execution verification is performed as follows: Extract similarity matching values ​​of all key execution points from the trust state sequence to form a temporal consistency feature vector; A reference consistency feature vector is formed based on the resource supply vector of the target node extracted in the dynamic mapping relationship, the security demand vector of the service load, and the optimal Euclidean distance value of the mapping matching; The timing consistency feature vector and the reference consistency feature vector are dimensionally aligned, and a weighted fusion algorithm is used to calculate an execution consistency index.

[0015] A trusted cloud native security level governance system comprises the following modules: A standard anchoring module: based on the core principles of cloud service security, a trusted cloud native security level calculation framework is established, and a hierarchical hardware anchoring standard for the cloud native environment is defined based on the level calculation framework; A policy matching module: based on the hierarchical standard, the trusted cloud native level management unit analyzes user demand and risk factors, automatically matches and forcibly configures corresponding hardware anchors and security policies; A remote verification module: the trusted cloud native level management unit verifies the integrity of the hardware anchor based on the hardware anchor and the security policy, and dynamically outputs a trusted level certificate and a trusted cloud unit level adjustment instruction based on the verification result; A difference analysis module: used to obtain the trusted cloud unit level adjustment instruction, and to perform differential analysis on the current hardware running baseline of the target trusted cloud unit and the target level compliance features to obtain an anchor state difference set; A reference determination module: used to collect service load features, construct a dynamic mapping relationship between hardware resources and security load based on the anchor state difference set, and derive the migration execution reference of the target node in the switching process according to the dynamic mapping relationship; A trust analysis module: based on the migration execution reference, the resource scheduling and state migration in the hardware anchor switching process are tracked and processed in real time to obtain key execution points; the trust anchoring result of the key execution points is verified, and a trust state sequence is constructed based on the trust anchoring result; A verification execution module: based on the trust state sequence and the dynamic mapping relationship, execution verification is performed to obtain an execution consistency index and determine whether the acceptance expectation is met; if yes, a security level delivery confirmation instruction is output; if not, a rollback mechanism is triggered.

[0016] The beneficial effects of the present application are as follows: 1. Construct a trusted cloud native security level calculation framework based on the security core principles of cloud services, divide TCDUN1-5 five levels of trusted cloud unit levels with step-by-step enhancement, and define the corresponding hardware trusted security function module anchoring standards of each level; at the same time, through the trusted cloud native level management unit, analyze the user business demand and risk elements, match the corresponding level of hardware anchor point and security policy, which is conducive to the binding of security level and hardware capability; at the same time, combined with the hardware anchoring requirements of different levels, adapt to the differentiated needs of lightweight deployment of low sensitivity business and hardware level isolation of high security level business.

[0017] 2. Based on the trusted cloud unit level adjustment instruction, parse the dynamic trusted report to establish a component-anchor-level association list, collect hardware running baseline data and extract target level compliance features, identify difference dimensions through dimension-by-dimension feature matching, combine weight distribution and numerical quantization to obtain state feature vector, and then calculate the cosine similarity and perform complementary mapping conversion to obtain the comprehensive difference degree, which is conducive to positioning the adaptation difference between the current hardware running baseline and the target level; at the same time, combined with the comprehensive difference degree, the difference dimension priority is divided to form an anchor state difference set, which improves the efficiency of security level adaptation.

[0018] 3. Collect service load characteristics in a combination of static analysis and dynamic monitoring to form a multi-dimensional feature group, which is conducive to capturing the comprehensive demand of services on computing, security and network resources; at the same time, the multi-dimensional feature group is converted into a security demand vector, which is matched and calculated with the resource supply vector of the infrastructure node to improve the adaptation accuracy of hardware resources and service security demand; based on the anchor state difference set, the candidate nodes that meet the requirements of the target level are selected, the matching distance between the resource supply vector and the security demand vector is calculated, and the optimal target node is determined, which is conducive to excluding hardware nodes that do not meet the security level requirements; at the same time, the dynamic mapping relationship between hardware resources and security load is constructed to optimize the rationality of resource scheduling and balance the resource utilization rate and security demand.

[0019] 4. For each key execution point, check and migrate the matching degree of the execution reference threshold value, integrate information in time sequence to construct a trust state sequence, which is conducive to recording the trust evolution trajectory of the switching process; at the same time, the trust state has the characteristics of traceability and checkability, providing accurate and structured data sources for the evaluation of subsequent execution effect. From the trust state sequence, the similar matching value of the key execution point is extracted to form a time sequence consistency feature vector, and the resource supply and security demand related data are extracted from the dynamic mapping relationship to form a reference consistency feature vector, and the execution consistency index is calculated, which is conducive to objectively quantifying the execution effect of hardware anchor point switching; at the same time, combined with the acceptance expected threshold value set by different trusted cloud unit levels, the quantitative evaluation of the security level switching effect is realized, and the credibility of the acceptance decision is improved. BRIEF DESCRIPTION OF DRAWINGS

[0020] The application will be further described below with reference to the drawings.

[0021] Figure 1 is a flowchart of a trusted hierarchical and level adjustment instruction generation in a trusted cloud native security level governance method according to an embodiment of the application; Figure 2 is a flowchart of anchor adjustment analysis in a trusted cloud native security level governance method according to an embodiment of the application; Figure 3 is a functional module diagram of a trusted cloud native security level governance system according to an embodiment of the application. DETAILED DESCRIPTION

[0022] In order to make the technical means, creative features, purposes and effects of the application easy to understand, the application will be further described below with reference to the specific embodiments.

[0023] Embodiment 1: Please refer to Figure 1 The trusted cloud native security level governance method according to an embodiment of the application includes the following steps: S1, based on the core principles of cloud service security, establish a level calculation framework of trusted cloud native security, and define hierarchical hardware anchoring standards for the cloud native environment based on the level calculation framework; The process of establishing a level calculation framework of trusted cloud native security and defining hierarchical hardware anchoring standards for the cloud native environment based on the level calculation framework is as follows: In some embodiments, the trusted cloud native security level calculation framework (TCDN) divides the cloud native environment into five levels of trusted cloud unit (TCDUNx) with increasing levels of trust, and clearly requires cloud native hardware trusted security function modules (CNHTSFM) that must be anchored in each level; It should be noted that CNHTSFM, as the root of trust, is integrated into the physical basis at different levels of the cloud native technology stack; the higher the TCDUNx level, the higher the dependence on the underlying hardware and the higher the security capability requirement; The skilled person in the art defines and configures different levels of TCDUNx according to the TCDN framework as follows: TCDUN1-2: running in an environment without any hardware trusted capability, its security is completely defined and implemented by software; TCDUN3: the underlying infrastructure must be equipped with and enabled with standard TPM (trusted platform module) or TCCM; It should be noted that the TCDUN3 level requires that the startup process of all critical components (such as Kubernetes nodes) must go through trusted measurement and remote attestation to ensure the basic integrity of the infrastructure; TCDUN4: The infrastructure where it is located must be equipped and enabled with TEE (Trusted Execution Environment, such as Intel SGX / TDX components); It should be noted that the TCDUN4 level requires that the core application load must be encapsulated in an encrypted container to run, ensuring that runtime memory data is invisible to cloud service providers; TCDUN5: The infrastructure where it is located is equipped with the highest level of TEE, HSM (Hardware Security Module) and DPU (Data Processing Unit); It should be noted that the TCDUN5 level requires full-process hardware anchoring: core computing is protected by TEE, static data keys are protected by HSM, and network policy execution is offloaded by DPU.

[0024] Among them, TCDUN1-2 has no hardware anchoring, TCDUN3 is basic hardware anchoring, TCDUN4 is confidential computing hardware anchoring, and TCDUN5 is full-process hardware anchoring; S2, based on the grading standard, the trusted cloud native level management unit analyzes user demand and risk elements, and automatically matches and forcibly configures the corresponding hardware anchor and security policy; Among them, the trusted cloud native level management unit analyzes user demand and risk elements, and automatically matches and forcibly configures the corresponding hardware anchor and security policy in the following way: In some embodiments, TCDNMU receives the business requirements declared by the developer in the deployment file, and clearly defines the data security level of the core data asset, namely DSLx; For example, for an enterprise internal OA service, it processes medium sensitive business data, and defines the data security level as DSLx=3; for a financial transaction product, its core transaction data is defined as DSL4; The trusted cloud native level management unit deduces the minimum environment level that carries the core data asset based on the data security level of the core data asset; The trusted cloud native level management unit automatically plans the deployment conditions based on the minimum environment level; For example, the way to plan the deployment conditions is: For TCDUN3 level (such as OA service): the infrastructure layer must be deployed on a virtual machine enabled with TPM2.0; the identity layer must be forced multi-factor authentication (MFA); For TCDUN4 level (such as financial transaction product): the infrastructure layer must be deployed on a bare metal server equipped with a hardware encryption card; the core logic must run in a TEE confidential container; network communication must be forced to implement two-way TLS (mTLS) encryption.

[0025] S3, the trusted cloud native level management unit performs real-time remote attestation verification of the integrity of the hardware anchor based on the hardware anchor and the security policy, and dynamically outputs a trusted level certificate and a trusted cloud unit level adjustment instruction based on the verification result; The manner of performing real-time remote attestation verification of the integrity of the hardware anchor, and dynamically outputting a trusted level certificate and a trusted cloud unit level adjustment instruction based on the verification result is as follows: S301, the trusted cloud native level management unit collects static information of each trusted cloud unit component inside; Preferably, the trusted cloud native level management unit (TCDNMU) manages and records static information of each component (TCDNGSM) contained in each trusted cloud unit (TCDUN) under its jurisdiction inside; The static information includes inherent security level at design time (for example, TCDNGSM4 calculated based on SBEC), hardware anchor type (such as Intel TDX) relied on, and current dynamic level initial value. S302, if the trusted cloud native level management unit receives a request for a current security level certificate of the component, active verification of the static information is triggered; Preferably, the manner of active verification is as follows: Verification strategy one: through remote attestation (initiating a challenge to the physical node, verifying the PCRs (platform configuration register) value of the TPM or TEE environment in real time, confirming that the hardware environment is healthy and has not been tampered with; Verification strategy two: querying the real-time running configuration of the component, and verifying whether it has enforced a strategy matching the level (such as the mTLS strategy required by TCDUN4); S303, based on the active verification result, a dynamic trusted report containing a trusted level certificate and a level adjustment instruction are outputted; Preferably, if the active verification result is valid, that is, verification strategy one and verification strategy two are both satisfied, and a dynamic trusted report is generated; The dynamic trusted report includes: timestamp, component ID (number), verification result of whether the hardware obtained through active verification matches the level and the strategy, and finally confirmed dynamic trusted level. If the active verification result does not satisfy verification strategy one and verification strategy two at the same time, that is, the active verification result is invalid, a level adjustment instruction of the trusted cloud unit is triggered, and a corresponding dynamic trusted report is outputted.

[0026] Embodiment 2: please refer to Figure 2 As shown in the figure, the trusted cloud native security level governance method described in the embodiment of the application further includes the following steps: S4, obtain a trusted cloud unit level adjustment instruction, and perform differential analysis on the current hardware running baseline of the target trusted cloud unit and the target level compliance characteristics to obtain an anchor point state difference set; The manner in which the current hardware running baseline of the target trusted cloud unit and the target level compliance characteristics are differentially analyzed based on the obtained trusted cloud unit level adjustment instruction is as follows: Preferably, based on the received trusted cloud unit level adjustment instruction, the component ID of the trusted cloud unit, the dynamic level of the component, and the hardware anchor point type (such as TPM or TEE) associated with the component in the dynamic trust report are analyzed to establish an association list containing the component, the anchor point, and the level; Based on the component ID and the anchor point type in the association list, the hardware running baseline data of the target trusted cloud unit is collected through a trusted cloud hardware abstraction layer interface; The anchor standard of the TCDUNx hierarchical hardware in the trusted cloud native security level calculation framework (TCDN) is obtained, and the compliance level characteristics corresponding to the target level are extracted; Based on the compliance level characteristics, a level compliance characteristic library is constructed; The current hardware running baseline is processed dimension by dimension using a feature matching algorithm to identify difference dimensions and non-difference dimensions; By way of example, the manner in which the difference dimensions are identified by performing the dimension-by-dimension verification processing is as follows: Hardware configuration difference: the current anchor point type or model does not meet the requirements of the target level (for example, TCDUN4 requires TEE, but the actual hardware is TPM); Functional parameter difference: the hardware anchor point performance parameter does not meet the target threshold (for example, the HSM encryption strength is less than 256 bits); Policy execution difference: the security policy is not enabled as required by the target level (for example, mTLS is not enabled); The difference dimensions and the non-difference dimensions are assigned different weights, and the verification results of the difference dimensions and the non-difference dimensions are numerically quantized; By way of example, the manner in which the numerical quantization is performed is as follows: the difference dimensions are quantized to 0, and the non-difference dimensions are quantized to 1; The manner in which the different weights are assigned is as follows: the hardware configuration difference weight w1 is set to 0.2, 0.2, 0.4, 0.5, and 0.6 for TCDUN1-TCDUN5 levels, respectively; The functional parameter difference weight w2 is set to 0.1, 0.1, 0.3, 0.3, and 0.25 for TCDUN1-TCDUN5 levels, respectively; The policy execution difference weight w3 is set to 0.2, 0.2, 0.3, 0.2, and 0.15 for TCDUN1-TCDUN5 levels, respectively; The numerical quantization results of the difference dimensions and the non-difference dimensions are multiplied by the corresponding weights to obtain a state feature vector; Construct a compliance feature vector and calculate the cosine similarity between the state feature vector and the compliance feature vector; The cosine similarity is transformed by complementary mapping to obtain the comprehensive difference. For example, the compliance feature vector is constructed as follows: using the hardware configuration, functional parameters, and policy execution difference weights (0.5, 0.3, 0.2) of the target level (such as TCDUN4) as components, combined with the quantified value of the ideal compliance state (1), the compliance feature vector is obtained. , ; If the target level is level four, and the current hardware configuration is different, the functional parameters are compliant, and the policy execution is compliant, the state feature vector is (0×0.5, 1×0.3, 1×0.2), i.e. (0, 0.3, 0.2), the compliance feature vector is (0.5, 0.3, 0.2), the cosine similarity is about 0.587, and after complementary mapping transformation (i.e. 1-0.587), the comprehensive difference is 0.413; Then, the priority score for each difference dimension is calculated by combining the weights corresponding to the difference dimensions with the overall difference degree, and different priorities are assigned according to the priority scores; Integrate component ID, difference type, and overall difference degree across the difference dimensions to generate an anchor point state difference set; S5. Collect service load characteristics, combine anchor point status difference set to construct dynamic mapping relationship between hardware resources and security load, and deduce the migration execution benchmark of target node during the switching process based on dynamic mapping relationship. The method for collecting service load characteristics is as follows: Preferably, the Trusted Cloud Native Level Management Unit collects service load characteristics through a combination of static analysis and dynamic monitoring; It should be noted that static parsing refers to parsing the deployment description file of a cloud-native application and extracting the resource specifications declared therein. The resource specifications include the number of CPU cores, memory capacity, persistent storage type, and network bandwidth threshold. Dynamic monitoring refers to continuously collecting performance metrics and behavioral patterns of service instances during runtime through programmable probes deployed in the host kernel. Performance metrics include CPU utilization, memory usage, and network throughput, while behavioral patterns include call records to hardware security modules or trusted execution environment components. The Trusted Cloud Native Level Management Unit combines the above static requirements with dynamic indicators to form a multi-dimensional feature set of service load, which is used to characterize the comprehensive requirements of service load for hardware computing resources, hardware security resources and network resources. Exemplarily, for a payment processing service, its multi-dimensional feature group can be described as: static declaration requires 4 central processor cores, 16 gigabytes of memory; dynamic monitoring shows that the central processor utilization rate reaches 80% during its peak period of business, and 200 invocation requests per second are initiated to the trusted execution environment; The manner of constructing the dynamic mapping relationship between the hardware resources and the security load in combination with the anchor state difference set is: Preferably, the trusted cloud native level management unit performs matching calculation between the hardware resources and the security requirements based on the anchor state difference set and the multi-dimensional feature group of the service load, to construct the dynamic mapping relationship from the load to the specific hardware node. The manner of performing matching calculation between the hardware resources and the security requirements is: The infrastructure resource pool is acquired, and the hardware capability of each schedulable node in the infrastructure resource pool is quantified as a resource supply vector. It should be noted that the dimensions of the resource supply vector include computing performance, supported hardware anchor types and their security capability levels, and the hardware anchor types include trusted platform modules, trusted execution environments, hardware security modules, and data processing units, and the hardware security capability levels correspond to the definitions in the trusted cloud native security level calculation framework. The multi-dimensional feature group is converted into a security requirement vector, and the security requirement vector is composed of the data security level of the load, the performance sensitivity, and the dependence on specific hardware anchors. The trusted cloud native level management unit screens all candidate nodes in the resource supply vector that meet the minimum hardware requirements of the target level according to the anchor state difference set. The Euclidean distance algorithm is used to calculate the Euclidean distance between the resource supply vector of each candidate node and the security requirement vector of the service load. The candidate node with the smallest Euclidean distance is determined as the optimal matching target, i.e., the target node, to achieve the establishment of the dynamic mapping relationship between the hardware resources and the security load. Exemplarily, if the anchor state difference set requires that the target environment must have a hardware security module that meets the TCDUN5 level requirement, the Euclidean distance algorithm excludes all nodes in the resource pool whose hardware security module capability does not meet this requirement, and then calculates the distance in the remaining candidate nodes to select the optimal one. The manner of deriving the target migration execution benchmark in the switching process according to the dynamic mapping relationship is: Preferably, the trusted cloud native level management unit derives the specific service migration execution step sequence, i.e., the target migration execution benchmark, according to the target node determined by the dynamic mapping relationship and the difference content recorded by the anchor state difference set. It should be noted that the derivation process is based on a predefined migration decision logic, and the input parameters of the migration decision logic include the distance value of the mapping match, the service interruption tolerance time in the multi-dimensional feature group, and the comprehensive difference degree calculated from the anchor point state difference set.

[0027] Embodiment 3: see Figure 2 As shown in the figure, the trusted cloud native security level governance system according to the embodiment of the application comprises the following steps: S6, based on the migration execution benchmark, the resource scheduling and state migration in the hardware anchor point switching process are tracked in real time to obtain the key execution point; the trust anchoring result of the key execution point is verified, and a trust state sequence is constructed based on the trust anchoring result; Among them, the way to track the resource scheduling and state migration in the hardware anchor point switching process based on the migration execution benchmark to obtain the key execution point is: According to the maximum allowed load threshold, the hardware resource reservation ratio, the upper limit of the migration execution time length and the security compliance verification node in the migration execution benchmark, the hardware anchor point switching whole process is divided into five core stages of resource pre-allocation, hardware anchor point initialization, security policy loading, application migration adaptation and trust chain closed loop; Through the time sequence data acquisition interface, the resource scheduling time sequence data (including: CPU frequency, memory frequency, network bandwidth allocation value, allocation timestamp) and state migration progress data (including hardware startup progress, policy loading completion rate, application migration success rate) of each stage are collected in real time; The collected resource scheduling time sequence data and state migration progress data are processed by adopting the 3σ principle to eliminate abnormal values (such as sudden resource allocation peak value and progress jump caused by data transmission error code), and the missing data is completed by linear interpolation method; The resource scheduling time sequence data and state migration progress data of each core stage after processing are analyzed by adopting K-means time sequence clustering algorithm, the time sequence node with the highest cluster density and the strongest correlation with the benchmark index is selected as the key execution point of each stage; For example, the resource allocation completion time is selected as the key execution point of the resource pre-allocation stage through clustering analysis, which corresponds to the hardware resource reservation ratio index in the benchmark; the TPM / TEE startup completion time and the key injection success time are selected as the key execution points of the hardware anchor point initialization stage, which correspond to the security compliance verification node in the benchmark; Among them, the way to verify the trust anchoring result of the key execution point and construct the trust state sequence based on the trust anchoring result is: Preferably, for each key execution point, the corresponding collected resource scheduling time sequence data and state migration progress data (such as network bandwidth allocation value, hardware startup state and application migration success rate) are standardized by adopting min-max algorithm; The cosine similarity algorithm is used to calculate the similarity matching value of the standardized resource scheduling time sequence data, state transition progress data and transition execution reference threshold value; The similarity matching value is compared with the preset similarity matching threshold value. If the similarity matching value is higher than or equal to the preset similarity matching threshold value, it is determined that the anchoring of the key execution point is valid, otherwise it is determined to be invalid; If it is determined to be valid, the phase identifier, timestamp, corresponding reference index, verification result and core verification data are integrated according to the time sequence of the key execution point to construct a structured trust state sequence; S7, based on the trust state sequence and the dynamic mapping relationship, the execution verification is carried out, the execution consistency index is obtained, and it is determined whether the acceptance expectation is met. If it is met, the safety level delivery confirmation instruction is output. If it is not met, the rollback mechanism is triggered; Among them, the execution verification based on the trust state sequence and the dynamic mapping relationship is: The similarity matching values of all key execution points are extracted from the trust state sequence to form a time sequence consistency feature vector; The resource supply vector of the target node, the security demand vector of the service load, and the optimal Euclidean distance value of the mapping matching in the dynamic mapping relationship of hardware resources-security load are extracted to form a reference consistency feature vector; The time sequence consistency feature vector and the reference consistency feature vector are dimensionally aligned, and the weighted fusion algorithm is used to calculate the execution consistency index: Among them, the weighted fusion algorithm is used to calculate the execution consistency index: S701, calculate the arithmetic mean of the similarity matching values of all key execution points in the consistency feature vector as the execution fit degree of the key link in the hardware anchor switching process; S702, first, the optimal Euclidean distance value is processed in reverse standardization, and the optimal Euclidean distance value after reverse standardization is taken as the average value of the cosine similarity of the resource supply vector and the security demand vector, as the basic adaptation value of resource adaptation; Preferably, the reverse standardization processing is performed by the formula: The optimal Euclidean distance value is , wherein is the maximum possible Euclidean distance matched by the resource pool node, and is preset to 1; S703, different weights are assigned to the execution fit degree and the basic adaptation value, and the weighted fusion calculation is performed based on the weights and the corresponding execution fit degree and basic adaptation value to obtain the execution consistency index; Preferably, the time sequence consistency weight is 0.6, and the reference consistency weight accounts for 0.4; The timing consistency weight is multiplied by the execution fit degree, the benchmark consistency weight is multiplied by the basic adaptation value, and the two multiplication results are summed to obtain an execution consistency index; Based on different levels of trusted cloud units, different acceptance expectation threshold values corresponding to the execution consistency index are set; If the execution consistency index is higher than or equal to the corresponding acceptance expectation threshold value, it is determined that the acceptance expectation is met, and the trusted cloud native level management unit outputs a security level delivery confirmation instruction to synchronously update the final level state in the dynamic trusted report; If the execution consistency index is lower than the corresponding acceptance expectation threshold value, it is determined that the acceptance expectation is not met, and a rollback mechanism is triggered immediately to roll back to the original running state before the hardware anchor switching, and the rollback reason (such as a similar matching value of a key execution point not meeting a standard, a benchmark mapping matching degree being insufficient) and related data are recorded to generate a rollback analysis report.

[0028] Embodiment 4: As shown in Figure 3 A trusted cloud native security level governance system includes the following modules: Standard anchoring module: Based on the core principles of cloud service security, a level calculation framework of trusted cloud native security is established, and a hierarchical hardware anchoring standard of the cloud native environment is defined based on the level calculation framework; Strategy matching module: Based on the hierarchical standard, the trusted cloud native level management unit analyzes user demand and risk elements, automatically matches and forcibly configures corresponding hardware anchors and security strategies; Remote verification module: Based on the hardware anchors and security strategies, the trusted cloud native level management unit performs real-time remote proof to verify the integrity of the hardware anchors, and dynamically outputs a trusted level proof and a trusted cloud unit level adjustment instruction based on the verification result; Difference analysis module: used to obtain the trusted cloud unit level adjustment instruction, and to perform differential analysis on the current hardware running baseline of the target trusted cloud unit and the target level compliance characteristics to obtain an anchor state difference set; Benchmark determination module: used to collect service load characteristics, construct a dynamic mapping relationship between hardware resources and security load based on the anchor state difference set, and derive a migration execution benchmark of the target node in the switching process according to the dynamic mapping relationship; Trust analysis module: based on the migration execution benchmark, real-time tracking processing is performed on the resource scheduling and state migration in the hardware anchor switching process to obtain a key execution point; the trust anchoring result of the key execution point is verified, and a trust state sequence is constructed based on the trust anchoring result; Verification execution module: based on the trust state sequence and the dynamic mapping relationship, execution verification is performed to obtain an execution consistency index and determine whether the acceptance expectation is met; if yes, a security level delivery confirmation instruction is output; if not, a rollback mechanism is triggered.

[0029] The foregoing merely illustrates the principles of the application and application of its more prominent features. Those skilled in the art will appreciate that the application is not limited to the embodiments described and illustrated and that many changes and modifications will occur to them without departing from the spirit and scope of the present application. The present application is therefore not to be limited to the exact details shown and described but only by the scope of the appended claims.

Claims

1. A method for governing a security level of a trusted cloud native, characterized in that: The method comprises the following steps: Obtain the trusted cloud unit level adjustment instruction, and perform differential analysis on the current hardware running baseline of the target trusted cloud unit and the target level compliance characteristics to obtain an anchor state difference set; Collect service load characteristics, construct a dynamic mapping relationship between hardware resources and security load based on the anchor state difference set, and derive a migration execution benchmark of the target node in the switching process according to the dynamic mapping relationship; Based on the migration execution benchmark, real-time tracking processing is performed on resource scheduling and state migration in the hardware anchor switching process to obtain a key execution point; Verify the trust anchoring result of the key execution point, and construct a trust state sequence based on the trust anchoring result; Perform execution verification based on the trust state sequence and the dynamic mapping relationship to obtain an execution consistency index and determine whether the acceptance expectation is met; if yes, output a security level delivery confirmation instruction; if not, trigger a rollback mechanism.

2. The trusted cloud native security level governance method of claim 1, wherein: The trusted cloud unit level adjustment instruction is obtained in the following manner: Based on the core principle of cloud service security, a level calculation framework of trusted cloud native security is established, and a hierarchical hardware anchoring standard of the cloud native environment is defined based on the level calculation framework; Based on the hierarchical standard, the trusted cloud native level management unit analyzes user demand and risk elements, automatically matches and forcibly configures corresponding hardware anchors and security policies; Based on the hardware anchors and security policies, the trusted cloud native level management unit performs real-time remote proof to verify the integrity of the hardware anchors, and dynamically outputs a trusted level proof and a trusted cloud unit level adjustment instruction based on the verification result.

3. The trusted cloud native security level governance method of claim 2, wherein: The trusted level proof and the trusted cloud unit level adjustment instruction are output in the following manner: The trusted cloud native level management unit collects static information of each trusted cloud unit component; If the trusted cloud native level management unit receives a current security level request of a proof component, it triggers active verification of the static information; Based on the active verification result, a dynamic trusted report containing the trusted level proof and the level adjustment instruction are output.

4. The trusted cloud-native security level governance method of claim 1, wherein: The differential analysis is performed in the following manner: Based on the received trusted cloud unit level adjustment instruction, hardware running baseline data of the target trusted cloud unit is collected; Obtain the anchoring standard of the hierarchical hardware in the trusted cloud native security level calculation framework, extract the compliance level characteristics corresponding to the target level, and construct a level compliance characteristic library; Use a feature matching algorithm to perform dimension-by-dimension inspection and processing on the current hardware running baseline, identify difference dimensions and non-difference dimensions; Multiply the numerical quantization results of the difference dimensions and the non-difference dimensions with the corresponding weights to obtain a state feature vector; Construct a compliance feature vector, and perform similarity conversion analysis on the compliance feature vector and the state feature vector to obtain a comprehensive difference degree; Calculate the priority score of each difference dimension based on the weight corresponding to the difference dimension and the comprehensive difference degree, and divide different priorities according to the priority score; Obtain and integrate the component ID, difference type, and comprehensive difference degree of the difference dimension to generate an anchor state difference set.

5. The trusted cloud native security level governance method of claim 4, wherein: The similarity conversion analysis is performed in the following manner: Calculate the cosine similarity of the state feature vector and the compliance feature vector; Complementary mapping conversion is performed on the cosine similarity to obtain a comprehensive difference degree.

6. The trusted cloud native security level governance method of claim 1, wherein: The target migration execution benchmark is obtained in the following manner: The trusted cloud native level management unit derives a specific service migration execution step sequence, i.e., a migration execution benchmark of the target, according to the target node determined by the dynamic mapping relationship and the difference content recorded by the anchor state difference set.

7. The trusted cloud native security level governance method of claim 6, wherein: The manner of establishing the dynamic mapping relationship is: The trusted cloud native level management unit collects service load characteristics by combining static analysis with dynamic monitoring, combines static requirements with dynamic indicators, and forms a multi-dimensional feature group of the service load; An infrastructure resource pool is obtained, and the hardware capacity of each schedulable node in the infrastructure resource pool is quantified into a resource supply vector; The multi-dimensional feature group is converted into a security demand vector, and the trusted cloud native level management unit screens all candidate nodes of the schedulable node that meet the minimum hardware requirements of the target level from the resource supply vector according to the anchor state difference set; The Euclidean distance algorithm is used to calculate the Euclidean distance between the resource supply vector of each candidate node and the security demand vector of the service load; The candidate node with the smallest Euclidean distance is determined as the optimal matching target, i.e., the target node, and the dynamic mapping relationship of the hardware resource to the security load is established.

8. The trusted cloud-native security level governance method of claim 1, wherein: The manner of obtaining the key execution point is: The hardware anchor is divided into core stages based on the migration execution benchmark; Resource scheduling time sequence data and state migration progress data of each stage are collected in real time through a time sequence data collection interface; A clustering algorithm is used to cluster and analyze the processed resource scheduling time sequence data and state migration progress data of each stage, and the time sequence node with the highest intra-cluster density and the strongest correlation with the benchmark indicator is screened out as the key execution point of each stage. 9.The trusted cloud native security level governance method of claim 1, wherein: The manner of performing the execution verification is: The similarity matching values of all key execution points are extracted from the trust state sequence to form a time sequence consistency feature vector; The resource supply vector of the target node, the security demand vector of the service load, and the optimal Euclidean distance value of the mapping matching are extracted from the dynamic mapping relationship to form a benchmark consistency feature vector; The time sequence consistency feature vector and the benchmark consistency feature vector are dimensionally aligned, and a weighted fusion algorithm is used to calculate an execution consistency index.

10. A trusted cloud native security level governance system for implementing the method of any one of claims 1-9, characterized in that: The following modules are included: Standard anchoring module: based on the core principles of cloud service security, a level calculation framework of trusted cloud native security is established, and a hierarchical hardware anchoring standard of the cloud native environment is defined based on the level calculation framework; Strategy matching module: based on the hierarchical standard, the trusted cloud native level management unit analyzes user demand and risk elements, automatically matches and forcibly configures corresponding hardware anchors and security policies; Remote verification module: the trusted cloud native level management unit verifies the integrity of the hardware anchor based on the hardware anchor and the security policy in real time, and dynamically outputs a trusted level certificate and a trusted cloud unit level adjustment instruction based on the verification result; Difference analysis module: used to obtain the trusted cloud unit level adjustment instruction, and to perform differential analysis on the current hardware running baseline of the target trusted cloud unit and the target level compliance features to obtain an anchor state difference set; The benchmark determination module is configured to collect service load characteristics, construct a dynamic mapping relationship between hardware resources and security load in combination with the set of anchor point state differences, and derive a migration execution benchmark of the target node in the switching process according to the dynamic mapping relationship. The trust analysis module is configured to track and process resource scheduling and state migration in the hardware anchor switching process in real time based on the migration execution benchmark, to obtain key execution points. The trust anchoring result of the key execution points is checked, and a trust state sequence is constructed based on the trust anchoring result. The execution module is configured to perform execution checking based on the trust state sequence and the dynamic mapping relationship, to obtain an execution consistency index and determine whether the execution meets the acceptance expectation; if yes, a safety level delivery confirmation instruction is output; if not, a rollback mechanism is triggered.

Images