Risk monitoring method and device for authority information, electronic equipment, medium and program

Abstract

The embodiment of the invention discloses a risk monitoring method and device for authority information, electronic equipment, a medium and a program, and the method comprises the steps: responding to an authority change event of a target user, and generating authority change information of the target user; determining a behavior risk level of a current detection behavior of the target user according to the user permission portrait information of the target user; and generating a permission processing strategy of the target user according to the behavior risk level of the current detection behavior of the target user and the permission change information. According to the technical scheme of the embodiment of the invention, the authority configuration time delay can be reduced, and the authority information risk management and control precision and efficiency are improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer software application technology, and in particular to a method, apparatus, electronic device, storage medium and program for risk monitoring of permission information. Background Technology

[0002] With the deepening of digital transformation in large enterprises, the number of business systems is growing explosively, making user identity and access control a critical link in the cybersecurity operations system. Taking industries such as energy, manufacturing, and finance as examples, enterprises often have hundreds of business systems, such as ERP (Enterprise Resource Planning), SCADA (Supervisory Control and Data Acquisition), marketing management, and OA (Office Automation System). Each system independently maintains user accounts and access control models, forming a "multi-source, decentralized, and fragmented" account management structure.

[0003] In the process of developing this invention, the inventors discovered the following shortcomings in existing technologies: Because different management systems employ independent account systems, the granularity of permissions, naming rules, and role divisions are inconsistent, making it impossible to achieve a globally unified perspective for permission tracking and risk auditing. Once user permissions change, manual configuration updates are required in multiple systems, resulting in significant delays and extremely low efficiency. Traditional permission governance is based solely on static configurations (such as role tables and permission matrices), failing to dynamically assess security risks such as "permission abuse" or "unauthorized access." Even with the introduction of a Security Orchestration, Automation, and Response (SOAR) platform, operations can only be performed in a single system or under specific security events, failing to create a unified automated closed loop for permission changes across multiple systems and roles. In summary, existing technologies cannot simultaneously achieve data integration, intelligent analysis, and automatic response in "multi-system user permission governance" scenarios. Especially in enterprise job transfer management, the lack of intelligent decision-making mechanisms based on logs and behavioral data becomes a major weakness in permission security governance. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, storage medium, and program for risk monitoring of access information, which can reduce access configuration latency and improve the accuracy and efficiency of access information risk management.

[0005] According to one aspect of the present invention, a risk monitoring method for access information is provided, comprising:

[0006] In response to a permission change event of the target user, permission change information of the target user is generated;

[0007] The behavioral risk level of the target user's current detection behavior is determined based on the target user's user permission profile information.

[0008] The target user's permission handling strategy is generated based on the behavioral risk level of the target user's current detected behavior and the permission change information.

[0009] According to another aspect of the present invention, a risk monitoring device for access information is provided, comprising:

[0010] The permission change information generation module is used to generate permission change information for the target user in response to a permission change event.

[0011] The behavior risk level determination module is used to determine the behavior risk level of the target user's current detected behavior based on the target user's user permission profile information.

[0012] The permission processing strategy generation module is used to generate a permission processing strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the risk monitoring method for permission information as described in any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the risk monitoring method for permission information as described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the risk monitoring method for permission information as described in any embodiment of the present invention.

[0019] This invention, in response to a target user's permission change event, generates permission change information for the target user, determines the behavioral risk level of the target user's current detected behavior based on the target user's user permission profile information, and then generates a permission processing strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information. This solves the problems of complex permission configuration processes and lack of intelligent analysis functions in existing permission information risk management, reduces permission configuration latency, and improves the accuracy and efficiency of permission information risk management.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a risk monitoring method for access control information provided in Embodiment 1 of the present invention;

[0023] Figure 2 This is a flowchart of a risk monitoring method for access control information provided in Embodiment 2 of the present invention;

[0024] Figure 3 This is a schematic diagram of a risk monitoring device for access information provided in Embodiment 3 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0028] Example 1

[0029] Figure 1 This is a flowchart of a risk monitoring method for permission information provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where permission information is automatically managed based on the user's behavioral risk level and permission change information. This method can be executed by a permission information risk monitoring device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. This electronic device can be a terminal device or a server device, as long as it can execute the permission information risk monitoring method. The present invention does not limit the specific type of electronic device. Correspondingly, as... Figure 1 As shown, the method includes the following operations:

[0030] S110. In response to the target user's permission change event, generate permission change information for the target user.

[0031] The target user can be any user whose permission information has changed in the relevant system. The permission change event can be of any type and can cause a change in user permissions. The permission change information can be permission update information.

[0032] This invention provides a dynamic management system for user permissions across multiple systems (hereinafter referred to as the dynamic permission management system). This system can be used for global security management of user permission information within an enterprise or institution. The dynamic permission management system can uniformly manage all user permission data across various business systems used within the enterprise or institution, such as ERP, OA, HR (Human Resources), CRM (Customer Relationship Management), and production control systems, thereby achieving "unified processing of permissions across the entire domain" and solving the problem of isolated permission information across multiple systems.

[0033] Optionally, the dynamic access control system can consist of an access data acquisition module (Data Integration Module), a log-privilege correlation analysis module (Log-Privilege Correlation Module), a behavioral analysis module (Behavioral Analysis Module), and an automated processing and linkage module (Automatic Handling and Linkage Module). The system comprises the following components: The permission data collection module collects and standardizes the analysis of user accounts, role permissions, and log data from multiple systems used by enterprises and institutions. The log and permission correlation analysis module analyzes and correlates data collected from various system platforms to build a model of the relationship between user behavior and permission configuration. The intelligent risk analysis module uses behavioral analysis algorithms to model user permission usage patterns and identify abnormal or unauthorized actions. The automated handling and linkage module automatically converts the risk review results of user permission information into handling scripts, enabling cross-system permission adjustments and security responses.

[0034] Optionally, the permission data acquisition module can deploy key components such as a multi-source acquisition agent, a data parsing engine, and UDM (Unified Data Management). During the data acquisition phase, the multi-source acquisition agent can call the API (Application Programming Interface) of various business systems (ERP, OA, HR / production systems) at preset intervals (e.g., every 5 minutes), or connect to the database via JDBC (Java Database Connectivity) to read account tables and / or role / permission tables, or receive operation logs in Syslog format, thereby achieving the acquisition of user permission data. The data parsing engine can perform semantic mapping and structured processing on permission fields in the data collected from different business systems. The UDM component can map the collected account, role, and permission triplet information into a unified data structure for easy subsequent analysis. The permission data acquisition module can employ a dynamic mapping maintenance algorithm to automatically synchronize mapping table changes in scenarios involving additions, job transfers, and mergers in relevant business systems. It supports real-time alignment with the organizational structure data of enterprises and institutions, enabling permission changes triggered by events such as job transfers and resignations. In summary, the permission data acquisition module adopts a unified abstraction and semantic alignment method for multi-system permission models, which can achieve dynamic synchronization of permissions based on organizational event triggers, and can also realize automatic updates and traceability records of permission graphs.

[0035] The data with a unified data structure, ultimately collected by the permission data collection module, can be sent to the log and permission correlation analysis module as the basic input for log parsing and baseline comparison. This allows the log and permission correlation analysis module to parse and correlate the data collected from various system platforms. Correspondingly, the log and permission correlation analysis module can perform parsing and correlation analysis based on the collected data, thereby associating user operation behaviors with permissions and comparing them with standard baselines. Optionally, the log and permission correlation analysis module may include a log rule engine, a permission correlation index library, and a baseline comparison module. The log rule engine can identify permission-related operation logs, such as "new account," "role change," and "unauthorized access." The permission correlation index library is used to establish a multi-dimensional index between user identity, department, system role, and log behavior. The baseline comparison module can analyze the difference between a user's current permission usage and the standard permission baseline for their position, outputting the difference results between the user's current permissions and the corresponding standard baseline for their position. Therefore, the log and permission correlation analysis module can extend the automated orchestration of behavioral security events to "permission governance scenarios," constructing a closed-loop automated execution process of "position change—permission change—system linkage."

[0036] Correspondingly, when a target user's permissions change, a permission change event will be generated in the associated business systems. For example, permission change events may include, but are not limited to, job transfer events, onboarding events, and offboarding events. At this time, the dynamic permission management system can detect and respond to the target user's permission change event in real time through the log and permission correlation analysis module, generating permission change information for the target user. This permission change information reflects the target user's recent permission changes.

[0037] S120. Determine the behavioral risk level of the target user's current detection behavior based on the target user's user permission profile information.

