Method for determining operation permissions and electronic device

Abstract

This application discloses a method and electronic device for determining operation permissions, relating to the field of computer technology. It determines whether an account currently possesses the permission to perform a target type of operation only when the importance level of the operation object is higher than a preset level. This is achieved by comprehensively utilizing the target probability determined by the account's historical operation sequence after the current login and the target credibility calculated based on the actual results obtained after executing historical operations. Therefore, it solves the technical problem in related technologies where the accuracy of operation permission definition is low due to the use of fixed account operation permission divisions, which fails to effectively prevent the execution of operations that do not match the operation type and account status, leading to system risks. It achieves the goal of accurately determining whether an account has operation permissions, thereby effectively preventing the account from executing operations that do not match its current status and operation type, and improving the technical effect of system security.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to methods for determining operating permissions and electronic devices. Background Technology

[0002] In related technologies, a static role-based access control mechanism is commonly used. This means that upon login, users are granted fixed menu access permissions or command execution permissions based on a pre-assigned role. The system only verifies whether a user has the necessary permissions based on their role. This approach makes it difficult to prevent operations that are incompatible with the type of operation and the account's status from being executed when an account experiences anomalies (such as theft, accidental operation, or internal violation) but the role permissions remain unchanged. This can lead to data loss or business interruption, resulting in system risks.

[0003] There is currently no effective solution to the above problems in the relevant technologies. Summary of the Invention

[0004] This application provides a method and electronic device for determining operation permissions, in order to at least solve the technical problem in the related technology that the accuracy of operation permission definition is low due to the use of fixed account operation permission division, which in turn cannot effectively prevent the execution of operations that do not match the type of operation and the status of the account, thus causing system risks.

[0005] This application provides a method for determining operation permissions, including: when it is detected that a target account needs to perform a target operation in a target system, determining the importance level of the target operation object, wherein the target account is an account currently logged into the target system; when it is determined that the importance level is greater than a preset level and there are historical operations, determining the target probability that the operation type of the target operation is a target type based on the historical operations, wherein the historical operations are operations performed by the target account after logging into the system this time, and the target type operation is an operation to suspend the execution of the target task; determining whether the target account has the permission to perform the target type operation based on the target probability and the target credibility of the target account, wherein the target credibility is determined based on the operation results of the historical operations.

[0006] This application also provides an operation permission determination device, comprising: a first determination module, used to determine the importance level of the operation object of the target operation when it is detected that the target account needs to perform a target operation in the target system, wherein the target account is an account currently logged into the target system; a second determination module, used to determine the target probability that the operation type of the target operation is a target type based on the historical operations when the importance level is determined to be greater than a preset level and there are historical operations, wherein the historical operations are operations performed by the target account after this login to the system, and the target type operation is an operation to suspend the execution of the target task; and a third determination module, used to determine whether the target account has the permission to perform the target type operation based on the target probability and the target credibility of the target account, wherein the target credibility is determined based on the operation results of the historical operations.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the method for determining any of the above-described operating permissions when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method for determining any of the above-described operation permissions.

[0009] This application also provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, it implements the steps of determining any of the above-described operation permissions.

[0010] This application utilizes the target account's historical operation sequence after the current login to determine the target probability of the target account performing the target type operation, only when the importance level of the operation object is higher than a preset level. This allows for a determination of the likelihood of the target account performing the target type operation based on its real-time status. Finally, the target probability is combined with the target credibility calculated based on the actual results obtained after executing historical operations to jointly determine whether the target account currently has the authority to perform the target type operation. This ensures that the determination of account operation permissions no longer relies solely on statically set role permissions, but is accurately determined based on the account's current credibility. Therefore, it solves the technical problem in related technologies where the use of fixed account operation permission divisions leads to low accuracy in defining operation rights, thus failing to effectively prevent the execution of operations that do not match the operation type and account status, resulting in system risks. It achieves the goal of accurately determining whether an account has the operation permissions, thereby effectively preventing accounts from performing operations that do not match their current status and operation type, and improving the technical effect of system security. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of a method for determining operation permissions according to an embodiment of this application;

[0013] Figure 2 This is a flowchart illustrating a method for determining operation permissions according to an embodiment of this application;

[0014] Figure 3 This is a flowchart illustrating a method for determining the login permissions of a target account according to an embodiment of this application;

[0015] Figure 4 This is a flowchart illustrating a method for determining the operation permissions of a target account according to an embodiment of this application;

[0016] Figure 5 This is a structural block diagram of an operation permission determination device according to an embodiment of this application;

[0017] Figure 6 This is a computer system architecture block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application. Furthermore, in the absence of conflict, the various embodiments and features in the embodiments of this application can be arbitrarily combined with each other in principle.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] According to one aspect of the embodiments of this application, a method for determining operation permissions is provided. Optionally, in this embodiment, the above method may be applied, but is not limited to, to applications such as... Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0021] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0022] The method for determining operation permissions in this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the method for determining operation permissions in this application embodiment can be executed by a client installed on the terminal device 102.

[0023] Taking the method for determining operation permissions in this embodiment, executed by terminal device 102 (server 104), as an example, Figure 2 This is a flowchart illustrating a method for determining operation permissions according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0024] Step S202: If it is detected that the target account needs to perform the target operation in the target system, determine the importance level of the target operation object, where the target account is the account currently logged into the target system;

[0025] Optionally, the execution subject of the method in this embodiment is a device with computing capabilities. This includes, but is not limited to, an access control server, security gateway, or management controller deployed within the target system, or a terminal device with access control decision-making capabilities.

[0026] Optionally, the target system in this embodiment is a platform with computing resources, data storage, and task processing capabilities. It can be a centralized monolithic architecture or a distributed microservice architecture. In actual use, the target system includes, but is not limited to: storage arrays / distributed storage systems used internally by enterprises, cloud computing platform resource scheduling centers, and financial transaction system back-ends.

[0027] Optionally, in this embodiment, the target account has already completed identity authentication and established a valid session in the target system. The target system can continuously track the behavioral trajectory of the target account during the session lifecycle of this login process. The target account may initiate various interaction requests with the target system through Secure Shell (SSH) command line, World Wide Web (WEB) management interface, Application Programming Interface (API), or client software.

[0028] Optionally, the target operation in this embodiment refers to the specific action that the target account wants to perform in the current session, including but not limited to click events in the graphical user interface (GUI), specific commands in the command line interface, function calls in the API, or the sending of data packets.

[0029] Optionally, in this embodiment, the operation object refers to the object on which the target operation is applied, including but not limited to specific volumes or pools in the storage system, and virtual machine instances or containers in computing resources. The operation object has a unique identifier (such as an ID).

[0030] Optionally, the importance level in this embodiment refers to the risk level predefined for the operation object, used to quantify the impact of operating on the object on task execution or target system performance. The importance level includes, but is not limited to, classification based on the object's business criticality, data sensitivity, and recovery difficulty (such as L1 Public, L2 Internal, L3 Confidential, L4 Top Secret, or Low, Medium, High, and Critical).

[0031] Step S204: If it is determined that the importance level is greater than the preset level and there are historical operations, the operation type of the target operation is determined as the target type based on the historical operations. The historical operations are the operations performed by the target account after logging into the system this time, and the target type operation is the operation of stopping the execution of the target task.

[0032] Optionally, in this embodiment, historical operations refer to a collection of operations performed sequentially by the target account in the current login session, from successful login to the current moment. Historical operations include not only the success or failure results of the operations, but also the contextual information of the operations, such as operation type, operation object, execution timestamp, operation time, mouse trajectory, and dependencies with previous operations.

