BR112024008227B1 - METHOD AND APPARATUS FOR MANAGING CLIENT APPLICATION NETWORK TRAFFIC - Google Patents

Abstract

METHOD AND APPARATUS FOR MANAGING CLIENT APPLICATION NETWORK TRAFFIC. According to embodiments of the present disclosure, a method, apparatus, device, and storage medium are provided for managing traffic data of a client application. The method described in the present invention comprises: detecting a transmission of user data from a target user from the client application to a server; analyzing the transmission traffic data at different transmission layers based on traffic data types; and, based on a determination that the analysis indicates that the traffic data satisfies a data exchange constraint corresponding to the target user, transmitting the traffic data to a server in compliance with the data exchange constraint. Thus, by analyzing the traffic data at different transmission layers and restricting traffic data that does not satisfy the data exchange constraint, it is possible to effectively prevent user data from being transmitted to unauthorized servers via various traffic data types.

Description

[001] This application claims priority from Chinese Patent Application No. 202111258204.1 filed with the National Intellectual Property Administration of China on October 27, 2021, and entitled “METHOD AND APPARATUS FOR MANAGING NETWORK TRAFFIC OF CLIENT APPLICATION”, the content of which is incorporated into the present invention by reference in its entirety.

FIELD

[002] Various implementations of the present disclosure relate to the computer field and, more specifically, to a computer method, apparatus, device, and storage medium related to a client application.

BACKGROUND

[003] With the development of Internet technology, various Internet applications have become an important part of people's lives. These applications generate a huge amount of data every day, which raises various data security issues, such as protecting data sovereignty. For example, some countries may prohibit specific types of user data from being sent to ROW (rest of the world) servers.

[004] For some globalized applications, these challenges are even more significant. These globalized applications may need to provide services to users in multiple different regions based on the same technical architecture. However, these regions may have different data security constraints, for example, specific data sovereignty protection requirements, which further exacerbates the difficulty of data security protection.

SUMMARY

[005] In a first aspect of the present disclosure, a method is provided for managing traffic data of a client application. The method comprises: detecting a transmission of user data of a target user from the client application to a server; analyzing the traffic data of the transmission at different layers of the transmission based on types of the traffic data; and according to a determination that the analysis indicates that the traffic data satisfies a data exchange contention corresponding to the target user, transmitting the traffic data to a server in compliance with the data exchange contention.

[006] In a second aspect of the present disclosure, an apparatus is provided for managing traffic data of a client application. The apparatus comprises: an initiator module configured to initiate a detection of a transmission of user data from a target user of the client application to a server; a management module configured to: in response to being activated by the initiator module, analyze the traffic data of the transmission at different layers of the transmission based on the types of the traffic data; and according to a determination that the analysis indicates that the traffic data satisfies a data exchange contention corresponding to the target user, transmit the traffic data to a server in compliance with the data exchange contention.

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

[008] In a fourth aspect of the present disclosure, there is provided a computer-readable storage medium with one or more computer instructions stored thereon, wherein the one or more computer instructions are executed by a processor to perform the method according to the first aspect of the present disclosure.

[009] In a fifth aspect of the present disclosure, there is provided a computer program product comprising one or more computer instructions, wherein the one or more computer instructions are executed by a processor to perform the method according to the first aspect of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[010] The above 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 drawings, the same or similar reference numerals indicate the same or similar elements, wherein: Fig. 1 shows a schematic block diagram of a data security protection system according to embodiments of the present disclosure; Fig. 2 shows a schematic block diagram of a computing security subsystem according to some embodiments of the present disclosure; Fig. 3A shows an example deployment environment in which a data exchange subsystem is deployed according to some embodiments of the present disclosure; Fig. 3B shows a DES implementation in an internal data center (IDC) on the TTP side and a ROW IDC (RoW (rest of world) IDC) where the non-TTP is located according to some embodiments of the present disclosure; Fig. 3C shows a block diagram of an example architecture according to some embodiments of the present disclosure; Fig. 3D shows a flowchart of a data exchange process according to some embodiments of the present disclosure; Fig. 3E shows a flowchart of an example data flow of various data processing implemented as DES according to some embodiments of the present disclosure; Fig. 3F shows a schematic block diagram of the data exchange architecture related to an MQ channel according to some embodiments of the present disclosure; Fig. 3G shows a schematic block diagram of the data exchange architecture related to an HDFS channel according to some embodiments of the present disclosure; Fig. 3H shows a schematic view of a target object store (TOS) channel for copying data from TTP IDC to Row IDC according to some embodiments of the present disclosure; Fig. 3I shows a schematic view of a TOS channel for copying data from RoW IDC to TTP IDC according to some embodiments of the present disclosure; Fig. 3J shows a message sequence diagram in a TOS channel according to some embodiments of the present disclosure; Fig. 3K shows a schematic block diagram of the data exchange architecture related to a channel service invocation according to some embodiments of the present disclosure; Fig. 3L shows an example of data exchange from non-TTP to TTP in a service invocation channel according to some embodiments of the present disclosure; Fig. 3M shows an example of data exchange from TTP to non-TTP in a service invocation channel according to some embodiments of the present disclosure; Fig. 4A shows a flowchart of a method of managing traffic data of a mobile end application according to some embodiments of the present disclosure; Fig. 4B shows a schematic view of an analysis and interception process for a native type of traffic data according to some embodiments of the present disclosure; Fig. 4C shows a schematic view of an analysis and interception process for a WebView type of traffic data according to some embodiments of the present disclosure; Fig. 4D shows a schematic view of an analysis and interception process for third-party SDK type traffic data according to some embodiments of the present disclosure disclosure; Fig. 4E shows a module diagram of a security sandbox subsystem according to some embodiments of the present disclosure; Fig. 5 shows a flowchart of an example process of managing a recommendation policy according to some embodiments of the present disclosure; Fig. 6 shows an example block diagram of an apparatus for exchanging data according to some embodiments of the present disclosure; and Fig. 7 shows a block diagram of an exemplary device for implementing embodiments of the present disclosure.

DETAILED DESCRIPTION OF THE MODALITIES

[011] The embodiments will be described in more detail with reference to the accompanying drawings, in which some embodiments of the present disclosure have been illustrated. However, the present disclosure can be implemented in various ways and, therefore, should not be construed as limited to the embodiments disclosed in the present invention. Rather, these embodiments are provided for the thorough and complete understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art. It should be understood that the drawings and embodiments of the present disclosure are used only for illustration, rather than to limit the scope of protection of the present disclosure.

[012] In describing the embodiments of the present disclosure, the terms “comprise” and their variants used in the present invention should be read as open terms meaning “includes, but is not limited to”. The term “based on” should be read as “based at least in part on”. The term “an embodiment” or “the embodiment” should be read as “at least one embodiment”. The terms “first”, “second”, and the like, may refer to different or the same objects. Other definitions, explicit and implicit, may be included below.

[013] The basic principle and various examples of implementations of the present disclosure will be illustrated with reference to the accompanying drawings.

General Architecture of the Data Security Protection System

[014] According to embodiments of the present disclosure, a data security protection system is provided. Fig. 1 shows a schematic block diagram of a data security protection system 1000 according to embodiments of the present disclosure. As shown in Fig. 1, the data security protection system 1000 comprises a plurality of subsystems for protecting, from different dimensions, the security of relevant data generated during a user's use of a target application.

[015] Generally speaking, to support the operation of the target application, on the one hand, the user needs to operate the target application 1080, for example, through an appropriate electronic device. On the other hand, a target application platform 1030 needs to be deployed in an appropriate computing environment (e.g., cloud computing environment) to operate various types of services to support the normal operation of the target application 1080.

[016] In some embodiments, the data security protection system 1000 may first ensure the security of data generated during the operation of the target application 1080 from the viewpoint of the security of the operational codes. As shown in Fig. 1, the data security protection system 1000 may comprise a security computing subsystem 1060, which may be used to ensure the security of codes corresponding to the target application 1080 and ensure the security of codes corresponding to the target application platform 1030.

[017] A service operational file compiled by the computing subsystem 1060 may be deployed to the target application platform 1030, for example, and an installation file (e.g., apk file) of the target application compiled by the computing subsystem 1060 may be issued to an application store 1120, for example. The specific implementation of the security computing subsystem 1060 will be discussed in detail below in conjunction with Fig. 2.

[018] In some embodiments, as shown in Fig. 1, the security computing subsystem 1060 may be based on cloud infrastructure 1070. In some embodiments, the cloud infrastructure 1070 may be provided by a trusted partner, for example. In the present disclosure, the “trusted partner” may also be referred to as a trusted technology partner (TTP), which may comprise, for example, any technically trusted individual, company, or organization in a specific region (e.g., specific country or jurisdiction).

[019] In some embodiments, as shown in Fig. 1, the data security protection system 1000 may comprise a trusted security environment 1010 provided by the TTP. Unlike deploying a traditional application platform, the target application platform 1030 may be deployed in the trusted security environment 1010 to increase the security of the data generated by the target application platform 1030, as well as the transparency and credibility of the operational mechanism thereof.

[020] In some embodiments, the target application 1080 may provide users with content recommendation services through recommendation algorithms. Such content recommendation may comprise, but is not limited to, multimedia content recommendation, user recommendation, product recommendation, etc. Considering that more and more recommendation systems currently use machine learning to perform the recommendation function, it may be difficult to ensure the fairness of the recommendation when managing the recommendation engine only from the code level.

[021] As shown in Fig. 1, the data security protection system 1000 may further comprise a recommendation management subsystem 1050, which may, for example, ensure the fairness of the recommendation engine in the target application 1080 by testing the recommendation algorithm operated by the target application platform 1030. The specific implementation of the recommendation management subsystem 1050 will be described in detail below.

[022] In some embodiments, considering that when the target application platform 1030 operates a service 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 referred to as ROW applications or ROW data centers) outside of the target region (e.g., a specific country or jurisdiction) where it is currently deployed.

[023] Generally, the target region often adopts laws or regulations to restrict the communication of data generated in the current region with the outside world. Specific types of data generated in the target region may be prohibited from being transmitted to the outside world. To ensure compliance of the target application platform 1030 during external communication, the data security protection subsystem may comprise a data exchange subsystem 1040. Similarly, the data exchange subsystem 1040 may be deployed in the trusted security environment 1010 to ensure the transparency and credibility of its operation.

[024] In some embodiments, as shown in Fig. 1, the data exchange subsystem 1040 may comprise a plurality of data channels for different types of data transmission. For example, multimedia data generated on the target application platform 1030 may communicate with an application of the ROW 1140 and/or a data center of the ROW 1150 through a respective data channel on the data exchange subsystem 1040 via a content distribution network 1130 provided by a third party.

[025] As another example, for some specific internal data generated on the target application platform 1030, it may communicate with the data center of the ROW 1150 and a development department of the ROW 1160 via a respective data channel, e.g., via a straight-through optical cable. The specific implementation of the data exchange subsystem 1040 will be described in detail in conjunction with Figs. 3A-3M.

[026] Additionally, to ensure the security of outgoing and incoming communication from the target application platform 1030, in some embodiments, the data security subsystem 1000 may further comprise an application firewall subsystem 1020. The application firewall subsystem 1020 may be deployed in the trusted security environment 1010, which may be used to monitor data communication from the target application 1080 to the target application platform 1030, data communication from the target application platform 1030 to the target application 1080, and/or data communication from the target application platform 1030 to a third-party application 110, etc.

