User permission risk identification method and system oriented to log platform

Abstract

A log platform-oriented user permission risk identification method and system, the method comprising: determining permission configuration information of a to-be-assessed user, the permission configuration information comprising user information, role information and permission information of the to-be-assessed user; determining a cue word based on the permission configuration information of the to-be-evaluated user and a preset risk analysis task instruction template; inputting the cue word into a large language model to guide the large language model to perform semantic understanding and logical reasoning on permission configuration information of the user to be evaluated, and identifying whether an unauthorized risk caused by combination of multiple role permissions exists or not; and obtaining a risk analysis result response output by the large language model, so as to determine whether the permission configuration information of the to-be-evaluated user has an unauthorized risk caused by the combination of multiple role permissions based on the risk analysis result response. Therefore, the defect that a traditional method depends on static rules and lacks semantic understanding is overcome, and normal form transformation from rule-based pattern matching to semantic-based association reasoning is achieved.

Description

Technical Field

[0001] This application relates to the fields of information security and access control technology, and in particular to a method and system for identifying user permission risks for log platforms. Background Technology

[0002] In modern information technology operations and security systems, centralized log platforms are critical infrastructure components used to aggregate, store, and analyze massive amounts of log data from network devices, servers, and application systems. To ensure the security and compliance of this log data, which often contains sensitive information, log platforms commonly employ role-based access control models for permission management. Administrators grant users corresponding permissions for reading, writing, exporting, and deleting logs by assigning one or more roles.

[0003] As system complexity and organizational scale increase, it's becoming increasingly common for a single user to be assigned multiple roles. Currently, the industry standard for auditing and detecting risks associated with role-based access control (RBAC) permission configurations involves pre-defining a series of prohibition rules. For example, the system group role cannot have permission to view business logs, and the development role cannot simultaneously have write permissions for the production environment and read permissions for audit logs. The system periodically or in real-time checks the current RBAC user permission configuration against these rules, triggering alerts if violations occur. This approach relies on a predefined static rule base for compliance checks, lacks an understanding of the business semantics behind permissions, and cannot effectively assess the risk of permission escalation caused by the cumulative effect of combining multiple role permissions.

[0004] Therefore, there is an urgent need for an auditing technique that can effectively identify risks associated with combined authority. Summary of the Invention

[0005] In a first aspect, this application provides a method for identifying user permission risks in a log platform. The method includes: determining the permission configuration information of a user to be evaluated, wherein the permission configuration information includes user information, role information, and permission information of the user to be evaluated, and the permission information of the user to be evaluated includes permissions for at least two roles; determining a prompt word based on the permission configuration information of the user to be evaluated and a preset risk analysis task instruction template; inputting the prompt word into a large language model to guide the large language model to perform semantic understanding and logical reasoning on the permission configuration information of the user to be evaluated, and to identify whether there is an unauthorized access risk caused by the combination of multiple role permissions; obtaining the risk analysis result response output by the large language model in response to the prompt word, and determining whether there is an unauthorized access risk caused by the combination of multiple role permissions based on the risk analysis result response.

[0006] The user permission risk identification method for log platforms provided in this application introduces a large language model as the core analysis engine. By leveraging the deep semantic understanding and logical reasoning capabilities of the large language model, it performs holistic reasoning on the multi-role permission combinations of the user to be evaluated, identifies the true business meaning and potential associations behind the permission combinations, and thus effectively identifies the risks of combined permissions. This overcomes the shortcomings of traditional methods that rely on static rules and lack semantic understanding, and realizes a paradigm shift from "rule-based pattern matching" to "semantic association reasoning".

[0007] In some possible implementations, the user information includes user identification information and the user's organizational context information, which includes at least one of department, job level, and business line.

[0008] This approach, by incorporating at least one organizational context—the user's department, job level, and business line—into the analysis framework, provides the large language model with key business scenarios and responsibility baselines. This allows the model's semantic understanding and logical reasoning to move beyond abstract permission lists and operate within specific organizational structures and job responsibilities, significantly improving the accuracy and reasonableness of risk identification and effectively reducing false positives. For example, the model can determine that "core database delete permission" is clearly high-risk for a "marketing department intern," but might be a reasonable configuration for a "senior engineer in the database operations team."

[0009] On the other hand, organizational context information can provide a data foundation for large language models to achieve refined risk classification. Specifically, permissions exceeding job level can reflect vertical overreach risk, while permissions crossing departmental or business line boundaries can reflect horizontal overreach risk in cross-business data correlation analysis.

[0010] In some possible implementations, the preset risk analysis task instruction template is an analysis task instruction template for target type unauthorized risks, which include horizontal unauthorized risks and / or vertical unauthorized risks.

[0011] This approach employs optional, modular risk task analysis instruction templates, which enhances the flexibility and scalability of the solution while ensuring the depth of analysis.

[0012] In some possible implementations, the prompt word is used to guide the large language model to perform at least one of the following analyses: analyzing whether there is a horizontal overreach risk in the combination of permissions of different roles of the user to be evaluated that allows for associated access across different business domains or data domains; analyzing whether there is a vertical overreach risk in the permissions possessed by the user to be evaluated that exceed the reasonable scope of their job level or responsibilities.

[0013] This approach explicitly requires large language models to focus on "related access across different business domains or data domains" to identify horizontal overreach, and to determine vertical overreach based on "the reasonable scope of job level or responsibilities." This provides large language models with clear reasoning paths and judgment criteria, reducing the possibility of model illusions or comprehension biases, and improving the accuracy and reliability of risk identification results.