[0033] Optionally, the target type in this embodiment is an operation that causes the currently ongoing task to be interrupted, data state to be rolled back, or system services to become unavailable. Target type operations include, but are not limited to, forcibly terminating a process, deleting a running core volume, disconnecting critical storage mappings, restarting cluster nodes, and reversing uncommitted transactions.

[0034] Optionally, the target probability in this embodiment is the probability value of the target account performing the target type operation next in the current historical operation sequence and context, which is a value between 0 and 1.

[0035] Step S206: Determine whether the target account has the authority to perform the target type operation based on the target probability and the target credibility of the target account. The target credibility is determined based on the operation results of historical operations.

[0036] Optionally, in this embodiment, the target credibility refers to the current credibility of the user dynamically assessed based on the actual results of the target account's historical operations in this login session and their impact on system performance. For example, if the target account's historical operations successfully fixed system alarms, optimized performance indicators, or completed standardized business processes, the credibility increases; if the target account's historical operations led to new alarms, increased system latency, abnormal resource consumption, or task failure, the credibility decreases.

[0037] The following example illustrates the method for determining operation permissions in this embodiment: Suppose that Zhang San, the administrator of a company's storage system, has the right to delete volumes upon initial login. During a Friday peak business period, he attempts to delete a critical data volume marked as L4 (Top Secret) that carries core business operations. The system first detects that the object being operated on is L4 (greater than the preset level), and then analyzes Zhang San's historical operation sequence after this login (e.g., first viewing multiple non-core volumes, then rapidly and continuously clicking to delete a core volume, with abnormally rapid mouse movements). It determines that the probability of him performing a high-risk operation is as high as 0.85 (greater than the first threshold). Since the probability is extremely high and the credibility of the target indicates that Zhang San does not currently have the permission to perform this deletion operation, the system refuses to execute the deletion command, thereby avoiding the loss of core data and business interruption.

[0038] This embodiment determines the target probability of an account performing a target type operation only when the importance level of the operation object is higher than a preset level, utilizing the target account's historical operation sequence after the current login. This allows for a determination of the likelihood of the target account performing the target type operation based on its real-time status. Finally, the target probability is combined with the target credibility calculated based on the actual results obtained after executing historical operations to jointly determine whether the target account currently has the authority to perform the target type operation. This ensures that the determination of account operation permissions no longer relies solely on statically set role permissions, but is accurately determined based on the account's current credibility. Therefore, it solves the technical problem in related technologies where using fixed account operation permission divisions leads to low accuracy in defining operation rights, thus failing to effectively prevent the execution of operations that do not match the operation type and account status, resulting in system risks. It achieves the goal of accurately determining whether an account has operation permissions, effectively preventing accounts from performing operations that do not match their current status and operation type, thereby improving system security.

[0039] In an exemplary embodiment, before determining the importance level of the target operation object when it is detected that the target account needs to perform a target operation in the target system, the method further includes: upon receiving a login request from the target account, obtaining the target account's environment parameters; determining the risk coefficient of the target account based on the matching relationship between the environment parameters and preset conditions; and determining whether to allow the target account to log in to the target system based on the comparison result between the risk coefficient and a preset risk threshold.

[0040] Optionally, the risk coefficient in this embodiment is a value obtained by quantitatively evaluating the environmental parameters of the target account, which is used to intuitively reflect the security risk level of this login request. The risk coefficient is a continuous value (such as a probability value between 0 and 1), and its calculation is based on the matching degree between the environmental parameters and the preset condition. For example, the risk coefficient is high when the environmental parameters completely conform to the historically commonly used features, and the risk coefficient decreases when an unfamiliar Internet Protocol Address (abbreviated as IP) or login in an abnormal time period occurs.

[0041] Optionally, the preset conditions in this embodiment may be pre-configured security rules, which are used to determine whether the environmental parameters are reasonable and determine the risk coefficient of the target account based on this. The preset conditions include a first preset condition (rules for network information, such as a trusted IP library and non-proxy access requirements), a second preset condition (rules for terminal information, such as a trusted device list, specific hardware fingerprints, and operating system compatibility requirements), and a third preset condition (rules for time information, such as the allowed login time window, maximum failed login frequency threshold, non-working time restriction, and reasonable login frequency). It should be noted that the preset conditions may be statically configured or dynamically generated based on a machine learning model, which is not limited in this embodiment.

[0042] Optionally, the preset risk threshold in this embodiment includes but is not limited to being set based on historical experience, or dynamically adjusted based on a machine learning model. For example, the preset risk threshold may be set to 0.3. When the risk coefficient s ≤ 0.3, the target account is at high risk, and the target account is prohibited from logging in to the target system; when the risk coefficient s > 0.3, a further risk threshold may be set to determine whether the target account can log in directly or needs to be verified before logging in, and the further set risk threshold needs to be greater than the preset risk threshold (for example, the further set risk threshold is 0.7, when 0.3 < s ≤ 0.7, the target account is at medium risk, and when the target account initiates a login request, account verification is required through methods such as SMS verification code, email verification code, face verification, etc., and the target account can log in to the target system only after the verification is passed; when s > 0.7, the target account is at low risk, and the target account can enter the target system without verification after initiating a login request).

[0043] Through this embodiment, before the target account logs in to the target system, a pre-login risk coefficient evaluation based on environmental parameters is required, which effectively prevents unauthorized login access requests from illegal network environments, so that potential illegal logins can be blocked before the account has any operation permissions, and the security of the system is improved.

[0044] In an exemplary embodiment, determining the risk coefficient of a target account based on the matching relationship between environmental parameters and preset conditions includes: parsing network information, terminal information, and time information from the environmental parameters, wherein the network information includes the environment type representing the network environment in which the target account is located, the terminal information includes the identifier representing the terminal used by the target account when sending the login request, and the time information includes the time and frequency at which the target account sends the login request; determining the first matching degree between the network information and the first preset condition, the second matching degree between the terminal information and the second preset condition, and the third matching degree between the time information and the third preset condition, wherein the preset conditions include the first preset condition, the second preset condition, and the third preset condition; and determining the risk coefficient of the target account based on the first matching degree, the second matching degree, and the third matching degree.

[0045] Optionally, the network information in this embodiment includes, but is not limited to, source IP address, IP network segment, proxy server information, network latency, and Domain Name System (DNS) resolution results. Terminal information includes, but is not limited to, device Media Access Control (MAC) address, device serial number, operating system type and version, and browser fingerprint. Time information includes, but is not limited to, the specific time the login request was initiated, the time interval since the last login, and the number of login attempts per unit time (i.e., login frequency).