[0038] The user permission profile information can be a profile built based on the user's permission data. The current detected behavior can be the operation currently performed by the target user in the relevant business system.

[0039] The log and permission correlation analysis module outputs the results of the current permission differences from the job standard baseline, along with permission-related operation logs (such as unauthorized access and role changes), which are then directed to the intelligent risk analysis module to provide data support for behavior modeling and risk scoring. The intelligent risk analysis module can include a behavior modeling engine, an anomaly detection module, and a risk scoring model. The behavior modeling engine generates user permission profiles of target users based on time series and the target user's operational characteristics. The anomaly detection module identifies high-risk users and labels abnormal behaviors using clustering and deviation analysis algorithms, such as "exporting data in bulk before leaving the company" and "accessing sensitive resources of the old position after a job transfer." The risk scoring model generates a risk score for each user by comprehensively considering multi-dimensional information related to permission differences, thus classifying the risk of user behavior. In other words, the intelligent risk analysis module can determine the behavioral risk level of a target user's current detected behavior based on their user permission profile information.

[0040] S130. Generate the permission handling strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information.

[0041] The intelligent risk analysis module can send the behavioral risk level of the target user's current detected behavior to the automated handling and linkage module. The automated handling and linkage module can then trigger the automated orchestration of corresponding script matching and execution logic based on the received information. The automated handling and linkage module can be configured with a playbook repository, an execution engine, and an approval and rollback mechanism. The playbook repository defines standardized permission adjustment process templates, such as "account cancellation for departing employees" and "permission update for job transfers." The execution engine uses APIs to link with various business systems to perform permission update operations such as adding, modifying, and deleting. The approval and rollback mechanism provides manual approval and rollback functionality for high-risk operations (such as banning production system accounts), realizing an execution control model that combines automated playbooks with manual approval. Correspondingly, after obtaining the behavioral risk level of the target user's current detected behavior from the intelligent risk analysis module, the automated handling and linkage module can combine the target user's permission change information with the automated execution scripts in the playbook repository to generate a permission handling strategy for the target user. Permission handling policies can automatically call system APIs to perform corresponding operations, such as banning, changing authorizations, and synchronous deletion. Optionally, permission handling policies can introduce a tiered execution mechanism. For example, low-risk operations can be executed automatically, while changes to high-risk operations require approval before being executed in a coordinated manner, realizing permission-based linkage changes based on security events.

[0042] In addition to the modules mentioned above, the dynamic access control system may also include a visualization and closed-loop governance module. This module is used to synchronize the execution results of permission adjustments, approval records, and rollback operation logs of automated handling and linkage modules in real time for dashboard display and audit traceability. The visualization and closed-loop governance module can be configured with a panoramic dashboard, a handling record audit library, and an intelligent feedback mechanism. The panoramic dashboard can centrally display the three-dimensional relationship between "user-role-system." The handling record audit library can record all automated and manual operation logs, meeting compliance requirements. When analysts mark "false alarms" or "missing rules," the visualization and closed-loop governance module can automatically feed back to the intelligent risk analysis module through the intelligent feedback mechanism. The visualization and closed-loop governance module can provide a unified permission view and review process, enabling traceability and continuous optimization of system operation risk handling. Model optimization instructions generated by the visualization and closed-loop governance module through the intelligent feedback mechanism, such as adjusting behavioral risk levels and updating job permission baselines, are passed back to the permission data collection module to optimize the data collection scope and standardized rules, forming a governance closed loop.

[0043] Therefore, the aforementioned dynamic permission management system can integrate cross-system data, uniformly analyze account and permission data from multiple systems, and utilize intelligent behavior analysis algorithms to identify behavior-driven risks and determine permission abuse. Furthermore, it can achieve precise and controllable permission adjustment and handling through a security orchestration and automated response platform, optimizing data collection scope and standardized rules, thereby realizing automated closed-loop governance of permission information from "perception to analysis to decision-making to execution." This embodiment of the invention generates permission change information for a target user in response to permission change events, determines the behavioral risk level of the target user's current detected behavior based on the user permission profile information, and then generates a permission processing strategy for the target user based on the behavioral risk level and permission change information. This addresses the problems of complex permission configuration processes and lack of intelligent analysis functions in existing permission information risk management, reducing permission configuration latency and improving the accuracy and efficiency of permission information risk management.

[0044] Example 2

