Intelligent management and control system for data security circulation in multi-cloud environment

Abstract

The invention relates to the technical field of data management and control, and discloses an intelligent management and control system for safe data circulation in a multi-cloud environment, which is used for solving the problem of token replay during data management and control, and comprises the following steps of: uniformly accessing and registering resource nodes of a plurality of cloud platforms; the method comprises the following steps: acquiring identity identification information of each cloud node, establishing an access connection table, verifying the legality and integrity of a node certificate in an access process, performing legality authentication on a source node of an external access request, performing token use state analysis on a legal external access request, identifying and blocking a repeatedly used access token request, and accessing the external access request. According to the method, the external access request passing the token replay detection is obtained, the permission verification matching is performed on the external access request passing the token replay detection, and the external access request passing the permission verification is obtained through screening, so that the security of data circulation is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of data management and control technology, and more specifically to an intelligent management and control system for secure data flow in a multi-cloud environment. Background Technology

[0002] Multi-cloud environments, as a crucial infrastructure form for current enterprise-level information systems, are widely used in government, energy, finance, manufacturing, and transportation sectors. Data collaboration and business interoperability between different cloud platforms enable enterprises to flexibly allocate computing and storage resources according to business needs, achieving elastic system expansion and optimized resource allocation. With the expansion of multi-cloud deployments, the flow of cross-cloud data and frequent interaction of access requests have become commonplace. To achieve unified management and security protection in multi-cloud environments, intelligent management and control systems based on access control, identity authentication, and encrypted communication are gradually being applied to cross-cloud data exchange and business collaboration scenarios, enabling secure data sharing and controllable access across multiple platforms. By deploying access gateways and authentication interfaces on each cloud node, the system can monitor data access behavior in real time and aggregate relevant records to a central control platform, thereby building a secure management system for cross-cloud resources and providing security guarantees for business operations under a multi-cloud architecture.

[0003] Existing multi-cloud data management systems generally employ access authentication methods based on token verification and permission comparison. Specifically, when the system receives an external access request, it first verifies the legality and validity of the access token, and then determines permissions based on user roles or access policies to decide whether data access is permitted. This mechanism can effectively identify unauthorized access or illegal node requests in a normal environment, ensuring basic security of access control.

[0004] However, the above-mentioned technologies have at least the following technical problems: In real-world environments, attackers may illegally obtain legitimate access tokens through network eavesdropping, cache theft, or man-in-the-middle attacks, and then repeatedly use these tokens to initiate requests within their validity period, thereby bypassing traditional authorization verification mechanisms. Because existing systems only statically verify token validity and signatures, lacking dynamic detection of token usage sequence and repetitive behavior, they cannot identify such "token replay attacks." Once this occurs, attackers can repeatedly access sensitive data within the system's permitted security boundaries, leading to data breaches or unauthorized operations, severely impacting the security and trustworthiness of multi-cloud data flow. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, the present invention provides an intelligent management and control system for secure data flow in a multi-cloud environment, so as to solve the problems existing in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: An intelligent management and control system for secure data flow in a multi-cloud environment includes: a multi-cloud resource access module for unified access and registration of resource nodes from multiple cloud platforms, obtaining the identity information of each cloud node and establishing an access connection table, verifying the legality and integrity of node certificates during the access process to obtain a set of verified trusted resource nodes; a data access authentication module for authenticating the source node of external access requests based on the set of verified trusted resource nodes, filtering out legitimate external access requests; and an access token replay detection module for analyzing the token usage status of legitimate external access requests, identifying and blocking repeatedly used access token requests by detecting the timestamp difference and token serial number identifier in the access request, thus obtaining a pass token replay detection result. The system includes: a token replay detection module for detecting external access requests; a data security flow control module for controlling data flow between cloud platform resource nodes corresponding to external access requests that have passed security verification, encrypting cross-cloud data links using secure encryption algorithms, and establishing a hash verification mechanism between data sending and receiving nodes; and a log auditing and anomaly monitoring module for recording and analyzing the entire transmission process and access behavior after the data security flow control module completes data transmission, generating security alarm information when unauthorized access, repeated access, or abnormal traffic behavior is detected, and feeding back the abnormal characteristics to the data access authentication module.

