A multi-cloud collaborative management method, system, device, storage medium and product

Abstract

This invention discloses a multi-cloud collaborative management method, system, device, storage medium, and product. Responding to phase changes in multi-cloud collaborative tasks, and based on the functional requirements involved in the tasks, it elects a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement from all participating organizations in the alliance. Responding to data access requests under multi-cloud collaborative tasks, it obtains the data tags and reference role attributes of the data to be accessed. Based on the data access request, data tags, and reference role attributes, it generates an access policy for the requester's access to the data to be accessed through the main coordinating body and the corresponding dedicated coordinating bodies. Using this invention, collaborative management can be transformed from static configuration to dynamic orchestration. While ensuring cross-platform collaboration flexibility, it enhances the security, compliance, and traceability of access control through separation of duties and joint decision-making, adapting to complex collaborative scenarios under multi-cloud architectures.

Description

Technical Field

[0001] This invention relates to the field of cloud architecture technology, and in particular to a multi-cloud collaborative management method, system, device, storage medium and product. Background Technology

[0002] Driven by the "Internet Plus" strategy, many sectors have deployed dedicated cloud platforms for data collection, analysis, and sharing. In the medical field, for example, collaborative medical data sharing among hospitals, disease control centers, and research centers is becoming a regular requirement.

[0003] In existing technologies, organizations typically upload their data to corresponding cloud services, collaboratively forming a multi-cloud alliance architecture. This architecture enables resource sharing among organizations. While multi-cloud alliance architecture improves system flexibility and resource utilization, it also presents significant challenges in cross-domain data sharing and access control. Summary of the Invention

[0004] The embodiments of the present invention aim to provide a multi-cloud collaborative management method, system, device, storage medium and product, which can transform collaborative management from static configuration to dynamic orchestration. While ensuring the flexibility of cross-platform collaboration, it enhances the security, compliance and traceability of access control through separation of duties and joint decision-making, and can adapt to complex collaborative scenarios under multi-cloud architecture.

[0005] In a first aspect, embodiments of the present invention provide a multi-cloud collaborative management method, including: In response to the phase change of the multi-cloud collaborative task, based on the functional requirements involved in the multi-cloud collaborative task, a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement are elected from all participating organizations of the alliance. In response to the data access request under the multi-cloud collaborative task, obtain the data tag and reference role attribute of the data to be accessed; Based on the data access request, the data tag, and the reference role attribute, the requester generates an access strategy for the data to be accessed through the main coordinating agency and the corresponding dedicated coordinating agency.

[0006] As an improvement to the above solution, the functional requirements involved in the multi-cloud collaborative task include data processing, request compliance assessment, and access auditing; The dedicated coordination mechanism includes a data coordination mechanism, a policy coordination mechanism, and an audit coordination mechanism; wherein, the data coordination mechanism is used for uploading, encrypting, and computing data; the policy coordination mechanism is used for access permission assessment and compliance judgment; and the audit coordination mechanism is used for generating access logs and auditing and uploading the access logs to the blockchain.

[0007] As an improvement to the above solution, in response to phase changes in multi-cloud collaborative tasks, based on the functional requirements involved in the multi-cloud collaborative tasks, a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement are elected from all participating organizations in the alliance, including: In response to phase changes in multi-cloud collaborative tasks, obtain the task type of the multi-cloud collaborative task, the functional requirements at the current phase, and the operational status of each participating organization in the alliance; Based on the operational status, calculate the matching degree between each participating organization and the task type, and elect a main coordinating organization from all participating organizations based on the matching degree. Based on the operational status, a dedicated coordinating body is elected for each of the aforementioned functional requirements.

[0008] As an improvement to the above scheme, the step of calculating the matching degree between each participating organization and the task type based on the operating status, and electing a main coordinating organization from all participating organizations based on the matching degree, includes: Based on the operating status, obtain the current load of each participating institution and the current resource health score of the cloud platform on which it is located; Based on the task type, obtain the priority weight of the role attributes of each organization for the multi-cloud collaborative task, and the degree of professional matching between each participating organization and the current task domain. The election score for each participating institution is calculated based on the current load, the current resource health score, the priority weight, and the professional matching degree. Based on the election scores, a chief coordinating body is elected from all participating bodies.

[0009] As an improvement to the above solution, the step of responding to a data access request under the multi-cloud collaborative task and obtaining the data tag and reference role attribute of the data to be accessed includes: In response to the data access request under the multi-cloud collaborative task, the identity attribute of the requester is obtained, and the role attribute bound to the identity attribute of the requester is obtained from the blockchain network; The data tags and reference role attributes of the data to be accessed are obtained from the file information chain of the blockchain network; the file information chain is used to record the core meta-information of all shared data in the consortium, and the core meta-information includes storage location, data tags, access policies and reference role attributes.

[0010] As an improvement to the above solution, the step of responding to a data access request under the multi-cloud collaborative task, obtaining the requester's identity attributes, and obtaining the role attributes bound to the requester's identity attributes from the blockchain network includes: Based on the data access request, the requester's identity attributes are obtained from the identity attribute chain of the blockchain network; the identity attribute chain is used to record the identity attributes of users in each participating institution. Based on the identity attribute, the role attribute bound to the identity attribute is obtained from the attribute mapping chain of the blockchain network; the attribute mapping chain is used to record the semantic equivalence mapping relationship of the identity attributes of users between different institutions.

[0011] As an improvement to the above scheme, the method for updating the identity attribute chain includes: In response to a registration request from a newly added organization, the role system data of the newly added organization is obtained; the role system data includes the role attributes of each user in the newly added organization. The role system data is uploaded to the identity attribute chain of the blockchain network.

[0012] As an improvement to the above scheme, the method for updating the attribute mapping chain includes: In response to an update to the identity attribute chain, retrieve the first role attributes of each user in an existing organization and the second role attributes of each user in a newly added organization from the attribute mapping chain; Calculate the first semantic similarity between the first role attribute and the second role attribute. If the first semantic similarity is greater than a preset similarity threshold, then map the user corresponding to the newly added organization to the attribute mapping chain. The second role attribute is bound to the identity attribute chain in the blockchain network.

[0013] As an improvement to the above solution, the step of generating an access strategy for the requester to access the data to be accessed, based on the data access request, the data tag, and the reference role attribute, through the main coordinating agency and the corresponding dedicated coordinating agency, includes: Based on the data access request, the requester's role attributes and access task tags are obtained; Calculate the second semantic similarity between the character attribute and the reference character attribute; The historical trust level is obtained based on the historical interaction data between the requester and the role corresponding to the reference role attribute; Calculate the semantic fit of the task based on the access task label and the data label; Based on the second semantic similarity, the historical trust level, and the task semantic fit, the dedicated coordination mechanism generates independent access strategies for each functional requirement. The main coordinating body integrates and coordinates the independent access policies to generate the requester's access policy for the data to be accessed.

[0014] As an improvement to the above solution, the step of integrating and coordinating the independent access policies through the main coordinating mechanism to generate the requester's access policy for the data to be accessed includes: Determine whether there are conflicts between the independent access policies generated by each dedicated coordination agency; If there is no conflict, the independent access policies are integrated through the main coordinating body to generate the requester's access policy for the data to be accessed; If a conflict exists, the independent access policy is coordinated by the main coordinating agency according to the preset coordination agency priority under the multi-cloud collaborative task, and an access policy for the requester to access the data to be accessed is generated.

[0015] As an improvement to the above scheme, when the data access request is an urgent data access request, the generated access policy is a temporary authorized access policy; after the independent access policies are integrated and coordinated through the main coordinating agency to generate the requester's access policy for the data to be accessed, the multi-cloud collaborative management method further includes: According to the temporary authorized access policy, temporary blocks are recorded in the blockchain network; the state of the temporary blocks is temporary. Within the preset waiting period, receive the approval result of the emergency data access request; If the approval result is passed, the status of the temporary block will be updated to effective. If the approval result is not approved, an authorization rollback operation is performed on the blockchain network, the temporary state is marked as invalid, and the record of the temporary block is transferred to the archive chain of the blockchain network.