[027] In this way, the data security protection platform 1000 can not only ensure the security and compliance of data communication between the target application platform 1030 and the outside through the data exchange subsystem 1040, but can also ensure the security and compliance of communication between the target application platform 1030 and various home objects (e.g., the target application 1080 or a third-party application 1110, etc.) through the application firewall subsystem 1020.

[028] In some embodiments, with respect to the target application 1080, to ensure compliance and credibility of its operation, the data security protection system 1000 may further comprise a security sandbox subsystem 1090 managed by the TTP, which enables different types of network communication involved in the application business logic 1100 of the target application 1080 to be protected by the security sandbox subsystem 1090. In this way, the data security protection system 1000 may prevent the target application 1080 from initiating non-compliant data communication, for example, through backdoor programs. The detailed implementation of the security sandbox subsystem 1090 will be described in conjunction with Figs. 4A-4E below.

[029] Thus, based on the data security protection system 1000 of the present disclosure, the TTP can manage and monitor various aspects such as code security and data security throughout the life cycle from development to operation of the target application, thereby ensuring the data security associated with the target application and also ensuring the compliance of its operation.

Security Computing Subsystem

[030] The security computing subsystem 1060 will be described in detail below with reference to Fig. 2. Fig. 2 shows a schematic block diagram of the security computing subsystem 1060 in accordance with embodiments of the present disclosure.

[031] As shown in Fig. 2, the security computing subsystem 1060 may comprise, for example, a security code environment 2010, which may be provided by the TTP. The work process of the security computing subsystem 1060 will be described in conjunction with the submission of the newly developed code 2140.

[032] As shown in Fig. 2, when developers need to deploy new developed code 2140, they can submit the developed code 2140 to the secure code environment 2010 through a synchronization gateway 2150 provided by the TTP. Accordingly, the developed code 2140 will be synchronized with a code library 2160 in the secure code environment 2010.

[033] In some embodiments, when developers need to use newly developed code 2140 for compilation, the developer may send a build request to an artifact build system 2080 through the synchronization gateway 2150.

[034] Alternatively, when code library 2160 receives newly developed code 2140, code library 2160 may also automatically send a code merge event to artifact build system 2080 to trigger artifact build system 2080 to begin the artifact (e.g., executable code) build process.

[035] When the build process is initiated, a code-removal module 2090 may obtain a code file for building from the code library 2160. In some embodiments, the code file for building may be specified by developers or determined automatically by the artifact build system 2080.

[036] Additionally, a compilation module 2100 may compile code retrieved from the code library 2160 by the code retrieve module 2090, for example, to compile it into intermediate code.

[037] In some embodiments, considering that some third-party code is typically introduced during the code compilation process, the security computing subsystem 1060 also needs to ensure the security of the introduced third-party code.

[038] As shown in Fig. 2, the security computing subsystem 1060 may comprise an independent third-party gateway 2030 for checking and confirming the security of a third-party library 2020 required to be introduced. It should be understood that such a third-party library may be a compiled link library or the source code itself, for example.

[039] The third-party library 2020 passing the security check may be added to an artifact library 2040. As shown in Fig. 2, during the artifact construction process, the compilation module 2100 may obtain, from the artifact library 2040, another artifact on which a current artifact to be compiled depends, for example, a historically compiled artifact or an artifact generated based on the third-party library 2020.

[040] Additionally, the compilation module 2100 may compile the code taken from the code library 2160 and the artifact obtained from the artifact library 2040 to generate intermediate code, so that a security code scanning module 2110 may perform code security checking.

[041] It should be understood that the TTP-managed security code scanning module 2110 can perform any code scanning process suitable for security checking. Such scanning rules are unknown to the developers, so that the security of the code compiled into the final artifacts can be guaranteed.

[042] In some embodiments, an upload module 2120 may perform respective uploads according to the result of the security code scanning module 2110. If the security code scanning module 2110 determines that the intermediate code obtained from the compilation is secure, then the upload module 2120 uploads an executable file obtained from the compilation to the artifact library 2040.

[043] Additionally, if the security code scanning module 2110 determines that the intermediate code obtained from the compilation is secure, the upload module 2120 may upload the executable file signature information to an artifact signature management module 2060.

[044] Conversely, if the security code scanning module 2110 determines that there are respective risks in the current intermediate code, then the upload module 2120 may upload the corresponding risks to an issue tracking system 2070 to form a risk analysis report. Accordingly, the executable file obtained from the compilation may be prohibited from being uploaded to the artifact library 2040.

[045] In some embodiments, the developed code 2140 in the code library 2160 may be provided in a trusted environment for manual checking. If it is determined that risks exist in the developed code 2140, then the result may also be reported to the issue tracking system 2070.

[046] In some embodiments, if the security code scanning module 2110 determines that respective risks exist in the current intermediate code, then the upload module 2120 may notify a callback module 2130 to mark the respective code in the code library 2160 as risk code.

[047] In some embodiments, the issue tracking system 2070 maintained by the TTP may send the received risk report information to the developers or maintainers of the developed code 2140 to remind them that the current developed code 2140 cannot pass the security check and therefore cannot be deployed.

[048] In some embodiments, if the developed code 2140 passes the security check, it may be compiled into an executable file and subsequently added to the artifact library 2040 to be deployed via a deployment gateway 2050.

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

[050] In some embodiments, the artifact may be an application program running on a client device, and then the deployment gateway 2050 may issue a generated installation file (e.g., apk file) to a respective application store for download by users. Thus, embodiments of the present disclosure may ensure that installation files that may be downloaded and installed by users are always issued by the secure code environment 2010 via the deployment gateway 2050.

[051] In some embodiments, the artifact may be a service program to be deployed to the target application platform 1030, for example. Specifically, the maintainer of the target application may initiate a request to deploy a specific artifact to the target application platform 1030 to the deployment platform. Accordingly, after the request is approved, the target application platform 1030 may obtain from the artifact library 2040 the specific artifact to be deployed and authenticate the signature of the specific artifact. After the artifact signature passes authentication, the artifact may be deployed to the target application platform 1030 via a virtual machine or container, for example.

[052] Thus, based on the discussed security computing subsystem, embodiments of the present disclosure can effectively monitor the code translation process into an application program or service program that will be deployed and used, from various cycles such as code uploading, code writing, code compilation, and referencing third-party libraries. In this manner, embodiments of the present disclosure can effectively prevent various security vulnerabilities or compliance risks introduced into the source code.

Data Exchange Subsystem

[053] Application operation involves data interaction between application platforms under the jurisdiction of different countries and regions. For example, in the example shown in Fig. 1, it is desirable to exchange data between the target application platform 1030 and a target application platform where the same application is operating abroad, to provide global application data interaction. As described above, the data exchange subsystem (DES) 1040 may support the synchronization of public data of the target application and other data that meets the rules between different platforms and ensure the security and compliance of the data being exchanged. In general, the DES 1040 is configured to detect whether data between different platforms meets a data exchange contention. Data exchange contentions may include contentions that are established to comply with national or regional laws and regulations, and contentions that are established due to company, organizational, and/or other user protection requirements, etc.

[054] For example, in countries or regions with specific data sovereignty protection requirements, the TTP may be required to conduct inspections involving data sovereignty protection. Therefore, in many cases involving data exchange between platforms, it is necessary to protect the security and compliance of data exchange. In particular, after the TTP computer room is set up, data exchange between outside parties and the TTP computer room will be restricted, and data interacted with by the TTP party is expected to be checked for data sovereignty protection. In these examples, data exchange restrictions may include rules referring to the data sovereignty protection requirements of specific countries or regions.

[055] Such interactive data can be divided into two aspects. One aspect includes inter-platform communication data, and the other includes operation and maintenance data, such as platform access or operation by the platform's operation and maintenance team. Intercommunication data is primarily used for synchronization between two platforms to ensure the functional integrity of applications, and such data needs to pass through the DES system for security and compliance checks. Intercommunication data includes, for example, online business data, offline data, etc. Operation and maintenance data checks aim to ensure that the operations of the operation and maintenance team in the operation and maintenance control plan are also compliant.

[056] Fig. 3A shows an example deployment environment 3001 where a DES 1040 is deployed in accordance with some embodiments of the present disclosure.

[057] In Fig. 3A, a TTP part 3027 refers to an environment that requires TTP supervision and containment in a specific country or region. The TTP part 3027 may involve various components for operating, managing, and maintaining a target application, for example, including a business system 3028, an operation platform 3029, an online storage 3030, an offline storage 3031, etc. The TTP part 3028 further comprises an operation and maintenance platform 3032, and the operation and maintenance personnel need to access the operation and maintenance platform 3032 to perform access, management, or maintenance of the target application.

[058] Similarly, a non-TTP part 3020 refers to an environment to which one or more countries or regions other than the specific country or region belong, which is free from the data exchange contention of the country or region where the TTP part 3027 is located. The non-TTP part 3020 may involve various components for operation, management, and maintenance of a target application, for example, including a business system 3020, an operation platform 3021, an online storage 3022, an offline storage 3023, etc. The non-TTP part 3020 further comprises an operation and maintenance platform 3024, and operation and maintenance personnel need to access the operation and maintenance platform 3024 to perform access, management, or maintenance of a local application or application platform.

[059] Domestic user traffic will flow through some components of the TTP portion 3027, and ROW user traffic will flow through some components of the non-TTP portion 3020. As used herein, “domestic user traffic” refers to user traffic generated on application platforms under the jurisdiction of the specific country or region, and “ROW user traffic” refers to user traffic generated on application platforms under the jurisdiction of one or more other countries or regions other than the specific country or region.

[060] In the environment of Fig. 3A, the intercommunication data comprises home user traffic and user traffic of the interacted ROW between the TTP portion and the non-TTP portion. The intercommunication data will pass through the DES 1040 for checks on aspects of data security, compliance, and the like. Furthermore, an operational gateway 3026 may additionally be established to perform data security and compliance checks on the operation and maintenance data.

[061] As will be discussed in detail below, in the DES 1040, different data channels may be established according to the data type to check the data to be exchanged on a respective channel. Fig. 3A schematically shows some channels, including a target object store (TOS) channel, a message queue (MQ) channel, an offline aggregate data channel, a log channel, a service invocation channel, etc.

[062] For both parties to the data exchange, they may have their own DESes to achieve data protection, for example, to protect incoming data and/or outgoing data.

[063] Fig. 3B further shows the implementation of the DES 1040 in the internal data center (IDC) of the TTP part and in the internal data center of the RoW (RoW IDC) where the non-TTP is located.

[064] In Fig. 3B, a TTP IDC 3056 refers to an IDC of the target application operating in the specific country or region, which is under data protection testing of the TTP. A ROW IDC 3059 refers to an IDC of the target application operating in one or more countries or regions other than the specific country or region, which may be subject to data protection containment of other countries or regions.

[065] As shown in Fig. 3B, a DES 1040A is implemented in the TTP IDC 3056 and used to detect received and/or sent data. A DES 1040B is implemented in the ROW IDC 3059 and used to detect received and/or sent data. Both the DES 1040A and the DES 1040B can be considered as specific implementation instances of the DES 1040.

[066] From the perspective of the TTP IDC 3056, the data received or sent may include various types of data, which will be described with examples.

