System for mutual authentication and security management between data hubs in edge-cloud collaborative environment

Abstract

The present invention relates to a mutual authentication and security management system between data hubs in an edge-cloud collaboration environment. It comprises: a first data hub that receives a user analysis request including a user-defined analysis code from a user node, performs verification, generates a first hash value of the user-defined analysis code, transmits a collaboration request including the user analysis request, the user-defined analysis code, and the first hash value to a second data hub, and generates a first signature for the completion of verification of the user analysis request and transmits it to an authentication server; a second data hub that generates a second hash value from the user-defined analysis code transmitted from the first data hub, compares it with the first hash value to confirm a match in hash values, performs verification of the collaboration request transmitted from the first data hub, generates a second signature for the completion of verification of the collaboration request, and transmits it to an authentication server; and an authentication server that verifies the first signature and the second signature and transmits the mutual authentication result to the first data hub and the second data hub. The second data hub executes the user-defined analysis code to perform data analysis only when the first hash value and the second hash value match and mutual authentication is approved by the authentication server.

Description

Technology Field

[0001] The present invention relates to a security technology for collaboration between data hubs in an edge-cloud environment, and more specifically, to a system that performs mutual authentication and data access control by applying a Zero Trust security model between data hubs during the collaboration process between an edge environment and a cloud environment. Background Technology

[0002] The recent rapid proliferation of edge devices and the advancement of cloud analytics technologies are fundamentally changing the structures of data collection, processing, and analysis in distributed environments. In particular, there is an increasing demand for distributed data hubs across various organizations and locations to collaborate in performing complex analyses, and these environments are evolving into structures that are more sensitive to security threats.

[0003] The following security issues exist in conventional edge-cloud hybrid environments.

[0004] First, it is difficult to ensure mutual trust due to the absence of an authentication structure between different security domains. In an environment where each data hub operates independent security policies, secure collaboration is impossible without a standardized mutual authentication mechanism. Existing PKI-based authentication relies on a hierarchical trust model where a trust relationship, once established, persists; this structure is vulnerable to insider threats and certificate theft, and limits collaboration between different domains.

[0005] Second, there is a lack of guarantees regarding the execution integrity of user-defined analysis code. The verification system for dynamically generated user-defined analysis code is inadequate, posing a risk of malicious code execution or unauthorized data access. In particular, there is no mechanism to verify code tampering in real-time during dynamic script execution, and insufficient isolation of the execution environment can threaten the security of the entire system. Furthermore, the lack of separation between code execution privileges and data access privileges poses a risk of privilege escalation beyond what is necessary.

[0006] Third, there is a lack of granular control over the scope of data or access permissions required for analysis requests. Simple Role-Based Access Control (RBAC) struggles to meet the complex permission requirements of dynamically changing collaborative environments. There is no mechanism to simultaneously apply multidimensional access control policies that account for data sensitivity, purpose of use, time constraints, and geographical limitations; this leads to issues such as the exposure of unnecessary data or the blocking of legitimate analysis.

[0007] Fourth, audit trails and separation of responsibility regarding collaboration results are difficult. Due to the lack of a system to integrally track and manage the activities of each hub in a distributed environment, it is difficult to analyze the cause and identify liability in the event of a security incident. When each hub manages logs independently, issues regarding log integrity and time synchronization arise, making it difficult to ensure visibility into the overall collaboration process. Furthermore, there are limitations in securing evidence for regulatory compliance and in conducting forensic analysis.

[0008] To address these issues, the Zero Trust security model is gaining attention. Based on the "Never Trust, Always Verify" principle, Zero Trust independently verifies every access request at every step, performing the same level of verification regardless of prior trust relationships or network locations. However, existing Zero Trust implementations primarily focus on user authentication and network access control, lacking effective strategies for complex collaboration scenarios such as dynamic code execution between data hubs.

