Cloud mobile phone application security control method and device based on multiple levels

Abstract

The invention belongs to the technical field of networks, and provides a cloud mobile phone application security control method and device based on multiple levels. The method comprises the following steps of: configuring application list constraint mechanisms of different hierarchies, including updating configured application black and white lists, performing package name filtering and performing application version control; constraining partners of cloud mobile phone business services and applications of cloud mobile phone commodities at the same time according to the configured application list constraining mechanisms of different levels; based on the cloud mobile phone access domain name, the access behavior in the application of the cloud mobile phone is controlled; and when the current application is installed or the user enters the cloud mobile phone, the cloud mobile phone server judges whether the application black and white list is the latest application black and white list or not, and judges whether the current application or the installed application belongs to the latest application black and white list or not, so as to determine whether the current application is allowed to be installed and used on the corresponding cloud mobile phone or not. According to the invention, the security management and control of the cloud mobile phone application can be realized more effectively.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud phone application security control, and in particular to a multi-level cloud phone application security management and control method and device. Background Art

[0002] As an emerging service model, cloud virtual phones provide users with a solution to run the Android operating system without physical devices. Users can access virtual phones through cloud services to install, use and manage applications. However, current technologies are relatively limited in terms of the security of cloud phone applications.

[0003] The cloud phone platform itself does not directly provide application security functions, but integrates with partners or customized application store APPs to ensure that the applications downloaded by users are safe and reliable. These application stores have built-in security scanning and quality monitoring mechanisms to review every application on the shelves. Users can only download and install applications through these certified application stores. Such measures provide users with a safe application download environment, thereby ensuring the safety of cloud phone applications.

[0004] Regarding the application security control capabilities that rely on the application market, the shortcomings of the existing technology are: Single source risk: If the application market itself has security vulnerabilities or is controlled by attackers, the applications distributed through the market may bring security risks. Browser download: Users can download compliant browsers through the application store, but various applications can be downloaded through the browser, which can bypass the security control of the application store. Update dependency: The application security of cloud phones is highly dependent on the timeliness of application market updates. If the application market updates are delayed, the best time to fix key security vulnerabilities may be missed. Restricted diversity: Users can only download applications from designated application markets, which limits the diversity of user choices and may affect user experience. Inability to constrain in-application access: The platform can only constrain the installation and use of applications, but if risky websites are accessed and used within the application, it cannot be constrained. In addition, regarding the application blacklist for partners, the shortcomings of the existing technology are: Risk omission: The manually set blacklist will not be able to cover all risky applications due to the inability to update in time. Weak business flexibility: The business scenarios of partners are diverse, and the blacklist settings applicable to one type of scenario may not meet the needs of another type of scenario, resulting in the inability to meet the business expansion and diversity of partners. Excessive restrictions: Due to the risk of one cloud phone product among the partners, all cloud phone products of the entire partner are prohibited from using related applications, which may affect the user experience and the interests of the partners. Difficulty in maintaining: As the number of cloud phone products increases, maintaining a single blacklist may become complicated and difficult to respond to changes in security threats in a timely manner. Inability to restrict in-app access: The platform can only restrict the installation and use of applications, but if risky websites are accessed and used within the application, it cannot be restricted.

[0005] Therefore, a multi-level cloud phone application security management method is provided to solve the above problems. Summary of the invention

[0006] The present invention aims to provide a cloud phone application security management and control method and system based on a multi-level structure to solve the technical problems that the current cloud phone application blacklist types are single and cannot cope with the risk of various complex applications, the inability to restrict in-application access within the cloud phone, and even the inability to restrict access to risky websites within the application, and the increased risk of application use due to security vulnerabilities in the application market itself or the risk of being controlled by attackers. The technical problems to be solved by the present invention are achieved through the following technical solutions.

[0007] The first aspect of the present invention proposes a multi-level cloud phone application security management and control method, which is applied to cloud phone business processing for online privacy communication, including: configuring application list constraint mechanisms at different levels, specifically including: updating the configured application black and white lists, filtering package names according to the package names in the updated application black and white lists, and performing application version control; according to the configured application list constraint mechanisms at different levels, simultaneously constraining the applications of partners of cloud phone business services and cloud phone products; based on the cloud phone access domain name, controlling the in-application access behavior of the cloud phone itself; when the current application is installed or the user enters the cloud phone, the cloud phone server determines whether the application black and white list is the latest application black and white list, and determines whether the current application or the installed application belongs to the latest application black and white list, so as to determine whether the current application is allowed to be installed and used on the corresponding cloud phone.

[0008] The second aspect of the present invention proposes a multi-level cloud phone application security management and control device, which adopts the multi-level cloud phone application security management and control method described in the first aspect of the present invention, and the device includes: a configuration module, which is used to configure application list constraint mechanisms at different levels, specifically including: updating the configured application black and white lists, filtering package names according to the package names in the updated application black and white lists, and performing application version control; a constraint module, which constrains the applications of partners of cloud phone business services and cloud phone products at the same time according to the configured application list constraint mechanisms at different levels; a control module, which controls the in-application access behavior of the cloud phone itself based on the cloud phone access domain name; a determination module, when the current application is installed or the user enters the cloud phone, the cloud phone server determines whether the application black and white list is the latest application black and white list, and determines whether the current application or the installed application belongs to the latest application black and white list, so as to determine whether the current application is allowed to be installed and used on the corresponding cloud phone.

[0009] The third aspect of the present invention provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the multi-level cloud phone application security management method described in the first aspect of the present invention.

[0010] The fourth aspect of the present invention provides a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, the multi-level cloud phone application security management and control method described in the first aspect of the present invention is implemented.

[0011] The embodiments of the present invention include the following advantages:

[0012] Compared with the prior art, the present invention configures application list constraint mechanisms at different levels, and according to the configured application list constraint mechanisms at different levels, constrains the applications of partners of cloud phone business services and cloud phone products at the same time; based on the cloud phone access domain name, controls the in-application access behavior of the cloud phone itself; when the current application is installed or the user enters the cloud phone, the cloud phone server determines whether the application black and white list is the latest application black and white list, and determines whether the current application or the installed application belongs to the latest application black and white list, so as to determine whether the current application is allowed to be installed and used on the corresponding cloud phone, which can more effectively realize the security management and control of cloud phone applications.