[0046] In practical use, we can statistically analyze the time periods during which each account has used the target system since its inception, and label these time periods as frequently used based on clustering methods (using K-means clustering, where clusters with a high number of user logins within a given time period are considered common time periods). For example, 09:00-18:00 is considered a common time period, while other times are considered infrequently used. We can also statistically analyze the network segments of the client IPs used by each account since the target system's inception, and label these segments as common network segments (the criterion for determining a common network segment is that its frequency of occurrence exceeds a certain threshold, such as 50%). Furthermore, we can query the hardware information of the devices used by the current account to access the target system, such as MAC addresses and device serial numbers. Finally, we can statistically analyze the login frequency of each account since the target system's inception. Therefore, for each account that can log in to the target system, a login table is maintained, recording the account's common operation time periods, common client IP network segments, common devices, and common login frequencies. After receiving a login request from the target account, the system actively obtains the following information: the login request initiation time (i.e., the time information mentioned above), the identifier of the terminal used to initiate the current login request (i.e., the terminal information mentioned above), the client IP network segment used to identify the network environment where the target account is located (such as a company intranet, home broadband, data center, or public Wi-Fi) (i.e., the network information mentioned above), and the login frequency of the target account within a unit of time (i.e., the time information mentioned above, such as the number of login requests initiated within a day). These four pieces of information are compared with the records in the login table corresponding to the target account to determine the risk coefficient of the target account. The risk coefficient of the target account can be calculated using the following formula: s = m × T + n × P + i × D + j × F, where s represents the risk coefficient, T indicates whether the current login request initiation time falls within a frequently used operation period, P indicates whether the network environment where the target account is located is a frequently used client IP network segment, D indicates whether the terminal used by the target account to send the login request is a frequently used device, and F indicates whether the login frequency of the target account is a frequently used login frequency. The values ​​of T, P, D, and F are all 0 or 1, with 1 indicating frequent use and 0 indicating infrequent use. m is the weight of T, n is the weight of P, i is the weight of D, j is the weight of F, m+n+i+j=1, and the values ​​of n and i are higher than the values ​​of m and j.It should be noted that the values ​​of m, n, i, and j include, but are not limited to, those obtained by using historically accumulated real login log data as a training set. Each sample contains four dimensions of input features (discrete labels T, P, D, and F for operation time, client IP network segment, operating device used, and login frequency) and their corresponding known label results (i.e., actual processing results of manual annotation or system history: allowed login or prohibited login). The predicted score of the model is calculated using the formula s=m×T+n×P+i×D+j×F under the initial weights (m, n, i, j). This predicted score is then compared with the actual label results (e.g., mapping normal login to a score range above the high-risk threshold and prohibiting login to a score range below the low-risk threshold) to calculate the prediction error (e.g., mean squared error or classification loss). Subsequently, optimization algorithms such as backpropagation or gradient descent are used to adjust the results in reverse according to the error magnitude.

[0047] Figure 3 This is a flowchart illustrating a method for determining the login permissions of a target account according to an embodiment of this application. Figure 3 As shown, the following steps are performed to determine whether the target account can log in to the target system:

[0048] Step S302: After receiving the login request initiated by the target account, obtain the login request initiation time (i.e., the time information mentioned above), the identifier of the terminal used for the login request (i.e., the terminal information mentioned above), the client IP network segment used to identify the network environment where the target account is located (such as a company intranet, home broadband, data center, or public Wi-Fi) (i.e., the network information mentioned above), and the login frequency of the target account within a unit of time (i.e., the time information mentioned above, such as how many times a login request is initiated within a day). Based on the above four pieces of information, determine the values ​​1, 2, 3, and 4 respectively. Determine whether the initiation time is within a common time period, whether the terminal used by the target account to send the login request is a common device, whether the network environment where the target account is located is a common client IP network segment, and whether the login frequency of the target account is a common login frequency. If so, set the corresponding value to 1; otherwise, set the corresponding value to 0.

[0049] Step S304: Calculate the risk coefficient of the target account based on values ​​1, 2, 3, and 4. The risk coefficient is calculated using the formula s = m × value 1 + n × value 2 + i × value 3 + j × value 4, where s represents the risk coefficient, value 1 indicates whether the login request was initiated during a common operating time period, value 2 indicates whether the terminal used by the target account to send the login request is a common device, value 3 indicates whether the network environment of the target account is within a common client IP segment, and value 4 indicates whether the login frequency of the target account is a common login frequency. m, n, i, and j are weights, and m + n + i + j = 1, with the values ​​of n and i being higher than the values ​​of m and j.

[0050] Step S306: Determine whether the risk coefficient is greater than the first risk threshold.

[0051] Step S308: If the risk coefficient is greater than the first risk threshold, the target account is determined to be low-risk and can be accessed through the target system without verification.

[0052] Step S310: If the risk coefficient is less than or equal to the first risk threshold, determine whether the risk coefficient is less than the second risk threshold.

[0053] Step S312: If the risk coefficient is less than the second risk threshold, the target account is determined to be high-risk, and the target account is prohibited from logging into the target system.

[0054] Step S314: The target account is of medium risk and requires account verification via SMS verification code, email verification code, facial recognition, etc. Only after successful verification can the target account log in to the target system.

[0055] In an exemplary embodiment, before determining whether a target account has the authority to perform an operation of the target type based on the target probability and the target credibility of the target account, the method further includes: determining a first state of the target system before performing the historical operation, and determining a second state of the target system after performing the historical operation based on the operation result; determining the state difference between the second state and the first state; and determining the target credibility based on the state difference and the first credibility of the target account before performing the historical operation.

[0056] Optionally, in this embodiment, the first state and the second state refer to system snapshots of the target system before and after the execution of a specific historical operation. The first state records the system performance before the historical operation (e.g., system health indicators, resource load, alarm list, configuration parameters, and business operation status); the second state records the corresponding indicators after the historical operation. The state difference between the two refers to the quantitative change value obtained by comparing the first state and the second state, including but not limited to the rate of change of Central Processing Unit (CPU) / memory utilization, fluctuations in Input / Output Operations Per Second (IOPS), and the number of new error log entries. The state difference objectively reflects the actual impact (positive optimization or negative damage) of the historical operation on the system.

[0057] For example, a business process template table can be created in the database. This table records the sequence of steps in a standard operation flow (e.g., Process ID: 1, Process Name: Storage Mapping Host Operation Flow, Operation Steps: [Create Redundant Array of Independent Disks (RAID), Add Storage, Create Pool, Create Volume, Map Host]). When the sequence of operations performed by the target account matches the sequence of the standard operation flow by ≥75% (allowing other operations to be interspersed between two operations performed by the target account), the trustworthiness of the target account will be appropriately increased after the entire process is completed.

[0058] It should be noted that after the target account logs into the target system, each successful operation will determine the difference between the first state of the target system before the operation and the second state of the target system after the operation. Then, using the state difference and the first credibility of the target account before the operation, the target credibility of the target account after the operation is obtained.

[0059] This embodiment dynamically adjusts the trustworthiness of the target account by comparing the differences in system state before and after historical operations. This ensures that the permission assessment is based on the actual operation results, which can objectively reflect the real impact of the operations performed by the target account on system performance. This dynamically corrects the trustworthiness of the target account, making it easier to accurately determine the operation permissions of the target account in the future.

[0060] In an exemplary embodiment, before determining the target credibility based on the state difference and the first credibility of the target account before executing the historical operations, the method further includes: obtaining the target role attribute of the target account before executing all operations included in the historical operations; determining the basic credibility of the target account based on the target role attribute; and calculating the product of the basic value used to represent the basic credibility and the risk coefficient to obtain the first credibility.

[0061] Optionally, in this embodiment, the target role attribute refers to a static permission identifier bound to the target account, defining the account's basic capabilities within the system. The target role attribute includes, but is not limited to, super administrator, administrator, ordinary user, auditor, and custom role. The target role attribute determines the target account's basic trustworthiness (i.e., initial trust score). Generally, the basic trustworthiness of a super administrator is greater than that of an administrator, which is greater than that of an ordinary user, and the basic trustworthiness of an ordinary user is greater than that of an auditor. The basic trustworthiness of a custom role is calculated based on the average of its initial operational permissions. For example, an administrator, due to higher permissions, has a base score of 70 for basic trustworthiness, while an ordinary user has a base score of 40. A custom user's initial operational permissions fall between those of an administrator and an ordinary user, so their base score for basic trustworthiness is (70+40) / 2=55.