[0014] In some possible implementations, the prompt word is used to instruct the large language model to output the risk analysis result response containing risk existence indication information, and, if the risk existence indication information indicates the existence of unauthorized access risk, the risk analysis result response should also include the risk type, risk level, and risk description for each identified risk, the risk description being used to explain in detail how the combination of permissions leads to unauthorized access.

[0015] In some possible implementations, after obtaining the risk analysis result response of the large language model in response to the prompt word output, the method further includes: when the risk existence indication information indicates the existence of an unauthorized access risk, calculating a risk score for the first risk based on the identified risk type, risk impact scope, confidence level of the first risk, and the job level of the user to be evaluated; the risk type includes horizontal unauthorized access risk and vertical unauthorized access risk; the first risk is any unauthorized access risk related to the user to be evaluated indicated by the risk analysis result response; based on the risk score of the first risk, outputting an unauthorized access risk report of the target user's permission configuration information using a corresponding notification strategy; when the user to be evaluated has an unauthorized access risk, the user to be evaluated is considered a target user.

[0016] This approach, on the one hand, transforms the natural language risk description output by the large language model into a unified and objective risk score by comprehensively considering the risk type, scope of impact, confidence level, and user job level in a multi-factor risk score calculation method, thereby achieving standardization and operability of risk assessment results.

[0017] On the other hand, the two key calculation parameters, risk impact scope and confidence level, enable the impact assessment to be based not on a simple, pre-defined classification, but on the impact scope parameter to comprehensively consider the depth of impact of specific risk scenarios, and on the confidence level parameter to comprehensively consider the uncertainty of the output of the large language model. This effectively suppresses high-scoring false alarms that may be caused by model illusions or vague expressions, and improves the precision and rationality of the risk assessment system.

[0018] In some possible implementations, the risk score of the first risk is calculated based on the following formula: final_score = base_score * scope_weight * rank_weight + confidence_adjustment, where base_score is the base score of the risk type, scope_weight is the weight coefficient of the risk's impact range, rank_weight is the user's job title weight, and confidence_adjustment is the confidence score of the first risk.

[0019] Using this approach, the core part of the formula, base_score * scope_weight * rank_weight, indicates that the severity of risk is jointly determined by the inherent attributes of risk (base score) and specific context (scope, job level). The confidence level is introduced as an independent addition, which can flexibly reflect the degree of certainty of the model's judgment without distorting the core risk logic, and effectively integrate the credibility of qualitative analysis with the quantitative severity of risk.

[0020] In some possible implementations, when the risk existence indication information indicates the existence of unauthorized access risk, the risk analysis result response also includes specific permission adjustment suggestions, and the risk report also includes permission adjustment suggestions.

[0021] Using this approach, permission adjustment suggestions require the large language model to perform semantic understanding and logical reasoning on complex user permission configurations, combined with the identified root causes of risks. This approach is highly targeted and reasonable, and helps reduce the professional threshold and time cost required for administrators to go from describing risk analysis results to formulating rectification plans.

[0022] Secondly, this application also provides a user permission risk identification system for a log platform, including a module for executing any of the user permission risk identification methods for a log platform in the first aspect.

[0023] Thirdly, this application also provides a user permission risk identification device for a log platform, including a unit for executing any of the user permission risk identification methods for a log platform in the first aspect.

[0024] Fourthly, this application also provides a computer storage medium that can store multiple instructions, which are adapted to be loaded and executed by a processor using any of the user permission risk identification methods for log platforms in the first aspect.

[0025] Fifthly, embodiments of this application also provide a computer program product containing instructions, which, when run on an electronic device, causes the electronic device to execute any of the user permission risk identification methods for log platforms described in the first aspect.

[0026] In a sixth aspect, embodiments of this application also provide a chip module, including a transceiver component and a chip, wherein the chip is used to execute any of the user permission risk identification methods for log platforms in the first aspect.

[0027] In a seventh aspect, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the method described in any one of the first aspects is performed when the processor executes the program.

[0028] It is understood that the user permission risk identification system, device, computer storage medium, computer program, computer program product, chip system, and electronic device provided above for log platforms are all used to execute the method shown in any implementation of the first aspect of the embodiments of this application. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0029] Figure 1 This is a flowchart illustrating a user permission risk identification method for a log platform provided in an embodiment of this application. Figure 2 This is a flowchart illustrating another method for identifying user permission risks in a log platform, as provided in an embodiment of this application. Figure 3 This is a schematic diagram of the architecture of a user permission risk identification system for a log platform provided in an embodiment of this application; Figure 4 This is a schematic diagram of a user permission risk identification device for a log platform provided in an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described below in conjunction with the accompanying drawings.

[0031] It should be noted that this application embodiment uses an electronic device as an example to illustrate the execution subject of the user permission risk identification method for a log platform provided in this application. This electronic device can also be understood as the user permission risk identification device for a log platform shown in this application embodiment. In this application embodiment, the electronic device can be a microprocessor or computer for executing program code, etc. Any electronic device that can be used to execute the method provided in this application embodiment is within the protection scope of this application embodiment, and this application does not impose any limitations. For example, the electronic device can be a desktop computer, a laptop, a mobile terminal, a 32-bit microprocessor, or a 64-bit microprocessor, etc., and this application embodiment does not limit this.

