Method and device for managing network traffic of client applications

Abstract

Provided herein is a method, apparatus, device, and storage medium for managing network traffic of a client application. The method described herein includes: based on the determination of a target user, detecting the network transmission of user data of the target user from the client application to the server; based on the type of network traffic corresponding to the network transmission, analyzing the network traffic at different layers of the network transmission; and based on the analysis indicating that the network traffic satisfies the data exchange constraints corresponding to the target user, sending the network traffic to a server defined by the data exchange constraints. In this way, by analyzing and limiting the network traffic that does not satisfy the data exchange constraints in the network traffic at different layers of the network transmission based on the type of the network traffic, it is possible to effectively prevent user data from being transmitted to an unauthorized server via various types of network traffic.

Description

Technical Field

[0001] Various implementations of the present disclosure relate to the computer field, and more specifically, to methods, devices, equipment, and computer storage media for client applications. Background Art

[0002] With the development of Internet technology, various Internet applications have become an important part of people's lives. Such applications will generate massive amounts of data every day, which brings about various data security issues such as data sovereignty protection. For example, some countries may prohibit certain types of user data from being sent to overseas servers.

[0003] For some global applications, such challenges are even more significant. Such global applications may need to provide services to users in multiple 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 further increases the difficulty of data security protection. Summary of the invention

[0004] In a first aspect of the present disclosure, a method for managing network traffic of a client application is provided. The method comprises: based on the determination of a target user, detecting the network transmission of user data of the target user from the client application to a server; based on the type of network traffic corresponding to the network transmission, analyzing the network traffic at different layers of the network transmission; and based on the analysis indicating that the network traffic satisfies the data exchange constraint corresponding to the target user, sending the network traffic to a server defined by the data exchange constraint.

[0005] In a second aspect of the present disclosure, a device for managing network traffic of a client application is provided. The device includes: a startup module configured to start detection of network transmission of user data of the target user from the client application to the server based on the determination of the target user. The device also includes a management module configured to: in response to being activated by the startup module, analyze network traffic at different layers of network transmission based on the type of network traffic corresponding to the network transmission; and send the network traffic to the server defined by the data exchange constraint based on the analysis indicating that the network traffic satisfies the data exchange constraint corresponding to the target user.

[0006] In a third aspect of the present disclosure, an electronic device is provided, comprising: a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method according to the first aspect of the present disclosure.

[0007] In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which one or more computer instructions are stored, wherein the one or more computer instructions are executed by a processor to implement the method according to the first aspect of the present disclosure.

[0008] In a fifth aspect of the present disclosure, a computer program product is provided, which includes one or more computer instructions, wherein the one or more computer instructions are executed by a processor to implement the method according to the first aspect of the present disclosure.

[0009] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0010] Figure 1 A schematic block diagram of a data security protection system according to an embodiment of the present disclosure is shown;

[0011] Figure 2 A schematic block diagram of a computing security subsystem according to some embodiments of the present disclosure is shown;

[0012] Figure 3A An example deployment environment in which a data exchange subsystem is deployed according to some embodiments of the present disclosure is shown;

[0013] Figure 3B The implementation of DES in an internal data center (IDC) of a TTP party and an offshore internal data center (RoW IDC) where a non-TTP is located according to some embodiments of the present disclosure is shown;

[0014] Figure 3C A block diagram illustrating an example architecture of a DE according to some embodiments of the present disclosure;

[0015] Figure 3D A flow chart showing a data exchange process according to some embodiments of the present disclosure;

[0016] Figure 3E A flowchart illustrating an example data flow of various types of data processing implemented at a DES according to some embodiments of the present disclosure;

[0017] Figure 3F A schematic block diagram of a data exchange architecture involving an MQ channel according to some embodiments of the present disclosure is shown;

[0018] Figure 3G A schematic block diagram of a data exchange architecture involving an HDFS channel according to some embodiments of the present disclosure is shown;

[0019] Figure 3HA schematic diagram showing a target object storage (TOS) channel for copying data from a TTP IDC to an overseas IDC according to some embodiments of the present disclosure;

[0020] Fig. 3I A schematic diagram showing a TOS channel for copying data from an overseas IDC to a TTP IDC according to some embodiments of the present disclosure;

[0021] Figure 3J shows a message sequence chart in a TOS channel according to some embodiments of the present disclosure;

[0022] Figure 3K A schematic block diagram of a data exchange architecture involving a service call channel according to some embodiments of the present disclosure is shown;

[0023] Figure 3L An example of data exchange from a non-TTP to a TTP in a service call channel according to some embodiments of the present disclosure is shown;

[0024] Figure 3M An example of data exchange from a TTP to a non-TTP in a service call channel according to some embodiments of the present disclosure is shown;

[0025] Figure 4A A flowchart showing a method for managing network traffic of a mobile application according to some embodiments of the present disclosure is shown;

[0026] Figure 4B A schematic diagram showing an analysis and interception process for native type network traffic according to some embodiments of the present disclosure is shown;

[0027] Figure 4C A schematic diagram showing an analysis and interception process for web view type network traffic according to some embodiments of the present disclosure is shown;

[0028] Figure 4D A schematic diagram showing an analysis and interception process for third-party SDK type network traffic according to some embodiments of the present disclosure is shown;

[0029] Figure 4E A module diagram of a security sandbox system according to some embodiments of the present disclosure is shown; and

[0030] Figure 5 A flowchart illustrating an example process for managing a recommendation strategy according to some embodiments of the present disclosure;

[0031] Figure 6 An example block diagram showing an apparatus for data exchange according to some embodiments of the present disclosure; and

[0032] Figure 7A block diagram of an example device that may be used to implement embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0033] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for 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 for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0034] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0035] The basic principles and several example implementations of the present disclosure are explained below with reference to the accompanying drawings.

[0036] Overall architecture of data security protection system

[0037] According to an embodiment of the present disclosure, a data security protection system is provided. Figure 1 FIG. 1 shows a schematic block diagram of a data security protection system 1000 according to an embodiment of the present disclosure. Figure 1 As shown, the data security protection system 1000 includes multiple subsystems for protecting the security of relevant data generated by users when using the target application from different dimensions.

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

[0039] In some embodiments, the data security protection system 1000 can firstly ensure the security of the data generated by the target application 1080 during operation from the perspective of the security of the running code. Figure 1 As shown, the data security protection system 1000 may include a secure computing subsystem 1060 , which may be used to ensure the security of the code corresponding to the target application 1080 , and to ensure the security of the code corresponding to the target application platform 1030 .

[0040] The service running file compiled by the computing subsystem 1060 can be deployed to the target application platform 1030, and the installation file (e.g., apk file) of the target application compiled by the computing subsystem 1060 can be published to the application store 1120. The specific implementation of the secure computing subsystem 1060 will be described below in conjunction with Figure 2 Discuss in detail.

[0041] In some embodiments, Figure 1 As shown, the secure computing subsystem 1060 may be based on a cloud infrastructure 1070. In some embodiments, the cloud infrastructure 1070 may be provided by a trusted partner, for example. In the present disclosure, a "trusted partner" may also be referred to as a trusted technology partner (Trusted Technology Partner, TTP), which may include, for example, any individual, enterprise or organization that is technically trusted in a specific region (e.g., a specific country or jurisdiction).

[0042] In some embodiments, Figure 1 As shown, the data security protection system 1000 may include a trusted security environment 1010 provided by the TTP. Different from the traditional application platform deployment, the target application platform 1030 may be deployed in the trusted security environment 1010 to improve the security of the data generated by the target application platform 1030, as well as the transparency and credibility of its operating mechanism.

[0043] In some embodiments, the target application 1080 can provide content recommendation services to users through recommendation algorithms. Such content recommendations may include, but are not limited to: multimedia content recommendations, user recommendations, product recommendations, etc. Considering that more and more recommendation systems currently use machine learning to implement recommendation functions, it may be difficult to ensure the fairness of recommendations by managing the recommendation mechanism only at the code level.

[0044] like Figure 1 As shown, the data security protection system 1000 may also include a recommendation management subsystem 1050, which may, for example, test the recommendation algorithm run by the target application platform 1030 to ensure the fairness of the recommendation mechanism in the target application 1080. The specific implementation of the recommendation management subsystem 1050 will be described in detail below.

[0045] In some embodiments, considering that the target application platform 1030 is running services to support the normal operation of the target application 1080, the target application platform 1030 may need to interact with applications or data centers (also called offshore applications or offshore data centers) outside the target area (e.g., a specific country or jurisdiction) in which it is currently deployed.

[0046] Generally speaking, the target region usually restricts the communication between the data generated in the region and overseas through laws or regulations. Certain types of data generated in the target region may be prohibited from being transmitted overseas. In order to ensure the compliance of the target application platform 1030 in the process of communicating with overseas, the data security protection subsystem may include a data exchange subsystem 1040. Similarly, the data exchange subsystem 1040 can be deployed in the trusted security environment 1010 to ensure the transparency and credibility of its operation.

[0047] In some embodiments, Figure 1 As shown, the data exchange subsystem 1040 may include multiple data channels for different types of data transmission. For example, the multimedia data generated in the target application platform 1030 may communicate with the overseas application 1140 and / or the overseas data center 1150 through the corresponding data channels in the data exchange subsystem 1040 and the content distribution network 1130 provided by a third party.

[0048] As another example, for some specific internal data generated in the target application platform 1030, it can communicate with the overseas data center 1150 and the overseas development department 1160 through corresponding data channels and, for example, through direct optical cables. The specific implementation of the data exchange subsystem 1040 will be described below in conjunction with FIG. 3A to FIG. 3M Detailed description.

[0049] Furthermore, in order to ensure the security of the egress and ingress communications of the target application platform 1030, in some embodiments, the data security protection system 1000 may further include an application firewall subsystem 1020. The application firewall subsystem 1020 may be deployed in the trusted security environment 1010, for example, and may be used to monitor data communications from the target application 1080 to the target application platform 1030, data communications from the target application platform 1030 to the target application 1080, and / or data communications from the target application platform 1030 to the third-party application 1110, etc.

[0050] In this way, the data security protection platform 1000 can not only ensure the security and compliance of data communications between the target application platform 1030 and overseas through the data exchange subsystem 1040, but also ensure the security and compliance of communications between the target application platform 1030 and various objects within the country (for example, the target application 1080 or third-party application 1110, etc.) through the application firewall subsystem 1020.

[0051] In some embodiments, for the target application 1080, in order to ensure the compliance and trustworthiness of its operation, the data security protection system 1000 may also include, for example, a security sandbox system 1090 managed by the TTP, which enables different types of network communications involved in the application business logic 1100 of the target application 1080 to be protected by the security sandbox system 1090. In this way, the data security protection system 1000 can prevent the target application 1080 from initiating non-compliant data communications, for example, through backdoor programs. The detailed implementation of the security sandbox system 1090 will be described below in conjunction with FIG. 4A to FIG. 4E Detailed description.