[0009] Existing data sharing platforms operate within a single structure where authentication and execution are integrated, and most have adopted a method that allows only predefined code. However, modern collaboration demands the performance of various forms of analysis by combining user-defined dynamic code, notebook-based analysis environments, and external functions, which are difficult to protect with existing security structures.

[0010] Furthermore, as data generated from IoT, mobile edge devices, and industrial automation systems recently demands real-time analysis, a structure is becoming widespread where selective data processing and code execution take place at the edge, while the cloud performs large-scale computational processing and integrated analysis to complement this.

[0011] Against this backdrop, each data hub possesses independent security policies and authentication schemes, and when mutual collaboration is required, ensuring Zero Trust-based mutual authentication and execution integrity is a prerequisite. In particular, in complex environments where multiple data hubs simultaneously perform collaborative analysis, a structural security framework capable of verifying trust without the need for a third party is required. To this end, a new security architecture is needed in which each hub exchanges signature-based authentication data and performs Zero Trust-based mutual authentication through an authentication server. The problem to be solved

[0012] The technical problem that the present invention aims to solve is to provide a system and method capable of performing secure collaboration between data hubs belonging to different security domains in an edge-cloud collaboration environment through Zero Trust-based mutual authentication. means of solving the problem

[0013] A mutual authentication and security management system between data hubs according to an embodiment of the present invention for solving the above-mentioned technical problem comprises: a first data hub that receives a user analysis request including a user-defined analysis code from a user node, performs verification, generates a first hash value of the user-defined analysis code, transmits a collaboration request including the user analysis request, the user-defined analysis code, and the first hash value to a second data hub, and generates a first signature for the completion of verification of the user analysis request and transmits it to an authentication server; the second data hub that generates a second hash value from the user-defined analysis code transmitted from the first data hub, compares it with the first hash value to confirm a hash value match, performs verification of the collaboration request transmitted from the first data hub, generates a second signature for the completion of verification of the collaboration request, and transmits it to the authentication server; and the authentication server that verifies the first signature and the second signature and transmits the mutual authentication result to the first data hub and the second data hub.

[0014] The second data hub performs data analysis by executing the user-defined analysis code only when the first hash value and the second hash value match and mutual authentication approval is obtained from the authentication server.

[0015] The above user analysis request may include metadata comprising at least one of user information, security policy information, purpose of analysis execution, time of analysis request, and analysis target dataset information, together with the above user-defined analysis code.

[0016] The first data hub can perform static analysis on the user-defined analysis code to detect at least one of a malicious code pattern, an unauthorized API call, and an attempt to access an external network.

[0017] When the first data hub transmits the collaboration request to the second data hub, it may additionally include the first data hub identifier and the verification result for the user analysis request.

[0018] The above second data hub can determine whether execution is possible by comparing the previously verified standard analysis code with the above user-defined analysis code.

[0019] The second data hub above can dynamically configure a data cleanroom execution environment that executes the user-defined analysis code in an isolated environment.

[0020] The above data cleanroom execution environment is isolated from external networks, and only authorized data and code may be accessible.

[0021] The authentication server can verify the first signature with the public key of the first data hub and verify the second signature with the public key of the second data hub.

[0022] The above system may further include a log system that records the collaboration process between the first data hub and the second data hub.

[0023] The first data hub and the second data hub each operate in an independent security domain and can apply different security policies.

[0024] The second data hub can perform sensitive information masking and policy-based filtering before transmitting the data analysis results to the first data hub.

[0025] The first data hub above can perform sensitive information masking and policy-based filtering before transmitting the data analysis results to the user node. Effects of the invention

[0026] According to the present invention, secure collaboration between data hubs belonging to different security domains is possible in an edge-cloud collaboration environment through Zero Trust-based mutual authentication. Furthermore, code integrity is guaranteed and tampering and man-in-the-middle attacks can be prevented through the comparison of hash values ​​of user-defined analysis codes and signature-based authentication. Additionally, a high level of security can be maintained even in a distributed environment by having each data hub independently perform verification and an authentication server perform final mutual authentication. Moreover, sensitive information protection and anonymization can be enhanced through a cleanroom-based isolated execution environment, and audit trails and security policies can be improved by centrally managing logs for all authentication and execution processes. Brief explanation of the drawing