[0045] Figure 2 This is a flowchart of a risk monitoring method for permission information provided in Embodiment 2 of the present invention. This embodiment is a specific implementation based on the above embodiment. In this embodiment, several specific optional implementation methods are given for generating permission change information of a target user and determining the behavioral risk level of the target user's current detected behavior. Correspondingly, as... Figure 2 As shown, the method in this embodiment may include:

[0046] S210. In response to the permission change event of the target user, obtain the current permission set and the updated job standard permission set of the target user.

[0047] The current permission set can be the set of job permissions for the target user before the permissions were updated. The updated job standard permission set can be the set of job permissions for the target user after the permissions were updated.

[0048] In this embodiment of the invention, the dynamic permission management system collects user accounts, roles, permission tables, and operation logs from various business systems through a permission data acquisition module. It then performs semantic mapping on the collected unstructured data (such as differences in permission field naming across systems). For example, it unifies the "data export right" of the ERP system and the "file download right" of the OA system into "data acquisition permissions," generating structured data conforming to the UDM standard. The permission data acquisition module periodically reports the generated structured data to the log and permission correlation analysis module. The log and permission correlation analysis module parses the data reported by the permission data acquisition module using a parser and updates a unified multi-dimensional permission correlation index library of "user-role-system-operation," ensuring that subsequent analysis can quickly locate the full permission data of the target user. The log and permission correlation analysis module can also define standard permission baselines for positions based on organizational structure and job responsibilities, generating a "position-permission mapping table." When a business system triggers permission change events such as "departure" or "job transfer" for a target user, the system automatically detects the difference between the current permission and the standard permission.

[0049] Specifically, when the log and permission correlation analysis module generates the standard permission baseline for a position, it can read organizational structure data such as departments, positions, and reporting relationships from the HR system, along with historical permission configuration records. Combined with the "position permission requirement list" provided by the business department, it generates a "position-permission mapping table," such as "financial supervisor position" corresponding to "ERP financial data query right, approval right, and OA expense reimbursement approval right." Furthermore, the log and permission correlation analysis module transforms the "position-permission mapping table" into a computable standard permission baseline. This standard permission baseline can be stored as a set of permission IDs and associated with all user accounts for the corresponding position, forming a "user-position-baseline permission" binding relationship.

[0050] S220. Calculate the permission difference set based on the current permission set and the updated job standard permission set.

[0051] S230. Generate permission change information for the target user based on the permission difference set; wherein, generating the permission change information includes permission set information to be revoked and permission set information to be added.

[0052] The permission difference set can be the set obtained by subtracting the current permission set from the updated job standard permission set.

[0053] After completing the preliminary data preparation, once a target user triggers a permission change event such as "departure" or "job transfer," such as an HR system notification that "User A has been transferred from a technical position to an operations and maintenance position," the permission dynamic management system can capture the permission change event in real time through the log and permission correlation analysis module. Based on the permission change event, it identifies the target user and automatically matches and obtains the target user's current permission set (Pcurrent) before the permission change and the updated job standard permission set (Pnew) after the permission change. Then, it calls the "job-permission difference identification algorithm" to calculate the difference between the current permission set and the updated job standard permission set, thus obtaining the permission difference set. .in, This represents the permission difference set, where Pcurrent represents the current permission set and Pnew represents the updated job standard permission set. Furthermore, the log and permission correlation analysis module can generate a permission adjustment list for the target user based on the permission difference set, including the set of permissions to be revoked (Pcurrent-Pnew) and the set of permissions to be added (Pnew-Pcurrent). For easier analysis and tracing later, the system types involved in the permission set information (such as production systems and financial systems) can be marked.

[0054] S240. Calculate the behavioral pattern deviation of the current detected behavior based on the user permission profile information.

[0055] Optionally, the intelligent risk analysis module can calculate the deviation degree of the current detection behavior based on the user permission profile information of the target user, so as to measure the degree of deviation between the target user's current detection behavior and its job permission through the deviation degree of the behavior pattern.

[0056] In an optional embodiment of the present invention, the step of calculating the behavioral pattern deviation of the current detected behavior based on the user permission profile information may include: obtaining the target user's historical permission behavior profile and updated job behavior profile; determining the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile respectively; and calculating the behavioral pattern deviation of the current detected behavior based on the historical permission behavior profile, the updated job behavior profile, and the profile weight factors.

