A trusted cloud native security level governance system and method

Abstract

The application belongs to the technical field of cloud service security, and provides a trusted cloud native security level management system and method, which comprises the following steps: a trusted cloud native security level calculation framework is established, and a trusted cloud unit hierarchical hardware anchoring standard is defined; user demand and risk elements are analyzed, and hardware anchor points and security strategies are automatically matched; the integrity of the hardware anchor points is verified based on real-time remote proof, and dynamic level proof and adjustment instructions are output; an anchor point state difference set is obtained through differential analysis, a dynamic mapping relationship is constructed in combination with service load characteristics, and a migration execution benchmark is deduced; key execution points of hardware anchor point switching are tracked, a trust state sequence is constructed, acceptance results are determined, and delivery instructions or a rollback mechanism is triggered; the system is first used for the above method; and the application is beneficial to the stable operation of business loads with different security level requirements in a compliant hardware environment, and improves the controllability and reliability of cloud service security.

Description

Technical Field

[0001] This invention belongs to the field of cloud service security technology, specifically a trusted cloud-native security level governance system and method. Background Technology

[0002] With the deepening development of the digital economy, cloud-native technologies, with their core advantages of elastic scaling and agile deployment, have become critical infrastructure supporting the operation of various business systems. However, the security governance of current cloud-native environments faces core technical bottlenecks: the lack of a standardized closed-loop mechanism for adapting security levels to hardware capabilities leads to a disconnect between security requirements and actual protection effects, making it difficult to coordinate compliance assurance and business continuity maintenance.

[0003] The existing technology grading standard system is lacking, and hardware anchoring lacks a unified basis. Cloud-native environments encompass diverse scenarios, ranging from lightweight businesses to highly sensitive financial-grade businesses. Different scenarios have significantly different security protection requirements, but existing technologies have not yet established a hardware trust capability grading standard that is precisely tied to the business security level. Traditional security governance often relies on software-defined protection strategies, neglecting the security support role of underlying hardware anchors, or simply adapting hardware resources. It has not formed a tiered governance framework from basic security to end-to-end hardware anchoring, resulting in low-sensitivity businesses bearing redundant security costs, while high-security-requirement businesses lack rigid protection support such as hardware-level isolation and encryption.

[0004] Therefore, this invention provides a trusted cloud-native security level governance system and method. 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:

[0007] A trusted cloud-native security level governance method includes the following steps:

[0008] Obtain the Trusted Cloud Unit Level Adjustment Instruction, perform a differential analysis on the current hardware operating baseline of the target Trusted Cloud Unit and the target level compliance characteristics, and obtain the anchor point state difference set;

[0009] Collect service load characteristics, combine anchor point status difference sets to construct a dynamic mapping relationship between hardware resources and security load, and deduce the migration execution benchmark of the target node during the switching process based on the dynamic mapping relationship;

[0010] Based on the migration execution benchmark, resource scheduling and state transition during hardware anchor switching are tracked and processed in real time to obtain key execution points; the trust anchoring results of key execution points are verified, and a trust state sequence is constructed based on the trust anchoring results;

[0011] Execution verification is performed based on the trust state sequence and dynamic mapping relationship to obtain the execution consistency index and determine whether the acceptance expectation is met; if it is met, a security level delivery confirmation instruction is output; if it is not met, a rollback mechanism is triggered.

[0012] Furthermore, the method for obtaining the trusted cloud unit level adjustment instruction is as follows:

[0013] Based on the core principles of cloud service security, a trusted cloud-native security graded computing framework is established, and a graded hardware anchoring standard for cloud-native environments is defined based on the graded computing framework.

[0014] Based on the grading standard, the Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, and automatically matches and forces the configuration of corresponding hardware anchors and security policies.

[0015] The Trusted Cloud Native Level Management Unit performs real-time remote verification of the integrity of hardware anchors based on hardware anchors and security policies, and dynamically outputs trust level certificates and trusted cloud unit level adjustment instructions based on the verification results.

[0016] Furthermore, the method for outputting the trust level proof and the trust cloud unit level adjustment instruction is as follows:

[0017] The Trusted Cloud Native Level Management Unit collects static information from each Trusted Cloud Unit component within it;

[0018] If the Trusted Cloud Native Level Management Unit receives a request to prove the current security level of the component, it will trigger active verification of the static information.

[0019] Based on the active verification results, a dynamic trust report containing trust level proof and a level adjustment instruction are output.

[0020] Furthermore, the differential analysis is conducted as follows:

[0021] Based on the received trusted cloud unit level adjustment instruction, collect the hardware operation baseline data of the target trusted cloud unit;

