Data security protection system

Abstract

According to an embodiment of the present disclosure, a system, method, electronic device, storage medium, and program product for data security protection are provided. The system includes a security computing subsystem configured to manage the security of a development code and compile the development code into an installation file corresponding to a target app and a service program for supporting the target app, a data exchange subsystem configured to manage data communication between the target app or the service program and overseas, and a security sandbox subsystem configured to manage network traffic related to the target app. According to such a scheme, the embodiment of the present disclosure can ensure the security and compliance of data related to the target app.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to a Chinese patent application bearing application number 202111258238.0, entitled "System for Data Security Protection," and filed on October 27, 2021, the entire contents of which are incorporated herein by reference.

[0002] TECHNICAL FIELD Implementations of the present disclosure relate to the computer field, and more particularly to systems, methods, electronic devices, and computer storage media for data security. [Background technology]

[0003] With the development of Internet technology, various Internet applications have become an important part of people's lives. These applications generate a large amount of data every day, which raises data security issues in various aspects, such as data sovereignty protection. For example, some countries may prohibit certain types of user data from being sent to overseas servers.

[0004] This challenge is even more pronounced for some globalized applications, which may need to serve users in multiple different regions based on the same technical architecture. However, these regions may have completely different data security constraints, such as specific data sovereignty protection requirements, which makes data security even more difficult. Summary of the Invention

[0005] A first aspect of the present disclosure provides a data security management system, including a security computing subsystem configured to manage security of development code and compile the development code into an installation file corresponding to a target app and a service program for supporting the target app, a data exchange subsystem configured to manage data communication between the target app or the service program and overseas, and a security sandbox subsystem configured to manage network traffic related to the target app.

[0006] A second aspect of the present disclosure provides a data security management method, including: managing security of development code by a security computing subsystem and compiling the development code into an installation file corresponding to a target app and a service program for supporting the target app; managing data communication between the target app or the service program and overseas by a data exchange subsystem; and managing network traffic related to the target app by a security sandbox subsystem.

[0007] A third aspect of the present disclosure provides an electronic device, the device including a memory and a processor, the memory adapted to store one or more computer instructions, the one or more computer instructions being executable by the processor to implement a method according to the second aspect of the present disclosure.

[0008] A fourth aspect of the present disclosure provides a computer-readable storage medium having stored thereon one or more computer instructions, the one or more computer instructions being executable by a processor to perform a method according to the second aspect of the present disclosure.

[0009] A fifth aspect of the present disclosure provides a computer program product comprising one or more computer instructions, which when executed by a processor cause to perform a method according to the second aspect of the present disclosure. [Brief explanation of the drawings]

[0010] These and other features, advantages, and aspects of the embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the drawings, in which like or similar drawing legends represent like or similar elements, and in which: [Figure 1] 1 shows a schematic block diagram of a system for data security protection according to an embodiment of the present disclosure. [Figure 2] 1 illustrates a schematic block diagram of a computing security subsystem according to some embodiments of the present disclosure. [Figure 3A] 1 illustrates an exemplary deployment environment into which a data exchange subsystem may be deployed according to some embodiments of the present disclosure. [Figure 3B] DES implementations in an internal data center (IDC) at the TTP side and an internal data center (RoW IDC) where non-TTPs are located, according to some embodiments of the present disclosure, are shown. [Figure 3C] 1 illustrates a block diagram of an example architecture of a DE according to some embodiments of the present disclosure. [Figure 3D] 1 illustrates a flowchart of a data exchange process according to some embodiments of the present disclosure. [Figure 3E] 1 illustrates an exemplary data stream flow chart of various data processing implemented in a DES according to some embodiments of the present disclosure. [Figure 3F] 1 illustrates a schematic block diagram of a data exchange architecture for an MQ channel according to some embodiments of the present disclosure. [Figure 3G] 1 illustrates a schematic block diagram of a data exchange architecture for an HDFS channel according to some embodiments of the present disclosure. [Figure 3H]1 illustrates a schematic diagram of a target object store (TOS) channel for copying data from a TTP IDC to an overseas IDC according to some embodiments of the present disclosure. [Figure 3I] 1 illustrates a schematic diagram of a TOS channel for copying data from an overseas IDC to a TTP IDC according to some embodiments of the present disclosure. [Figure 3J] 1 illustrates a message sequence diagram for a TOS channel according to some embodiments of the present disclosure. [Figure 3K] 1 illustrates a schematic block diagram of a data exchange architecture for a service invocation channel according to some embodiments of the present disclosure. [Figure 3L] 1 illustrates an example of non-TTP to TTP data exchange in a service invocation channel according to some embodiments of the present disclosure. [Figure 3M] 1 illustrates an example of TTP to non-TTP data exchange in a service invocation channel according to some embodiments of the present disclosure. [Figure 4A] 1 illustrates a flowchart of a method for managing network traffic of a mobile edge application according to some embodiments of the present disclosure. [Figure 4B] 1 illustrates a schematic diagram of an analysis and restriction process for native-type network traffic according to some embodiments of the present disclosure. [Figure 4C] 1 illustrates a schematic diagram of an analysis and restriction process for web page view type network traffic according to some embodiments of the present disclosure. [Figure 4D] 1 illustrates a schematic diagram of an analysis and restriction process for third-party SDK-type network traffic according to some embodiments of the present disclosure. [Figure 4E] 1 illustrates a modular diagram of a security sandbox subsystem according to some embodiments of the present disclosure. [Figure 5] 1 illustrates a flowchart of an example process for managing recommendation policies according to some embodiments of the present disclosure. [Figure 6]1 illustrates a flowchart of an exemplary process for data security management according to some embodiments of the present disclosure. [Figure 7] 1 illustrates a block diagram of an exemplary device that can be used to implement embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following describes in more detail the embodiments of the present disclosure with reference to the drawings. Although several embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be realized in various forms and should not be construed as being limited to the embodiments described herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the protection scope of the present disclosure.

[0012] In describing embodiments of the present disclosure, the term "comprises" and similar terms should be understood as an open inclusion, i.e., "including, but not limited to." The term "based on" should be understood as "based at least in part on." The terms "in one embodiment" or "in this embodiment" should be understood as "at least one embodiment." The terms "first," "second," etc. may refer to different or the same object. The following may include other explicit and implicit definitions.

[0013] The basic principles and some exemplary implementations of the present disclosure will now be described with reference to the drawings.

[0014] Overall architecture of the system for data security protection According to an embodiment of the present disclosure, a system for data security protection is provided. Fig. 1 shows a schematic block diagram of a system 1000 for data security protection according to an embodiment of the present disclosure. As shown in Fig. 1, the system 1000 for data security protection includes multiple subsystems for protecting the security of related data generated in the process of a user using a target app from different dimensions.

[0015] Generally, to support the operation of the target app, on the one hand, a user needs to be able to run the target app 1080, for example, through an appropriate electronic device, and on the other hand, it is also necessary to deploy the target app platform 1030 in an appropriate computing environment (e.g., a cloud computing environment), for example, to run various types of services to support the normal operation of the target app 1080.

[0016] In some embodiments, the system for data security protection 1000 may first ensure the security of data generated during the operation of the target app 1090 from the perspective of the security of the operating code. As shown in FIG. 1 , the system for data security protection 1000 may include a security computing subsystem 1060, which may be used to ensure the security of the code corresponding to the target app 1080 and the security of the code corresponding to the target app platform 1030.

[0017] The service operation file compiled by the computing subsystem 1060 may be deployed to, for example, the target application platform 1030, and the target application installation file (e.g., apk file) compiled by the computing subsystem 1060 may be released to, for example, the app mall 1120. A specific implementation of the security computing subsystem 1060 will be discussed in detail below in conjunction with FIG. 2.

[0018] 1, security computing subsystem 1060 may be based on cloud infrastructure 1070. In some embodiments, cloud infrastructure 1070 may be provided by, for example, a trusted partner. In this disclosure, a "trusted partner" may be referred to as a Trusted Technology Partner (TTP), which may include, for example, any individual, company, or organization that is trusted with technology within a particular domain (e.g., a particular country or jurisdiction).

[0019] 1, a system 1000 for data security protection may include a trusted security environment 1010 provided by a TTP. Unlike traditional application platform deployments, a target application platform 1030 may be deployed in the trusted security environment 1010 to improve the security of data generated by the target application platform 1030 and the transparency and reliability of its operation mechanism.

[0020] In some embodiments, the target app 1080 may provide a content recommendation service to a user through a recommendation algorithm. Such content recommendations may include, but are not limited to, multimedia content recommendations, user recommendations, product recommendations, etc. Considering that an increasing number of recommendation systems currently utilize machine learning to implement recommendation functions, managing recommendation mechanisms solely through code may make it difficult to ensure the fairness of recommendations.

[0021] 1 , the system for data security protection 1000 may further include a recommendation management subsystem 1050, which can ensure the fairness of the recommendation mechanism in the target app 1080, for example, by testing the recommendation algorithm run by the target app platform 1030. A specific implementation of the recommendation management subsystem 1050 will be described in detail below.

[0022] In some embodiments, when target app platform 1030 is considering running services to support the normal operation of target app 1080, target app platform 1030 may need to interact with apps or data centers (also referred to as overseas apps or overseas data centers) outside the target region (e.g., a particular country or jurisdiction) in which it is currently deployed.

[0023] Typically, the target region typically has laws or regulations restricting the communication of data originating within the region with overseas entities. Certain types of data originating within the target region may be prohibited from being distributed overseas. To ensure compliance during communication between the target app platform 1030 and overseas entities, the data security protection subsystem may include a data exchange subsystem 1040. Similarly, the data exchange subsystem 1040 may be deployed in a trusted security environment 1010 to ensure the transparency and reliability of its operation.

[0024] In some embodiments, as shown in Figure 1, data exchange subsystem 1040 may include multiple data channels for different types of data transmission. For example, multimedia data originating in target app platform 1030 may be communicated to overseas app 1140 and / or overseas data center 1150 via, for example, a content delivery network 1130 provided by a third party via a corresponding data channel in data exchange subsystem 1040.

[0025] As another example, certain internal data generated in some target application platforms 1030 can be communicated with overseas data centers 1150 and overseas development departments 1160 via corresponding data channels, for example, via directly connected optical cables. A specific implementation of the data exchange subsystem 1040 will be described in detail below in conjunction with Figures 3A to 3M.

[0026] Additionally, to ensure the security of egress and ingress communications to and from the target app platform 1030, in some embodiments, the data security subsystem 1000 may further include an app firewall subsystem 1020. The app firewall subsystem 1020 may be deployed in the trusted security environment 1010, for example, and may be used to manage data communications from the target app 1080 to the target app platform 1030, from the target app platform 1030 to the target app 1080, and / or from the target app platform 1030 to the third-party app 110, for example.

[0027] With this method, the data security protection platform 1000 can not only ensure the safety and compliance of data communication between the target app platform 1030 and overseas via the data exchange subsystem 1040, but also ensure the safety and compliance of communication between the target app platform 1030 and each domestic object (e.g., the target app 1080 or the third-party app 1110) via the app protection wall subsystem 1020.

[0028] In some embodiments, to ensure compliance and reliability of the target app 1080's operation, the system for data security protection 1000 may further include a security sandbox subsystem 1090, for example, managed by a TTP, so that different types of network communications involving the app service logic 1100 of the target app 1080 can be protected by the security sandbox subsystem 1090. In this manner, the system for data security protection 1000 can prevent the target app 1080 from initiating unauthorized data communications, for example, by a backdoor program. A detailed implementation of the security sandbox subsystem 1090 will be described in detail below in conjunction with FIGS. 4A to 4E.

[0029] As a result, according to the data security protection system 1000 of the present disclosure, the TTP can manage and monitor various aspects such as code security and data security throughout the entire lifecycle of the target application from development to operation, thereby ensuring the security of data related to the target application and ensuring compliance with its operation.