[0057] Among them, the historical permission behavior profile can be generated based on data such as the target user's historical permissions and historical operation behavior. The updated job behavior profile can be generated based on data such as the target user's updated permissions and current detection behavior. The profile weight factor can represent the importance of the profile.

[0058] The intelligent risk analysis module receives permission change information, such as the set of permissions to be revoked and the set of newly added permissions for the target user, from the log and permission correlation analysis module. It can also obtain the target user's operation logs over a historical period (e.g., within 30 days) through the log and permission correlation analysis module, thereby triggering the behavior modeling engine to generate a historical permission behavior profile of the target user based on time series algorithms such as LSTM (Long Short-Term Memory). For example, the historical permission behavior profile may include information such as the target user's average daily number of operations, frequently used systems, and the frequency of sensitive operations. Simultaneously, the intelligent risk analysis module can also generate an updated job behavior profile of the target user based on their current detected behavior and the newly added permission set information. Optionally, the current detected behavior can be recent operations initiated on relevant business systems, such as on the same day. Since it includes both historical permission behavior profiles and updated job behavior profiles, matching profile weight factors can be set for both to balance the proportion of each profile. Correspondingly, the intelligent risk analysis module can calculate the behavioral pattern deviation of the current detected behavior based on the historical permission behavior profile, the updated job behavior profile, and the profile weight factors.

[0059] For example, the intelligent risk analysis module can perform clustering modeling on the target user's operational behavior over the past 30 days and calculate their behavioral deviation score: Deviation Score = w1 Historical permission behavior profile deviation +w2 Update the deviation of the job behavior profile. The deviation of the historical permission behavior profile can be calculated based on the historical permission behavior profile, and the deviation of the updated job behavior profile can be calculated based on the updated job behavior profile.

[0060] In an optional embodiment of the present invention, determining the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile may include: determining the target user's permission range before and after the change based on the target user's permission change information; calculating the target user's permission change measurement value based on the target user's permission range before and after the change; and determining the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile based on the target user's permission change measurement value.

[0061] The "pre-change" permission scope can be the permission scope of the target user before the permission change. The "post-change" permission scope can be the permission scope of the target user after the permission change. The permission change metric can be used as a reference value for allocating profile weight factors. For example, the permission change metric can be a sub-weight factor assigned to the profile weight factor.

[0062] It is understandable that different scopes of permission changes for a target user will lead to different key data points for detecting permission behavior risks. Therefore, the profile weight factors corresponding to historical permission behavior profiles and updated job behavior profiles can be dynamically adjusted in real time based on the scope of permission changes for the target user. Specifically, the user's permission range before and after the change can be determined based on the user's permission change information. Typically, the permission range before and after the change are different. Furthermore, a permission change measurement value for the target user can be calculated based on the user's permission range before and after the change. For example, a sub-weight factor can be assigned to the profile weight factor of the historical permission behavior profile, and another sub-weight factor can be assigned to the profile weight factor of the updated job behavior profile. Further, the user's permission range before and after the change can be compared. If the difference between the user's permission range before and after the change is small, it indicates a minor permission change, and the user's historical permission behavior profile has greater reference value. In this case, the proportion of sub-weight factors of each profile weight factor can be adjusted, making the profile weight factor of the historical permission behavior profile larger and the profile weight factor of the updated job behavior profile smaller. If there is a significant difference between the target user's permission scope before and after the change, it indicates a substantial change in the target user's permissions. In this case, the updated job behavior profile of the target user is of greater reference value. The proportion of sub-weighting factors of each profile weighting factor can be adjusted, making the profile weighting factor of the updated job behavior profile larger and the profile weighting factor of the historical permission behavior profile smaller. During the adjustment of profile weighting factors, it is essential to always ensure that the sum of the profile weighting factors of the historical permission behavior profile and the updated job behavior profile is 1.

[0063] S250. Calculate the behavioral risk level of the current detection behavior based on the behavioral pattern deviation of the current detection behavior.

[0064] After calculating the deviation degree of the current detection behavior pattern, the intelligent risk analysis module can combine it with other relevant factors of the business system to comprehensively calculate the risk score of the current detection behavior, thereby determining the behavioral risk level of the current detection behavior. The behavioral risk level of the current detection behavior can assess whether the target user's current detection behavior is abnormal, such as an increase in sensitive operations or access to unauthorized resources.