[0062] Optionally, before executing all operations included in the historical operations in this embodiment, the first credibility of the target account is equal to the base value representing the basic credibility multiplied by the risk coefficient. That is, the first credibility of the target account U_init = U_base × U_env, where U_base represents the basic credibility of the target account and U_env represents the aforementioned risk coefficient (which can also be called the user environment weight).

[0063] This embodiment combines static basic credibility with dynamic risk coefficients. The first credibility is determined by multiplication before all operations in the execution history are performed. The first credibility of the target account is determined by combining the initial role permissions of the target account (i.e., target role attributes) and the security risks at the time of login (for example, even if a high-privilege administrator logs in in a high-risk network environment, its first credibility will be reduced accordingly). This prevents high-privilege accounts from being used in high-risk environments, thereby avoiding system risks caused by the use of high-privilege accounts in high-risk environments.

[0064] In one exemplary embodiment, determining the target credibility based on the state difference and the first credibility of the target account before the historical operation includes: determining a reward score based on the degree of performance improvement of the target system when the state difference indicates that the historical operation improved the performance of the target system; and determining the sum of the reward score and a first value used to represent the first credibility as a first target value used to represent the target credibility.

[0065] In one exemplary embodiment, determining a target credibility based on a state difference and a first credibility of the target account before the execution of the historical operation includes: determining a penalty score based on the degree of performance degradation of the target system when the state difference indicates that the historical operation has reduced the performance of the target system; and determining a second target value for representing the target credibility by summing the penalty score with a first value representing the first credibility.

[0066] For example, the number of alarms and key metrics (such as latency) of the target system can be monitored in real time. When a target account repairs a system fault or clears alarms through certain operations, the target account's credibility will increase appropriately. If there was an "XX link anomaly alarm" before a historical operation, and the alarm was cleared after the historical operation, and this operation is directly related to the clearing of the XX link anomaly alarm, then the target account's initial credibility value will increase. If the target system's latency was 1 second before a historical operation, and the latency is reduced to 0.5 seconds through configuration optimization, then the target account's initial credibility value will also increase. Conversely, if a historical operation causes the system to generate new alarms or device metric anomalies, then the target account's initial credibility value will decrease depending on the severity.

[0067] In this embodiment, state differences manifest as reward points for performance improvements, positively incentivizing users to perform actions that enhance system performance (such as optimizing configurations or fixing faults), thereby increasing their target credibility. Conversely, when state differences manifest as system performance degradation, penalty points are deducted, indirectly restricting users from performing harmful or inefficient actions and promptly reducing their target credibility. Once a user's actions cause system performance deterioration, the target credibility of the corresponding account will decrease, leading to restrictions on subsequent operation permissions, further ensuring system security.

[0068] In one exemplary embodiment, determining whether a target account has the permission to perform a target type operation based on the target probability and the target credibility of the target account includes: determining that the target account has the permission to perform a target type operation when the target probability is less than or equal to a first threshold; and determining that the target account does not have the permission to perform a target type operation when the target probability is greater than the first threshold.

[0069] In one exemplary embodiment, determining that a target account has permission to perform a target type operation when the target probability is less than or equal to a first threshold includes: determining that the target account has permission to directly perform a target type operation in a target system in a real environment when the target probability is less than or equal to a second threshold, wherein the second threshold is less than the first threshold; and determining that the target account has permission to perform a target type operation in a target system in a simulated environment when the target probability is greater than the second threshold.

[0070] Optionally, in this embodiment, the first threshold and the second threshold are risk probability thresholds used to divide different security intervention levels. The first threshold is used to determine whether high-risk operations (such as abort operations) are allowed. If the value exceeds this threshold, the risk is considered uncontrollable and the operation is prohibited. The second threshold is used to distinguish between direct execution and sandbox simulation execution. If the value is below this threshold, it indicates that the intent is highly credible and can be operated directly in the real environment. If the value is between the first and second thresholds, it indicates that there is a certain risk and it needs to be verified in the simulation environment. If the operation in the simulation environment does not reduce the performance of the target system, the target type operation can be performed in the target system in the real environment.

[0071] Optionally, in this embodiment, the real environment refers to the production environment of the target system, which directly operates physical or virtual resources and has an actual business impact; the simulated environment (or shadow mode, sandbox mode) refers to a logically isolated space that mirrors or simulates the real environment. Operations performed in this environment will not directly affect production data or business services, but rather the results of simulated execution are used to predict the possible consequences of actual operations.

[0072] For example, if P represents the target probability, the first threshold is 0.5, and the second threshold is 0.3. If 0 ≤ P ≤ 0.3, the target account can execute the target type operation in the target system in the real environment; if 0.3 < P ≤ 0.5, the target account is isolated in a simulated container for operation, that is, the actual command issued is performed in the simulated container. If the result shows that the operation will cause the business (such as the target task) to be interrupted (such as insufficient remaining resources, shutdown service interruption), a warning message will pop up: "Your operation may cause the cluster to crash and has been automatically blocked." If the operation will not stop the business execution, the target type operation can be executed in the target system in the real environment; if 1 ≥ P > 0.5, the target account does not have the permission to execute the target type operation.

[0073] This embodiment allows execution in either a real environment or a simulated environment, depending on the different ranges of the target probability. For low-risk target accounts, execution is allowed directly in the target system of the real environment to ensure the task can be executed smoothly. For medium-risk target accounts, the target type operation is allowed to be executed in the target system of the simulated environment. Compared with completely blocking the execution of the target type operation, this provides a better user experience and operational flexibility.

[0074] In an exemplary embodiment, after determining that the target account has the authority to directly execute the target type operation in the target system in a real environment when the target probability is less than or equal to a second threshold, the method further includes: determining the target operation to be executed by the target account based on the click action triggered by the target account in the target system; determining the operation score required to execute the target operation based on the performance parameters of the target system; and determining whether the target account has the ability to execute the target operation based on the comparison result between the operation score and the target value used to represent the target credibility.

[0075] Optionally, in this embodiment, the operation score refers to the minimum trust score required to execute a specific target operation, used to dynamically control whether the target account has the permission to execute a certain operation. When the target account's current target trust level is greater than or equal to the operation score of the target operation, the target account is allowed to execute the target operation; when the target account's current target trust level is less than the operation score of the target operation, the target account is prohibited from executing the target operation.

[0076] In this embodiment, even if the predicted intention of the target account to perform the target type operation is low, it is still necessary to determine whether the target account has the actual operation permission based on the target account's target credibility and the operation score required for the target account to actually perform the target operation, thereby further accurately determining the target account's operation permission.

[0077] In an exemplary embodiment, after determining the importance level of the target operation object when it is detected that the target account needs to perform a target operation in the target system, the method further includes: if the importance level is determined to be less than or equal to a preset level, determining the target operation to be performed by the target account based on the click action triggered by the target account in the target system; determining the operation score required to perform the target operation based on the performance parameters of the target system; and determining whether the target account has the ability to perform the target operation based on the comparison result between the operation score and the target value used to represent the credibility of the target.

[0078] It should be noted that in actual use, even when the importance level is determined to be greater than the preset level, but historical operations exist, the above process is still executed. That is, the target operation to be performed by the target account is determined directly based on the click actions triggered by the target account in the target system; the operation score required to perform the target operation is determined based on the performance parameters of the target system; and the operation score is compared with the target value used to represent the credibility of the target to determine whether the target account has the ability to perform the target operation.

[0079] When the target account's current target credibility is greater than or equal to the target operation's operation score, the target account is allowed to execute the target operation; when the target account's current target credibility is less than the target operation's operation score, the target account is prohibited from executing the target operation.