[0013] In addition, by supporting the monitoring and interception of access requests for various network protocols, it can ensure that any form of illegal or unsafe access can be discovered and blocked in a timely manner.

[0014] In addition, by decrypting traffic and checking the requested target domain name based on a domain blacklist or URL blacklist, hidden network threats can be accurately identified and cloud phone applications can be blocked from accessing malicious websites. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a flowchart of an example of a multi-level cloud phone application security management and control method of the present invention;

[0016] Figure 2 It is a schematic diagram of an application example of a multi-level application list configured in the multi-level cloud phone application security management and control method of the present invention;

[0017] Figure 3 It is a structural block diagram of the multi-level cloud phone application security management and control device of the present invention;

[0018] Figure 4 is a schematic structural diagram of an electronic device embodiment according to the present invention;

[0019] Figure 5 It is a schematic diagram of the structure of a computer-readable medium embodiment according to the present invention. DETAILED DESCRIPTION

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

[0021] In view of the above problems, the present invention proposes a multi-level cloud phone application security management and control method and device. This method configures different levels of application list constraint mechanisms, and according to the configured different levels of application list constraint mechanisms, constrains the partners of cloud phone business services and the applications of cloud phone products at the same time; based on the cloud phone access domain name, controls the in-application access behavior of the cloud phone itself; when the current application is installed, the cloud phone service determines whether the application blacklist and whitelist is the latest application blacklist and whitelist, and determines whether the current application belongs to the latest application blacklist and whitelist, so as to determine whether the current application is allowed to run on the corresponding cloud phone, which can more effectively realize the cloud phone application security management and control.

[0022] In addition, based on the existing technology, the present invention further enriches the types of application lists and adds configuration levels. It configures different application black and white lists for the partners of cloud phone business services and the cloud phone products under the names of the partners, and supports the control of the URLs accessed by applications in the cloud phone, so as to more flexibly and comprehensively support the security needs of business scenarios.

[0023] Example 1

[0024] Refer to the following Figure 1 and Figure 2 , the contents of the present invention will be described in detail.

[0025] Figure 1 It is a step flow chart of an example of the multi-level cloud phone application security management and control method of the present invention.

[0026] like Figure 1 As shown, in step S101, different levels of application list constraint mechanisms are configured, specifically including: updating the configured application black and white lists, filtering package names according to the package names in the updated application black and white lists, and performing application version control.

[0027] In a specific application example, the cloud phone business processing applied to online private communication is specifically applied to the operation platform, which is an operation platform that can interact with the client and the cloud service end respectively. The cloud service end provides cloud phone business services for private communication between partners and clients, and the operation platform performs security management and control on cloud phone applications. The operation platform includes a user identity authentication module and a configuration module. The user identity authentication module is responsible for ensuring that only verified clients (such as a certain user) can access the cloud phone background operation service, and can perform relevant configurations. The configuration module is responsible for configuring application black and white lists for partners that cooperate with the operation platform and cloud phone products set by each partner, specifically application blacklists and application whitelists. The application blacklist contains a blacklist list, and the application whitelist contains a whitelist list. The multi-level application list constraint mechanism includes the configuration of multi-level application lists, specifically including application blacklists and application whitelists. For details, please refer to Figure 2 .

[0028] For applications in the application blacklist, installation and use on the corresponding cloud phone is prohibited. For applications in the application whitelist, only applications in the whitelist are allowed to be installed and used on the corresponding cloud phone. If they are different from the applications in the whitelist, installation and use are not allowed. Specifically, the blacklist and whitelist management of applications of partners and cloud phone products is carried out through application package names to ensure that only authorized applications are allowed to be installed and used on the cloud phone.

[0029] Specifically, a multi-level application list constraint mechanism is set up corresponding to the partners of the cloud phone business services and the cloud phone products.

[0030] For the multi-level application list constraint mechanism, a multi-level application list constraint mechanism is configured according to the usage scenarios of the partners and the target customer groups of the cloud phone products. The multi-level application list constraint mechanism includes creating a blacklist and a whitelist. An application blacklist and a whitelist are created for each partner. The applications in the blacklist and the whitelist are applications that are prohibited from being installed and used on the corresponding cloud phone, and the applications in the whitelist are applications that are allowed to be installed and used on the corresponding cloud phone.

[0031] Each application ID of each partner corresponds to only one blacklist ID or one whitelist ID; each application ID of each cloud phone product corresponds to only one blacklist ID or one whitelist ID; the application package name is used as each application ID.

[0032] Each application has a unique package name (Package Name) as the identification of the application in the operation platform. The configuration module can accurately identify and manage each application by parsing the application package name. When the package name is configured in the whitelist, the operation platform will only allow applications with the specified package name to be installed and run on the cloud phone. When the package name is configured in the blacklist, specific applications (such as which applications) will be prohibited from being installed or run.

[0033] For the application whitelist constraint mechanism, an application whitelist is configured. All application package names in the application whitelist will be allowed to be installed and run on the cloud phone. Users can only use applications in the cloud phone environment through the package names or application versions in the application list. Any application not in the application whitelist will be automatically blocked from installation or use.

[0034] Optionally, a configured application whitelist is used to perform package name filtering.

[0035] Specifically, the configuration module accurately matches applications based on the application package name to ensure that only specific applications can be installed. To increase flexibility, the whitelist also supports configuration by developer signature, allowing only applications released by specific developers to be installed.

[0036] For the application blacklist constraint mechanism, an application blacklist is configured, and all application package names in the application blacklist will be prohibited from being installed in the cloud phone. Even if the application is installed through other means (such as manually downloading the APK file), as long as its package name appears in the application blacklist, the system will block its installation.

