Dynamic authority authorization and risk monitoring method and device, equipment and storage medium

Abstract

The invention relates to the technical field of authority management, in particular to an authority dynamic authorization and risk monitoring method and device, equipment and a computer storage medium. According to the method, whether the request permission is necessary or not can be intelligently judged, and automatic response is performed in a low-risk situation, so that authorized popup windows during operation are remarkably reduced, and the user experience is improved; a dynamic granularity adjustment mechanism is introduced, one-time granting of full authority is avoided, and the privacy exposure risk is reduced while normal functions are guaranteed; the method has the capability of behavior detection during operation, can identify permission abuse behaviors and give an alarm in real time based on permission use frequency, calling context and behavior sequences, and fills up the defect of hysteresis of post-event analysis in an existing scheme; the method does not depend on any machine learning framework, completely adopts system calling, state machine judgment and configuration driving, is low in resource consumption and high in adaptability, can stably run on middle-end and low-end equipment, and has the industrialization landing capability.

Description

Technical Field

[0001] The present invention relates to the technical field of rights management, and in particular to a method, apparatus, device and computer storage medium for dynamic rights authorization and risk monitoring. Background Art

[0002] In mobile operating systems, especially on the Android platform, permission management has always been a key link in system security and user privacy protection.

[0003] The shortcomings of the current Android system's permission management mechanism are mainly reflected in the following aspects: 1. Severe Interaction Interference: Permission pop-ups frequently interrupt user operations during runtime, especially in scenarios where high-frequency access is required for permissions such as location, storage, and microphone, severely impacting user experience. Frequent pop-ups over a long period of time can also easily lead to user "authorization fatigue," causing users to unthinkingly grant sensitive permissions, thus creating security risks.

[0004] 2. Rough authorization granularity: The current permission management mechanism cannot dynamically adjust the permission granularity according to the scenario. For example, location permission cannot distinguish between the two scenarios of "foreground precise positioning" and "background fuzzy positioning", resulting in excessive permissions being granted, exceeding the actual required scope.

[0005] 3. Lack of real-time analysis mechanism: Most existing solutions are based on static rules or post-log analysis. They are unable to analyze runtime behavior and assess risks when permission requests occur, and are unable to detect and intercept abnormal permission usage behaviors in a timely manner.

[0006] 4. Significant device performance constraints: Although some research projects have introduced lightweight AI models to predict permission behavior, they are still limited by practical conditions such as device computing power, system resource scheduling mechanisms, and power consumption constraints, and cannot be stably deployed on most devices, resulting in the inability to apply them on a large scale. Summary of the Invention

[0007] To this end, the technical problem to be solved by the present invention is to overcome the problems in the prior art such as poor user experience due to severe interaction interference, poor security protection due to coarse authorization granularity and lack of real-time analysis mechanism, and poor system adaptability due to large device performance constraints.

[0008] To solve the above technical problems, the present invention provides a method for dynamic authorization and risk monitoring of permissions, comprising: Preferably, intercepting the permission request and obtaining context information of the permission request; According to the permission request and its context information, a pre-built rule engine is used to match rules and determine the authorization management policy. The authorization management policy includes allowing the permission request, rejecting the permission request, delaying the permission request, adjusting the permission granularity of the permission request, and popping up a security warning window; Monitor permission call behavior in real time and trigger alarms in case of abnormal usage.

[0009] Preferably, the interception permission request includes: By instrumenting the activity management service and package management service, it intercepts sensitive permission requests including precise positioning, audio recording, and reading contacts.

[0010] Preferably, obtaining the context information of the permission request includes: Get context information including the name of the application package currently requesting permission, the foreground and background status of the application, the current window focus and whether the user is in the application interface, permission request trigger stack information, current system time, current system screen status and current system network status, and encapsulate it into a permission request context structure.

[0011] Preferably, the determining of the authorization management policy by performing rule matching based on the permission request and its context information and a pre-built rule engine includes: Build a rule engine with configurable rules; According to the permission request and its context information, a rule engine traverses the rule list to perform rule matching; In the case that a successful matching rule exists, the successful matching rule with the highest priority is determined as the current authorization management policy; In the absence of a successful matching rule, the system default policy is determined to be the current authorization management policy.