[0080] In one exemplary embodiment, determining the operation score required to perform a target operation based on the performance parameters of the target system includes: determining the importance weight of the operation object based on the importance level; determining the support capability of the target system to perform the target operation based on the performance parameters of the target system to obtain a first weight; and determining the operation score by multiplying the importance weight, the first weight, and the initial score of the target operation, wherein the initial score is determined based on the degree of influence of the target operation on the performance of the target system.

[0081] Optionally, the operation score in this embodiment is calculated based on the importance weight of the operation object (e.g., core data has a high weight), the support capability weight of the target system (e.g., when the system load is high, stricter permissions are required to ensure stability), and the initial score of the operation (based on the preset base score of the operation type, such as the initial score of the delete operation being higher than that of the view operation).

[0082] Optionally, in this embodiment, the importance weight refers to the conversion result of mapping the importance level of the operation object to a numerical coefficient (such as 0.2, 0.5, etc.). The numerical range of the importance weight is (0, 1). Of course, in actual use, the numerical range can also be set according to the actual situation, and this embodiment does not limit this. The importance weight reflects the degree of influence of the static attributes of the operation object itself on system security. The higher the level of the object, the greater its weight, resulting in a higher final operation score, thus requiring the account to have a higher target credibility to execute the relevant operation. The importance weight can be fixed or dynamically adjusted according to the business scenario (for example, during disaster recovery drills, the weight of core backup objects may be temporarily reduced to allow more maintenance operations).

[0083] Optionally, the performance parameters of the target system in this embodiment refer to parameters that reflect the current operating status, resource load, and health of the target system, and are used to evaluate the system's carrying capacity when performing the target operation. Performance parameters include, but are not limited to, CPU utilization, memory usage, disk IOPS, network bandwidth utilization, queue depth, average response latency, error rate, and number of system alarms.

[0084] Optionally, the support capability in this embodiment refers to the system's ability to perform a certain operation, quantified based on the current performance parameters of the target system. The first weight is usually negatively correlated with the system load. When the system load is low and resources are abundant, the first weight is higher (e.g., 0.8 or 1.0); while when the system detects high load, hard disk failure, or performance bottleneck, the first weight will automatically decrease (e.g., 0.5 or lower). The value range of the first weight is (0, 1). Of course, in actual use, the value range can also be set according to the actual situation, and this embodiment does not limit this. For example, when the system's IOPS is greater than a certain threshold, for any operation involving writing data, deleting, creating, or modifying, the first weight B_env is automatically increased to 0.5 to prevent large-scale business interruption caused by insufficient system performance when performing these operations; when a hard disk failure or wear level of 95% is detected in the system, the first weight of the target operation of the pool and volume related to the operation of that hard disk is automatically increased to the maximum value, so that the target value used to represent the target trustworthiness of the target account can never be reached; when the system is idle and there are no alarms, the first weight B_env is decreased to 0.8, allowing the operation to proceed more smoothly.

[0085] Optionally, the initial score in this embodiment refers to a predefined basic risk score for the target operation. The initial score reflects the degree to which the operation itself changes the system state, without considering the current system state. For example, the initial score for viewing logs might be 5 points, the initial score for modifying normal configuration might be 30 points, the initial score for deleting a volume might be 80 points, and the initial score for restarting the cluster might be 95 points. For example, backup in the backup and restore module can be performed by both the super administrator and the administrator, but the restore operation in the backup and restore module can only be performed by the super administrator. Table 1 shows the grading standards and preset score ranges corresponding to each level of operation. The levels in the first column are classified according to the potential degree or scope of damage or impact of the operation on the data integrity, business continuity, and system stability of the target system. These levels typically include viewing level, operation level, configuration level, and high-risk level, each representing a different risk. A lenient trust mechanism is adopted for low-level operations, while strict control is implemented for high-level operations. The impact descriptions in the second column define the consequences of actions corresponding to a specific operation level, clarifying the specific changes that the operation at this level brings to the system at both the logical and physical levels: "Read Only" describes read-only behavior with no state change; "Modify Personal Configuration" describes changes to localized, non-critical data; "Business Configuration" describes changes to data involving resources or core logic; and "Affect Data Security or Business Continuity" describes data changes that may lead to data loss, service interruption, or system crashes. The typical operation examples in the third column refer to representative and common specific operations under this operation level, helping system administrators or developers understand the specific scope of this level. For example, viewing volume details is a typical read-only query. The preset score range in the fourth column refers to the pre-set basic risk score range (e.g., 0-20, 21-40, etc.) for operations under this level, used to quantify the initial score of the operation at this level. The higher the initial score, the greater the potential threat that the operation type itself poses to the system. The initial score range is [1, 100].

[0086] Table 1:

[0087]

[0088] In practical use, a module role table can be created in the database to record the modules that each role attribute can operate, as well as the operations included in the modules; and an operation button table can be created to record the web page element identifier, button name, corresponding command, module, level, and base score of each operation.

[0089] Optionally, in this embodiment, the operation score B_cur required to perform the target operation is B_base × O_imp × B_env, where O_imp represents the importance weight, B_env represents the first weight, and B_base represents the initial score of the target operation.

[0090] In this embodiment, the operation score required to execute the target operation is determined by comprehensively considering the importance weight of the operation object, the support capability of the target system to execute the target operation, and the initial score of the target operation. The operation score required to execute the target operation can be dynamically adjusted based on the real-time load of the system, thereby more effectively ensuring the security of the target system.

[0091] In an exemplary embodiment, when the importance level is determined to be greater than a preset level and historical operations exist, determining the target probability that the operation type of the target operation is the target type based on the historical operations includes: performing a vector transformation operation on the target text used to record historical operations and the execution time of the historical operations to obtain a target feature vector sequence; determining a state vector representing the current operation intent of the target account based on the target feature vector sequence; calculating the matching degree between the state vector and each candidate feature vector to obtain at least one fourth matching degree, wherein the candidate feature vector is the feature vector of the operation type of the target type, and different candidate feature vectors correspond to different operations under the target type; and performing a normalization operation on the fourth matching degree to obtain the target probability.

[0092] Optionally, in this embodiment, the target feature vector sequence refers to the numerical sequence obtained by converting the historical operation logs (including text or structured data such as operation type, timestamp, and preceding operations) generated by the target account after this login through natural language processing. The target feature vector sequence preserves the temporal order and semantic association of historical operations and can capture the pattern features of the account's operation behavior. For example, the operation of creating a volume is immediately followed by the operation of formatting a volume, or the operation of creating a volume is immediately followed by the operation of mounting a volume.

[0093] Optionally, the state vector in this embodiment includes, but is not limited to, the operational intent of the target account at the current moment obtained by encoding the target feature vector sequence through a temporal model (such as a recurrent neural network (RNN) or a long short-term memory network (LSTM)).

[0094] Optionally, in this embodiment, the candidate feature vector refers to a vector pre-stored in the system representing various known target types of operations. By calculating the distance or similarity (i.e., the fourth matching degree) between the current state vector and each candidate feature vector, the degree of closeness between the target account's operational intent and known target types of operations is determined. The higher the fourth matching degree, the more likely the target account is to want to perform a certain target type of operation, thus outputting a higher target probability. In practical use, the candidate feature vector represents some target types of operations. For example, the target account's most recent historical operation is clicking the first menu, which includes operations such as modifying user basic information, modifying data type, and deleting data. Among these, modifying data type and deleting data are target type operations. Therefore, based on historical operations, the target probability determined is that the target account will perform the operations of modifying data type and deleting data.