[0016] As an improvement to the above solution, after the main coordinating body integrates and coordinates the independent access policies to generate the requester's access policy for the data to be accessed, the multi-cloud collaborative management method further includes: According to the access policy, blockchain network authorization confirmation is performed. Once the authorization confirmation is successful, a token bound to the data to be accessed is generated, enabling the requester to access the data through the token. Once the access is complete, an access log entry is generated and written into the access record chain of the blockchain network.

[0017] Secondly, embodiments of the present invention provide a multi-cloud collaborative management system, including: The organization election module is used to respond to phase changes in multi-cloud collaborative tasks. Based on the functional requirements involved in the multi-cloud collaborative tasks, it elects the main coordinating organization and the dedicated coordinating organization corresponding to each functional requirement from all participating organizations in the alliance. The request and response module is used to respond to data access requests under the multi-cloud collaborative task and obtain the data tags and reference role attributes of the data to be accessed. The access policy generation module is used to generate an access policy for the requester to access the data based on the data access request, the data tag, and the reference role attribute, through the main coordinating agency and the corresponding dedicated coordinating agency.

[0018] Thirdly, embodiments of the present invention provide a multi-cloud collaborative management device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the multi-cloud collaborative management method as described above.

[0019] Fourthly, embodiments of the present invention provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the multi-cloud collaborative management method as described above.

[0020] Fifthly, embodiments of the present invention provide a computer program product, the computer program product including a computer program or computer instructions, wherein when the computer program or computer instructions are executed by a processor, the multi-cloud collaborative management method described above is performed.

[0021] Compared with existing technologies, the present invention discloses a multi-cloud collaborative management method, system, device, storage medium, and product. In response to phase changes in multi-cloud collaborative tasks, and based on the functional requirements involved in the multi-cloud collaborative tasks, it elects a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement from all participating organizations in the alliance. In response to data access requests under the multi-cloud collaborative tasks, it obtains the data tags and reference role attributes of the data to be accessed. Based on the data access request, the data tags, and the reference role attributes, it generates an access policy for the requester's access to the data to be accessed through the main coordinating body and the corresponding dedicated coordinating bodies. Using the embodiments of the present invention, collaborative management can be transformed from static configuration to dynamic orchestration. While ensuring the flexibility of cross-platform collaboration, it enhances the security, compliance, and traceability of access control through separation of duties and joint decision-making, and can adapt to complex collaborative scenarios under multi-cloud architectures. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the steps of a multi-cloud collaborative management method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a multi-cloud collaborative management system provided in an embodiment of the present invention; Figure 3This is a schematic diagram of the structure of a multi-cloud collaborative management device provided in an embodiment of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] In the description and claims, it should be understood that the terms "first," "second," etc., used in the description and claims are only for the purpose of distinguishing the description of the same technical features, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated, nor necessarily the order of description or chronological order. The terms are interchangeable where appropriate. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature.

[0025] With the rapid development of cloud computing technology, enterprises and research institutions are gradually migrating massive amounts of data to multi-cloud platforms. While multi-cloud architecture improves system flexibility and resource utilization, it also brings significant challenges to cross-domain data sharing and access control. Especially when issues such as management isolation, inconsistent attribute descriptions, and incompatible security policies exist between multiple cloud security domains, ensuring the secure flow of data between different cloud domains has become a key challenge in current research and application.

[0026] It should be noted that the following specific embodiments of the present invention are illustrated using a multi-institutional cross-domain data sharing scenario as an example, but the present invention is not limited thereto. It is understood that the embodiments of the present invention aim to provide a cross-platform collaborative management solution applicable to multi-cloud architectures. Its core mechanism can be widely applied to any scenario requiring cross-security domain data sharing and collaborative management. For example, cross-regional government data collaboration scenarios, cross-enterprise supply chain collaboration, and cross-institutional scientific research collaboration, etc. Any data collaboration scenario involving multiple participants and multiple security domains under a multi-cloud architecture, requiring a balance between efficiency and compliance, can adopt the technical solution provided by the present invention. Further details will not be elaborated here.

[0027] Based on the above considerations, embodiments of the present invention provide a multi-cloud collaborative management method. Please refer to... Figure 1 In this embodiment, the multi-cloud collaborative management method is specifically executed through steps S1 to S3: S1. In response to the phase change of the multi-cloud collaborative task, based on the functional requirements involved in the multi-cloud collaborative task, elect the main coordinating body and the dedicated coordinating body corresponding to each functional requirement from all participating organizations of the alliance. S2. In response to the data access request under the multi-cloud collaborative task, obtain the data tag and reference role attribute of the data to be accessed; S3. Based on the data access request, the data tag, and the reference role attribute, the requester generates an access strategy for the data to be accessed through the main coordinating agency and the corresponding dedicated coordinating agency.

[0028] In the multi-cloud environment of this invention embodiment, different organizations can be hosted on different cloud service providers (such as Huawei Cloud, Alibaba Cloud, AWS, etc.). To address the current situation of distributed data management across multiple cloud platforms, this invention embodiment preferably introduces a multi-cloud collaboration middleware (Cloud-Orchestrator Layer) into the application. This middleware serves as the core for cross-platform resource scheduling and policy execution, responsible for the unified management of data access, access control command issuance, and resource index registration on various cloud platforms. The middleware decouples the access control model to a unified logic layer through an abstract access adaptation interface (AAI), ensuring consistent execution of system access processes and security policies even under heterogeneous underlying resources.

[0029] Multi-cloud collaborative tasks may face different collaborative management needs at different stages. To achieve dynamic adaptation of the coordination structure and avoid the problem of mismatched capabilities of fixed coordination agencies at different stages, this embodiment of the invention re-elects within the alliance based on the functional requirements of the current stage when stages change. This enables each agency to play its role in its area of ​​expertise, thereby improving collaborative efficiency.

[0030] It should be noted that a data access request is an application initiated by a requester to the blockchain network for access to specific shared data within the blockchain network. Data tags can include descriptions of the type, purpose, and sensitivity of the data to be accessed; reference role attributes clarify the pre-defined access qualification standards for the data.

[0031] All shared data in the blockchain network is uploaded by registered institutions. In a preferred embodiment of the invention, when uploading shareable data, the data owner can enhance the data attributes by attaching a set of tags to the shared data. For example, data... The set of tags is represented as: ; in, A predefined set of data type labels, such as "diabetes", "images", "electrocardiogram", etc. The i-th label represents the domain to which the data belongs.

[0032] After obtaining information about the data access request and the data to be accessed, the decision-making process involves the joint participation of the primary coordinating body and the dedicated coordinating bodies corresponding to this multi-cloud collaborative task. The primary coordinating body provides overall coordination, while each dedicated coordinating body offers professional judgment based on its respective functions, ultimately generating an access strategy for the request.

[0033] This invention constructs an adaptive cross-platform access control mechanism by dynamically splitting collaborative tasks into stages, dividing them by functional specialties, and making collaborative decisions based on requests. During task execution, the management structure is not fixed but rather the coordinating body is re-elected as the stage changes, ensuring that resource scheduling and decision-making authority always match the actual needs of the current task. Each function is undertaken by a different dedicated coordinating body, avoiding efficiency bottlenecks and ambiguity of authority caused by mixed responsibilities, and achieving professional parallel collaboration. When a specific access request arrives, the final authorization strategy is not determined by a single entity but is generated by the main coordinating body in coordination with the participation of dedicated coordinating bodies for each function, thus forming a multi-party check and balance and professional complementarity at the decision-making level.