[0037] Specifically, the configured application blacklist is used for dynamic package name monitoring. For some applications installed through dynamic loading mechanisms (such as using the APK dynamic merging function, reflection technology, or dynamic packaging methods of some malicious applications), the configuration module will also obtain the package name declared by the application by, for example, checking the package attribute in the AndroidManifest.xml file after the APK file is decompressed, and checking whether there is a class path consistent with the declared package name in the classes.dex file to identify the application package name, and strictly screen these "disguised" applications to ensure that all problematic applications (including "disguised" applications) are accurately identified.

[0038] The following technical means are used to determine whether the application package name has been disguised. Specifically, it includes package name verification when running the current application, confirming whether the class path actually loaded by the current application conforms to the expected package name structure, and comparing the application package name of the current application with the application package name in the self-built threat intelligence library to determine whether it is a risky application.

[0039] Specifically, the complete information of the application is obtained by dynamically calling PackageManager to confirm whether the application package name recorded when the current application is installed is consistent with the application package name loaded at runtime.

[0040] We further monitor the class loader behavior through the memory analysis tool Xposed to confirm whether the class path actually loaded by the current application conforms to the expected package name structure. We check whether there are unexpected class paths (such as dynamically generated paths or reflectively loaded classes). We identify whether there is a risk of bypassing the application package name check.

[0041] Then compare the application package name of the current application with the threat intelligence library (for example, add risky applications identified by the operation platform on the basis of VirusTotal and Google PlayProtect databases to build a threat intelligence library), check whether the current application is in the application blacklist of the threat intelligence library, and compare the application package name of the current application with the application package name in the self-built threat intelligence library to determine whether it is a risky application.

[0042] Alternatively, if some malicious application package names change frequently, they can be identified through behavioral pattern and feature matching.

[0043] Regarding permission requests and behavior pattern analysis, malicious apps usually request permissions that do not match their functions, or access sensitive resources under certain conditions. For the above situations, statistical methods and probability models can be used to describe the anomalies of permission requests and behavior patterns to determine whether the current application is a normal application.

[0044] A probability distribution model is used to describe the anomalies of permission requests and behavior patterns.

[0045] Assume that the permission request pattern of an application is a random process. P(.) represents each permission p requested by the application. i Assume that P = {p1, p2, ..., pn} is a permission set, where p i represents the probability that the i-th permission is requested.

[0046] Under normal circumstances, the probability distribution of permission requests is known (for example, within a certain probability range, such as 10% to 30%), and can be modeled through historical data (permission request data marked with access probability) to construct a probability distribution model p normal , and use the constructed probability distribution model to determine the permission request pattern of legitimate applications.

[0047] If the permission request pattern of the current application is consistent with the probability distribution model p normal If the distribution of is significantly different, it can be determined as an abnormal permission request mode, that is, it can be determined as an abnormal application.

[0048] The following expression is used to calculate the permission request mode and probability distribution model p of the current application: normal The abnormality degree YD between the distribution of (i.e., the permission request pattern of normal applications).

[0049]

[0050] Among them, YD represents the permission request mode of the current application and the probability distribution model p normal The abnormality between the distribution of (i.e., the permission request pattern of normal applications); app (p i ) indicates that the current application requests permission p i The probability of normal (p i ) is the probability distribution corresponding to normal application. Among them, p app (p i ) is calculated as follows: For a permission p i , count all apps requesting this permission p i Frequency (e.g., statistics of all applications requesting this permission within a specified historical period of one week, two weeks, four weeks, two months, six months, etc.) i frequency). Assume that there are N apps Sample applications, record the permission list they request app1 ,P app2 ,...,P appN . Calculate the number of applications requesting this permission i The request probability can be expressed as follows:

[0051]

[0052] Among them, p app (p i ) indicates that the current application requests permission p i The probability of 1(p i ∈P appj ) is the indicator function. When application j requests permission p i When 1(p i ∈P appj )=1, and when the application does not request permission p i When 1(p i ∈P appj ) = 0. For example, if 100 applications are analyzed, 30 of them request permission p1, then

[0053]

[0054] If the calculated abnormality exceeds a specified threshold (usually in the range of 0.7 to 0.9), it is marked as a malicious application.

[0055] If the calculated abnormality is less than the specified threshold, it is marked as a normal application. Threshold setting is a dynamic and optimized process. It depends on the method of abnormality calculation, data distribution characteristics, system requirements, and tolerance for false positives and false negatives. In actual applications, the threshold can be gradually adjusted and optimized through experiments and historical data analysis.

[0056] In another optional embodiment, the abnormality of the permission request is quantified using, for example, mean and variance (based on statistics). The abnormality of the permission request, i.e., the abnormality score F, is calculated using the following expression: 异常 .

[0057]

[0058] Among them, F 异常 Indicates the abnormality of the permission request of the current application, that is, the abnormality score; x i is the number or frequency of times the current application requests a specific permission, x i The subscript i in x represents the number or frequency of permission requests of the i-th application. i It represents the number of times or frequency that the i-th application requests a specific permission (such as camera permission, location permission, etc.). Here i is an index, indicating the application to which the value corresponds. μ is the mean of all applications requesting a specific permission, and σ is the standard deviation of all applications requesting a specific permission. The specific permission is, for example, a specific permission for a cloud phone business service (specifically, a cloud phone business service that the cloud service end provides for private communication between partners and clients).

[0059] When the anomaly score F 异常 When a certain threshold is exceeded (the anomaly score exceeds 1.5 to 3 standard deviations), the behavior of the application is considered to have significantly deviated from the normal pattern and the current application is judged to be an abnormal application.

[0060] When the anomaly score F 异常 When it is less than a specific threshold, the current application is determined to be a normal application.

[0061] In another optional embodiment, reflection and dynamic loading detection are used to determine abnormal applications or malicious applications.

[0062] Specifically, malicious applications dynamically load classes, methods, or resources through reflection technology, which changes their behavior. When reflection calls detect dynamic loading, malicious applications use reflection to call classes and methods. You can detect it through the API call frequency to quantify the frequency of reflection calls in the detected application.

[0063] Use the following expression to calculate the reflection call frequency of the current application:

[0064]