[0030] Security Computing Subsystem The Security Computing Subsystem 1060 will now be described in detail with reference to Figure 2. Figure 2 shows a schematic block diagram of the Security Computing Subsystem 1060 according to an embodiment of the present disclosure.

[0031] 2, the security computing subsystem 1060 may include, for example, a security code environment 2010, which may be provided by, for example, a TTP. The following describes the operation process of the security computing subsystem 1060 in conjunction with the submission of new development code 2140.

[0032] 2, when a developer needs to deploy new developed code 2140, the developer may submit the developed code 2140 to the security code environment 2010 via a synchronization gateway 2150 provided by, for example, a TTP. In response, the developed code 2140 is synchronized to a code base 2160 in the security code environment 2010.

[0033] In some embodiments, when a developer needs to compile using new development code 2140, the developer may send a build request to product build system 2080, for example, via synchronization gateway 2150.

[0034] Alternatively, when the code base 2160 receives new development code 2140, the code base 2160 may automatically send a code integration event to the product building system 2080 to trigger the product building system 2080 to initiate the building process of the product (artifact, e.g., executable code).

[0035] After the build process is initiated, the code pull module 2090 can retrieve the code files for the build from the code base 2160. In some embodiments, the code files for the build may be specified by a developer, for example, or may be automatically determined by the product build system 2080.

[0036] Additionally, the compilation module 2100 may compile code pulled from the code base 2160 by the code pull module 2090, for example, into intermediate code.

[0037] Considering that some embodiments may also utilize the introduction of some third-party code during code compilation, the security computing subsystem 1060 must also ensure the security of the introduced third-party code.

[0038] 2, the security computing subsystem 1060 may include a third-party independent gateway 2030 for inspecting and verifying the security of any third-party libraries 2020 that need to be installed. It should be understood that such third-party libraries may be, for example, compiled link libraries or the source code itself.

[0039] Third-party libraries 2020 that pass safety testing may be added to product library 2040. As shown in FIG. 2, during product construction, compilation module 2100 may retrieve from product library 2040 other products on which the compilation of the current product depends, such as products that have already been compiled in the past or products that were generated based on third-party libraries 2020.

[0040] Furthermore, the compilation module 2100 can compile, for example, code pulled from the code base 2160 and dependent products obtained from the product library 2040 to generate intermediate code, and perform code security detection using the security code scanning module 2110.

[0041] It should be understood that the security code scanning module 2110 managed by the TTP can perform any suitable code scanning process to perform security checks, and such scanning rules may be unknown to the developer, thereby ensuring the security of the code for compilation into the final product.

[0042] In some embodiments, the upload module 2120 may perform the appropriate upload based on the results of the security code scanning module 2110. If the security code scanning module 2110 determines that the compiled intermediate code is safe, the upload module 2120 may further upload the compiled executable file to the product library 2040.

[0043] Furthermore, if the security code scanning module 2110 determines that the compiled intermediate code is safe, the upload module 2120 may upload the signature information of the executable file to the product signature management module 2060.

[0044] Conversely, if the security code scanning module 2110 determines that the current intermediate code has a relevant risk, the upload module 2120 may upload the associated risk to the issue tracking system 2070, for example, to form a risk analysis report. In response, the resulting compiled executable file is prohibited from being uploaded to the product library 2040.

[0045] In some embodiments, the development code 2140 in the code base 2160 may be provided in a trusted environment, for example, to undergo artificial testing. If it is determined that a risk exists in the development code 2140, this result may also be reported to the issue tracking system 2070.

[0046] In some embodiments, if the security code scanning module 2110 determines that the current intermediate code has an applicable risk, the upload module 2120 may notify the callback module 2130 to mark the applicable code as a risk code in the code base 2160.

[0047] In some embodiments, the issue tracking system 2070 maintained by the TTP may, for example, send the received risk report information to the developer or maintainer of the development code 2140, notifying them that the current development code 2140 cannot be deployed because it cannot pass security testing.

[0048] In some embodiments, if the development code 2140 passes safety testing, it may be compiled into an executable file and added to the product library 2040 for deployment, for example, via a deployment gateway 2050.

[0049] In some embodiments, before deploying a product (i.e., an executable file) obtained from product library 2040, deployment gateway 2050 may verify whether the product's signature is valid via product signature management system 2060. After the product's signature is validated, deployment gateway 2050 may deploy the product generated based on development code 2140 to the network.

[0050] In some embodiments, the product may be, for example, an application running on a client device, and the deployment gateway 2050 may, for example, release the generated installation file (e.g., an apk file) to a corresponding app store for download by a user. Thereby, embodiments of the present disclosure can ensure that installation files that a user can download and install are always released via the deployment gateway 2050 by the security code environment 2010.

[0051] In some embodiments, the product may be, for example, a service program for deployment to the target application platform 1030. Specifically, a target application maintainer may initiate a request to the deployment platform to deploy a specific product to the target application platform 1030. In response, after the request passes verification, the target application platform 1030 may obtain the specific product to be deployed from the product library 2040 and authenticate the signature of the specific product. After the signature of the product passes verification, the product may be deployed to the target application platform 1030 in the manner of, for example, a virtual machine or a container.

[0052] As a result, based on the considered security computing subsystem, the embodiment of the present disclosure can effectively monitor the process of converting code into an application or service program that is actually deployed and used, from each stage, such as code upload, code creation, code compilation, and third-party library incorporation, etc. Based on this method, the embodiment of the present disclosure can effectively avoid various security vulnerabilities or compliance risks introduced in source code.

[0053] Data Exchange Subsystem The operation of an app involves data interaction between app platforms under the jurisdiction of different countries or regions. For example, in the example shown in FIG. 1, data interaction is expected to occur between a target app platform 1030 and a target app platform where the same app is operated overseas to provide global data interaction for the app. As described above, the data exchange subsystem (DES) 1040 supports synchronization of common data of the target app and other data that meets rules between different platforms, while ensuring the security and compliance of the exchanged data. Generally, the DES 1040 is configured to detect whether data between different platforms meets data exchange constraints. Data exchange constraints may include constraints set to comply with national or regional laws and regulations, constraints that need to be set due to other requirements for enterprise, organizational, and / or user protection, etc.

[0054] For example, in countries or regions with specific data sovereignty requirements, TTPs may conduct data sovereignty inspections. Therefore, in many cases involving data exchange between platforms, it is necessary to ensure the security and compliance of the data exchange. In particular, after the TTP machine room is installed, data exchange with external parties stored in the TTP machine room is restricted, and data that wishes to interact with the TTP side is subject to data sovereignty inspections. In such cases, the data exchange restrictions may include rules related to the data sovereignty requirements of the specific country or region.

[0055] Such interaction data can be divided into two aspects: one aspect includes inter-platform communication data, and the other aspect includes operation and maintenance data, such as platform access or operation by platform operators and maintainers. Interaction data is mainly used for synchronization between two platforms to ensure the functional integrity of the application, and such data needs to be inspected for safety and compliance by the DES system. Interaction data includes, for example, online traffic data, offline data, etc. The inspection of operation and maintenance data is intended to ensure that the operations of operators and maintainers on the operation and maintenance control plane are also in compliance.

[0056] FIG. 3A illustrates an example deployment environment 3001 in which the DES 1040 may be deployed according to some embodiments of the present disclosure.

[0057] 3A, the TTP side 3027 refers to an environment that is subject to TTP supervision and restrictions in a specific country or region. The TTP side 3027 may relate to various assemblies for operating, managing, and maintaining the target application, such as a business system 3028, an operating platform 3029, online storage 3030, and offline storage 3031. The TTP side 3027 further includes an operation and maintenance platform 3032, through which an operation and maintenance personnel can access, manage, or maintain the target application.

[0058] Similarly, the non-TTP side 3020 is an environment belonging to one or more countries or regions other than a specific country or region, which is not subject to the data exchange restrictions of the country or region where the TTP side 3027 is located. The non-TTP side 3020 may relate to various assemblies for operating, managing, and maintaining the target app, such as a business system 3020, an operating platform 3021, an online storage 3022, an offline storage 3023, etc. The non-TTP side 3020 further includes an operation and maintenance platform 3024, and an operation and maintenance person needs to access the operation and maintenance platform 3024 to realize access, management, or maintenance of the local app or app platform.

[0059] Domestic user traffic flows through several assemblies on the TTP side 3027, and overseas user traffic flows through several assemblies on the non-TTP side 3020. In this specification, "domestic user traffic" refers to user traffic generated on an application platform under the jurisdiction of this specific country or region, and "overseas user traffic" refers to user traffic generated on an application platform under the jurisdiction of one or more countries or regions other than this specific country or region.

[0060] In the environment of Figure 3A, the intercommunication data includes domestic user traffic and international user traffic exchanged between the TTP and non-TTP. The intercommunication data passes through DES 1040 to facilitate inspection of aspects such as data security and compliance. An operation gateway 3026 may also be installed to inspect the operation and maintenance data for aspects such as data security and compliance.

[0061] As will be discussed in detail below, DES 1040 may configure different data channels based on the type of data and perform inspection of the data to be exchanged on the corresponding channels. Figure 3A illustrates several channels, including a target object store (TOS) channel, a message queue (MQ) channel, an offline aggregated data channel, a log (LOG) channel, a service invocation channel, etc.

[0062] For both data exchanges, each may have a respective DES to provide data protection, for example protection of incoming and / or outgoing data.

[0063] FIG. 3B further illustrates the implementation of DES 1040 in an internal data center (IDC) at the TTP side and an overseas internal data center (RoW IDC) where non-TTPs are located.

[0064] In FIG. 3B , TTP IDC 3056 is the IDC of a target app that operates in a specific country or region and is subject to the data protection detection of the TTP, and overseas IDC 3059 is the IDC of a target app that operates in one or more countries or regions other than the specific country or region and may be subject to the data protection restrictions of other countries or regions.

[0065] 3B, DES 1040A is implemented in TTP IDC 3056 to detect externally incoming data and / or internally outgoing data. DES 1040B is implemented in overseas IDC 3059 to detect externally incoming data and / or internally outgoing data. DES 1040A and DES 1040B may be considered specific deployment examples of DES 1040.

[0066] From the perspective of TTP IDC 3056, the externally inflowing data or internally outflowing data may include various types of data, which are described below by way of example.

[0067] As shown in FIG. 3B , external data entering the TTP IDC 3056 may include user requests, such as spontaneous requests initiated by domestic users in a particular country or region via target apps 3058 running domestically. As described elsewhere herein, in some embodiments, user requests may be secured via a mobile sandbox and / or a firewall gateway 3057 at the TTP IDC 3056. The user requests arrive at a domestic app platform 3041 at the TTP IDC 3056 for further processing. In some examples, the domestic app platform 3041 may include an assembly of various services, provider gateways, storage, etc. Note that if the user request is to be delivered to a data center other than the TTP IDC 3056, the user request is passed to DES 1040A for data protection.

[0068] In some embodiments, the incoming data to the TTP IDC 3056 may further include a supplier request initiated by the supplier 3055, e.g., requesting a specific service of the domestic app platform. For example, a third-party supplier may invoke an application programming interface (API) of the domestic app platform, e.g., OpenAPI. Because it is not possible to verify whether a third-party supplier belongs to a domestic user, the supplier request is routed via the third-party gateway 3040 in the TTP IDC 3056 to the supplier gateway in the domestic app platform 3041 for inspection to determine whether it is a domestic user. If the supplier initiating the request is a domestic user, the supplier request can be responded to normally. If the supplier initiating the request is an international user, the supplier request is routed via the DES 1040A.

[0069] In some embodiments, for TTP IDC 3056, the incoming data may further include data synchronized from an overseas IDC 3059 to TTP IDC 3056. For example, if a data security assessment needs to be performed on the incoming data from overseas, the incoming data may also be processed by DES 1040A.