[0034] The above solution transforms collaborative management from static configuration to dynamic orchestration. While ensuring the flexibility of cross-platform collaboration, it enhances the security, compliance, and traceability of access control through separation of duties and joint decision-making. It can adapt to complex collaborative scenarios with multiple participants, multiple stages, and multiple functions in parallel under a multi-cloud architecture.

[0035] As a preferred implementation, the functional requirements involved in the multi-cloud collaborative task include data processing, request compliance assessment, and access auditing; The dedicated coordination mechanism includes a data coordination mechanism, a policy coordination mechanism, and an audit coordination mechanism; wherein, the data coordination mechanism is used for uploading, encrypting, and computing data; the policy coordination mechanism is used for access permission assessment and compliance judgment; and the audit coordination mechanism is used for generating access logs and auditing and uploading the access logs to the blockchain.

[0036] When data to be shared needs to be incorporated into the collaborative system, the data coordination agency is responsible for uploading the data to the designated storage location and encrypting the data to ensure transmission and storage security. Furthermore, upon receiving a data access request, the data coordination agency will perform necessary calculations based on the data access request and the data to be accessed, such as format conversion and hash calculations.

[0037] For example, during the process of generating access policies, data coordination agencies need to determine whether data is extractable, whether the extraction scope is reasonable, whether data anonymization is required, and whether it will affect data-side performance.

[0038] When a data access request is received, the policy coordination agency determines whether the requester is qualified to access the data, based on the requester's identity attributes, the security level of the data to be accessed, the access task tag, and whether the task or request complies with usage restrictions, ethical requirements, the principle of minimum necessity, regional regulatory requirements, etc.

[0039] After each data access is completed, the audit coordination agency is responsible for generating a detailed access log, recording key information about the access behavior. The log content is then audited to verify whether the access behavior complies with the authorized scope and compliance requirements. Finally, the audit results are written to the blockchain, leveraging its immutability to achieve permanent evidence storage. Understandably, upon receiving a data access request, the audit coordination agency will propose constraints on the requester during the actual data access process based on audit requirements.

[0040] For example, during the access policy generation process, the audit coordination agency determines whether the operation meets traceability requirements, whether log fields are complete, and whether retention periods and archiving responsibilities meet requirements.

[0041] In the above solution, in response to multi-dimensional processing needs, the authority of the traditional coordination agency is refined into sub-roles such as the main coordination agency, data coordination agency, strategy coordination agency, and audit coordination agency. Parallel collaborative execution is achieved through task coordination contracts, which can effectively adapt to the characteristics of "multiple participants and multiple sub-processes" and improve processing capabilities and module autonomy.

[0042] As a preferred implementation, step S1, in response to the phase change of the multi-cloud collaborative task, selects a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement from all participating organizations in the alliance, based on the functional requirements involved in the multi-cloud collaborative task, and executes this step through steps S11-S13: S11. In response to the phase change of the multi-cloud collaborative task, obtain the task type of the multi-cloud collaborative task, the functional requirements at the current phase, and the operational status of each participating organization in the alliance. S12. Based on the operating status, calculate the matching degree between each participating organization and the task type, and elect a main coordinating organization from all participating organizations based on the matching degree. S13. Based on the operating status, elect a dedicated coordination agency for each of the aforementioned functional requirements.

[0043] In this embodiment of the invention, in view of the complexity of actual shared tasks and the need for multi-dimensional collaboration, a collaborative dedicated coordination mechanism is further introduced on the basis of the traditional single main coordination mechanism, which divides different functional needs into multiple dedicated coordination mechanisms.

[0044] Each dedicated coordinating body collaborates through a Task Coordination Contract triggered by a smart contract, with the main coordinating body handling the task packaging and final submission. This mechanism ensures that in highly specialized task environments, different bodies can lead their respective sub-processes, thereby improving system efficiency and accuracy.

[0045] Participating institutions may differ significantly in terms of physical conditions, management systems, and compliance audits. In some preferred embodiments, a health feedback mechanism is introduced to dynamically score each institution's health before the election, determining whether the institution can participate in the current consensus process or the election process. The dynamic health score of institution i is expressed as: ; in, The online time ratio of institution i; This indicates whether organization i's data has undergone timely legal and ethical compliance verification; The network performance metrics for organization i are comprehensively evaluated based on historical response latency and packet loss rate.

[0046] The main coordinating body is responsible for overall coordination and needs to possess comprehensive capabilities matching the current task type. In this embodiment of the invention, the main coordinating body is elected by calculating the matching degree between participating organizations and task types. In this calculation process, for tasks with high timeliness requirements, organizations with low load and fast response have a higher matching degree; for tasks with high professional requirements, organizations with accumulated experience in that field have a higher matching degree.

[0047] A dedicated coordinating body is responsible for executing specific functions and needs to possess professional capabilities in its assigned functional area. It should be noted that the required capabilities of the body vary depending on the specific functional requirements. For example, data processing may require strong computing resources, compliance assessment may require professional compliance review capabilities, and access auditing may require robust log management and evidence preservation capabilities. In this embodiment of the invention, the corresponding dedicated coordinating body will be automatically selected based on intelligent requirements.

[0048] In the above scheme, the election of coordinating bodies is carried out through a hierarchical election mechanism based on both task type and functional requirements. This allows for the parallel handling of complex issues by different coordinating bodies, thereby improving multi-cloud collaborative management capabilities.

[0049] Further, preferably, step S12 involves calculating the matching degree between each participating organization and the task type based on the operating status, and electing a main coordinating organization from all participating organizations based on the matching degree, including: Based on the operating status, obtain the current load of each participating institution and the current resource health score of the cloud platform on which it is located; Based on the task type, obtain the priority weight of the role attributes of each organization for the multi-cloud collaborative task, and the degree of professional matching between each participating organization and the current task domain. The election score for each participating institution is calculated based on the current load, the current resource health score, the priority weight, and the professional matching degree. Based on the election scores, a chief coordinating body is elected from all participating bodies.

[0050] In the standard Raft architecture, the coordinating body is typically elected based on a timeout voting mechanism. However, in medical scenarios, shared tasks often have characteristics such as "suddenness," "clear objectives," and "professional dependence," and traditional random leader election strategies may lead to a mismatch between the scheduling role and the task.

[0051] Each multi-cloud collaborative task has a priority weight based on policy or role assignment. For example, the National Health Commission has a higher priority in regulatory tasks.

[0052] In some preferred embodiments, the current resource health score includes multiple indicators such as network stability, resource availability, and interface response latency.

[0053] In this embodiment of the invention, a task-driven coordination mechanism is introduced. Specifically, before triggering the election, the election score of each participating organization is calculated: ; in, The degree of professional matching between participating organization i and the current task domain T; Current load; Priority weight; Assess the current health of resources; , , and These are adjustable weighting coefficients. ,and .

[0054] With adjustable coefficient weights, embodiments of the present invention can achieve task type-driven, node state-driven, alliance strategy-driven, and health-driven approaches.

[0055] For example, under task type-driven conditions, if the task is an emergency prevention and control task, the system will increase the weight of PolicyPriority(i, T). If the task involves scientific data modeling, then Expertise is given more emphasis. ),therefore Weight boosting. Driven by node state, when a node's system load is high, the system load will be reduced. The system prioritizes certain types of institutions to avoid selecting coordinating agencies that cannot efficiently perform tasks due to resource bottlenecks. Driven by the alliance strategy, when regulators or alliance members explicitly require certain types of institutions to participate preferentially in specific scenarios (e.g., top-tier hospitals in critical care data tasks), the system automatically adjusts the allocation accordingly. Driven by health metrics, if the overall health of the alliance's operating environment is low, such as when some cloud nodes experience resource shortages or network latency, the system will increase [its efficiency / performance]. The proportion of nodes should be prioritized, and nodes with stable operation should be selected first.