[0065] Among them, L 频率 Indicates the reflection call frequency of the current application when the application is started, or within a specified time period (for example, 10 seconds, 60 seconds, 120 seconds) calculated from the start of the application; C 当前 Indicates the number of reflection calls of the current application when the application is started, or within a specified time period (for example, 10 seconds, 60 seconds, or 120 seconds) calculated from the start of the application; C 总 Indicates the total number of reflection calls of all applications within a specified time period (for example, 10 seconds, 60 seconds, or 120 seconds from the current time) calculated forward from the start of the current application.

[0066] When the calculated reflection call frequency L 频率 When the frequency is greater than or equal to a specified frequency (for example, the specified frequency is determined according to the application scenario and the tolerance, specifically 0.1 to 0.5), the current application is determined to be a malicious application or an abnormal application.

[0067] When the calculated reflection call frequency L 频率 When the frequency is less than a specified frequency (for example, the specified frequency is determined according to the application scenario and tolerance), the current application is determined to be a normal application.

[0068] Preferably, the threshold of the reflection call frequency is between 0.1 and 0.3, wherein 0.1 is suitable for scenarios that are more sensitive to reflection calls, mainly detecting mild malicious behavior or hidden malicious behavior. 0.2 is suitable for general application scenarios, detecting potential malicious applications or abnormal reflection calls in some complex applications. 0.3 or higher is suitable for high-risk environments, indicating a high frequency of reflection calls, which is usually a strong indication of malicious applications.

[0069] It should be noted that the frequency of reflection calls can be used as an indicator of malicious behavior, especially for applications that frequently perform reflection calls when the application is started. The above is only described as an optional example and cannot be understood as a limitation of the present invention.

[0070] Preferably, the client periodically checks whether the application blacklist and whitelist are updated.

[0071] In an optional implementation, the application package name identifier of the current application is parsed, and the package name is filtered to determine whether it is an application that is allowed to be installed or run in the application blacklist or whitelist.

[0072] After the package name is filtered, application version control is performed based on the application package name identifier and application version number, so that the applications in the cloud phone are always within a safe version range.

[0073] It should be noted that in the present invention, the blacklist and whitelist configuration of each application is not limited to the package name itself, but can also be further controlled according to the version number (Version Code and Version Name). For example, applications of a certain version and above can be allowed to be installed, or applications below a certain version can be prohibited from being installed to ensure that the applications in the cloud phone are always within a safe version range. The above is only explained as an optional example and cannot be understood as a limitation of the present invention.

[0074] Next, in step S102, according to the application list constraint mechanism at different levels, constraints are imposed on the partners of the cloud phone business service and the applications of the cloud phone products at the same time.

[0075] Specifically, both the application blacklist and the application whitelist include creation and activation. After creation, the corresponding application blacklist or the corresponding application whitelist needs to be activated to take effect.

[0076] For list creation rules, if you set a blacklist or whitelist for a partner, you can only create one list, either a blacklist or a whitelist. You cannot create a blacklist and a whitelist at the same time to avoid conflicts.

[0077] If you set an application blacklist or whitelist for the same cloud phone product, you can only create one list, either a blacklist or a whitelist. You cannot create both a blacklist and a whitelist at the same time to avoid conflicts. Based on the relationship between partners and cloud phone products, when conflicts occur between application list constraint mechanisms at different levels for the same cloud phone, only the application list constraint mechanism with the highest priority will be allowed to take effect based on the conflict strategy.

[0078] For a partner, the partner includes multiple cloud phone products. After creating application lists for the partner and each of the partner's cloud phone products respectively, in order to avoid conflicts when activating the effective application list, the list activation rules will judge the conflicts between the activation lists based on the application package name identifier and the application version number. If it is determined that a conflict occurs, the new list will not be allowed to be activated.

[0079] For example, if the operating platform creates an application whitelist for a partner, then only cloud phones of all cloud phone products under the partner's name are allowed to install applications on the whitelist. At this time, if the application blacklist of a cloud phone product under the partner's name is newly enabled, and the applications in the application blacklist overlap with the applications in the partner's application whitelist, a conflict will occur and the application blacklist of the cloud phone product will not be allowed to be enabled.

[0080] For example, the operator first creates and enables an application whitelist for cloud phone product A, which includes application a. This means that cloud phone product A only allows the installation and use of application a, and does not allow the installation and use of other applications. At this time, the operator creates an application blacklist for cloud phone product A, which includes application a. This means that cloud phone product A does not allow users to install and use application a. This creates a conflict with the application whitelist created previously, and the application blacklist is not allowed to be created.

[0081] For the list activation rule, specifically, if there is an activated application blacklist, all application blacklists will take effect at the same time.

[0082] When a partner's application blacklist is newly enabled, the entire application whitelist (if any) of the partner and all cloud phone products under its name that have been enabled will be automatically compared. If the application package name and application version number in the newly enabled list overlap with those in the enabled list, the application will not be allowed to be enabled.

[0083] When the application blacklist of a new cloud phone product is enabled, it will be automatically compared with the enabled partner whitelist (if any). If there are overlapping applications, activation will not be allowed.

[0084] When a partner's application whitelist is newly enabled, it will be automatically compared with all the blacklists (if any) enabled for the partner and all the cloud phone products under its name. If there are overlapping applications, activation will not be allowed. It is also necessary to compare all the whitelists (if any) enabled for all the cloud phone products under the partner's name. If the partner's application whitelist does not include applications in the enabled list, activation will not be allowed.

[0085] When the application whitelist of a cloud phone product is newly enabled, it is compared with the application blacklist of the enabled partner (if any). If there is an application that overlaps with the current application, the activation fails. The application whitelist of the enabled partner (if any) must also be compared. If the partner's application whitelist does not include the application in the newly enabled list, activation is not allowed.

[0086] Preferably, it is dynamically checked whether there is unauthorized code injection, dynamically loaded classes or unknown external libraries, and it is confirmed whether constraints are implemented according to the application list constraint mechanism.

[0087] It should be noted that the above is only described as an optional example and should not be understood as a limitation to the present invention.