[0022] Obtain the anchoring standards for graded hardware in the trusted cloud-native security level calculation framework, extract the compliance level features corresponding to the target level, and construct a graded compliance feature library;

[0023] A feature matching algorithm is used to examine the current hardware operating baseline dimension by dimension to identify the difference and non-difference dimensions.

[0024] The numerical quantization results of the differential and non-differential dimensions are multiplied with their corresponding weights to obtain the state feature vector;

[0025] Construct a compliance feature vector, perform a similarity transformation analysis on the compliance feature vector and the status feature vector, and obtain a comprehensive degree of difference.

[0026] 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.

[0027] Obtain and integrate the component ID, difference type, and comprehensive difference degree of the difference dimension to generate the anchor point state difference set.

[0028] Furthermore, the similarity transformation analysis is performed as follows:

[0029] Calculate the cosine similarity between the state feature vector and the compliance feature vector;

[0030] The cosine similarity is transformed by complementary mapping to obtain the comprehensive difference.

[0031] Furthermore, the target migration execution baseline is obtained as follows:

[0032] 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.

[0033] Furthermore, the dynamic mapping relationship is established as follows:

[0034] 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.

[0035] Obtain the infrastructure resource pool and quantify the hardware capabilities of each schedulable node in the infrastructure resource pool into a resource supply vector;

[0036] 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.

[0037] 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.

[0038] 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.

[0039] Furthermore, the key execution points are obtained as follows:

[0040] Based on the migration execution benchmark, the hardware anchor points are divided into core stages;

[0041] 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;

[0042] 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.

[0043] Furthermore, the execution verification is performed as follows:

[0044] Extract similarity matching values ​​of all key execution points from the trust state sequence to form a temporal consistency feature vector;

[0045] Based on the dynamic mapping relationship, the resource supply vector, the security requirement vector of the service load, and the optimal Euclidean distance value of the mapping match of the target node are extracted to form the benchmark consistency feature vector.

[0046] The temporal consistency feature vector and the benchmark consistency feature vector are dimensionally aligned, and the execution consistency index is calculated using a weighted fusion algorithm.

[0047] A trusted cloud-native security level governance system includes the following modules:

[0048] Standard Anchoring Module: Based on the core principles of cloud service security, it establishes a trusted cloud-native security graded computing framework, and defines graded hardware anchoring standards for cloud-native environments based on the graded computing framework;

[0049] Policy matching module: Based on the hierarchical standard, the Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, automatically matches and forces the configuration of corresponding hardware anchors and security policies;

[0050] Remote Verification Module: The Trusted Cloud Native Level Management Unit performs real-time remote verification of the integrity of hardware anchors based on hardware anchors and security policies, and dynamically outputs trust level certificates and trusted cloud unit level adjustment instructions based on the verification results.

[0051] Difference Analysis Module: Used to obtain Trusted Cloud Unit Level Adjustment Instructions, perform difference analysis on the current hardware operating baseline of the target Trusted Cloud Unit and the target level compliance characteristics, and obtain the anchor point status difference set;

[0052] The baseline determination module is used to collect service load characteristics, combine the anchor point state difference set to construct a dynamic mapping relationship between hardware resources and security load, and deduce the migration execution baseline of the target node during the handover process based on the dynamic mapping relationship.

[0053] Trust Analysis Module: Based on the migration execution benchmark, it performs real-time tracking and processing of resource scheduling and state migration during the hardware anchor switching process to obtain key execution points; it verifies the trust anchoring results of key execution points and constructs a trust state sequence based on the trust anchoring results;

[0054] Verification Execution Module: Based on the trust state sequence and dynamic mapping relationship, it performs execution verification to obtain the execution consistency index and determine whether the acceptance expectations are met; if they are met, it outputs a security level delivery confirmation instruction; if they are not met, it triggers a rollback mechanism.

[0055] The beneficial effects of this invention are as follows:

[0056] 1. Based on the core principles of cloud service security, a trusted cloud-native security level computing framework is constructed, dividing the trusted cloud unit into five progressively enhanced levels (TCDUN1-5), and defining the corresponding hardware trusted security function module anchoring standards for each level. Simultaneously, the trusted cloud-native level management unit analyzes user business needs and risk factors, matching the corresponding hardware anchors and security policies, which facilitates the binding of security levels with hardware capabilities. Furthermore, by combining the hardware anchoring requirements of different levels, it adapts to the differentiated needs of lightweight deployment for low-sensitivity services and hardware-level isolation for high-security-level services.