[0052] Therefore, based on the data security protection system 1000 disclosed in the present invention, TTP can manage and monitor various aspects such as code security and data security during the entire life cycle from the development to the operation of the target application, thereby ensuring the security of the data associated with the target application and ensuring the compliance of its operation.

[0053] Secure computing subsystem

[0054] The following will refer to Figure 2 The secure computing subsystem 1060 is described in detail. Figure 2 A schematic block diagram of a secure computing subsystem 1060 according to an embodiment of the present disclosure is shown.

[0055] like Figure 2 As shown, the secure computing subsystem 1060 may include, for example, a secure code environment 2010 , which may be provided by, for example, a TTP. The working process of the secure computing subsystem 1060 will be described below in conjunction with submitting a new development code 2140 .

[0056] like Figure 2 As shown, when a developer has new development code 2140 that needs to be deployed, the developer can submit the development code 2140 to the secure code environment 2010 through a synchronization gateway 2150 provided by the TTP. Accordingly, the development code 2140 will be synchronized to the code base 2160 in the secure code environment 2010.

[0057] In some embodiments, when a developer needs to use new development code 2140 for compilation, the developer may send a build request to the artifact build system 2080 through the synchronization gateway 2150 , for example.

[0058] Alternatively, when the code repository 2160 receives new development code 2140 , the code repository 2160 may also automatically send a code merge event to the artifact building system 2080 to trigger the artifact building system 2080 to start the artifact (eg, executable code) building process.

[0059] When the building process is started, the code pulling module 2090 can obtain the code files used for building from the code library 2160. In some embodiments, the code files used for building can be specified by the developer, or automatically determined by the product building system 2080, for example.

[0060] Furthermore, the compiling module 2100 may compile the code pulled from the code repository 2160 by the code pulling module 2090 to, for example, compile the code into an intermediate code.

[0061] In some embodiments, considering that some third-party codes are often introduced during the code compilation process, the secure computing subsystem 1060 also needs to ensure the security of the introduced third-party codes.

[0062] like Figure 2 As shown, the secure computing subsystem 1060 may include a third-party independent gateway 2030 for checking and confirming the security of the third-party library 2020 to be introduced. It should be understood that such a third-party library may also be a compiled link library or the source code itself.

[0063] The third-party library 2020 that passes the security check can be added to the product library 2040. Figure 2 As shown, during the artifact construction process, the compilation module 2100 can also obtain other artifacts on which the compilation of the current artifact depends from the artifact library 2040, such as artifacts that have been compiled and generated in the past, or artifacts generated based on the third-party library 2020, etc.

[0064] Furthermore, the compilation module 2100 may, for example, compile the code pulled from the code repository 2160 and the dependent artifacts obtained from the artifact repository 2040 to generate intermediate code, so that the security code scanning module 2110 can perform code security detection.

[0065] It should be understood that the secure code scanning module 2110 managed by the TTP can execute any appropriate code scanning process to perform security checks, and such scanning rules are unknown to developers, thereby ensuring the security of the code used to compile the final product.

[0066] In some embodiments, the upload module 2120 may perform corresponding uploads according to the result 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 upload the further compiled executable file to the artifact library 2040.

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

[0068] On the contrary, if the security code scanning module 2110 determines that the current intermediate code has corresponding risks, the upload module 2120 can upload the relevant risks to the issue tracking system 2070 to, for example, form a risk analysis report. Accordingly, the compiled executable file will be prohibited from being uploaded to the artifact library 2040.

[0069] In some embodiments, the development code 2140 in the code base 2160 may also be provided in a trusted environment, for example, for manual verification. If it is determined that the development code 2140 has a risk, the result may also be reported to the issue tracking system 2070 .

[0070] In some embodiments, if the security code scanning module 2110 determines that the current intermediate code has corresponding risks, the upload module 2120 may also notify the callback module 2130 to mark the corresponding code as risky code in the code library 2160 .

[0071] In some embodiments, the issue tracking system 2070 maintained by the TTP may, for example, send the received risk reporting information to the developer or maintainer of the development code 2140 to remind them that the current development code 2140 cannot pass the security check and therefore cannot be deployed.

[0072] In some embodiments, if the development code 2140 passes the security check, it may be compiled into an executable file and further added to the artifact library 2040 to be deployed, for example, via the deployment gateway 2050 .

[0073] In some embodiments, before deploying the artifact (i.e., executable file) obtained from the artifact library 2040, the deployment gateway 2050 can verify whether the signature of the artifact is valid through the artifact signature management system 2060. When the validity of the signature of the artifact is confirmed, the deployment gateway 2050 can deploy the artifact generated based on the development code 2140 to the network.

[0074] In some embodiments, the product may be, for example, an application program executed at a client device, and the deployment gateway 2050 may, for example, publish the generated installation file (e.g., apk file) to a corresponding application store for the user to download. Thus, the embodiments of the present disclosure may ensure that the installation file that the user can download and install is always published by the secure code environment 2010 via the deployment gateway 2050.

[0075] In some embodiments, the product may be, for example, a service program for deployment to the target application platform 1030. Specifically, the maintainer of the target application may initiate a request to the deployment platform to deploy a specific product to the target application platform 1030. Accordingly, after the request is reviewed, 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 is authenticated, the product may be deployed to the target application platform 1030, for example, in the form of a virtual machine or a container.

[0076] Therefore, based on the discussed secure computing subsystem, the embodiments 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 various links such as code uploading, code writing, code compiling, and third-party library reference. Based on this approach, the embodiments of the present disclosure can effectively avoid various security vulnerabilities or compliance risks introduced in the source code.

[0077] Data exchange subsystem

[0078] The operation of the application involves data interaction between application platforms governed by different countries and regions. Figure 1 In the example shown, it is expected that data is exchanged between the target application platform 1030 and the target application platform where the same application is running abroad to provide global data interaction of the application. As previously described, the data exchange subsystem (DES) 1040 can support the synchronization of the public data of the target application and other data that meet the rules between different platforms, and ensure the security and compliance of the exchanged data. In general, DES1040 is configured to detect whether the data between different platforms meets the data exchange constraints. Data exchange constraints may include constraints set to meet national or regional laws and regulations, constraints that need to be set due to other requirements of enterprise, organization and / or user protection, and so on.

[0079] For example, in countries or regions with specific data sovereignty protection requirements, the TTP may be required to conduct checks involving data sovereignty protection. Therefore, in many cases involving cross-platform data exchange, it is necessary to protect the security and compliance of data exchange. In particular, after setting up a TTP computer room, the data exchange between the outside world and the data stored in the TTP computer room will be restricted, and the data that is expected to interact with the TTP party will be subject to data sovereignty protection checks. In such an example, the data exchange constraints may include rules related to the data sovereignty protection requirements of a specific country or region.

[0080] This type of interactive data can be divided into two aspects: one aspect includes intercommunication data between platforms, and the other aspect includes operation and maintenance data such as the access or operation of the platform by the operation and maintenance personnel of the platform. Intercommunication data is mainly used for synchronization between the two platforms to ensure the functional integrity of the application. This type of data needs to be checked by the DES system for security and compliance. Intercommunication data includes, for example, online business data and offline data. The inspection of operation and maintenance data is to ensure that the operations of the operation and maintenance personnel on the operation and maintenance control plane are also compliant.

[0081] Figure 3A An example deployment environment 3001 is shown in which the DES 1040 is deployed according to some embodiments of the present disclosure.

[0082] exist Figure 3A In the figure, TTP party 3027 refers to an environment in a specific country or region that needs to be supervised and constrained by TTP. TTP party 3027 may involve various components for operating, managing, and maintaining the target application, such as business system 3028, operation platform 3029, online storage 3030, offline storage 3031, etc. TTP party 3027 also includes operation and maintenance platform 3032, and operation and maintenance personnel will need to access operation and maintenance platform 3032 to access, manage, or maintain the target application.

[0083] Similarly, non-TTP party 3020 refers to an environment belonging to one or more other countries or regions outside a specific country or region, which is not subject to the data exchange constraints of the country or region where TTP party 3027 is located. Non-TTP party 3020 may involve various components for operating, managing, and maintaining target applications, such as business system 3025, operation platform 3021, online storage 3022, offline storage 3023, etc. Non-TTP party 3020 also includes operation and maintenance platform 3024, and operation and maintenance personnel will need to access operation and maintenance platform 3024 to access, manage, or maintain local applications or application platforms.

[0084] Domestic user traffic will flow through some components of TTP party 3027, and overseas user traffic will flow through some components of non-TTP party 3020. In this article, "domestic user traffic" refers to user traffic generated on the application platform under the jurisdiction of the specific country or region, and "overseas user traffic" refers to user traffic generated on the application platform under the jurisdiction of one or more other countries or regions outside the specific country or region.

[0085] exist Figure 3AIn an environment of , intercommunication data includes domestic user traffic and overseas user traffic exchanged between TTP parties and non-TTP parties. Intercommunication data will pass through DES1040 for data security and compliance checks. In addition, an operation gateway 3026 can also be set to perform data security and compliance checks on operation and maintenance data.

[0086] As will be discussed in detail below, in DES 1040, different data channels may be set according to the type of data to perform checks on the data to be exchanged in the corresponding channels. Figure 3A Some channels are schematically shown, including a target object storage (TOS) channel, a message queue (MQ) channel, an offline aggregation data channel, a log (LOG) channel, a service call channel, etc.

[0087] Both parties in data exchange may have their own DES to implement data protection, for example, to protect incoming data and / or outgoing data.

[0088] Figure 3B It further illustrates the implementation of DES 1040 in the internal data center (IDC) of the TTP party and the offshore internal data center (RoW IDC) where the non-TTP is located.

[0089] exist Figure 3B In the data protection regulations, TTP IDC 3056 refers to the IDC for target applications running in a specific country or region, which is subject to the data protection detection of TTP, and overseas IDC 3059 refers to the IDC for target applications running in one or more other countries or regions outside the specific country or region, which may be subject to the data protection constraints of other countries or regions.

[0090] like Figure 3B As shown, DES1040A is implemented in TTP IDC 3056 to detect external inflow and / or internal outflow data. DES1040B is implemented in overseas IDC 3059 to detect external inflow and / or internal outflow data. DES1040A and DES1040B can be considered as specific deployment instances of DES1040.

[0091] From the perspective of TTP IDC 3056, data flowing in from the outside or out from the inside may include various types of data, which will be described below with examples.

