Cross-domain data sharing method and cross-domain data sharing system

Abstract

The present application provides a cross-domain data sharing method and a cross-domain data sharing system. The sharing client determines the server link information according to the authorization license file generated by the authorization management platform, and then sends a sharing request to the sharing server corresponding to the server link information. The sharing server determines the domain of the sharing client, and determines the permission information corresponding to the target data based on the domain, and then starts a microservice container for the sharing client, generates corresponding sharing information according to the permission information, and returns it to the sharing client, so that the sharing client can access the target data in the microservice container, thereby realizing cross-domain data sharing, and can determine the permission in combination with the domain where the sharing client is located, so as to achieve the purpose of sharing according to the domain in a targeted manner, thereby ensuring the security and reliability of cross-domain data sharing, and can realize data isolation between users, further ensuring the security of data sharing.

Description

Technical Field

[0001] The present application relates to the technical field of data sharing, and in particular to a cross-domain data sharing method and a cross-domain data sharing system. Background Art

[0002] At present, with the continuous integration of artificial intelligence big model technology and high-performance computing and cloud computing technology, users may need to process the same data on multiple computing platforms such as intelligent computing, general computing, and supercomputing. At the same time, they also need to ensure that data access is secure and reliable and that permissions can be effectively guaranteed.

[0003] There are two main existing solutions. One is to copy the original data, for example, copy the data in the intelligent computing environment to the supercomputing environment, and then copy or move the results to the original location after processing. However, this method requires storage space, and the user operation is cumbersome, the data movement process takes a long time, and often causes data loss.

[0004] Another way is to share data using the Web. This method relies on Web services. However, due to the stateless nature of the Web, any browser can access the shared link after it is sent, making it difficult to ensure data security, especially for some sensitive data. Summary of the invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, the present application aims to provide a cross-domain data sharing method and a cross-domain data sharing system to solve the problems in the prior art such as high storage space requirements, cumbersome user operations, long data movement time, easy data loss and low data security.

[0006] The embodiment of the present application provides a cross-domain data sharing method, which is applied to a cross-domain data sharing system. The cross-domain data sharing system includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster. The method includes:

[0007] The sharing client determines the server link information based on the authorization license file generated by the authorization management platform, and sends a sharing request to the sharing server corresponding to the server link information;

[0008] The sharing server determines the domain of the sharing client in response to the sharing request, and determines the permission information corresponding to the target data based on the domain of the sharing client;

[0009] The sharing server starts a microservice container for the sharing client, generates sharing information corresponding to the target data according to the permission information, and returns the sharing information to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information.

[0010] Optionally, before determining the authority information corresponding to the target data based on the domain where the sharing client is located, the method further includes:

[0011] The sharing server determines whether the domain where the sharing client is located is the same as the domain where the sharing server is located;

[0012] If not, the sharing server obtains historical sharing record information, and determines the number of failed sharing requests in the domain where the sharing client is located based on the historical sharing record information;

[0013] The sharing server determines whether the number of failed sharing requests exceeds a preset number threshold, and if not, executes a step of determining permission information corresponding to the target data based on the domain where the sharing client is located.

[0014] Optionally, determining the permission information corresponding to the target data based on the domain where the sharing client is located includes:

[0015] The sharing server obtains the required access type and required access duration in the sharing request;

[0016] The sharing server determines the access duration, the number of access devices and the access type corresponding to the target data based on the number of failed sharing requests, the required access type and the required access duration, and obtains permission information.

[0017] Optionally, after determining the authority information corresponding to the target data based on the domain where the sharing client is located, the method further includes:

[0018] The sharing server determines the sensitivity of the target data;

[0019] The sharing server adjusts at least one of the access duration, the number of access devices, and the access type corresponding to the target data based on the sensitivity.

[0020] Optionally, after returning the shared information to the client, the method further includes:

[0021] In response to detecting that a user triggers a link in the shared information, the sharing client accesses the target data through the microservice container; or,

[0022] In response to detecting that a user inputs a target data path in the shared information and inputs the identity authentication information in the shared information, the sharing client mounts the target data to a local hard disk, and accesses the target data through the microservice container when the user accesses the local hard disk.

[0023] Optionally, accessing the target data through the microservice container includes:

[0024] The shared client requests to access the microservice container, the shared service end obtains the IP address of the shared client, and determines whether the shared client can access the microservice container based on the IP address;

[0025] If so, the shared client accesses the microservice container to access the target data in the mounted object storage data, block storage data, and file storage data through the unified storage mounting service provided by the microservice container.

[0026] Optionally, the method further includes:

[0027] The sharing client, in response to detecting the sharing instruction, determines the user information, the directory of the target data, the required access type and the required access duration in the sharing instruction, and generates the graphic information based on the user information, the directory, the required access type and the required access duration;

[0028] In response to detecting the scanning result of the graphic information, the authorization management platform generates an authorization license file.

[0029] Optionally, the authorization management platform generates an authorization license file in response to detecting a scan result for the graphic information, including:

[0030] In response to detecting the scan result, the authorization management platform determines whether the requested shared server in the scan result exists, and if so, determines an authorization string based on the scan result;