[067] As shown in Fig. 3B, for the IDC TTP 3056, the data received from outside may include a user request, for example, a proactive request initiated by a user in a specific country or region via a target application 3058 operating within. As will be described elsewhere in this specification, in some embodiments, the user request may further pass through a firewall gateway 3057 at the IDC TTP 3056 and/or a mobile sandbox for security protection. The user request will reach a home application platform 3041 at the IDC TTP 3056 for further processing. In some examples, the home application platform 3041 may comprise various services, vendor gateways, storage, and other components. Furthermore, if the user request is transferred to a data center other than the IDC TTP 3056, the user request will be delivered to the DES 1040A for data protection.

[068] In some embodiments, for the IDC TTP 3056, the data received from outside may further comprise a vendor request initiated by a vendor 3055, e.g., requesting a specific service from a home application platform. For example, a third-party vendor may invoke an application program interface (API) of a home application platform, e.g., OpenAPI. Since it cannot be confirmed whether the third-party vendor is a home user, the vendor request will be sent via a third-party gateway 3040 in the IDC TTP 3056 to the vendor gateway in the home application platform 3041 to check to determine whether it is a home user. If the vendor initiating the request is a home user, then the vendor request may be responded to normally. If the vendor initiating the request is a ROW user, then the vendor request will pass through the DES 1040A before being transferred.

[069] In some embodiments, for the TTP IDC 3056, the data received from outside may additionally comprise data that is synchronized from the ROW IDC 3059 to the TTP IDC 3056. For example, if the data received from outside needs data security auditing, the data received from outside will also need to be processed by the DES 1040A.

[070] In some embodiments, for the TTP IDC 3056, the data received from outside may additionally comprise operation and maintenance operations of the TTP IDC 3056 by the operation and maintenance team, for example, changes to the TTP IDC 3056. Such operations may include code type changes, configuration type changes, log maintenance, etc. Code type changes may comprise initializing new functions, releasing binary files, and so on. Code type changes may be performed by the domestic operation and maintenance team of the application platform in the country or region. Configuration type changes may include enabling or disabling some settings of the target application, scaling traffic configuration, and so on. In some cases, configuration changes may be performed by the platform operation and maintenance team of the ROW for multinational operation application platforms. Of course, this depends on the management requirements of the different applications. Log maintenance refers to maintaining a 3044 log at TTP IDC 3056.

[071] In some embodiments, the home or ROW operation and maintenance team may perform operation and maintenance operations on the IDC TTP 3056 under network isolation conditions to further ensure data sovereignty protection. As shown in Fig. 3B, the home operation and maintenance team initiates the operation and maintenance operation under network isolation, and the operation and maintenance operation will be distributed via a load balancer 3045 to be distributed to the code 3042, an operation and maintenance platform 3043, or the log 3044 on the IDC TTP 3056. In addition to network isolation, the operation and maintenance operation of the home operation and maintenance team will be further subjected to security checking via the operational gateway 3046 and then distributed to the code 3042, the operation and maintenance platform 3043, or the log 3044 on the IDC TTP 3056.

[072] In some embodiments, for the TTP IDC 3056, the data sent from within may include a third-party request which is initiated from the home application platform 3041 during operation of the application platform, to request a third-party service 3054, e.g., a third-party request on a public network. The third-party request also requires data protection by the DES 1040A.

[073] In some embodiments, for the TTP IDC 3056, the data sent from within may additionally comprise data that is synchronized from the TTP IDC 3056 to the ROW IDC 3059. For example, during the operation of the target application, user contents stored in the TTP IDC 3056 may need to be synchronized with the ROW IDC 3059. According to some regulations on data sovereignty protection, such data may be the main data that the DES 1040A needs to review.

[074] In some embodiments, for the TTP IDC 3056, the data sent from within may additionally comprise code synchronization data. For example, in some cases, due to verification requirements, such as data sovereignty protection, a code review of the target application or application platform may be required. In order to prevent code leaks while meeting data sovereignty protection requirements, the code may be synchronized with a security isolation environment 3051 for review. The security 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, and the like, or a virtual computing environment with security protection, etc.

[075] From the perspective of the ROW IDC 3059, the DES 1040B deployed therein can also perform security protection on data received from outside and on data sent from inside similarly. For example, a user request that is generated by the user through the target application 3058 operating outside can also be protected by the DES 1040B after reaching an application platform of the ROW 3048 (which can comprise various types of services and storage) via the load balancer 3047. In the operation and maintenance aspect, the operation and maintenance personnel of the ROW can also perform operation and maintenance operation on the application platform of the ROW 3048 via a crystal gateway 3049 with network isolation. Such operation and maintenance operations can be under data protection via the DES 1040B.

[076] For data being protected under DES 1040A or 1040B, the solutions and processing for protecting data sovereignty may also differ depending on the different types of data.

[077] In embodiments of the present disclosure, in the DES 1040 (e.g., the DES 1040A or 1040B), data may be pre-processed according to the data type to format the standardized data formats, thereby simplifying and facilitating subsequent inspections on data sovereignty protection and accelerating the data exchange process.

[078] Thus, the DES 1040 may be divided into different processing portions according to the data type. For example, according to the data source, the DES 1040A may comprise a domestic user data channel for processing data relating to users in a specific country or region; a ROW user data channel for processing data relating to users overseas; an engineering technology data channel for processing engineering, operation, and maintenance data, such as code, parameters, and other research and development data, operation and maintenance data, etc. Additionally, the data in each channel may be further divided depending on the processing techniques, such as data generation, transmission, reception, and storage. As described below, divided by techniques, the data in different channels may be divided into one or more of message queue (MQ) data, offline aggregate data, target object store (TOS) data, and service invocation data, or other data types.

[079] For data undergoing data sovereignty protection review, the normalized format data can be converted back to the original format data and provided to a corresponding destination. According to the solution of the present disclosure, due to different data sources, different types of data differ in data format, processing techniques, and other aspects. Through normalized pre-processing and post-processing, the complexity in the subsequent data sovereignty protection review stage can be reduced. Furthermore, with the update of data sources and technical expansions/changes, it is possible to only change the data pre-processing and post-processing, rather than making complex processing changes at the data exchange contention determination stage. Therefore, the data exchange architecture has great flexibility and scalability.

[080] With reference to the accompanying drawings, a detailed description of some specific embodiments is presented below.

General Architecture and Data Flow of DES

[081] Fig. 3C shows a block diagram of an example of a DES 1040 according to some embodiments of the present disclosure. In the example of Fig. 3C, the DES 1040 is shown as synchronizing data between the home application platform 304 and an external application platform (collectively referred to as the ROW application platform 3048) for the target application and performing a determination of a data exchange contention.

[082] As shown in Fig. 3C, the DES 1040 may comprise a DES adapter 3061, a DES hub, and a DES adapter 3070. The DES hub may comprise DES hubs for different types of data channels, for example, a DES hub 3065A for home user data, a DES hub 3065B for ROW user data, and a DES hub 3065C for engineering technology data, etc. The DES hubs 3065A, 3065B, and 3065C have different synchronization capabilities. For purposes of description below, the DES hubs 3065A, 3065B, and 3065C may be collectively referred to as the DES hub 3065.

[083] The DES adapter 3061 is connected with the home application platform 3041 to receive data to be synchronized and detected via the DES 1040 from the home application platform 3041, send data received from the home application platform 3041 and detected by the DES 1040 to the ROW application platform 3048, and receive data to be synchronized and detected by the DES 1040 from the ROW application platform 3048. The DES adapters 3061 and 3070 are both interconnected with the DES hub 3065 to transfer data to the DES hub 3065.

[084] Each DES hub 3065 is configured to detect data when using a data exchange containment to ensure the security and compliance of data exchanged between two application platforms. Typically, data that meets the data exchange containment will be delivered to a respective destination via the DES 1040, while data that does not meet the data exchange containment may be rejected by the DES 1040.

[085] The DES adapter 3061 and 3070 may be configured to perform pre-processing and post-processing on data to be transferred to the DES center 3065, so that the DES center 3065 can determine whether data exchange contention is met based on the corresponding normalized data for various data types.

[086] In some embodiments, the DES adapter 3061 and the DES hub 3065 in the DES 1040 may be implemented in the TTP IDC 3065 along with the home application platform 3041, and the DES adapter 3070 may be implemented in the ROW IDC 3059 along with the ROW application platform 3048.

[087] In some embodiments, different components in DES 1040 may be isolated to further ensure more effective data isolation. This data isolation may be implemented by deploying different components in different data centers. In some embodiments, data isolation may be accomplished by applying virtual private data center (VPC) technology. For example, as shown in Fig. 3C, DES adapter 3061 may be deployed in VPC1, and multiple DES hubs may be deployed in VPC2, and DES adapter 3070 may be deployed in VPC3. Determining the security and compliance of data in DES hub 3065 may be performed by TTP. In the case of data isolation, VPC1 and VPC3 do not have a direct communication connection between them, while VPC1 and VPC3 each have a direct communication connection with VPC2 and can communicate data/information. Through the data isolation brought by VPC technology, the DES 3065 center deployed in VPC2 can be a TTP trusted area (referred to as TTP trusted area).

[088] In some embodiments, the DES adapter 3061 may comprise a DES gateway 3062, which may perform control plane processing, e.g., apply to create and manage data channels, logging rules, etc. by operation and maintenance personnel, and may view the data in the channel by TTP. The DES adapter 3061 may further comprise a DES proxy 3063 that may perform 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 comprise a control plane DES gateway 3072 and a data plane DES proxy 3073.

[089] In some embodiments, for home user data channels, the DES center 3065A may comprise a DES logging center for logging data exchange contentions, configuration data, etc. The DES center 3065A may further comprise fine-grained channels, including service invocation channels for service invocation data, MQ channels for MQ data, HDFS channels for offline aggregate data (where HDFS is referred to as Hadoop distributed file system), and TOS channels for TOS data. The offline aggregate data comprises, for example, highly parallel integrated virtual environment (HIVE) type data.

[090] Service invocation data comprises data for remote service invocations using various network protocols or invocation protocols, such as HTTP protocol or RPC protocol. MQ data may comprise data supporting the MQ protocol and similar protocol, for example, including data stored in various databases (e.g., MySQL database, Redis). Offline aggregate data may comprise data in file systems based on HDFS technology and data in file systems based on other techniques. TOS data comprises object files, such as video, audio, image, document, and other media files.

[091] In some embodiments, although not shown in Fig. 3C, the DES hub 3065B for ROW user data channels and the DES hub 3065C for engineering technology data channels may also comprise similar components to the DES hub 3065A.

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

[093] As shown in Fig. 3D, at block 3301, the DES 1040 obtains original data to be exchanged by a target application between a first platform (e.g., the home application platform 3014) and a second platform (e.g., the ROW application platform 3048). Depending on the exchange direction, the original data may be from the first platform and may be received by the DES adapter 3061 at the DES 1040. Or the original data may be from the second platform and may be received by the DES adapter 3070 at the DES 1040.

[094] In block 3302, the DES 1040 processes the original data based on the type of the original data to obtain normalized data corresponding to the type. The processing of the original data (also referred to as preprocessing) may be determined according to the type of the original data. The type of the original data may comprise, for example, MQ data, offline aggregated data, TOS data, or service invocation data, etc. Additionally, in some cases, the processing of the original data may also be determined according to multiple data sources. For example, according to the data source, the original data may be divided into home user data, ROW user data, or engineering technology data. Different data types correspond to different formats, and the corresponding normalized data may be generated in different ways.