[0007] Preferably, the steps for obtaining the verified trusted resource node set are as follows: Obtain node access information for each cloud platform, including a unique node identifier, platform type, access interface address, and security certificate file; verify the legitimacy of the cloud node identity information by calling the cloud platform's public key infrastructure service to check the issuing authority, certificate serial number, and expiration time of the security certificate file; when the issuing authority is detected in the trusted CA list and the certificate status is valid, the node is deemed legitimate and recorded as a legitimate node; otherwise, the node is marked as an illegitimate node and access is terminated; obtain the security certificate files of all legitimate nodes, verify the integrity of the security certificate files, and record nodes that pass the verification as complete nodes; construct a node information table and generate a trust identifier code, the node information table storing fields such as unique node identifier, platform type, certificate verification status, trust level, and last update time; for all complete nodes, generate a trust identifier code for each node and record its certificate verification status, trust level, and last update time in the node information table; summarize the node information of all complete nodes to form a verified trusted resource node set.

[0008] Preferably, the step of verifying the integrity of the security certificate file is as follows: calculate the hash digest value of the security certificate file and compare it with the original digest value stored in the registration stage; if the two are consistent, it proves that the certificate content has not been tampered with and the node is determined to have passed verification; if there is a difference, the node is determined to have failed verification, the node is marked as an "abnormal certificate node" and a security alarm is triggered.

[0009] Preferably, the steps for obtaining a legitimate external access request are as follows: receiving external access requests from various cloud nodes; each external access request includes a source node identifier, a request timestamp, an access token, and request type information; performing a trustworthiness comparison of the source node of the external access request based on a verified set of trusted resource nodes; if the source node trustworthiness comparison matches, then validating the access token of the external access request; if the access token is determined to be valid, then calculating the difference between the request timestamp in the external access request and the current time, and comparing the result with a preset time window threshold; if the difference exceeds the time window range, determining that the request is expired or abnormal and terminating the processing; if the timestamp is within the valid range, then determining that the request session verification is successful; if the request session verification is successful, then recording the access request as a legitimate external access request.

[0010] Preferably, the step of performing a trustworthiness comparison on the source node of the external access request is as follows: extract the source node identifier from the request data and match it with the unique node identifier in the set of trusted resource nodes; if the match is successful, it is determined that the access request comes from a trusted node and the source node trustworthiness comparison is successful; otherwise, it is determined that the source node trustworthiness comparison is unsuccessful, and the request is marked as an illegal request and the authentication process is terminated.

[0011] Preferably, the step of validating the access token for the external access request is as follows: call the token verification interface to verify the issuing authority, signature information, validity period and number of uses of the access token; if the signature verification passes and the token is within the validity period, the token is considered valid; otherwise, the request is marked as invalid and access is denied.

[0012] Preferably, the steps for identifying and blocking duplicate access token requests are as follows: extracting the token sequence number, token issuance timestamp, request reception time, and request identifier from a legitimate external access request; calculating the difference between the request reception time and the token issuance timestamp to obtain a timestamp difference value, representing the actual delay time of the access request; determining whether the current access request meets the time condition based on the timestamp difference value; if the current access request meets the time condition, recording the token sequence number set in the cache table; when a new access request enters, comparing whether its token sequence number exists in the set; if it exists, it is determined to be a duplicate request and enters the blocking process; if it does not exist, it is allowed to continue subsequent detection; comparing the current request identifier with the identifier of the token's most recent successful access record; if the two are equal, it is determined to be a replay behavior; if the two are not equal, the token replay detection is passed, and the identifier record of the token is updated; when a duplicate or abnormal access token is detected, blocking and feedback operations are performed; when a replay behavior is determined, a blocking instruction is generated, and the token sequence number and its source node identifier are written into the blacklist, while a blocking event record is returned to the data access authentication module.

[0013] Preferably, the step of determining whether the current access request meets the time condition based on the timestamp difference value is as follows: obtain the maximum allowed delay time; if the timestamp difference value is less than 0, it means that the request time is earlier than the issuance time and is determined to be a forged request; if the timestamp difference value is greater than the maximum allowed delay time, it means that the request exceeds the allowed time window and is determined to be an expired request and directly rejected; otherwise, it is determined that the current access request meets the time condition.

[0014] The technical effects and advantages of this invention are as follows: This system enables unified access and registration of resource nodes across multiple cloud platforms, obtains the identity information of each cloud node and establishes an access connection table. During the access process, it verifies the legality and integrity of node certificates, authenticates the source node of external access requests, analyzes the token usage status of legitimate external access requests, identifies and blocks reused access token requests, obtains external access requests that pass token replay detection, performs permission verification and matching on external access requests that pass token replay detection, and filters out external access requests that pass permission verification, effectively improving the security of data flow. Attached Figure Description