[0065] In an optional embodiment of the present invention, the step of calculating the behavioral risk level of the current detection behavior based on the behavioral pattern deviation of the current detection behavior may include: determining the frequency of permission changes of the target user and the system sensitive information of the user's associated system; and calculating the behavioral risk level of the current detection behavior by fusing the behavioral pattern deviation of the current detection behavior, the frequency of permission changes of the target user, and the system sensitive information of the user's associated system.

[0066] Among these, the user-related system can be the relevant business systems involved in the change of the target user's permissions. System sensitive information, also known as system sensitivity, is a core indicator for measuring the responsiveness of a business system to changes in permission parameters. It can assess the sensitivity of the system output to changes in permission parameters.

[0067] In a specific example, the intelligent risk analysis module can be based on the formula: Calculate the behavioral risk score for the current detected behavior. Among them, Indicates the degree of deviation from behavioral patterns. The weight for the deviation of the behavioral pattern; This indicates the frequency of permission changes for the target user. Weighting based on the frequency of permission changes; Indicates system sensitivity information, Weights for system sensitivity information. Optional. , and The algorithm can be trained on 100,000 historical permission operation logs (including scenarios such as job transfers and resignations) using a random forest. Optionally, the optimal parameter combination can be... , , Because it may involve multiple types of systems, therefore The appropriate values ​​need to be determined for the various systems involved. For example, for a production system, The value can be 0.9. For OS systems, It can take the value 0.3.

[0068] Furthermore, the intelligent risk analysis module can determine the behavioral risk level of the current detection behavior based on the behavioral risk score calculated for the current detection behavior and pre-set thresholds for each behavioral level. For example, if the behavioral risk score is greater than or equal to 80, the behavioral risk level of the current detection behavior can be determined as high risk; if the behavioral risk score is less than or equal to 50, the behavioral risk level of the current detection behavior can be determined as low risk; and if the behavioral risk score is greater than 50 but less than 80, the behavioral risk level of the current detection behavior can be determined as medium risk.

[0069] S260. Generate the permission handling strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information.

[0070] The automated processing and linkage module automatically generates appropriate permission handling strategies for the target user based on the behavioral risk level and permission change information of the target user's current detected behavior, such as freezing old permissions or synchronizing new permissions. Optionally, the automated processing and linkage module can adopt a dual-channel control logic of automatic execution channel and approval execution channel. If the behavioral risk level of the target user's current detected behavior is determined to be low risk, an automatic permission synchronization script can be matched, and the automatic execution channel can directly call the API to execute the automatic permission update operation of low-risk systems (such as OA systems and attendance systems). If the behavioral risk level of the target user's current detected behavior is determined to be high risk, a permission revoke script requiring dual approval can be matched, and the approval execution channel can be used to perform manual secondary confirmation for high-risk systems (such as financial systems and production control systems). If the behavioral risk level of the target user's current detected behavior is determined to be medium risk, such as a job transfer involving non-core system permission changes, an approval work order can be automatically pushed to the target user's direct supervisor. The work order can include a "permission difference list" and "abnormal behavior screenshot" for the approver's reference.

[0071] Optionally, for permission change operations requiring approval, after approval, the execution engine of the automated processing and linkage module calls the target system (such as a code repository or ERP) via API interface to perform permission adjustment operations according to the set of permissions to be revoked and the set of permissions to be added, such as deleting code repository access permissions for technical positions and adding equipment management permissions for maintenance positions. After execution, the automated processing and linkage module can automatically initiate a permission write-back verification process, that is, re-collecting user permission data of the target system and comparing it with the expected adjustment results. If there is a discrepancy, such as some permissions not being successfully deleted, a retry mechanism is triggered. Optionally, the retry mechanism can set a retry threshold to avoid getting stuck in an infinite loop. If the retry fails or a business interruption alarm occurs during execution, such as accidentally deleting core account permissions, the automated processing and linkage module can also call the permission snapshot through the rollback module to restore user permissions to the state before the operation and push a fault alarm to the security administrator. Optionally, the permission snapshot can be automatically generated within a set time period, such as 5 minutes, before the execution of the permission processing policy.