[0012] Preferably, the adjusting the permission granularity of the permission request includes: granting temporary permission, granting fuzzy permission and not making an authorization decision.

[0013] Preferably, when the authorization management policy determines that a security warning pop-up window is displayed, an instruction is obtained as to whether the user chooses to automatically process such requests, and the user preference is recorded to optimize future decisions.

[0014] Preferably, the real-time monitoring of permission call behavior and triggering an alarm in the event of abnormal usage includes: Real-time monitoring includes Binder call behavior and Logcat logs, tracking permission usage frequency, call time period, and permission call behavior information of the call source; When abnormal usage behavior is detected based on permission call behavior information, an alarm is triggered. The alarm content includes the abnormal package name, permission name, triggering rules and recommended handling methods.

[0015] The present invention also provides a device for dynamic authorization and risk monitoring of permissions, comprising: A data acquisition module, configured to intercept permission requests and obtain context information of the permission requests; A policy matching module is used to perform rule matching based on the permission request and its context information and a pre-built rule engine to determine the authorization management policy. The authorization management policy includes allowing the permission request, rejecting the permission request, delaying the permission request, adjusting the permission granularity of the permission request, and issuing a security warning pop-up window; The exception monitoring module is used to monitor permission call behavior in real time and trigger an alarm in the event of abnormal use.

[0016] The present invention also provides a device for dynamic authorization and risk monitoring of permissions, including: memory for storing computer programs; A processor is used to implement the above-mentioned steps of the method for dynamic authorization of permissions and risk monitoring when executing the computer program.

[0017] The present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned method for dynamic authorization of permissions and risk monitoring are implemented.

[0018] The above technical solution of the present invention has the following advantages over the prior art: The dynamic permission authorization and risk monitoring method described in the present invention can intelligently determine whether the requested permission is necessary and automatically respond in low-risk situations, thereby significantly reducing runtime authorization pop-ups and improving user experience; the present invention introduces a dynamic granularity adjustment mechanism to avoid granting "full permissions" at one time, reducing privacy exposure risks while ensuring normal functions; the present invention has runtime behavior detection capabilities, and can identify permission abuse behaviors and issue real-time alarms based on permission usage frequency, call context and behavior sequence, filling the shortcoming of the "post-analysis" lag in existing solutions; the present invention does not rely on any machine learning framework, and all uses system calls, state machine judgment and configuration drive, with low resource consumption, strong adaptability, can run stably on mid- and low-end devices, and has the ability to be industrialized. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to make the content of the present invention more clearly understood, the present invention is further described in detail below based on specific embodiments of the present invention in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of the implementation of a method for dynamic authorization and risk monitoring of permissions provided by the present invention; Figure 2This is a flowchart of a method for dynamic authorization and risk monitoring of permissions provided by an embodiment of the present invention; Figure 3 This is a structural block diagram of a device for dynamic authorization and risk monitoring of permissions provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] The core of the present invention is to provide a method, device, equipment and computer storage medium for dynamic authorization and risk monitoring of permissions, which effectively improves user experience, security protection and system adaptability.

[0021] In order to enable those skilled in the art to better understand the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0022] Please refer to Figure 1. Figure 1 This is a flowchart of the implementation of a method for dynamic authorization and risk monitoring of permissions provided by the present invention; the specific operation steps are as follows: S101: intercepting a permission request and obtaining context information of the permission request; S102: Based on the permission request and its context information, a pre-built rule engine is used to perform rule matching to determine an authorization management policy. The authorization management policy includes allowing the permission request, rejecting the permission request, delaying the permission request, adjusting the permission granularity of the permission request, and issuing a security alert pop-up window. S103: Monitor the permission calling behavior in real time and trigger an alarm in case of abnormal usage.

[0023] Based on the above embodiment, this embodiment describes step S101 in detail: In some embodiments, specific implementations of intercepting permission requests include: By inserting stubs in the ActivityManagerService and PackageManagerService, sensitive permission requests such as precise positioning (CCESS_FINE_LOCATION), recording (RECORD_AUDIO), and reading contacts (READ_CONTACTS) are intercepted.