[0057] 2. Based on the Trusted Cloud Unit Level Adjustment Instruction, the dynamic Trusted Report is parsed to establish a component-anchor-level association list. Hardware operating baseline data is collected and target level compliance features are extracted. Difference dimensions are identified through dimensional feature matching. State feature vectors are obtained by combining weight allocation and numerical quantization. Then, cosine similarity is calculated and complementary mapping transformation is performed to obtain the comprehensive difference degree, which is helpful in locating the adaptation difference between the current hardware operating baseline and the target level. At the same time, the priority of difference dimensions is divided by the comprehensive difference degree to form an anchor point state difference set, which improves the efficiency of security level adaptation.

[0058] 3. By combining static analysis with dynamic monitoring, service load characteristics are collected to form a multi-dimensional feature set of service load, which is beneficial for capturing the comprehensive needs of services for computing, security, and network resources. At the same time, the multi-dimensional feature set is transformed into a security requirement vector and matched with the resource supply vector of infrastructure nodes to improve the accuracy of hardware resource and service security requirements. Based on the anchor point state difference set, candidate nodes that meet the target level requirements are screened, and the matching distance between the resource supply vector and the security requirement vector is calculated to determine the optimal target node, which helps to exclude hardware nodes that do not meet the security level requirements. At the same time, a dynamic mapping relationship between hardware resources and security load is constructed to optimize the rationality of resource scheduling and balance resource utilization and security requirements.

[0059] 4. For each key execution point, verify the matching degree between the verification and migration execution baseline thresholds, and integrate information in chronological order to construct a trust state sequence. This facilitates a complete record of the trust evolution trajectory during the switching process and ensures that the trust state has traceable and verifiable characteristics, providing a precise and structured data source for subsequent performance evaluation. Extract similarity matching values ​​of key execution points from the trust state sequence to form a temporal consistency feature vector, and extract resource supply and security requirement-related data from the dynamic mapping relationship to form a baseline consistency feature vector. Calculating the execution consistency index helps to objectively quantify the performance of hardware anchor switching. Furthermore, by setting acceptance expectation thresholds based on different trusted cloud unit levels, a quantitative evaluation of the security level switching effect can be achieved, enhancing the credibility of the acceptance judgment. Attached Figure Description

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

[0061] Figure 1 This is a flowchart illustrating the generation of trust level and level adjustment instructions in a trusted cloud-native security level governance method according to an embodiment of the present invention.

[0062] Figure 2 This is a flowchart of the anchor point adjustment analysis in a trusted cloud-native security level governance method according to an embodiment of the present invention;

[0063] Figure 3 This is a functional module diagram of a trusted cloud-native security level governance system according to an embodiment of the present invention. Detailed Implementation

[0064] 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.

[0065] Example 1: Please refer to Figure 1 As shown in the figure, a trusted cloud-native security level governance method according to an embodiment of the present invention includes the following steps:

[0066] S1. Based on the core principles of cloud service security, establish a trusted cloud-native security graded computing framework, and define graded hardware anchoring standards for cloud-native environments based on the graded computing framework;

[0067] Among them, the process of establishing a trusted cloud-native security graded computing framework and defining graded hardware anchoring standards for cloud-native environments based on the graded computing framework is as follows:

[0068] In some embodiments, the Trusted Cloud Native Security Level Computing Framework (TCDN) divides the cloud native environment into five progressively enhanced Trusted Cloud Unit Levels (TCDUNx) and sets forth specific requirements for the Trusted Cloud Native Hardware Security Function Modules (CNHTSFM) that must be anchored to each level.

[0069] It should be noted that CNHTSFM, as a root of trust, is the physical foundation integrated into different layers of the cloud-native technology stack; the higher the TCDUNx level, the greater the dependence on the underlying hardware and the higher the security requirements.

[0070] Based on the TCDN framework, those skilled in the art define and configure different levels of TCDUNx as follows:

[0071] TCDUN1-2: It runs in an environment without any hardware trust capabilities, and its security is entirely defined and implemented by software;

[0072] TCDUN3: The infrastructure in which it resides must be equipped with and have a standard TPM (Trusted Platform Module) or TCCM enabled;

[0073] It should be noted that the TCDUN3 level requires that the startup process of all critical components (such as Kubernetes nodes) must undergo trust measurement and remote verification to ensure the basic integrity of the infrastructure.

[0074] TCDUN4: The infrastructure on which it resides must be equipped with and have TEE (Trusted Execution Environment, such as Intel SGX / TDX components) enabled.

[0075] It should be noted that TCDUN4 requires core application workloads to be encapsulated in encrypted containers to ensure that runtime memory data is not visible to cloud service providers.