[0027] FIG. 1 is a diagram showing the overall configuration of a mutual authentication and security management system between data hubs according to one embodiment of the present invention. FIG. 2 is a sequence diagram showing the operation flow of a mutual authentication and security management system between data hubs according to an embodiment of the present invention. Specific details for implementing the invention

[0028] Then, with reference to the attached drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily implement the present invention.

[0029] The terms used in this specification are for describing embodiments and are not intended to limit the invention. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text. The terms "comprises" and / or "comprising" used in this specification do not exclude the presence or addition of one or more other components in addition to the components mentioned. Throughout the specification, the same reference numerals refer to the same components, and "and / or" includes each of the mentioned components and all combinations of one or more. Although terms such as "first," "second," etc., are used to describe various components, these components are not limited by these terms. These terms are used merely to distinguish one component from another. Therefore, the first component mentioned below may be the second component within the technical scope of the invention.

[0030] FIG. 1 is a diagram showing the overall configuration of a mutual authentication and security management system between data hubs according to one embodiment of the present invention.

[0031] Referring to FIG. 1, the system according to the present invention may include a user node (100), an edge data hub (200), a cloud data hub (300), an authentication server (400), and a log system (500).

[0032] The user node (100), edge data hub (200), cloud data hub (300), authentication server (400), and log system (500) can exchange various information and data through a communication network.

[0033] The communication network may include a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), the Internet, 2G, 3G, 4G, 5G, LTE mobile communication network, Wibro, satellite communication network, etc., and the communication method is not limited to wired or wireless and any communication method is acceptable.

[0034] A user node (100) is a subject requesting data analysis and can send a user analysis request, including user-defined analysis code and metadata, to an edge data hub (200) via a web-based interface or API.

[0035] In this specification, "User Defined Analysis Code" refers to executable code written by a user to perform analysis on a specific dataset in a data hub, and includes User Defined Functions (UDFs), analysis scripts in the form of notebooks, or data processing and analysis logic written in other programming languages. Such User Defined Analysis Code can be dynamically executed in the execution environment of the data hub to perform tasks such as data transformation, statistical analysis, and the application of machine learning models.

[0036] Here, the user analysis request includes a user-defined analysis code and may also include metadata such as user information, access rights, execution policies, whether it is a cleanroom request, and purpose tags (e.g., statistical purposes / non-identification analysis, etc.).

[0037] The edge data hub (200) can perform a primary verification of a user analysis request received from a user node (100) and send a collaboration request for collaboration with the cloud data hub (300). Specifically, before sending the collaboration request, the edge data hub (200) can perform pre-filtering to detect malicious code patterns, unauthorized API calls, and attempts to access external networks through static analysis and security filters on the user-defined analysis code. During the static analysis process, potential risk factors can be detected by analyzing the structure of the user-defined analysis code, threats can be identified by comparing it with known malicious code patterns, and it can be verified whether the code is authorized by comparing it with a list of allowed APIs and functions.

[0038] The edge data hub (200) can block execution or request modification if the user-defined analysis code includes access to an external network, access to local files, or unauthorized API calls.

[0039] When verification of a user analysis request is completed, the edge data hub (200) generates a hash value (first hash value) of a user-defined analysis code using a cryptographic hash function such as SHA-256 or SHA-512. Subsequently, a signature (first signature) for the completion of verification is generated using the private key of the edge data hub (200) using an asymmetric encryption algorithm such as RSA or ECDSA, and this can be transmitted to an authentication server (400). Depending on the embodiment, the subject of the first signature may be the first hash value, the user analysis request, or the analysis result of the user analysis request.