[0092] like Figure 3BAs shown, for TTP IDC 3056, the data flowing in from outside may include user requests, such as active requests initiated by users in a specific country or region through a target application 3058 running in the territory. As will be described in other parts of this article, in some embodiments, the user request may also be protected for security through a mobile sandbox and / or a firewall gateway 3057 in TTP IDC 3056. The user request will arrive at the domestic application platform 3041 in TTP IDC 3056 for further processing. In some examples, the domestic application platform 3041 may include various services, supplier gateways, storage, and other components. In addition, if the user request is to be transmitted to a data center outside of TTP IDC 3056, the user request will be passed to DES1040A for data protection.

[0093] In some embodiments, for TTP IDC 3056, the external inflow data may also include supplier requests initiated by supplier 3055, such as requesting specific services of a domestic application platform. For example, a third-party supplier may call an application programming interface (API) of a domestic application platform, such as OpenAPI. Since it is impossible to confirm whether the third-party supplier is a domestic user, the supplier request will be sent to the supplier gateway in the domestic application platform 3041 via the third-party gateway 3040 in TTP IDC 3056 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 overseas user, the supplier request will be transmitted through DES1040A.

[0094] In some embodiments, for TTP IDC 3056, the external inflow data may also include data synchronized from overseas IDC 3059 to TTP IDC 3056. For example, if data security audit is required for the overseas inflow data, the overseas inflow data also needs to be processed by DES 1040A.

[0095] In some embodiments, for TTP IDC 3056, the data flowing in from outside may also include the operation and maintenance operations of TTP IDC 3056 by the operation and maintenance personnel, such as changes to TTP IDC 3056. Such operations may include code changes, configuration changes, log maintenance, etc. Code changes may include, for example, the launch of new functions, the release of bin files, etc. Code changes may be performed by domestic operation and maintenance personnel of the application platform of this international or regional country. Configuration changes may include enabling or disabling some settings of the target application, scheduling traffic configuration, etc. In some cases, for application platforms operating across borders, configuration changes may be performed by overseas platform operation and maintenance personnel. Of course, this depends only on the management requirements of different applications. Log maintenance refers to the maintenance of logs 3044 in TTP IDC 3056.

[0096] In some embodiments, domestic or overseas operation and maintenance personnel can perform operation and maintenance operations on TTPIDC 3056 under network isolation conditions to further ensure data sovereignty protection. Figure 3B As shown, domestic operation and maintenance personnel initiate operation and maintenance operations under network isolation, and the operation and maintenance operations will be distributed through load balancer 3045 to be distributed to code 3042 in TTP IDC 3056, operation and maintenance platform 3043 or log 3044. In addition to network isolation, the operation and maintenance operations of overseas operation and maintenance personnel will be further checked for security through operation gateway 3046, and then distributed to code 3042 in TTP IDC 3056, operation and maintenance platform 3043 or log 3044.

[0097] In some embodiments, for TTP IDC 3056, the internal outflow data may include a third-party request initiated from the domestic application platform 3041 during the operation of the application platform to request a third-party service 3054, such as a third-party service in a public network. The third-party request also needs to be protected by DES 1040A.

[0098] In some embodiments, for TTP IDC 3056, the internal outflow data may also include data synchronized from TTP IDC 3056 to overseas IDC 3059. For example, during the operation of the target application, it may be necessary to synchronize the user content stored in TTP IDC 3056 to overseas IDC 3059. According to some regulations on data sovereignty protection, such data may be key data that DES 1040A needs to review.

[0099] In some embodiments, for TTP IDC 3056, the internal outflow data may also include code synchronization data. For example, in some cases, due to inspection requirements for data sovereignty protection and other aspects, code review of the target application or application platform may be required. In order to prevent code leakage while meeting data sovereignty protection requirements, the code may be synchronized to the secure isolation environment 3051 for review. The secure isolation environment 3051 may be, for example, a physical environment such as a computer room that is not connected to the Internet, a monitored computer room, or a virtual computing environment with security protection, etc.

[0100] From the perspective of the overseas IDC 3059, the DES1040B deployed therein will also provide security protection for similar external inflow data and internal outflow data. For example, user requests generated by users through the target application 3058 running overseas can also be protected by DES1040B after reaching the overseas application platform 3048 (which may include various services and storage) through the load balancer 3047. In terms of operation and maintenance, overseas operation and maintenance personnel can also perform operation and maintenance operations on the overseas application platform 3048 through the crystal gateway 3049 under network isolation. This type of operation and maintenance operation can also be protected by DES1040B.

[0101] For data protected in DES 1040A or 1040B, the scheme for performing data sovereignty protection and the processing required to implement data sovereignty protection may also be different depending on the type.

[0102] In an embodiment of the present disclosure, in DES1040 (for example, DES1040A or 1040B), data can be preprocessed according to the type of data to uniformly format the data, thereby simplifying and facilitating subsequent checks on data sovereignty protection and accelerating the data exchange process.

[0103] Therefore, DES1040 can be divided into different processing parts according to data types. For example, according to the data source, DES1040A 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; an engineering technology data channel for processing engineering and operation and maintenance data, such as various types of R&D data, operation and maintenance data such as code and parameters. Furthermore, depending on the processing technology of data generation, transmission, reception, storage, etc., the data in each channel can be further divided. As will be described below, according to the technical division, the data in different channels can be divided into one or more of message queue (MQ) data, offline aggregation data, target object storage (TOS) data, service call data, or other types of data.

[0104] For data that has passed the data sovereignty protection review, the data in the unified format can be converted back to the original format and provided to the corresponding destination. According to the scheme of the present disclosure, due to different data sources, different types of data are different in data format, processing technology, etc., and the complexity of the subsequent review stage of data sovereignty protection can be reduced through unified formatting pre-processing and post-processing. In addition, with the update of data sources and technical expansion / changes, etc., only the pre-processing and post-processing of the data need to be changed, without making complex changes to the processing in the data exchange constraint determination stage. As a result, the data exchange architecture has great flexibility and scalability.

[0105] Some specific embodiments will be described in detail below with reference to the accompanying drawings.

[0106] The overall architecture and data flow of DES

[0107] Figure 3C FIG. 1 is a block diagram showing an example architecture of a DES 1040 according to some embodiments of the present disclosure. Figure 3C In the example, DES 1040 is shown as synchronizing data between a domestic application platform 3041 and an external application platform (collectively referred to as an overseas application platform 3048) for a target application, and performing determination of data exchange constraints.

[0108] like Figure 3C As shown, DES1040 may include a DES adapter 3061, a DES center and a DES adapter 3070. The DES center may include a DES center 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. In the following, sometimes for the convenience of description, DES centers 3065A, 3065B and 3065C may be collectively referred to as DES centers 3065.

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

[0110] Each DES center 3065 is configured to detect data using data exchange constraints to ensure the security and compliance of data exchanged between the two application platforms. Typically, data that meets the data exchange constraints will be passed to the corresponding destination through DES1040, while data that does not meet the data exchange constraints may be rejected by DES1040.

[0111] DES adapters 3061 and 3070 may be configured to perform pre-processing and post-processing on data to be transmitted to DES center 3065 so that DES center 3065 determines whether data exchange constraints are satisfied based on uniformly formatted data corresponding to each data type.

[0112] In some embodiments, the DES adapter 3061 and the DES center 3065 in the 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 .

[0113] In some embodiments, different components in DES 1040 can be isolated to further ensure more effective data isolation. Such data isolation can be achieved by deploying different components in different data centers. In some embodiments, data isolation can be achieved by applying virtual private data center (VPC) technology. For example, Figure 3CAs shown, DES adapter 3061 can be implemented in VPC1, each DES center can be implemented in VPC2, and DES adapter 3070 can be implemented in VPC3. The determination of data security and compliance in DES center 3065 can be performed by TTP. In the case of data isolation, VPC1 and VPC3 do not have a direct communication connection, but VPC1 and VPC3 have a direct communication connection with VPC2 respectively, and can communicate data / information with each other. Through the data isolation brought by VPC technology, DES center 3065 deployed in VPC2 can be a TTP trusted area (referred to as a TTP trusted area).

[0114] In some embodiments, the DES adapter 3061 may include a DES entry 3062, which may implement control plane processing, such as application by operation and maintenance personnel to establish and manage data channels, registration rules, etc., and the data in the channel may be viewed by the TTP. The DES adapter 3061 may also include a DES proxy 3063, which may implement data plane processing, such as data verification, data filtering, data conversion, data sampling, log detection, etc. Similarly, in some embodiments, the DES adapter 3070 may include a DES entry 3072 of the control plane and a DES proxy 3073 of the data plane.

[0115] In some embodiments, for domestic user data channels, the DES center 3065A may include a DES registration center for registering data exchange constraints, configuration data, etc. The DES center 3065A may also include further subdivided channels, including a service call channel for service call data, an MQ channel for MQ data, an HDFS channel for offline aggregated data (where HDFS is called Hadoop Distributed File System), and a TOS channel for TOS data. Offline aggregated data, for example, includes highly parallel integrated virtual environment (HIVE) type data.

[0116] Service call data may include, for example, data for remote service calls using various network protocols or call protocols, such as HTTP or RPC. MQ data may include data that supports MQ and similar protocols, such as data stored in various databases (e.g., MySQL, Redis database). Offline aggregation data may include data in a file system based on HDFS technology, as well as data in a file system based on other technologies. TOS data includes object files, such as video, audio, image, document, and other media files.

[0117] In some embodiments, although Figure 3CNot shown, the DES center 3065B for overseas user data channels and the DES center 3065C for engineering technology data channels may also include components similar to the DES center 3065A.

[0118] Figure 3D A flow chart of a data exchange process 300 is shown according to some embodiments of the present disclosure. The process 3004 may be implemented in the DES 1040 .

[0119] like Figure 3D As shown, in block 3301, DES 1040 obtains the original data to be exchanged between the first platform (e.g., domestic application platform 3041) and the second platform (e.g., overseas application platform 3048) by the target application. Depending on the direction of the exchange, the original data may come from the first platform and may be received by the DES adapter 3061 in DES 1040. Alternatively, the original data may come from the second platform and may be received by the DES adapter 3070 in DES 1040.

[0120] In box 3302, DES1040 processes the original data based on the type of the original data to obtain uniformly formatted data corresponding to the type. The processing of the original data (processing herein may also be referred to as preprocessing) can be determined according to the type of the original data. The type of original data may include, for example, MQ data, offline aggregated data, TOS data, or service call data. Further, in some cases, the processing of the original data may also be determined according to the different sources of the data. For example, according to the source of the data, the original data may be divided into domestic user data, overseas user data, or engineering and technical data. Different types of data have different corresponding formats, and different methods may be applied to generate corresponding uniformly formatted data.