[0076] TCDUN5: The infrastructure it is located in is equipped with the highest level of TEE, HSM (Hardware Security Module), and DPU (Data Processing Unit).

[0077] It should be noted that 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.

[0078] Among them, TCDUN1-2 have no hardware anchoring, TCDUN3 has basic hardware anchoring, TCDUN4 has confidential computing hardware anchoring, and TCDUN5 has full-process hardware anchoring.

[0079] S2. Based on the hierarchical standard, the Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, and automatically matches and forces the configuration of corresponding hardware anchors and security policies.

[0080] The Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, and automatically matches and forces the configuration of corresponding hardware anchors and security policies in the following way:

[0081] In some embodiments, TCDNMU receives business requirements declared by developers in the deployment file and clarifies the data security level of core data assets, namely DSLx;

[0082] For example, for an enterprise's internal OA service that processes moderately sensitive business data, the data security level is defined as DSLx=3; for a financial transaction product, its core transaction data is defined as DSL4.

[0083] The Trusted Cloud Native Level Management Unit derives the minimum environmental level for supporting the data security of core data assets based on the data security level of core data assets.

[0084] Automatically plan deployment conditions based on the lowest environment level trusted cloud-native level management unit;

[0085] For example, the deployment conditions can be planned as follows:

[0086] For TCDUN3 level (such as OA services): the infrastructure layer must be deployed on a virtual machine with TPM2.0 enabled; the identity layer must enforce multi-factor authentication (MFA).

[0087] For TCDUN4 level (such as financial trading products): 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; and network communication must be subject to mandatory two-way TLS (mTLS) encryption.

[0088] S3, the Trusted Cloud Native Level Management Unit performs real-time remote verification of the integrity of hardware anchors based on hardware anchors and security policies, and dynamically outputs trust level certificates and trusted cloud unit level adjustment instructions based on the verification results.

[0089] The method for performing real-time remote verification of the integrity of hardware anchor points, and dynamically outputting trust level certificates and trust cloud unit level adjustment instructions based on the verification results, is as follows:

[0090] S301, The Trusted Cloud Native Level Management Unit collects static information of each Trusted Cloud Unit component within it;

[0091] Preferably, the Trusted Cloud Native Grade Management Unit (TCDNMU) manages and records the static information of each component (TCDNGSM) contained in each Trusted Cloud Unit (TCDUN) under its jurisdiction.

[0092] The static information includes: the inherent security level at design time (e.g., TCDNGSM4 calculated based on SBEC), the type of hardware anchor it depends on (e.g., Intel TDX), and the initial value of the current dynamic level.

[0093] S302. If the Trusted Cloud Native Level Management Unit receives a request to prove the current security level of the component, it will trigger active verification of static information.

[0094] The preferred method for active verification is:

[0095] Verification Strategy 1: Remote verification (challenging physical nodes to verify the PCRs (Platform Configuration Registers) values ​​of the TPM or TEE environment in real time, confirming that the hardware environment is healthy and has not been tampered with).

[0096] Verification Strategy 2: Query the real-time running configuration of the component to verify whether it enforces a policy that matches the level (such as the mTLS policy required by TCDUN4).

[0097] S303. Based on the active verification results, output a dynamic trust report containing trust level proof and a level adjustment instruction;

[0098] Preferably, if the result of the active verification is valid, that is, both verification strategy one and verification strategy two are satisfied, a dynamic trust report is generated.

[0099] The dynamic trust report includes: timestamp, component ID (number), verification results of the process and strategy for determining whether the hardware matches the level through proactive verification, and the final confirmed dynamic trust level.

[0100] If the proactive verification result does not simultaneously satisfy both verification strategy one and verification strategy two, i.e. the proactive verification result is invalid, the trusted cloud unit's level adjustment instruction will be triggered, and the corresponding dynamic trusted report will be output.

[0101] Example 2: Please refer to Figure 2 As shown in the embodiment of the present invention, a trusted cloud-native security level governance method further includes the following steps:

[0102] S4. Obtain the Trusted Cloud Unit Level Adjustment Instruction, perform a differential analysis on the current hardware operating baseline of the target Trusted Cloud Unit and the target level compliance characteristics, and obtain the anchor point state difference set.

[0103] The method for obtaining the Trusted Cloud Unit level adjustment instruction and performing a differential analysis on the current hardware operating baseline and target level compliance characteristics of the target Trusted Cloud Unit is as follows:

[0104] Preferably, based on the received Trusted Cloud Unit level adjustment instruction, the component ID, dynamic level of the component, and hardware anchor type (such as TPM or TEE) associated with the component in the dynamic Trusted Report are parsed to establish an association list containing components, anchors, and levels.

[0105] Based on the component ID and plotting point type in the associated list, the hardware operation baseline data of the target trusted cloud unit is collected through the trusted cloud hardware abstraction layer interface;

[0106] Obtain the anchoring standard of TCDUNx graded hardware in the Trusted Cloud Native Security Level Computing Framework (TCDN), and extract the compliance level features corresponding to the target level;

[0107] Construct a compliance feature library based on compliance level characteristics;

[0108] A feature matching algorithm is used to examine the current hardware operating baseline dimension by dimension to identify the difference and non-difference dimensions.

[0109] For example, the method for performing dimension-by-dimensional verification to identify differing dimensions is as follows:

[0110] Hardware configuration differences: The current anchor point type or model does not match the target level requirements (e.g., TCDUN4 requires TEE, but it is actually TPM).

[0111] Functional parameter differences: Hardware anchor performance parameters did not reach the target threshold (e.g., HSM encryption strength is less than 256 bits).

[0112] Policy enforcement discrepancies: Security policies are not enforced at the target level (e.g., mTLS is not enabled);

[0113] Different weights are assigned to the differential and non-differential dimensions, and the verification results of the differential and non-differential dimensions are numerically quantified.

[0114] For example, the numerical quantization method is to quantize the difference dimension as 0 and the non-difference dimension as 1;

[0115] The method for assigning different weights is as follows: Hardware configuration difference weight w1: TCDUN1-TCDUN5 levels are set to 0.2, 0.2, 0.4, 0.5, and 0.6 respectively;

[0116] Functional parameter difference weight w2: TCDUN1-TCDUN5 levels are set to 0.1, 0.1, 0.3, 0.3, and 0.25 respectively;

[0117] The strategy execution difference weight w3 is set to 0.2, 0.2, 0.3, 0.2, and 0.15 for TCDUN1-TCDUN5 respectively.

[0118] The numerical quantization results of the differential and non-differential dimensions are multiplied with their corresponding weights to obtain the state feature vector;

[0119] Construct a compliance feature vector and calculate the cosine similarity between the state feature vector and the compliance feature vector;

[0120] The cosine similarity is transformed by complementary mapping to obtain the comprehensive difference.

[0121] 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. , ;

[0122] 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;

[0123] 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;

[0124] Integrate component ID, difference type, and overall difference degree across the difference dimensions to generate an anchor point state difference set;

[0125] 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.

[0126] The method for collecting service load characteristics is as follows:

[0127] Preferably, the Trusted Cloud Native Level Management Unit collects service load characteristics through a combination of static analysis and dynamic monitoring;

[0128] 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.

[0129] 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.

[0130] 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.

[0131] For example, a payment processing service can be described as having the following multidimensional feature set: static declaration requires 4 CPU cores and 16 gigabytes of memory; dynamic monitoring shows that its CPU utilization reaches 80% during peak business hours and it initiates 200 call requests to the trusted execution environment per second.

[0132] The method for constructing the dynamic mapping relationship between hardware resources and security loads by combining the anchor point state difference set is as follows:

[0133] Preferably, the Trusted Cloud Native Level Management Unit performs matching calculations between hardware resources and security requirements based on the anchor point state difference set and the multi-dimensional feature set of service load, so as to build a dynamic mapping relationship from load to specific hardware nodes;

[0134] The method for matching hardware resources with security requirements is as follows:

[0135] Obtain the infrastructure resource pool and quantify the hardware capabilities of each schedulable node in the infrastructure resource pool into a resource supply vector;

[0136] It should be noted that the dimensions of the resource supply vector include computing performance, supported hardware anchor types and their security capability levels. Hardware anchor types include trusted platform modules, trusted execution environments, hardware security modules, and data processing units. The hardware security capability levels correspond to the definitions in the trusted cloud-native security level computing framework.

[0137] The multidimensional feature set is transformed into a security requirement vector, which consists of the data security level of the load, performance sensitivity, and dependence on specific hardware anchors.

[0138] The Trusted Cloud Native Level Management Unit selects all candidate nodes from the resource supply vector that meet the minimum hardware requirements of the target level based on the anchor point status difference set.

[0139] 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.

[0140] 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.

[0141] For example, if the anchor point state difference set requires the target environment to have hardware security modules that meet the TCDUN5 level requirements, then the Euclidean distance algorithm excludes all nodes in the resource pool whose hardware security module capabilities do not meet this requirement, and then calculates the distance among the remaining candidate nodes to select the best one.