[0070] In some embodiments, data received from outside the TTP IDC 3056 may further include operation and maintenance operations of the TTP IDC 3056 by an operator, such as changes to the TTP IDC 3056. Such operations may include code changes, configuration changes, log maintenance, and the like. Code changes may include, for example, bringing new features online or releasing bin files. Code changes may be performed by an operator in the country of the international or regional application platform. Configuration changes may include enabling or disabling certain settings of the target application, configuring scheduled traffic, and the like. In some cases, for application platforms operated across borders, configuration changes may be performed by an overseas platform operator. Of course, this depends solely on the management requirements of different applications. Log maintenance refers to maintaining the logs 3044 in the TTP IDC 3056.

[0071] In some embodiments, a domestic operator or an overseas operator may perform operation and maintenance operations on the TTP IDC 3056 under network isolation conditions to further ensure data sovereignty protection. As shown in FIG. 3B , the domestic operator initiates operation and maintenance operations in the event of network isolation, and the operation and maintenance operations are allocated via the load balancer 3045 and distributed to the code 3042, operation and maintenance platform 3043, or log 3044 in the TTP IDC 3056. In addition to network isolation, the operation and maintenance operations of the overseas operator are further security-checked via the operation gateway 3046 and distributed to the code 3042, operation and maintenance platform 3043, or log 3044 in the TTP IDC 3056.

[0072] In some embodiments, data exfiltrated from the TTP IDC 3056 may include third-party requests to request third-party services 3054 initiated from the domestic app platform 3041 during operation of the app platform, such as third-party services on a public network. Third-party requests also need to be data protected by DES 1040A.

[0073] In some embodiments, for the TTP IDC 3056, the data flowing from the TTP IDC 3056 may further include data synchronized from the TTP IDC 3056 to the overseas IDC 3059. For example, during the operation of the target application, user content stored in the TTP IDC 3056 may need to be synchronized to the overseas IDC 3059. According to some provisions of data sovereignty protection, such data may be important data that needs to be assessed by DES 1040A.

[0074] In some embodiments, the data transmitted from the TTP IDC 3056 may further include code synchronization data. For example, in some cases, inspection requirements such as data sovereignty protection may require code assessment of the target application or application platform. To ensure that the data sovereignty protection requirements are met, the code may be synchronized to a secure isolated environment 3051 for assessment to prevent code leakage. The secure isolated environment 3051 may be, for example, a physical environment such as a machine room not connected to a network or a monitored machine room, or a virtual computing environment with security protection.

[0075] From the perspective of the overseas IDC 3059, the DES 1040B deployed therein also performs similar security protection for data flowing in from the outside and data flowing out from the inside. For example, a user request generated through a target application 3058 operated by a user overseas may be protected by the DES 1040B after arriving at the overseas application platform 3048 (which may include various services and storage) via the load balancer 3047. In terms of operation and maintenance, an overseas operator may also perform operation and maintenance operations on the overseas application platform 3048 via a crystal gateway 3049 in the event of network isolation. Such operation and maintenance operations may be data protected via the DES 1040B.

[0076] For data protected in DES 1040A or 1040B, different types of data may have different methods for implementing data sovereignty protection and different processes that need to be performed to achieve data sovereignty protection.

[0077] In an embodiment of the present disclosure, in the DES 1040 (e.g., DES 1040A or 1040B), data can be preprocessed according to the data type to uniformly format the data, thereby simplifying and facilitating subsequent inspection of data sovereignty protection and accelerating the data exchange process.

[0078] As a result, data may be divided into different processing sections in DES 1040 according to data type. For example, according to data source, DES 1040A may include a domestic user data channel for processing data related to domestic users in a specific country or region, an overseas user data channel for processing data related to overseas users, and an engineering technology data channel for processing engineering and operation and maintenance data, such as various research and development data such as codes and parameters, operation and maintenance data, etc. Furthermore, the data in each channel may be further divided according to processing technology such as data generation, transmission, reception, and storage. As described below, when divided according to technology, the data in different channels may be divided into one or more of message queue (MQ) data, offline aggregation data, target object store (TOS) data, service invocation data, or other types of data.

[0079] For data that passes the data sovereignty protection assessment, the data can be converted from the unified format back to the original format and provided to the corresponding destination. According to the solution disclosed herein, since different data sources and different types of data vary in terms of data format, processing technology, etc., the complexity of the subsequent data sovereignty protection assessment stage can be reduced by pre-processing and post-processing of the unified format. Furthermore, with updates to data sources and technological expansion / changes, only the pre-processing and post-processing of data can be changed without making complex changes to the process of the data exchange constraint determination stage. This provides the data exchange architecture with great flexibility and scalability.

[0080] In the following, some specific embodiments will be described in detail with reference to the drawings.

[0081] DES overall architecture and data stream 3C illustrates a block diagram of an example architecture of the DES 1040 according to some embodiments of the present disclosure. In the example of FIG. 3C, the DES 1040 is shown to synchronize data between a domestic app platform 3041 and an external app platform (collectively referred to as the international app platform 3048) for a target app and to enforce data exchange constraint determinations.

[0082] As shown in Figure 3C, DES 1040 may include a DES adapter 3061, a DES center, and a DES adapter 3070. The DES center may include DES centers for different types of data channels, such as a DES center 3065A for domestic user data, a DES center 3065B for overseas user data, and a DES center 3065C for engineering technology data. DES centers 3065A, 3065B, and 3065C have different synchronization capabilities. Hereinafter, for ease of description, DES centers 3065A, 3065B, and 3065C may be collectively referred to as DES center 3065.

[0083] The DES adapter 3061 is connected to the domestic application platform 3041 and is used to receive data synchronized from the domestic application platform 3041 and to be detected by the DES 1040, and to transmit data received from the overseas application platform 3048 and detected by the DES 1040 to the domestic application platform 3041. The DES adapter 3070 is connected to the overseas application platform 3048 and is used to transmit data received by the domestic application platform 3041 and detected by the DES 1040 to the overseas application platform 3048, and to receive data synchronized from the overseas application platform 3048 and to be detected by the DES 1040. The DES adapter 3061 and the DES adapter 3070 are both connected to the DES center 3065 to distribute data to the DES center 3065.

[0084] Each DES center 3065 is configured to utilize data exchange constraints to detect data and ensure the safety and compliance of data exchanged between two application platforms. Generally, data that meets the data exchange constraints is passed to its appropriate destination via the DES 1040, while data that does not meet the data exchange constraints may be rejected by the DES 1040.

[0085] DES adapters 3061 and 3070 may be configured to perform pre-processing and post-processing on data to be input to DES center 3065 so that DES center 3065 determines whether data exchange constraints are met based on the unified format data corresponding to each data type.

[0086] In some embodiments, the DES adapter 3061 and DES center 3065 in DES 1040 may be implemented in the TTP IDC 3056 together with the domestic application platform 3041, and the DES adapter 3070 may be implemented in the overseas IDC 3059 together with the overseas application platform 3048.

[0087] In some embodiments, different assemblies in the DES 1040 may be isolated to further ensure more effective data isolation. Such data isolation may be achieved by deploying different assemblies in different data centers. In some embodiments, data isolation may be achieved by applying virtual private data center (VPC) technology. For example, as shown in FIG. 3C , the DES adapter 3061 may be implemented in VPC1, each DES center may be implemented in VPC2, and the DES adapter 3070 may be implemented in VPC3. Data safety and compliance decisions in the DES center 3065 may be performed by the TTP. In the case of data isolation, VPC1 and VPC3 do not have a direct communication connection, but VPC1 and VPC3 each have a direct communication connection with VPC2 and can communicate data / information with each other. With data isolation using VPC technology, the DES center 3065 deployed in VPC2 may be an area trusted by the TTP (referred to as a TTP trusted area).

[0088] In some embodiments, DES adapter 3061 may include DES entry 3062, which may implement control plane processing, such as application for establishing and managing data channels by an operator, registration rules, etc., and may also enable TTPs to view data on the channels. DES adapter 3061 may further include DES proxy 3063, which may implement data plane processing, such as data validation, data filtering, data conversion, data sampling, log detection, etc. Similarly, in some embodiments, DES adapter 3070 may include DES entry 3072 for the control plane and DES proxy 3073 for the data plane.

[0089] In some embodiments, for domestic user data channels, DES center 3065A may include a DES registration center for registering data exchange constraints, configuration data, etc. DES center 3065A may further include more subdivided channels, including a service invocation channel for service invocation data, an MQ channel for MQ data, an HDFS channel (herein referred to as the Hadoop Distributed File System) for offline aggregated data, and a TOS channel for TOS data. Offline aggregated data includes, for example, highly parallel integrated virtual environment (HIVE) type data.

[0090] Service invocation data may include, for example, data that makes remote service invocations using various network or invocation protocols, such as the HTTP protocol or the RPC protocol. MQ data may include data that supports the MQ protocol and similar protocols, including, for example, data stored in various databases (e.g., MySQL®, Redis database). Offline aggregated data may include data in file systems based on HDFS technology and data in file systems based on other technologies. TOS data includes object files, such as video, audio, image, document, and other media files.

[0091] In some embodiments, not shown in FIG. 3C, DES center 3065B for overseas user data channels and DES center 3065C for engineering technical data channels may include assemblies similar to DES center 3065A.

[0092] 3D illustrates a flowchart of a data exchange process 300 according to some embodiments of the present disclosure. The process 3004 may be implemented in the DES 1040.

[0093] 3D , in box 3301, DES 1040 obtains raw data that a target app exchanges between a first platform (e.g., domestic app platform 3041) and a second platform (e.g., international app platform 3048). Depending on the direction of the exchange, the raw data may originate from the first platform and be received by DES adapter 3061 in DES 1040. Alternatively, the raw data may originate from the second platform and be received by DES adapter 3070 in DES 1040.

[0094] In box 3302, DES 1040 processes the raw data based on the type of the raw data to obtain unified format data corresponding to this type. The processing of the raw data (here, the processing may be referred to as pre-processing) may be determined based on the type of the raw data. The type of raw data may include, for example, MQ data, offline aggregation data, TOS data, or service call data. Furthermore, in some cases, the processing of the raw data may be determined by the data source. For example, based on the data source, the raw data may be divided into domestic user data, overseas user data, or engineering technology data. Different types of data have different corresponding formats, and different methods may be applied to generate the corresponding unified format data.

[0095] In some embodiments, due to different technologies used by data sources, data of the same type may be provided in different formats, which increases the demands of technical processing. Therefore, a single unified format may be specified. In the pre-processing stage, a format conversion may be performed to convert the format of the raw data into the format specified by this type, thereby obtaining unified format data.

[0096] For example, for MQ data, parsing MQ data in different formats may facilitate analysis of content in messages encapsulated in different formats. For offline aggregated data and TOS data, responding to different requests to invoke such data from file systems or data systems in different formats may be converted into file invocation requests implemented by a unified API. For service invocation, service invocation requests generated in different protocols may be converted into service invocation requests in a unified protocol.

[0097] Specific pre-processing schemes for different types of data are described in more detail below.

[0098] In box 3303, the DES 1040 determines whether the data exchange constraints are satisfied from the unified format data. For example, the DES center 3065 in the DES 1040, especially the DES center 3065 of the corresponding data type, can perform a check whether the data exchange constraints are satisfied. The unified format preprocessing eliminates the need for the DES center 3065 to apply various different techniques to analyze the raw data, thereby making it easier to use rules to perform data safety and compliance checks.

[0099] If, in box 3304, it is determined that the unified format data satisfies the data exchange constraints, the DES 1040 converts the unified format data into raw data. If the data exchange constraints are met, the data is allowed to be synchronized between platforms. To ensure that the data is synchronized correctly, the DES 1040 further processes the intermediately generated unified format data (i.e., performs a post-processing step) to convert the unified format data into raw data having the original format.

[0100] In box 3305, the DES 1040 performs the exchange of raw data between the first and second platforms, thereby achieving secure and compliant data exchange.