[0095] In practical applications, the target probability can be determined by using a sequence prediction model to identify the target operation type based on historical operations. The input layer of the sequence prediction model converts the target text execution vector, which records historical operations and their execution times, into a sequence of target feature vectors. The target text includes both discrete and continuous behavioral features of the target account. Discrete features include operation button text (create volume, modify configuration), element identifiers, corresponding commands, and the module to which they belong; continuous features include page dwell time, mouse movement speed, etc. The encoding layer of the sequence prediction model determines a state vector representing the current operational intent of the target account based on the target feature vector sequence and automatically learns the association between different historical operations and the target type operation. The output layer of the sequence prediction model calculates the matching degree between the state vector and each candidate feature vector, obtaining at least one fourth matching degree, and performs a normalization operation on the fourth matching degree to obtain the target probability. The output layer of the sequence prediction model can calculate the target probability P using the formula P=S(Wseq×Hseq+Wstay×Hstay+Wmouse×Hmouse+B), where S is the Sigmoid activation function, Hseq represents the historical operation sequence feature vector, referring to the historical operations performed by the target account after logging into the target system (such as clicked button names, element identifiers, corresponding commands, etc.), Hstay represents the dwell time feature vector, which is the continuous time feature such as the duration of page dwell, thinking delay, or mouse hover time before the target account performs the historical operation, and Hmouse represents the mouse trajectory feature vector, which is the continuous behavioral feature such as the mouse movement speed of the target account during the operation. Wseq is the dynamic weight coefficient corresponding to Hseq, Wstay is the dynamic weight coefficient corresponding to Hstay, and Wmouse is the dynamic weight coefficient corresponding to Hmouse. These weights are automatically learned by the model during training and reflect the relative importance of different behavioral dimensions (operation sequence, temporal behavior, spatial trajectory) in predicting the operational intent of the target type operation. B is a constant term introduced in the sequence prediction model, which reflects the prior probability that the target account will perform the target type operation when there are no specific behavioral feature inputs or all feature inputs are zero.

[0096] This embodiment utilizes vector transformation and matching degree to determine the probability of a target account performing a target type operation based on historical operations. It can capture the temporal dependencies and logical connections between historical operations, thereby more accurately predicting the target probability of a target account performing a target type operation and improving the accuracy of determining the probability of a target account performing a target type operation.

[0097] In an exemplary embodiment, after determining that the target account does not have permission to perform the target type operation when the target probability is greater than a first threshold, the method further includes: performing a cleanup operation on the target account and prohibiting the target account from logging into the target system within a preset time period when the target probability is greater than a third threshold, wherein the third threshold is greater than the first threshold; and hiding the button for performing the target type operation in the target system when the target probability is less than or equal to the third threshold.

[0098] Optionally, the cleanup operation in this embodiment refers to the measures taken to forcibly terminate the session and isolate resources for high-risk accounts, including but not limited to immediately disconnecting all current network connections and logging out of the current login session.

[0099] For example, in practical use, if P represents the above target probability, the first threshold is 0.5, the second threshold is 0.3, and the third threshold is 0.7. If 0 ≤ P ≤ 0.3, the target account can execute the target type operation in the target system in the real environment. If 0.3 < P ≤ 0.5, the target account is isolated in a simulated container for operation, meaning the actual commands are executed in the simulated container. If the result shows that the operation will cause business (such as the target task) to be interrupted (e.g., insufficient remaining resources, service interruption due to shutdown), a warning message will pop up: "Your operation may cause the cluster to crash and has been automatically blocked." If the operation will not stop business execution, the target type operation can be executed in the target system in the real environment. If 0.5 < P ≤ 0.7, the front-end interface elements are dynamically reconstructed, the display content and interaction logic of the front-end interface are changed in real time, and buttons related to the target type operation in the front-end interface are automatically grayed out or hidden, physically cutting off the target account from executing the target type operation. If the probability that the target account will execute the operation of exporting and deleting core data is predicted to be 1 ≥ P > 0.7, the target account is directly forced offline and locked for 30 minutes (during the lockout period, no operation can be performed, including login).

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0101] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0103] The above method is described below through a specific embodiment. In a storage system operation and maintenance scenario, the target account is Zhang San, an operation and maintenance engineer with the "administrator" role, and the target system is a distributed storage cluster. Figure 4 This is a flowchart illustrating a method for determining the operation permissions of a target account according to an embodiment of this application. The system determines whether the target account has the permission to perform the target operation by executing the following steps:

[0104] Step S402: It is detected that the target account has selected the core data pool (i.e. the above-mentioned operation object) in the management interface, and the importance level of the core data pool is determined.

[0105] Step S404: Based on the preset data classification strategy, determine the importance level of the core data pool as the highest level (L4), and determine that the importance level of the core data pool is greater than the preset level (L3).

[0106] Step S406: Since Zhang San performed the operations of exporting the core volume mapping file and "pausing business IO" after this login, it is determined that there are historical operations. Based on the historical operations, the operation type of the target operation is determined to be the target type of the target probability.

[0107] Step S408: Determine whether the target probability is greater than the first threshold;

[0108] Step S410: If the target probability is less than or equal to the first threshold, determine whether the target probability is greater than the second threshold, wherein the second threshold is less than the first threshold.

[0109] Step S412: If the target probability is less than or equal to the second threshold, determine that the target account has the permission to directly execute the target type operation in the target system in the real environment, and then execute step S424.

[0110] Step S414: If the target probability is greater than the first threshold, determine whether the target probability is greater than the third threshold, wherein the third threshold is greater than the first threshold.

[0111] Step S416: If the target probability is greater than the third threshold, perform a cleanup operation on the target account and prohibit the target account from logging into the target system within a preset time period;

[0112] Step S418: If the target probability is less than or equal to the third threshold, hide the button for performing the target type operation in the target system, and then proceed to step S424.

[0113] Step S420: If the target probability is greater than the second threshold, determine that the target account has the permission to perform target type operations in the target system in the simulated environment;

[0114] Step S422: Perform the target type operation in the target system in the simulated environment. Based on the operation result, determine that the target account can perform the target type operation in the target system in the real environment. Then proceed to step S424.

[0115] Step S424: Based on the click actions triggered by the target account in the target system, determine the target operation to be performed by the target account;

[0116] Step S426: Based on the performance parameters of the target system, determine the number of operations required to perform the target operation;

[0117] Step S428: Based on the comparison between the operation score and the target value used to represent the target credibility, determine whether the target account has the ability to execute the target operation. When the target account's current target credibility is greater than or equal to the operation score of the target operation, the target account is allowed to execute the target operation; when the target account's current target credibility is less than the operation score of the target operation, the target account is prohibited from executing the target operation.

[0118] Through the above embodiments, the target probability of the target account performing a target type of operation is determined by combining the importance level of the operation object and the target account's historical operation sequence after this login. This target probability is then combined with the target account's target credibility to jointly determine whether the target account currently has the authority to perform the target type of operation, making the determination of account operation permissions more accurate. Furthermore, after actually knowing the target operation that the target account needs to perform, the target credibility is compared with the operation score of the target operation to further confirm whether the target account truly has the authority to perform the target operation. This effectively avoids major data security incidents to the target system due to account theft or malicious damage by internal personnel, thus improving the security of the storage system.

[0119] According to another aspect of the embodiments of this application, a communication establishment apparatus is also provided. This apparatus can be used to implement the operation permission determination method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0120] Figure 5 This is a structural block diagram of an operation permission determination device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0121] The first determining module 52 is used to determine the importance level of the target operation object when it is detected that the target account needs to perform the target operation in the target system, wherein the target account is the account currently logged into the target system;