[0121] 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 requirements for technical processing. Therefore, a unified format can be specified. In the preprocessing stage, the format of the original data can be converted into the specified format of the type through format conversion to obtain uniformly formatted data.

[0122] For example, for MQ data, MQ data of different formats can be parsed to analyze the content of messages encapsulated in different formats. For offline aggregated data and TOS data, different requests for calling these data from file systems or data systems in different formats can be converted into file call requests implemented through a unified API. For service calls, service call requests generated under different protocols can be converted into service call requests in a unified protocol.

[0123] The specific preprocessing methods for different types of data will be described in more detail below.

[0124] In block 3303, DES 1040 determines the satisfaction of the data exchange constraint from the uniformly formatted data. For example, the DES center 3065 in DES 1040, especially the DES center 3065 of the corresponding data type, can perform a check on whether the data exchange constraint is satisfied. After the uniformly formatted preprocessing, the DES center 3065 does not need to apply various different technologies to parse the original data, so that it is more convenient to use rules to perform data security and compliance checks.

[0125] In block 3304, if it is determined that the uniformly formatted data satisfies the data exchange constraints, the DES 1040 converts the uniformly formatted data into raw data. In the case where the data exchange constraints are satisfied, the data is allowed to be synchronized between the platforms. To ensure that the data is correctly synchronized, the DES 1040 further processes the intermediately generated uniformly formatted data (i.e., performs a post-processing phase) to convert the uniformly formatted data into raw data, which has an original format.

[0126] In block 3305, DES 1040 performs the exchange of original data between the first platform and the second platform, thereby achieving data exchange while satisfying security and compliance.

[0127] In certain embodiments, as briefly mentioned above, multiple data channels corresponding to different types of raw data can be created between different platforms, and different types of raw data will be transferred to corresponding data channels for processing. Each data channel may include a pre-processing component, a post-processing component, and a confirmation component about data exchange constraints that are suitable for processing the raw data of this type. Additionally or alternatively, each data channel may be registered with data exchange constraints that are to be applied to the raw data of this particular type. In this way, separation in terms of pre-processing of different types of data, confirmation of data exchange constraints, and post-processing can be achieved.

[0128] 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 the data exchange constraints for a specific type of data need to be updated, they can be executed in the corresponding data channel without affecting other data channels. In addition, according to business needs, if a new type of raw data is to be exchanged between the first platform and the second platform and the new type of data also needs to perform checks on data sovereignty protection, then a new data channel can be flexibly created between the first platform and the second platform to process the new type of raw data.

[0129] Figure 3EA flowchart showing an example data flow 3005 of various types of data processing implemented at the DES 1040 according to some embodiments of the present disclosure is shown. The data flow 3005 involves data flow of the control plane and data flow of the data plane.

[0130] On the control plane, the operation and maintenance personnel can configure one or more types of data channels in DES1040, and can update and maintain the channels. Figure 3E As shown, domestic operation and maintenance personnel can request to configure specific data types and channels for processing specific data types via DES entry 3062, and register data directory 3081 indicating specific data types and data definition 3082 similar to specific data to DES registration center 3066. Data definition 3082 can specify channel information for processing different types of data in DES 1040, and can include pre-processing solutions, post-processing solutions, etc. for corresponding types of data.

[0131] Similarly, the overseas operation and maintenance personnel may also request to configure a specific data type and a channel for processing the specific data type via the DES entry 3072. The overseas operation and maintenance personnel may also register a data directory 3084 indicating a specific data type and a data definition 3085 similar to the specific data to the DES registration center 3066. The data definition 3085 may specify channel information for processing different types of data in the DES 1040, and may include a pre-processing solution, a post-processing solution, etc. for the corresponding type of data.

[0132] On the data plane, different types of data will pass through their own channels in DES1040. Figure 3E As shown, for service call data, service call requests are exchanged between the client or server 3086 on the TTP IDC side and the client or server 3090 on the overseas IDC side. In order to make the service call request meet the data sovereignty protection requirements, the service call request is processed in the service call channel in DES1040.

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

[0134] In this example, it is assumed that the service call request is uniformly formatted to comply with a uniform protocol, namely, a request of the HTTP protocol. Therefore, after determining that the uniformly formatted service call request satisfies the data exchange constraint, the HTTP proxy 3088 can provide the uniformly formatted service call request to the client or server 3090 on the other side through the routing module 3089. Before being provided to the client or server 3090, the uniformly formatted service call request is converted back to a service call request that complies with the original protocol.

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

[0136] The original data 3091 of the MQ type is transmitted to the preprocessing module 3092. The preprocessing module 3092 processes the original data 3091 using the data preprocessing scheme specified in the data definition 3082 to obtain the uniformly formatted data 3093. The uniformly formatted data 3093 is extracted by the MQ transmitter 3094, for example, via a third-party software development kit (SDK). After checking the data exchange constraints, the SDK pushes the uniformly formatted data 3096 that meets the rules to the overseas IDC. The uniformly formatted data 3095 that does not meet the data exchange constraints is rejected. The routing module 3097 routes the uniformly formatted data 3096 that meets the rules to the corresponding destination, and the uniformly formatted data 3093 is converted back to the corresponding original data 3098 before being transmitted to the destination.

[0137] For offline aggregated data and TOS data, the original data will be processed in the HDFS channel and TOS channel in DES1040 respectively. Figure 3E An example of one channel is shown, but it is understood that the HDFS channel and the TOS channel may include the components shown. Figure 3E In the example, the HDFS channel or TOS channel may include at least a pre-processing module 3100 in the DES agent 3063, a file transmitter 3103 in the DES center 3065, and a routing module 3105 in the DES agent 3073.

[0138] Since the offline aggregate data type or TOS type data is stored in a file system or other storage system, the pre-processing module 3100 may initiate a request to the file transfer manager 3102 to call a file transfer API, so as to obtain the raw data 3099 for the offline aggregate data type or TOS type to be transmitted to the pre-processing module 3100. The pre-processing module 3100 may process the raw data 3099 using the data pre-processing scheme specified in the data definition 3082 to obtain uniformly formatted data 3101.

[0139] Similar to MQ type data processing, the unified formatted data 3101 is extracted by the file transmitter 3103, for example, via the SDK. After checking the data exchange constraints, the SDK pushes the unified formatted data 3104 that meets the rules to the overseas IDC. The unified formatted data that does not meet the data exchange constraints will be rejected and cannot be transmitted to the overseas IDC. The routing module 3105 routes the unified formatted data 3104 that meets the rules to the corresponding destination, and the unified formatted data 3094 is converted back to the corresponding original data 3106 before being transmitted to the destination.

[0140] It should be understood that Figure 3E Only the processing of outflow data from the TTP IDC to the overseas IDC in DES 1040 is shown. Data flow in the opposite direction can also be processed in DES 1040 through a similar process, and DES 1040 can also retain corresponding components to support corresponding processing, especially components in the DES adapter.

[0141] Some example implementations of different types of data in DES 1040 are discussed in detail below.

[0142] Sample implementation of data exchange for MQ

[0143] Figure 3F FIG. 300 shows a schematic block diagram of a data exchange architecture 3006 involving an MQ channel according to some embodiments of the present disclosure. The data exchange architecture 3006 may be implemented in DES 1040 to perform data security protection for MQ type data. Figure 3F In the example shown, data exchange from the TTP IDC to the overseas IDC is shown.

[0144] like Figure 3F As shown, the source database 3110 in the TTP IDC generates entities of MQ data to be transmitted. The MQ data may include messages such as change data or business customization events, and different messages may have different formats. The MQ data generated by the source database 3110 is placed in the source message queue 3112.

[0145] exist Figure 3F In the example of , in addition to the DES entry 3062, the DES adapter 3061 also includes a DES pre-adapter 3120. The DES pre-adapter 3120 can be implemented as a part of the DES agent 3063 to pre-process the MQ data from the TTP IDC to the overseas IDC direction. The DES pre-adapter 3120 can be configured to process the MQ data of different formats into unified formatted MQ data with a unified format, and provide the unified formatted MQ data to the MQ transmitter 3094 to perform a determination on whether the data exchange constraints are satisfied.

[0146] MQ data (or messages) can also include data generated by different protocols, each of which has a customized format and therefore requires different preprocessing. Figure 3F As shown, the pre-DES adapter 3120 may include a parser 3122, which is configured to parse different types of original MQ data to convert different types of original MQ data into unified formatted MQ data in a unified format. Figure 3F As shown, the pre-DES adapter 3120 may include a MySQL parser for parsing data generated through the MySQL protocol, such as change data capture (CDC) data; a Redis parser for parsing data generated through the Redis protocol, such as CDC data; a document parser for parsing data in a document database, especially CDC data; a graph parser for parsing data in a graph database, especially CDC data; an MQ parser for parsing different types of business event data sent through a message queue, etc. It can be understood that the parser 3122 is flexibly scalable, wherein more, fewer, or other parsers may be provided for parsing corresponding types of MQ data.

[0147] The uniformly formatted MQ data obtained after parsing can also be in the form of a message queue, and can be put into the uniformly formatted message queue 3124. In VPC2 of the TTP IDC, the MQ transmitter 3094 responsible for MQ data can extract the parsed uniformly formatted MQ data from the uniformly formatted message queue 3124 through the SDK for data security and compliance checks.

[0148] The unified formatted MQ data is rejected by the MQ transporter 3094 and recorded in the rejection log 3126. The unified formatted MQ data satisfying the data exchange constraint is pushed to the DES post-adapter 3130 in the DES adapter 3070 via the SDK.

[0149] The DES post-adapter 3130 can be implemented as a part of the DES agent 3073 to post-process the unified formatted MQ data from the TTP IDC to the overseas IDC to transmit the data to the destination. The unified formatted MQ data that meets the data exchange constraints is pushed to the DES post-adapter 3130 via the SDK.

[0150] The DES post-adapter 3130 may include a data replayer 3132 for performing post-processing on the uniformly formatted MQ data. Specifically, the DES post-adapter 3130 may be configured to convert the uniformly formatted MQ data into raw MQ data. Therefore, the DES post-adapter 3130 may include replayers corresponding to different types of MQ data for performing conversion from the uniform format to respective customized formats. Figure 3F As shown, the DES post-adapter 3130 may include a MySQL player for converting uniformly formatted MQ data into MQ data that complies with the MySQL protocol; a Redis player for converting uniformly formatted MQ data into MQ data that complies with the Redis protocol; a document player for converting uniformly formatted MQ data into raw data in a graphical form; an MQ player for converting uniformly formatted data into raw data that complies with the MQ protocol, and so on.

[0151] The converted original MQ data is put into the uniformly formatted message queue 3134 in the DES post-adapter 3130, and can be synchronized to the 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 DES 1040. The target database 3136 can obtain the desired MQ data from the target message queue 3135.