[0024] In some embodiments, a specific implementation of obtaining the context information of the permission request includes: Get context information, including the name of the application package currently requesting permission, the foreground and background status of the application, the current window focus and whether the user is in the application interface, permission request trigger stack information, current system time, current system screen status and current system network status, etc., and encapsulate it into a permission request context structure (PermissionContext).

[0025] It should be noted that the foreground and background status of the application is obtained through the list of currently running application processes (ActivityManager.getRunningAppProcesses()); It should be noted that the InputManagerService is used to determine the user interaction status, obtain the current window focus, and determine whether the user is in the application interface. It should be noted that the permission request trigger stack information is obtained through Binder call chain tracking.

[0026] It should be noted that the current system time, current system screen status, and current system network status are read directly from the cache when a permission request occurs.

[0027] Based on the above embodiment, this embodiment describes step S102 in detail: In some embodiments, according to the permission request and its context information, a specific implementation method of performing rule matching based on a pre-built rule engine to determine the authorization management policy includes: Build a rule engine with configurable rules; According to the permission request and its context information, a rule engine traverses the rule list to perform rule matching; In the case that a successful matching rule exists, the successful matching rule with the highest priority is determined as the current authorization management policy; In the absence of a successful matching rule, the system default policy is determined to be the current authorization management policy.

[0028] It should be noted that the specific implementation method of building a rule engine with configurable rules is as follows: The rule engine is built using a state machine + multi-condition expression matching mechanism, including: Rule definition structure: Rules are configured in JSON or XML format, containing fields such as the rule ID (a unique identifier for the rule), applicable conditions, matching priority, and policy actions. Using JSON or XML, which are structured, easy-to-read, and easy-to-modify configuration files, security policy administrators can add, delete, or adjust permission control policies simply by editing text files without modifying system code.

[0029] Rule parser: loads configuration rules when the system starts, parses them and stores them in the rule mapping table in memory; Rule Executor: Each time a permission request is triggered, the rule table is matched item by item according to priority, the highest priority matching rule is selected, and the policy is executed.

[0030] In some embodiments, rule configuration supports online updates via OTA, and the manufacturer iterates the rule set based on actual risk trends.

[0031] The rule engine of the present invention can be updated through configuration, allowing users or system manufacturers to flexibly customize policies to adapt to different scenario requirements and has high scalability.

[0032] In some embodiments, users can customize rules, add them through the system settings portal, and write them into the local rule configuration file.

[0033] It should be noted that the specific implementation methods of performing rule matching based on the rule engine traversing the rule list include: Traverse the rule list to determine whether the matching fields (such as package name, permission type, application status, and user behavior) meet the applicable conditions. This judgment supports logical AND / OR condition combinations and multi-layer nested judgments, such as: (App is in the background AND requests the camera) OR (App is in the non-focus window AND requests positioning).

[0034] In some embodiments, the rule matching engine runs in the Binder call chain and uses an O(1) hash index to quickly match package names and permission combinations.

[0035] It should be noted that the engine size is less than 100KB, the configuration file can be tailored as needed, and it can be adapted to mid- and low-end devices without performance pressure.

[0036] In some embodiments, the system default policy is a security alert pop-up window.

[0037] In some embodiments, the authorization management policy includes: 1.GRANT_IMMEDIATE: Automatically approve immediately Meaning: The system automatically approves the permission request without user action.

[0038] Applicable scenarios: low-risk, high-frequency permission requests.

[0039] For example: a weather application in the foreground requests network permission; an input method requests vibration feedback permission.

[0040] This strategy improves user experience, reduces unnecessary pop-up window interference, and does not pose a security risk.

[0041] 2. DENY_IMMEDIATE: Automatically reject immediately Meaning: The system automatically denies the permission request without user action.

[0042] Applicable scenario: The app requests highly sensitive permissions when running in the background.

[0043] For example: a music recognition application in the background service suddenly requests to use the microphone; any behavior that requests to read contacts in the background.