[0088] Next, in step S103, based on the cloud phone access domain name, the in-application access behavior of the cloud phone itself is controlled.

[0089] In a specific implementation, a scanning and uninstalling module is used to scan the applications in the cloud phone to identify whether the currently installed application or the installed application matches the application in the application blacklist or the application in the application whitelist. As long as there is an overlapping matching result with the application in the application blacklist, the application installation is rejected or the installed application is uninstalled.

[0090] For scanning and verification, each installed application will be scanned one by one to confirm whether there are any overlapping matching results with the applications in the current application blacklist and whitelist. Whenever the cloud phone's application list changes (such as adding, updating or uninstalling), the package name of each application will be automatically compared with the application list in the application blacklist and whitelist to confirm whether there are any overlapping matching results with the applications in the current application blacklist and whitelist, so as to ensure that each application to be installed meets the requirements, so that the cloud phone application security management can be more effectively realized.

[0091] Optionally, perform a signature verification. For example, perform a signature verification (specifically, application signature verification) on the application to be installed (i.e., the current application). For example, perform a signature verification based on the application signature and signature information (such as version number) of the application to be installed to confirm that the application to be installed is in the application list of the application whitelist (i.e., there is a matching result for overlapping applications) and that the version number is within the specified version range. When the matching result is that there is no overlapping application, it is confirmed that the application to be installed is at risk, and corresponding uninstallation or installation prohibition measures are taken.

[0092] Based on the unique identifier of each application (specifically the application package name), each installed application will be scanned one by one to confirm whether it matches the blacklist or whitelist in the latest application blacklist or whitelist.

[0093] Whenever the cloud phone's application list changes, the package name of each application is automatically compared with the application list in the application blacklist and whitelist, including the following changes: addition, update or uninstallation.

[0094] Specifically, when the pending client installs the current cloud phone application for the first time, and / or when the pending client enters the current cloud phone application, the scanning mechanism is triggered to determine whether the current cloud phone application has risks based on the latest application blacklist and whitelist. For risky applications, the application is refused to be installed or uninstalled.

[0095] Dynamically check for application packages that are not downloaded from the app store.

[0096] For example, when a user enters the cloud phone to use an application or when a user installs a new application, the application scanning mechanism will be triggered.

[0097] Furthermore, the administrator of the operation platform can configure a domain name blacklist and a website blacklist to list all domain names and websites that are considered to be security risks, illegal or unauthorized. Risk and fraud identification is carried out based on the domain name blacklist and website blacklist, and the domain names and websites on the domain name blacklist and website blacklist will be regarded as "restricted resources", which will automatically block all applications in the cloud phone from accessing these websites.

[0098] It should be noted that, in order to improve the flexibility of the blacklist, it is also supported to use wildcards (such as *.example.com) for domain name matching, so that the blacklist can cover all subdomains under a specific domain name. The above is only described as an optional example and cannot be understood as a limitation of the present invention.

[0099] Next, in step S104, when the current application is installed, the cloud phone server determines whether the application blacklist and whitelist is the latest application blacklist and whitelist, and determines whether the current application belongs to the latest application blacklist and whitelist to determine whether the current application is allowed to run on the corresponding cloud phone.

[0100] Specifically, when the current application is installed, the cloud phone server determines whether the application blacklist is the latest application blacklist and whether the application whitelist is the latest application whitelist. Specifically, by determining whether the current application belongs to the latest application whitelist, when it is determined that the current application belongs to the latest application whitelist, it is determined to allow the current application to run on the corresponding cloud phone.

[0101] When it is determined that the current application does not belong to the latest application whitelist and the current application belongs to the latest application blacklist, it is determined that the current application is prohibited from running on the corresponding cloud phone.

[0102] In an optional implementation, it also includes automatically monitoring external requests issued by each application. Specifically, each application in the cloud phone will issue external HTTP / HTTPS requests during operation. These HTTP / HTTPS requests are, for example, requests to access Web services, download resources, or conduct remote communications. Specifically, these external requests are automatically monitored to identify the target domain name and URL of each request. According to the domain name blacklist and URL blacklist, the access target is compared to determine whether it is a prohibited domain name or URL.

[0103] When it is determined that the target domain name or URL of the current application's access request is in the domain name blacklist or URL blacklist, the current application's access request will be immediately intercepted and the current application will be prevented from further accessing the prohibited address. For example, the blocking measures may include returning an error message, disconnecting, or forcibly terminating the current application's network request behavior.

[0104] In another optional implementation, the cloud phone application can use HTTP / HTTPS protocol to make network requests, and can also communicate with external servers through other protocols (such as FTP, WebSocket, DNS requests, etc.). Therefore, comprehensive protection can be achieved, and access requests for various network protocols can be monitored and intercepted, ensuring that any form of illegal or unsafe access can be discovered and blocked in a timely manner.

[0105] Optionally, log records and real-time feedback are also included. When the current application attempts to access a domain name or URL in the domain blacklist or URL blacklist, an access log will be automatically generated and recorded in real time in the management background. The log will record the blocked access behavior in detail, including the blocked domain name, application package name, blocking time, blocking reason and other information. In addition, the access log also records all key operations and specific events. Through real-time reporting, administrators can clearly see which applications have initiated non-compliant access requests, which is convenient for subsequent security audits and troubleshooting.

[0106] When an application in the cloud phone frequently accesses a blacklisted URL, or has multiple accesses blocked, an alarm notification can be sent to the administrator via SMS or other tools. The administrator can identify potential security risks based on the alarm information and take timely countermeasures.

[0107] In another optional implementation, dynamic URL access interception is performed. External resources are obtained by dynamically loading URLs, especially in application scenarios such as advertising, push notifications, and social media. Applications often dynamically generate URLs based on external needs. If these dynamically generated URLs are included in domain names or URLs in a domain blacklist or URL blacklist, these requests will be identified and intercepted, ensuring the network security of the cloud phone even if these URLs are temporarily generated.