[0142] The method for deriving the target migration execution benchmark during the switching process based on the dynamic mapping relationship is as follows:

[0143] Preferably, the Trusted Cloud Native Level Management Unit derives the specific service migration execution step sequence, i.e. the target migration execution benchmark, based on the target node determined by the dynamic mapping relationship and the difference content recorded in the anchor point state difference set;

[0144] It should be noted that the derivation process is based on a predefined migration decision logic. The input parameters of the migration decision logic include the distance value of the mapping match, the business interruption tolerance time in the multi-dimensional feature group, and the comprehensive difference degree calculated by the anchor state difference set.

[0145] Example 3: Please refer to Figure 2 As shown in the embodiment of the present invention, a trusted cloud-native security level governance system includes the following steps:

[0146] S6. Based on the migration execution benchmark, perform real-time tracking and processing of resource scheduling and state migration during the hardware anchor point switching process to obtain key execution points; verify the trust anchoring results of key execution points, and construct a trust state sequence based on the trust anchoring results;

[0147] Among them, based on the migration execution benchmark, the resource scheduling and state transition during the hardware anchor point switching process are tracked and processed in real time to obtain the key execution points in the following way:

[0148] Based on the maximum allowable load threshold, hardware resource reservation ratio, migration execution time limit and security compliance verification nodes in the migration execution benchmark, the entire hardware anchor switching process is divided into five core stages: resource pre-allocation, hardware anchor initialization, security policy loading, application migration adaptation, and trust chain closed loop.

[0149] Through the time-series data acquisition interface, real-time resource scheduling time-series data (including CPU frequency, memory frequency, network bandwidth allocation value, allocation timestamp) and state transition progress data (including hardware startup progress, policy loading completion rate, and application migration success rate) are collected at each stage.

[0150] The collected resource scheduling time-series data and state transition progress data are processed using the 3σ principle to remove outliers (such as sudden resource allocation peaks or progress jumps caused by data transmission errors), and missing data is supplemented using linear interpolation.

[0151] The K-means time-series clustering algorithm was used to perform cluster analysis on the resource scheduling time-series data and state transition progress data of each core stage after processing. The time-series nodes with the highest density in the cluster and the strongest correlation with the benchmark index were selected as the key execution points of each stage.

[0152] For example, in the resource pre-allocation phase, cluster analysis is used to select the time when resource allocation is completed as the key execution point, corresponding to the hardware resource reservation ratio index in the benchmark; in the hardware anchor initialization phase, the time when TPM / TEE startup is completed and the time when key injection is successful are selected, corresponding to the security compliance verification node in the benchmark.

[0153] The method for verifying the trust anchoring results of key execution points and constructing a trust state sequence based on the trust anchoring results is as follows:

[0154] Preferably, for each key execution point, the corresponding collection resource scheduling time series data and state transition progress data (such as network bandwidth allocation value, hardware startup status, and application migration success rate) are extracted and standardized using the min-max algorithm;

[0155] The cosine similarity algorithm is used to calculate the similarity matching value between the standardized resource scheduling time series data, state transition progress data and the migration execution benchmark threshold;

[0156] The similarity matching value is compared with the preset similarity matching threshold. If the similarity matching value is higher than or equal to the preset similarity matching threshold, the anchoring of the key execution point is determined to be valid; otherwise, it is determined to be invalid.

[0157] If the determination is valid, then according to the time sequence of the key execution points, the stage identifier, timestamp, corresponding benchmark indicators, verification results and core verification data are integrated to construct a structured trust state sequence.

[0158] S7. Perform execution verification based on the trust state sequence and dynamic mapping relationship to obtain the execution consistency index and determine whether the acceptance expectation is met; if it is met, output the security level delivery confirmation instruction; if it is not met, trigger the rollback mechanism.

[0159] The execution verification method based on the trust state sequence and dynamic mapping relationship is as follows:

[0160] Extract similarity matching values ​​of all key execution points from the trust state sequence to form a temporal consistency feature vector;

[0161] Extract 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 match from the dynamic mapping relationship of hardware resources and security load to form a benchmark consistency feature vector.

[0162] The temporal consistency feature vector and the baseline consistency feature vector are dimensionally aligned, and a weighted fusion algorithm is used to calculate the execution consistency index.

[0163] The method for calculating the execution consistency index using the weighted fusion algorithm is as follows:

[0164] S701. Calculate the arithmetic mean of the similarity matching values ​​of all key execution points in the consistency feature vector, and use it as the execution fit of key links in the hardware anchor switching process;