[0044] This policy directly blocks the most suspicious and potentially malicious abuses of permissions and is an important line of defense for privacy protection.

[0045] 3. PROMPT_DELAYED: Delayed prompt Meaning: Instead of displaying a pop-up window immediately, wait for the right moment (such as when the user switches back to the app foreground) to request permission from the user.

[0046] Applicable scenarios: Non-urgent permission requests that require user informed consent, especially those initiated in the background.

[0047] For example, a social media app requests storage permission in the background to prepare for uploading pictures. The system will wait until the user opens the app next time to pop up a window to ask.

[0048] This strategy ensures that permission requests are relevant to the user context, improves user understanding and authorization rates, and avoids interrupting users without their knowledge.

[0049] 4. Adjust the permission granularity of the permission request, the specific implementation of which includes: (1) GRANT_TEMPORARY: Grant temporary permissions Meaning: Grants an application a time-limited permission that automatically becomes invalid after the expiration date.

[0050] Applicable scenarios: Scenarios where sensitive functions need to be used for a short period of time.

[0051] For example, a map navigation app is granted precise positioning permission "only while the app is in use" or "within the next 5 minutes." Once the time is up or the app returns to the background, the permission is automatically reclaimed.

[0052] This strategy adheres to the principle of minimizing permissions, significantly reducing the risk of privacy leaks while meeting functional requirements. This is the core embodiment of refined permission management.

[0053] (2) GRANT_COARSE_ONLY: Grant fuzzy permissions What it means: For permissions that support granular control (such as location), the system automatically downgrades to granting a coarse version rather than the precise version requested by the app.

[0054] Applicable scenarios: The app requests high-precision permissions, but its usage scenario does not require such high precision.

[0055] For example, a local news app requests precise location information to push local news. The system may automatically grant it only fuzzy location permissions (based on network base stations, with city-level accuracy), which is sufficient to meet its functionality.

[0056] This strategy maximizes the protection of users' sensitive data (such as precise GPS coordinates) while providing basic functionality.

[0057] (3) LOG_ONLY: Only logs are recorded, i.e. no authorization decisions are made Meaning: No decision is made on the permission request to approve or deny it. Instead, the permission request is recorded in detail in the security log for subsequent analysis.

[0058] Applicable scenarios: Used for collecting "risk profiles" and conducting data mining for suspicious or new permission request patterns.

[0059] For example, if a request's behavior is slightly unusual but doesn't meet the criteria for automatic rejection, the system will record "a certain application requested a certain permission at a certain time" to accumulate data for training more accurate machine learning models.

[0060] This strategy provides security teams with data support to identify potential threats and optimize automatic decision-making rules without affecting the current user experience.

[0061] It should be noted that granular control of certain permissions can be achieved through the Android system's AppOpsManager interface: For permissions that support fuzzy / precise, such as location permissions, if precise permissions are granted in the foreground, they will be automatically downgraded to fuzzy permissions in the background; For audio and sensor permissions, the permissions are suspended or temporarily closed after monitoring App lifecycle events (such as onPause() and onStop()); All dynamic changes are recorded in the log for auditing and can be read and displayed.

[0062] 5. ESCALATE_WARNING: Security warning pop-up window Meaning: This permission request is identified as a high-risk event. On the one hand, it is submitted to the security alert center, and on the other hand, a strong warning dialog box pops up to the user.

[0063] Applicable scenarios: Detecting extremely high-risk or extremely suspicious behavior patterns.

[0064] For example, a rarely used calculator app suddenly requests permission to send text messages late at night; or a newly installed app attempts to access all account information on the device. The alert pop-up might use a more eye-catching color (such as red) and a stronger warning message to alert the user.

[0065] This policy is the last and most important manual line of defense. It puts the final decision-making power in the hands of the user, but provides clear risk warnings to prevent users from unconsciously authorizing it.