[0056] In some preferred embodiments, when the election score of participating institution i Only when a candidate exceeds a preset score threshold does it qualify to participate in the election process. Ultimately, by securing the support of a majority of qualified voting nodes, the organization with the highest level of professional expertise and system health is selected as the main coordinating body.

[0057] The above solution introduces a multi-factor scoring model that considers task type, node professional capabilities, and policy priorities to select the most suitable main coordinating body for the current task. This avoids the scheduling mismatch problem caused by the random selection of the main body in traditional Raft, improves the overall intelligence of task-driven mobilization, and makes the main body selection process more reasonable, which can effectively improve the response efficiency in the multi-cloud collaborative management process.

[0058] As a preferred implementation, step S2, in response to the data access request under the multi-cloud collaborative task, obtains the data tag and reference role attribute of the data to be accessed, and executes it through steps S21-S22: S21. In response to the data access request under the multi-cloud collaborative task, obtain the identity attribute of the requester and obtain the role attribute bound to the identity attribute of the requester from the blockchain network; S22. Obtain the data tag and reference role attribute of the data to be accessed from the file information chain of the blockchain network; the file information chain is used to record the core meta-information of all shared data in the consortium, and the core meta-information includes storage location, data tag, access strategy and reference role attribute.

[0059] In some preferred embodiments, the data access request includes the requester's identity attributes and access purpose tags. For example, the identity attributes are "clinical researcher," "statistical modeling expert," etc.; the access purpose tags are "modeling research," "anomaly detection," "training AI model," etc.

[0060] The identity attribute is the requester's identity identifier or role information within their organization. The role attribute is the attribute that is bound to the requester's identity in the blockchain network. Furthermore, this role attribute may correspond to multiple user roles from different organizations, and these user roles are similar in terms of permissions and functions.

[0061] Under the architecture of this invention, the requester can declare their identity, but their true authority role cannot be determined solely by the declaration. They must obtain pre-bound role information from a trusted blockchain network to ensure the authenticity of the requester's authority.

[0062] In this embodiment of the invention, the File Information Chain (FIC) is used to record the core meta-information of all shared files in the consortium, constructing an on-chain resource directory for the data layer. Each FIC chain record includes the following key fields: Data storage location: an encrypted storage path or the file system location it points to, such as the encrypted URL of a DICOM image or the de-identified storage ID of a structured EMR; Data tag set: such as medical semantic keywords like "diabetes," "hypertension," and "lung CT," used for task adaptation and feature indexing; Access policy description: indicating the purpose for which the data can be accessed (e.g., "for research use only," "not exportable," "requires ethical approval," etc.), and can be combined with an access token mechanism to generate fine-grained access rules.

[0063] Each record in the FIC chain will include an identifier field (CloudProviderID) for the cloud platform from which the data originates, used to distinguish resource ownership and permission mapping sources. The system supports embedding access protocol identifiers and policy matching rules for multiple cloud platforms into the consortium blockchain structure, achieving unified directory management, rapid location, and access condition verification of cloud resources through the "platform identifier - resource path - policy rule" triple.

[0064] The metadata of the data to be accessed is obtained from the file information chain rather than relying on the data provider's real-time interface or local cache, which ensures the authority and consistency of the access rules. Once the access policy set by the data provider is written onto the chain, it becomes a rule that all participating institutions abide by, and cannot be unilaterally modified or circumvented.

[0065] In the above scheme, the reliable storage and retrieval of identity information and data metadata are realized through the blockchain network, and a reliable information acquisition channel is built in the access request processing stage.

[0066] Further, preferably, step S21, in response to a data access request under the multi-cloud collaborative task, obtains the requester's identity attributes and retrieves the role attributes bound to the requester's identity attributes from the blockchain network, including: Based on the data access request, the requester's identity attributes are obtained from the identity attribute chain of the blockchain network; the identity attribute chain is used to record the identity attributes of users in each participating institution. Based on the identity attribute, the role attribute bound to the identity attribute is obtained from the attribute mapping chain of the blockchain network; the attribute mapping chain is used to record the semantic equivalence mapping relationship of the identity attributes of users between different institutions.

[0067] In cross-regional sharing scenarios, different institutions may have different definitions of user roles. For example, as shown in Table 1, there are differences in role permissions and data type attributes among different medical institutions. The attribute mapping chain serves to align these differences in role attributes between different institutions.

[0068] Table 1

[0069] In this embodiment of the invention, the Identity Attribute Chain (IAC) is used to record the identity information of medical users and the set of role attributes they are bound to. Each medical alliance member (such as a doctor, researcher, or ethics reviewer) generates a unique identifier IDu upon registration and establishes a binding relationship with its corresponding set of role attributes Au. This chain ensures that the visitor's identity is verifiable and their behavior is traceable. By linking with the AMC chain, the IAC chain can achieve dynamic visitor role resolution, assisting the permission decision module in quickly determining whether the user has the corresponding access qualifications.

[0070] Since the requester's identity attributes are maintained independently by the participating organization to which the requester belongs, directly using the original identity attributes for cross-domain authorization would lead to semantic inconsistencies. Therefore, it is necessary to convert them into role attributes that can be recognized during cross-domain access.

[0071] The Attribute Mapping Chain (AMC) is used to maintain the equivalent mapping relationships of semantic attributes such as roles, functions, and permissions among participating institutions in a medical consortium. Since different medical institutions differ in their professional title systems and permission configurations, this chain achieves cross-institutional role matching by recording the equivalence relationships of "attribute semantic pairs." For example, mapping "Chief Physician" to "Researcher" or "Senior Data Analyst" ensures that visitors from different systems have equivalent permission expression capabilities during the sharing process. The AMC chain supports dynamic updates and smart contract-driven mechanisms. Mapping relationships can be generated and verified through semantic similarity matching, historical interaction behavior, etc., and stored on the chain in a structured form to ensure attribute consistency and transparency.

[0072] In a preferred embodiment of the present invention, an Attribute Authority (AA) is used to map and manage each institution, which can ensure that when accessing across domains, the access request is correctly mapped from "Clinical Researcher" to the equivalent access attribute of "Associate Chief Physician", and the corresponding data fields and access permissions are automatically matched.

[0073] By querying the attribute mapping chain, the requester's identity attributes within their organization can be mapped to cross-domain universal role attributes.

[0074] In the above scheme, the identity attribute chain serves as a centralized record carrier of user identity information from participating institutions, providing each user with a trusted identity credential; the attribute mapping chain serves as a record carrier of identity attribute mapping relationships between different institutions, converting the unique identity attributes of each institution into a unified role expression across domains; by combining the identity attribute chain and the attribute mapping chain, the unique identity attributes of each institution can be converted into unified role attributes based on data access requests, eliminating semantic barriers in cross-domain access.

[0075] Furthermore, preferably, the method for updating the identity attribute chain includes: In response to a registration request from a newly added organization, the role system data of the newly added organization is obtained; the role system data includes the role attributes of each user in the newly added organization. The role system data is uploaded to the identity attribute chain of the blockchain network.

[0076] In the multi-cloud architecture of this invention, new organizations need to request registration from the blockchain network before they can participate in collaborative management under the multi-cloud architecture. During the registration request process, in order to achieve full blockchain-based role collaborative management, the organization's user identity information needs to be incorporated into the alliance's trusted identity system.

[0077] Newly added organizations will upload their internal role system data to the identity attribute chain of the blockchain network, and the identity attribute chain corresponding to organization k will be updated accordingly. Represented as: ; in, This represents the i-th role attribute, such as "Director of Infectious Diseases Department" or "Data Analyst". Each role attribute includes the fields Department, Title, Functional Permissions, and Qualification Level.