[0032] Please see Figure 1 , Figure 1 This application provides a flowchart of a user permission risk identification method for a log platform. Figure 1 As shown, this user permission risk identification method for log platforms includes the following steps: S101, the electronic device determines the permission configuration information of the user to be evaluated.

[0033] In this embodiment of the application, the permission configuration information of the user to be evaluated includes the user information, role information, and permission information of the user to be evaluated, wherein the permission information of the user to be evaluated includes the permissions of at least two roles.

[0034] In some possible implementations, user information includes user identification information and the user's organizational context information, which includes at least one of department, job level, and business line. The user identification information includes the user name and / or a unique user identifier (e.g., an employee ID number). Business lines can be associated with permissions; for example, permission A might be marked as belonging to the e-commerce business line, and permission B might be marked as belonging to the payment business line.

[0035] For example, the electronic device extracts the following data from the RBAC (Record-Based Accounting) system: user list, role list, permission list, user-role assignment relationship, and role-permission mapping relationship; it also obtains organizational context data from relevant systems, such as user department and job level information from the Human Resources Management (HR) system, and business line and team information from the organizational structure system. Through key fields (such as user identification information and department identification), the data from different systems are associated to construct a complete user data view containing user information, role information, and permission information. This complete user data view can also be understood as a complete user data view containing user identification information, organizational hierarchical document information (any one of department information, job level information, team information, or business line information), role information, and permission information.

[0036] As an example, the user to be evaluated is any user in the complete user data view who has permissions for at least two roles. As another example, the user to be evaluated could also be a specific user designated by the user who requires an unauthorized access risk assessment.

[0037] In some possible implementations, the electronic device determines the permission configuration information of the user to be evaluated, specifically by: acquiring and using all data related to the user to be evaluated (user identification information, organizational file information, role information, and permission information) recorded in the aforementioned complete user data view as the permission configuration information of the user to be evaluated.

[0038] In some other possible implementations, the aforementioned permission configuration information is a semantic permission file containing role permission description paragraphs. The electronic device determines the permission configuration information of the user to be evaluated, specifically including: obtaining all data of reference users with permissions containing at least two roles recorded in the aforementioned complete user data view, loading the permission file description template, traversing each reference user, combining the user data and the permission file description template to generate a role permission description paragraph for each reference user as the semantic permission file of the reference user, and combining the semantic permission files of each reference user to form a complete permission file set; when it is determined that an unauthorized access risk assessment needs to be performed on the user to be evaluated (any reference user), the semantic permission file of the user to be evaluated is obtained from the complete permission file set as the permission configuration information of the user to be evaluated.

[0039] In some possible implementations, electronic devices can also perform redundancy elimination on the role permission description paragraphs of the reference user, merge the descriptions of the same permissions contained in multiple roles of the reference user, and use conjunctions and transition sentences to make the permission profile read more coherently.

[0040] For example, the semantic permission profile of the user to be evaluated is: "User Zhang San (intermediate engineer of the core infrastructure team of the Operations Department) has the roles [Log Administrator, Security Auditor], where the Log Administrator role allows [delete all logs] and the Security Auditor role allows [view all security logs]".

[0041] S102, the electronic device determines the prompt words based on the permission configuration information of the user to be evaluated and the preset risk analysis task instruction template.

[0042] In this embodiment of the application, the preset risk analysis task instruction template is an analysis task instruction template for target type unauthorized risks, which include horizontal unauthorized risks and / or vertical unauthorized risks.

[0043] In this embodiment, the organizational context information in the user information of step S101 above can provide a data foundation for the large language model to achieve refined risk classification. Specifically, permissions exceeding job level can reflect vertical overreach risk, and permissions crossing departmental or business line boundaries can assist in the analysis of horizontal overreach risk in cross-business data correlation analysis. In some possible implementations, if the risk analysis task instruction template is a task instruction template for analyzing vertical overreach risk, the above-mentioned organizational context information may only include job level information and not department and business line information. If the risk analysis task instruction template is a task instruction template for analyzing horizontal overreach risk, the above-mentioned organizational context information may also include department and business line information but not job level information.

[0044] In this application embodiment, the prompt words are used to guide the large language model to perform at least one of the following analyses: analyze whether there is a horizontal overreach risk in the combination of permissions of different roles of the user to be evaluated that allows for related access across different business domains or data domains; analyze whether there is a vertical overreach risk in the permissions possessed by the user to be evaluated that exceed the reasonable scope of their job level or responsibilities.

[0045] In this embodiment of the application, the prompt word is also used to instruct the large language model to output a risk analysis result response containing risk existence indication information. Furthermore, when the risk existence indication information indicates the existence of unauthorized access risk, the risk analysis result response should also include the risk type, risk level, and risk description of each identified risk. The risk description is used to explain in detail how the combination of permissions leads to unauthorized access.

[0046] As an example, the instruction template for an analysis task targeting horizontal escalation risk is as follows: prompt =“You are a security audit expert. Please analyze the following user's permission configuration:” {Permission configuration information of the user to be evaluated} Please identify whether the user has any horizontal privilege escalation risk due to a combination of multiple roles.

[0047] Focus on the combination of permissions for different business domains or data domains, and assess whether the combination can enable cross-domain correlation analysis or obtain an overall business view beyond its scope of responsibility.