[0108] Malicious websites or attacks can hide their true targets through encryption protocols (such as HTTPS). To prevent this from happening, we support in-depth analysis and interception of URLs in encrypted traffic by combining technologies such as DNS resolution and SSL certificate verification. By decrypting traffic and checking the target domain name of the request, we can accurately identify hidden network threats and prevent cloud phone applications from accessing malicious websites.

[0109] It should be noted that in the present invention, especially in certain specific cloud phone application scenarios (such as cloud games, enterprise applications, etc.), the network access of the cloud phone is isolated to avoid interference of URL requests between applications. By implementing domain name isolation in the virtual environment, it can be ensured that different applications will not affect each other during network access, thereby enhancing security. The above is only explained as an optional example and cannot be understood as a limitation of the present invention.

[0110] In addition, the drawings are only schematic illustrations of the processes included in the method according to an exemplary embodiment of the present invention, and are not intended to be limiting. It is easy to understand that the processes shown in the drawings do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0111] Compared with the prior art, the present invention configures application list constraint mechanisms at different levels, and according to the configured application list constraint mechanisms at different levels, constrains the applications of partners of cloud phone business services and cloud phone products at the same time; based on the cloud phone access domain name, controls the in-application access behavior of the cloud phone itself; when the current application is installed, the cloud phone server determines whether the application black and white list is the latest application black and white list, and determines whether the current application belongs to the latest application black and white list, so as to determine whether the current application is allowed to run on the corresponding cloud phone, which can more effectively realize the security management and control of cloud phone applications.

[0112] In addition, by supporting the monitoring and interception of access requests for various network protocols, it can ensure that any form of illegal or unsafe access can be discovered and blocked in a timely manner.

[0113] In addition, by decrypting traffic and checking the requested target domain name based on a domain blacklist or URL blacklist, hidden network threats can be accurately identified and cloud phone applications can be blocked from accessing malicious websites.

[0114] Example 2

[0115] The following are embodiments of the device of the present invention, which can be used to implement the method embodiments of the present invention. For details not disclosed in the device embodiments of the present invention, please refer to the method embodiments of the present invention.

[0116] Figure 3 It is a structural diagram of an example of a multi-level cloud phone application security management and control device of the present invention.

[0117] Reference Figure 3 The second aspect of the present disclosure provides a multi-level cloud phone application security management and control device, which adopts the multi-level cloud phone application security management and control method described in the first aspect of the present invention.

[0118] Specifically, the multi-level cloud phone application security management and control device 300 includes a configuration module 310, a constraint module 320, a control module 330 and a determination module 340.

[0119] In a specific embodiment, the configuration module 310 is used to configure different levels of application list constraint mechanisms, specifically including: updating the configured application black and white lists, filtering package names according to the package names in the updated application black and white lists, and performing application version control. The constraint module 320 constrains the applications of partners of the cloud phone business service and cloud phone products at the same time according to the configured application list constraint mechanisms of different levels. The control module 330 controls the in-application access behavior of the cloud phone itself based on the cloud phone access domain name. The determination module 340 determines whether the application black and white list is the latest application black and white list when the current application is installed or the user enters the cloud phone, and determines whether the current application or the installed application belongs to the latest application black and white list to determine whether the current application is allowed to be installed and used on the corresponding cloud phone.

[0120] The cloud phone business processing applied to online privacy communication specifically includes a cloud service end, an operation platform, and a client end. The cloud service end provides cloud phone business services for privacy communication between partners and clients, and the operation platform performs security management and control on cloud phone applications. A multi-level application list constraint mechanism is configured corresponding to the partners of the cloud phone business service and the cloud phone products. The multi-level application list constraint mechanism is configured according to the usage scenarios of the partners and the target customer groups of the cloud phone products. The multi-level application list constraint mechanism includes creating a blacklist and a whitelist, and creating an application blacklist and whitelist for each partner. The applications in the application blacklist and whitelist are applications that are prohibited from being installed and used on the corresponding cloud phone, and the application whitelist is applications that are allowed to be installed and used on the corresponding cloud phone.

[0121] Each application ID of each partner corresponds to only one blacklist ID or one whitelist ID; each application ID of each cloud phone product corresponds to only one blacklist ID or one whitelist ID; the application package name is used as each application ID.

[0122] Based on the conflict strategy, only the application list constraint mechanism with the highest priority is allowed to take effect.

[0123] According to an optional implementation method, conflict judgment is performed based on the list type, application package name identifier, and application version number. The conflict strategy judgment includes that the operation platform creates a corresponding application whitelist for each cloud phone product. In this case, only applications in the application whitelist of each cloud phone product are allowed to be installed, and applications in the application whitelist of each cloud phone product are not allowed to be used as applications for creating an application blacklist.

[0124] When it is determined that there is a conflict between the application blacklist and the application whitelist created or enabled by the operation platform, only the original application list is enabled, and the new application list is not allowed to be enabled.

[0125] According to an optional implementation manner, the client periodically checks whether to update the application blacklist and whitelist.

[0126] When the pending client installs the current cloud phone application for the first time, and / or when the pending client enters the current cloud phone application, the scanning mechanism is triggered to determine whether the current cloud phone application has risks based on the latest application blacklist and whitelist. For risky applications, the application is refused to be installed or uninstalled.

[0127] Dynamically check for application packages that are not downloaded from the app store.

[0128] According to an optional implementation, based on the unique identifier of each application, each installed application is scanned one by one to confirm whether it matches the blacklist or whitelist in the latest application blacklist or whitelist.

[0129] Whenever the cloud phone's application list changes, the package name of each application is automatically compared with the application list in the application blacklist and whitelist, including the following changes: addition, update or uninstallation.

[0130] The steps of determining whether the current application is a normal application include:

[0131] If the permission request pattern of the current application is consistent with the probability distribution model p normal If the distribution of is significantly different, it can be determined as an abnormal permission request mode, that is, it can be determined as an abnormal application;

[0132] The following expression is used to calculate the permission request mode and probability distribution model p of the current application: normal The abnormality degree YD between the distribution of (i.e., the permission request pattern of normal applications).

[0133]