[0015] Figure 1 This is a structural diagram of an intelligent management and control system for secure data flow in a multi-cloud environment, provided as an embodiment of this application. Detailed Implementation

[0016] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. In addition, the forms of the various structures described in the following embodiments are merely illustrative. The intelligent management and control system for secure data flow in a multi-cloud environment involved in the present invention is not limited to the structures described in the following embodiments. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] This invention provides an intelligent management and control system for secure data flow in a multi-cloud environment, such as... Figure 1 As shown, the system includes: The multi-cloud resource access module is used to uniformly access and register resource nodes of multiple cloud platforms, obtain the identity information of each cloud node and establish an access connection table, and verify the legality and integrity of node certificates during the access process to obtain a set of verified trusted resource nodes, so as to ensure the security and controllability of the multi-cloud access environment. In this embodiment, it should be specifically explained that the steps for obtaining the verified set of trusted resource nodes are as follows: Obtain node access information from various cloud platforms. This information includes a unique node identifier, platform type, access interface address, and security certificate file. The unique node identifier distinguishes the resource source from different cloud platforms, and the security certificate file is used for subsequent legitimacy verification. This initial registration of multi-cloud resource nodes provides a data foundation for subsequent authentication and verification. The system verifies the legitimacy of cloud node identity information by invoking the cloud platform's public key infrastructure service to check the issuing authority, certificate serial number, and expiration date of the security certificate file. If the issuing authority is detected in the trusted CA list and the certificate is valid, the node is deemed legitimate and recorded as a legitimate node; otherwise, the node is marked as an illegitimate node and its access is terminated. The system ensures that it only accepts node requests from trusted cloud platforms, and that the identity information includes the node's unique identifier and the issuing information, serial number, and valid fields in the security certificate file. Public Key Infrastructure (PKI) provides functions such as issuance, distribution, verification, and revocation of digital certificates, serving as the fundamental security support system for trusted node identity verification during multi-cloud resource access. This service operates collaboratively through components such as Root Certificate Authorities (RootCA), Sub-Certificate Authorities (SubCA), and Registration Authorities (RA). It assigns a unique public and private key pair to each cloud node and generates a security certificate containing fields such as issuer information, validity period, purpose, and serial number. When a system accesses a node, it can verify the authenticity and validity of the node's certificate by calling the certificate verification interface provided by PKI, thereby ensuring the trustworthiness and traceability of the node's identity source.

[0018] The trusted CA list records the set of certificate authorities trusted by the current system and is a crucial basis for determining the legitimacy of cloud node certificates. This list includes information such as the name of each trusted authority, certificate fingerprint, issuing algorithm type, and trust level. When performing node legitimacy verification, the system compares the node certificate's issuing authority with the trusted CA list. If the issuing authority exists in the list and its trust status is valid, the node certificate is deemed trustworthy; if there is no match or the trust status has expired, it is considered to have been issued by an untrusted authority, thus denying node access. By setting up a trusted CA list, trust boundary control between different security domains in a multi-cloud environment can be achieved, preventing unauthorized nodes from accessing the system.

[0019] Obtain the security certificate files of all legitimate nodes, verify the integrity of the security certificate files, and record the nodes that pass the verification as complete nodes; Construct a node information table and generate a trust identifier code. The node information table is a system registration table used to record the node's running status. It stores fields such as the node's unique identifier, platform type, certificate verification status, trust level, and last update time. For all complete nodes, generate a trust identifier code for each node and record its certificate verification status, trust level and last update time in the node information table; The system aggregates node information from all complete nodes to form a verified set of trusted resource nodes. This set includes fields such as unique node identifier, access interface, trust identifier code, and certificate validity period, providing a list of trusted nodes for the data access authentication module. When a node's status is abnormal or its certificate expires, the system automatically removes it from the set, thus maintaining the real-time validity and security of the trusted set.

[0020] In this embodiment, it should be specifically explained that the steps for verifying the integrity of the security certificate file are as follows: The hash digest value of the security certificate file is calculated and compared with the original digest value stored during the registration phase. If they match, the certificate content has not been tampered with, and the node verification is deemed successful. If there is a discrepancy, the node verification is deemed unsuccessful, the node is marked as an "abnormal certificate node," and a security alarm is triggered. This step prevents the node certificate from being tampered with during transmission or storage.