[0072] During the audit and feedback phase, the panoramic dashboard of the visualization and closed-loop governance module can update the target user's permission adjustment results and risk score changes in real time. For example, it can show the successful revocation of 3 permissions or the addition of 2 permissions, resulting in the target user's risk score dropping from 75 to 30. The dashboard supports filtering by "user / department / system". The visualization and closed-loop governance module also automatically stores all operation logs in the audit logbook, including but not limited to the executor, execution time, approval opinions, and rollback records, meeting the requirement for traceable permission changes. If a false alarm is flagged for an abnormal behavior, such as access caused by user A temporarily assisting a technical staff member after a job transfer, the intelligent feedback mechanism automatically adds this situation to the training set of the behavior risk score calculation model and adjusts accordingly. The calculation weights are then used to optimize the accuracy of subsequent risk identification.

[0073] The dynamic access control system can also employ a closed-loop optimization mechanism for access governance. The system records each access adjustment, risk score, and execution result, writing the results back to the analysis model. If the risk score significantly decreases after an access adjustment, the rule is automatically strengthened; if false alarms or missing permissions occur, the model parameters are automatically optimized. This mechanism can periodically generate access governance analysis reports, providing quantitative support for enterprise security management.

[0074] This invention provides a cross-system, multi-source data fusion user permission security governance system. It extracts a four-dimensional relationship of "user-role-permission-system" from multi-source system account data through multi-source log collection and analysis, and establishes a "behavior + permission" dual-feature profile model. This model identifies abnormal permission behaviors such as unauthorized logins and illegal operations through log parsing and alarm linkage. It constructs a risk-based human-machine collaborative execution system to achieve automated permission difference calculation and linkage governance in permission change scenarios. This results in a closed-loop security governance system encompassing "perception-analysis-decision-execution," significantly improving the automation level, security controllability, and intelligent evolution capabilities of multi-system permission management. It possesses stability, scalability, and practical deployability, making it particularly suitable for account security governance scenarios in energy, finance, government affairs, and large enterprises.

[0075] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant regions.

[0076] It should be noted that any arrangement or combination of the technical features in the above embodiments also falls within the protection scope of this invention.

[0077] Example 3

[0078] Figure 3 This is a schematic diagram of a risk monitoring device for access control information provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes: a permission change information generation module 310, a behavior risk level determination module 320, and a permission processing strategy generation module 330, wherein:

[0079] The permission change information generation module 310 is used to generate permission change information for the target user in response to a permission change event of the target user.

[0080] The behavior risk level determination module 320 is used to determine the behavior risk level of the target user's current detected behavior based on the target user's user permission profile information;

[0081] The permission processing strategy generation module 330 is used to generate the permission processing strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information.

[0082] This invention, in response to a target user's permission change event, generates permission change information for the target user, determines the behavioral risk level of the target user's current detected behavior based on the target user's user permission profile information, and then generates a permission processing strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information. This solves the problems of complex permission configuration processes and lack of intelligent analysis functions in existing permission information risk management, reduces permission configuration latency, and improves the accuracy and efficiency of permission information risk management.

[0083] Optionally, the permission change information generation module 310 is further configured to: in response to the permission change event of the target user, obtain the current permission set and the updated job standard permission set of the target user; calculate the permission difference set based on the current permission set and the updated job standard permission set; generate the permission change information of the target user based on the permission difference set; wherein, the generated permission change information includes the permission set information to be revoked and the newly added permission set information.

[0084] Optionally, the behavior risk level determination module 320 is further configured to: calculate the behavior pattern deviation degree of the current detected behavior based on the user permission profile information; and calculate the behavior risk level of the current detected behavior based on the behavior pattern deviation degree of the current detected behavior.

[0085] Optionally, the behavior risk level determination module 320 is further configured to: obtain the target user's historical permission behavior profile and updated job behavior profile; determine the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile respectively; and calculate the behavior pattern deviation of the current detected behavior based on the historical permission behavior profile, the updated job behavior profile and the profile weight factors.

[0086] Optionally, the behavior risk level determination module 320 is further configured to: determine the target user's permission range before and after the change based on the target user's permission change information; calculate the target user's permission change measurement value based on the target user's permission range before and after the change; and determine the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile based on the target user's permission change measurement value.

[0087] Optionally, the behavior risk level determination module 320 is further configured to: determine the frequency of permission changes of the target user and the system sensitive information of the user's associated system; and calculate the behavior risk level of the current detected behavior based on the deviation of the behavior pattern of the current detected behavior, the frequency of permission changes of the target user, and the system sensitive information of the user's associated system.