[0078] In the above scheme, when a new institution joins the alliance, the identity attributes of its users are incorporated into the alliance's identity system through blockchain. In this way, the user identity attributes of all participating institutions are stored in the identity attribute chain, forming a unified identity information database for the alliance. Although the identity data of each institution is independently uploaded to the chain, they are stored on the same identity attribute chain, which facilitates cross-institutional querying and verification.

[0079] Preferably, the method for updating the attribute mapping chain includes: In response to an update to the identity attribute chain, retrieve the first role attributes of each user in an existing organization and the second role attributes of each user in a newly added organization from the attribute mapping chain; Calculate the first semantic similarity between the first role attribute and the second role attribute. If the first semantic similarity is greater than a preset similarity threshold, then map the user corresponding to the newly added organization to the attribute mapping chain. The second role attribute is bound to the identity attribute chain in the blockchain network.

[0080] When the identity attribute chain is updated, it means that new role attribute data has been written to the chain. This is usually caused by the registration of a new organization or the addition of a user to an existing organization. Using the update of the identity attribute chain as a trigger condition enables the automatic synchronization and updating of the attribute mapping chain.

[0081] The first role attribute is the set of role attributes for each user in the existing institutions within the attribute mapping chain, and it has already completed the mapping of user identities to different institutions. The second role attribute is the set of role attributes for each user in the newly added institutions. The first semantic similarity is a quantitative indicator that measures the degree of semantic similarity between the first and second role attributes. The higher the value, the closer the two role attributes are semantically, and the more likely there is an equivalent mapping relationship.

[0082] In some preferred embodiments, the calculation of the first semantic similarity is based on medical language models such as BioBERT and FastText.

[0083] Preferably, users of newly added institutions are mapped to the existing alliance's attribute mapping chain. The process is represented as: ; in, This is the second role attribute for user i in the newly added organization k; The first role attribute of user j in the existing alliance organization r; The first semantic similarity between the first role attribute and the second role attribute; The preset similarity threshold is usually set to 0.75~0.90.

[0084] Next, the second role attributes of each user in the newly added organization are bound to the identity attribute chain to form a set of binding relationships, represented as follows: .

[0085] In a preferred embodiment of the present invention, a context-aware role mapping mechanism is adopted in the process of role semantic mapping. This mechanism combines shared task context, role semantic similarity, inter-organizational trust history and access behavior preferences to dynamically select the most suitable cross-domain attribute mapping path, ensuring high-precision role adaptation under the premise of security and compliance.

[0086] Furthermore, during the shared task initiation phase, the semantic tags of the current multi-cloud collaborative task, such as data types, departmental specialties, and usage purposes, are first analyzed to automatically activate the adaptation strategy. For example, if the current task is a "hospital infection early warning" system, the system will prioritize doctors or administrators from departments with infection control experience (such as "Infectious Diseases Department" or "Public Health Center"); if the task is "diabetes intelligent assisted diagnosis and treatment modeling," it will prefer to enable access roles from "Endocrinology Department" and "Medical Data Analysis Group" to support modeling feature extraction.

[0087] In the above scheme, after the identity attributes of the newly added institution are put on the blockchain, the system will automatically obtain the role attributes of the newly added institution and perform semantic matching with the existing role attributes to automatically establish a mapping relationship, which significantly reduces the manual configuration cost when expanding the alliance.

[0088] In a preferred embodiment of the present invention, the FIC chain, IAC chain, and AMC chain form a three-chain linkage structure, which supports resource positioning by role, permission matching by policy, and behavior tracking by identity, ensuring that data sharing has a closed-loop capability of "controllable entry, trusted process, and auditable result".

[0089] In a preferred implementation, step S3, based on the data access request, the data tag, and the reference role attribute, generates an access policy for the requester's data to be accessed through the main coordinating agency and the corresponding dedicated coordinating agency, and executes it through steps S31-S36: S31. Based on the data access request, obtain the requester's role attributes and access task tags; S32. Calculate the second semantic similarity between the character attribute and the reference character attribute; S33. Obtain the historical trust level based on the historical interaction data between the requester and the role corresponding to the reference role attribute; S34. Calculate the semantic fit of the task based on the access task tag and the data tag; S35. Based on the second semantic similarity, the historical trust level, and the task semantic fit, generate independent access strategies for each functional requirement through the dedicated coordination mechanism. S36. The main coordinating body integrates and coordinates the independent access policies to generate the requester's access policy for the data to be accessed.

[0090] The reference role attributes reflect the ideal role profile of the data to be accessed, and the second semantic similarity between the requester's role attributes and the reference role attributes reflects how close the requester's role is to this ideal role profile. A higher similarity indicates that the requester's role is closer to the data's pre-defined visitor criteria. In some preferred embodiments, the second semantic similarity is calculated based on the language model embedding space.

[0091] It should be noted that the data to be accessed can be either a specified reference role or a specified reference role attribute. When a reference role attribute is specified for the data to be accessed, the corresponding role can be found through the attribute mapping chain, and then the historical interaction data between the requester and that role can be obtained.

[0092] Historical interaction data records the data access interactions that the two parties have had in the past, including the frequency of interactions, compliance status, and any abnormal behavior. Historical trust score is a score based on the sum of historical interaction data, used to measure the compliance level and frequency of the two roles in past data interactions.

[0093] The access task label describes the requester's access purpose, while the data label describes the characteristics or category of the data to be accessed. The task semantic fit calculated by the access task label and the data label can measure the degree of matching between these two types of labels at the semantic level, reflecting the adaptability between the requester's access purpose and the data characteristics.

[0094] This step inputs the quantitative results of three dimensions—secondary semantic similarity, historical trust, and task semantic fit—to each dedicated coordinating agency. Each dedicated coordinating agency corresponds to a functional requirement and, based on its own functional criteria and the aforementioned three quantitative results, generates its own independent access policy. Each agency's independent access policy represents its authorization opinion on the access request from its own functional perspective.

[0095] In some preferred embodiments, a comprehensive matching score is calculated based on the second semantic similarity, the historical trust level, and the task semantic fit, thereby generating an independent access strategy. Represented as: ; in, For character attributes and reference character attributes The second semantic similarity; Based on historical trust level; For task context; For task semantic fit; This is the preset penalty coefficient; This is a semantic distance penalty term; , and These are adjustable weighting coefficients. .

[0096] For example, in a scientific research modeling task, when a "data analyst" from a research institution requests access to anonymized data of diabetic patients from multiple hospitals for model training, the focus is on whether the role attributes are semantically similar (e.g., "researcher" vs. "data analyst"), while the requirement for historical trust is relatively lenient. The weighting coefficients can be set as follows: , , This system pays more attention to semantic similarity, ensuring that research roles are correctly mapped.

[0097] In clinical emergency missions, when CDC experts need temporary access to infectious disease medical records at a hospital, task context matching is paramount, as it's essential to ensure the personnel possess the necessary qualifications for epidemic prevention or infection control. The weighting coefficient can be set as follows: , , This way, the system will prioritize determining the fit between the role and the task scenario, rather than relying solely on semantics or historical collaboration.

[0098] Under a stable alliance built on multiple collaborations, a large hospital and a research institution have a long-standing partnership and have repeatedly completed compliant data sharing. In this case, historical trust levels should be given higher weight to encourage priority authorization from reliable partners. The weighting coefficient could be set as follows: , , .

[0099] The main coordinating body, acting as the overall coordinating body, is responsible for coordinating differences of opinion among various functional departments, handling potential policy conflicts, collecting, analyzing, and integrating various independent policies, synthesizing opinions from all parties to form a unified conclusion, and finally generating the formal access policy for the requester to access the data.