[0021] It should be noted that calculating the hash digest value of the security certificate file is a prior art technique, and this embodiment will not provide a detailed description of its specific steps.

[0022] A hash digest is a fixed-length data characteristic value obtained by performing a one-way mapping operation on the content of a security certificate file using a hash algorithm. It is used to uniquely identify the content status of the certificate file. Hash algorithms can use international or national cryptographic standard algorithms such as SHA-256 and SM3. The operation result is highly sensitive to the input data; even if only one byte in the certificate file changes, the resulting hash digest value will be completely different.

[0023] The data access authentication module is used to authenticate the legitimacy of the source node of external access requests based on a verified set of trusted resource nodes, and to filter out legitimate external access requests. In this embodiment, it should be specifically explained that the steps for obtaining a legitimate external access request are as follows: Receive external access requests from various cloud nodes or user terminals; each external access request includes the source node identifier, request timestamp, access token, and request type information. The source node identifier of the external access request is used as the initial authentication basis to provide input conditions for subsequent legitimacy verification. Based on a verified set of trusted resource nodes, the trustworthiness of the source node of an external access request is compared. If the source node's trustworthiness is verified, the access token for the external access request will be validated. If the access token is deemed valid, the difference between the request timestamp in the external access request and the current time is calculated, and the result is compared with a preset time window threshold. If the difference exceeds the time window range, the request is deemed expired or abnormal, and processing is terminated. If the timestamp is within the valid range, the request session is deemed to have passed verification. The time window threshold is obtained through an adaptive thresholding method, which dynamically adjusts the time window threshold based on the timing characteristics of access requests and network latency during system operation. This method calculates the time difference distribution range by real-time monitoring of the average arrival interval of access requests, system processing latency, and network transmission jitter parameters within a certain period, and uses the central trend value or mean square deviation range of the distribution as the basis for threshold updates. When the system detects an increase in network latency or fluctuations in request frequency, the adaptive thresholding method automatically expands the time window threshold range to avoid misjudging normal requests as timeout requests; when the system is running stably and the access frequency is concentrated, the threshold range is automatically contracted to improve the sensitivity of anomaly detection. If the session verification is successful, the access request is recorded as a legitimate external access request, and the legitimate request is written into the authentication result table. An authentication identifier code is assigned to it for use in subsequent permission verification and policy matching modules, thereby enabling secure data transfer between multiple modules.

[0024] In this embodiment, it should be specifically explained that the step of performing a trustworthiness comparison on the source node of the external access request is as follows: Extract the source node identifier from the request data and match it with the unique node identifier in the set of trusted resource nodes. If the match is successful, it is determined that the access request comes from a trusted node and the source node trustworthiness comparison is successful. Otherwise, it is determined that the source node trustworthiness comparison is unsuccessful, and the request is marked as an illegal request and the authentication process is terminated.

[0025] In this embodiment, it should be specifically explained that the step of validating the access token for external access requests is as follows: Call the token verification interface to verify the issuing authority, signature information, validity period, and number of uses of the access token; if the signature verification passes and the token is within its validity period, the token is considered valid; otherwise, the request is marked as invalid and access is denied.

[0026] The access token replay detection module is used to analyze the token usage status of legitimate external access requests. By detecting the timestamp difference and token serial number identifier in the access request, it identifies and blocks repeated access token requests, and obtains external access requests that pass the token replay detection, so as to prevent legitimate tokens from being maliciously replayed. In this embodiment, it should be specifically explained that the step of identifying and blocking repeatedly used access token requests is as follows: Extract the token sequence number, token issuance timestamp, request receipt time, and request identifier from a valid external access request; The difference between the request receiving time and the token issuance timestamp is calculated to obtain the timestamp difference value, which represents the actual delay time of the access request. The current access request is determined based on the timestamp difference value. If the current access request meets the time condition, the token sequence number set is recorded in the cache table. When a new access request comes in, its token sequence number is compared with that of the set. If it exists, it is determined to be a duplicate request and enters the blocking process. If it does not exist, it is allowed to continue subsequent detection. This step achieves rapid identification of token usage status. The current request identifier is compared with the identifier of the token's most recent successful access record. If the two are equal, it is determined to be a replay behavior. If the two are not equal, the token replay detection is passed, and the token's identifier record is updated. This step prevents different requests from being impersonated as the same token. When a duplicate or abnormal access token is detected, blocking and feedback operations are performed. When the system determines the replay behavior, it generates a blocking instruction and writes the token serial number and its source node identifier into the blacklist. At the same time, it returns a blocking event record to the data access authentication module, including the detection time and blocking reason code. This step enables the immediate isolation and secure traceability of duplicate tokens.