[0134] Among them, YD represents the permission request mode of the current application and the probability distribution model p normal The abnormality between the distribution of (i.e., the permission request pattern of normal applications); app (p i ) indicates that the current application requests permission p i The probability of normal (p i ) is the probability distribution corresponding to normal application.

[0135] According to an optional implementation, it is dynamically checked whether there is unauthorized code injection, dynamically loaded classes or unknown external libraries, and it is confirmed whether constraints are implemented according to the application list constraint mechanism.

[0136] According to an optional implementation method, when the enabled blacklist is the application blacklist of the partner, it is automatically compared with all enabled whitelists. When it is determined that there are overlapping applications, the activation fails; when the enabled blacklist is the application blacklist of the cloud phone product, it is automatically compared with the enabled partner's application whitelist. When it is determined that there are overlapping applications, the activation fails.

[0137] When the enabled whitelist is the partner's application whitelist, it is automatically compared with all enabled blacklists. If there are overlapping applications, the activation fails. When the enabled application whitelist is the cloud phone product's application blacklist, it is automatically compared with the enabled partner's blacklist. If there are overlapping applications, the activation fails.

[0138] According to an optional implementation manner, the application package name identifier of the current application is parsed, and the package name is filtered to determine whether it is an application that is allowed to be installed or run in the application blacklist or whitelist.

[0139] After the package name is filtered, application version control is performed based on the application package name identifier and application version number, so that the applications in the cloud phone are always within a safe version range.

[0140] Compared with the prior art, the present invention configures application list constraint mechanisms at different levels, and according to the configured application list constraint mechanisms at different levels, constrains the applications of partners of cloud phone business services and cloud phone products at the same time; based on the cloud phone access domain name, controls the in-application access behavior of the cloud phone itself; when the current application is installed, the cloud phone server determines whether the application black and white list is the latest application black and white list, and determines whether the current application belongs to the latest application black and white list, so as to determine whether the current application is allowed to run on the corresponding cloud phone, which can more effectively realize the security management and control of cloud phone applications.

[0141] In addition, by supporting the monitoring and interception of access requests for various network protocols, it can ensure that any form of illegal or unsafe access can be discovered and blocked in a timely manner.

[0142] In addition, by decrypting traffic and checking the requested target domain name based on a domain blacklist or URL blacklist, hidden network threats can be accurately identified and cloud phone applications can be blocked from accessing malicious websites.

[0143] It should be noted that the cloud phone application security management method executed by the multi-level cloud phone application security management device in Example 2 is the same as the multi-level cloud phone application security management method in Example 1, so the description of the same parts is omitted.

[0144] Figure 4 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

[0145] like Figure 4 As shown, the electronic device is presented in the form of a general computing device. The processor may be one or more and work in coordination. The present invention does not exclude distributed processing, that is, the processor may be dispersed in different physical devices. The electronic device of the present invention is not limited to a single entity, but may also be the sum of multiple physical devices.

[0146] The memory stores a computer executable program, which is usually a machine-readable code. The computer-readable program can be executed by the processor to enable the electronic device to perform the method of the present invention, or at least part of the steps in the method.

[0147] The memory includes a volatile memory, such as a random access memory unit (RAM) and / or a cache memory unit, and may also be a non-volatile memory, such as a read-only memory unit (ROM).

[0148] Optionally, in this embodiment, the electronic device further includes an I / O interface, which is used for the electronic device to exchange data with an external device. The I / O interface can represent one or more of several types of bus structures, including a storage unit bus or a storage unit controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of a variety of bus structures.

[0149] It should be understood that Figure 4 The electronic device shown is only an example of the present invention, and the electronic device of the present invention may also include elements or components not shown in the above examples. For example, some electronic devices also include display units such as display screens, and some electronic devices also include human-computer interaction elements such as buttons, keyboards, etc. As long as the electronic device can execute the computer-readable program in the memory to implement the method of the present invention or at least part of the steps of the method, it can be considered as an electronic device covered by the present invention.

[0150] Through the above description of the implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by combining software with necessary hardware. Figure 5 As shown, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of commands to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present invention.

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

[0152] The computer readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with a command execution system, device, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.

[0153] Program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., through the Internet using an Internet service provider).

[0154] The computer-readable medium carries one or more programs (eg, computer-executable programs). When the one or more programs are executed by a device, the computer-readable medium implements the method of the present disclosure.

[0155] Those skilled in the art will appreciate that the above modules can be distributed in the device according to the description of the embodiment, or can be changed accordingly and only used in one or more devices different from the embodiment. The modules of the above embodiments can be combined into one module, or further divided into multiple sub-modules.

[0156] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several commands to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiment of the present invention.

[0157] The exemplary embodiments of the present invention are specifically shown and described above. It should be understood that the present invention is not limited to the detailed structure, configuration or implementation method described herein; on the contrary, the present invention is intended to cover various modifications and equivalent configurations included in the spirit and scope of the appended claims.

Claims

1. A multi-level cloud phone application security management and control method, characterized in that: Cloud phone business processing for online privacy communications, including: Configure different levels of application list constraint mechanisms, including: updating the configured application blacklist and whitelist, filtering package names based on the package names in the updated application blacklist and whitelist, and performing application version control; According to the application list constraint mechanism at different levels, constraints are imposed on partners of cloud phone business services and applications of cloud phone products at the same time; Based on the cloud phone access domain name, control the in-app access behavior of the cloud phone itself; When the current application is installed or the user enters the cloud phone, the cloud phone server determines whether the application blacklist and whitelist is the latest application blacklist and whitelist, and determines whether the current application or the installed application belongs to the latest application blacklist and whitelist to determine whether the current application is allowed to be installed and used on the corresponding cloud phone.