[0101] In some embodiments, as briefly mentioned above, multiple data channels corresponding to different types of raw data may be created between different platforms, and different types of raw data may be passed to the corresponding data channels for processing. Each data channel may include a pre-processing assembly suitable for processing that type of raw data, a post-processing assembly, and a data exchange constraint verification assembly. Additionally or alternatively, each data channel may register data exchange constraints applicable to that particular type of raw data. In this manner, separation of different types of data in terms of pre-processing, data exchange constraint verification, and post-processing may be achieved.

[0102] Data channels corresponding to different types of data can be flexibly created, updated, and deleted. In this way, if the data pre-processing and post-processing methods change or if the data exchange restrictions for a specific type of data need to be updated, this can be done on the corresponding data channel without affecting other data channels. Furthermore, if a new type of raw data needs to be exchanged between the first platform and the second platform according to business needs and this new type of data also needs to be inspected for data sovereignty protection, a new data channel for processing the new type of raw data can be flexibly created between the first platform and the second platform.

[0103] 3E illustrates an example data stream 3005 flow chart of various data processes implemented in the DES 1040 according to some embodiments of the present disclosure. The data stream 3005 relates to a control plane data stream and a data plane data stream.

[0104] In the control plane, an operator and maintainer may configure channels for one or more types of data in DES 1040, and may perform updates and maintenance on the channels. As shown in FIG. 3E, a domestic operator and maintainer may request the configuration of a specific data type and a channel for processing the specific data type via DES entry 3062, and may register a data directory 3081 indicating the specific data type and a data definition 3082 similar to the specific data in DES registration center 3066. Data definition 3082 may be specified as channel information for processing different types of data in DES 1040, and may include pre-processing plans, post-processing plans, etc. for the corresponding types of data.

[0105] Similarly, an overseas operator and maintainer may request the configuration of a specific data type and a channel for processing the specific data type via DES entry 3072. The overseas operator and maintainer may register a data directory 3084 indicating the specific data type and a data definition 3085 similar to the specific data in DES registration center 3066. Data definition 3085 may be specified in channel information for processing different types of data in DES 1040, and may include pre-processing methods, post-processing methods, etc. for the corresponding types of data.

[0106] In the data plane, different types of data pass through respective channels in the DES 1040. As shown in Fig. 3E, for service call data, a service call request is exchanged between the client or server 3086 on the TTP IDC side and the client or server 3090 on the overseas IDC side. The service call request is processed in the service call channel in the DES 1040 so that the service call request meets the data sovereignty protection requirements.

[0107] In the example of Figure 3E, the service invocation channel may include at least a pre-processing module 3087 in the DES proxy 3063, an HTTP proxy 3088 in the DES center 3065, and a routing module 3089 in the DES proxy 3073. A service invocation request from a client or server 3086 on the TTP IDC side is delivered to the pre-processing module 3087. The pre-processing module 3087 processes the service invocation request using a data pre-processing scheme specified in the data definition 3082, and sends the unified formatted service invocation request to the HTTP proxy 3088.

[0108] In this example, it is assumed that the service invocation request is uniformly formatted into a request conforming to a unified protocol, i.e., the HTTP protocol. Therefore, after the HTTP proxy 3088 determines that the unified-formatted service invocation request satisfies the data exchange constraints, it may provide the unified-formatted service invocation request to the other-side client or server 3090 via the routing module 3089. Before being provided to the client or server 3090, the unified-formatted service invocation request is converted into a service invocation request conforming to the original protocol.

[0109] For MQ data, this type of raw data is processed in an MQ channel in DES 1040. In the example of FIG. 3E, the MQ channel may include at least a pre-processing module 3092 in DES proxy 3063, an MQ sender 3094 in DES center 3065, and a routing module 3097 in DES proxy 3073.

[0110] Raw data 3091 for the MQ type is delivered to a preprocessing module 3092. The preprocessing module 3092 processes the raw data 3091 using a data preprocessing scheme defined in the data definition 3082 to obtain unified format data 3093. The unified format data 3093 is extracted by an MQ transmitter 3094, for example, via a third-party software development kit (SDK). After inspecting the data exchange constraints, the SDK pushes unified format data 3096 that meets the rules to the overseas IDC. Uniform format data 3095 that does not meet the data exchange constraints is rejected. A routing module 3097 routes the unified format data 3096 that meets the rules to the corresponding destination, and the unified format data 3093 is converted to the corresponding raw data 3098 before being transmitted to the destination.

[0111] For offline aggregated data and TOS data, the raw data is processed in the HDFS channel and the TOS channel in the DES 1040, respectively. For simplicity, FIG. 3E shows an example of one channel, but it can be understood that the HDFS channel and the TOS channel may include the illustrated assemblies. In the example of FIG. 3E, the HDFS channel or the TOS channel may include at least a pre-processing module 3100 in the DES proxy 3063, a file sender 3103 in the DES center 3065, and a routing module 3105 in the DES proxy 3073.

[0112] Because data of the offline aggregation data type or TOS type is stored in a file system or other storage system, the pre-processing module 3100 may initiate a request to the file delivery manager 3102 to invoke a file delivery API to obtain raw data 3099 for the offline aggregation data type or TOS type and deliver it to the pre-processing module 3100. The pre-processing module 3100 may process the raw data 3099 using a data pre-processing scheme defined in the data definition 3082 to obtain unified format data 3101.

[0113] Similar to MQ-type data processing, unified format data 3101 is extracted by a file sender 3103, for example via an SDK. After checking the data exchange constraints, the SDK pushes unified format data 3104 that meets the rules to the overseas IDC. Uniform format data that does not meet the data exchange constraints is rejected and cannot be delivered to the overseas IDC. A routing module 3105 routes the unified format data 3104 that meets the rules to the corresponding destination, and before being transmitted to the destination, the unified format data 3094 is converted into corresponding raw data 3106.

[0114] It should be understood that Figure 3E only illustrates the processing of outgoing data from the TTP IDC to the overseas IDC in the DES 1040. The reverse data stream may be processed in a similar flow in the DES 1040, and the DES 1040 may reserve corresponding assemblies, particularly assemblies in the DES adapter, to support the corresponding processing.

[0115] Below, some exemplary implementations of different types of data in DES 1040 are discussed in detail.

[0116] Example implementation of data exchange for MQ 3F illustrates a schematic block diagram of a data exchange architecture 3006 for an MQ channel according to some embodiments of the present disclosure. The data exchange architecture 3006 may be implemented with DES 1040 to perform data security protection for MQ-type data. The example of FIG. 3F illustrates data exchange from a TTP IDC to an overseas IDC.

[0117] As shown in Figure 3F, a source database 3110 in the TTP IDC generates entities of MQ data to be distributed. The MQ data may include messages such as change data or commercially customized events, and different messages may have different formats. The MQ data generated by the source database 3110 is queued in a source message queue 3112.

[0118] 3F , DES adapter 3061 further includes DES front adapter 3120 in addition to DES entry 3062. DES front adapter 3120 may be implemented as part of DES proxy 3063 to pre-process MQ data from the TTP IDC to the overseas IDC. DES front adapter 3120 may be configured to process MQ data of different formats as uniform format MQ data having a uniform format, and provide the uniform format MQ data to MQ sender 3094 to perform a determination as to whether data exchange constraints are satisfied.

[0119] The MQ data (or message) may include data generated by different protocols, each of which has a custom format and therefore requires different preprocessing. As shown in FIG. 3F, the DES front adapter 3120 may include a parser 3122 configured to parse different types of raw MQ data and convert the different types of raw MQ data into unified-format MQ data. As shown in FIG. 3F, the DES front adapter 3120 may include a MySQL® parser for parsing data generated by the MySQL® protocol, such as change data capture (CDC) data; a Redis parser for parsing data generated by the Redis protocol, such as CDC data; a document parser for parsing data in a document database, particularly CDC data; a graph parser for parsing data in a graph database, particularly CDC data; and an MQ parser for parsing different types of business event data sent by a message queue. As can be appreciated, the parser 3122 is scalable, where more, fewer, or other parsers may be installed to parse corresponding types of MQ data.

[0120] The unified format MQ data obtained after the parsing may be in the form of a message queue and may be placed in the unified format message queue 3124. In VPC2 of the TTP IDC, the MQ sender 3094 responsible for the MQ data may extract the parsed unified format MQ data from the unified format message queue 3124 via the SDK and use it for data safety and compliance inspection. The unified format MQ data that does not satisfy the data exchange constraints is rejected by the MQ sender 3094 and recorded in the rejection log 3126. The unified format MQ data that satisfies the data exchange constraints is pushed to the DES rear adapter 3130 in the DES adapter 3070 via the SDK.

[0121] The DES rear adapter 3130 may be implemented as part of the DES proxy 3073 to post-process unified format MQ data from the TTP IDC to the overseas IDC and deliver the data to the destination. The unified format MQ data that meets the data exchange constraints is pushed to the DES rear adapter 3130 via the SDK.

[0122] The DES rear adapter 3130 may include a data replayer 3132 for performing post-processing of the uniform format MQ data. Specifically, the DES rear adapter 3130 may be configured to convert the uniform format MQ data into raw MQ data. Therefore, the DES rear adapter 3130 may include replayers corresponding to different types of MQ data to perform conversion from the uniform format to respective custom formats. As shown in FIG. 3F , the DES rear adapter 3130 may include a MySQL® replayer for converting the uniform format MQ data into MQ data conforming to the MySQL® protocol, a Redis replayer for converting the uniform format MQ data into MQ data conforming to the Redis protocol, a document replayer for converting the uniform format MQ data into graphics-style raw data, an MQ replayer for converting the uniform format data into raw data conforming to the MQ protocol, etc.

[0123] The converted raw MQ data may be placed in a unified format message queue 3134 in the DES rear adapter 3130, and synchronized from there to a target message queue 3135. The target message queue 3135 is used to store the MQ data synchronized indirectly from the source message queue 3112 via the DES 1040. The target database 3136 can obtain the expected MQ data from the target message queue 3135.

[0124] 3F only shows assemblies involved in data exchange in the direction from the TTP IDC to the overseas IDC. The example of FIG. 3F shows data exchange in the direction from the overseas IDC to the TTP IDC, and DES 1040 may include similar assemblies for processing data exchange in this direction; for example, DES adapter 3070 may include a DES front adapter with functionality similar to DES front adapter 3120, and DES adapter 3061 may include a DES rear adapter with functionality similar to DES rear adapter 3130. For the sake of simplicity, detailed description of processing in this direction will be omitted.

[0125] It will be appreciated that the assembly for processing MQ data exchange in the DES shown in Figure 3F is only one example, and in other examples, different functional modules may be subdivided, integrated, etc. in other ways, and may further include more, fewer, or different functional modules, as needed.

[0126] Example implementation of data exchange for offline aggregated data FIG. 3G illustrates a schematic block diagram of a data exchange architecture 3500 for an HDFS channel according to some embodiments of the present disclosure. The data exchange architecture 3500 may be implemented in DES 1040 to perform data security protection for offline aggregated data. The example of FIG. 3G illustrates offline aggregated data exchange between HDFS 3502 on the TTP IDC side and HDFS 3504 on the overseas IDC side. Some offline aggregated data in HDFS 3502 and HDFS 3504 may need to be synchronized with each other.

[0127] 3G, in the data exchange architecture 3500, a data delivery detector 3510 on the TTP IDC side is responsible for detecting whether the HDFS 3502 stores offline aggregated data that needs to be delivered to the other side's HDFS 3504. If the HDFS 3502 finds offline aggregated data to be delivered, the data delivery transmitter 3520 may pass a request for data delivery to the file sender 3550. While being passed to the file sender, a data preprocessing module 3530 is configured to perform data preprocessing to process the offline aggregated data as unified format data.