[0027] In this embodiment, it should be specifically explained that the step of determining whether the current access request meets the time condition based on the timestamp difference value is as follows: Obtain the maximum allowed delay time. If the timestamp difference is less than 0, it means the request time is earlier than the issuance time and is judged as a forged request. If the timestamp difference is greater than the maximum allowed delay time, it means the request exceeds the allowed time window and is judged as an expired request and directly rejected. Otherwise, the current access request is judged to meet the time condition.

[0028] The permission verification and policy matching module is used to perform permission verification and matching on external access requests that pass the token replay detection, and filter out external access requests that pass the permission verification. It should be noted that performing permission verification and matching on external access requests that pass token replay detection and filtering out external access requests that pass permission verification is a prior art technique, and this embodiment will not describe its specific steps in detail.

[0029] The data security circulation control module is used to perform security control on the data circulation between resource nodes of the cloud platform corresponding to external access requests that have passed the permission verification. It encrypts the cross-cloud data link through a security encryption algorithm and establishes a hash verification mechanism between the data sending node and the data receiving node to prevent data from being tampered with or lost during transmission. It should be noted that encrypting the cross-cloud data link through a security encryption algorithm is an existing technology, and this embodiment does not describe its specific steps in detail. It should be noted that the data sending node and the data receiving node correspond to the resource nodes of different cloud platforms that have been registered in the multi-cloud resource access module.

[0030] The hash verification mechanism is used to verify the integrity of transmitted data between the data sending node and the data receiving node. Specifically, the data sending node calculates a hash digest value for each transmitted data packet and sends this digest value along with the data packet to the receiving node. After receiving the data packet, the receiving node recalculates the hash digest value of the received data and compares it with the attached digest value. When the comparison results match, it is determined that the data has not been tampered with or lost during cross-cloud transmission. When the comparison results do not match, a transmission anomaly handling process is triggered. This mechanism ensures the integrity and immutability of transmitted content in the cross-cloud data link, thereby improving the reliability of the data security flow control module. It should be noted that the hash verification mechanism is existing technology, and its specific steps are not described in detail in this embodiment.

[0031] The log auditing and anomaly monitoring module is used to record and analyze the entire transmission process and access behavior after the data security flow control module completes the data transmission. When unauthorized access, repeated access, or abnormal traffic behavior is detected, security alarm information is generated and the abnormal characteristics are fed back to the data access authentication module for dynamic correction of access rules or permission policies.

[0032] It should be noted that the various modules in the system interact through communication protocols: the resource access module uses authentication handshake messages with cloud nodes, the token replay detection module performs token verification through request-response messages, the permission policy module uses policy synchronization messages, the data circulation module uses encrypted link protocols for cross-node communication, and the log audit module reports anomalies through security alarm messages.

[0033] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

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

Claims

1. An intelligent management and control system for secure data flow in a multi-cloud environment, characterized in that, The system includes; The multi-cloud resource access module is used to uniformly access and register resource nodes of multiple cloud platforms, obtain the identity information of each cloud node and establish an access connection table, and verify the legality and integrity of node certificates during the access process to obtain a set of verified trusted resource nodes. The data access authentication module is used to authenticate the legitimacy of the source node of external access requests based on a verified set of trusted resource nodes, and to filter out legitimate external access requests. The access token replay detection module is used to analyze the token usage status of legitimate external access requests. By detecting the timestamp difference and token serial number identifier in the access request, it identifies and blocks repeated access token requests, thus obtaining external access requests that pass the token replay detection. The permission verification and policy matching module is used to perform permission verification and matching on external access requests that pass the token replay detection, and filter out external access requests that pass the permission verification. The data security circulation control module is used to control the data circulation between resource nodes of the cloud platform corresponding to external access requests that have passed the permission verification. It encrypts the cross-cloud data link through a security encryption algorithm and establishes a hash verification mechanism between the data sending node and the data receiving node. The log auditing and anomaly monitoring module is used to record and analyze the entire transmission process and access behavior after the data security flow control module completes the data transmission. When unauthorized access, repeated access or abnormal traffic behavior is detected, security alarm information is generated and the abnormal characteristics are fed back to the data access authentication module.

2. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 1, characterized in that: The steps for obtaining the verified set of trusted resource nodes are as follows: Obtain node access information for each cloud platform. Node access information includes the node's unique identifier, platform type, access interface address, and security certificate file. The system verifies the legitimacy of the cloud node's identity information by calling the cloud platform's public key infrastructure service to check the issuing authority, certificate serial number, and expiration date of the security certificate file. If the issuing authority is detected to be in the trusted CA list and the certificate status is valid, the node is deemed to be legitimate and recorded as a legitimate node; otherwise, the node is marked as an illegitimate node and its access is terminated. Obtain the security certificate files of all legitimate nodes, verify the integrity of the security certificate files, and record the nodes that pass the verification as complete nodes; Construct a node information table and generate a trust identifier code. The node information table is used to store fields such as the unique identifier of the node, platform type, certificate verification status, trust level, and last update time. For all complete nodes, generate a trust identifier code for each node and record its certificate verification status, trust level and last update time in the node information table; The node information of all complete nodes is aggregated to form a verified set of trusted resource nodes.

3. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 2, characterized in that, The steps for verifying the integrity of the security certificate file are as follows: Calculate the hash digest value of the security certificate file and compare it with the original digest value stored during the registration phase. If they match, it proves that the certificate content has not been tampered with, and the node is deemed to have passed verification. If there is a difference, the node is deemed to have failed verification, the node is marked as an "abnormal certificate node", and a security alarm is triggered.

4. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 1, characterized in that, The steps for obtaining the legitimate external access request are as follows: Receive external access requests from various cloud nodes; each external access request includes the source node identifier, request timestamp, access token, and request type information; Based on a verified set of trusted resource nodes, the trustworthiness of the source node of an external access request is compared. If the source node's trustworthiness is verified, the access token for the external access request will be validated. If the access token is deemed valid, the difference between the request timestamp in the external access request and the current time is calculated, and the result is compared with a preset time window threshold. If the difference exceeds the time window range, the request is determined to be expired or abnormal and the processing is terminated. If the timestamp is within the valid range, the session verification for the request is deemed successful. If the session verification is successful, the access request will be recorded as a valid external access request.

5. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 4, characterized in that: The step of performing a trustworthiness comparison on the source node of the external access request is as follows: Extract the source node identifier from the request data and match it with the unique node identifier in the set of trusted resource nodes. If the match is successful, it is determined that the access request comes from a trusted node and the source node trustworthiness comparison is successful. Otherwise, it is determined that the source node trustworthiness comparison is unsuccessful, and the request is marked as an illegal request and the authentication process is terminated.

6. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 4, characterized in that: The steps for validating the access token of external access requests are as follows: Call the token verification interface to verify the issuing authority, signature information, validity period, and number of uses of the access token; If the signature verification passes and the token is within its validity period, the token is considered valid; otherwise, the request is marked as invalid and access is denied.

7. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 1, characterized in that: The steps for identifying and blocking repeatedly used access token requests are as follows: Extract the token sequence number, token issuance timestamp, request receipt time, and request identifier from a valid external access request; The difference between the request receiving time and the token issuance timestamp is calculated to obtain the timestamp difference value, which represents the actual delay time of the access request. The current access request is determined based on the timestamp difference value. If the current access request meets the time condition, the token sequence number set is recorded in the cache table. When a new access request comes in, its token sequence number is compared with that set. If it exists, it is determined to be a duplicate request and enters the blocking process. If it does not exist, it is allowed to continue subsequent detection. Compare the current request identifier with the identifier of the token's most recent successful access record. If they are equal, it is determined to be a replay behavior. If they are not equal, the token replay detection is passed, and the token's identifier record is updated. When a duplicate or abnormal access token is detected, blocking and feedback operations are performed. When a replay behavior is determined, a blocking instruction is generated, and the token serial number and its source node identifier are written to the blacklist. At the same time, a blocking event record is returned to the data access authentication module.

8. The intelligent management and control system for secure data flow in a multi-cloud environment according to claim 7, characterized in that: The step of determining whether the current access request meets the time condition based on the timestamp difference is as follows: Get the maximum allowed delay time. If the timestamp difference is less than 0, it means that the request time is earlier than the issuance time, and it is judged as a forged request. If the timestamp difference is greater than the maximum allowed delay time, it means that the request has exceeded the allowed time window, is judged as an expired request, and is directly rejected; Otherwise, the current access request is deemed to meet the time condition.

Images