[0066] This invention can intelligently determine whether requested permissions are necessary and automatically respond in low-risk scenarios, significantly reducing runtime authorization pop-ups and improving the user experience. This invention introduces a dynamic granularity adjustment mechanism to avoid granting "full permissions" at once, ensuring normal functionality while reducing privacy exposure risks. For example, navigation apps only use precise location information on the map page and automatically downgrade after leaving.

[0067] Based on the above embodiment, when the authorization management policy determines that a security alert pop-up window is displayed, the user is instructed whether to automatically process such requests, and the user's preference is recorded to optimize future decisions. The specific implementation method is as follows: After the user checks "Remember my choice" / "Automatically process this type of request" in the pop-up window, the behavior will be stored in the user preference cache and can be automatically matched the next time the same request is made.

[0068] In addition, users can view the permission behavior history and authorization log of each app to improve transparency.

[0069] Based on the above embodiment, this embodiment describes step S103 in detail: In some embodiments, specific implementations of real-time monitoring of permission invocation behavior and triggering an alarm in the event of abnormal usage include: Real-time monitoring of permission call behavior information, including Binder call behavior and Logcat logs, tracking permission usage frequency, call time period, and call source; When abnormal usage behavior is detected based on permission call behavior information (such as frequent reading of contacts in a non-interactive state at night), an alarm is triggered. The alarm content includes the abnormal package name, permission name, triggering rules, recommended handling methods, etc., which can be displayed visually.

[0070] The present invention has the ability to detect behavior at runtime, and can identify permission abuse and issue real-time alarms based on the frequency of permission use, call context and behavior sequence, filling the shortcoming of the "post-analysis" lag in existing solutions.

[0071] In some embodiments, abnormal permissions may be automatically disabled and logged.

[0072] In some embodiments, users can customize the abnormal alarm whitelist, add it through the system settings portal, and write it into the local rule configuration file.

[0073] like Figure 2 , Figure 2 Flowchart of a method for dynamic authorization and risk monitoring of permissions provided by an embodiment of the present invention: Starting with "Starting System Services," the system first captures all application permission requests (package name, status, user interaction, etc.) in real time, constructing a multi-dimensional context that feeds into the rules engine. The engine then automatically decides whether to grant, deny, or grant fuzzy permissions based on pre-set security policies. If a rule is not met, the system default policy is reverted to a pop-up window to query the user, and the authorization result and user preferences are logged. Permission invocation behavior is then continuously monitored, using anomaly detection models to identify risks such as backend abuse and frequent access, triggering alerts and dynamically issuing security patches. If behavior is normal, authorization is maintained, achieving a closed-loop, adaptive, and traceable permissions governance system.

[0074] The present invention does not rely on any machine learning framework. It adopts system calls, state machine judgment and configuration drive. It has low resource consumption, strong adaptability, can run stably on mid- and low-end devices, and has the ability to be industrialized.

[0075] The present invention fundamentally solves the problems of poor permission authorization experience and difficulty in preventing permission abuse, and provides a new permission management solution for mobile devices that takes into account "convenience, security, and real-time performance".

[0076] Please refer to Figure 3 , Figure 3 This is a structural block diagram of a device for dynamic authorization and risk monitoring of permissions provided by an embodiment of the present invention; the specific device may include: The data acquisition module 100 is used to intercept permission requests and obtain context information of the permission requests; A policy matching module 200 is configured to perform rule matching based on the permission request and its context information, using a pre-built rule engine, and determine an authorization management policy. The authorization management policy includes allowing the permission request, denying the permission request, delaying the permission request, adjusting the permission granularity of the permission request, and providing a security alert pop-up window. The abnormality monitoring module 300 is used to monitor the permission calling behavior in real time and trigger an alarm in the event of abnormal use.

[0077] The dynamic authorization and risk monitoring device of this embodiment is used to implement the aforementioned dynamic authorization and risk monitoring method. Therefore, the specific implementation methods of the dynamic authorization and risk monitoring device can be seen in the embodiment part of the aforementioned dynamic authorization and risk monitoring method. For example, the data acquisition module 100, the policy matching module 200, and the anomaly monitoring module 300 are respectively used to implement steps S101, S102, and S103 in the aforementioned dynamic authorization and risk monitoring method. Therefore, its specific implementation methods can refer to the descriptions of the corresponding embodiments of each part and will not be repeated here.