[095] In some embodiments, since the techniques used by the data source differ, the same type of data may be provided in different formats, which adds requirements to the technical processing. Therefore, a normalized format may be specified. In the preprocessing stage, the format of the original data may be converted to a format specified under the type through format conversion, to normalize the data.

[096] For example, for MQ data, MQ data in different formats can be examined to analyze message contents encapsulated in different formats. For offline aggregate data and TOS data, different requests from file systems or data systems in different formats to invoke that data can be converted into file call requests implemented by uniform API. For service invocation, service invocation requests generated under different protocols can be converted into service invocation requests in a uniform protocol.

[097] For specific preprocessing on different data types, a more detailed description will be presented below.

[098] In block 3303, the DES 1040 determines whether the normalized data meets a data exchange contention. For example, the DES center 3065 in the DES 1040, especially the DES center 3065 of a corresponding data type, can check whether the data exchange contention is met or not. Through normalized preprocessing, the DES center 3065 does not need to examine the original data by different techniques, so that data security and compliance can be checked more conveniently when using rules.

[099] In block 3304, if it is determined that the normalized data meets the data exchange contention, the DES 1010 converts the normalized data to the original data. If the data exchange contention is met, the data is allowed to be synchronized across platforms. In order to ensure correct data synchronization, the DES 1040 will further process the normalized data to convert the normalized data to the original data, which has an original format.

[0100] In block 3305, the DES 1040 performs an exchange of the original data between the first platform and the second platform. Thus, the exchange of data meeting security and compliance can be performed.

[0101] In some embodiments, as briefly mentioned above, a plurality of data channels corresponding to different types of source data may be created between different platforms, and different types of source data will be delivered to the corresponding data channels for processing. Each data channel may comprise a pre-processing component, a post-processing component, and a data exchange contention confirmation component, which are suitable for processing this type of source data. Additionally, or alternatively, each data channel may be registered with a data exchange contention to be applied to the specific type of source data. In this way, it is possible to perform the separation of pre-processing, data exchange contention confirmation, and post-processing for different types of data.

[0102] Data channels corresponding to different data types can be flexibly created, updated, and deleted. Thus, if pre-processing and post-processing of data changes or data exchange containment for a specific data type needs to be updated, the change or update can be performed in the respective data channel without any impact on other data channels. Furthermore, according to business needs, if a new type of raw data needs to be exchanged between the first platform and the second platform, and the new type of data is also subject to data sovereignty protection checks, a new data channel can be created between the first platform and the second platform to process the new type of raw data.

[0103] Fig. 3E shows a flowchart of an example data flow 3005 of various types of data processing performed in the DES 1040 in accordance with some embodiments of the present disclosure. The data flow 3005 involves a control plane data flow and a data plane data flow.

[0104] In the control plane, the operation and maintenance personnel may configure one or more types of data channels in the DES 1040 and perform update and maintenance of the channels. As shown in Fig. 3E, the domestic operation and maintenance personnel may, via the DES input 3062, request the configuration of a specific data type and a channel for processing the specific data type, and register a data directory 3081 indicating the specific data type and a data definition 3082 similar to the specific data to a DES registration center 3066. The data definition 3082 may specify channel information for processing different types of data in the DES 1040 and may comprise a pre-processing solution and a post-processing solution over a respective data type.

[0105] Similarly, the ROW operation and maintenance staff may, via the DES input 3072, request the configuration of a specific data type and a channel for processing the specific data type. The ROW operation and maintenance staff may also register a data directory 3084 indicating the 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 data types in the DES 1040 and may comprise a pre-processing solution and a post-processing solution over a corresponding data type.

[0106] In the data plane, different types of data will pass through their respective channels in the DES 1040. As shown in Fig. 3E, for service invocation data, a service invocation request is exchanged between a client or server 3086 on the TTP IDC side and a client or a server 3090 on the ROW IDC side. In order to make the service invocation request meet data sovereignty protection requirements, the service invocation request is processed on the service invocation channel in the DES 1040.

[0107] In the example of Fig. 3E, the service invocation channel may comprise at least a preprocessing module 3087 in the DES proxy 3063, an HTTP proxy 3088 in the DES center 3065, and a routing module 3089 in the DES proxy 3073. The service invocation request from the client or server 3086 on the TTP IDC side is transferred to the preprocessing module 3087. The preprocessing module 3087 processes the service invocation request using a data preprocessing solution specified in the data definition 3082 and sends the normalized service invocation request to the HTTP proxy 3088.

[0108] In this example, it is assumed that the service invocation request is formatted into a request that conforms to a uniform protocol, i.e., HTTP protocol. Therefore, HTTP proxy 3088 may, after determining that the normalized service invocation request meets the data exchange contention, provide the normalized service invocation request through routing module 3089 to client or server 3090 on the other side. Before being provided to client or server 3090, the normalized service invocation request is converted back into a service invocation request that conforms to an original protocol.

[0109] For MQ data, such original data type is processed in the MQ channel in the DES 1040. In the example of Fig. 3E, the MQ channel may comprise at least a preprocessing module 3092 in the DES proxy 3063, an MQ transmitter 3094 in the DES center 3065, and a routing module 3097 in the DES proxy 3073.

[0110] The original MQ-type data 3091 is transferred to the preprocessing module 3092. The preprocessing module 3092 uses a data preprocessing solution specified in the data definition 3082 to process the original data 3091 to obtain normalized data 3093. The normalized data 3093 is extracted by the MQ transmitter 3094, for example, extracted via a third-party software development kit (SDK). After passing the data exchange contention check, the SDK pushes the normalized data 3096 that meets the rules to the ROW IDC. The normalized data 3095 that does not meet the rules is rejected. The routing module 3097 routes the normalized data 3096 that meets the rules to a corresponding destination. Before being transmitted to the corresponding destination, the normalized data 3093 is converted back to the corresponding original data 3098.

[0111] For offline aggregated data and TOS data, the original data is processed in the HDFS channel and the TOS channel in DES 1040, respectively. For the purpose of brevity, Fig. 3E shows an example of a channel. However, it should be understood that the HDFS channel and the TOS channel may comprise components that are shown. In the example of Fig. 3E, the HDFS channel and the TOS channel may comprise at least a preprocessing module 3100 in DES proxy 3063, a file transmitter 3103 in DES center 3065, and a routing module 3105 in DES 3073.

[0112] As data of the offline aggregate data type or TOS type is stored in a file system or other storage system, the preprocessing module 3100 may initiate a request to invoke a file transfer API to a file transfer manager 3102 to obtain original data 3099 of the offline aggregate data type or TOS type. The original data 3099 is transferred to the preprocessing module 3100. The preprocessing module 3100 may use a data preprocessing solution specified in the data definition 3082 to process the original data 3099 to obtain normalized data 3101.

[0113] Like MQ-type data processing, normalized data 3101 is extracted by file transmitter 3103, e.g., via SDK. After passing the data exchange contention check, the SDK pushes normalized data 3104 that meets the rules to the IDC ROW. Normalized data that does not meet the rules is rejected and cannot be transferred to the IDC ROW. Routing module 3105 routes normalized data 3104 that meets the rules to a corresponding destination. Before being transmitted to the corresponding destination, normalized data 3104 is converted back to the corresponding original data 3106.

[0114] It should be understood that Fig. 3E only shows the processing of data sent from the TTP IDC to the ROW IDC in the DES 1040. For a data flow in the opposite direction, this may also be processed through a similar process in the DES 1040, and the DES 1040 may retain a corresponding component to support the respective processing, especially a component in the DES adapter.

[0115] A detailed discussion is presented below for some example implementations for different data types in DES 1040.

Data Exchange Implementation Example for MQ Data

[0116] Fig. 3F shows a schematic block diagram of the data exchange architecture 3006 involving an MQ channel in accordance with some embodiments of the present disclosure. The data exchange architecture 3006 may be implemented in the DES 1040 to perform data security protection on MQ type data. In the example of Fig. 3F, a data exchange from the TTP IDC to the ROW IDC is shown.

[0117] As shown in Fig. 3F, a source database 3110 in the TTP IDC generates an entity of MQ data to be transferred. The MQ data may comprise 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 a source message queue 3112.

[0118] In the example of Fig. 3F, the DES adapter 3061 further comprises a DES pre-adapter 3120 in addition to the DES input 3062. The DES pre-adapter 3120 may be implemented as part of the DES proxy 3063 to perform pre-processing on the MQ data from the TTP IDC to the ROW IDC. The DES pre-adapter 3120 may be configured to process MQ data in different formats into normalized MQ data in a normalized format and provide the normalized MQ data to an MQ transmitter 3094 to determine whether data exchange contention is met or not.

[0119] The MQ data (or message) may also comprise data generated under different protocols, the data under each protocol having a custom format, so that different preprocessing is required. As shown in Fig. 3F, the DES pre-adapter 3120 may comprise a examiner 3122 that is configured to examine different types of original MQ data to convert different types of original data into normalized data in a normalized format. As shown in Fig. 3F, the DES pre-adapter 3120 may comprise a MySQL examiner for examining data generated through the MySQL protocol, for example, change data capture (CDC) data; a Redis examiner for examining data generated through the Redis protocol, such as CDC data; a document examiner for examining data in the document database, especially CDC data; a graph examiner for examining data in a graph database, especially CDC data; an MQ examiner for examining different types of business event data sent through a message queue, etc. It should be understood that the examiner 3122 is flexibly scalable, in that more, fewer, or other examiners can be established for examining a respective type of MQ data.

[0120] The normalized MQ data obtained from the scan may also be in the form of a message queue and may be placed in a normalized message queue 3124. In the VPC2 of the TTP IDC, the MQ transmitter 3094 in charge of the MQ data may pull the scanned normalized MQ data from the normalized message queue 3124 via the SDK for data security and compliance checks. Normalized MQ data that does not meet the data security and compliance check is rejected by the MQ transmitter 3094 and written to a reject log 3126. Normalized MQ data that meets the data exchange contention is pushed via the SDK to a DES post-adapter 3130 on the DES adapter 3070.

[0121] The DES post-adapter 3130 may be implemented as part of the DES proxy 3073 to perform post-processing on the normalized MQ data from the IDC TTP to the IDC ROW to transfer data to a destination. The normalized MQ data that meets the data exchange contention is pushed to the DES post-adapter 3130 via the SDK.

[0122] The DES post-adapter 3130 may comprise a data player 3132 for performing post-processing on the normalized MQ data. Specifically, the DES post-adapter 3130 may be configured to convert the normalized MQ data into original MQ data. Therefore, the DES post-adapter 3130 may comprise players corresponding to different types of MQ data for converting from a normalized format to respective custom formats. As shown in Fig. 3F, the DES post-adapter 3130 may comprise a MySQL player for converting normalized MQ data into MQ data that conforms to the MySQL protocol; a Redis player for converting normalized MQ data into MQ data that conforms to the Redis protocol; a document player for converting normalized MQ data into original data in graph form; an MQ player to convert normalized MQ data into original data that conforms to the MQ protocol, etc.

[0123] The converted original MQ data may be placed in a normalized message queue 3134 and may be synchronized with a target message queue 3135. The target message queue 3135 is used to save MQ data that is indirectly synchronized from a source message queue 3112 via the DES 1040. The target database 3136 may obtain desired MQ data from the target message queue 3135.