[0165] S702. First, perform reverse standardization on the optimal Euclidean distance value. Then, take the average of the cosine similarity between the optimal Euclidean distance value after reverse standardization and the resource supply vector and security demand vector, and use it as the basic adaptation value for resource adaptation.

[0166] Preferably, by formula: Perform reverse standardization. The optimal Euclidean distance value is given by: The maximum possible Euclidean distance for matching resource pool nodes, preset to 1;

[0167] S703. Assign different weights to the execution fit and the basic adaptation value, and perform a weighted fusion calculation based on the weights and the corresponding execution fit and basic adaptation values ​​to obtain the execution consistency index.

[0168] Preferably, the timing consistency weight is 0.6, and the baseline consistency weight is 0.4.

[0169] Multiply the timing consistency weight by the execution fit, multiply the baseline consistency weight by the baseline fit value, and sum the two results to obtain the execution consistency index.

[0170] Based on different trusted cloud unit levels, different acceptance expectation thresholds are set for different execution consistency indices.

[0171] If the execution consistency index is higher than or equal to the corresponding acceptance expectation threshold, the acceptance expectation is determined to be met, and the Trusted Cloud Native Level Management Unit outputs a security level delivery confirmation instruction and synchronously updates the final level status in the dynamic trust report.

[0172] If the consistency coefficient is lower than the corresponding acceptance expectation threshold, it is determined that the acceptance expectation is not met, and the rollback mechanism is immediately triggered to roll back to the original running state before the hardware anchor point switch. At the same time, the rollback reason (such as the similarity matching value of the key execution point is not up to standard, or the baseline mapping matching degree is insufficient) and related data are recorded, and a rollback analysis report is generated.

[0173] Example 4: Figure 3 As shown, a trusted cloud-native security level governance system includes the following modules:

[0174] Standard Anchoring Module: Based on the core principles of cloud service security, it establishes a trusted cloud-native security graded computing framework, and defines graded hardware anchoring standards for cloud-native environments based on the graded computing framework;

[0175] Policy matching module: Based on the hierarchical standard, the Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, automatically matches and forces the configuration of corresponding hardware anchors and security policies;

[0176] Remote Verification Module: The Trusted Cloud Native Level Management Unit performs real-time remote verification of the integrity of hardware anchors based on hardware anchors and security policies, and dynamically outputs trust level certificates and trusted cloud unit level adjustment instructions based on the verification results.

[0177] Difference Analysis Module: Used to obtain Trusted Cloud Unit Level Adjustment Instructions, perform difference analysis on the current hardware operating baseline of the target Trusted Cloud Unit and the target level compliance characteristics, and obtain the anchor point status difference set;

[0178] The baseline determination module is used to collect service load characteristics, combine the anchor point state difference set to construct a dynamic mapping relationship between hardware resources and security load, and deduce the migration execution baseline of the target node during the handover process based on the dynamic mapping relationship.

[0179] Trust Analysis Module: Based on the migration execution benchmark, it performs real-time tracking and processing of resource scheduling and state migration during the hardware anchor switching process to obtain key execution points; it verifies the trust anchoring results of key execution points and constructs a trust state sequence based on the trust anchoring results;

[0180] Verification Execution Module: Based on the trust state sequence and dynamic mapping relationship, it performs execution verification to obtain the execution consistency index and determine whether the acceptance expectations are met; if they are met, it outputs a security level delivery confirmation instruction; if they are not met, it triggers a rollback mechanism.

[0181] 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 method for governing a security level of a trusted cloud native, characterized in that: Includes the following steps: Obtain the Trusted Cloud Unit Level Adjustment Instruction, perform a differential analysis on the current hardware operating baseline of the target Trusted Cloud Unit and the target level compliance characteristics, and obtain the anchor point state difference set; Collect service load characteristics, construct a dynamic mapping relationship between hardware resources and security load by combining the anchor point status difference set, and derive the migration execution benchmark of the target node during the switching process based on the dynamic mapping relationship; Based on the migration execution benchmark, the resource scheduling and state migration during the hardware anchor point switching process are tracked and processed in real time to obtain the key execution points; Verify the trust anchoring results at key execution points, and construct a trust state sequence based on the trust anchoring results; Execution verification is performed based on the trust state sequence and dynamic mapping relationship to obtain the execution consistency index and determine whether the acceptance expectation is met; if it is met, a security level delivery confirmation instruction is output; if it is not met, a rollback mechanism is triggered.