[0078] A specific embodiment of the present invention also provides a dynamic permission authorization and risk monitoring device, including: a memory for storing a computer program; a processor for implementing the steps of the above-mentioned dynamic permission authorization and risk monitoring method when executing the computer program.

[0079] A specific embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned method for dynamic authorization of permissions and risk monitoring are implemented.

[0080] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0081] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0082] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0083] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0084] Obviously, the above embodiments are merely examples for clarity of explanation and are not intended to limit the implementation methods. Those skilled in the art will appreciate that other variations or modifications can be made based on the above description. It is not necessary and impossible to enumerate all implementation methods here. Obvious variations or modifications arising therefrom remain within the scope of protection of the present invention.

Claims

1. A method for dynamic authorization and risk monitoring of permissions, characterized in that: include: Intercepting permission requests and obtaining context information about the permission requests; According to the permission request and its context information, a pre-built rule engine is used to match rules and determine the authorization management policy. The authorization management policy includes allowing the permission request, rejecting the permission request, delaying the permission request, adjusting the permission granularity of the permission request, and popping up a security warning window; Monitor permission call behavior in real time and trigger alarms in case of abnormal usage.

2. The method for dynamic authorization and risk monitoring of permissions according to claim 1, characterized in that: The interception permission request includes: By instrumenting the activity management service and package management service, it intercepts sensitive permission requests including precise positioning, audio recording, and reading contacts.

3. The method for dynamic authorization and risk monitoring of permissions according to claim 1, characterized in that: The obtaining of the context information of the permission request includes: Get context information including the name of the application package currently requesting permission, the foreground and background status of the application, the current window focus and whether the user is in the application interface, permission request trigger stack information, current system time, current system screen status and current system network status, and encapsulate it into a permission request context structure.

4. The method for dynamic authorization and risk monitoring of permissions according to claim 1, characterized in that: The determining of the authorization management policy by performing rule matching based on the permission request and its context information and a pre-built rule engine includes: Build a rule engine with configurable rules; According to the permission request and its context information, a rule engine traverses the rule list to perform rule matching; In the case that a successful matching rule exists, the successful matching rule with the highest priority is determined as the current authorization management policy; In the absence of a successful matching rule, the system default policy is determined to be the current authorization management policy.

5. The method for dynamic authorization and risk monitoring of permissions according to claim 1, characterized in that: The adjusting the permission granularity of the permission request includes: granting temporary permission, granting fuzzy permission, and not making an authorization decision.

6. The method for dynamic authorization and risk monitoring of permissions according to claim 1, characterized in that: In the case where the authorization management policy determines that a security alert pop-up window is provided, an instruction is obtained indicating whether the user chooses to automatically process such requests, and the user preference is recorded to optimize future decisions.

7. The method for dynamic authorization and risk monitoring of permissions according to claim 1, characterized in that: The real-time monitoring of permission call behavior and the triggering of alarms in the event of abnormal use include: Real-time monitoring includes Binder call behavior and Logcat logs, tracking permission usage frequency, call time period, and permission call behavior information of the call source; When abnormal usage behavior is detected based on permission call behavior information, an alarm is triggered. The alarm content includes the abnormal package name, permission name, triggering rules and recommended handling methods.

8. A device for dynamic authorization and risk monitoring of permissions, characterized in that: include: A data acquisition module, configured to intercept permission requests and obtain context information of the permission requests; A policy matching module is used to perform rule matching based on the permission request and its context information and a pre-built rule engine to determine the authorization management policy. The authorization management policy includes allowing the permission request, rejecting the permission request, delaying the permission request, adjusting the permission granularity of the permission request, and issuing a security warning pop-up window; The exception monitoring module is used to monitor permission call behavior in real time and trigger an alarm in the event of abnormal use.

9. A device for dynamic authorization and risk monitoring, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of a method for dynamic authorization and risk monitoring of permissions as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of a method for dynamic authorization and risk monitoring of permissions as described in any one of claims 1 to 7.

Images