[0124] Fig. 3F shows only the components involved in the data exchange from the TTP IDC to the ROW IDC. The example in Fig. 3F shows the data exchange from the ROW IDC to the TTP IDC. The DES 1040 may comprise similar components for processing the data exchange in this direction, for example, the DES adapter 3070 may comprise a DES pre-adapter with similar functions to the DES pre-adapter 3120, and the DES adapter 3061 may comprise a DES post-adapter with similar functions to the DES post-adapter 3130. For the purpose of brevity, the processing in this direction is not detailed.

[0125] It should be understood that the component for processing offline aggregated data exchange in the DES, as shown in Fig. 3F, is merely exemplary. In other examples, depending on the needs, different functional modules may be further refined, combined, and the like in another manner, and may further comprise more, fewer, or different functional modules.

Data Exchange Implementation Example for Offline Aggregated Data

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

[0127] As shown in Fig. 3G, in the data exchange architecture 3500, a data transfer detector 3510 on the TTP IDC side is responsible for detecting whether offline aggregated data to be transferred to the HDFS 3504 on the other side is stored in the HDFS 3052. Where offline aggregated data to be transferred is found, a data transfer sender 3520 may forward a data transfer request to a file transmitter 3550. Before the request is forwarded to the file transmitter, a data preprocessing module 3530 is configured to perform data preprocessing to process offline aggregated data into normalized data.

[0128] In the file transmitter 3550, a data transfer server 3556 is configured to control data transfer services based on a data exchange contention. If the data transfer server 3556 determines that the preprocessed normalized data from the HDFS 3502 meets the data exchange contention, then a transfer job 3558 may be invoked to transfer the normalized data to the ROW IDC via a transfer task 3562 under the transfer job 3558. In some embodiments, the transfer job 3558 may optionally additionally have a data verification task 3560, which may be configured to perform data verification as needed. The normalized data passes through an HDFS gateway 3564 and may be processed to obtain original offline aggregated data that is then saved in the HDFS 3504.

[0129] Similarly, in the data exchange architecture 3500, a data transfer detector 3570 on the ROW IDC side is responsible for detecting whether offline aggregated data to be transferred to the HDFS 3502 on the TTP IDC side is stored in the HDFS 3054. Where offline aggregated data to be transferred is found, a data transfer sender 3572 may forward a data transfer request to a file transmitter 3550. Before the request is forwarded to the file transmitter, a data preprocessing module 3570 is configured to perform data preprocessing to process offline aggregated data into normalized data.

[0130] At file transmitter 3550, if data transfer server 3556 determines that preprocessed normalized data from HDFS 3504 fits the data exchange contention, then a transfer job 3554 may be invoked to transfer the normalized data to the TTP IDC via a transfer task 3552 under transfer job 3554. The original offline aggregated data is obtained by processing the normalized data and then saved to HDFS 3502.

[0131] It should be understood that the components for processing offline aggregated data exchange in DES as shown in Fig. 3G are merely exemplary. In other examples, depending on the needs, different functional modules may be further refined, combined, and the like in another manner, and may further comprise more, fewer, or different functional modules.

Example of Data Exchange Implementation for Object Storage

[0132] In general, the TOS channel may determine whether an object file meets data exchange contention and copy the object file from a source IDC (e.g., the TTP IDC or ROW IDC) to a destination IDC (e.g., the ROW IDC or TTP IDC) where contention is met. The object file may be, for example, a video, audio, image, document, or other media file.

[0133] In some embodiments, the object file may be copied from an object store via API to determine whether data exchange contention is met and push the object file to the object store at the final destination via API. Upon data exchange of the object file, it is determined whether data exchange contention is met by a corresponding copy request to the object file. Details of the TOS channel will be described with reference to Fig. 3H to Fig. 3J.

[0134] Fig. 3H shows a schematic view of a target object store (TOS) channel 3600 for copying data from the TTP IDC to the ROW IDC in accordance with some embodiments of the present disclosure. In this example, the data to be exchanged is an object file, which is stored in an object store 3606 in the TTP IDC and desired to be exchanged to an object store 3607 in the ROW IDC.

[0135] In Fig. 3H, an API 3605 in the TTP IDC is configured to push the copy request to a worker node 3605 and receive from the worker node 3605 a copy result that is exchanged from the ROW IDC on the other side. As depicted, when a data flow begins 3601, the copy request for the object file to be exchanged is transferred to the worker node 3605 via an API 3602 (also referred to as DES-TOS API). The copy request may indicate information related to the object file to be exchanged, e.g., a format (video, audio, text, etc.) of the object file, an identifier of the object file, and other file metadata, etc. The copy request has a normalized format.

[0136] The worker node 3605 within the trusted area of VPC2 is configured to perform a data exchange contention determination in response to the copy request for the target file. Specifically, the worker node 3605 may determine from the normalized copy request whether the object file to be exchanged meets the data exchange contention.

[0137] In some embodiments, on the TTP IDC side, a record of the data exchange contention may be initiated at the initial stage or when needed later. When the contention record begins 3622, the used data exchange contention may be recorded in a DES record center 3624 in the TTP trusted area through a DES entry 3620 in the TTP IDC. Recording of the data exchange contention may be implemented by invoking the API 3602. The worker node 3605 may access the currently used data exchange contention through the DES record center 3624.

[0138] In some embodiments, data exchange containment may indicate a whitelist of object files that are allowed to be exchanged or a blacklist of object files that are not allowed to be exchanged, and in each list, file objects that are allowed or not allowed to be exchanged may be identified by object file formats, identifiers, and the like.

[0139] Upon fulfilling data exchange contention, worker node 3605 allows the copy request that meets the data exchange contention to execute. If the copy request is allowed to execute, worker node 3605 accesses object store 3606 in the IDC TTP to copy the object file to object store 3607 in the IDC ROW. Illegal requests (i.e., copy requests that do not meet the data exchange contention) will be rejected and therefore cannot be executed. Worker node 3605 may write the copied object file to object store 3607 via an API 3610 in the IDC ROW. Thus, the data flow ends 3611.

[0140] Fig. 3I shows a schematic view of a TOS channel 3650 for copying data from the ROW IDC to the TTP IDC in accordance with some embodiments of the present disclosure. In this example, an object file to be exchanged is stored in object store 3607 in the ROW TTP IDC and is desired to be exchanged to object store 3606 in the TTP IDC.

[0141] In Fig. 3I, API 3610 on the ROW IDC is configured to push the copy request to worker node 3605 and receive from worker node 3605 a copy result that is exchanged from the TTP IDC on the other side. As shown in Fig. 3I, when a data flow begins 3651, the copy request for the object file to be exchanged is transferred to worker node 3605 via API 3610. The copy request may indicate information related to the object file to be exchanged, e.g., a format (video, audio, text, etc.) of the object file, an identifier of the object file, and other file metadata, etc. The copy request has a normalized format. Worker node 3605 within the trusted area of VPC2 may determine from the normalized copy request whether the object file to be exchanged meets data exchange contention.

[0142] In some embodiments, on the ROW IDC side, a record of the data exchange contention may be initiated at the initial stage or when needed later. When the contention record begins 3632, the used data exchange contention may be recorded in a DES record center 3624 in the TTP trusted area through a DES entry 3630 in the ROW IDC. Recording of the data exchange contention may be implemented by invoking the API 3610. The worker node 3605 may access the currently used data exchange contention through the DES record center 3624.

[0143] Upon fulfilling data exchange contention, worker node 3605 allows the copy request that meets the data exchange contention to execute. If the copy request is allowed to execute, worker node 3605 accesses object store 3607 in the IDC ROW to copy the object file to object store 3607 in the IDC TTP. Illegal requests (i.e., copy requests that do not meet the data exchange contention) will be rejected and therefore cannot be executed. Worker node 3605 may write the copied object file to object store 3606 via API 3602 in the IDC TTP. Thus, the data flow terminates 3652.

[0144] It should be understood that the components for processing the TOS data exchange in the DES as shown in Figs. 3H and 3I are merely exemplary. In other examples, depending on the requirements, different functional modules may further be refined, merged, and the like in another manner, and may further comprise more, fewer, or different functional modules.

[0145] Fig. 3J shows a sequence of messages 3012 on the TOS channel according to some embodiments of the present disclosure. The sequence of messages 3012 in Fig. 3J involves a TTP 3701, operation and maintenance personnel 3702, platform work personnel 3703, a DES entry 3704, an API 3705, the worker node 3605, and an object store 3708.

[0146] Depending on the direction of data exchange, the DES input 3704, the API 3705, and the object store 3708 in Fig. 3J may be corresponding components in any of Figs. 3H and 3I. For example, in the TOS channel 3600 for copying data from the TTP IDC to the ROW IDC as shown in Fig. 3H, the DES input 3704 comprises the DES input 3620 shown in Fig. 3H, the API 3705 comprises the API 3602 shown in Fig. 3H, and the object store 3708 comprises the object store 3606 in Fig. 3H. In the TOS channel 3650 for copying data from the ROW IDC to the TTP IDC, the DES entry 3704 comprises the DES entry 3630 shown in Fig. 3I, the API 3705 comprises the API 3610 shown in Fig. 3I, and the object store 3708 comprises the object store 3607 in Fig. 3I.

[0147] In message sequence 3012, operation and maintenance personnel 3702 registers 3711 a data exchange contention to DES entry 3704, which may contain copying an object file between object storage 3606 and 3607 in different IDCs. After registration is complete, DES entry 3704 may send 3714 a response to operation and maintenance personnel. DES entry 3704 registers 3712 container information about the data exchange contention to API 3705, and API 3705 may send 3713 a response to DES entry 3704 after registration is complete. Rules registered via DES entry 3704 may be cached 3715 in API 3705 and may also be cached 3716 on worker node 3605.

[0148] Platform worker team 3703 may initiate 3717 an object file copy request to API 3705. API 3705 may perform authentication 3718. Worker node 3605 may retrieve 3719 the copy request from API 3705 and perform 3720 a determination of data exchange contention on the object file to be copied. If the object file is permitted to be copied, worker node 3605 performs 3721 file copy to copy the corresponding object file from object store 3706. Regardless of the outcome of the data exchange determination, worker node 3605 will return 3722 feedback to API 3705. Where the object file is permitted to be copied, the feedback comprises the copied object file. When the object file is not allowed to be copied, feedback is used to indicate that the copy request was rejected.

[0149] In some embodiments, the platform work team 3703 may call back 3723 the API 3705, and a copy request ID may be returned 3724 from the API 3705 to the platform work team 3703. In some embodiments, the TTP 3701 may view the status 3725 about historical object file copies through the DES entry 3704 to confirm whether the exchange of object files in a past time period meets the data exchange contentions requirements. The DES entry 3704 may return 3726 as a result of the viewing.

Example of Implementing Data Exchange Protection for Service Invocation

[0150] Fig. 3K shows a schematic block diagram of the data exchange architecture 3800 involving a service invocation channel in accordance with some embodiments of the present disclosure. The data exchange architecture 3800 may be implemented in the DES 1040 to perform data security protection on service invocation type data. In the example of Fig. 3L, a data exchange service invocation is shown between a target platform service 3802 on the TTP IDC side and a ROW (non-TTP) platform service 3804 on the ROW IDC side. For example, a service on the target platform service 3802 may need to invoke a service on the ROW platform service 3804, and vice versa, a service on the ROW platform service 3804 may need to invoke a service on the target platform service 3802.