[0031] The authorization management platform encrypts the authorization string using a preset service key, and signs the encrypted authorization string using a preset service private key;

[0032] The authorization management platform converts the signed authorization string into an authorization code, and writes the authorization code into a file to obtain an authorization license file.

[0033] Optionally, the shared client determines the server link information based on the authorization license file generated by the authorization management platform, including:

[0034] In response to detecting the authorization license file, the shared client decrypts and verifies the signature of the authorization license file;

[0035] If both decryption and signature verification are successful, the shared client reads the user's device information and verifies the legitimacy of the device information. If the legitimacy verification is successful, the server link information is generated based on the cluster where the target data in the authorization license file is located and the path of the target data.

[0036] The embodiment of the present application further provides a cross-domain data sharing system, which includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster, wherein:

[0037] The sharing client is used to determine the server link information based on the authorization license file generated by the authorization management platform, and send a sharing request to the sharing server corresponding to the server link information;

[0038] The sharing server is used to determine the domain of the sharing client in response to the sharing request, and determine the permission information corresponding to the target data based on the domain of the sharing client; start a microservice container for the sharing client, and generate sharing information corresponding to the target data according to the permission information, and return the sharing information to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information.

[0039] The present application also provides an electronic device, the electronic device comprising:

[0040] Processor and memory;

[0041] The processor is used to execute the steps of the cross-domain data sharing method provided in any embodiment of the present application by calling the program or instruction stored in the memory.

[0042] An embodiment of the present application also provides a computer-readable storage medium, which stores a program or instruction, and the program or instruction enables a computer to execute the steps of the cross-domain data sharing method provided by any embodiment of the present application.

[0043] To summarize, the present application proposes a cross-domain data sharing method, in which the sharing client determines the server link information according to the authorization license file generated by the authorization management platform, and then sends a sharing request to the sharing server corresponding to the server link information. The sharing server responds to the sharing request, determines the domain of the sharing client, and determines the permission information corresponding to the target data based on the domain, and then starts a microservice container for the sharing client, generates sharing information corresponding to the target data according to the permission information, and returns it to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information, thereby realizing cross-domain data sharing, and can determine the permission in combination with the domain where the sharing client is located, so as to achieve the purpose of targeted sharing according to the domain, thereby ensuring the security and reliability of cross-domain data sharing. In this method, the shared client parses the server link information through the authorization license file to request data sharing, which can ensure the security of authorization and prevent data tampering. Moreover, by returning the shared information to the shared client, the shared client accesses the target data in the microservice container through the shared information without relying on Web services or copying data, thus solving the problems of high storage space requirements for data sharing, cumbersome user operations, long data movement time, easy data loss and low data security. In addition, in this method, a microservice container is started for each shared client for data access, which can achieve data isolation between users and further ensure the security of data sharing. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0045] Figure 1 is a schematic diagram of a cross-domain data sharing system provided in an embodiment of the present application;

[0046] Figure 2 is a flow chart of a cross-domain data sharing method provided in an embodiment of the present application;

[0047] Figure 3 This is a schematic diagram of a process for generating an authorization license file provided in an embodiment of the present application;

[0048] Figure 4 This is a schematic diagram of a process in which a sharing service end returns shared information provided by an embodiment of the present application;

[0049] Figure 5 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the invention are shown in the accompanying drawings.

[0051] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0052] As mentioned in the background technology, in view of the problems in the prior art, this application proposes a cross-domain data sharing method. The cross-domain data sharing method provided in the embodiment of this application is applied to a cross-domain data sharing system, which includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster.

[0053] like Figure 1 As shown, Figure 1 This is a schematic diagram of a cross-domain data sharing system provided by an embodiment of the present application. The cross-domain data sharing system includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster. The sharing client can be deployed on the user side, the sharing server can be deployed in each cluster of each domain, and the authorization management platform can communicate with the sharing client and the sharing server in each cluster.

[0054] The authorization management platform needs to pre-enter the information of the available shared server, such as the address, port, protocol type, request method, verification method, etc. of the shared server, which is generally an API interface. The authorization management platform can issue an authorization license file to the shared client. The shared client can use the received authorization license file to request data sharing from the shared server through a unified access interface (WebSocket or HTTPS), and then the shared server can access the user data (objects, files or blocks).

[0055] Figure 2 is a flow chart of a cross-domain data sharing method provided by an embodiment of the present application. Figure 2 , the cross-domain data sharing method specifically includes:

[0056] S110: The sharing client determines the server link information based on the authorization license file generated by the authorization management platform, and sends a sharing request to the sharing server corresponding to the server link information.

[0057] The authorization license file may be a file indicating that the sharing client is allowed to access the data. The authorization license file may include server link information, which may be used to describe the relevant information of the sharing server that the sharing client needs to link to, such as the cluster, address, etc. In addition to the server link information, the authorization license file may also include user information, the directory of the target data, the required access type, and the required access duration.

[0058] In an embodiment of the present application, the shared client may first request an authorization license file from the authorization management platform. In order to further ensure the security of authorization, the authorization management platform may first issue a message to the shared client. The information needs to be confirmed by the shared server. After the authorization management platform obtains the confirmation of the shared server, the authorization management platform may issue an authorization license file to the shared client.