[0128] In the file transmitter 3550, the data delivery server 3556 is configured to control the data delivery service based on the utilization of the data exchange constraints. If the data delivery server 3556 determines that the pre-processed unified format data from the HDFS 3502 conforms to the data exchange constraints, the data delivery server 3556 may invoke the delivery work 3558 to deliver the unified format data to the overseas IDC via a delivery task 3562 under the delivery work 3558. In some embodiments, the delivery work 3558 may further include an optional data validation task 3560, which may be configured to perform data validation as needed. The unified format data may pass through the HDFS gateway 3564, and after post-processing is performed, the original offline aggregated data may be obtained and stored in the HDFS 3504.

[0129] Similarly, in the data exchange architecture 3500, the data distribution detector 3570 on the overseas IDC side is responsible for detecting whether the HDFS 3504 stores offline aggregated data that needs to be distributed to the HDFS 3502 on the TTP IDC side. If the data distribution transmitter 3572 finds offline aggregated data to be distributed, it may pass a request for data distribution to the file sender 3550. Before being passed to the file sender, the data preprocessing module 3570 is configured to perform data preprocessing to process the offline aggregated data as unified format data.

[0130] In the file transmitter 3550, if the data delivery server 3556 determines that the pre-processed unified format data from the HDFS 3504 complies with the data exchange constraints, it may invoke the delivery work 3554 to deliver the unified format data to the TTP IDC via the delivery task 3552 under the delivery work 3554. After the unified format data undergoes post-processing, the original offline aggregated data is obtained and stored in the HDFS 3502.

[0131] It can be understood that the assembly for processing offline aggregate data exchange in the DES shown in Figure 3G is only one example, and in other examples, different functional modules may be subdivided, integrated, etc. in other ways, and may further include more, fewer, or different functional modules, as needed.

[0132] Example implementation of data exchange for object stores Overall, the TOS channel can determine whether an object file satisfies data exchange constraints and, if so, copy the object file from a source IDC (e.g., a TTP IDC or an overseas IDC) to a destination IDC (e.g., an overseas IDC or a TTP IDC). Object files can be, for example, video, audio, images, documents, or other media files.

[0133] In some embodiments, an object file may be copied from an object store via an API, a determination of data exchange constraints may be performed, and the object file may be pushed to an object store at a destination end using the API. During the data exchange of the object file, it may be determined whether the data exchange constraints are satisfied by the copy request corresponding to the object file. The TOS channel is described in more detail below with reference to Figures 3H-3J.

[0134] 3H illustrates a schematic diagram of a target object store (TOS) channel 3600 for copying data from a TTP IDC to an overseas IDC, according to some embodiments of the present disclosure. In this example, the data being exchanged is an object file, which is stored in an object store 3606 at the TTP IDC and expects to be exchanged to an object store 3607 at the overseas IDC.

[0135] In Figure 3H, API 3605 in the TTP IDC is configured to push copy requests to work nodes 3605 and receive exchanged copy results from the work nodes 3605 from the other overseas IDC. As shown in the figure, at data stream initiation 3601, a copy request for an object file to be exchanged is delivered to work node 3605 by API (which may be referred to as a DES-TOS API) 3602. This copy request may indicate information related to the object file to be exchanged, such as the object file format (video, audio, text, etc.), the object file identifier, and other file metadata. This copy request has a unified format.

[0136] Work node 3605 in trust domain VPC2 is configured to respond to copy requests for object files and perform decisions regarding data exchange constraints. Specifically, work node 3605 can determine whether an object file to be exchanged from a unified format copy request satisfies the data exchange constraints.

[0137] In some embodiments, the TTP IDC may initiate the registration of data exchange constraints at an initial stage or at a subsequent required time. At constraint registration initiation 3622, the data exchange constraints to be used may be registered with a DES registration center 3624 in the TTP trust realm via a DES entry 3620 in the TTP IDC. The registration of data exchange constraints may be realized by calling API 3602. Work node 3605 may access the currently used data exchange constraints via DES registration center 3624.

[0138] In some embodiments, the data exchange constraints may indicate a whitelist of object files that are allowed to be exchanged or a blacklist of object files that are not allowed to be exchanged, and each list may identify file objects that are allowed or not allowed to be exchanged by object file format, identifier, etc.

[0139] In enforcing the data exchange constraints, the work node 3605 allows execution of copy requests that satisfy the data exchange constraints. If execution of the copy request is allowed, the work node 3605 accesses the object store 3606 in the TTP IDC to copy the object file to the object store 3607 in the overseas IDC. For invalid requests (i.e., copy requests that do not satisfy the data exchange constraints), they are rejected and therefore cannot be executed. The work node 3605 may write the copied object file to the object store 3607 via the API 3610 in the overseas IDC. This results in data stream termination 3611.

[0140] 31 shows a schematic diagram of a TOS channel 3650 for copying data from an overseas IDC to a TTP IDC according to some embodiments of the present disclosure. In this example, the object files to be exchanged are stored in an object store 3607 at the overseas TTP IDC and expect to be exchanged in an object store 3606 at the TTP IDC.

[0141] In FIG. 3I, API 3610 in the overseas IDC is configured to push copy requests to work node 3605 and receive exchanged copy results from work node 3605 from the other TTP IDC. As shown in FIG. 3I, at data stream start 3651, a copy request for an object file to be exchanged is delivered to work node 3605 by API 3610. This copy request may indicate information related to the object file to be exchanged, such as the object file format (e.g., video, audio, text), object file identifier, and other file metadata. This copy request has a unified format. Work node 3605 in trust domain VPC2 can determine whether the object file to be exchanged satisfies the data exchange constraints from the unified-format copy request.

[0142] In some embodiments, the overseas IDC may initiate registration of data exchange constraints at an initial stage or at a subsequent time when needed. At constraint registration initiation 3632, the data exchange constraints to be used may be registered with the DES registration center 3624 in the TTP trust domain via the DES entry 3630 in the overseas IDC. The registration of data exchange constraints may be realized by calling the API 3610. The work node 3605 may access the currently used data exchange constraints via the DES registration center 3624.

[0143] When enforcing the data exchange constraints, the work node 3605 allows execution of copy requests that satisfy the data exchange constraints. If the copy request allowance is executed, the work node 3605 accesses the object store 3607 in the overseas IDC to copy the object file to the object store 3606 in the TTP IDC. For invalid requests (i.e., copy requests that do not satisfy the data exchange constraints), they are rejected and therefore cannot be executed. The work node 3605 may write the copied object file to the object store 3606 via the API 3602 in the TTP IDC. This results in the data stream ending 3652.

[0144] It will be appreciated that the assemblies for processing TOS data exchange in DES shown in Figures 3H and 3I are merely examples, and in other examples, different functional modules may be subdivided, integrated, etc. in other ways, and may further include more, fewer, or different functional modules, as needed.

[0145] 3J illustrates a message sequence 3012 in a TOS channel according to some embodiments of the present disclosure. The message sequence 3012 in FIG. 3J relates to a TTP 3701, an operator / maintainer 3702, a platform staff 3703, a DES entry 3704, an API 3705, a work node 3605, and an object store 3708.

[0146] Depending on the direction of data exchange, DES entry 3704, API 3705, and object store 3708 in Figure 3J may be the corresponding assemblies in either Figure 3H or Figure 3I. For example, in TOS channel 3600 copied from the TTP IDC to the overseas IDC shown in Figure 3H, DES entry 3704 includes DES entry 3620 shown in Figure 3H, API 3705 includes API 3602 in Figure 3H, and object store 3708 includes object store 3606 in Figure 3H. In TOS channel 3650 copied from the overseas IDC to the TTP IDC, DES entry 3704 includes DES entry 3630 shown in Figure 3I, API 3705 includes API 3610 in Figure 3I, and object store 3708 includes object store 3607 in Figure 3I.

[0147] In message sequence 3012, an operator / maintainer 3702 registers 3711 data exchange constraints in a DES entry 3704, which can restrict copying of object files between object stores 3606 and 3607 of different IDCs. After the registration is complete, the DES entry 3704 can send 3714 a response to the operator / maintainer. The DES entry 3704 registers 3712 container information related to the data exchange constraints in an API 3705, and after the registration is complete, the API 3705 can send 3713 a response to the DES entry 3704. The rules registered via the DES entry 3704 can be cached 3715 in the API 3705, and can also be cached 3716 in the work node 3605.

[0148] Platform staff 3703 may initiate 3717 a copy request for an object file to API 3705. API 3705 may perform 3718 authentication. Work node 3605 may pull 3719 the copy request from API 3705 and perform 3720 a data exchange constraint determination on the object file to be copied. If copying the object file is allowed, work node 3605 performs 3721 the file copy, copying the corresponding object file from object store 3706. Of course, regardless of the result not satisfying the data exchange determination, work node 3605 returns 3722 feedback to API 3705. If copying the object file is allowed, the feedback includes the object file that was copied. If copying the object file is not allowed, the feedback is used to indicate that the copy request was denied.

[0149] In some embodiments, platform staff 3703 can call back 3723 API 3705, which can return 3724 a copy request ID to platform staff 3703. In some embodiments, TTP 3701 can look at 3725 the historical status of object file copies via DES entry 3704 to see if object file exchanges within a certain time period conform to the requirements of data exchange constraints. DES entry 3704 can return 3726 the results to be looked at.

[0150] An exemplary implementation of data exchange protection for service invocations FIG. 3K illustrates a schematic block diagram of a data exchange architecture 3800 for a service invocation channel according to some embodiments of the present disclosure. The data exchange architecture 3800 may be implemented in DES 1040 to perform data security protection for service invocation-type data. The example of FIG. 3L illustrates a service invocation data exchange between a target platform service 3802 on the TTP IDC side and an overseas (non-TTP) platform service 3804 on the overseas IDC side. For example, a service on the target platform service 3802 may need to invoke a service on the overseas platform service 3804, and conversely, a service on the overseas platform service 3804 may also need to invoke a service on the target platform service 3802.

[0151] Different service platforms may use various different service invocation protocols, such as HTTP or Thrift RPC. In some embodiments of the present disclosure, it is desirable to be able to process uniform format data, such as HTTP protocol data, when implementing data sovereignty protection in the VPC trust domain.

[0152] In Figure 3K, in the control plane, the non-TTP control plane is used for channel registration, channel architecture updates, and discovery, while the TTP / TTP control plane is used for channel request authorization, channel banning, channel discovery, etc. In the data plane, the HTTP load balancer 3810 is an L7 equalization product from TTP Cloud and is the key assembly that ensures all DES-RPC channel traffic passes through the VPC trust domain. The HTTP channel is a DES-RPC channel that supports the HTTP protocol. The Thrift RPC channel is a DES-RPC channel that supports the Thrift RPC protocol. Before being sent to TTP's HTTP load balancer, the Thrift RPC channel is wrapped in an HTTP channel.

[0153] During the channel registration phase, a DES-RPC channel is announced using channel information and data definitions. The channel information may include the type of channel, e.g., Thrift RPC or HTTP. The channel information may also include an RPC call tuple. The call tuple may include a src dc, a src service, a dst dc, a dst service, and an rpc method / http route.

[0154] The data definition may depend on the direction of data flow: For non-TTP to TTP data flows, announce responses in Thrift IDL with compliance comments; For TTP to non-TTP data flows, announce requests in Thrift IDL with compliance comments. In some embodiments, a DES-RPC channel is available only if it passes compliance registration.

[0155] It can be understood that the assembly for processing service call data exchange in the DES shown in Figure 3K is only one example, and in other examples, different functional modules may be subdivided, integrated, etc. in other ways, and may further include more, fewer, or different functional modules, as needed.

[0156] FIG. 3L illustrates an example of data exchange from a non-TTP to a TTP in the service call channel illustrated in FIG. 3K according to some embodiments of the present disclosure. As illustrated in FIG. 3L, a call initiated by service A 3901 in an overseas domain is forwarded to an HTTP load balancer 3905 of the TTP by an HTTP proxy 3902 or a Thrift proxy 3903. Service A 3901 may be an example of an overseas platform service illustrated in FIG. 3M. For an HTTP request, the call is forwarded to the HTTP load balancer 3905 by the HTTP proxy 3902. For a Thrift request, the call is forwarded to the HTTP load balancer 3905 by the Thrift proxy 3903.