[0048] Please answer in the following format: 1. Existence of risk: [Yes / No] 2. Risk Description: [If present, describe in detail how combined permissions could lead to unauthorized access] 3. Risk Level: [High / Medium / Low] 4. Recommendation: [Specific suggestions for permission adjustments] As another example, the instruction template for an analysis task targeting vertical overreach risk is as follows: prompt =“You are a security audit expert. Please analyze the following user's permission configuration:” {Permission configuration information of the user to be evaluated} Please identify whether the user has any vertical overreach risks, i.e., whether they have high-risk permissions that exceed their job level or responsibilities.

[0049] Key areas of focus include: system management permissions, data deletion permissions, audit log access permissions, and user management permissions.

[0050] Please answer in the following format: 1. Existence of risk: [Yes / No] 2. Risk Description: [Detailed Description] 3. Risk Level: [High / Medium / Low] 4. Recommendation: [Specific suggestions for permission adjustments] Understandably, if a prompt word generated based on an analysis task instruction template specifying a particular type of unauthorized access risk (horizontal or vertical), and this prompt is input into a large language model, resulting in an analysis result indicating the presence of risk, then the risk type is the specified unauthorized access risk, and the output content may not include a risk type field. However, it should be noted that, depending on specific design requirements, the output content specified in the analysis task instruction template may also include a risk type field; this article does not impose any restrictions on this.

[0051] As another example, the analysis task instruction template for detecting both horizontal and vertical unauthorized access risks is as follows: The prompt reads: "You are a security audit expert. Based on the principles of least privilege and separation of duties, please comprehensively analyze the permission configurations of the following users to identify any vertical and horizontal privilege escalation risks."

[0052] {Permission configuration information of the user to be evaluated}

Analysis Task and Definition

[0053] 2) Please identify whether the user poses a risk of vertical privilege escalation, i.e., whether they possess high-risk permissions beyond their job level or responsibilities. Pay particular attention to: system administration permissions, data deletion permissions, audit log access permissions, and user management permissions.

[0054] Please output your analysis results in the following structured format. I. Horizontal Unauthorized Access Risk Assessment Risk Presence: [Yes / No] Risk Description: [If present, please clearly explain which combination of roles / permissions led to the cross-domain access risk, and which data or services that should have been isolated may be affected.] Risk level: [High / Medium / Low] Recommended adjustments: [Specific role or permission adjustment suggestions] II. Vertical Overreach Risk Assessment Risk Presence: [Yes / No] Risk Description: [If any, please clearly explain which high-risk permissions do not match the employee's job level / position, and the potential hazards.] Risk level: [High / Medium / Low] Recommended adjustments: [Specific role or permission adjustment suggestions] III. Overall Conclusion and Level of Urgency Overall Risk Rating: [Based on the above two factors, an overall risk rating is given.] Emergency handling recommendations: [e.g., handle immediately, prioritize, optimize regularly] S103, the electronic device inputs the prompt words into the large language model to guide the large language model to perform semantic understanding and logical reasoning on the permission configuration information of the user to be evaluated, and to identify whether there is any risk of unauthorized access due to the combination of multiple role permissions.

[0055] In this embodiment of the application, after determining the prompt word, the electronic device inputs the prompt word into the large language model to assist and guide the large language model to perform semantic understanding and logical reasoning on the permission configuration information of the user to be evaluated, and to identify whether there is a risk of unauthorized access due to the combination of multiple role permissions.

[0056] As an example, the cue words target horizontal escalation risk detection, indicating that the user being assessed is a finance staff member in the finance department, whose primary business line is finance, and who possesses both access to the marketing activity log and customer information database. The large language model identifies horizontal escalation risk based on the cue words by analyzing the data and finding that the user's access to both marketing activity logs and customer information database is significantly different from their primary business line of responsibility within the finance department. Therefore, it is inferred that a finance staff member typically does not need and should not access marketing activity logs and the customer information database; this combination allows them to cross-domain linking of financial transactions, marketing activities, and customer data, thus identifying horizontal escalation risk.

[0057] For example, the prompt word targets horizontal privilege escalation risk detection and indicates that the user being evaluated includes both a security auditor and a business system maintainer. The security auditor role is granted permission to view all security event logs (including IP and time), while the business system maintainer role is granted permission to view business system access logs (including user ID and operations). The large language model performs cross-domain correlation analysis based on the prompt word, checking whether the permissions from different roles can be concatenated: the security auditor role can view all security event logs (including IP and time), and the business system maintainer role can view business system access logs (including user ID and operations). Model inference: After combination, the user can associate security events (IP) with business operations (user ID), thereby accurately detecting sensitive behaviors of specific individuals and identifying horizontal privilege escalation capabilities caused by the combination that a single role does not possess.

[0058] For example, large language models can also check whether high-risk permissions from different roles are improperly centralized based on prompt words, identifying horizontal privilege escalation capabilities. For instance, role A has "log deletion permission," and role B has "audit log disabling permission." The model infers that a user with both permissions can theoretically delete operation logs and disable auditing, thus eliminating traces of their own violations. This overlap creates a high-risk ability to "cover up traces" that a single role does not possess.

[0059] As another example, regarding the detection of vertical privilege escalation risks, a specific scenario for the large language model to identify vertical privilege escalation risks is as follows: When the large language model analyzes and finds that the user to be evaluated is a "junior engineer" who simultaneously possesses "production database configuration modification permissions" and "user account management permissions," it determines that these are system management or high-risk operation permissions, which are usually inconsistent with the "junior" job level. Even if these two permissions come from different roles, their combination further amplifies the severity of the mismatch, and the model can then identify the vertical privilege escalation risk accordingly.

[0060] Generally, the temperature parameter in large language model analysis refers to how smoothly the probability distribution of a large language model is smoothed when generating the next word. A low temperature parameter makes the probability distribution of the large language model sharper or more concentrated, and the model is more inclined to choose the word it considers most likely and certain, resulting in outputs with high certainty, conservatism, and strong repeatability. A high temperature parameter makes the probability distribution of the model smoother or more uniform, and the model is more willing to give words with lower probabilities more opportunities, resulting in outputs with higher randomness, creativity, and diversity, but may also be more unstable.

[0061] In this embodiment of the application, the electronic device can also set an appropriate temperature parameter for the analysis of the large language model to ensure the stability and reliability of the output of the large model intelligent analysis module and meet the strict requirements of security audit products for the consistency of results. For example, it can be set to a low value (such as a value greater than or equal to 0.1 and less than or equal to 0.3) to ensure the stability of the output.

[0062] S104, the electronic device obtains the risk analysis result response of the large language model response to the prompt word output, so as to determine whether the permission configuration information of the user to be evaluated has an unauthorized risk due to the combination of multiple role permissions based on the risk analysis result response.

[0063] For example, the output of the large language model is a risk analysis result response containing risk existence indication information, wherein, when the risk existence indication information indicates the existence of unauthorized risk, the risk analysis result response also includes the risk type, risk level, and risk description of each risk identified by the large language model analysis.

[0064] Specifically, the electronic device receives the risk analysis text returned by the large language model, extracts risk information (including risk existence, risk type, risk level, risk description, etc.), and associates it with the specific user's permission configuration information. It then outputs associated data containing risk information, the specific user, and the user's permission configuration information to inform the relevant administrator about the unauthorized risk of the user's role and permission combination.

[0065] Currently, the industry's auditing and detection of RBAC permission configuration risks mainly relies on the following two types of technical solutions, but both have obvious limitations: 1) Compliance check method based on static rule base Implementation: This method predefines a series of "prohibition rules" or "compliance baselines," such as "system group roles must not have permission to view business logs" and "development roles cannot simultaneously have write permissions for the production environment and read permissions for audit logs." The system periodically or in real-time checks the current RBAC configuration (user-role, role-permission relationship) against these rules, triggering alarms if rules are violated.

[0066] Problems exist: Outdated and rigid rules: Rules need to be defined and maintained manually in advance, which cannot cover all potential combinations of risks, and it is especially difficult to foresee new risk scenarios that arise as business changes and new roles are added.

[0067] Lack of semantic understanding: This method only performs literal matching and cannot understand the business meaning behind the permissions. For example, it cannot determine whether the seemingly independent permissions of "view all security logs" and "view all business system logs" violate the "principle of least privilege" when combined on a single user.

[0068] Unable to identify logical association risks: Unable to infer that combined permissions can perform cross-domain association analysis, thus failing to identify the true risk of excessive data exposure.

[0069] 2) Real-time detection and alerting method based on permission change logs Implementation: This solution focuses on the "granting" action of permissions itself. By monitoring operation logs such as permission allocation and role binding in the RBAC system, it provides real-time alerts for operations deemed "high-risk." For example, operations such as "assigning administrator roles to ordinary users" and "changing permissions outside of working hours" are flagged.