[0151] Different service platforms may apply different service invocation protocols, such as the HTTP protocol or the Thrift RPC protocol. In some embodiments of the present disclosure, it is expected that normalized data, e.g., HTTP protocol data, may be processed when performing data sovereignty protection in the VPC trusted area.

[0152] In Fig. 3K, in the control plane, the non-TTP control plane is used for channel registration, update, and channel architecture detection; the TTP/TTP plane is used for channel request approval, channel prohibition, channel detection, etc. In the data plane, an HTTP load balancer 3810 is a TTP Cloud L7 load balancer product, which is a key component in ensuring that all DES-RPC channel traffic passes through the VPR trust zone. An HTTP channel is a channel between DES-RPC channels that supports the HTTP protocol. A Thrift RPC channel is a channel between DES-RPC channels that supports the Thrift RPC protocol. Before being sent to the TTP HTTP load balancer, the Thrift RPC channel will be packaged in the HTTP channel.

[0153] At the channel registration stage, the DES-RPC channel uses channel information and data definition to declare. The channel information may comprise a channel type, such as Thrift RPC or HTTP. The channel information may further comprise RPC call tuples. The call tuples may include src dc, src services, dst dc, dst services, rpc methods/http paths.

[0154] The data definition may depend on the direction of the data flow. For a non-TTP to TTP data flow, the Thrift IDL with conformance annotations will be used to assert the response. For a TTP to non-TTP data flow, the Thrift IDL with conformance annotations will be used to assert the request. In some embodiments, only when the DESRPC channel passes the conformance record will the DES-RPC channel become available.

[0155] It should be understood that the components for processing the data exchange service invocation in DES, as shown in Fig. 3K, are merely exemplary. In other examples, depending on the needs, different functional modules may be further refined, combined, and the like in another manner, and may further comprise more, fewer, or different functional modules.

[0156] Fig. 3L shows an example of non-TTP to TTP data exchange in the service invocation channel shown in Fig. 3K in accordance with some embodiments of the present disclosure. As shown in Fig. 3L, an invocation initiated by service A 3901 in a region of the ROW will be forwarded by an HTTP proxy 3902 or a Thrift proxy 3903 to an HTTP TTP load balancer 3905. Service A 3901 may be an example platform service of the ROW shown in Fig. 3K. For an HTTP request, the invocation will be forwarded by HTTP proxy 3902 to HTTP load balancer 3905. For a Thrift request, the invocation will be forwarded by Thrift proxy 3903 to HTTP load balancer 3905.

[0157] It is suggested that service discovery from the corresponding service proxy in the IDC ROW, such as the HTTP proxy 3902 or the Thrift proxy 3903 to the VPC trust area HTTP load balancer 3905, be implemented via DNS, and it is suggested that service discovery of the corresponding request to the IDC TTP area should use custom/universal service discovery.

[0158] The HTTP load balancer 3905 may comprise a compliance plugin 3906. For an illegal request, the compliance plugin 3906 will return an error. For a Thrift RPC invocation, the request will be HTTP-wrapped to generate a new HTTP request. The body of the new HTTP request is a Thrift binary file.

[0159] In the VPC trust area, TTP's HTTP load balancer 3905 forwards requests to TTP's HTTP proxy 3907 and Thrift proxy 3908 respectively, and HTTP proxy 3907 and Thrift proxy 3908 forward requests to service B 3908 and service C 3910 as target services respectively. For a Thrift rpc invocation, Thrift proxy 3908 restores an original Thrift request from the new HTTP request generated before sending the request.

[0160] The HTTP TTP proxy 3907 and the Thrift proxy 3908 check responses before sending them to the HTTP TTP load balancer 3905. For a response that does not pass the compliance check, an error will be returned. Additionally, for the Thrift RPC invocation, 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.

[0161] Fig. 3M shows an example of TTP to non-TTP data exchange on the service invocation channel shown in Fig. 3K in accordance with some embodiments of the present disclosure. As shown in Fig. 3M, an invocation initiated by TTP service A 3951 will be forwarded by a TTP HTTP proxy 3952 and a Thrift proxy 3953 to a TTP HTTP load balancer 3955. For an HTTP request, the invocation will be forwarded by the HTTP proxy 3952 to the HTTP load balancer 3955. For a Thrift request, the invocation will be forwarded by the Thrift proxy 3953 to the HTTP load balancer 3955.

[0162] For an illegal request, an error will be returned. For a response that fails the compliance check, an error will be returned. For Thrift RPC invocation, the request will be HTTP-wrapped to generate a new HTTP response. The body of the new HTTP response is a Thrift binary file.

[0163] The TTP HTTP load balancer 3955 forwards requests to non-TTP HTTP proxy (i.e., ROW) 3957 and a Thrift proxy 3958, respectively. Then, the HTTP proxy 3957 and the Thrift proxy 3958 forward requests to the ROW's B service 39598 and C service 3960.

[0164] For a Thrift rpc invocation, the Thrift proxy restores an original Thrift request from the new HTTP request generated before sending the request.

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

Security Sandbox Subsystem

[0166] A client application needs to communicate with a server to transmit data. The client application's traffic data may transmit a large amount of user data. Therefore, there is a need for a method that can manage the client application's traffic data so that user data is not transmitted to an unauthorized server via the client application's traffic data. For example, in the data sovereignty protection scenario, the method can prevent user data from being transmitted to a server in a country without data sovereignty.

[0167] However, there are wide varieties of client application traffic data types. Client applications can include mobile applications and desktop (PC) applications. Client application traffic data can include native traffic data and WebView traffic data, etc. Furthermore, not all client application traffic data is under the management and control of the application owner. For example, client application traffic data may include traffic data from a third-party advertiser. Therefore, it is very difficult to manage multiple types of traffic data for client applications.

[0168] An example embodiment of the present disclosure proposes a method for managing traffic data of a client application. The method comprises: detecting a transmission of user data of a target user from the client application to a server; analyzing the traffic data of the transmission at different layers of the transmission based on types of the traffic data; and according to a determination that the analysis indicates that the traffic data satisfies a data exchange contention corresponding to the target user, transmitting the traffic data to a server in compliance with the data exchange contention.

[0169] In this way, by analyzing traffic data at different transmission levels based on the traffic data type and limiting the transmission of traffic data that does not meet the data exchange contentions, it is possible to effectively prevent user data from being transmitted to an unapproved server via various traffic data types.

[0170] A detailed description is presented below to illustrate embodiments of the present disclosure with reference to the accompanying drawings. A mobile application will be used as an example to illustrate the solution of the present disclosure.

[0171] Fig. 4A shows a flowchart of an exemplary method 4100 for managing traffic data of a mobile application in accordance with some embodiments of the present disclosure. The method 4100 may be implemented in the security sandbox subsystem 1090 of Fig. 1. The mobile application may be the target application 1080 on the mobile end.

[0172] In block 4102, a transmission of user data of a target user from the client application to a server is detected. In other words, if it is determined that a current user is the target user, then the security sandbox subsystem 1090 may detect the transmission of user data of the target user.

[0173] In some implementations, traffic data may be routed to the security sandbox subsystem 1090 based on the determination of the target user, such that the security sandbox subsystem 1090 may detect and analyze traffic data corresponding to the transmission of the user data. The security sandbox subsystem 1090 may analyze a network request from the target application 1080 and limit a network request that does not meet a condition based on a data exchange contention.

[0174] Data exchange containment may comprise exchange containment over data sovereignty, for example, data sovereignty protection rules. Data sovereignty protection rules may be determined in accordance with regulations of various countries or regions. Data sovereignty protection rules may also be determined by application operators (e.g., related to user data usage protocols).

[0175] Data sovereignty protection rules may be established based on a specific scenario. For example, data sovereignty protection rules may specify that user data from a data sovereign country is not permitted to be transmitted to any server outside the data sovereign country. In other implementations, data sovereignty protection rules may specify that private data of users from a data sovereign country is not permitted to be transmitted to any unregistered server. The scope of this disclosure is not limited in this regard.

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

[0177] The target user refers to a user for whom the transmission of user data needs to be detected and managed. The target user may be a user who is a national of a data sovereignty country. Alternatively, or in addition, the target user may also be a user determined in accordance with specific data sovereignty protection rules. For example, the target user may be a user who is a national of a data sovereignty country and is currently geographically located in the data sovereignty country.

[0178] In some implementations, the target user may be determined based on user information. The user information may comprise user account information, personal information, registration information, etc. Alternatively, or in addition, the target user may be determined based on device information. The device information may comprise subscriber identity module (SIM) information, an IP address, network service provider information, a device's system settings, application settings, etc.

[0179] In some implementations, the target user may be determined based on combinations of a plurality of information types. The plurality of information types may have different priorities. For example, the priority of SIM information and network service provider information may be higher than that of the IP address, a device's system settings, application settings, etc.

[0180] In some implementations, determining the target user may be based on a 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 to determine the target user. For example, the region where the user is currently located may be determined using the region setting in the system setting of a smartphone, and thus it may be determined 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 on the SIM card, and thus the target user may be determined.

[0181] In some implementations, the target user may be determined when the application is first started. In other words, it may be determined whether the current user is the target user when the application is first started. Alternatively, or in addition, it may be determined whether the current user is the target user during user registration. Alternatively, or in addition, it may be determined whether the current user is the target user when the user logs in, logs out, or switches accounts.

[0182] In some implementations, a determination result may be stored locally or on a server. The result may be determined after the user is determined as the target user for the first time, and the stored result may be established to be used within a threshold time period. Thus, when the user later logs in, the user does not need to be determined again.

[0183] In block 4104, the traffic data of the transmission is analyzed into different layers of the transmission based on the types of the traffic data.

[0184] Traffic data in the target application 1080 may comprise a plurality of traffic data types, such as native, WebView, and third-party software development kit (SDK) traffic data. Native-type traffic data is generated and processed by operating system code (e.g., Android and iOS) in the business layer. Native-type traffic data may be completely controlled by the owner of the target application 1080.

[0185] Third-party SDK traffic data is generated and processed by the third-party SDK. Typically, the third-party SDK may access the target application 1080 to perform login or sharing functions. Third-party SDK traffic data is generated and processed by third-party SDKs. It should be understood that third-party SDK traffic data is generally not completely controlled by the application owner.

[0186] WebView traffic data may comprise traffic data controlled by the application owner, e.g., traffic data generated by the application's built-in browser when invoking native application code. WebView traffic data may additionally comprise traffic data controlled by third parties, e.g., traffic data generated and controlled by third-party advertisers.

[0187] Based on the type of traffic data, the security sandbox subsystem 1090 may adopt a respective analysis policy to better manage the transmission of user data within the application.

[0188] At block 4106, pursuant to a determination that analysis indicates that the traffic data satisfies a data exchange containment corresponding to the target user, the traffic data is transmitted to a server in compliance with the data exchange containment. Different data exchange containments may be established for different target users. For example, more stringent data exchange containments may be established for target users with higher sensitivity levels. Data exchange containment may limit which user data may be transmitted to which servers. In some implementations, a data exchange containment corresponding to the target user may be determined based on the target user's user information or corresponding device information.

[0189] In some implementations, the security sandbox subsystem 1090 may comprise a plurality of submodules for different types of traffic data, such as a submodule for managing native-type traffic data, a submodule for managing WebView-type traffic data, and a submodule for managing third-party SDK-type traffic data. These submodules may analyze the respective types of traffic data and restrict or intercept traffic data that does not meet the data exchange containment. Details of the management of different types of traffic data will be described with reference to Figs. 4B-4E.