[0059] In a specific implementation, the method provided in the embodiment of the present application further includes the following steps:

[0060] Step 11, in response to detecting the sharing instruction, the sharing client determines the user information, the directory of the target data, the required access type and the required access duration in the sharing instruction, and generates graphic information based on the user information, the directory, the required access type and the required access duration;

[0061] Step 12: The authorization management platform generates an authorization license file in response to detecting the scanning result for the graphic information.

[0062] In step 11, the user (data accessor) can initiate an instruction to obtain the authorization license file in the sharing client, that is, a sharing instruction. After the sharing client detects the sharing instruction, it determines the user information, the directory of the target data, the required access type, and the required access duration.

[0063] Among them, the target data is the data that the user wants to access, the required access type is the permission type that the user wants to access the target data, such as read-only, write-only, read-write, etc., and the required access duration is the duration that the user wants to access the target data.

[0064] Furthermore, the sharing client can generate graphic information based on the parsed user information, directory, required access type and required access duration. The graphic information can be a QR code or barcode. Of course, in addition to the graphic form, the sharing client can also generate other forms of information to be confirmed, such as links and files, and the sharing server will confirm the authorization.

[0065] In the embodiment of the present application, the purpose of the shared client generating graphic information is to facilitate the subsequent shared server to perform authorization confirmation by scanning the graphic information, thereby improving the authorization efficiency of the data owner, and also preventing the relevant data from being tampered with, thereby further ensuring the security of authorization.

[0066] Specifically, after the shared client generates the graphic information, the user can send the graphic information to the data owner through email or communication applications, and then the data owner can use the authorization management platform to scan the graphic information and obtain the scan result. Alternatively, after the shared client generates the graphic information, it can communicate with the authorization management platform and send the graphic information to the authorization management platform, and then the authorization management platform displays the confirmation information corresponding to the graphic information, and after the data owner confirms, scans the graphic information to obtain the scan result.

[0067] Furthermore, in step 12, the authorization management platform, in response to detecting the scanning result for the graphic information, can read the user information, the directory of the target data, the required access type and the required access duration in the graphic information, perform the authorization process, and generate an authorization license file.

[0068] Through the above steps 11 and 12, authorization and licensing based on graphic information can be implemented. The shared client can display the authorized content in a graphical form, and the authorization management platform can scan it, thereby ensuring the security of the authorized content and preventing it from being maliciously tampered with by other devices. At the same time, it can also improve the authorization efficiency.

[0069] With respect to the above step 12, in one example, the authorization management platform generates an authorization license file in response to detecting a scanning result for the graphic information, including the following steps:

[0070] Step 121, in response to detecting the scan result, the authorization management platform determines whether the requested shared server in the scan result exists, and if so, determines the authorization string based on the scan result;

[0071] Step 122: The authorization management platform encrypts the authorization string using the preset service key, and signs the encrypted authorization string using the preset service private key;

[0072] Step 123: The authorization management platform converts the signed authorization string into an authorization code, and writes the authorization code into a file to obtain an authorization license file.

[0073] In step 121, after the authorization management platform detects the scanning result for the graphic information, it can first determine whether the shared server corresponding to the target data requested in the scanning result exists. If not, it directly feeds back an error prompt information to prompt the error. If yes, it obtains the authorization string according to the scanning result. The authorization string can be a JSON string.

[0074] Furthermore, in step 122, the authorization management platform may encrypt the authorization string using a preset service key, such as using AES (Advanced Encryption Standard). After encryption, the authorization management platform signs the encrypted authorization string using a preset service private key, such as using RSA (Rivest-Shamir-Adleman, an asymmetric encryption algorithm).

[0075] After the signature is completed, in step 123, the authorization management platform converts the signed authorization string into an authorization code, such as BASE64 code, and the obtained authorization code can be written into a template file to obtain an authorization license file.

[0076] like Figure 3 As shown, Figure 3 This is a schematic diagram of the generation process of an authorization license file provided by an embodiment of the present application. Among them, the authorization management platform can first read the scan results and determine whether the shared server exists. If not, an error message is prompted. If it exists, the scan results are composed into a JSON string, and then the preset service key is used to encrypt the information using AES, and the preset service private key is used to sign the RSA private key, and finally BASE64 encoding is performed to generate an authorization license file.

[0077] Through the above steps 121 to 123, the generation of the authorization license file is realized. Before the generation, it is determined whether the sharing server exists, which can avoid invalid sharing requests and ensure sharing security. During the generation process, encryption, signing, encoding and other steps can ensure the security of the authorization license file to prevent information from being maliciously intercepted by other devices.

[0078] Specifically, after obtaining the authorization license file, the data owner can send the authorization license file to the data accessor via email or communication applications, and the data accessor then uploads the authorization license file to the shared client; alternatively, the authorization management platform can communicate with the shared client and directly send the authorization license file to the shared client.

[0079] Furthermore, after obtaining the authorization license file, the shared client can perform operations such as signature verification and decryption on the authorization license file to obtain the server link information.