[0152] Figure 3F Only the components involved in data exchange from TTP IDC to overseas IDC are shown. Figure 3F In the example of FIG. 1 , data exchange from an overseas IDC to a TTP IDC is shown. DES 1040 may include similar components for processing data exchange in this direction. For example, DES adapter 3070 may include a DES front adapter having a function similar to that of DES front adapter 3120, and DES adapter 3061 may include a DES back adapter having a function similar to that of DES back adapter 3130. For the purpose of simplicity, the processing in this direction will not be expanded in detail.

[0153] Understandably, Figure 3FThe components for processing MQ data exchange in DES shown in FIG. are only examples. In other examples, different functional modules may also be subdivided, merged, etc. in other ways, depending on the needs, and may also include more, fewer or different functional modules.

[0154] Example implementation of data exchange for offline aggregated data

[0155] Figure 3G A schematic block diagram of a data exchange architecture 3500 involving an HDFS channel according to some embodiments of the present disclosure is shown. The data exchange architecture 3500 can be implemented in DES 1040 to perform data security protection for offline aggregated data. Figure 3G In the example of FIG. 35 , offline aggregate data exchange between HDFS 3502 on the TTP IDC side and HDFS 3504 on the overseas IDC side is shown. Some offline aggregate data in HDFS 3502 and HDFS 3504 may need to be synchronized with each other.

[0156] like Figure 3G As shown, in the data exchange architecture 3500, the data transfer detector 3510 on the TTP IDC side is responsible for detecting whether offline aggregated data that needs to be transferred to the HDFS 3504 on the other side is stored in the HDFS 3502. In the case of finding offline aggregated data to be transferred, the data transfer submitter 3520 can submit a request for data transfer to the file transmitter 3550. Before being submitted to the file transmitter, the data preprocessing module 3530 is configured to perform preprocessing on the data to process the offline aggregated data into uniformly formatted data.

[0157] In the file transmitter 3550, the data transmission server 3556 is configured to control the data transmission service based on the use of data exchange constraints. If the data transmission server 3556 determines that the pre-processed unified formatted data from the HDFS 3502 meets the data exchange constraints, then the transmission job 3558 can be called to transmit the unified formatted data to the overseas IDC through the transmission task 3562 under the transmission job 3558. In some embodiments, the transmission job 3558 can also optionally include a data verification task 3560, which can be configured to perform data verification as needed. The unified formatted data passes through the HDFS gateway 3564 and can be post-processed to obtain the original offline aggregated data and stored in HDFS3504.

[0158] Similarly, in the data exchange architecture 3500, the data transfer detector 3574 on the overseas IDC side is responsible for detecting whether the HDFS 3504 stores offline aggregated data that needs to be transferred to the HDFS 3502 on the TTP IDC side. When the offline aggregated data to be transferred is found, the data transfer submitter 3572 can submit a request for data transfer to the file transmitter 3550. Before being submitted to the file transmitter, the data preprocessing module 3570 is configured to perform preprocessing on the data to process the offline aggregated data into uniformly formatted data.

[0159] In the file transmitter 3550, if the data transmission server 3556 determines that the pre-processed uniformly formatted data from the HDFS 3504 meets the data exchange constraints, the transmission job 3554 can be called to transmit the uniformly formatted data to the TTP IDC through the transmission task 3552 under the transmission job 3554. After the uniformly formatted data is post-processed, the original offline aggregated data is obtained and stored in the HDFS 3502.

[0160] Understandably, Figure 3G The components for processing offline aggregate data exchange in DES shown in FIG. 1 are only examples. In other examples, different functional modules may be subdivided, merged, etc. in other ways depending on the needs, and may include more, fewer or different functional modules.

[0161] Example implementation of data exchange for object storage

[0162] In general, the TOS channel can determine whether the object file meets the data exchange constraints, and copy the object file from the source IDC (e.g., TTP IDC or offshore IDC) to the destination IDC (e.g., offshore IDC or TTP IDC) if the constraints are met. The object file is, for example, a video, audio, image, document, or other media file.

[0163] In some embodiments, an object file may be copied from an object storage through an API, a determination of a data exchange constraint may be performed, and the object file may be pushed to the object storage at the destination end using the API. In the data exchange of the object file, the satisfaction of the data exchange constraint may be determined by a copy request corresponding to the object file. Figures 3H to 3J To describe the details of the TOS channel.

[0164] Figure 3HA schematic diagram of a target object storage (TOS) channel 3600 of data replication from a TTP IDC to an offshore IDC according to some embodiments of the present disclosure is shown. In this example, the data to be exchanged is an object file, which is stored in an object storage 3606 in the TTP IDC and is expected to be exchanged to an object storage 3607 of the offshore IDC.

[0165] exist Figure 3H In the figure, the API 3605 in the TTP IDC is configured to push the replication request to the work node 3605, and receive the replication result exchanged from the overseas IDC on the other side from the work node 3605. As shown in the figure, when the data flow starts 3601, the replication request for the object file to be exchanged is transmitted to the work node 3605 by the API (also known as the DES-TOS API) 3602. The replication request can indicate information related to the object file to be exchanged, such as the format of the object file (video, audio, text, etc.), the identifier of the object file, and other file metadata. The replication request has a unified format.

[0166] The worker node 3605 in the trusted region VPC2 is configured to perform a determination on the data exchange constraint in response to a replication request for an object file. Specifically, the worker node 3605 can determine whether the object file to be exchanged satisfies the data exchange constraint from the uniformly formatted replication request.

[0167] In some embodiments, at the TTP IDC side, the registration of data exchange constraints can be initiated in the initial stage or when needed later. When the constraint registration starts 3622, the data exchange constraints to be used can be registered with the DES registration center 3624 in the TTP trusted zone through the DES entry 3620 in the TTP IDC. The registration of data exchange constraints can be implemented by calling API 3602. The working node 3605 can access the data exchange constraints currently to be used through the DES registration center 3624.

[0168] In some embodiments, the data exchange constraints may indicate a white list of object files allowed to be exchanged or a black list of object files not allowed to be exchanged. In each list, the file objects allowed or not allowed to be exchanged may be identified according to the format, identifier, etc. of the object file.

[0169] After executing the data exchange constraint, the worker node 3605 allows the execution of the replication request that satisfies the data exchange constraint. If the replication request is allowed to be executed, the worker node 3605 accesses the object storage 3606 in the TTPIDC to replicate the object file to the object storage 3607 in the offshore IDC. For illegal requests (i.e., replication requests that do not satisfy the data exchange constraint), they will be rejected and thus cannot be executed. The worker node 3605 can write the replicated object file to the object storage 3607 via the API 3610 in the offshore IDC. In this way, the data flow ends 3611.

[0170] Fig. 3I A schematic diagram of a TOS channel 3650 for copying data from an offshore IDC to a TTP IDC according to some embodiments of the present disclosure is shown. In this example, the object file to be exchanged is stored in the object storage 3607 in the offshore TTP IDC and is expected to be exchanged to the object storage 3606 of the TTP IDC.

[0171] exist Fig. 3I In the example, the API 3610 in the overseas IDC is configured to push the replication request to the working node 3605, and receive the replication result exchanged from the TTP IDC on the other side from the working node 3605. Fig. 3I As shown, when the data flow starts 3651, a replication request for the object file to be exchanged is transmitted by API 3610 to worker node 3605. The replication request may indicate information related to the object file to be exchanged, such as the format of the object file (video, audio, text, etc.), the identifier of the object file, and other file metadata. The replication request has a unified format. Worker node 3605 in the trusted region VPC2 can determine whether the object file to be exchanged meets the data exchange constraint from the uniformly formatted replication request.

[0172] In some embodiments, at the overseas IDC side, the registration of data exchange constraints can be initiated in the initial stage or when needed later. When the constraint registration starts 3632, the data exchange constraints to be used can be registered with the DES registration center 3624 in the TTP trusted zone through the DES entry 3630 in the overseas IDC. The registration of data exchange constraints can be achieved by calling API 3610. The working node 3605 can access the data exchange constraints currently to be used through the DES registration center 3624.

[0173] After executing the data exchange constraint, the worker node 3605 allows the execution of the replication request that satisfies the data exchange constraint. If the replication request is allowed to be executed, the worker node 3605 accesses the object storage 3607 in the offshore IDC to replicate the object file to the object storage 3606 in the TTP IDC. For illegal requests (i.e., replication requests that do not satisfy the data exchange constraint), they will be rejected and thus cannot be executed. The worker node 3605 can write the replicated object file to the object storage 3606 via the API 3602 in the TTP IDC. In this way, the data flow ends 3652.

[0174] Understandably, Figure 3H and Fig. 3I The components for processing TOS data exchange in DES shown in FIG. are only examples. In other examples, depending on the needs, different functional modules can also be subdivided, merged, etc. in other ways, and can also include more, fewer or different functional modules.

[0175] Figure 3J A message sequence 3012 in a TOS channel is shown according to some embodiments of the present disclosure. Figure 3J The message sequence 3012 in involves TTP 3701, operation and maintenance personnel 3702, platform staff 3703, DES entry 3704, API 3705, working node 3605 and object storage 3708.

[0176] Depending on the direction of data exchange, Figure 3J The DES entry 3704, API 3705 and object storage 3708 in can be Figure 3H and Fig. 3I For example, in Figure 3H As shown, in the TOS channel 3600 copied from the TTP IDC to the offshore IDC, the DES entry 3704 includes Figure 3H DES inlet 3620 shown, API 3705 includes Figure 3H API 3602, object storage 3708 includes Figure 3H In the TOS channel 3650 copied from the offshore IDC to the TTP IDC, the DES entry 3704 includes Fig. 3I DES entry 3630 shown, API 3705 includes Fig. 3I API 3610, object storage 3708 includes Fig. 3I Object storage 3607 in.

[0177] In message sequence 3012, operator 3702 registers 3711 data exchange constraints with DES entry 3704, which can constrain the replication of object files between object stores 3606 and 3607 of different IDCs. After completing the registration, DES entry 3704 can send 3714 a response to the operator. DES entry 3704 registers 3712 container information about data exchange constraints with API 3705, and after the registration is completed, API 3705 can send 3713 a response to DES entry 3704. Rules registered via DES entry 3704 can be cached 3715 to API 3705, and can also be cached 3716 to working node 3605.

[0178] The platform worker 3703 may initiate 3717 a copy request for an object file to the API 3705. The API 3705 may perform authentication 3718. The worker node 3605 may pull 3719 the copy request from the API 3705 and perform 3720 a determination of data exchange constraints on the object file to be copied. If copying of the object file is allowed, the worker node 3605 performs 3721 a file copy to copy the corresponding object file from the object storage 3706. Regardless of the result of not satisfying the data exchange determination, the worker node 3605 returns 3722 feedback to the API 3705. In the case where copying of the object file is allowed, the feedback includes the copied object file. In the case where copying of the object file is not allowed, the feedback is used to indicate that the copy request is rejected.