[0040] A collaboration request transmitted from the edge data hub (200) to the cloud data hub (300) may include a user analysis request containing a user-defined analysis code, a first hash value, and extended metadata including an edge data hub identifier and a verification result for the user analysis request.

[0041] The edge data hub (200) can perform post-filtering after receiving analysis results from the cloud data hub (300) and before delivering the analysis results to the user. In particular, the edge data hub (200) can perform sensitive information masking and policy-based filtering according to its own security policy, and deliver only results that meet the user's authority and the edge data hub's security requirements to the user node (100).

[0042] The cloud data hub (300) can perform a second verification of the collaboration request received from the edge data hub (200) and execute actual data analysis. First, the cloud data hub (300) can generate a hash value (second hash value) from the received user-defined analysis code and check whether there has been any tampering during transmission by comparing it with the first hash value transmitted from the edge data hub (200). If the hash values ​​match, it can determine whether execution is possible by comparing them with a previously verified standard analysis code.

[0043] Here, the standard analysis code is a set of secure analysis codes that have been verified and approved in advance by the cloud data hub (300), and may include standard analysis patterns such as statistical analysis, data transformation, and approved machine learning algorithms.

[0044] When the verification of the collaboration request is completed, the cloud data hub (300) can generate a signature (second signature) of the verification completion using its own private key and send it to the authentication server (400).

[0045] The cloud data hub (300) evaluates execution rights and data access rights based on metadata. In this process, policy-based access control can be performed by considering metadata such as user roles, organizations, purpose of use, and time conditions, as well as internal metadata such as data sources, permission tags, and sensitivity levels.

[0046] When mutual authentication of the signatures of both data hubs (200, 300) is completed at the authentication server (400), the cloud data hub (300) can dynamically create a cleanroom execution environment isolated inside.

[0047] The cleanroom execution environment is configured based on containers or virtual machines (VMs) and can be configured to be completely isolated from the external network. It can be implemented so that only verified user-defined analysis code (UDF or notebook) and data filtered according to policies are injected into the cleanroom execution environment, and the code execution process can be monitored in real time and all logs can be recorded.

[0048] When data analysis according to user-defined analysis code is completed in a cleanroom execution environment, the cloud data hub (300) can perform sensitive information masking and policy-based filtering on the execution results according to its own security policy. This may include data access control policies, sensitive information masking rules, time-based access conditions, etc., and is intended for data protection requirements and regulatory compliance on the side of the cloud data hub (300).

[0049] Analysis results filtered according to cloud-side policies in the cloud data hub (300) can be transmitted to the edge data hub (200), then filtered again according to edge-side policies in the edge data hub (200) and provided to the user node (100).

[0050] The authentication server (400) can perform mutual authentication by verifying the signatures received from the edge data hub (200) and the cloud data hub (300), respectively.

[0051] The authentication server (400) can verify the validity of the signature, timestamp, issuer information, etc., during the process of verifying the signature using the public key of each data hub (200, 300). The authentication server (400) may approve mutual authentication only when both signatures are valid, issue an authentication token, and transmit the result to each data hub (200, 300).

[0052] The authentication server (400) manages the public keys and certificates of all registered data hubs, manages the lifecycle of authenticated sessions, and can perform the issuance and verification of one-time tokens. All authentication requests and results from the authentication server (400) can be transmitted to the log system (500) for audit trail.

[0053] The authentication server (400) can be implemented to operate in the following manner according to the core principles of the Zero Trust security model.

[0054] First, perform stateless authentication.

[0055] Each authentication request is processed independently and does not rely on previous authentication results or session information, thereby preventing a single authentication success from leading to continuous trust.

[0056] Second, perform real-time verification

[0057] Public keys in the data hub are retrieved in real-time from a central public key registry, rather than being pre-stored static information. The current status of the relevant public key (active, revoked, expired) can be checked immediately.