[0122] The second determining module 54 is used to determine the target probability that the operation type of the target operation is the target type based on the historical operations when the determination importance level is greater than the preset level and there are historical operations. The historical operations are the operations performed by the target account after logging into the system this time, and the target type operation is the operation of suspending the execution of the target task.

[0123] The third determining module 56 is used to determine whether a target account has the authority to perform the target type operation based on the target probability and the target credibility of the target account. The target credibility is determined based on the operation results of historical operations.

[0124] It should be noted that the first determining module 52 in this embodiment can be used to execute the above-described step S202, the second determining module 54 in this embodiment can be used to execute the above-described step S204, and the third determining module 56 in this embodiment can be used to execute the above-described step S206. For a description of the features corresponding to the operation permission determining device in the embodiment, please refer to the relevant description of the operation permission determining method in the embodiment, which will not be repeated here.

[0125] The embodiments provided in this application determine the target probability of a target account performing a target type operation only when the importance level of the operation object is higher than a preset level. This allows for the determination of the likelihood of the target account performing the target type operation based on the real-time status of the target account. Finally, the target probability is combined with the target credibility calculated based on the actual results obtained after performing historical operations to jointly determine whether the target account currently has the authority to perform the target type operation. This ensures that the determination of account operation permissions no longer relies solely on statically set role permissions but is accurately determined based on the account's current credibility. Therefore, this addresses the technical problem in related technologies where the use of fixed account operation permission divisions leads to low accuracy in defining operation rights, which in turn fails to effectively prevent the execution of operations that do not match the operation type and account status, thus causing system risks. This achieves the goal of accurately determining whether an account has operation permissions, effectively preventing accounts from performing operations that do not match their current status and operation type, thereby improving the system's security.

[0126] In an exemplary embodiment, the first determining module 52 is further configured to, before determining the importance level of the target operation object when it is detected that the target account needs to perform a target operation in the target system, obtain the environmental parameters of the target account upon receiving the login request of the target account; determine the risk coefficient of the target account based on the matching relationship between the environmental parameters and preset conditions; and determine whether to allow the target account to log in to the target system based on the comparison result between the risk coefficient and the preset risk threshold.

[0127] In an exemplary embodiment, the first determining module 52 is further configured to parse network information, terminal information, and time information from environmental parameters, wherein the network information includes an environment type representing the network environment in which the target account is located, the terminal information includes an identifier representing the terminal used by the target account when sending a login request, and the time information includes the time and frequency at which the target account sends a login request; determine a first degree of matching between the network information and a first preset condition, a second degree of matching between the terminal information and a second preset condition, and a third degree of matching between the time information and a third preset condition, wherein the preset conditions include the first preset condition, the second preset condition, and the third preset condition; and determine the risk coefficient of the target account based on the first degree of matching, the second degree of matching, and the third degree of matching.

[0128] In an exemplary embodiment, the first determining module 52 is further configured to determine, before determining whether the target account has the authority to perform the target type operation based on the target probability and the target credibility of the target account, a first state of the target system before performing the historical operation, and a second state of the target system after performing the historical operation based on the operation result; determine the state difference between the second state and the first state; and determine the target credibility based on the state difference and the first credibility of the target account before performing the historical operation.

[0129] In an exemplary embodiment, the first determining module 52 is further configured to obtain the target role attribute of the target account before determining the target credibility based on the state difference and the first credibility of the target account before executing all operations included in the historical operations; determine the basic credibility of the target account based on the target role attribute; and calculate the product of the basic value used to represent the basic credibility and the risk coefficient to obtain the first credibility.

[0130] In an exemplary embodiment, the first determining module 52 is further configured to determine a reward score based on the degree of performance improvement of the target system when the state difference indicates that the historical operation has improved the performance of the target system; and to determine the sum of the reward score and the first value used to represent the first credibility as the first target value used to represent the target credibility.

[0131] In an exemplary embodiment, the first determining module 52 is further configured to determine a penalty score based on the degree of performance degradation of the target system when the state difference indicates that historical operations have reduced the performance of the target system; and to determine the sum of the penalty score and a first value used to represent the first credibility as a second target value used to represent the target credibility.

[0132] In an exemplary embodiment, the third determining module 56 is further configured to determine that the target account has the permission to perform the target type operation when the target probability is less than or equal to the first threshold; and to determine that the target account does not have the permission to perform the target type operation when the target probability is greater than the first threshold.

[0133] In an exemplary embodiment, the third determining module 56 is further configured to determine that the target account has the permission to directly execute target type operations in a target system in a real environment when the target probability is less than or equal to the second threshold, wherein the second threshold is less than the first threshold; and to determine that the target account has the permission to execute target type operations in a target system in a simulated environment when the target probability is greater than the second threshold.

[0134] In an exemplary embodiment, the third determining module 56 is further configured to, after determining that the target account has the authority to directly execute the target type operation in the target system in a real environment when the target probability is less than or equal to the second threshold, determine the target operation to be executed by the target account based on the click action triggered by the target account in the target system; determine the operation score required to execute the target operation based on the performance parameters of the target system; and determine whether the target account has the ability to execute the target operation based on the comparison result between the operation score and the target value used to represent the target credibility.

[0135] In an exemplary embodiment, the third determining module 56 is further configured to, upon detecting that the target account needs to perform a target operation in the target system, determine the importance level of the operation object of the target operation, and if the importance level is less than or equal to a preset level, determine the target operation to be performed by the target account based on the click action triggered by the target account in the target system; determine the operation score required to perform the target operation based on the performance parameters of the target system; and determine whether the target account has the ability to perform the target operation based on the comparison result between the operation score and the target value used to represent the credibility of the target.

[0136] In an exemplary embodiment, the third determining module 56 is further configured to determine the importance weight of the operation object based on the importance level; determine the support capability of the target system to perform the target operation based on the performance parameters of the target system to obtain the first weight; and determine the operation score by multiplying the importance weight, the first weight, and the initial score of the target operation, wherein the initial score is determined based on the degree of influence of the target operation on the performance of the target system.

[0137] In an exemplary embodiment, the second determining module 54 is further configured to perform a vector transformation operation on the target text used to record historical operations and the execution time of the historical operations to obtain a target feature vector sequence; determine a state vector representing the current operation intention of the target account based on the target feature vector sequence; calculate the matching degree between the state vector and each candidate feature vector to obtain at least one fourth matching degree, wherein the candidate feature vector is a feature vector of an operation of the target type, and different candidate feature vectors correspond to different operations under the target type; and perform a normalization operation on the fourth matching degree to obtain the target probability.

[0138] In an exemplary embodiment, the third determining module 56 is further configured to, after determining that the target account does not have the permission to perform the target type operation when the target probability is greater than the first threshold, perform a clearing operation on the target account and prohibit the target account from logging into the target system within a preset time period when the target probability is greater than the third threshold, wherein the third threshold is greater than the first threshold; and hide the button for performing the target type operation in the target system when the target probability is less than or equal to the third threshold.

[0139] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0140] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps in the method embodiment for determining any of the above-described operation permissions via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0141] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described methods for determining operation permissions when it is run.

[0142] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0143] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for determining operating permissions.

[0144] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described methods for determining operating permissions.