[0179] In some embodiments, the platform staff 3703 may call back 3723 the API 3705, and the API 3705 may return 3724 the replication request ID to the platform staff 3703. In some embodiments, the TTP 3701 may view 3725 the historical object file replication status through the DES entry 3704 to confirm whether the exchange of object files in the past period of time meets the requirements of the data exchange constraint. The DES entry 3704 may return 3726 the result to be viewed.

[0180] Example implementation of data exchange protection for service calls

[0181] Figure 3K FIG. 3 is a schematic block diagram of a data exchange architecture 3800 involving a service call channel according to some embodiments of the present disclosure. The data exchange architecture 3800 may be implemented in the DES 1040 to perform data security protection for service call type data. Figure 3LIn the example of FIG. 3 , service call data exchange between the target platform service 3802 on the TTP IDC side and the overseas (non-TTP) platform service 3804 on the overseas IDC side is shown. For example, the service on the target platform service 3802 may need to call the service on the overseas platform service 3804, and vice versa, the service on the overseas platform service 3804 may also need to call the service on the target platform service 3802.

[0182] Different service platforms may apply a variety of different service call protocols, such as HTTP or Thrift RPC. In some embodiments of the present disclosure, it is desirable to process uniformly formatted data, such as HTTP protocol data, when executing data sovereignty protection in a VPC trusted zone.

[0183] exist Figure 3K In the control plane, the non-TTP control plane is used for channel registration, channel architecture update, and detection; the TTP / TTP control plane is used for channel request approval, channel prohibition, channel detection, etc. On the data plane, the HTTP load balancer 3810 is an L7 balancing product from TTPCloud, which is a key component to ensure that all DES-RPC channel traffic passes through the VPC trusted zone. The HTTP channel is a channel in the DES-RPC channel that supports the HTTP protocol. The Thrift RPC channel is a channel in the DES-RPC channel that supports the ThriftRPC protocol. The Thrift RPC channel will be wrapped in the HTTP channel before being sent to the TTP's HTTP load balancer.

[0184] During the channel registration phase, a DES-RPC channel is declared using channel information and data definitions. Channel information may include the type of channel, such as Thrift RPC or HTTP. Channel information may also include an RPC call tuple. The call tuple may include src dc, src service, dst dc, dst service, rpc method / http path.

[0185] The data definition may depend on the direction of data flow. For data flow from non-TTP to TTP, responses will be declared using Thrift IDL with compliance annotations. For data flow from TTP to non-TTP, requests will be declared using Thrift IDL with compliance annotations. In some embodiments, the DES-RPC channel is available only when it is registered with compliance.

[0186] Understandably, Figure 3KThe components for processing service call data exchange in DES shown in FIG. are only examples. In other examples, different functional modules may also be subdivided, merged, etc. in other ways, depending on needs, and may also include more, fewer or different functional modules.

[0187] Figure 3L According to some embodiments of the present disclosure, Figure 3K An example of data exchange from non-TTP to TTP in the service call channel is shown in Figure 1. Figure 3L As shown, the call initiated by service A 3901 in the overseas region will be forwarded by HTTP proxy 3902 or Thrift proxy 3903 to HTTP load balancer 3905 of TTP. Service A 3901 can be Figure 3M An example of an offshore platform service is shown. For HTTP requests, the call will be forwarded by HTTP proxy 3902 to HTTP load balancer 3905. For Thrift requests, the call will be forwarded by Thrift proxy 3903 to HTTP load balancer 3905.

[0188] For the corresponding service proxies in the overseas IDC, such as HTTP proxy 3902 or Thrift proxy 3903, it is recommended to implement service discovery to the HTTP load balancer 3905 in the VPC trusted area through DNS. For the service discovery of the proxy that forwards requests to the TTP IDC area, it is recommended to use customized / general service discovery.

[0189] HTTP load balancer 3905 may include compliance plug-in 3906. For illegal requests, compliance plug-in 3906 will return an error. For Thrift rpc calls, the request will be HTTP wrapped to generate a new HTTP request. The body of the new HTTP request is a Thrift binary file.

[0190] In the VPC trusted zone, the HTTP load balancer 3905 of the TTP forwards the request to the HTTP proxy 3907 and Thrift proxy 3908 of the TTP, and then the HTTP proxy 3907 and Thrift proxy 3908 forward the request to the target services, service B 3908 and service C 3910, respectively. For Thrift rpc calls, the Thrift proxy 3908 recovers the original Thrift request from the generated new HTTP request before sending the request.

[0191] TTP's HTTP proxy 3907 and Thrift proxy 3908 will check the response before sending it to TTP's HTTP load balancer 3905. For responses that fail the compliance check, an error will be returned. In addition, for Thriftrpc calls, the Thrift response will be HTTP wrapped to generate a new HTTP response. The body of the new HTTP response is a Thrift binary file.

[0192] Figure 3M According to some embodiments of the present disclosure, Figure 3K An example of data exchange from TTP to non-TTP in the service call channel is shown in Figure 1. Figure 3M As shown, the call initiated by the service A 3951 of the TTP will be forwarded by the HTTP proxy 3952 and Thrift proxy 3953 of the TTP to the HTTP load balancer 3955 of the TTP. For HTTP requests, the call will be forwarded by the HTTP proxy 3952 to the HTTP load balancer 3955. For Thrift requests, the call will be forwarded by the Thrift proxy 3953 to the HTTP load balancer 3955.

[0193] For illegal requests, an error will be returned. For responses that fail the compliance check, an error will be returned. For Thrift rpc calls, the request will be HTTP wrapped to generate a new HTTP request. The body of the new HTTP request is the Thrift binary file.

[0194] The HTTP load balancer 3955 of the TTP forwards the request to the HTTP proxy 3957 and the Thrift proxy 3958 of the non-TTP (i.e., the overseas region). Then the HTTP proxy 3957 and the Thrift proxy 3958 forward the request to the service B 3959 and the service C 3960 of the overseas region.

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

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

[0197] Safe sandbox system

[0198] Client applications need to communicate with servers to transmit data. The network traffic of client applications can transmit a large amount of user data. Therefore, a method is needed to manage the network traffic of client applications so that user data will not be transmitted to unauthorized servers via the network traffic of client applications. For example, in the scenario of data sovereignty protection, this method can prevent user data from being transmitted to servers in non-data sovereign countries.

[0199] However, the types of network traffic of client applications are very rich. Client applications may include mobile applications and computer (PC) applications. The network traffic of client applications may include native type network traffic and web view type network traffic, etc. In addition, the network traffic of client applications is not all under the management and control of the owner of the application. For example, the network traffic of client applications may include network traffic from third-party advertisers. Therefore, it is very difficult to manage various types of network traffic of client applications.

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

[0201] In this way, by analyzing network traffic at different layers of network transmission based on the type of network traffic and limiting the transmission of network traffic that does not meet data exchange constraints, user data can be effectively prevented from being transmitted to unauthorized servers via various types of network traffic.

[0202] The embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. The following will take a mobile application as an example to exemplarily illustrate the solution of the present disclosure.

[0203] Figure 4A A flowchart of an example method 4100 for managing network traffic of a mobile application according to some embodiments of the present disclosure is shown. The method 4100 may be, for example, Figure 1 The mobile terminal application may be a target application 1080 on the mobile terminal.

[0204] At block 4102, based on the determination of the target user, the network transmission of the target user's user data from the target application 1080 to the server is detected. In other words, if it is determined that the current user is the target user, the security sandbox system 1090 may detect the network transmission of the target user's user data.

[0205] In some implementations, network traffic can be routed to the security sandbox system 1090 based on the determination of the target user so that the security sandbox system 1090 can detect and analyze network traffic corresponding to network transmission of user data. The security sandbox system 1090 can analyze the network requests of the target application 1080 and restrict network requests that do not meet the conditions based on the data exchange constraints.

[0206] Data exchange constraints may include exchange constraints related to data sovereignty, such as data sovereignty protection rules. Data sovereignty protection rules may be determined according to the regulations of each country or region. Data sovereignty protection rules may also be determined by the operator of the application (for example, related to the user data usage agreement).

[0207] Data sovereignty protection rules can be set based on specific scenarios. For example, data sovereignty protection rules can stipulate that user data of a data sovereign country is not allowed to be transferred to any server outside the data sovereign country. In other implementations, data sovereignty protection rules can stipulate that user data of a data sovereign country's privacy is not allowed to be transferred to any unregistered server. The scope of this disclosure is not limited to this.

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

[0209] The target user refers to a user whose user data transmission needs to be detected and managed. The target user may be a user with the nationality of a data sovereign country. Alternatively or additionally, the target user may also be a user determined according to specific rules for data sovereignty protection. For example, the target user may be a user with the nationality of a data sovereign country and currently located in the data sovereign country geographically.

[0210] 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, application setting information, etc.

[0211] In some implementations, the target user may be determined based on a combination of multiple information. Multiple information may have different priorities. For example, SIM information and network service provider information may have a higher priority than IP address, system setting information, application setting information, etc.

[0212] In some implementations, the determination of the target user may be based on the determination of the region where the target user is located. The region where the target user is located may be determined using the above user information or device information, thereby determining the target user. For example, the region where the current user is located may be determined using the region setting in the system settings of a smartphone, and thereby determining whether the current user is the target user. For another example, the region where the target user is located may be determined using the country code of the SIM card, and thereby determining the target user.

[0213] In some implementations, the target user may be determined when the application is first launched. In other words, whether the current user is the target user may be determined when the application 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.

[0214] In some implementations, the determination result may be stored locally or in a server. The determination result may be stored after the user is determined as a target user for the first time and the stored determination result may be set to be used within a threshold time period. In this way, when the user logs in again, it is not necessary to determine the user again.

[0215] At block 4104, the network traffic is analyzed at different layers of the network transmission based on the type of network traffic to which the network transmission corresponds.

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

[0217] The network traffic of the third-party SDK type is generated and processed by the third-party SDK. Generally, the third-party SDK can be connected to the target application 1080 to implement the login or sharing function. The network traffic of the third-party SDK type is generated and processed by these third-party SDKs. It should be understood that the network traffic of the third-party SDK type is usually not completely controlled by the owner of the application.

[0218] Web page view type network traffic may include network traffic controlled by the owner of the application, for example, network traffic generated by the built-in browser of the application by calling the code of the native application. Web page view type network traffic may also include network traffic controlled by a third party, for example, network traffic generated and controlled by a third-party advertiser.