[0080] In some implementations, the sharing client determines the server link information based on the authorization license file generated by the authorization management platform, including the following steps:

[0081] Step 21: In response to detecting the authorization license file, the shared client decrypts and verifies the signature of the authorization license file;

[0082] Step 21: If both decryption and signature verification are successful, the shared client reads the user's device information and verifies the legitimacy of the device information. If the legitimacy verification is successful, the server link information is generated based on the cluster where the target data is located in the authorization license file and the path of the target data.

[0083] Among them, in step 21, after the shared client detects the authorization license file, it can first decrypt and verify the signature. For example, use the preset service public key to verify the signature, and use the private key of the preset service key (the public key used for encryption and the private key used for decryption) to decrypt it. The preset service public key and the preset service key can be sent by the authorization management platform.

[0084] Furthermore, in step 22, if both the decryption and the signature verification are passed, the shared client can verify the legitimacy of the authorization license file, such as reading the user information in the authorization license file and the device information corresponding to the device on which the shared client is deployed, and verifying the legitimacy of the user information and the device information. If the verification is passed, the cluster where the target data is located and the path of the target data in the authorization license file are further read to generate the server link information.

[0085] In the above steps 21 and 22, after obtaining the authorization license file, the shared client performs steps such as decryption, signature verification, and legitimacy verification to obtain the server link information, which can ensure the security of the process and the accuracy of the server link information, thereby ensuring the reliability of data sharing.

[0086] In an embodiment of the present application, after determining the server link information, the shared client can send a sharing request to the shared server corresponding to the server link information. It should be noted that the shared client can be in the same domain as the shared server, or in a different domain, where the domain can be understood as a computing power center, and different computing power centers can adopt different architectures, such as AI computing power systems, cloud computing power systems, supercomputing systems and other computing power centers. For example, the shared client is deployed in an intelligent computing system, and the shared server is deployed in a supercomputing system. The shared client and the shared server belong to different domains, that is, cross-domain.

[0087] S120: The sharing server determines the domain of the sharing client in response to the sharing request, and determines permission information corresponding to the target data based on the domain of the sharing client.

[0088] Specifically, after receiving the sharing request, the sharing server may first determine the domain where the sharing client is located, and then determine the authority information corresponding to the target data according to the domain where the sharing client is located.

[0089] In the embodiment of the present application, in order to ensure the security of cross-domain data sharing, the domain where the sharing client is located may be verified before determining the permission information provided for the sharing client.

[0090] In a specific implementation manner, before determining the authority information corresponding to the target data based on the domain where the sharing client is located, the following steps are also included:

[0091] Step 31, the sharing server determines whether the domain where the sharing client is located is the same as its own domain;

[0092] Step 32: If not, the sharing server obtains historical sharing record information, and determines the number of failed sharing requests in the domain where the sharing client is located based on the historical sharing record information;

[0093] Step 33: The sharing server determines whether the number of failed sharing requests exceeds a preset threshold. If not, the server performs a step of determining the authority information corresponding to the target data based on the domain where the sharing client is located.

[0094] In step 31, the sharing server may first determine whether the domain where the sharing client is located is the same as its own domain, that is, whether the sharing client and the sharing server are in the same domain.

[0095] Furthermore, in step 32, if they are different, the sharing server can obtain historical sharing record information, thereby determining the number of failed sharing requests for the domain where the sharing client is located according to the historical sharing record information. The historical sharing record information can record the number of successful sharing requests and failed sharing requests for each domain.

[0096] Furthermore, in step 33, the sharing server determines whether the number of failed sharing requests exceeds a preset threshold. If so, it means that the domain where the sharing server is located has experienced a large number of failed requests, and the security of the domain may be extremely low. In this case, the sharing request can be refused to respond. Otherwise, the subsequent steps of determining the permission information can be executed to respond to the sharing request.

[0097] Through the above steps 31 to 33, before the sharing server responds to the sharing request of the sharing client, it can first determine whether they are located in the same domain. If they are different, the domain where the sharing client is located is verified by the number of failed sharing requests in the domain where the sharing client is located, so as to continue to respond to the sharing request when the domain is safe, further ensuring the security of cross-domain data sharing.

[0098] In some implementations, determining the permission information corresponding to the target data based on the domain where the sharing client is located includes the following steps:

[0099] Step 41: The sharing server obtains the required access type and required access duration in the sharing request;

[0100] Step 42: The sharing server determines the access duration, number of access devices and access type corresponding to the target data based on the number of failed sharing requests, the required access type and the required access duration, and obtains permission information.

[0101] In step 41, the sharing server may obtain the user's required access type and required access duration from the sharing request.

[0102] Furthermore, the sharing server can adjust the required access type and required access duration according to the number of failed sharing requests in the domain where the sharing client is located, obtain the access type and access duration, and determine the number of access devices according to the number of failed sharing requests to obtain permission information. The number of access devices is the maximum number of devices that can access the target data.