[0070] Problems exist: Its focus is one-sided: it only focuses on the "moment" and "operation" of permission changes, rather than the "final state" of permission configuration. This method cannot effectively identify an over-authorization configuration that accumulates gradually through multiple routine operations (e.g., assigning the same user two roles that are individually reasonable but combined are high-risk).

[0071] Lack of contextual risk assessment: Its alerts rely on predefined "high-risk operation" keywords and cannot combine contextual information such as the user's department, job level, and existing permission combination to dynamically and intelligently assess the actual risk of authorized behavior.

[0072] Responding after the fact rather than proactively preventing: This is a post-event auditing approach that usually issues alerts only after improper permission configuration has already occurred, and cannot proactively and preventively identify risks at the permission configuration policy level.

[0073] The user permission risk identification method for log platforms provided in this application creatively applies the semantic understanding and logical reasoning capabilities of large language models to the deep risk auditing scenario of RBAC permission configuration in log platforms. It performs holistic reasoning on the multi-role permission combinations of users to be evaluated, identifies the true business meaning and potential associations behind the permission combinations, and thus effectively identifies the risks of combined permissions. This overcomes the shortcomings of traditional methods that rely on static rules and lack semantic understanding, and realizes a paradigm shift from "rule-based pattern matching" to "semantic association reasoning".

[0074] In some possible implementations, such as Figure 2As shown, after the electronic device obtains the risk analysis result response of the large language model to the prompt word output (that is, after step S104 above), the electronic device also performs the following steps: S201, when an electronic device determines that there is an unauthorized access risk, it calculates a risk score for the first risk based on the risk type, the scope of the risk's impact, the confidence level of the first risk, and the job level of the user to be evaluated.

[0075] Among them, the risk types include horizontal unauthorized risk and vertical unauthorized risk. The first risk is any unauthorized risk related to the user to be evaluated, as indicated by the risk analysis result response.

[0076] The following is a distinction: users who pose a risk of unauthorized access are referred to as target users. Specific electronic devices can mark users who pose a risk of unauthorized access as target users.