2. The trusted cloud native security level governance method of claim 1, wherein: The method for obtaining the Trusted Cloud Unit Level Adjustment Instruction is as follows: Based on the core principles of cloud service security, a trusted cloud-native security graded computing framework is established, and a graded hardware anchoring standard for cloud-native environments is defined based on the graded computing framework. Based on the hierarchical hardware anchoring standard, the Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, and automatically matches and forces the configuration of corresponding hardware anchors and security policies. The Trusted Cloud Native Level Management Unit performs real-time remote verification of the integrity of hardware anchors based on hardware anchors and security policies, and dynamically outputs trust level certificates and trusted cloud unit level adjustment instructions based on the verification results.

3. The method of claim 2, wherein: The method for outputting the trust level proof and the trust cloud unit level adjustment instruction is as follows: The Trusted Cloud Native Level Management Unit collects static information from each Trusted Cloud Unit component within it; If the Trusted Cloud Native Level Management Unit receives a request to prove the current security level of the component, it will trigger active verification of the static information. Based on the active verification results, a dynamic trust report containing trust level proof and a level adjustment instruction are output.

4. The trusted cloud-native security level governance method of claim 1, wherein: The method for conducting the aforementioned differentiation analysis is as follows: Based on the received trusted cloud unit level adjustment instruction, collect the hardware operation baseline data of the target trusted cloud unit; Obtain the anchoring standards for graded hardware in the trusted cloud-native security level calculation framework, extract the compliance level features corresponding to the target level, and construct a graded compliance feature library; A feature matching algorithm is used to examine the current hardware operating baseline dimension by dimension to identify the difference and non-difference dimensions. The numerical quantization results of the differential and non-differential dimensions are multiplied with their corresponding weights to obtain the state feature vector; Construct a compliance feature vector, perform a similarity transformation analysis on the compliance feature vector and the status feature vector, and obtain a comprehensive degree of difference. 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. Obtain and integrate the component ID, difference type, and comprehensive difference degree of the difference dimension to generate the anchor point state difference set.

5. The trusted cloud native security level governance method of claim 4, wherein: 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.

6. The trusted cloud-native security level governance method of claim 1, wherein: The method for obtaining the migration execution baseline is 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, that is, the migration execution benchmark of the target node.

7. The trusted cloud native security level governance method of claim 6, wherein: 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.

8. The trusted cloud-native security level governance method of claim 1, wherein: The method for obtaining the key execution point is 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. 9.The trusted cloud native security level governance method of claim 1, wherein: 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; Based on the dynamic mapping relationship, the resource supply vector, the security requirement vector of the service load, and the optimal Euclidean distance value of the mapping match of the target node are extracted to form the benchmark consistency feature vector. The temporal consistency feature vector and the benchmark consistency feature vector are dimensionally aligned, and the execution consistency index is calculated using a weighted fusion algorithm.

10. A trusted cloud-native security level governance system, used to implement the trusted cloud-native security level governance method according to any one of claims 1-9, characterized in that: Includes the following modules: Standard Anchoring Module: Based on the core principles of cloud service security, it establishes a trusted cloud-native security graded computing framework, and defines graded hardware anchoring standards for cloud-native environments based on the graded computing framework; Policy matching module: Based on the hierarchical hardware anchoring standard, the Trusted Cloud Native Level Management Unit analyzes user needs and risk factors, automatically matches and forces the configuration of corresponding hardware anchors and security policies; Remote Verification Module: The Trusted Cloud Native Level Management Unit performs real-time remote verification of the integrity of hardware anchors based on hardware anchors and security policies, and dynamically outputs trust level certificates and trusted cloud unit level adjustment instructions based on the verification results. Difference Analysis Module: Used to obtain Trusted Cloud Unit Level Adjustment Instructions, perform difference analysis on the current hardware operating baseline of the target Trusted Cloud Unit and the target level compliance characteristics, and obtain the anchor point status difference set; The baseline determination module is used to collect service load characteristics, combine the anchor point status difference set to construct a dynamic mapping relationship between hardware resources and security load, and derive the migration execution baseline of the target node during the switching process based on the dynamic mapping relationship. Trust Analysis Module: Based on the migration execution benchmark, it performs real-time tracking and processing of resource scheduling and state migration during the hardware anchor switching process to obtain key execution points; Verify the trust anchoring results at key execution points, and construct a trust state sequence based on the trust anchoring results; Verification Execution Module: Based on the trust state sequence and dynamic mapping relationship, it performs execution verification to obtain the execution consistency index and determine whether the acceptance expectations are met; if they are met, it outputs a security level delivery confirmation instruction; if they are not met, it triggers a rollback mechanism.

Images