[0219] Based on the type of network traffic, the security sandbox system 1090 can adopt corresponding analysis strategies to better manage the network transmission of user data in the application.

[0220] At block 4106, based on the analysis indicating that the network traffic satisfies the data exchange constraints corresponding to the target user, the network traffic is sent to the server defined by the data exchange constraints. Different data exchange constraints may be set for different target users. For example, for target users with a higher sensitivity level, stricter data exchange constraints may be set. The data exchange constraints may define which user data may 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 of the target user or the corresponding device information.

[0221] In some implementations, the security sandbox system 1090 may include multiple submodules for different types of network traffic. For example, a submodule for managing native type network traffic, a submodule for managing web view type network traffic, and a submodule for managing third-party SDK type network traffic. These submodules can analyze the corresponding type of network traffic, and limit or intercept network traffic that does not meet the data exchange constraints. FIG. 4B to FIG. 4E To describe in detail the details of managing different types of network traffic.

[0222] Figure 4B A schematic diagram of an analysis and restriction process 4200 for native type network traffic according to some embodiments of the present disclosure is shown. Figure 4B A submodule 4210 for analyzing and limiting native type network traffic is shown. The submodule 4210 may be a part of the security sandbox system 1090 or a specific implementation of the security sandbox system 1090.

[0223] like Figure 4B As shown, the business logic layer 4220 sends the network request to the underlying OS 4230. The business logic layer 4220 can be Figure 1 A specific implementation of the application business logic 1100 in terms of network transmission. Submodule 4210 can be used as an interceptor to analyze and limit network requests at the network layer. Submodule 4210 can limit network requests by analyzing endpoints, parameters of network requests, or schemas. For example, it can be determined whether to limit the network request based on whether the schema has been registered. Alternatively or additionally, it can be determined whether to limit the network request based on whether the fields requested in the network request involve sensitive information.

[0224] In some implementations, submodule 4210 may include an interceptor for Android and an interceptor for IOS. Additionally, submodule 4210 may also include an interceptor for C++. In this way, by analyzing and limiting network requests at the network layer, it is possible to better determine whether the network request should be limited based on the protocol information of the network request.

[0225] Figure 4C A schematic diagram of a process 4300 for analyzing and limiting network traffic of a web page view type according to some embodiments of the present disclosure is shown. Figure 4C A submodule 4310 for analyzing and limiting network traffic of a web page view type is shown. The submodule 4310 may be a part of the security sandbox system 1090 or a specific implementation of the security sandbox system 1090.

[0226] The submodule 4310 may transfer the web view type network traffic to the native network interface so that the web view type network traffic may be analyzed and restricted by the submodule 4210 for the native type network traffic. In some implementations, the submodule 4310 may utilize a hook mechanism of JavaScript (JS) to transfer the web view type network traffic to the native network interface.

[0227] like Figure 4C As shown, submodule 4310 may include a launcher 4311, a navigation URL interceptor 4312, and an internal request interceptor 4313. Submodule 4310 may communicate with a browser 4320 built into the application so that network traffic of a web view type may be managed and detected by submodule 4310. Launcher 4311 may perform JS injection when the browser 4320 built into the application is opened (created) so that network traffic of a web view type may be transferred to a native network interface using a hook mechanism. Network traffic transferred to a native network interface may be taken over by a native network module.

[0228] In some implementations, the following method can be used to utilize JS hook technology to transfer network traffic.

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

[0230] The internal request interceptor 4313 can transfer the 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 the native type of network traffic, and will not be repeated here.

[0231] In some implementations, submodule 4310 may adopt different analysis and restriction strategies for web page view type network traffic controlled by the owner of the application and web page view type network traffic controlled by a third party. For example, for web page view type network traffic controlled by a third party, only navigation URL interceptor 4312 may be used to determine whether the URL of the main page is registered to analyze the relevant network traffic without further analyzing the static resources and dynamic resources of the main page.

[0232] Figure 4D A schematic diagram of an analysis and restriction process 4400 for third-party SDK type network traffic according to some embodiments of the present disclosure is shown. Figure 4D A submodule 4410 for analyzing and limiting the network traffic of a third-party SDK type is shown. The submodule 4410 may be a part of the security sandbox system 1090 or a specific implementation of the security sandbox system 1090.

[0233] Submodule 4410 can analyze and limit the network traffic of third-party SDK types at the application program interface (API) layer. Submodule 4410 can limit the network traffic of third-party SDK types by analyzing whether the data requested by the API of the third-party SDK meets the data exchange constraints at the API layer.

[0234] In some implementations, the submodule 4410 may wrap the API of the third-party SDK that requests user data, and add judgment logic based on data exchange constraints in the wrapping. In other words, the submodule 4410 may determine the wrapping API by adding judgment logic to the API of the third-party SDK. In this way, the business logic layer 4220 does not directly call the API of the third-party SDK, but calls the wrapping API with the judgment logic added.

[0235] like Figure 4DAs shown, submodule 4410 may include a wrapping module for each third-party SDK. For example, wrapping module 4412 for SDK 4411, wrapping module 4414 for SDK 4413, and wrapping module 4416 for SDK 4415. The wrapping module (e.g., wrapping module 4412) may wrap the API in the corresponding SDK (e.g., SDK 4411) to generate the corresponding wrapped API. In some implementations, submodule 4410 may dynamically add a wrapping module to wrap the API of the third-party SDK.

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

[0237] The judgment logic can determine whether the API of the wrapped third-party SDK can be called based on the data exchange constraints. In some implementations, the judgment logic can analyze whether the API of the third-party SDK can be called based on the name of the SDK, the name of the API, the name of the API parameter, etc. If the judgment result is yes, the API of the third-party SDK can be called and return a value to the business layer. If the judgment result is no, the API of the third-party SDK is not called, that is, the network traffic related to the API is restricted. It should be understood that the judgment logic can vary based on the specific scenario. For example, the judgment logic can be set to not allow the user's privacy data to be passed to the third-party SDK.

[0238] In this way, by analyzing and restricting 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.

[0239] Figure 4E FIG. 1 shows a module diagram of a security sandbox system 1090 according to some embodiments of the present disclosure. Figure 4E As shown, the security sandbox system 1090 includes a startup module 4520. The startup module 4520 is configured to start the detection of the network transmission of the user data of the target user from the client application to the server based on the determination of the target user. The startup module 4520 can activate the management module to detect, manage, analyze and limit the network traffic corresponding to the network transmission of the user data.

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

[0241] In some implementations, the management module may include a submodule (also referred to as a first management module) 4210, a submodule (also referred to as a second management module) 4310, and a submodule (also referred to as a third management module) 4410. The submodules 4210, 4310, and 4410 may analyze and limit network traffic of client applications.

[0242] In some implementations, the submodule 4210 is configured to analyze the network traffic at a network layer based on the type of the network traffic being a native type of network traffic.

[0243] In some implementations, submodule 4310 is configured to transfer the web view type network traffic to the network interface of the client application to be managed by the native network module of the client application based on the type of the network traffic being web view type network traffic; and analyze the transferred network traffic at the network layer.

[0244] In some implementations, transferring the web view type of network traffic to the network interface of the mobile application includes: utilizing a JavaScript hook mechanism to transfer the web view type of network traffic.

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

[0246] In some implementations, analyzing the network traffic at the API layer includes: determining a wrapping API by adding a judgment logic based on the data exchange constraint to an API of a third-party SDK; and calling the wrapping API to analyze the network traffic using the judgment logic.

[0247] In some implementations, the startup module 4520 may activate submodules 4210, 4310, and 4410 based on the determination of the target user. For example, the startup module 4520 may determine whether the current user is the target user when the user registers. If the determination result is yes, the startup module 4520 may activate submodules 4210, 4310, and 4410. For another example, the startup module 4520 may obtain the determination result of the user from the local or server when the user logs in, and determine whether to activate submodules 4210, 4310, and 4410 based on the determination result.

[0248] The security sandbox system 1090 may further include a sampling module 4510 for sampling network traffic. In some implementations, the sampling module 4510 may send a sampling signal to the start module 4520 to trigger the start module 4520. The sampling signal may indicate a sampling rate for sampling network traffic.

[0249] 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. Using the sampling module 4510, only a portion of the network traffic can be analyzed, thereby reducing overhead and maintaining application stability.

[0250] It should be understood that the security sandbox system 1090 may also include other modules, or may only include Figure 4E For example, when the target application 1080 is only a native application of the mobile terminal, the security sandbox system 1090 may not include the submodule 4310 for the network traffic of the web view type. The scope of the present disclosure is not limited to this.

[0251] In some implementations, network traffic can also be analyzed and restricted at the socket layer based on the type of network traffic. For example, third-party SDK type network traffic can be transferred 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 view type network traffic can also be analyzed and restricted at the Scoket layer.

[0252] In some implementations, a local server as a proxy may also be established on the target application 1080. By forwarding the network request of the target application 1080 to the local server, and by analyzing and limiting the network traffic at the local server, the network request forwarded by the local server to the external server may be managed. In this way, different types of network traffic may be analyzed and limited in consideration of protocol information, thereby better managing the network traffic of the application from being transmitted to an unauthorized external server.

[0253] References FIG. 4B to FIG. 4E The principles and details of the analysis and restriction of different types of network traffic are described in detail. It should be understood that the above restriction rules, judgment logic and data exchange constraints are only exemplary and do not limit the scope of the present disclosure. For example, different data sovereignty protection rules can be set according to the legal and regulatory requirements of different countries. In addition, depending on the definition of the layers of the computer network, the network traffic can be analyzed and restricted at layers close to or similar to the above layers.

[0254] In addition, in the above description, the security sandbox system 1090 can directly analyze and limit the network traffic in the target application 1080. In other words, only the network traffic that is not restricted by the security sandbox system 1090 can continue to be transmitted. Alternatively or additionally, the security sandbox system 1090 may not directly restrict the network traffic, but only provide an analysis report. In this case, a copy of the network request can be sent to the security sandbox system 1090 while the network request is normally transmitted. The security sandbox system 1090 can analyze the copy of the network request and provide an analysis report.

[0255] In some implementations, for multiple data sovereign countries, multiple security sandbox systems 1090 may be set up accordingly to process each data sovereign country separately. For example, based on the determination of the region where the target user is located, the corresponding security sandbox system may be started to analyze and restrict network traffic so that the network transmission of user data in the application complies with the data sovereignty protection rules of the corresponding country.

[0256] Recommendation Management Subsystem

[0257] As discussed above, the target application may, for example, provide users with various content recommendations through a recommendation mechanism, such as multimedia content recommendations, user recommendations, product recommendations, etc. In such applications, the fairness of recommendation strategies has become a key point of management in many regions. For example, some applications may use a recommendation mechanism to guide users to pay attention to specific content that is irrelevant to user habits, and such a recommendation mechanism may be non-compliant.