[0077] For example, the risk score for the first risk mentioned above is calculated based on the following formula 1: Where base_score is the base score for the risk type, scope_weight is the weight coefficient for the scope of risk impact, rank_weight is the weight for the user's job level, and confidence_adjustment is the confidence score for the first risk. In some possible implementations, an upper limit for the risk score can also be set (e.g., an upper limit of 100 points). Formula 1 above also includes the following function: return min(final_score, 100).

[0078] As an example, the base score for risk types includes: horizontal overstepping: 80 points, vertical overstepping: 70 points. The higher the score, the higher the risk of overstepping. Alternatively, the base score for risk types can be other suitable values ​​based on the specific design of the risk type. This article does not limit this.

[0079] As an example, the confidence score for the first risk is based on the degree of certainty in the natural language description text (including risk type, risk level, and risk description) of the first risk in the risk analysis response. For instance, high-certainty keywords (e.g., including but not limited to: obvious, certain, serious conflict, etc.) and low-certainty keywords (e.g., including but not limited to: possible, perhaps, potential, etc.) are predefined. Based on the certainty keywords contained in the natural language description text of the first risk, a certainty score is assigned to the first risk. Another example is using a lightweight text classification model (or directly calling the meta-capabilities of a large model) to request a confidence score for the certainty of the first risk. Yet another example is that the prompt also requires the large language model to include not only risk information but also a numerical field of confidence score in its output.

[0080] As an example, the weighting coefficient (scope_weight) of the aforementioned risk impact scope is determined based on the data scope dimension of the target user's permissions (the breadth and depth of data that the permissions can access) and / or the operation scope dimension (the types and destructiveness of operations that the permissions can perform).

[0081] For example, data scope levels include, but are not limited to, high, medium, and low levels. The data scope keywords contained in the target user's permission information description correspond to the following data scope levels: keywords representing "all data" (e.g., all, complete, full volume) correspond to a high data impact level; keywords representing "across multiple business domains" (e.g., cross-domain, cross-system, multiple) correspond to a medium data impact level; and other cases correspond to a low data impact level. Understandably, other level classification methods may also be used depending on the specific design. The electronic device then obtains the highest data impact level by parsing the data scope keywords contained in the target user's permission information description.

[0082] For example, the scope of operation can be categorized into three levels—high, medium, and low—based on the destructiveness and recoverability of the operation. The scope of operation corresponding to the permission operation type keywords in the target user's permission information description is as follows: keywords representing "delete operation" (e.g., delete, remove, delete) correspond to a high level of operation impact; keywords representing "modify operation" (e.g., modify, update, edit, create, add, create) correspond to a medium level of operation impact; and other cases correspond to a low level of operation impact.

[0083] For example, electronic devices determine the weighting coefficients for the scope of risk impact based on the data scope and operational scope dimensions of the target user's permissions. Specifically, this includes: scoring the data scope level based on the target user's data scope level, scoring the operational scope level based on the target user's operational scope level, and determining the weighting coefficient based on the weighted sum of the two scores. For instance, if the total score is 100, and the weighted sum is greater than 80, the impact is system-wide, with a weighting coefficient of 1.5; if the weighted sum is greater than 60, the impact is cross-departmental, with a weighting coefficient of 1.2; otherwise, the weighting coefficient is 1.

[0084] It should be noted that, based on different designs, other alternative methods can be used to determine the weighting coefficients of the risk impact scope. This article does not limit this. For example, different combinations of data scope level and operational scope level correspond to different weighting coefficients of the risk impact scope.

[0085] As an example, the higher a user's job rank, the lower their rank weight (because they may require more privileges). For instance, a junior rank weight is 1.3, a mid-level rank weight is 1.0, and a senior rank weight is 0.9.

[0086] S202, the electronic device outputs a risk report to the target user based on the risk score of the first risk and adopts the corresponding notification strategy.

[0087] In this embodiment, the risk report includes, but is not limited to, the target user's original permission data, organizational structure information, and risk information. The risk information includes the risk type, risk level, and risk description.

[0088] For example, a tiered notification strategy is adopted. For target users whose risk scores indicate high risk (e.g., scores greater than or equal to 85), the risk of exceeding authority is notified in real time via instant messaging tools and SMS; for medium risk (e.g., scores greater than or equal to 75 and less than 80), notifications are sent via email and workflow; and for low risk (e.g., scores less than 75), the risk is only displayed within the system, for example, by generating a risk distribution visualization chart.

[0089] In some possible implementations, the risk analysis results response may also include specific permission adjustment recommendations, and the risk report may also include these recommendations to guide administrators in optimizing the permission configurations of relevant target users. For example, the large language model, combined with its identified risk root causes (e.g., horizontal privilege escalation due to simultaneously holding roles A and B), provides specific and actionable governance measures such as recommending the removal of role B or narrowing the permission scope of role A from 'all systems' to 'XX business line'.

[0090] In some possible implementations, electronic devices can also collect administrator feedback on risk reports (adoption, adoption after modification, re-analysis, or disapproval), and can also record specific optimization modifications as historical cases, and use historical cases to optimize large language models, forming a closed loop.

[0091] In some possible implementations, electronic devices can also group users with similar permission configurations together, call the large language model only once to perform unauthorized access risk analysis on the entire group, and apply the risk analysis results to all users within the group.