[0190] Fig. 4B shows a schematic view of an analysis and restriction process 4200 for native-type traffic data in accordance with some embodiments of the present disclosure. Fig. 4B shows a submodule 4210 for analyzing and restricting native-type traffic data. Submodule 4210 is part of security sandbox subsystem 1090 and may also be a specific implementation of security sandbox subsystem 1090.

[0191] As shown in Fig. 4B, a business logic layer 4220 issues a network request to an underlying OS 4230. The business logic layer 4220 may be a specific implementation of the application business logic 1100 shown in Fig. 1 in terms of transmission. The submodule 4210 may be used as an interceptor to analyze and restrict the network request at the network layer. The submodule 4210 may restrict the network request by analyzing endpoints, a parameter, or schema of the network request. For example, it may determine whether to restrict the network request depending on whether the schema has been registered. Alternatively, or in addition, it may determine whether to restrict the network request depending on whether the requested field in the network request involves sensitive information.

[0192] In some implementations, submodule 4210 may comprise an interceptor for Android and an interceptor for iOS. In addition, submodule 4210 may also comprise an interceptor for C++. In this way, by analyzing and restricting the network request at the network layer, it may be better evaluated whether the network request should be restricted, based on the protocol information of the network request.

[0193] Fig. 4C shows a schematic view of an analysis and restriction process 4300 for WebView-type traffic data in accordance with some embodiments of the present disclosure. Fig. 4C shows a submodule 4310 for analyzing and restricting WebView-type traffic data. Submodule 4310 may be part of security sandbox subsystem 1090 and may also be a specific implementation of security sandbox subsystem 1090.

[0194] Submodule 4310 may transfer WebView-type traffic data to a native network interface, such that WebView-type traffic data may be parsed and restricted by submodule 4210 to native-type traffic data. In some implementations, submodule 4310 may use a JavaScript (JS) hook mechanism to transfer WebView-type traffic data to the native network interface.

[0195] As shown in Fig. 4C, submodule 4310 may comprise an initiator 4311, a navigation URL interceptor 4312, and an internal request interceptor 4313. Submodule 4310 may communicate with an integrated browser 4320 of the application, so that WebView-type traffic data may be managed and detected by submodule 4310. Initiator 4311 may perform JS injection when the integrated browser 4320 of the application is opened (created), so that WebView-type traffic data may be transferred to the native network interface using the hook mechanism. The traffic data transferred to the native network interface may be taken by a native network module.

[0196] In some implementations, traffic data may be transferred using the JS hook technique as follows.

[0197] Navigation URL interceptor 4312 may analyze and restrict the URL of a main page (home page). For example, navigation URL interceptor 4312 may determine whether to restrict the network request depending on whether the URL-based scheme has been registered. If the network request is not restricted, then browser 4320 may load the main page.

[0198] The internal request interceptor 4313 may transfer traffic data related to static and dynamic resources from the main page to the native network interface, so that this traffic data may be restricted and analyzed by the submodule 4210 at the network layer. The specific analysis and restriction process is similar to native-type traffic data and is not detailed here.

[0199] In some implementations, submodule 4310 may adopt different analysis and restriction policies for application owner-controlled WebView traffic data and third-party controlled WebView traffic data. For example, for third-party controlled WebView traffic data, it may only be determined using navigation URL interceptor 4312 whether the URL of the main page was recorded, without further analyzing the static and dynamic resources of the main page.

[0200] Fig. 4D shows a schematic view of an analysis and restriction process 4400 for third-party SDK-type traffic data in accordance with some embodiments of the present disclosure. Fig. 4D shows a submodule 4410 for analyzing and restricting third-party SDK-type traffic data. Submodule 4410 may be part of security sandbox subsystem 1090 and may also be a specific implementation of security sandbox subsystem 1090.

[0201] Submodule 4410 may analyze and restrict third-party SDK-type traffic data at the application program interface (API) layer. Submodule 4410 may restrict third-party SDK-type traffic data by analyzing at the API layer whether the data requested by the third-party SDK's API meets data exchange contentions.

[0202] In some implementations, submodule 4410 may package the API requesting user data in the third-party SDK and add judgment logic based on data exchange contentions in the package. In other words, submodule 4410 may add judgment logic to the third-party SDK's API to determine whether the API should be packaged. Thus, business logic layer 4220 does not directly invoke the third-party SDK's API, but rather invokes the packaged API to which the judgment logic has been added.

[0203] As shown in Fig. 4D, submodule 4410 may comprise a packaging module for each third-party SDK, such as a packaging module 4412 for SDK 4411, a packaging module 4414 for SDK 4413, and a packaging module 4416 for SDK 4415. The packaging module (e.g., packaging module 4412) may package the API in the corresponding SDK (e.g., SDK 4411) to generate a corresponding packaged API. In some implementations, submodule 4410 may dynamically augment a packaging module to package an API from a third-party SDK.

[0204] In some implementations, an API from a third-party SDK may be packaged as follows. Packaging module 4412 may define an API that is exposed to the business layer and equal to the API in SDK 4411. Packaging module 4412 may realize the API and define a package category of the SDK data type 4411.

[0205] The judgment logic may determine, based on data exchange constraints, whether the third-party SDK's packaged API can be invoked. In some implementations, the judgment logic may analyze whether the third-party SDK's API can be invoked based on an SDK name, an API name, an API parameter name, and so on. If the judgment result is yes, then the third-party SDK's API can be invoked and a value is returned to the business layer. If the judgment result is no, then the third-party SDK's API is not invoked; that is, traffic data related to the API is restricted. It should be understood that the judgment logic may change based on a specific scenario. For example, the judgment logic may determine that a user's private data is not allowed to be sent to the third-party SDK.

[0206] In this way, through analysis and restriction at the API layer, the submodule 4410 can manage and detect third-party SDK-type traffic data in the network without needing to know the internal code of the third-party SDK.

[0207] Fig. 4E shows a block diagram of the security sandbox subsystem 1090 according to some embodiments of the present disclosure. As shown in Fig. 4E, the security sandbox subsystem 1090 comprises an initiator module 4520. The initiator module 4520 is configured to initiate a detection of a transmission of user data of a target user from the client application to a server. The initiator module 4520 may activate a management module to detect, manage, analyze, and restrict traffic data corresponding to the transmission of user data.

[0208] The management module is configured to analyze the transmission traffic data at different transmission layers based on the traffic data types; and transmit the traffic data to a server in compliance with data exchange contention according to a determination that the analysis indicates that the traffic data satisfies a data exchange contention corresponding to the target user.

[0209] In some implementations, the management module may comprise 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. Submodules 4210, 4310, and 4410 may analyze and restrict client application traffic data.

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

[0211] In some implementations, submodule 4310 is configured to, based on whether traffic data is of type WebView, transfer the WebView traffic data to a network interface of the client application to be managed by a native network module of the client application; and analyze the transferred traffic data at the network layer.

[0212] In some implementations, transferring WebView traffic data to the mobile application's network interface comprises: using a JavaScript hook mechanism to transfer the WebView traffic data.

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

[0214] In some implementations, analyzing traffic data at the API layer comprises: determining the packaging of an API by adding judgment logic based on data exchange contention to the third-party SDK's API; and invoking the packaged API to use the judgment logic to analyze the traffic data.

[0215] In some implementations, initiator module 4520 may activate submodules 4210, 4310, and 4410 based on a target user determination. For example, initiator module 4520 may determine during user registration whether a current user is the target user. If the determination result is yes, then initiator module 4520 may activate submodules 4210, 4310, and 4410. For another example, initiator module 4520 may obtain the user determination result locally or from a server during user login and determine based on the determination result whether submodules 4210, 4310, and 4410 should be activated.

[0216] The security sandbox subsystem 1090 may further comprise a sampling module 4510 for sampling traffic data. In some implementations, the sampling module 4510 may send the initiator module 4520 a sampling signal to trigger the initiator module 4520. The sampling signal may indicate a sampling rate at which traffic data is sampled.

[0217] The sampling module 4510 may sample target user and different types of traffic data based on data exchange contentions. For example, the sampling module 4510 may sample different types of traffic data at different sampling rates. With the sampling module 4510, not only can a portion of traffic data be analyzed, but also overhead can be reduced and application stability can be maintained.

[0218] It should be understood that the security sandbox subsystem 1090 may additionally comprise another module or comprise only a portion of the modules shown in Fig. 4E. For example, when the target application 1080 is only a native application on the mobile end, the security sandbox subsystem 1090 may not comprise the submodule 4310 for WebView-type traffic data. The scope of the present disclosure is not limited in this regard.

[0219] In some implementations, based on the traffic data type, the traffic data may additionally be parsed and restricted at the Socket layer. For example, third-party SDK type traffic data may be forwarded at the Socket layer so that the third-party SDK type network request can be parsed directly. Alternatively, or in addition, native type traffic data and WebView type traffic data may be parsed and restricted at the Socket layer.

[0220] In some implementations, a local server may be built as a proxy in the target application 1080. Network requests forwarded by the local server to external servers may be managed by forwarding the network requests from the target application 1080 to the local server and analyzing and restricting the traffic data at the local server. In this manner, different types of traffic data may be analyzed and restricted taking into account protocol information to better manage the application's traffic data that will not be transmitted to unauthorized external servers.

[0221] The principles and details of analyzing and restricting different types of traffic data have been described in detail with reference to Figs. 4B-4E. It should be understood that the above restriction rules, judgment logic, and data exchange restraints are merely exemplary and are not intended to limit the scope of the present disclosure. For example, different data sovereignty protection rules may be established according to laws and regulations of different countries. Furthermore, depending on the definition of a computer network layer, traffic data may be analyzed and restricted at layers close to or similar to the layers above.

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

[0223] In some implementations, with respect to multiple data sovereignty countries, a plurality of security sandbox subsystems 1090 may be established respectively to perform processing for each data sovereignty country, respectively. For example, based on determining a region where the target user is located, a corresponding security sandbox subsystem may be initiated to analyze and restrict traffic data so that the transmission of user data in the application complies with the data sovereignty protection rules of the corresponding country.

Recommendation Management Subsystem

[0224] As discussed above, the target application may provide users with various content recommendations through a recommendation engine, such as multimedia content recommendation, user recommendation, product recommendation, etc. In such applications, the fairness of recommendation policies has become the focus of management in many regions. For example, some applications may use recommendation engines to guide users to pay attention to specific content that has nothing to do with the user's habits, and therefore, such recommendation engines may not be compatible.

[0225] On the one hand, common recommendation algorithms often rely on machine learning models for implementation. For example, code-level verification performed by the security computing subsystem 1060 may be unable to effectively detect the fairness of recommendation algorithms. On the other hand, the training and updating of recommendation models are often closely related to real user data, and people do not expect to expose users' private data during the inspection process, as this may lead to data compliance risks.

[0226] Embodiments of the present disclosure further propose a solution for managing a recommendation policy. Fig. 5 shows a flowchart of a process 500 for managing a recommendation policy. Process 500 may be performed by recommendation management subsystem 1050, for example.

[0227] As shown in Fig. 5, at block 502, the recommendation management subsystem 1050 obtains a group of object features associated with a group of objects in a target application, wherein the group of object features is converted based on attributes of the group of objects, the group of objects not directly expressing attributes of the group of objects.

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