[0088] The aforementioned risk monitoring device for permission information can execute the risk monitoring method for permission information provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in this embodiment can be found in the risk monitoring method for permission information provided in any embodiment of the present invention.

[0089] Since the aforementioned permission information risk monitoring device is an apparatus capable of executing the permission information risk monitoring method in the embodiments of the present invention, those skilled in the art can understand the specific implementation and various variations of the permission information risk monitoring device in this embodiment based on the permission information risk monitoring method described in the embodiments of the present invention. Therefore, how the permission information risk monitoring device implements the permission information risk monitoring method in the embodiments of the present invention will not be described in detail here. Any apparatus used by those skilled in the art to implement the permission information risk monitoring method in the embodiments of the present invention falls within the scope of protection of this application.

[0090] Example 4

[0091] Figure 4A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0092] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0093] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0094] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as risk monitoring methods for access control information.

[0095] Optionally, the risk monitoring method for permission information may include: generating permission change information for the target user in response to a permission change event; determining the behavioral risk level of the target user's current detected behavior based on the target user's user permission profile information; and generating a permission processing strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information.

[0096] In some embodiments, the risk monitoring method for access control information may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the risk monitoring method for access control information described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the risk monitoring method for access control information by any other suitable means (e.g., by means of firmware).

[0097] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0098] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0099] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0100] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0101] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0102] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0103] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0104] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for risk monitoring of access information, characterized in that, include: In response to a permission change event of the target user, permission change information of the target user is generated; The behavioral risk level of the target user's current detection behavior is determined based on the target user's user permission profile information. The target user's permission handling strategy is generated based on the behavioral risk level of the target user's current detected behavior and the permission change information.

2. The method according to claim 1, characterized in that, The step of generating permission change information for the target user in response to a permission change event includes: In response to the permission change event of the target user, obtain the target user's current permission set and update the job standard permission set; Calculate the permission difference set based on the current permission set and the updated job standard permission set; The permission change information of the target user is generated based on the permission difference set; wherein, the generated permission change information includes permission set information to be revoked and permission set information to be added.

3. The method according to claim 1, characterized in that, The step of determining the behavioral risk level of the target user's current detected behavior based on the target user's user permission profile information includes: Calculate the behavioral pattern deviation of the current detected behavior based on the user permission profile information; The behavioral risk level of the current detection behavior is calculated based on the deviation of the behavioral pattern of the current detection behavior.

4. The method according to claim 3, characterized in that, The step of calculating the behavioral pattern deviation of the current detected behavior based on the user permission profile information includes: Obtain the target user's historical permission behavior profile and updated job behavior profile; Determine the profile weighting factors corresponding to the historical permission behavior profile and the updated job behavior profile, respectively; The behavioral pattern deviation of the current detected behavior is calculated based on the historical permission behavior profile, the updated job behavior profile, and the profile weighting factor.

5. The method according to claim 4, characterized in that, The step of determining the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile includes: Determine the target user's permission scope before and after the change based on the target user's permission change information; Calculate the permission change assessment value of the target user based on the target user's permission scope before and after the change; Based on the target user's permission change measurement value, determine the profile weight factors corresponding to the historical permission behavior profile and the updated job behavior profile, respectively.

6. The method according to claim 3, characterized in that, The step of calculating the behavioral risk level of the current detection behavior based on the behavioral pattern deviation of the current detection behavior includes: Determine the frequency of permission changes for the target user and the system-sensitive information of the user's associated systems; The behavioral risk level of the current detected behavior is calculated by fusing the deviation of the behavior pattern of the current detected behavior, the frequency of permission changes of the target user, and the system sensitive information of the user's associated system.

7. A risk monitoring device for access information, characterized in that, include: The permission change information generation module is used to generate permission change information for the target user in response to a permission change event. The behavior risk level determination module is used to determine the behavior risk level of the target user's current detected behavior based on the target user's user permission profile information. The permission processing strategy generation module is used to generate a permission processing strategy for the target user based on the behavioral risk level of the target user's current detected behavior and the permission change information.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that is executed by the at least one processor, which enables the at least one processor to perform the risk monitoring method for access information as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the risk monitoring method for permission information as described in any one of claims 1-6.

10. A computer program product, characterized in that, It includes a computer program / instruction, wherein when the computer program / instruction is executed by a processor, it implements the risk monitoring method for permission information as described in any one of claims 1-6.

Images