[0100] The above scheme quantifies the generation of access strategies from three dimensions: semantic similarity of roles, historical trust of roles, and semantic fit of tasks. It also enables multiple dedicated coordinating agencies to independently generate their own access strategies based on their own functions and responsibilities, which is more professional and in-depth than a single agency making unified decisions.

[0101] Further, preferably, step S36, integrating and coordinating the independent access policies through the main coordinating mechanism to generate the requester's access policy for the data to be accessed, includes: Determine whether there are conflicts between the independent access policies generated by each dedicated coordination agency; If there is no conflict, the independent access policies are integrated through the main coordinating body to generate the requester's access policy for the data to be accessed; If a conflict exists, the independent access policy is coordinated by the main coordinating agency according to the preset coordination agency priority under the multi-cloud collaborative task, and an access policy for the requester to access the data to be accessed is generated.

[0102] It should be noted that during collaborative management, conflicting judgments may arise among different roles in specific tasks. For example, the strategy coordination agency may refuse to share data for compliance reasons; the data coordination agency may want to release data as soon as possible due to computing needs; and the audit coordination agency may request additional logs and tracking conditions.

[0103] Without a mechanism, the system will struggle to reach a consensus. Therefore, this invention introduces a two-layer mechanism: a Task Coordination Contract (TCC) and role priority rules.

[0104] Under the task coordination protocol, the judgment results of all sub-roles are recorded on the blockchain in the form of "conditional opinions" (e.g., "agree, but with an anonymization strategy required"). The main coordinating body collects and summarizes these conditional opinions to generate a unified task packaging scheme. If the opinions of the various roles are not completely consistent, the main coordinating body will trigger automated arbitration logic, prioritizing the search for "intersection solutions" (e.g., partial data sharing under the premise of meeting compliance requirements).

[0105] Under the role priority rule, different role priorities are set for different scenarios, which is also an important consideration for determining whether there are conflicts and coordinating efforts. For example, in high-risk scenarios or those involving legal compliance, the strategy coordination agency has the highest veto power; even if the data coordination agency wishes to share data, it must meet the minimum compliance conditions of the strategy coordination agency. Provided the compliance conditions are met, the constraints of the data coordination agency and the audit coordination agency work together: the data coordination agency is responsible for data quality and efficiency, while the audit coordination agency ensures traceability. The main coordination agency, as the overall coordinator, can only conduct balancing coordination without violating the opinions of the strategy coordination agency.

[0106] In a preferred embodiment of a research task, the strategy coordinating body requires that data be anonymized before sharing; the data coordinating body desires to release the original data as soon as possible. The system will prioritize the requirements of the strategy coordinating body, and the main coordinating body will generate a task plan of "anonymization before sharing".

[0107] In another preferred embodiment, the audit coordinating body requires full logging of access information, while the data coordinating body believes this would increase computational latency. In this case, the primary coordinating body will adopt a compromise solution of "differential logging + delayed archiving" to ensure both compliance and performance.

[0108] In the above scheme, by determining whether there is a conflict between independent access policies, and then using the main coordinating body for integration and coordination, it can be ensured that the collaborative management process will not lead to a task deadlock due to mutual veto by different roles.

[0109] In a preferred embodiment, when the data access request is an urgent data access request, the generated access policy is a temporary authorized access policy; after step S3, through the main coordinating mechanism, the independent access policies are integrated and coordinated to generate the requester's access policy for the data to be accessed, the multi-cloud collaborative management method further includes: According to the temporary authorized access policy, temporary blocks are recorded in the blockchain network; the state of the temporary blocks is temporary. Within the preset waiting period, receive the approval result of the emergency data access request; If the approval result is passed, the status of the temporary block will be updated to effective. If the approval result is not approved, an authorization rollback operation is performed on the blockchain network, the temporary state is marked as invalid, and the record of the temporary block is transferred to the archive chain of the blockchain network.

[0110] An emergency data access request refers to a data access request that is time-sensitive or sudden and cannot wait for full approval through the normal process. In this embodiment of the invention, a conditional temporary authorized access policy is generated for emergency data access requests, allowing the requester to access the data before formal approval is completed.

[0111] Unlike the "immutability" principle of traditional blockchains, this invention takes into account the lag in ethical review of medical data access (such as the need for IRB approval) and designs a Conditional Block mechanism. Of course, this mechanism can also be adapted to other scenarios besides medical ones.

[0112] For example, when an access request is initially approved due to urgent research needs, the system can first record it as a "temporary block" on the blockchain and mark its status as pending. Subsequently, when the ethics review result is released, the following actions are performed: if the approval is successful, the block status is updated to committed; if the approval is unsuccessful, an on-chain authorization rollback operation is performed, and the record is marked as revoked and transferred to the archive chain for use in post-event auditing and risk assessment.

[0113] In the above scheme, emergency data access requests can obtain temporary authorization without waiting for a full approval process, which can meet the needs of rapid response; at the same time, the temporary authorization access policy is not regarded as the final access policy. If the approval is approved, it will take effect, and if it is not approved, the authorization will be rolled back, so that emergency access behavior is still under the constraints of the compliance framework.

[0114] As a preferred implementation, after step S3, in which the main coordinating mechanism integrates and coordinates the independent access policies to generate the requester's access policy for the data to be accessed, the multi-cloud collaborative management method further includes: According to the access policy, blockchain network authorization confirmation is performed. Once the authorization confirmation is successful, a token bound to the data to be accessed is generated, enabling the requester to access the data through the token. Once the access is complete, an access log entry is generated and written into the access record chain of the blockchain network.

[0115] After the access policy is generated, it is verified and confirmed through the blockchain network to ensure its validity and immutability. An officially effective access token is generated only after the authorization transaction is confirmed. Essentially, the access token is the execution credential of the on-chain authorization result in the multi-cloud access layer; its effectiveness depends on the authorization decision being confirmed on-chain and written to the relevant records.

[0116] In a preferred embodiment of the present invention, after the access request is authorized, the system binds the access token to the cloud platform where the target data resides and transmits the token to the corresponding Edge Access Proxy (EAP) node of the target cloud platform through a unified token gateway. Each EAP converts the token into local access credentials for that cloud platform and executes the actual data access request according to the local security policy, ensuring the security and legitimacy of the token during cross-cloud transmission. The access result is returned to the middleware layer for unified aggregation and recorded in the access log, supporting subsequent auditing and policy optimization.

[0117] In some preferred embodiments, after authorization confirmation, the one-time access token generated for the requester is represented as follows: ; in, Data to be accessed; For the requester's role attributes; Tags for access purposes; For the effective access time window; Use privacy policy structures such as "not exportable", "restricted field access", and "not trainable".

[0118] Access log entries record key information for each access, including but not limited to the requester's identity, access time, accessed data, token used, and access result. After generating an access log entry, the system writes it into the access record chain of the blockchain network to ensure that every access behavior is recorded in the blockchain network.

[0119] In the above scheme, the generation of tokens needs to be authorized and confirmed by the blockchain network, which ensures the legality and validity of the tokens. Furthermore, after each data access is completed, a log item is automatically generated and written to the access record chain, forming a complete access behavior ledger, which provides a credible evidentiary basis for post-event auditing, security investigation, and compliance checks.

[0120] The multi-cloud collaborative management method provided by this invention transforms collaborative management from static configuration to dynamic orchestration. While ensuring the flexibility of cross-platform collaboration, it enhances the security, compliance, and traceability of access control through separation of duties and joint decision-making. It can adapt to complex collaborative scenarios with multiple participants, multiple stages, and multiple functions in parallel under a multi-cloud architecture.