[0058] Third, the Principle of Least Privilege

[0059] Even if authentication is successful, minimal privileges are granted only for that session, and it is implemented to require new authentication for each collaboration request.

[0060] The authentication server (400) can be implemented to immediately record a timestamp upon receiving a signature and to review the freshness of the signature according to a predefined validity period standard. Signatures that have expired are automatically rejected. The authentication server (400) can query the currently valid public key of the corresponding data hub in real time from a central public key registry. This process does not rely on cached information and is always based on the latest status. The authentication server (400) can verify whether the public key is valid at the current time by checking the validity period and revocation list (CRL) of the queried public key. Additionally, the authentication server (400) can perform cryptographic verification of the signature to confirm that the signature was actually generated using the private key of the corresponding data hub. The authentication server (400) can issue a one-time authentication token only if all verification steps have been passed. This token is valid only within the corresponding collaboration session and cannot be reused.

[0061] The log system (500) can centrally manage collaboration processes such as the authentication process of the entire system, code execution history, and policy evaluation results. This enables audit trails, security policy improvements, and anomaly detection.

[0062] FIG. 2 is a sequence diagram showing the operation flow of a mutual authentication and security management system between data hubs according to an embodiment of the present invention.

[0063] Referring to FIG. 2, first, a user node (100) can generate a user-defined analysis code to execute an analysis on a dataset to be analyzed (S201), and transmit a user analysis request including the generated user-defined analysis code and metadata to an edge data hub (200) (S203). Here, the metadata may include user information (user ID, authentication token), security policy information (execution authority, access authority), purpose of analysis execution (e.g., statistical purpose, non-identification analysis), time of analysis request, and information on the dataset to be analyzed.

[0064] Next, the edge data hub (200) can perform verification of the user analysis request (S205). In step (S205), the verification of the user analysis request includes verification of the user-defined analysis code.

[0065] When the verification of the user analysis request is completed in step (S205), the edge data hub (200) can generate a hash value (Hash B) and a first signature (Sign B) of the user-defined analysis code (S207). Here, the first signature is intended to prove that the edge data hub (200) has completed the verification of the user analysis request, and can be generated using the private key of the edge data hub (200) for predetermined data (e.g., hash value (Hash B), edge hub identifier, verification result code, or a combination thereof).

[0066] Subsequently, the edge data hub (200) transmits the first signature (Sign B) to the authentication server (400) (S209), and can also transmit a collaboration request including a user analysis request, a user-defined analysis code, a first hash value, and extended metadata to the cloud data hub (300) to request verification (S211). Here, the extended metadata may be the metadata transmitted by the user with the edge data hub identifier and the verification result for the user analysis request added.

[0067] Next, the cloud data hub (300) can perform verification on the collaboration request received from the edge data hub (200) (S213). In step (S213), the verification of the collaboration request includes verification of the user-defined analysis code. Specifically, a second hash value can be generated from the user-defined analysis code and the code integrity can be verified by comparing it with the first hash value. If the hash values ​​match, the feasibility of execution can be determined by comparing it with a previously verified standard analysis code. In addition, the cloud data hub (300) may be implemented to perform additional pre-determined verification on the collaboration request.

[0068] When the verification of the collaboration request is completed in step (S213), the cloud data hub (300) can generate a second signature (Sign A) using its own private key (S215) and send it to the authentication server (400) to request verification (S217). The second signature is intended to prove that the cloud data hub (300) has completed the verification of the collaboration request, and can be generated using the cloud data hub's (300) private key for predetermined data (e.g., hash value (Hash A), cloud data hub identifier, verification result code, or a combination thereof).

[0069] Next, the authentication server (400) can perform mutual authentication on both sides' signatures by verifying the first signature and the second signature with the public keys of each data hub (200, 300) (S219). Afterwards, the authentication server (400) can transmit the mutual authentication approval result (authentication token) to the edge data hub (200) and the cloud data hub (300) (S221, S223).