[0258] On the other hand, common recommendation algorithms often rely on machine learning models for implementation, and code-level verification such as that performed by the secure computing subsystem 1060 may not be able to effectively detect the fairness of the recommendation algorithm. On the other hand, the training and updating of recommendation models are often closely related to actual user data, and people do not want to expose user privacy data during the inspection process, as this may lead to data compliance risks.

[0259] The embodiments of the present disclosure further propose a solution for managing recommendation strategies. Figure 5 A flow chart of a process 500 for managing a recommendation strategy is shown. The process 500 may be performed by the recommendation management subsystem 1050, for example.

[0260] like Figure 5 As shown, in box 502, the recommendation management subsystem 1050 obtains a set of object features associated with a set of objects in a target application, wherein the set of object features is converted based on the attributes of the set of objects, and the set of object features does not directly express the attributes of the set of objects.

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

[0262] In some embodiments, the set of object features may be obtained by, for example, converting the set of object features by a feature extraction model based on the attributes of the set of objects. In this way, the management party or other third party of the recommendation strategy cannot determine the original attribute information of the object based on the object features. Thus, the security of the data in the target application can be guaranteed.

[0263] At block 504 , the recommendation management subsystem 1050 determines a first object feature and a second object feature from a set of object features, wherein a first difference between the first object feature and the second object feature is less than a first threshold.

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

[0265] In block 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 the recommendation strategy in the target application.

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

[0267] In some embodiments, in order to ensure the security of the recommendation strategy, the recommendation management subsystem 1050 may send the selected first object feature and the second object feature to a remotely executed recommendation model via an API provided by the target application to determine the first recommendation result and the second recommendation result. Exemplarily, the recommendation model may be executed by the maintainer of the target application.

[0268] In some embodiments, the process of generating the first recommendation result and the second recommendation result will not affect the recommendation model actually deployed in the target application.

[0269] In some embodiments, the first recommendation result and the second recommendation result may be vector representations output by the recommendation model. Thus, the recommendation management subsystem 1050 cannot directly interpret the semantics of the first recommendation result and the second recommendation result, thereby further improving the security of the data in the target application.

[0270] At block 508 , the recommendation management subsystem 1050 evaluates a recommendation strategy based on the first recommendation result and the second recommendation result.

[0271] 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 strategy based on a comparison between the second difference and a second threshold.

[0272] Specifically, for a reasonable recommendation strategy, for two similar objects, the recommendation results should be similar. Therefore, if the recommendation management subsystem 1050 determines that the second difference exceeds the second threshold, it can be determined that the recommendation strategy has poor fairness.

[0273] Alternatively, the recommendation management subsystem 1050 may also determine the fairness of the recommendation strategy based on the proportion of object feature pairs whose second difference exceeds the second threshold. For example, the recommendation management subsystem 1050 may randomly sample multiple groups of object feature pairs, and if the proportion of object feature pairs whose second difference exceeds the second threshold exceeds the threshold proportion, it may be determined that the recommendation strategy has poor fairness.

[0274] In some embodiments, the recommendation management subsystem 1050 may also determine the fairness of the recommendation strategy based on the correlation between the object features used to input into the recommendation model and the historical recommendation results. Specifically, the recommendation management subsystem 1050 may also obtain a third object feature and the historical recommendation results for the third object feature from the target application. Further, the recommendation management subsystem 1050 determines the fairness of the recommendation strategy based on the correlation between the third object feature and the historical recommendation results. For example, the recommendation management subsystem 1050 may determine whether the object feature matches the category information of the historical recommendation results.

[0275] 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 correlation 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 strategy has poor fairness.

[0276] In some embodiments, as mentioned above, the source code associated with the recommended policy may also be checked by the secure computing subsystem 1060. Specifically, the secure computing subsystem 1060 may obtain the source code corresponding to the recommended policy, and evaluate the recommended policy based on the source code or the intermediate code corresponding to the source code.

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

[0278] Example devices and equipment

[0279] The embodiments of the present disclosure also provide corresponding devices for implementing the above methods or processes. Figure 6 A schematic structural block diagram of an apparatus 600 for managing network traffic of a client application according to some embodiments of the present disclosure is shown.

[0280] like Figure 6 As shown, the device 600 includes: a detection unit 610, configured to detect the network transmission of user data of the target user from the client application to the server based on the determination of the target user; an analysis unit 620, configured to analyze the network traffic at different layers of the network transmission based on the type of network traffic corresponding to the network transmission; and a sending unit 630, configured to send the network traffic to the server defined by the data exchange constraints based on the analysis indicating that the network traffic satisfies the data exchange constraints corresponding to the target user.

[0281] Figure 7 A schematic block diagram of an example device 700 that can be used to implement an embodiment of the present disclosure is shown. For example, the system 100 and / or system 400 according to an embodiment of the present disclosure can be implemented by the device 700. As shown, the device 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 702 or loaded from a storage unit 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the device 700 can also be stored. The CPU 701, ROM 702, and RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0282] A number of components in the device 700 are connected to the I / O interface 705, including: an input unit 706, such as a keyboard, a mouse, etc.; an output unit 707, such as various types of displays, speakers, etc.; a storage unit 708, such as a disk, an optical disk, etc.; and a communication unit 709, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 709 allows the device 700 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

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

[0284] The present disclosure may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present disclosure.

[0285] Computer readable storage medium can be a tangible device that can hold and store instructions used by an instruction execution device. Computer readable storage medium can 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 thereof. More specific examples (non-exhaustive list) of computer readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, for example, a punch card or a convex structure in a groove on which instructions are stored, and any suitable combination thereof. The computer readable storage medium used here is not interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (for example, a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

[0286] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or 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 can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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 for storage in the computer-readable storage medium in each computing / processing device.

[0287] The computer program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's 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., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be customized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0288] Various aspects of the present disclosure are described herein with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0289] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0290] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0291] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of the module, program segment or instruction includes one or more executable instructions for realizing the specified logical function. In some alternative implementations, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

[0292] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for managing network traffic of a client application, comprising: Based on the determination of the target user, detecting network transmission of user data of the target user from the client application to the server; Analyzing the network traffic at different layers of the network transmission based on the type of network traffic corresponding to the network transmission; as well as sending the network traffic to a server defined by the data exchange constraints based on the analysis indicating that the network traffic satisfies the data exchange constraints corresponding to the target user, Analyzing the network traffic at different layers of the network transmission includes: Based on the type of the network traffic being a third-party SDK type of network traffic, analyzing the network traffic at an application programming interface (API) layer, Analyzing the network traffic at the API layer includes: Determine the package API by adding judgment logic based on the data exchange constraint to the API of the third-party SDK; and The wrapping API is called to analyze the network traffic using the decision logic.

2. The method according to claim 1, wherein the determination of the target user is based on at least one of the following: User information of the target user; and The device information corresponding to the target user.

3. The method according to claim 2, wherein: The user information includes: user account information, personal information, and / or registration information; and The device information includes: Subscriber Identity Module SIM information, IP address, network service provider information, device system setting information, and / or application setting information.

4. The method according to claim 2 or 3, further comprising: Based on the user information or corresponding device information of the target user, a data exchange constraint corresponding to the target user is determined.

5. The method according to claim 1, wherein the type of network traffic comprises at least one of the following: Native-type network traffic associated with native apps; Web view type network traffic associated with the app's built-in browser; and Network traffic of the third-party SDK type associated with a third-party software development kit (SDK).

6. The method of claim 1, wherein analyzing the network traffic at different layers of the network transmission comprises: Based on the fact that the type of the network traffic is native type of network traffic, the network traffic is analyzed at the network layer.

7. The method of claim 1, wherein analyzing the network traffic at different layers of the network transmission comprises: Based on the type of the network traffic being web view type network traffic, transferring the web view type network traffic to a network interface of the client application to be managed by a native network module of the client application; as well as Analyze the diverted network traffic at the network layer.

8. The method of claim 7, wherein diverting the web view type of network traffic to the network interface of the client application comprises: A JavaScript hook mechanism is utilized to divert network traffic of the web view type.

9. A device for managing network traffic of a client application, comprising: A starting module, configured to start detection of network transmission of user data of the target user from the client application to the server based on the determination of the target user; Management module, configured as: In response to being activated by the startup module, analyzing the network traffic at different layers of the network transmission based on the type of network traffic corresponding to the network transmission; as well as sending the network traffic to a server defined by the data exchange constraints based on the analysis indicating that the network traffic satisfies the data exchange constraints corresponding to the target user, The management module includes: The third management module is configured to analyze the network traffic at an application program interface (API) layer based on the type of the network traffic being a third-party SDK type of network traffic, wherein analyzing the network traffic at the API layer includes: Determine the package API by adding judgment logic based on the data exchange constraint to the API of the third-party SDK; and The wrapping API is called to analyze the network traffic using the decision logic.

10. The apparatus according to claim 9, wherein the determination of the target user is based on at least one of the following: User information of the target user; and The device information corresponding to the target user.

11. The device according to claim 10, wherein: The user information includes: user account information, personal information, and / or registration information; and The device information includes: Subscriber Identity Module SIM information, IP address, network service provider information, device system setting information, and / or application setting information.

12. The device according to claim 10 or 11, further comprising: The constraint determination module is configured to determine the data exchange constraint corresponding to the target user based on the user information or the corresponding device information of the target user.

13. The apparatus according to claim 9, wherein the type of the network traffic comprises at least one of the following: Native-type network traffic associated with native apps; Web view type network traffic associated with the app's built-in browser; and Network traffic of the third-party SDK type associated with a third-party software development kit (SDK).

14. The apparatus according to claim 9, wherein the management module comprises: The first management module is configured to analyze the network traffic at a network layer based on the fact that the type of the network traffic is native type of network traffic.

15. The apparatus according to claim 9, wherein the management module comprises: The second management module is configured as follows: Based on the type of the network traffic being web view type network traffic, transferring the web view type network traffic to a network interface of the client application to be managed by a native network module of the client application; as well as Analyze the diverted network traffic at the network layer.

16. The apparatus of claim 15, wherein diverting the web view type of network traffic to the network interface of the client application comprises: A JavaScript hook mechanism is utilized to divert network traffic of the web view type.

17. The apparatus according to claim 9, further comprising: The sampling module is configured to send a sampling signal to the start module to trigger the start module, wherein the sampling signal indicates a sampling rate for sampling the network traffic.

18. An electronic device, comprising: Memory and processor; The memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method according to any one of claims 1 to 8.

19. A computer-readable storage medium having one or more computer instructions stored thereon, wherein the one or more computer instructions are executed by a processor to implement the method according to any one of claims 1 to 8.

Images