[0157] It is proposed that service discovery from the corresponding service proxy in the overseas IDC, e.g., HTTP proxy 3902 or Thrift proxy 3903, to the VPC trust realm HTTP load balancer 3905 is realized by DNS, and service discovery of the proxy through which the corresponding request is forwarded to the TTP IDC realm is proposed to use customized / generic service discovery.

[0158] The HTTP load balancer 3905 may include a compliance plugin 3906. For invalid requests, the compliance plugin 3906 returns an error. For Thrift rpc calls, the request is wrapped in HTTP to generate a new HTTP request. The body of the new HTTP request is the Thrift binary file.

[0159] In the VPC trust domain, TTP's HTTP load balancer 3905 forwards the request to TTP's HTTP proxy 3907 and Thrift proxy 3908, respectively, which then forward the request to target services Service B 3908 and Service C 3910, respectively. For Thrift RPC calls, Thrift proxy 3908 recovers the original Thrift request from the new HTTP request generated before sending the request.

[0160] The TTP HTTP proxy 3907 and Thrift proxy 3908 inspect responses before sending them to the TTP HTTP load balancer 3905. An error is returned for responses that do not pass the compliance inspection. For Thrift RPC calls, the Thrift response is wrapped in HTTP to generate a new HTTP response. The body of the new HTTP response is a Thrift binary file.

[0161]

[0033] Figure 3M illustrates an example of data exchange from a TTP to a non-TTP in the service call channel illustrated in Figure 3K according to some embodiments of the present disclosure. As illustrated in Figure 3M, a call initiated by a TTP service A 3951 is forwarded to a TTP HTTP load balancer 3955 by a TTP HTTP proxy 3952 and a Thrift proxy 3953. For an HTTP request, the call is forwarded to the HTTP load balancer 3955 by the HTTP proxy 3952. For a Thrift request, the call is forwarded to the HTTP load balancer 3955 by the Thrift proxy 3953.

[0162] For invalid requests, an error is returned. For responses that do not pass compliance checks, an error is returned. For Thrift rpc calls, the request is wrapped in HTTP to create a new HTTP request. The body of the new HTTP request is the Thrift binary file.

[0163] The TTP HTTP load balancer 3955 forwards the request to a non-TTP (i.e., overseas domain) HTTP proxy 3957 and a Thrift proxy 3958. The HTTP proxy 3957 and the Thrift proxy 3958 then forward the request to a service B 3959 and a service C 3960 in the overseas domain.

[0164] For Thrift rpc calls, the Thrift proxy recovers the original Thrift request from the new HTTP request generated before sending it.

[0165] The non-TTP HTTP proxy 3957 and the Thrift proxy 3958 send responses to the TTP HTTP load balancer 3955. For Thrift rpc calls, the Thrift response is wrapped in HTTP to generate a new HTTP response. The body of the new HTTP response is a Thrift binary file.

[0166] Security Sandbox Subsystem A client application needs to communicate with a server to transmit data. The client application's network traffic can carry a large amount of user data. Therefore, a network traffic method is needed to manage the client application so that user data is not transmitted to an unauthorized server via the client application's network traffic. For example, in a data sovereignty scenario, this method can prevent user data from being transmitted to a server outside the data sovereignty country.

[0167] However, the types of network traffic of client apps are very diverse. Client apps may include mobile-end apps and computer (PC-end) apps. The network traffic of client apps may include native-type network traffic and web page view-type network traffic. However, not all of the network traffic of client apps is managed and controlled by the app owner. For example, the network traffic of client apps may include network traffic from third-party advertisers. Therefore, managing the various types of network traffic of client apps can be very difficult.

[0168] An exemplary embodiment of the present disclosure proposes a method for managing network traffic of a client application, the method including: detecting network transmission of user data of the target user from the client application to a server based on determining a target user; analyzing the network traffic at different layers of the network transmission based on a type of network traffic corresponding to the network transmission; and sending the network traffic to a server limited by the data exchange constraint based on the analysis indicating that the network traffic satisfies a data exchange constraint corresponding to the target user.

[0169] This method analyzes network traffic at different layers of network transmission based on the type of network traffic, and restricts the transmission of network traffic that does not meet data exchange constraints, thereby effectively preventing user data from being transmitted to unauthorized servers via various types of network traffic.

[0170] Hereinafter, the embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Hereinafter, the solution of the present disclosure will be described in detail with reference to a mobile terminal application as an example.

[0171] 4A illustrates a flowchart of an example method 4100 for managing network traffic of a mobile edge app according to some embodiments of the present disclosure. The method 4100 may be implemented, for example, in the security sandbox subsystem 1090 of FIG. 1. The mobile edge app may be a target app 1080 at the mobile edge.

[0172] In box 4102, based on determining the target user, detect a network transmission of the target user's user data from the target app 1080 to a server. In other words, if it determines that the current user is the target user, the security sandbox subsystem 1090 can detect a network transmission of the target user's user data.

[0173] In some implementations, network traffic may be routed to the security sandbox subsystem 1090 based on determining the target user so that the security sandbox subsystem 1090 can detect and analyze network traffic corresponding to network transmissions of user data. The security sandbox subsystem 1090 can analyze the network requests of the target app 1080 and restrict network requests that do not meet the conditions based on the data exchange constraints.

[0174] The data exchange restrictions may include exchange restrictions related to data sovereignty, such as data sovereignty protection rules. The data sovereignty protection rules may be determined based on national or regional regulations. The data sovereignty protection rules may also be determined by the app operator (e.g., regarding user data usage protocols).

[0175] The data sovereignty protection rule may be set based on a specific scenario. For example, the data sovereignty protection rule may stipulate that user data of a data sovereign nation is not allowed to be transmitted to any server outside the data sovereign nation. In some other implementations, the data sovereignty protection rule may stipulate that privacy user data of a data sovereign nation is not allowed to be transmitted to any server that is not registered with the data sovereign nation. The scope of the present disclosure is not limited thereto.

[0176] 1, a network request of a target application 1080 is transmitted to the application firewall subsystem 1020 after being analyzed and processed by the security sandbox subsystem 1090. The principles and details of the security sandbox subsystem 1090 will be described in detail below.

[0177] A target user is a user whose transmission of user data needs to be detected and managed. The target user may be a user who has the nationality of a data sovereign state. Alternatively or additionally, the target user may be a user determined based on specific rules of data sovereignty protection. For example, the target user may be a user who has the nationality of a data sovereign state and is currently geographically located in this data sovereign state.

[0178] In some implementations, the target user may be determined based on user information. The user information may include the user's account information, personal information, registration information, etc. Alternatively or additionally, the target user may be determined based on device information. The device information may include Subscriber Identity Module (SIM) information, IP address, network service provider information, device system setting information, app setting information, etc.

[0179] In some implementations, target users may be determined based on a combination of various information, which may have different priorities. For example, SIM information, network service provider information may have a higher priority than IP address, system configuration information, app configuration information, etc.

[0180] In some implementations, determining the target user may be based on determining the region in which the target user is located. The target user may be determined by using the user information or device information described above to determine the region in which the target user is located. For example, the region setting in the smartphone's system settings may be used to determine the region in which the current user is located, thereby determining whether the current user is the target user. For example, the country code of the SIM card may be used to determine the region in which the target user is located, thereby determining the target user.

[0181] In some implementations, the target user may be determined when the app is first launched. In other words, whether the current user is the target user may be determined when the app is first launched. Alternatively or additionally, whether the current user is the target user may be determined when the user registers. Alternatively or additionally, whether the current user is the target user may be determined when the user logs in, logs out, or switches accounts.

[0182] In some implementations, the determination result may be stored locally or on a server. After the first determination that a user is a target user, the determination result may be stored and configured to use the stored determination result within a threshold time period. In this way, when the user registers again, there is no need to determine the user again.

[0183] In box 4104, the network traffic is analyzed at different layers of the network transmission based on the type of network traffic corresponding to the network transmission.

[0184] The network traffic of the target app 1080 may include multiple types of network traffic, such as native, webpage view, and third-party software development kit (SDK) type network traffic. Native type network traffic is generated and processed by operating system (e.g., Android and IOS) code at the business layer. Native type network traffic may be completely controlled by the owner of the target app 1080.

[0185] Third-party SDK type network traffic is generated and processed by third-party SDKs. Typically, the target app 1080 may access third-party SDKs to implement registration or sharing functionality. Third-party SDK type network traffic is generated and processed by these third-party SDKs. It should be understood that third-party SDK type network traffic is typically not fully controlled by the app owner.

[0186] Network traffic of the web page view type may include network traffic controlled by the app owner, such as network traffic generated by an app's built-in browser calling native app code. Network traffic of the web page view type may also include network traffic controlled by a third party, such as network traffic generated and controlled by a third-party advertiser.

[0187] Based on the type of network traffic, the security sandbox subsystem 1090 can adopt appropriate analysis policies to better manage the network transmission of user data in the app.

[0188] In box 4106, based on the analysis indicating that the network traffic satisfies the data exchange constraint corresponding to the target user, the network traffic is sent to a server restricted by the data exchange constraint. Different data exchange constraints may be set for different target users. For example, stricter data exchange constraints may be set for target users with higher sensitivity. The data exchange constraints may limit which user data can be transmitted to which servers. In some implementations, the data exchange constraints corresponding to the target user may be determined based on the user information or corresponding device information of the target user.

[0189] In some implementations, the security sandbox subsystem 1090 may include multiple sub-modules for different types of network traffic, such as a sub-module for managing native-type network traffic, a sub-module for managing web page view-type network traffic, and a sub-module for managing third-party SDK-type network traffic. These sub-modules can analyze the appropriate types of network traffic and restrict or block network traffic that does not meet data exchange constraints. Details of managing different types of network traffic are described in more detail below with reference to Figures 4B through 4E.

[0190] 4B illustrates a schematic diagram of an analysis and restriction process 4200 for native-type network traffic according to some embodiments of the present disclosure. FIG. 4B illustrates a sub-module 4210 for analyzing and restricting native-type network traffic. The sub-module 4210 may be part of the security sandbox subsystem 1090 or may be a specific implementation of the security sandbox subsystem 1090.

[0191] As shown in FIG. 4B , the business logic layer 4220 issues a network request to the lower OS 4230. The business logic layer 4220 may be a specific implementation of the application service logic 1100 shown in FIG. 1 regarding network transmission. The submodule 4210 can analyze and restrict the network request at the network layer as a blocker. The submodule 4210 can restrict the network request by analyzing the endpoint, parameters of the network request, or schema. For example, it can determine whether to restrict the network request based on whether the schema is already registered. Alternatively or additionally, it can determine whether to restrict the network request based on whether a field requested in the network request relates to sensitive information.

[0192] In some implementations, sub-module 4210 may include a blocker for Android and a blocker for IOS. Additionally, sub-module 4210 may further include a blocker for C++. In this manner, by analyzing and restricting network requests at the network layer, it is possible to better determine whether a network request should be restricted based on protocol information of the network request.

[0193] 4C illustrates a schematic diagram of an analysis and restriction process 4300 for web page view type network traffic according to some embodiments of the present disclosure. FIG. 4C illustrates a sub-module 4310 for analyzing and restricting web page view type network traffic. The sub-module 4310 may be a part of the security sandbox subsystem 1090 or may be a specific implementation of the security sandbox subsystem 1090.

[0194] Sub-module 4310 may transition web page view type network traffic to a native network interface so that the web page view type network traffic may be analyzed and restricted by sub-module for native type network traffic 4210. In some implementations, sub-module 4310 may utilize a JavaScript (JS) hook mechanism to transition web page view type network traffic to a native network interface.