[0103] Exemplarily, when the number of failed sharing requests in the domain where the sharing client is located is greater than a set value, the sharing server can reduce the required access time to obtain the access time, and adjust the required access type (adjusted for the purpose of reducing permissions) to obtain the access type, wherein the amount of time reduction can be determined by the difference between the number of failed sharing requests and the set value. In addition, the sharing server can determine the number of access devices based on the comparison relationship between the number of failed sharing requests and the set value, such as, if the number of failed sharing requests is less than the set value, the more the number of access devices, and the number of failed sharing requests is greater than the set value, the fewer the number of access devices.

[0104] Through the above steps 41 and 42, it is possible to determine the permission information corresponding to the target data provided to the user based on the number of failed sharing requests based on the domain where the sharing client is located, and to flexibly allocate permissions according to different domains, so as to achieve the purpose of dynamically specifying authorization, ensure the security of permission provision, and further improve the security of access.

[0105] In the embodiment of the present application, considering the different importance of different data, the user's permission information may be appropriately adjusted for the core data to further ensure the security of the core data.

[0106] In an example, after determining the authority information corresponding to the target data based on the domain where the sharing client is located, the method further includes:

[0107] The sharing server determines the sensitivity of the target data; the sharing server adjusts at least one of the access duration, the number of access devices, and the access type corresponding to the target data based on the sensitivity.

[0108] Specifically, after the sharing server determines the authority information corresponding to the target data according to the domain of the sharing client, the sharing server can also determine the sensitivity of the target data. The sensitivity can reflect the importance of the target data, and the higher the importance, the higher the sensitivity.

[0109] Furthermore, the sharing server can adjust at least one of the access duration, the number of access devices, and the access type corresponding to the target data based on the sensitivity. For example, if the sensitivity is greater than a preset critical value, the access duration corresponding to the target data is reduced, or the number of access devices corresponding to the target data is reduced, or the access type corresponding to the target data is adjusted, or both the access duration and the number of access devices are reduced.

[0110] Through the above example, after the sharing server determines the permission information corresponding to the target data according to the domain, the permission information can be adjusted in combination with the sensitivity of the target data, which can further ensure the sharing security of the core data.

[0111] S130. The sharing server starts a microservice container for the sharing client, generates sharing information corresponding to the target data according to the permission information, and returns the sharing information to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information.

[0112] Specifically, the shared server can start a microservice container for the shared client, that is, start a microservice container for the user, and each user corresponds to a microservice container. The microservice container can be used to provide data access services for the user.

[0113] In addition, the sharing server can generate sharing information based on the permission information and return the sharing information to the sharing client. After receiving the sharing information, the sharing client can use the data access service provided by the microservice container to access the target data. The sharing information can be a link or the identity authentication information (such as user name and password) that the user needs to enter for local file mounting.

[0114] In an embodiment of the present application, in order to improve sharing security, after the sharing server starts a microservice container for the sharing client, the user identity can be verified in the microservice container, and then after the verification is passed, a unified storage mounting service is used to generate shared information such as a link to the target data. The user can subsequently perform operations such as reading and writing the target data in the microservice container.

[0115] For example, Figure 4 Schematic diagram of a process of returning shared information by a sharing service end provided in an embodiment of the present application. Figure 4 As shown, the link request of the sharing client can be sent to the sharing server through the API. After detecting the sharing link (HTTP / WebSocket) request of the sharing client, the sharing server can call the service layer interface to authenticate the user first, such as verification based on authorization information such as MAC address, user name, cluster, etc. After the verification is passed, the user sharing file microservice container is started for the user, and then the Rclone unified storage mounting service can be called to generate a link to the target data or generate relevant information for mounting the target data to the user's local hard disk. The user can read, write and other operations on the target data in the microservice container.

[0116] It should be noted that the target data may be data such as objects, file systems or block storage, and the embodiments of the present application do not limit this. The shared server can access data such as objects, file systems and block storage through a unified storage mounting service, and provide access services to shared clients through microservice containers to support multi-source data sharing.

[0117] In a specific implementation, after returning the shared information to the client, the method further includes:

[0118] The sharing client accesses the target data through the microservice container in response to detecting that the user triggers the link in the shared information;

[0119] Alternatively, in response to detecting the target data path entered by the user in the shared information and the identity authentication information entered in the shared information, the sharing client mounts the target data to the local hard disk, and accesses the target data through the microservice container when the user accesses the local hard disk.

[0120] Specifically, the user can directly click on the link in the shared information through the sharing client (Web), and the sharing client accesses the target data through the microservice container in response to detecting that the user triggers the link.

[0121] In addition to accessing the target data through a link, the user can also enter the target data path in the shared information and the identity authentication information in the shared information in the sharing client. In response to detecting the above information, the sharing client can mount the target data to the local hard disk, and the user can then access the local hard disk to access the target data.

[0122] During this process, the sharing client can also detect the cumulative duration of accessing the target data in real time and determine whether it exceeds the access duration corresponding to the target data. If so, it means that the access has expired, and the sharing server link can be stopped in time, and the sharing ends.

[0123] Through the above implementation, it is possible to access the target data based on the link, or to mount the target data to the local hard disk, thereby providing users with multiple access methods, thereby improving the user experience while ensuring the security of data sharing.

[0124] In one example, accessing target data through a microservice container includes the following steps:

[0125] Step 51: The shared client requests to access the microservice container, and the shared service end obtains the IP address of the shared client and determines whether the shared client can access the microservice container based on the IP address;

[0126] Step 52: If yes, the shared client accesses the microservice container to access the target data in the mounted object storage data, block storage data, and file storage data through the unified storage mounting service provided by the microservice container.

[0127] Specifically, the shared client can request access to the microservice container. Furthermore, the shared server can obtain the IP address of the shared client. The shared server can determine whether the IP address meets the conditions for accessing the microservice container. Exemplarily, network access rules can be specified in advance for each service through Kubernetes' Network Policy resources, such as which namespaces, labels, or IP segments can access the microservice container; and then the shared server can determine whether it can access the microservice container by determining whether the IP address belongs to a preset IP segment, or whether it is in a preset namespace, or whether the label of the shared client is the same as the preset label.

[0128] If the microservice container can be accessed, the shared client can access the target data in the mounted object storage data, block storage data, and file storage data through the unified storage mounting service provided by the microservice container. If they are different, it means that the shared client accessing the microservice container is wrong. At this time, it may be that other users are accessing the target data. At this time, the shared server can feedback error prompt information to the shared client.

[0129] Through the above steps 51 to 53, considering that the corresponding microservice container is started for each user, the source of access traffic can be restricted by policy. Even for microservice containers in the same cluster, only authorized users can access the specified microservice container. If other users try to access it, the shared server can refuse to respond and report an error, which further improves the security of data sharing and avoids data leakage.

[0130] In the cross-domain data sharing method provided by the embodiment of the present application, the sharing client determines the server link information according to the authorization license file generated by the authorization management platform, and then sends a sharing request to the sharing server corresponding to the server link information. The sharing server responds to the sharing request, determines the domain of the sharing client, and determines the permission information corresponding to the target data based on the domain, and then starts the microservice container for the sharing client, generates sharing information corresponding to the target data according to the permission information, and returns it to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information, thereby realizing cross-domain data sharing, and can determine the permission in combination with the domain where the sharing client is located, so as to achieve the purpose of sharing according to the domain in a targeted manner, thereby ensuring the security and reliability of cross-domain data sharing. In this method, the shared client parses the server link information through the authorization license file to request data sharing, forming a flexible authorization, safe and reliable, integrated and unified data sharing method, which meets the user needs in multiple scenarios, can ensure the security of authorization, and prevent data tampering. In addition, by returning the shared information to the shared client, the shared client accesses the target data in the microservice container through the shared information without relying on Web services or copying data, which solves the problems of high storage space requirements for data sharing, cumbersome user operations, long data movement time, easy data loss, and low data security. In addition, in this method, a microservice container is started for each shared client for data access, which can achieve data isolation between users and further ensure the security of data sharing.

[0131] The cross-domain data sharing method provided in the embodiment of the present application can enable data accessors and data owners to complete sharing through the following process: 1. The data accessor installs the sharing client locally and makes a sharing request (user, data directory, required access type, required access duration, etc.); 2. The data accessor receives the request QR code generated by the sharing client; 3. The data accessor sends the request QR code to the data owner; 4. The data owner uses the authorization management platform to read the QR code information, perform the authorization process (encryption, signing, etc.), and generate an authorization license file. At the same time, the relevant information of the device where the sharing client is located can be recorded in the database after the authorization is passed; 5. The data owner receives the authorization license file; 6. The data owner sends the authorization license file to the data accessor via WeChat or email; 7. The data accessor transfers the authorization license file to the sharing client, double-clicks the file, and automatically starts the sharing client. The client performs decryption, signature verification and other legitimacy verification, and reads the device information for legitimacy verification, and reads the data server link information for backup; 8. The sharing client requests the linked sharing server to share data according to the server link information read in the authorization license file, and the sharing server verifies the information and starts the file sharing service of user and directory permissions, and returns the sharing information. Among them, the sharing server can first determine whether the device where the sharing client is located is an authorized device based on the MAC address and other information stored in the database. If so, it starts the microservice container with the username and cluster; 9. The sharing client receives the sharing information, such as the link, username and password; 10. The sharing client uses the Web method or file mounting method to link and share data; among them, the sharing server can first verify the username and cluster of the microservice container. If the verification is passed, the sharing client can use the microservice container to access the target data. In addition, the sharing client can periodically detect the access time, stop the server link after expiration, and the sharing ends.

[0132] This method can support reliable data sharing that is tamper-proof, secure, device-bound, and time-limited; supports multiple data sharing methods, such as Web, file mounting, etc.; supports multi-level file permission sharing, such as file-level, object-level, and data-level read and write permissions; supports dynamic user-level multi-source data sharing services (user-level microservice method).

[0133] The embodiment of the present application further provides a cross-domain data sharing system, which includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster, wherein:

[0134] The sharing client is used to determine the server link information based on the authorization license file generated by the authorization management platform, and send a sharing request to the sharing server corresponding to the server link information;

[0135] The sharing server is used to determine the domain of the sharing client in response to the sharing request, and determine the permission information corresponding to the target data based on the domain of the sharing client; start a microservice container for the sharing client, and generate sharing information corresponding to the target data according to the permission information, and return the sharing information to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information.