2. The multi-level cloud phone application security management and control method according to claim 1 is characterized in that: The application list constraint mechanism of different levels is configured, including: The cloud phone business processing applied to online private communication specifically includes a cloud service end, an operation platform, and a client end. The cloud service end provides a cloud phone business service for private communication between partners and clients, and the operation platform performs security management and control on the cloud phone application. A multi-level application list constraint mechanism corresponding to the partners of the cloud phone business service and the cloud phone products is configured. The multi-level application list constraint mechanism is configured according to the usage scenarios of the partners and the target customer groups of the cloud phone products. The multi-level application list constraint mechanism includes creating a blacklist and a whitelist. An application blacklist and a whitelist are created for each partner. Applications in the blacklist and the whitelist are applications that are prohibited from being installed and used on the corresponding cloud phone, and applications in the whitelist are applications that are allowed to be installed and used on the corresponding cloud phone; Each application ID of each partner corresponds to only one blacklist ID or one whitelist ID; each application ID of each cloud phone product corresponds to only one blacklist ID or one whitelist ID; the application package name is used as each application ID; Based on the conflict strategy, only the application list constraint mechanism with the highest priority is allowed to take effect.

3. The multi-level cloud phone application security management and control method according to claim 2 is characterized in that: Further including: Conflicts are judged based on the list type, application package name identifier, and application version number. The conflict strategy judgment includes that the operation platform creates a corresponding application whitelist for each cloud phone product, then only the applications in the application whitelist of each cloud phone product are allowed to be installed, and the applications in the application whitelist of each cloud phone product are not allowed to be used as applications for creating an application blacklist; When it is determined that there is a conflict between the application blacklist and the application whitelist created or enabled by the operation platform, only the original application list is enabled, and the new application list is not allowed to be enabled.

4. The multi-level cloud phone application security management and control method according to claim 2 is characterized in that: Further including: The client periodically checks whether the application blacklist and whitelist are updated; When the pending client installs the current cloud phone application for the first time, and / or when the pending client enters the current cloud phone application, the scanning mechanism is triggered to determine whether the current cloud phone application has risks based on the latest application blacklist and whitelist. For risky applications, the installation of the application is refused or the application is uninstalled; Dynamically check for application packages that are not downloaded from the app store.

5. The multi-level cloud phone application security management and control method according to claim 1 is characterized in that: Further including: Based on the unique identifier of each application, each installed application will be scanned one by one to confirm whether it matches the blacklist or whitelist in the latest application blacklist or whitelist; Whenever the cloud phone's application list changes, the package name of each application is automatically compared with the application list in the application blacklist and whitelist, including the following changes: addition, update or uninstallation.

6. The multi-level cloud phone application security management and control method according to claim 1 is characterized in that: Further including: The steps of determining whether the current application is a normal application include: If the permission request pattern of the current application is consistent with the probability distribution model p normal If the distribution of is significantly different, it can be determined as an abnormal permission request mode, that is, it can be determined as an abnormal application; The following expression is used to calculate the permission request mode and probability distribution model p of the current application: normal The abnormality degree YD between the distribution of (i.e., the permission request pattern of normal applications). Among them, YD represents the permission request mode of the current application and the probability distribution model p normal The abnormality between the distribution of (i.e., the permission request pattern of normal applications); app (p i ) indicates that the current application requests permission p i The probability of normal (p i ) is the probability distribution corresponding to normal application.

7. The multi-level cloud phone application security management and control method according to claim 1 is characterized in that: Further including: When the enabled blacklist is the partner's application blacklist, it will automatically compare all enabled whitelists. If it is determined that there are overlapping applications, the activation will fail; When the enabled blacklist is the application blacklist of the cloud phone product, it will automatically compare with the enabled partner's application whitelist. If it is determined that there is an overlapping application, the activation will fail; When the enabled whitelist is the partner's application whitelist, it is automatically compared with all enabled blacklists. If there are overlapping applications, the activation fails. When the enabled application whitelist is the cloud phone product's application blacklist, it is automatically compared with the enabled partner's blacklist. If there are overlapping applications, the activation fails.

8. The multi-level cloud phone application security management and control method according to claim 1 is characterized in that: Further including: Parse the application package name identifier of the current application and perform package name filtering to determine whether it is an application that is allowed to be installed or run in the application blacklist or whitelist; After the package name is filtered, application version control is performed based on the application package name identifier and application version number, so that the applications in the cloud phone are always within a safe version range.

9. A multi-level cloud phone application security management and control device, characterized in that: It implements the multi-level cloud phone application security management method according to any one of claims 1 to 8, and the cloud phone application security management device comprises: A configuration module is used to configure different levels of application list constraint mechanisms, specifically including: updating the configured application blacklist and whitelist, filtering package names according to the package names in the updated application blacklist and whitelist, and performing application version control; The constraint module constrains the partners of the cloud phone business service and the applications of the cloud phone products at the same time according to the application list constraint mechanism of different levels; The control module controls the in-application access behavior of the cloud phone itself based on the cloud phone access domain name; Determination module, when the current application is installed or the user enters the cloud phone, the cloud phone server determines whether the application blacklist and whitelist is the latest application blacklist, and determines whether the current application or the installed application belongs to the latest application blacklist to determine whether the current application is allowed to be installed and used on the corresponding cloud phone.

10. The multi-level cloud phone application security management and control device according to claim 9, characterized in that: Further including: The cloud phone business processing applied to online private communication specifically includes a cloud service end, an operation platform, and a client end. The cloud service end provides a cloud phone business service for private communication between partners and clients, and the operation platform performs security management and control on the cloud phone application. A multi-level application list constraint mechanism corresponding to the partners of the cloud phone business service and the cloud phone products is configured. The multi-level application list constraint mechanism is configured according to the usage scenarios of the partners and the target customer groups of the cloud phone products. The multi-level application list constraint mechanism includes creating a blacklist and a whitelist. An application blacklist and a whitelist are created for each partner. Applications in the blacklist and the whitelist are applications that are prohibited from being installed and used on the corresponding cloud phone, and applications in the whitelist are applications that are allowed to be installed and used on the corresponding cloud phone; Each application ID of each partner corresponds to only one blacklist ID or one whitelist ID; each application ID of each cloud phone product corresponds to only one blacklist ID or one whitelist ID; the application package name is used as each application ID; Based on the conflict strategy, only the application list constraint mechanism with the highest priority is allowed to take effect.

Images