[0195] As shown in FIG. 4C , submodule 4310 may include a starter 4311, a navigation URL blocker 4312, and an internal request blocker 4313. Submodule 4310 can communicate with a browser 4320 built into the app so that web page view type network traffic can be managed and detected by submodule 4310. Starter 4311 can perform JS injection when the browser 4320 built into the app is opened (created) so that the web page view type network traffic can be transitioned to a native network interface using a hook mechanism. The network traffic transitioned to the native network interface can be taken over by a native network module.

[0196] In some implementations, JS hook technology can be used to transition network traffic in the following ways:

[0197] The navigation URL blocker 4312 can analyze and restrict the URL of the main page (initial page). For example, the navigation URL blocker 4312 can determine whether to restrict this network request based on whether the schema of the URL is registered. If this network request is not restricted, the browser 4320 can load this main page.

[0198] The internal request blocker 4313 can relay network traffic related to the static resources and dynamic resources of the main page to the native network interface so that these network traffic can be restricted and analyzed at the network layer by the submodule 4210. The specific analysis and restriction process is similar to that of native-type network traffic, and will not be further described here.

[0199] In some implementations, submodule 4310 may employ different analysis and restriction policies for web page view type network traffic controlled by the app owner and network traffic controlled by a third party. For example, for web page view type network traffic controlled by a third party, the navigation URL blocker 4312 may be used to analyze the associated network traffic by determining whether the main page URL is registered, without the need to further analyze the static and dynamic resources of the main page.

[0200] 4D illustrates a schematic diagram of a process 4400 for analyzing and restricting third-party SDK-type network traffic according to some embodiments of the present disclosure. FIG. 4D illustrates a sub-module 4410 for analyzing and restricting third-party SDK-type network traffic. The sub-module 4410 may be part of the security sandbox subsystem 1090 or may be a specific implementation of the security sandbox subsystem 1090.

[0201] Submodule 4410 may analyze and restrict third-party SDK-type network traffic at an application programming interface (API) layer by analyzing whether data requested by the API of the third-party SDK satisfies data exchange constraints at the API layer.

[0202] In some implementations, the submodule 4410 can wrap an API that requests user data in a third-party SDK and add decision logic based on data exchange constraints to the wrapper. In other words, the submodule 4410 can determine the wrapped API by adding decision logic to the API of the third-party SDK. In this way, the business logic layer 4220 calls the wrapped API with the decision logic added, rather than directly calling the API of the third-party SDK.

[0203] 4D , sub-module 4410 may include a wrap module for each third-party SDK, e.g., wrap module 4412 for SDK 4411, wrap module 4414 for SDK 4413, and wrap module 4416 for SDK 4415. A wrap module (e.g., wrap module 4412) can wrap an API in a corresponding SDK (e.g., SDK 4411) to generate a corresponding wrapped API. In some implementations, sub-module 4410 can dynamically augment wrap modules to wrap APIs of third-party SDKs.

[0204] In some implementations, a third-party SDK API may be wrapped in the following manner: The wrapper module 4412 may define an API exposed to the business layer that is the same as the API in the SDK 4411. The wrapper module 4412 may define a wrapper class for the SDK 4411 data type that implements this API.

[0205] The determination logic may determine whether the API of the wrapped third-party SDK can be called based on the data exchange constraints. In some implementations, the determination logic may analyze whether the API of the third-party SDK can be called based on the SDK name, API name, API parameter names, etc. If the determination result is YES, the API of the third-party SDK can be called and a value is returned to the business layer. If the determination result is NO, the API of the third-party SDK is not called, i.e., network traffic related to this API is restricted. It should be understood that the determination logic may vary based on the specific scenario. For example, the determination logic may be configured to not allow user privacy data to be input into the third-party SDK.

[0206] In this manner, by performing analysis and restriction at the API layer, submodule 4410 can manage and detect third-party SDK type network traffic without knowing the internal code of the third-party SDK.

[0207] 4E illustrates a module diagram of the security sandbox subsystem 1090 according to some embodiments of the present disclosure. As shown in FIG. 4E, the security sandbox subsystem 1090 includes an initiation module 4520. The initiation module 4520 is configured to initiate detection of network transmissions of user data of the target user from a client app to a server based on determining the target user. The initiation module 4520 can activate a management module to detect, manage, analyze, and restrict network traffic corresponding to the network transmissions of the user data.

[0208] The management module is configured to analyze the network traffic at different layers of the network transmission based on a type of network traffic corresponding to the network transmission, and send the network traffic to a server limited by the data exchange constraint based on the analysis indicating that the network traffic satisfies the data exchange constraint corresponding to the target user.

[0209] In some implementations, the management module may include a sub-module (also referred to as a first management module) 4210, a sub-module (also referred to as a second management module) 4310, and a sub-module (also referred to as a third management module) 4410. The sub-modules 4210, 4310, and 4410 may analyze and limit network traffic of client apps.

[0210] In some implementations, sub-module 4210 is configured to analyze the network traffic at the network layer based on the type of the network traffic being native type network traffic.

[0211] In some implementations, submodule 4310 is configured, based on the type of network traffic being web page view type network traffic, to transition the web page view type network traffic to a network interface of the client app to be managed by a native network module of the client app and analyze the transitioned network traffic at the network layer.

[0212] In some implementations, transitioning the web page view type network traffic to the network interface of the mobile edge app includes utilizing a JavaScript hooking mechanism to transition the web page view type network traffic.

[0213] In some implementations, submodule 4410 is configured to analyze network traffic at the application programming interface API layer based on the type of network traffic being third-party SDK type network traffic.

[0214] In some implementations, analyzing the network traffic at the API layer includes determining a wrapped API by adding decision logic based on the data exchange constraints to an API of a third-party SDK, and invoking the wrapped API to analyze the network traffic using the decision logic.

[0215] In some implementations, the activation module 4520 can activate the sub-modules 4210, 4310, and 4410 based on determining the target user. For example, the activation module 4520 can determine whether the current user is the target user at the time of user registration. If the determination result is YES, the activation module 4520 can activate the sub-modules 4210, 4310, and 4410. Also, for example, the activation module 4520 can obtain the determination result for this user locally or from a server at the time of user registration, and determine whether to activate the sub-modules 4210, 4310, and 4410 based on the determination result.

[0216] The security sandbox subsystem 1090 may further include a sampling module 4510 for sampling network traffic. In some implementations, the sampling module 4510 can send a sampling signal to the wake-up module 4520 to trigger the wake-up module 4520. The sampling signal can indicate a sampling rate at which to sample the network traffic.

[0217] The sampling module 4510 can sample target users and different types of network traffic based on data exchange constraints. For example, the sampling module 4510 can sample different types of network traffic at different sampling rates. By utilizing the sampling module 4510, only a portion of the network traffic can be analyzed, thereby reducing overhead and maintaining app stability.

[0218] It should be understood that the security sandbox subsystem 1090 may further include other modules or may include only the partial modules shown in Figure 4E. For example, if the target app 1080 is only a native app on the mobile end, the security sandbox subsystem 1090 may not include the sub-module 4310 for web page view type network traffic. The scope of the present disclosure is not limited thereto.

[0219] In some implementations, network traffic may be analyzed and restricted at the socket layer based on the type of network traffic. For example, third-party SDK-type network traffic may be relayed at the socket layer so that third-party SDK-type network requests can be directly analyzed. Alternatively or additionally, native-type network traffic and web page view-type network traffic may be analyzed and restricted at the socket layer.

[0220] In some implementations, a local server may be established as a proxy on the target app 1080. The network requests of the target app 1080 may be forwarded to the local server, and the local server may analyze and restrict the network traffic, thereby managing the network requests forwarded by the local server to external servers. This method may analyze and restrict different types of network traffic taking protocol information into account, thereby better managing the app's network traffic from being transmitted to unauthorized external servers.

[0221] The principles and details of analyzing and restricting different types of network traffic have been described in detail above with reference to Figures 4B to 4E. It should be understood that the above restriction rules, judgment logic, and data exchange restrictions are merely exemplary and do not limit the scope of the present disclosure. For example, different data sovereignty protection rules can be set based on the legal requirements of different countries. Furthermore, depending on the definition of the layers of a computer network, network traffic can be analyzed and restricted at layers close to or similar to the above layers.

[0222] Note that in the above description, the security sandbox subsystem 1090 can directly analyze and restrict network traffic in the target app 1080. In other words, only network traffic that is not restricted by the security sandbox subsystem 1090 can continue to be transmitted. Alternatively or additionally, the security sandbox subsystem 1090 may not directly restrict network traffic but may only provide an analysis report. In such a case, a copy of the network request can be sent to the security sandbox subsystem 1090 at the same time as the network request is successfully transmitted. The security sandbox subsystem 1090 can analyze the copy of the network request and provide an analysis report.

[0223] In some implementations, in the case of multiple data sovereign countries, multiple security sandbox subsystems 1090 may be configured accordingly to process each data sovereign country, respectively. For example, based on a determination of the region where the target user is located, a corresponding security sandbox subsystem may be invoked to analyze and restrict network traffic so that the network transmission of user data in the app complies with the data sovereignty protection rules of the corresponding country.

[0224] Recommendation Management Subsystem As discussed above, a target app may provide users with various content recommendations, such as multimedia content recommendations, user recommendations, and product recommendations, through a recommendation mechanism. In such apps, the fairness of recommendation policies has become a key focus of many local control efforts. For example, some apps may use recommendation mechanisms to induce users to pay attention to specific content that is unrelated to the user's habits, potentially resulting in unfairness.

[0225] On the one hand, common recommendation algorithms often rely on machine learning models for their implementation, and code-level verification performed by, for example, the security computing subsystem 1060 may not be able to effectively detect the fairness of recommendation algorithms. On the other hand, people also do not expect users' privacy data to be exposed during inspection, because the training and updating of recommendation models are often closely related to actual user data, which may lead to data compliance risks.

[0226] The embodiment of the present disclosure further proposes a method for managing recommendation policies. Figure 5 shows a flowchart of a process 500 for managing recommendation policies. The process 500 may be performed by, for example, the recommendation management subsystem 1050.

[0227] As shown in FIG. 5 , in box 502, the recommendation management subsystem 1050 obtains a set of object features related to a set of objects in a target app, where the set of object features are obtained by transformation based on the attributes of the set of objects, and the set of object features do not directly represent the attributes of the set of objects.

[0228] In some embodiments, the recommendation management subsystem 1050 may obtain the set of object features via an application programming interface API provided by the target app. In some embodiments, the recommendation management subsystem 1050 may obtain the set of object features associated with the set of objects in the target app 1080 from the target app platform 1030, for example via a dedicated API.

[0229] In some embodiments, the set of object features may be obtained by, for example, a feature extraction model transforming the set of object attributes. In this manner, a recommendation policy manager or other third party may be prevented from determining the original attribute information of the object based on the object features, thereby ensuring data security in the target app.

[0230] In box 504, the recommendation management subsystem 1050 determines a first object feature and a second object feature from the set of object features, where a first difference between the first object feature and the second object feature is less than a first threshold.

[0231] In some embodiments, the set of object features may be represented, for example, as a plurality of vectors. Further, the recommendation management subsystem 1050 may select at least one pair of object features from the set of object features, for example, based on the difference between the vectors, where the difference is less than a first threshold.

[0232] In box 506, the recommendation management subsystem 1050 determines a first recommendation result corresponding to the first object feature and a second recommendation result corresponding to the second object feature based on a recommendation policy in the target app.

[0233] In some embodiments, the recommendation management subsystem 1050 may provide first object features to a recommendation model associated with the recommendation policy to determine a first recommendation result, and provide second object features to the recommendation model to determine a second recommendation result.

[0234] In some embodiments, to ensure the safety of the recommendation policy, the recommendation management subsystem 1050 may send the selected first and second object features to a remotely run recommendation model via an API provided by the target app to determine the first and second recommendation results. Exemplarily, the recommendation model may be run by, for example, the maintenance side of the target app.