[0136] On the basis of the above-mentioned implementation modes, optionally, the sharing server is also used to determine whether the domain where the sharing client is located is the same as its own domain; if not, obtain historical sharing record information, and determine the number of failed sharing requests in the domain where the sharing client is located based on the historical sharing record information; determine whether the number of failed sharing requests exceeds a preset threshold, and if not, execute the step of determining the permission information corresponding to the target data based on the domain where the sharing client is located.

[0137] On the basis of the above-mentioned implementation modes, optionally, the sharing server is also used to obtain the required access type and the required access duration in the sharing request; based on the number of failed sharing requests, the required access type and the required access duration, the access duration, the number of access devices and the access type corresponding to the target data are determined to obtain permission information.

[0138] Based on the above implementations, optionally, the shared server is also used to determine the sensitivity of the target data; and adjust at least one of the access duration, number of access devices, and access type corresponding to the target data based on the sensitivity.

[0139] Based on the above embodiments, optionally, the sharing client is also used to access the target data through the microservice container in response to detecting that a user triggers a link in the shared information; or, in response to detecting that a user inputs a target data path in the shared information and inputs identity authentication information in the shared information, mount the target data to a local hard disk, and access the target data through the microservice container when the user accesses the local hard disk.

[0140] Based on the above implementation modes, optionally, the shared client is further used to request access to the microservice container, and the shared service end is further used to obtain the IP address of the shared client, and determine whether the shared client end can access the microservice container based on the IP address;

[0141] If so, the shared client is further used to access the microservice container, so as to access the target data in the mounted object storage data, block storage data and file storage data through the unified storage mounting service provided by the microservice container.

[0142] Based on the above implementations, optionally, the sharing client is further used to, in response to detecting a sharing instruction, determine the user information, the directory of the target data, the required access type and the required access duration in the sharing instruction, and generate graphic information based on the user information, the directory, the required access type and the required access duration;

[0143] The authorization management platform is used to generate an authorization license file in response to detecting a scanning result for the graphic information.

[0144] On the basis of the above-mentioned implementation modes, optionally, the authorization management platform is also used to determine whether the shared server requested in the scan result exists in response to detecting the scan result, and if so, determine the authorization string based on the scan result; encrypt the authorization string using a preset service key, and sign the encrypted authorization string using a preset service private key; convert the signed authorization string into an authorization code, and write the authorization code into a file to obtain an authorization license file.

[0145] Based on the above-mentioned implementation modes, optionally, the shared client is also used to decrypt and verify the signature of the authorization license file in response to detecting the authorization license file; if the decryption and signature verification are passed, the device information of the user is read and the legitimacy of the device information is verified. If the legitimacy verification passes, the server link information is generated based on the cluster where the target data in the authorization license file is located and the path of the target data.

[0146] The cross-domain data sharing system provided in the embodiment of the present application can execute the steps in the cross-domain data sharing method provided in the method embodiment of the present application, and the execution steps and beneficial effects are no longer repeated here.

[0147] Figure 5 Schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 5 As shown, the electronic device 400 includes one or more processors 401 and a memory 402 .

[0148] The processor 401 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 400 to perform desired functions.

[0149] The memory 402 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may include, for example, a read-only memory (ROM), a hard disk, a flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 401 may run the program instructions to implement the cross-domain data sharing method of any embodiment of the present application described above and / or other desired functions. Various contents such as initial external parameters, thresholds, etc. may also be stored in the computer-readable storage medium.

[0150] In one example, the electronic device 400 may further include: an input device 403 and an output device 404, which are interconnected via a bus system and / or other forms of connection mechanisms (not shown). The input device 403 may include, for example, a keyboard, a mouse, etc. The output device 404 may output various information to the outside, including early warning prompt information, braking force, etc. The output device 404 may include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, etc.

[0151] Of course, to simplify, Figure 5 Only some of the components related to the present application in the electronic device 400 are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device 400 may also include any other appropriate components.

[0152] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the cross-domain data sharing method provided by any embodiment of the present application.

[0153] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0154] In addition, an embodiment of the present application may also be a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the processor executes the steps of the cross-domain data sharing method provided by any embodiment of the present application.

[0155] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0156] It should be noted that the terms used in this application are only for describing specific embodiments, rather than limiting the scope of this application. As shown in the specification and claims of this application, unless the context clearly indicates an exception, the words "one", "a", "a kind of" and / or "the" do not specifically refer to the singular, but may also include the plural. The terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method or device. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the presence of other identical elements in the process, method or device including the elements.

[0157] It should also be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present application. Unless otherwise clearly specified and limited, the terms "installed", "connected", "connected", etc. should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be an indirect connection through an intermediate medium, or it can be a connection between the two elements. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0158] This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and its core ideas of this application. The above is only the preferred implementation method of this application. It should be pointed out that due to the limitations of textual expression and the objective existence of infinite specific structures, ordinary technicians in this technical field can make several improvements, modifications or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes or combinations, or the direct application of the concept and technical solution of the invention to other occasions without improvement, should be regarded as the scope of protection of this application.

Claims