[0092] For example, the electronic device extracts key information about roles and permissions from the permission configuration information of each user to be evaluated. For instance, key permission information in the permission configuration information includes permission operations ('view', 'delete', 'modify', 'export', 'configure') and permission objects ('log', 'security log', 'business log', 'system log', 'audit log'). Then, based on the key information in the permission configuration information of the users to be evaluated, a lightweight pre-trained language representation model (BERT model) is used to generate semantic vectors for the users to be evaluated. Then, based on a cosine similarity-based agglomerative clustering method (e.g., setting the similarity threshold to 0.7 or other suitable values), similar users to be evaluated that meet the similarity threshold are grouped into a user group, and common characteristics of users within the group (e.g., shared roles and high-frequency permission operations) are summarized. A representative user profile is selected as a detailed analysis sample (e.g., selecting the user profile with the longest profile, which usually contains the most complete information). Based on the commonalities of users within the group, the representative user profile, and the user group's unauthorized access analysis instruction template, prompt words are constructed for the user group.

[0093] For example, the template for user group privilege escalation analysis is as follows: prompt = "As a security audit expert, please analyze the following user groups with similar permission configurations."

[0094] [Common Analysis of User Group Permission Configuration] {common_pattern} [Detailed analysis of the sample (representing a typical configuration of this group)] {representative_archive} [Analysis Task] Please assess the risks associated with this permission configuration method. Special attention should be paid to: 1. Is there a risk of horizontal privilege escalation (cross-domain data association)? 2. Is there a risk of vertical overreach (mismatch between authority and job level)? 3. Is it a high-risk permission combination mode? Please output in the following format. Risk Model Overview: [Describe the general risks associated with this configuration model] Detailed risk assessment (for the above sample users): 1. Horizontal Unauthorized Access: [Yes / No], Description: [...] 2. Vertical overriding: [Yes / No], Description: [...] 3. Overall Risk Level: [High / Medium / Low] Scope of impact: The estimated number of similar users affected by this risk is approximately {len(user_group_archives)} people. Recommended general corrective measures: [...] This approach clusters and groups users with similar permission configurations, enabling a single large model call to complete the unauthorized access risk analysis for the entire group of users. This reduces the number of API calls and computational costs, improving audit efficiency. Furthermore, because users within a group have similar permission structures, their unauthorized access risk patterns are highly consistent. Therefore, the results obtained from representative sample analysis can be reliably reused for other users within the group. While ensuring the accuracy of risk identification, this approach achieves a breakthrough in large-scale audit capabilities, enabling it to efficiently handle permission auditing scenarios involving a large number of users within an enterprise.

[0095] This application also provides a user permission risk identification system for log platforms, including a module for executing any of the user permission risk identification methods for log platforms described in the above method embodiments.

[0096] Please refer to Figure 3 This application provides an architectural diagram of a user permission risk identification system for a log platform. Figure 3 As shown, the system may include a permission configuration acquisition module 301, a large-scale intelligent analysis module 302, and a risk decision-making and report generation module 303. The permission configuration acquisition module 301 is used to determine the permission configuration information of the user to be evaluated. For example, the permission configuration acquisition module 301 specifically includes a data acquisition and preprocessing submodule and a semantic translation submodule.

[0097] For example, this data acquisition and preprocessing submodule is used to extract the following data from the RBAC log platform system: user list, role list, permission list, user-role assignment relationship, and role-permission mapping relationship; obtain the following context data from relevant systems: user department and job level information from the human resources (HR) system, and business line and team information from the organizational structure system; and clean and standardize the acquired data: unify naming conventions, parse permission operation objects, associate user and organizational information, and build a complete data view.

[0098] This semantic translation submodule is used to generate a personalized permission profile for each user based on the complete data view and permission profile template mentioned above. The permission configuration information of the user to be evaluated is the semantic permission profile of that user.

[0099] The aforementioned large-scale intelligent analysis module 302 is used to determine prompt words based on the permission configuration information of the user to be evaluated and the preset risk analysis task instruction template; input the prompt words into the large language model to guide the large language model to perform semantic understanding and logical reasoning on the permission configuration information of the user to be evaluated, and to identify whether there is an unauthorized risk caused by the combination of multiple role permissions; The risk decision and report generation module 303 is used to obtain the risk analysis result response of the large language model in response to the prompt word output, so as to determine whether the permission configuration information of the user to be evaluated has an unauthorized risk due to the combination of multiple role permissions based on the risk analysis result response.

[0100] In some possible implementations, the risk decision and report generation module 303 is further configured to, when the risk existence indication information indicates the existence of an unauthorized access risk, calculate a risk score for the first risk based on the identified risk type, risk impact scope, confidence level of the first risk, and the job level of the user to be evaluated, wherein the first risk is any unauthorized access risk related to the user to be evaluated indicated by the risk analysis result response; and based on the risk score of the first risk, output an unauthorized access risk report of the target user's permission configuration information using a corresponding notification strategy, wherein the user to be evaluated is considered a target user if the user to be evaluated has an unauthorized access risk.

[0101] In the embodiments of this application, any of the implementation methods mentioned in the method embodiments are also applicable to the user permission risk identification system for log platforms provided in this application. For specific execution steps, please refer to the description of the foregoing method embodiments, which will not be detailed here.

[0102] This application also provides a user permission risk identification device for a log platform, including a unit for executing any of the user permission risk identification methods for a log platform in the above method embodiments.

[0103] This application also provides a user permission risk identification device for a log platform, including a processor, which is used to execute any one of the user permission risk identification methods for a log platform in the above method embodiments.