[0229] In some embodiments, the object feature group may be converted by a feature extraction model based on attributes of the object group. In this way, the management party recommending the policy or other third party cannot determine the original attribute information of objects based on the object features. Therefore, data security in the target application may be ensured.

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

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

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

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

[0234] In some embodiments, to ensure the security of a recommended policy, the recommendation management subsystem 1050 sends the first selected object resource and the second selected object resource via the API provided by the target application to a recommendation model that operates remotely to determine the first recommendation result and the second recommendation result. For example, the recommendation model may be operated by the maintainer of the target application.

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

[0236] In some embodiments, the first recommendation result and the second recommendation result may be represented as vectors 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 data security in the target application.

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

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

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

[0240] Or the recommendation management subsystem 1050 may also determine the fairness of the recommendation policy based on a proportion of the object feature pairs whose second difference exceeds the second threshold. For example, the recommendation management subsystem 1050 may randomly sample the plurality of object feature groups, and if the proportion of the object feature pairs whose second difference exceeds the second threshold exceeds a threshold proportion, then it may determine that the recommendation policy has low fairness.

[0241] In some embodiments, the recommendation management subsystem 1050 may further determine the fairness of the recommendation policy based on the correlation between the object features inputted into the recommendation model and the historical recommendation results. Specifically, the recommendation management subsystem 1050 may obtain a third object feature from the target application and a historical recommendation result for the third object feature. Additionally, the recommendation management subsystem 1050 determines the fairness of the recommendation policy based on the correlation between the third object feature and the historical recommendation result. For example, the recommendation management subsystem 1050 may determine whether the object feature matches the category information of the historical recommendation result.

[0242] In some embodiments, the recommendation management subsystem 1050 may determine vector representations 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 a 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, then the recommendation management subsystem 1050 may determine that the recommendation policy has low fairness.

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

[0244] In some embodiments, the recommendation policy may be used to recommend at least one multimedia content to a user in the target application 1080, for example. Examples of the multimedia content may include: an image, video, music, or combinations thereof, etc., for example.

Exemplary Apparatus and Device

[0245] Embodiments of the present disclosure further provide a corresponding apparatus for performing the above method or process. Fig. 6 shows a schematic block diagram of an apparatus 600 for data traffic of a client application.

[0246] As depicted, the apparatus 600 comprises: a detection unit 610 configured to detect a transmission of user data of a target user from the client application to a server; an analysis unit 620 configured to analyze the traffic data of the transmission at different layers of the transmission based on traffic data types; and a transmission unit 630 configured to, according to a determination that the analysis indicates that the traffic data satisfies a data exchange contention corresponding to the target user, transmit the traffic data to a server in compliance with the data exchange contention.

[0247] Fig. 7 shows a schematic block diagram of an exemplary device 700 for implementing embodiments of the present disclosure. For example, system 100 and/or system 400 according to embodiments of the present disclosure may be implemented by device 700. As depicted, device 700 comprises a central processing unit (CPU) 701, which may perform various appropriate actions and processing based on computer program instructions stored in a read-only memory (ROM) 702 or on computer program instructions loaded into a random access memory (RAM) 703 from a storage unit 708. In RAM 703, various programs and data required by the operation of device 700 are also stored. 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 bus 704.

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

[0249] The procedures and processes described above, such as process 500, may be executed by processing unit 701. For example, in some embodiments, process 500 may be implemented as a computer software program, which is tangibly included on a machine-readable medium, e.g., storage unit 708. In some embodiments, the computer program may be partially or fully loaded and/or mounted on device 700 via ROM 702 and/or communication unit 709. The computer program, when loaded into RAM 703 and executed by CPU 701, may perform one or more actions of process 500 as described above.

[0250] The present disclosure may be a method, apparatus, system, and/or computer program product. The computer program product may comprise a computer-readable storage medium onto which are loaded computer-readable program instructions for executing various aspects of the present disclosure.

[0251] The computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, such as an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More concrete examples of computer-readable storage medium (non-exhaustive list) include: a portable computer floppy 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 disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device such as punched cards stored with instructions thereon or a projection in a slot, and any suitable combination of the foregoing. The computer-readable storage medium as used in the present invention should not be construed as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated through a waveguide or other transmission media (e.g., optical pulses via fiber optic cables), or electrical signals transmitted through wires.

[0252] The computer-readable program instructions described in the present invention may be downloaded from the computer-readable storage medium to each computing/processing device, or to an external computer or external storage device via a network, e.g., the Internet, a local area network, a geographically distributed network, and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, network key computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on the computer-readable storage medium of each computing/processing device.

[0253] Computer-readable program instructions for performing operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-set data, or source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a geographically distributed network (WAN), or the connection may be made to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, the electronic circuitry, including, for example, programmable logic circuitry, field programmable gate array (FPGA), or programmable logic array (PLA), may execute computer-readable program instructions using state information from the computer-readable program instructions to customize the electronic circuitry to perform aspects of the present disclosure.

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

[0255] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block or blocks of the block diagram. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable storage medium having the instructions stored thereon comprises an article of manufacture including instructions that implement aspects of the function/act specified in the flowchart and/or block or blocks of the block diagram.

[0256] Computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process, such that the instructions that are executed on the computer, other programmable apparatus, or other devices implement the functions/acts specified in the flowchart and/or block or blocks of the block diagram.

[0257] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of computer systems, methods, and program products in accordance with various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, program segment, or portion of code, comprising one or more executable instructions for implementing the specified logical functions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the accompanying drawings. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, may be implemented by systems based on special-purpose hardware that perform the specified functions or actions, or by combinations of special-purpose hardware and computer instructions.

[0258] The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The selection of terms used in the present invention has been chosen to better explain the principles of the embodiments, the practical application or technical improvements over commercially available technologies, or to enable others skilled in the art to understand the embodiments disclosed in the present invention.

Claims (20)

1. A method for managing traffic data of a client application, comprising: detecting a transmission of user data of a target user from the client application to a server; analyzing the traffic data of the transmission at different layers of the transmission based on the types of traffic data, wherein analyzing the traffic data at different layers of the transmission comprises: according to a determination that the traffic data is of a third-party software development kit (SDK) type, analyzing the traffic data at an application program interface (API) layer, wherein analyzing the traffic data at an API layer comprises: determining a packaging API by adding decision logic based on a data exchange contention to an API of the third-party SDK; and invoking the packaging API to analyze the traffic data by using the decision logic; and according to a determination that the analysis indicates that the traffic data satisfies the data exchange contention corresponding to the target user, transmitting the traffic data to a server in compliance with the data exchange contention. 2. The method of claim 1, wherein the target user is determined based on at least one of: user information of the target user; and device information corresponding to the target user. 3. The method of claim 2, wherein: the user information comprises: user account information, personal information, and/or registration information; and the device information comprises: subscriber identity module information, SIM, an IP address, network service provider information, system settings of a device, and/or application settings. 4. The method of claim 2, further comprising: determining the data exchange contention corresponding to the target user based on the user information of the target user or the corresponding device information. 5. The method of claim 1, wherein the traffic data types comprise at least one of: a native type of traffic data associated with a native application; a WebView type of traffic data associated with a browser integrated into an application; and a third-party SDK type of traffic data associated with a third-party SDK. 6. The method of claim 1, wherein analyzing traffic data at different transmission layers comprises: in accordance with a determination that the traffic data is of a native type, analyzing the traffic data at a network layer. 7. The method of claim 1, wherein analyzing traffic data at different transmission layers comprises: in accordance with a determination that the traffic data is of a WebView type, transferring the WebView type of traffic data to a network interface of the client application to be managed by a native network module of the client application; and analyzing the transferred traffic data at a network layer. 8. The method of claim 7, wherein transferring the WebView type of traffic data to the network interface of the client application comprises: transferring the WebView type of traffic data using a JavaScript hook mechanism. 9. An electronic device comprising: a memory and a processor; wherein the memory stores one or more computer instructions, wherein the one or more computer instructions are executed by the processor to perform the method comprising: detecting a transmission of user data of a target user from the client application to a server; analyzing the traffic data of the transmission at different layers of the transmission based on the types of traffic data, wherein analyzing the traffic data at different layers of the transmission comprises: according to a determination that the traffic data is of a third-party software development kit (SDK) type, analyzing the traffic data at an application program interface (API) layer, wherein analyzing the traffic data at an API layer comprises: determining a packaging API by adding decision logic based on a data exchange contention for a third-party SDK API; and invoking the packaging API to analyze the traffic data by using the decision logic; and in accordance with a determination that the analysis indicates that the traffic data satisfies the data exchange containment corresponding to the target user, transmit the traffic data to a server in compliance with the data exchange containment. 10. The device of claim 9, wherein the target user is determined based on at least one of: user information of the target user; and device information corresponding to the target user. 11. The device of claim 10, wherein: the user information comprises: user account information, personal information, and/or registration information; and the device information comprises: subscriber identity module information, SIM, an IP address, network service provider information, system settings of a device, and/or application settings. 12. The device of claim 10, wherein the method further comprises: determining the data exchange contention corresponding to the target user based on the user information of the target user or the corresponding device information. 13. The device of claim 9, wherein the traffic data types comprise at least one of: a native type of traffic data associated with a native application; a WebView type of traffic data associated with a browser integrated into an application; and a third-party SDK type of traffic data associated with a third-party SDK. 14. The device of claim 9, wherein analyzing the traffic data at different layers of the transmission comprises: in accordance with a determination that the traffic data is of a native type, analyzing the traffic data at a network layer. 15. The device of claim 9, wherein analyzing the traffic data at different layers of the transmission comprises: in accordance with a determination that the traffic data is of a WebView type, transferring the WebView type of traffic data to a network interface of the client application to be managed by a native network module of the client application; and analyzing the transferred traffic data at a network layer. 16. The device of claim 15, wherein transferring the WebView type of traffic data to the network interface of the client application comprises: transferring the WebView type of traffic data using a JavaScript hook mechanism. 17. A computer-readable, non-transitory storage medium with one or more computer instructions stored therein, wherein the one or more computer instructions are executed by a processor to perform the method comprising: detecting a transmission of user data of a target user from the client application to a server; analyzing the traffic data of the transmission at different layers of the transmission based on the types of traffic data, wherein analyzing the traffic data at different layers of the transmission comprises: according to a determination that the traffic data is from a type of third-party software development kit (SDK), analyzing the traffic data at an application program interface (API) layer, wherein analyzing the traffic data at an API layer comprises: determining a packaging API by adding decision logic based on a data exchange contention for an API of the third-party SDK; and invoking the packaging API to analyze the traffic data by using the decision logic; and in accordance with a determination that the analysis indicates that the traffic data satisfies the data exchange containment corresponding to the target user, transmit the traffic data to a server in compliance with the data exchange containment. 18. The non-transitory computer-readable storage medium of claim 17, wherein the target user is determined based on at least one of: user information of the target user; and device information corresponding to the target user. 19. The non-transitory computer-readable storage medium of claim 18, wherein: the user information comprises: user account information, personal information, and/or registration information; and the device information comprises: subscriber identity module information, SIM, an IP address, network service provider information, system settings of a device, and/or application settings. 20. The non-transitory computer-readable storage medium of claim 18, wherein the method further comprises: determining data exchange contention corresponding to the target user based on the target user's user information or the corresponding device information.