[0235] In some embodiments, the process of generating the first and second recommendation results does not affect the recommendation model actually deployed in the target app.

[0236] In some embodiments, the first recommendation result and the second recommendation result may be represented by a vector output by the recommendation model, so that the recommendation management subsystem 1050 cannot directly decipher the semantics of the first recommendation result and the second recommendation result, thereby further improving the security of data in the target app.

[0237] In box 508, the recommendation management subsystem 1050 evaluates a recommendation policy based on the first recommendation result and the second recommendation result.

[0238] In some embodiments, the recommendation management subsystem 1050 may determine a second difference between the first recommendation result and the second recommendation result and determine the fairness of the recommendation policy based on a comparison between the second difference and a second threshold.

[0239] Specifically, for a reasonable recommendation policy, the recommendation results for two similar objects should be similar. Therefore, if the recommendation management subsystem 1050 determines that the second difference exceeds a second threshold, it may determine that the recommendation policy has relatively poor fairness.

[0240] Alternatively, the recommendation management subsystem 1050 may determine the fairness of the recommendation policy based on, for example, the percentage of object feature pairs whose second difference exceeds a second threshold. For example, the recommendation management subsystem 1050 may randomly sample multiple object feature pairs, and if the percentage of object feature pairs whose second difference exceeds the second threshold exceeds a threshold percentage, the recommendation management subsystem 1050 may determine that the recommendation policy has relatively poor fairness.

[0241] In some embodiments, the recommendation management subsystem 1050 may determine the fairness of the recommendation policy based on the association between the object features to be input into the recommendation model and the historical recommendation results. Specifically, the recommendation management subsystem 1050 may obtain a third object feature and historical recommendation results for the third object feature from the target app. Furthermore, the recommendation management subsystem 1050 determines the fairness of the recommendation policy based on the association between the third object feature and the historical recommendation results. For example, the recommendation management subsystem 1050 may determine the fairness of the recommendation policy based on whether the object features match type information of the historical recommendation results.

[0242] In some embodiments, the recommendation management subsystem 1050 may determine a vector representation corresponding to the third object feature and the historical recommendation result, and determine the relevance between the third object feature and the historical recommendation result based on the difference between the two vector representations. For example, if the vector difference between an object and its historical recommendation result is greater than a threshold, the recommendation management subsystem 1050 may determine that the recommendation policy has relatively poor fairness.

[0243] In some embodiments, as mentioned above, the security computing subsystem 1060 may examine, for example, source code associated with a recommendation policy. Specifically, the security computing subsystem 1060 may obtain, for example, source code corresponding to a recommendation policy and evaluate the recommendation policy based on the source code or intermediate code corresponding to the source code.

[0244] In some embodiments, the recommendation policy may be used to recommend at least one multimedia content to a user, for example, in the target app 1080. Examples of multimedia content may include, for example, images, videos, music, or a combination thereof.

[0245] Example Processes and Equipment 6 illustrates a flowchart of an exemplary process 600 of a data security management method according to some embodiments of the present disclosure. As shown in FIG. 6, at 602, a security computing subsystem manages the security of development code and compiles the development code into an installation file corresponding to a target app and a service program for supporting the target app. At 604, a data exchange subsystem manages data communication between the target app or the service program and overseas. At 606, a security sandbox subsystem manages network traffic related to the target app.

[0246] FIG. 7 illustrates a schematic block diagram of an example device 700 that may be used to implement embodiments of the present disclosure. For example, system 100 and / or system 400 according to embodiments of the present disclosure may be implemented by device 700. As shown, device 700 includes a central processing unit (CPU) 701, which may perform various appropriate operations and processes based on computer program instructions stored in read-only memory (ROM) 702 or loaded from storage unit 708 into random access memory (RAM) 703. RAM 703 may store various programs and data necessary for device 700 operation. CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. An input / output (I / O) interface 705 is also connected to bus 704.

[0247] Several components in device 700 are connected to I / O interface 705, including an input unit 706 (e.g., keyboard, mouse, etc.), an output unit 707 (e.g., various types of displays, speakers, etc.), a storage unit 708 (e.g., magnetic disk, optical disk, etc.), and a communication unit 709 (e.g., network card, modem, wireless communication transceiver, etc.). The communication unit 709 allows device 700 to exchange information / data with other devices via, for example, a computer network of the Internet and / or various telecommunication networks.

[0248] Each of the processes and operations described above, such as process 600, may be performed by execution of processing unit 701. For example, in some embodiments, process 600 may be implemented as a computer software program that is tangibly contained on a machine-readable medium, such as storage unit 708. In some embodiments, some or all of the computer program may be loaded and / or installed into device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by CPU 701, it may perform one or more operations of process 600 described above.

[0249] The present disclosure may be a method, an apparatus, a system, and / or a computer program product, which may include a computer-readable storage medium having stored thereon computer-readable program instructions for carrying out aspects of the present disclosure.

[0250] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, machine-encoded devices such as punch cards or slot-in-projection structures having instructions stored thereon, and any suitable combination of the above. As used herein, computer-readable storage medium is not to be construed as a momentary signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0251] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in each computing / processing device.

[0252] Computer program instructions for carrying out the operations of the present disclosure may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or target code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and the like, and traditional procedural programming languages ​​such as "C" or similar programming languages. The computer-readable program instructions may be executed entirely on the user computer, partially on the user computer, as a separate software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, the state information of the computer-readable program instructions is used to personalize and customize an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), that is capable of executing the computer-readable program instructions, thereby implementing aspects of the present disclosure.

[0253] Aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer-readable program instructions.

[0254] These computer-readable program instructions may be provided to a processing unit of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when these instructions are executed by the processing unit of the computer or other programmable data processing apparatus, it generates an apparatus that implements the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium that causes the computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable medium on which the instructions are stored comprises an article of manufacture containing instructions that implement each aspect of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0255] Computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other apparatus such that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other apparatus to produce a computer-implemented process whereby the instructions executing on the computer, other programmable data processing apparatus, or other apparatus implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0256] The flowcharts and block diagrams in the figures illustrate possible system architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, program segment, or part of an instruction set, which includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions illustrated in the blocks may occur in a different order than illustrated in the figures. For example, two consecutive blocks may actually be executed essentially in parallel, or may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or operation, or by a combination of dedicated hardware and computer instructions.

[0257] Although the embodiments of the present disclosure have been described above, the above description is illustrative, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used in this specification is intended to best interpret the principles, practical applications, or improvements in technology in the marketplace of the embodiments, or to enable other skilled in the art to understand the embodiments disclosed herein.

Claims

1. a security computing subsystem configured to manage security of the development code and compile the development code into an installation file corresponding to a target app and a service program for supporting the target app; a data exchange subsystem configured to manage data communication between the target application or the service program and a foreign country; a security sandbox subsystem configured to manage network traffic associated with the target app and, based on the network traffic satisfying a data exchange constraint corresponding to the target user, send the network traffic to a server limited by the data exchange constraint; The target application or the service program communicates with the data exchange subsystem via a first platform, and the data exchange subsystem further: obtaining raw data to be exchanged between the first platform and the second platform; processing the raw data based on the type of the raw data to obtain unified format data corresponding to the type; A system for data security configured to determine from the unified format data that data exchange constraints are satisfied.

2. The security computing subsystem further comprises: Compiling the development code to generate intermediate code; The system of claim 1 , configured to provide the intermediate code to a code scanning module managed by a trusted collaborator to determine safety of the developed code.

3. The security computing subsystem further comprises: obtaining third-party libraries related to said development code; The system of claim 2 , configured to generate the intermediate code based on the development code and the third-party library.

4. The security computing subsystem includes: The system of claim 1 , comprising a deployment gateway configured to provide the installation file to an app store or deploy the service program to a target app platform.

5. The security computing subsystem further comprises: The system of claim 4 , configured to generate a signature corresponding to the installation file or the service program in response to determining that the development code is safe.

6. The system of claim 1 , wherein the first platform is a target application platform under the jurisdiction of a specific country or region, and the second platform is a target application platform under the jurisdiction of another country or region.

7. converting the unified format data to the raw data if it is determined that the unified format data satisfies the data exchange constraints; 2. The system of claim 1, further comprising: performing an exchange of the raw data between the first platform and the second platform.

8. Processing the raw data includes: Detecting a format of the raw data, wherein the type of raw data includes a plurality of formats; The system of claim 1 , further comprising: converting the format of the raw data into a specified format in the plurality of formats by format conversion to obtain the unified format data.

9. Creating a plurality of data channels between the first platform and the second platform, each corresponding to a plurality of types of raw data, and processing the raw data includes: selecting a data channel from the plurality of data channels based on a type of the raw data; and providing the raw data to a selected data channel for processing.

10. the target app is a client app, and the security sandbox subsystem further comprises: Based on determining the target user, detecting a network transmission of user data of the target user from the client app to a server; analyzing the network traffic at different layers of the network transmission based on a type of network traffic corresponding to the network transmission; 2. The system of claim 1, further configured to send the network traffic to a server defined by a data exchange constraint based on the analysis indicating that the network traffic satisfies a data exchange constraint corresponding to the target user.

11. The type of network traffic is: Native-type network traffic associated with native apps and Web page view type network traffic related to the app's built-in browser, and Third-party SDK type network traffic relating to third-party software development kits (SDKs); and The system of claim 10, comprising at least one of:

12. Analyzing the network traffic at different layers of the network transmission includes: The system of claim 10 , further comprising analyzing the network traffic at a network layer based on the type of the network traffic being native type network traffic.

13. Analyzing the network traffic at different layers of the network transmission includes: Based on the type of the network traffic being a web page view type network traffic, transitioning the web page view type network traffic to a network interface of the client application to be managed by a native network module of the client application; and analyzing the transitioned network traffic at a network layer.

14. Analyzing the network traffic at different layers of the network transmission includes: The system of claim 10 , further comprising analyzing the network traffic at an application programming interface API layer based on the type of the network traffic being third-party SDK type network traffic.

15. Obtain a set of object features related to a set of objects in the target application, and the set of object features are obtained by transforming the set of object features based on attributes of the set of objects, where the set of object features do not directly represent the attributes of the set of objects; determining a first target feature and a second target feature from the set of object features, wherein a first difference between the first target feature and the second target feature is less than a first threshold; Determine a first recommendation result corresponding to the first target feature and a second recommendation result corresponding to the second target feature based on a recommendation policy in the target app; The system of claim 1 , further comprising a recommendation assessment subsystem configured to evaluate the recommendation policy based on the first recommendation result and the second recommendation result.

16. The recommendation assessment subsystem further comprises: The system of claim 15 , configured to obtain the set of object features via an application programming interface API provided by the target app.

17. managing the security of the development code by a security computing subsystem, and compiling the development code into an installation file corresponding to a target application and a service program for supporting the target application; managing data communication between the target application or the service program and overseas by a data exchange subsystem; managing network traffic associated with the target app by a security sandbox subsystem, and sending the network traffic to a server defined by the data exchange constraints based on the network traffic satisfying the data exchange constraints corresponding to the target user; The target application or the service program communicates with the data exchange subsystem via a first platform, and the data exchange subsystem further: obtaining raw data to be exchanged between the first platform and the second platform; processing the raw data based on the type of the raw data to obtain unified format data corresponding to the type; A method for data security configured to determine from the unified format data that data exchange constraints are satisfied.

18. An electronic device including a memory and a processor, 20. An electronic device, wherein the memory is adapted to store one or more computer instructions, the one or more computer instructions being executable by the processor to implement the method of claim 17.

19. 20. A computer-readable storage medium having stored thereon one or more computer instructions, the one or more computer instructions being executed by a processor to implement the method of claim 17.

20. 20. A program product comprising one or more computer instructions, the one or more computer instructions being executed by a processor to implement the method of claim 17.

Images