[0070] Afterwards, if the cloud data hub (300) receives mutual authentication approval from the authentication server (400) and the first hash value and the second hash value match, it can dynamically create a cleanroom execution environment within the cloud data hub (300) and execute user-defined analysis code to perform data analysis (S227).

[0071] Next, the data analysis results from the cloud data hub (300) can be transmitted to the edge data hub (200) after undergoing sensitive information masking and policy-based filtering according to the cloud data hub's own security policy (S229). In this filtering process, personal information, confidential information, etc., may be masked or removed according to the cloud's data protection requirements, regulatory compliance, and data sensitivity level.

[0072] Then, the edge data hub (200) can provide the data analysis results received from the cloud data hub (300) to the user node (100) after additionally performing sensitive information masking and policy-based filtering according to the edge data hub's own security policy (S231). In this process, additional information filtering may be performed according to the user's access rights, roles, and edge-side security requirements. Through this dual filtering structure, each data hub can apply its own security policy in an independent security domain, while multi-layered security is implemented overall, thereby strengthening the protection of sensitive information.

[0073] Meanwhile, logs regarding mutual authentication history between the two data hubs (200, 300) through the authentication server (400) and data analysis execution history in the cloud data hub (300) can all be recorded in the log system (500) (S225, S233).

[0074] The embodiments described above may be implemented as hardware components, software components, and / or combinations of hardware and software components. For example, the devices, methods, and components described in the embodiments may be implemented using one or more general-purpose computing devices or special-purpose computing devices, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing device may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing device may be described as being used as a single one, but those skilled in the art will understand that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are also possible.

[0075] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0076] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

[0077] Although the embodiments have been described above with reference to the limited drawings, those skilled in the art can apply various technical modifications and variations based on the above. For example, suitable results may be achieved even if the described techniques are performed in a different order than described, and / or if the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

Claims