[0121] This invention provides a multi-cloud collaborative management system. Please refer to [link / reference]. Figure 2 The multi-cloud collaborative management system includes an organization election module 11, a request and response module 12, and an access policy generation module 13, wherein: The organization election module 11 is used to respond to the phase change of the multi-cloud collaborative task and, based on the functional requirements involved in the multi-cloud collaborative task, elect the main coordinating organization and the dedicated coordinating organization corresponding to each functional requirement from all participating organizations of the alliance. Request response module 12 is used to respond to data access requests under the multi-cloud collaborative task and obtain the data tags and reference role attributes of the data to be accessed; The access policy generation module 13 is used to generate an access policy for the data to be accessed by the requester based on the data access request, the data tag, and the reference role attribute, through the main coordinating agency and the corresponding dedicated coordinating agency.

[0122] As a preferred implementation, the functional requirements involved in the multi-cloud collaborative task include data processing, request compliance assessment, and access auditing; The dedicated coordination mechanism includes a data coordination mechanism, a policy coordination mechanism, and an audit coordination mechanism; wherein, the data coordination mechanism is used for uploading, encrypting, and computing data; the policy coordination mechanism is used for access permission assessment and compliance judgment; and the audit coordination mechanism is used for generating access logs and auditing and uploading the access logs to the blockchain.

[0123] In a preferred embodiment, the institutional election module 11 includes: The task phase change response unit is used to respond to phase changes in multi-cloud collaborative tasks, and to obtain the task type of the multi-cloud collaborative task, the functional requirements at the current phase, and the operational status of each participating organization in the alliance. The main coordinating body election unit is used to calculate the matching degree between each participating organization and the task type based on the operating status, and to elect a main coordinating body from all participating organizations based on the matching degree. The dedicated coordination agency election unit is used to elect a dedicated coordination agency for each of the aforementioned functional requirements based on the operational status.

[0124] Further, preferably, the main coordinating body election unit is specifically used for: Based on the operating status, obtain the current load of each participating institution and the current resource health score of the cloud platform on which it is located; Based on the task type, obtain the priority weight of the role attributes of each organization for the multi-cloud collaborative task, and the degree of professional matching between each participating organization and the current task domain. The election score for each participating institution is calculated based on the current load, the current resource health score, the priority weight, and the professional matching degree. Based on the election scores, a chief coordinating body is elected from all participating bodies.

[0125] In a preferred embodiment, the request-response module 12 includes: The role attribute acquisition unit is used to respond to the data access request under the multi-cloud collaborative task, acquire the identity attribute of the requester, and acquire the role attribute bound to the identity attribute of the requester from the blockchain network; The core metadata acquisition unit is used to obtain the data tag and reference role attribute of the data to be accessed from the file information chain of the blockchain network; the file information chain is used to record the core metadata of all shared data in the consortium, and the core metadata includes storage location, data tag, access strategy and reference role attribute.

[0126] Further, preferably, the character attribute acquisition unit is specifically used for: Based on the data access request, the requester's identity attributes are obtained from the identity attribute chain of the blockchain network; the identity attribute chain is used to record the identity attributes of users in each participating institution. Based on the identity attribute, the role attribute bound to the identity attribute is obtained from the attribute mapping chain of the blockchain network; the attribute mapping chain is used to record the semantic equivalence mapping relationship of the identity attributes of users between different institutions.

[0127] Furthermore, preferably, the method for updating the identity attribute chain includes: In response to a registration request from a newly added organization, the role system data of the newly added organization is obtained; the role system data includes the role attributes of each user in the newly added organization. The role system data is uploaded to the identity attribute chain of the blockchain network.

[0128] Preferably, the method for updating the attribute mapping chain includes: In response to an update to the identity attribute chain, retrieve the first role attributes of each user in an existing organization and the second role attributes of each user in a newly added organization from the attribute mapping chain; Calculate the first semantic similarity between the first role attribute and the second role attribute. If the first semantic similarity is greater than a preset similarity threshold, then map the user corresponding to the newly added organization to the attribute mapping chain. The second role attribute is bound to the identity attribute chain in the blockchain network.

[0129] In a preferred embodiment, the access policy generation module 13 includes: The requester information acquisition unit is used to obtain the requester's role attributes and access task tags based on the data access request; The second semantic similarity calculation unit is used to calculate the second semantic similarity between the role attribute and the reference role attribute; The historical trust calculation unit is used to obtain the historical trust level based on the historical interaction data between the requester and the role corresponding to the reference role attribute; The task semantic fit calculation unit is used to calculate the task semantic fit based on the access task tag and the data tag; An independent access policy generation unit is used to generate independent access policies for each functional requirement based on the second semantic similarity, the historical trust level, and the task semantic fit, through the dedicated coordination mechanism. The access policy generation unit is used to integrate and coordinate the independent access policies through the main coordinating mechanism to generate the requester's access policy for the data to be accessed.

[0130] Further, preferably, the access policy generation unit is specifically used for: Determine whether there are conflicts between the independent access policies generated by each dedicated coordination agency; If there is no conflict, the independent access policies are integrated through the main coordinating body to generate the requester's access policy for the data to be accessed; If a conflict exists, the independent access policy is coordinated by the main coordinating agency according to the preset coordination agency priority under the multi-cloud collaborative task, and an access policy for the requester to access the data to be accessed is generated.

[0131] In a preferred implementation, when the data access request is an urgent data access request, the generated access policy is a temporary authorized access policy; the multi-cloud collaborative management system further performs the following steps: According to the temporary authorized access policy, temporary blocks are recorded in the blockchain network; the state of the temporary blocks is temporary. Within the preset waiting period, receive the approval result of the emergency data access request; If the approval result is passed, the status of the temporary block will be updated to effective. If the approval result is not approved, an authorization rollback operation is performed on the blockchain network, the temporary state is marked as invalid, and the record of the temporary block is transferred to the archive chain of the blockchain network.

[0132] In a preferred embodiment, the multi-cloud collaborative management system further includes an access record module, used for: According to the access policy, blockchain network authorization confirmation is performed. Once the authorization confirmation is successful, a token bound to the data to be accessed is generated, enabling the requester to access the data through the token. Once the access is complete, an access log entry is generated and written into the access record chain of the blockchain network.

[0133] The multi-cloud collaborative management system provided by this invention transforms collaborative management from static configuration to dynamic orchestration. While ensuring the flexibility of cross-platform collaboration, it enhances the security, compliance, and traceability of access control through separation of duties and joint decision-making. It can adapt to complex collaborative scenarios with multiple participants, multiple stages, and multiple functions in parallel under a multi-cloud architecture.

[0134] Please see Figure 3 , Figure 3This is a structural block diagram of a multi-cloud collaborative management device provided in an embodiment of the present invention. The multi-cloud collaborative management device includes a processor 31, a memory 32, and a computer program stored in the memory 32 and executable on the processor 31. When the processor 31 executes the computer program, it implements the steps in the above-described embodiments of the various multi-cloud collaborative management methods, such as steps S1 to S3.

[0135] For example, the computer program can be divided into one or more modules / units, which are stored in the memory 32 and executed by the processor 31 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the multi-cloud collaborative management device.

[0136] The multi-cloud collaborative management device may include, but is not limited to, a processor 31 and a memory 32. Those skilled in the art will understand that the schematic diagram is merely an example of a multi-cloud collaborative management device and does not constitute a limitation on the device. It may include more or fewer components than illustrated, or combine certain components, or use different components. For example, the multi-cloud collaborative management device may also include input / output devices, network access devices, buses, etc.

[0137] The processor 31 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 31 is the control center of the multi-cloud collaborative management device, connecting various parts of the device via various interfaces and lines.