[0104] Please refer to Figure 4 This is a schematic diagram of another user permission risk identification device for a log platform provided in an embodiment of this application, as shown below. Figure 4 As shown, the user permission risk identification device 400 for the log platform may include: at least one processor 401, such as a CPU, at least one communication interface 403, a memory 404, and at least one communication bus 402. The communication bus 402 is used to implement communication between these components. The communication interface 403 may optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface or a Bluetooth interface), etc. The memory 404 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 404 may also be at least one storage device located remotely from the aforementioned processor 401. Figure 4 As shown, the memory 404, which serves as a computer storage medium, may include an operating system, a network communication module, and program instructions.

[0105] exist Figure 4 In the user permission risk identification device 400 for the log platform shown, the processor 401 can be used to load program instructions stored in the memory 404 and specifically execute any one of the user permission risk identification methods for the log platform in the above method embodiments.

[0106] It should be noted that the specific execution process can be found in the detailed description of the above method embodiments, and will not be elaborated here.

[0107] For specific execution steps, please refer to the description of the foregoing method embodiments, which will not be detailed here.

[0108] This application also provides a computer storage medium that can store multiple instructions. These instructions are adapted to be loaded and executed by a processor using the user permission risk identification method for a log platform provided in this application. For details of the execution process, please refer to the specific description of the method embodiments shown above, which will not be elaborated here.

[0109] This application also provides a computer program product containing instructions that, when run on an electronic device, cause the electronic device to execute the method steps of the method embodiments shown above.

[0110] This application also provides a chip module, including a transceiver component and a chip, wherein the chip is used to execute the method steps of the above-described method embodiments.

[0111] It is understood that the user permission risk identification system, device, computer storage medium, computer program, computer program product, and chip provided above for log platforms are all used to execute the methods shown in any implementation of the corresponding aspects of the embodiments of this application. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be detailed here.

[0112] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes the processes of the embodiments of the above methods.

[0113] The term "at least one" in this application refers to one or more items. "More than one item" means two or more items. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, it should be understood that although the terms "first," "second," etc., may be used to describe objects in this application, these objects should not be limited to these terms. These terms are only used to distinguish the objects from each other.

[0114] The terms “including” and “having” mentioned above, and any variations thereof, are intended to cover non-exclusive inclusion.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for identifying user permission risks in a log platform, characterized in that, The method includes: Determine the permission configuration information of the user to be evaluated. The permission configuration information includes the user information, role information, and permission information of the user to be evaluated. The permission information of the user to be evaluated includes the permissions of at least two roles. Based on the user's permission configuration information and the preset risk analysis task instruction template, determine the prompt words; The prompt words are input into the large language model to guide the large language model to perform semantic understanding and logical reasoning on the permission configuration information of the user to be evaluated, and to identify whether there is a risk of unauthorized access due to the combination of multiple role permissions. Obtain the risk analysis result response of the large language model in response to the prompt word output, and determine whether the permission configuration information of the user to be evaluated has an unauthorized risk due to the combination of multiple role permissions based on the risk analysis result response.

2. The method as described in claim 1, characterized in that, The user information includes user identification information and user organizational context information, wherein the organizational context information includes at least one of department, job level, and business line.

3. The method as described in claim 1 or 2, characterized in that, The preset risk analysis task instruction template is an analysis task instruction template for target type unauthorized risks, which include horizontal unauthorized risks and / or vertical unauthorized risks.

4. The method according to any one of claims 1 to 3, characterized in that, The prompt words are used to guide the large language model to perform at least one of the following analyses: Analyze whether the permission combinations of different roles of the user to be evaluated constitute a horizontal unauthorized access risk that would allow for related access across different business domains or data domains; The analysis examines whether the permissions held by the user to be evaluated constitute a risk of vertical overreach that exceeds the reasonable scope of their job level or responsibilities.

5. The method according to any one of claims 1 to 4, characterized in that, The prompt word is used to instruct the large language model to output the risk analysis result response containing risk existence indication information. In the case that the risk existence indication information shows that there is an unauthorized access risk, the risk analysis result response should also include the risk type, risk level and risk description of each identified risk, and the risk description is used to explain in detail how the combination of permissions leads to unauthorized access.

6. The method as described in claim 5, characterized in that, After obtaining the risk analysis result response of the large language model in response to the prompt word output, the method further includes: When the risk existence indication information indicates the existence of an unauthorized risk, a risk score for the first risk is calculated based on the risk type, risk impact scope, confidence level of the first risk, and job level of the user to be evaluated. The first risk is any unauthorized risk related to the user to be evaluated as indicated by the risk analysis result response. Based on the risk score of the first risk, a report on the unauthorized access risk of the target user's permission configuration information is output using the corresponding notification strategy. If the user to be evaluated has an unauthorized access risk, the user to be evaluated is the target user.

7. The method as described in claim 6, characterized in that, The risk score for the first risk is calculated based on the following formula: final_score = base_score * scope_weight * rank_weight + confidence_adjustment Wherein, base_score is the base score for the risk type, scope_weight is the weight coefficient for the scope of risk impact, rank_weight is the weight for the user's job level, and confidence_adjustment is the confidence score for the first risk.

8. The method as described in claim 6 or 7, characterized in that, If the risk existence indication information indicates the existence of unauthorized access risk, the risk analysis result response also includes specific permission adjustment suggestions, and the risk report also includes permission adjustment suggestions.

9. A user permission risk identification system for a log platform, characterized in that, Includes a module for performing the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed, performs the method according to any one of claims 1 to 8.

Images