Claim 1 A first data hub that receives a user analysis request including a user-defined analysis code from a user node, performs verification, generates a first hash value of the user-defined analysis code, transmits a collaboration request including the user analysis request, the user-defined analysis code, and the first hash value to a second data hub, and generates a first signature for the completion of verification of the user analysis request and transmits it to an authentication server; a second data hub that generates a second hash value from the user-defined analysis code transmitted from the first data hub, compares it with the first hash value to confirm a hash value match, performs verification of the collaboration request transmitted from the first data hub, generates a second signature for the completion of verification of the collaboration request, and transmits it to the authentication server; and an authentication server that verifies the first signature and the second signature and transmits the mutual authentication result to the first data hub and the second data hub, wherein the second data hub is isolated, blocked from an external network, and accessible only to approved data and code, only when the first hash value and the second hash value match and mutual authentication is approved by the authentication server. A mutual authentication and security management system between data hubs characterized by dynamically configuring a data cleanroom execution environment and performing data analysis by executing the user-defined analysis code in the data cleanroom execution environment. Claim 2 A mutual authentication and security management system between data hubs according to claim 1, wherein the user analysis request comprises metadata including at least one of user information, security policy information, purpose of analysis execution, time of analysis request, and analysis target dataset information, together with the user-defined analysis code. Claim 3 A mutual authentication and security management system between data hubs according to claim 1, wherein the first data hub performs static analysis on the user-defined analysis code to detect at least one of a malicious code pattern, an unauthorized API call, and an attempt to access an external network. Claim 4 A mutual authentication and security management system between data hubs according to claim 1, wherein the first data hub additionally includes and transmits the first data hub identifier and the verification result for the user analysis request when transmitting the collaboration request to the second data hub. Claim 5 A mutual authentication and security management system between data hubs according to claim 1, wherein the second data hub determines whether execution is possible by comparing a pre-verified standard analysis code with the user-defined analysis code. Claim 6 delete Claim 7 A mutual authentication and security management system between data hubs according to claim 1, wherein the authentication server verifies the first signature with the public key of the first data hub and verifies the second signature with the public key of the second data hub. Claim 8 A mutual authentication and security management system between data hubs according to claim 1, characterized in that the system further includes a log system that records the collaboration process between the first data hub and the second data hub. Claim 9 A mutual authentication and security management system between data hubs according to claim 1, wherein the first data hub and the second data hub each operate in an independent security domain and apply different security policies. Claim 10 A mutual authentication and security management system between data hubs according to claim 1, wherein the second data hub performs sensitive information masking and policy-based filtering before transmitting the data analysis results to the first data hub, and the first data hub performs sensitive information masking and policy-based filtering before transmitting the data analysis results to the user node. Claim 11 A first data hub receives a user analysis request containing a user-defined analysis code from a user node and performs verification; the first data hub generates a first hash value of the user-defined analysis code; the first data hub transmits a collaboration request including the user analysis request, the user-defined analysis code, and the first hash value to a second data hub; the first data hub generates a first signature for the completion of verification of the user analysis request and transmits it to an authentication server; the second data hub generates a second hash value from the user-defined analysis code transmitted from the first data hub and compares it with the first hash value to confirm a hash value match; the second data hub performs verification of the collaboration request transmitted from the first data hub; the second data hub generates a second signature for the completion of verification of the collaboration request and transmits it to the authentication server; the authentication server verifies the first signature and the second signature and transmits the mutual authentication result to the first data hub and the second data hub. A method for mutual authentication and security management between data hubs, comprising the step of dynamically configuring an isolated data cleanroom execution environment in which only approved data and code are accessible and which is blocked from an external network, when the first hash value and the second hash value match and mutual authentication approval is obtained from the authentication server, and executing the user-defined analysis code in the data cleanroom execution environment to perform data analysis. Claim 12 A method for mutual authentication and security management between data hubs according to claim 11, wherein the step of receiving a user analysis request and performing verification includes the step of performing static analysis on the user-defined analysis code to detect at least one of a malicious code pattern, an unauthorized API call, and an attempt to access an external network. Claim 13 A method for mutual authentication and security management between data hubs according to claim 11, wherein the step of transmitting the collaboration request to the second data hub includes the step of transmitting the collaboration request with the first data hub identifier and the verification result for the user analysis request added thereto. Claim 14 A method for mutual authentication and security management between data hubs according to claim 11, wherein the step of performing verification of the collaboration request includes the step of determining whether the second data hub can execute by comparing a pre-verified standard analysis code with the user-defined analysis code. Claim 15 delete Claim 16 A method for mutual authentication and security management between data hubs according to claim 11, wherein the step of verifying the first signature and the second signature and transmitting the mutual authentication result comprises: the step of the authentication server verifying the first signature with the public key of the first data hub; the step of the authentication server verifying the second signature with the public key of the second data hub; and the step of approving mutual authentication when both signatures are valid. Claim 17 A method for mutual authentication and security management between data hubs according to claim 11, wherein the method further comprises: a step in which, after performing the data analysis, the second data hub performs sensitive information masking and policy-based filtering according to its own security policy on the analysis results; and a step in which the first data hub performs sensitive information masking and policy-based filtering according to its own security policy on the filtered analysis results received from the second data hub and then transmits them to the user node. Claim 18 A method for mutual authentication and security management between data hubs according to claim 11, characterized in that the method further includes the step of recording the collaboration process between the first data hub and the second data hub in a log system. Claim 19 A method for mutual authentication and security management between data hubs according to claim 11, wherein the user analysis request comprises metadata including at least one of user information, security policy information, purpose of analysis execution, time of analysis request, and analysis target dataset information, together with the user-defined analysis code. Claim 20 A method for mutual authentication and security management between data hubs according to claim 11, wherein the first data hub and the second data hub each operate in an independent security domain and apply different security policies.

Images