[0138] The memory 32 can be used to store the computer programs and / or modules. The processor 31 implements various functions of the multi-cloud collaborative management device by running or executing the computer programs and / or modules stored in the memory 32 and calling the data stored in the memory 32. The memory 32 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 32 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0139] If the modules / units integrated by the multi-cloud collaborative management device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 31, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0140] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A multi-cloud collaborative management method, characterized in that, include: In response to the phase change of the multi-cloud collaborative task, based on the functional requirements involved in the multi-cloud collaborative task, a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement are elected from all participating organizations of the alliance. In response to the data access request under the multi-cloud collaborative task, obtain the data tag and reference role attribute of the data to be accessed; Based on the data access request, the data tag, and the reference role attribute, the requester generates an access strategy for the data to be accessed through the main coordinating agency and the corresponding dedicated coordinating agency.

2. The multi-cloud collaborative management method as described in claim 1, characterized in that, The functional requirements involved in the multi-cloud collaboration task include data processing, request compliance assessment, and access auditing. The dedicated coordination mechanism includes a data coordination mechanism, a policy coordination mechanism, and an audit coordination mechanism; wherein, the data coordination mechanism is used for uploading, encrypting, and computing data; the policy coordination mechanism is used for access permission assessment and compliance judgment; and the audit coordination mechanism is used for generating access logs and auditing and uploading the access logs to the blockchain.

3. The multi-cloud collaborative management method as described in claim 1, characterized in that, In response to the phase change of the multi-cloud collaborative task, based on the functional requirements involved in the multi-cloud collaborative task, a main coordinating body and dedicated coordinating bodies corresponding to each functional requirement are elected from all participating organizations in the alliance, including: In response to phase changes in multi-cloud collaborative tasks, obtain the task type of the multi-cloud collaborative task, the functional requirements at the current phase, and the operational status of each participating organization in the alliance; Based on the operational status, calculate the matching degree between each participating organization and the task type, and elect a main coordinating organization from all participating organizations based on the matching degree. Based on the operational status, a dedicated coordinating body is elected for each of the aforementioned functional requirements.

4. The multi-cloud collaborative management method as described in claim 3, characterized in that, The process involves calculating the matching degree between each participating organization and the task type based on the operational status, and electing a main coordinating organization from all participating organizations based on the matching degree, including: Based on the operating status, obtain the current load of each participating institution and the current resource health score of the cloud platform on which it is located; Based on the task type, obtain the priority weight of the role attributes of each organization for the multi-cloud collaborative task, and the degree of professional matching between each participating organization and the current task domain. The election score for each participating institution is calculated based on the current load, the current resource health score, the priority weight, and the professional matching degree. Based on the election scores, a chief coordinating body is elected from all participating bodies.

5. The multi-cloud collaborative management method as described in claim 1, characterized in that, The step of responding to a data access request under the multi-cloud collaborative task by obtaining the data tag and reference role attributes of the data to be accessed includes: In response to the data access request under the multi-cloud collaborative task, the identity attribute of the requester is obtained, and the role attribute bound to the identity attribute of the requester is obtained from the blockchain network; The data tags and reference role attributes of the data to be accessed are obtained from the file information chain of the blockchain network; the file information chain is used to record the core meta-information of all shared data in the consortium, and the core meta-information includes storage location, data tags, access policies and reference role attributes.

6. The multi-cloud collaborative management method as described in claim 5, characterized in that, The process of responding to a data access request under the multi-cloud collaborative task, obtaining the requester's identity attributes, and retrieving the role attributes bound to the requester's identity attributes from the blockchain network includes: Based on the data access request, the requester's identity attributes are obtained from the identity attribute chain of the blockchain network; the identity attribute chain is used to record the identity attributes of users in each participating institution. Based on the identity attribute, the role attribute bound to the identity attribute is obtained from the attribute mapping chain of the blockchain network; the attribute mapping chain is used to record the semantic equivalence mapping relationship of the identity attributes of users between different institutions.

7. The multi-cloud collaborative management method as described in claim 6, characterized in that, The method for updating the identity attribute chain includes: In response to a registration request from a newly added organization, the role system data of the newly added organization is obtained; the role system data includes the role attributes of each user in the newly added organization. The role system data is uploaded to the identity attribute chain of the blockchain network.

8. The multi-cloud collaborative management method as described in claim 6, characterized in that, The method for updating the attribute mapping chain includes: In response to an update to the identity attribute chain, retrieve the first role attributes of each user in an existing organization and the second role attributes of each user in a newly added organization from the attribute mapping chain; Calculate the first semantic similarity between the first role attribute and the second role attribute. If the first semantic similarity is greater than a preset similarity threshold, then map the user corresponding to the newly added organization to the attribute mapping chain. The second role attribute is bound to the identity attribute chain in the blockchain network.

9. The multi-cloud collaborative management method as described in claim 1, characterized in that, The step of generating an access strategy for the requester to access the data based on the data access request, the data tag, and the reference role attribute, through the main coordinating agency and the corresponding dedicated coordinating agency, includes: Based on the data access request, the requester's role attributes and access task tags are obtained; Calculate the second semantic similarity between the character attribute and the reference character attribute; The historical trust level is obtained based on the historical interaction data between the requester and the role corresponding to the reference role attribute; Calculate the semantic fit of the task based on the access task label and the data label; Based on the second semantic similarity, the historical trust level, and the task semantic fit, the dedicated coordination mechanism generates independent access strategies for each functional requirement. The main coordinating body integrates and coordinates the independent access policies to generate the requester's access policy for the data to be accessed.

10. A multi-cloud collaborative management method as described in claim 9, characterized in that, The process of integrating and coordinating the independent access policies through the main coordinating body to generate the requester's access policy for the data to be accessed includes: Determine whether there are conflicts between the independent access policies generated by each dedicated coordination agency; If there is no conflict, the independent access policies are integrated through the main coordinating body to generate the requester's access policy for the data to be accessed; If a conflict exists, the independent access policy is coordinated by the main coordinating agency according to the preset coordination agency priority under the multi-cloud collaborative task, and an access policy for the requester to access the data to be accessed is generated.

11. The multi-cloud collaborative management method as described in claim 1, characterized in that, When the data access request is an urgent data access request, the generated access policy is a temporary authorized access policy; after the independent access policies are integrated and coordinated through the main coordinating agency to generate the requester's access policy for the data to be accessed, the multi-cloud collaborative management method further includes: According to the temporary authorized access policy, temporary blocks are recorded in the blockchain network; the state of the temporary blocks is temporary. Within the preset waiting period, receive the approval result of the emergency data access request; If the approval result is passed, the status of the temporary block will be updated to effective. If the approval result is not approved, an authorization rollback operation is performed on the blockchain network, the temporary state is marked as invalid, and the record of the temporary block is transferred to the archive chain of the blockchain network.

12. The multi-cloud collaborative management method as described in claim 1, characterized in that, After the primary coordinating body integrates and coordinates the independent access policies to generate the requester's access policy for the data to be accessed, the multi-cloud collaborative management method further includes: According to the access policy, blockchain network authorization confirmation is performed. Once the authorization confirmation is successful, a token bound to the data to be accessed is generated, enabling the requester to access the data through the token. Once the access is complete, an access log entry is generated and written into the access record chain of the blockchain network.

13. A multi-cloud collaborative management system, characterized in that, include: The organization election module is used to respond to phase changes in multi-cloud collaborative tasks. Based on the functional requirements involved in the multi-cloud collaborative tasks, it elects the main coordinating organization and the dedicated coordinating organization corresponding to each functional requirement from all participating organizations in the alliance. The request and response module is used to respond to data access requests under the multi-cloud collaborative task and obtain the data tags and reference role attributes of the data to be accessed. The access policy generation module is used to generate an access policy for the requester to access the data based on the data access request, the data tag, and the reference role attribute, through the main coordinating agency and the corresponding dedicated coordinating agency.

14. A multi-cloud collaborative management device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the multi-cloud collaborative management method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the multi-cloud collaborative management method as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, perform the multi-cloud collaborative management method as described in any one of claims 1 to 12.

Images