[0145] According to another aspect of the embodiments of this application, a computer program product is also provided, which includes a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0146] Figure 6 This is a computer system architecture block diagram of an electronic device according to an embodiment of this application. For example... Figure 6 As shown, the computer system includes a CPU (corresponding to...) Figure 6 The central processing unit 601 in the ROM (corresponding to Figure 6 The program is stored in the read-only memory 602 or loaded from the storage section 608 into the RAM (corresponding to the read-only memory 602). Figure 6 The system executes various appropriate actions and processes by storing programs in the random access memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The central processing unit 601, the read-only memory 602, and the RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0147] The following components are connected to the I / O interface (corresponding to...) Figure 6The input / output interface 605 includes an input section 606 such as a keyboard and mouse; an output section 607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 608 including a hard disk; and a communication section 609 including network interface cards such as LAN cards and modems. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0148] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs various functions defined in the system of this application.

[0149] It should be noted that, Figure 6 The computer system of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0150] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a CPU, a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a System on Chip (SoC), a Complex Programmable Logic Device (CPLD), a Microcontroller Unit (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, application program, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0151] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0152] The foregoing has provided a detailed description of a method for determining operating permissions and an electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for determining operation permissions, characterized in that, include: If it is detected that a target account needs to perform a target operation in the target system, the importance level of the target operation object is determined, wherein the target account is the account currently logged into the target system; If it is determined that the importance level is greater than the preset level and there are historical operations, the target probability of the operation type of the target operation is determined based on the historical operations. The historical operations are the operations performed by the target account after logging into the system this time, and the operation of the target type is the operation of suspending the execution of the target task. Based on the target probability and the target credibility of the target account, it is determined whether the target account has the authority to perform the operation of the target type, wherein the target credibility is determined based on the operation results of the historical operations.

2. The method according to claim 1, characterized in that, Before determining the importance level of the target operation object when it is detected that the target account needs to perform a target operation in the target system, the method further includes: Upon receiving a login request for the target account, obtain the environment parameters of the target account; Based on the matching relationship between the environmental parameters and preset conditions, the risk coefficient of the target account is determined; Based on the comparison between the risk coefficient and the preset risk threshold, it is determined whether the target account is allowed to log in to the target system.

3. The method according to claim 2, characterized in that, Based on the matching relationship between the environmental parameters and preset conditions, the risk coefficient of the target account is determined, including: Network information, terminal information, and time information are parsed from the environmental parameters. The network information includes the environment type representing the network environment in which the target account is located. The terminal information includes the identifier of the terminal used by the target account when sending the login request. The time information includes the time and frequency at which the target account sends the login request. The first matching degree between the network information and the first preset condition, the second matching degree between the terminal information and the second preset condition, and the third matching degree between the time information and the third preset condition are determined respectively, wherein the preset conditions include the first preset condition, the second preset condition, and the third preset condition; The risk coefficient of the target account is determined based on the first matching degree, the second matching degree, and the third matching degree.

4. The method according to claim 2, characterized in that, Before determining whether the target account has the permission to perform the operation of the target type based on the target probability and the target credibility of the target account, the method further includes: Determine a first state of the target system before executing the historical operation, and determine a second state of the target system after executing the historical operation based on the operation result; Determine the state difference between the second state and the first state; The target credibility is determined based on the state difference and the first credibility of the target account before the execution of the historical operation.

5. The method according to claim 4, characterized in that, Before determining the target credibility based on the state difference and the first credibility of the target account before performing the historical operation, the method further includes: Before executing all operations included in the historical operations, obtain the target role attributes of the target account; Based on the target role attributes, determine the basic credibility of the target account; The first confidence level is obtained by multiplying the base value used to represent the basic confidence level by the risk coefficient.

6. The method according to claim 4, characterized in that, Based on the state difference and the first credibility of the target account before executing the historical operation, the target credibility is determined, including: When the state difference indicates that the historical operation improved the performance of the target system, a reward score is determined based on the degree of performance improvement of the target system. The sum of the reward score and the first value used to represent the first credibility is determined as the first target value used to represent the target credibility.

7. The method according to claim 4, characterized in that, Based on the state difference and the first credibility of the target account before executing the historical operation, the target credibility is determined, including: When the state difference indicates that the historical operation has reduced the performance of the target system, a penalty score is determined based on the degree of performance reduction of the target system. The sum of the penalty score and the first value used to represent the first credibility is determined as the second target value used to represent the target credibility.

8. The method according to claim 1, characterized in that, Determining whether the target account has the authority to perform the target type operation based on the target probability and the target account's target credibility includes: If the target probability is less than or equal to a first threshold, it is determined that the target account has the permission to perform the operation of the target type; If the target probability is greater than the first threshold, it is determined that the target account does not have the permission to perform the operation of the target type.

9. The method according to claim 8, characterized in that, If the target probability is less than or equal to a first threshold, determine that the target account has the permission to perform the operation of the target type, including: If the target probability is less than or equal to a second threshold, it is determined that the target account has the permission to directly execute the target type of operation in the target system in a real environment, wherein the second threshold is less than the first threshold; If the target probability is greater than the second threshold, it is determined that the target account has the permission to perform the target type operation in the target system in a simulated environment.

10. The method according to claim 9, characterized in that, If the target probability is less than or equal to a second threshold, and after determining that the target account has the permission to directly execute the target type of operation in the target system in a real environment, the method further includes: Based on the click actions triggered by the target account in the target system, the target operation to be performed by the target account is determined; Based on the performance parameters of the target system, determine the number of operations required to perform the target operation; Based on the comparison between the operation score and the target value used to represent the credibility of the target, it is determined whether the target account has the ability to perform the target operation.

11. The method according to claim 1, characterized in that, If it is detected that a target account needs to perform a target operation in a target system, after determining the importance level of the target operation's target object, the method further includes: If the importance level is determined to be less than or equal to the preset level, the target operation to be performed by the target account is determined based on the click action triggered by the target account in the target system. Based on the performance parameters of the target system, determine the number of operations required to perform the target operation; Based on the comparison between the operation score and the target value used to represent the credibility of the target, it is determined whether the target account has the ability to perform the target operation.

12. The method according to claim 10 or 11, characterized in that, Based on the performance parameters of the target system, determine the operation score required to perform the target operation, including: The importance weight of the operation object is determined based on the importance level; Based on the performance parameters of the target system, the support capability of the target system to perform the target operation is determined, and a first weight is obtained; The operation score is determined by multiplying the importance weight, the first weight, and the initial score of the target operation, wherein the initial score is determined based on the degree of impact of the target operation on the performance of the target system.

13. The method according to claim 1, characterized in that, If the importance level is determined to be greater than a preset level, and historical operations exist, the target probability that the operation type of the target operation is the target type is determined based on the historical operations, including: Perform a vector transformation operation on the target text used to record the historical operations and the execution time of the historical operations to obtain a target feature vector sequence; Based on the target feature vector sequence, a state vector representing the current operational intent of the target account is determined; Calculate the matching degree between the state vector and each candidate feature vector to obtain at least one fourth matching degree, wherein the candidate feature vector is the feature vector of the operation type of the target type, and different candidate feature vectors correspond to different operations under the target type; Perform a normalization operation on the fourth matching degree to obtain the target probability.

14. The method according to claim 8, characterized in that, After determining that the target account does not have permission to perform the operation of the target type when the target probability is greater than the first threshold, the method further includes: If the target probability is greater than a third threshold, the target account is terminated and prohibited from logging into the target system within a preset time period, wherein the third threshold is greater than the first threshold; If the target probability is less than or equal to the third threshold, the button for performing the operation of the target type is hidden in the target system.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for determining operating permissions as described in any one of claims 1 to 14 when executing the computer program.

Images