1. A cross-domain data sharing method, characterized in that: Applied to a cross-domain data sharing system, the cross-domain data sharing system includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster, the method includes: The sharing client determines the server link information based on the authorization license file generated by the authorization management platform, and sends a sharing request to the sharing server corresponding to the server link information; The sharing server determines the domain of the sharing client in response to the sharing request, and determines the permission information corresponding to the target data based on the domain of the sharing client; The shared service end starts a microservice container for the shared client, generates shared information corresponding to the target data according to the permission information, and returns the shared information to the shared client, so that the shared client can access the target data in the microservice container through the shared information, wherein the microservice container is used to provide data access services for users, each user corresponds to one microservice container, and the user performs read and write operations on the target data in the microservice container; After returning the shared information to the client, the method further includes: In response to detecting that a user triggers a link in the shared information, the sharing client accesses the target data through the microservice container; or, in response to detecting that a user inputs a target data path in the shared information and inputs identity authentication information in the shared information, the sharing client mounts the target data to a local hard disk, and when the user accesses the local hard disk, accesses the target data through the microservice container; The shared client accesses target data in the mounted object storage data, block storage data, and file storage data through the unified storage mounting service provided by the microservice container.

2. The method according to claim 1, characterized in that Before determining the authority information corresponding to the target data based on the domain where the sharing client is located, the method further includes: The sharing server determines whether the domain where the sharing client is located is the same as the domain where the sharing server is located; If not, the sharing server obtains historical sharing record information, and determines the number of failed sharing requests in the domain where the sharing client is located based on the historical sharing record information; The sharing server determines whether the number of failed sharing requests exceeds a preset number threshold, and if not, executes a step of determining permission information corresponding to the target data based on the domain where the sharing client is located.

3. The method according to claim 2, characterized in that Determining the authority information corresponding to the target data based on the domain where the sharing client is located includes: The sharing server obtains the required access type and required access duration in the sharing request; The sharing server determines the access duration, the number of access devices and the access type corresponding to the target data based on the number of failed sharing requests, the required access type and the required access duration, and obtains permission information.

4. The method according to claim 1, characterized in that: After determining the authority information corresponding to the target data based on the domain where the sharing client is located, the method further includes: The sharing server determines the sensitivity of the target data; The sharing server adjusts at least one of the access duration, the number of access devices, and the access type corresponding to the target data based on the sensitivity.

5. The method according to claim 1, characterized in that Accessing the target data through the microservice container includes: The shared client requests to access the microservice container, the shared server obtains the IP address of the shared client, and determines whether the shared client can access the microservice container based on the IP address; If so, the shared client accesses the microservice container to access the target data in the mounted object storage data, block storage data, and file storage data through the unified storage mounting service provided by the microservice container.

6. The method according to claim 1, characterized in that The method further comprises: The sharing client, in response to detecting the sharing instruction, determines the user information, the directory of the target data, the required access type and the required access duration in the sharing instruction, and generates the graphic information based on the user information, the directory, the required access type and the required access duration; In response to detecting the scanning result of the graphic information, the authorization management platform generates an authorization license file.

7. The method according to claim 6, characterized in that The authorization management platform generates an authorization license file in response to detecting a scanning result of the graphic information, including: In response to detecting the scan result, the authorization management platform determines whether the requested shared server in the scan result exists, and if so, determines an authorization string based on the scan result; The authorization management platform encrypts the authorization string using a preset service key, and signs the encrypted authorization string using a preset service private key; The authorization management platform converts the signed authorization string into an authorization code, and writes the authorization code into a file to obtain an authorization license file.

8. The method according to claim 7, characterized in that The shared client determines the server link information based on the authorization license file generated by the authorization management platform, including: In response to detecting the authorization license file, the shared client decrypts and verifies the signature of the authorization license file; If both decryption and signature verification are successful, the shared client reads the user's device information and verifies the legitimacy of the device information. If the legitimacy verification is successful, the server link information is generated based on the cluster where the target data in the authorization license file is located and the path of the target data.

9. A cross-domain data sharing system, characterized in that: The cross-domain data sharing system includes a sharing client, an authorization management platform, and a sharing server deployed in each cluster, wherein: The sharing client is used to determine the server link information based on the authorization license file generated by the authorization management platform, and send a sharing request to the sharing server corresponding to the server link information; The sharing server is used to determine the domain of the sharing client in response to the sharing request, and determine the permission information corresponding to the target data based on the domain of the sharing client; start a microservice container for the sharing client, and generate sharing information corresponding to the target data according to the permission information, and return the sharing information to the sharing client, so that the sharing client can access the target data in the microservice container through the sharing information, wherein the microservice container is used to provide data access services for users, each user corresponds to one microservice container, and the user performs read and write operations on the target data in the microservice container; In response to detecting that a user triggers a link in the shared information, the sharing client accesses the target data through the microservice container; or, in response to detecting that a user inputs a target data path in the shared information and inputs identity authentication information in the shared information, the sharing client mounts the target data to a local hard disk, and when the user accesses the local hard disk, accesses the target data through the microservice container; The shared client accesses target data in the mounted object storage data, block storage data, and file storage data through the unified storage mounting service provided by the microservice container.

Images