Method and apparatus for managing rights

Abstract

The application discloses a permission management method and device, and relates to the technical field of network security. In the case that an operation request from a request initiator is received, an electronic device can acquire initiator features of the request initiator and request features of the operation request, the initiator features including at least one of identity features, device features, environment features, behavior features and historical violation features, and determine a trust level of the request initiator according to the initiator features and the request features, so that the electronic device can perform permission management on the operation request according to a permission management strategy corresponding to the trust level; the permission management strategy includes any one of the following: granting the operation request complete permission; granting the operation request partial permission; initiating a secondary authentication process for the request initiator; intercepting the operation request and outputting alarm information.

Description

Technical Field

[0001] This application belongs to the field of network security technology, specifically relating to a method and apparatus for access control. Background Technology

[0002] Currently, electronic devices can authenticate the identity of the access requester. Once authentication is successful, the electronic device can grant the access requester full permissions and execute corresponding operations based on the various operation requests sent by the access requester, thereby enabling mobile office, remote collaboration, and other functions.

[0003] However, there is a possibility that after identity authentication is successful, the account of the requester may be stolen. In this case, since the electronic device has granted the requester full permissions, the electronic device will still execute the corresponding operations according to the various operation requests sent by the requester. This may lead to the leakage of privacy data, resulting in poor network security. Summary of the Invention

[0004] The purpose of this application is to provide a permission management method and apparatus that can improve network security.

[0005] In a first aspect, embodiments of this application provide a permission management method, which includes: upon receiving an operation request from a request initiator, an electronic device can obtain the initiator characteristics of the request initiator and the request characteristics of the operation request. The initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. Based on the initiator characteristics and request characteristics, the electronic device determines the trust level of the request initiator, thereby enabling the electronic device to perform permission management on the operation request according to the permission management policy corresponding to the trust level. The permission management policy includes any one of the following: granting the operation request full permissions; granting the operation request partial permissions; initiating a secondary authentication process for the request initiator; and intercepting the operation request and outputting alarm information.

[0006] Secondly, embodiments of this application provide a permission management device, comprising: an acquisition module, configured to acquire, upon receiving an operation request from a request initiator, the initiator's characteristics and the operation request's request characteristics, wherein the initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics; a determination module, configured to determine the trust level of the request initiator based on the initiator characteristics and request characteristics acquired by the acquisition module; and a management module, configured to perform permission management on the operation request according to the permission management policy corresponding to the trust level determined by the determination module; wherein the permission management policy includes any one of the following: granting the operation request full permissions; granting the operation request partial permissions; initiating a secondary authentication process for the request initiator; and intercepting the operation request and outputting alarm information.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions implementing the steps of the method as described in the first aspect when executed by the processor.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0010] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method as described in the first aspect.

[0011] In this embodiment, upon receiving an operation request from a request initiator, the electronic device can obtain the initiator's characteristics and the operation request's characteristics. The initiator's characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. Based on the initiator's characteristics and the request characteristics, the electronic device determines the trust level of the request initiator. The electronic device can then perform access control on the operation request according to the access control policy corresponding to the trust level. The access control policy includes any one of the following: granting the operation request full access; granting the operation request partial access; initiating a secondary authentication process for the request initiator; or intercepting the operation request and outputting alarm information. When an electronic device receives an operation request, it acquires the initiator's characteristics and the request's characteristics. These initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. In other words, the initiator's characteristics can include multi-dimensional features of the request initiator. Based on these multi-dimensional features and the request's characteristics, the electronic device can accurately determine the trust level of the request initiator. This trust level allows it to accurately ascertain whether the request initiator is trustworthy. Based on this trust level, the electronic device can then employ a corresponding access control strategy (i.e., granting full access to the operation request, granting partial access, initiating a secondary authentication process for the request initiator, or intercepting the operation request and outputting an alarm message) to manage access to the operation request. In other words, the electronic device can use different access control strategies (i.e., appropriate strategies) to manage access to the operation request based on whether the request initiator is trustworthy, rather than directly executing the corresponding operation based on the operation request. Therefore, it can prevent the leakage of private data due to the theft of the request initiator's account, thus improving network security. Attached Figure Description

[0012] Figure 1 This is one of the flowcharts illustrating the permission management method provided in the embodiments of this application;

[0013] Figure 2 This is a second flowchart illustrating the permission management method provided in the embodiments of this application;

[0014] Figure 3 This is the third flowchart illustrating the permission management method provided in the embodiments of this application;

[0015] Figure 4 This is a schematic diagram of the architecture of the electronic device provided in the embodiments of this application;

[0016] Figure 5 This is the fourth flowchart illustrating the permission management method provided in the embodiments of this application;

[0017] Figure 6This is a schematic diagram of the permission management device provided in the embodiments of this application;

[0018] Figure 7 This is one of the hardware structure diagrams of the electronic device provided in the embodiments of this application;

[0019] Figure 8 This is the second schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0021] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0022] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0023] The permission management method and apparatus provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0024] It should be noted that the permission management method provided in this application can be executed by electronic devices such as mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, servers, and gateways. Some embodiments of this application use electronic devices as the executing entity to illustrate the permission management method provided in this application.

[0025] The permission management method provided in this application embodiment can be applied to scenarios involving permission management.

[0026] One specific application scenario is that electronic devices manage permissions for operation requests sent from control devices to controlled devices, and another specific application scenario is that electronic devices manage permissions for operation requests from applications within the electronic devices.

[0027] Currently, electronic devices can authenticate the identity of the access requester. Once authentication is successful, the electronic device can grant the access requester full permissions and execute corresponding operations based on the various operation requests sent by the access requester, thereby enabling mobile office, remote collaboration, and other functions.

[0028] However, there is a possibility that after identity authentication is successful, the account of the requester may be stolen. In this case, since the electronic device has granted the requester full permissions, the electronic device will still execute the corresponding operations according to the various operation requests sent by the requester. This may lead to the leakage of privacy data, resulting in poor network security.

[0029] To address the aforementioned technical problems, this application provides a permission management method. Figure 1 A flowchart illustrating the permission management method provided in an embodiment of this application is shown. Figure 1 As shown, the permission management method provided in this application embodiment may include the following steps 101 to 103.

[0030] Step 101: When the electronic device receives an operation request from the request initiator, it obtains the initiator characteristics of the request initiator and the request characteristics of the operation request.

[0031] In this embodiment of the application, the initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics.

[0032] In some embodiments of this application, the above-mentioned electronic device may include, but is not limited to, any of the following: tablet computer, laptop computer, handheld computer, vehicle electronic device, server, gateway.

[0033] In some embodiments of this application, the request initiator may include, but is not limited to, any of the following: other electronic devices, applications in electronic devices.

[0034] In some embodiments of this application, the above-mentioned operation request is used to request the execution of a first operation, which may include, but is not limited to, at least one of the following: an access operation, a control operation, a function call operation, a data query operation, etc. The operation request may include, but is not limited to, at least one of the following: a Hypertext Transfer Protocol (HTTP) request, an Application Programming Interface (API) access request, etc.

[0035] In one scenario, when the request initiator (e.g., another electronic device) needs to control the controlled device, the other electronic device can send an operation request to the controlled device through the electronic device, thereby allowing the electronic device to receive the operation request from the other electronic device.

[0036] In another scenario, when an application on an electronic device needs to perform an operation using a specific function of the electronic device, the application can send an operation request to the electronic device, which can then receive the operation request from the application. This specific function may include, but is not limited to, at least one of the following: camera, microphone, location services, storage, contacts, and SMS.

[0037] In some embodiments of this application, the aforementioned initiator features are used to indicate the multi-dimensional real-time status information of the request initiator.

[0038] In some examples, the aforementioned identity characteristics may include, but are not limited to, at least one of the following: user role, data access scope, etc. The data access scope may include, but is not limited to, at least one of the following: data only for the user, data for the user and the pre-defined role, all data, etc.

[0039] In some examples, the aforementioned device characteristics may include, but are not limited to, at least one of the following: device identifier, device fingerprint, etc. The device identifier may include, but is not limited to, at least one of the following: device identification code (ID), device name, and the device fingerprint may include, but is not limited to, Canvas fingerprint.

[0040] In some examples, the environmental characteristics mentioned above may include, but are not limited to, at least one of the following: the location of the device, the time of device access, etc. For example, the location of the device is "City A / Office Network", and the time of device access is "Working hours 9:00".

[0041] In some examples, the aforementioned behavioral characteristics may include, but are not limited to, at least one of the following: operation frequency, sensitivity weight, etc. The operation frequency can be used to indicate how often the request initiator sends a request; for example, the operation frequency could be "number of accesses in the past hour." The sensitivity weight is used to indicate the degree of data privacy involved in the operation corresponding to the request sent by the request initiator. For example, if the operation corresponding to the request sent by the request initiator is viewing a payslip, it can be understood that the operation involves a high degree of data privacy; therefore, the sensitivity weight can be "highly sensitive."

[0042] In some examples, the aforementioned historical violation characteristics are used to indicate the number of times the request initiator's actions corresponding to requests were considered violations within a preset time period. This preset time period can be set by the user or configured by other devices. For example, a historical violation characteristic could be "3 abnormal logins last month".

[0043] For example, the aforementioned initiator characteristics may include identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. The initiator characteristics may be: identity as "finance department employee" (high privileges), device as "registered mobile phone" (trusted), environment as "company intranet Internet Protocol (IP)" (low risk), behavior including "first access to payslip" (normal), and no historical violation records.

[0044] In some embodiments of this application, the electronic device can obtain request characteristics through an access proxy module and initiator characteristics through an AI multi-dimensional trust assessment module. At least one of the access proxy module and the AI ​​multi-dimensional trust assessment module can be a module within the electronic device or a module within other devices.

[0045] In some examples, when the access proxy module is a module within an electronic device, the electronic device can directly obtain the request characteristics through the access proxy module. When the access proxy module is a module within another device, the electronic device can send a request to that other device to request the access proxy module within that other device to obtain the request characteristics. The electronic device can then receive a response from that other device that includes the request characteristics.

[0046] In some examples, when the AI ​​multi-dimensional trust assessment module is a module within an electronic device, the electronic device can directly obtain the initiator's characteristics through the AI ​​multi-dimensional trust assessment module. When the AI ​​multi-dimensional trust assessment module is a module within another device, the electronic device can send a request to that other device's AI multi-dimensional trust assessment module to obtain the initiator's characteristics. The electronic device can then receive a response from the other device that includes the initiator's characteristics.

[0047] In some embodiments of this application, the above operation request includes the initiator identifier of the request initiator. In some examples, combined with... Figure 1 ,like Figure 2 As shown, step 101 above can be specifically implemented through step 101a below.

[0048] Step 101a: When the electronic device receives an operation request from the request initiator, it retrieves the initiator feature corresponding to the initiator identifier from the database and retrieves the request feature.

[0049] In some examples, the aforementioned initiator identifier is used to indicate the request initiator. This initiator identifier may include, but is not limited to, at least one of the following: the request initiator's user ID, the request initiator's device ID, the request initiator's application ID, etc.

[0050] In some examples, the database described above can be deployed in electronic devices or other devices. This database can be the database associated with the access proxy module mentioned above.

[0051] Optionally, each time the request initiator initiates a request, the database can record the correspondence between the characteristics of the request initiator and the initiator identifier in real time, so that the electronic device can obtain the initiator characteristics corresponding to the initiator identifier from the database.

[0052] In some examples, electronic devices can access the agent module to retrieve the initiator characteristics corresponding to the initiator identifier from the database.

[0053] Optionally, the database includes multiple first correspondences, which are correspondences between identifiers and features. Thus, the electronic device can access the proxy module to determine an identifier that matches the initiator identifier from the multiple first correspondences, and determine the feature corresponding to the identifier as the initiator feature.

[0054] It should be noted that the above matching can be understood as: identical or the similarity between the two is less than or equal to a preset threshold.

[0055] In some examples, electronic devices can extract the aforementioned request features from operation requests by accessing a proxy module. For instance, an electronic device can extract information such as the Uniform Resource Locator (URL) and headers from the operation request and use the extracted information as request features.

[0056] Therefore, since the operation request can also include the initiator's identifier, the electronic device can accurately obtain the initiator's characteristics from the database based on the initiator's identifier, thus improving the accuracy of the electronic device in obtaining the characteristics.

[0057] Step 102: The electronic device determines the trust level of the request initiator based on the initiator's characteristics and the request characteristics.

[0058] In some embodiments of this application, the aforementioned trust level is used to indicate the degree of trustworthiness of the request initiator. This trust level may include, but is not limited to, any of the following: high trust score, medium trust score, low trust score, and risky trust score.

[0059] In some embodiments of this application, the electronic device can first calculate the scores corresponding to the initiator's characteristics and the request characteristics, and then determine the trust level based on the scores. The electronic device can directly calculate the scores, or it can calculate the scores through an AI multi-dimensional trust assessment module; this AI multi-dimensional trust assessment module can be a module in the electronic device or a module in other devices.

[0060] In some examples, when the AI ​​multi-dimensional assessment module is a module in an electronic device, the electronic device can directly input the initiator characteristics and request characteristics into the AI ​​multi-dimensional assessment module to calculate the aforementioned score through the AI ​​multi-dimensional trust assessment module; when the AI ​​multi-dimensional assessment module is a module in another device, the electronic device can send a request to the other device, which includes the initiator characteristics and request characteristics, to request the other device to calculate the aforementioned score through the AI ​​multi-dimensional trust assessment module.

[0061] In some examples, electronic devices can first encapsulate the initiator characteristics and request characteristics into a JSON file, and then calculate the scores corresponding to the initiator characteristics and request characteristics based on the file.

[0062] In some embodiments of this application, combined with Figure 1 ,like Figure 3 As shown, step 102 can be implemented through steps 102a and 102b below.

[0063] Step 102a: The electronic device inputs the initiator features and request features into the artificial intelligence (AI) model. The AI ​​model performs weighted fusion of the initiator features and request features to obtain the trust score output by the AI ​​model.

[0064] In some examples, the AI ​​model described above can be the model in the AI ​​multi-dimensional trust assessment model described above.

[0065] In some examples, when the aforementioned AI multi-dimensional trust assessment model is a model in an electronic device, the electronic device can directly input the initiator's characteristics and request characteristics into the AI ​​model; when the aforementioned AI multi-dimensional trust assessment model is a model in another device, the electronic device can send a request to the other device, which includes the initiator's characteristics and request characteristics, to request the other device to input the initiator's characteristics and request characteristics into the AI ​​model.

[0066] In this embodiment of the application, the trust score is used to indicate the degree of trustworthiness of the request initiator.

[0067] In some examples, the trust score mentioned above is positively or negatively correlated with the credibility of the requester.

[0068] For example, where the trust score is positively correlated with the credibility of the requester, the higher the trust score, the higher the credibility of the requester.

[0069] For example, when the trust score is negatively correlated with the credibility of the requester, the higher the trust score, the lower the credibility of the requester.

[0070] In some examples, the AI ​​model mentioned above includes weights corresponding to the initiator's features and weights corresponding to the request features. Thus, electronic devices can use the AI ​​model to perform weighted fusion based on the initiator's features, the weights corresponding to the initiator's features, the request features, and the weights corresponding to the request features to obtain a trust score.

[0071] In some examples, step 102a above can be specifically implemented by steps 102a1 to 102a3 below.

[0072] Step 102a1: The electronic device inputs the initiator feature and the request feature into the AI ​​model. Based on the feature type of the initiator feature, it determines the first weight corresponding to the initiator feature, and based on the feature type of the request feature, it determines the second weight corresponding to the request feature.

[0073] Optionally, the AI ​​model can be pre-trained to determine a second correspondence between different feature types and different weights. The electronic device can then first determine the feature type matching the initiator's feature from the different second correspondences, and then determine the weight corresponding to that feature type as the first weight; then, it can determine the feature type matching the request feature from the different second correspondences, and then determine the weight corresponding to that feature type as the second weight. This yields the first weight and the second weight.

[0074] For example, suppose the second correspondence mentioned above includes: a weight of 40% for behavioral feature types and a weight of 25% for environmental feature types. When the initiator's features include behavioral features, the electronic device can determine the first weight as 40% using an AI model.

[0075] Step 102a2: The electronic device adjusts the first weight and the second weight according to the request parameters corresponding to the operation request.

[0076] Optionally, the above request parameters may include, but are not limited to, at least one of the following: request time, request operation type, etc.

[0077] Optionally, the electronic device may first determine the correction weight based on the request parameters, and then correct the first weight and the second weight according to the correction weight.

[0078] For example, multiple third correspondences are set in the electronic device, which are correspondences between parameters and weights. Thus, the electronic device can first determine a parameter that matches the request parameter from the multiple third correspondences, and then determine the weight corresponding to that parameter as the correction weight.

[0079] For example, the electronic device can subtract (or add) the first weight and the modified weight to obtain the modified first weight; and / or, the electronic device can subtract (or add) the second weight and the modified weight to obtain the modified first weight.

[0080] It is understandable that since electronic devices can adjust the first weight and the second weight according to the request parameters, it is possible to avoid using fixed weights for calculation in different determination processes. In other words, this application can use dynamic thresholds to replace fixed rules, thereby further improving the accuracy of determining the trust level.

[0081] Step 102a3: The electronic device uses the modified first weight and the modified second weight to perform weighted fusion of the initiator features and the request features.

[0082] Optionally, the electronic device can first use a modified first weight to weight the score corresponding to the initiator's feature to obtain a first score, and then use a modified second weight to weight the score corresponding to the request feature to obtain a second score. Then, the sum of the first and second scores is calculated to obtain the trust score. It can be understood that this trust score can be the sum of the first and second scores.

[0083] Thus, it can be seen that since the electronic device can first determine the first weight corresponding to the initiator feature and the second weight corresponding to the request feature, and then adjust the first weight and the second weight according to the request parameters corresponding to the operation request to obtain the accurate first weight (i.e., the corrected first weight) and the accurate second weight (i.e., the corrected second weight), the electronic device can use the accurate first weight and the accurate second weight to perform weighted fusion of the initiator feature and the request feature, instead of using inaccurate weights to perform weighted fusion of the initiator feature and the request feature, thereby improving the accuracy of the electronic device in determining the trust score.

[0084] Step 102b: The electronic device determines the trust level based on the trust score.

[0085] In some examples, multiple score ranges are set in the electronic device, each score range corresponding to a level. The electronic device can first determine the score range to which the trust score belongs, and then determine the level corresponding to that score range as the trust level.

[0086] For example, the aforementioned score ranges include four ranges: 85-100, 60-84, 30-59, and 0-29. The 85-100 range corresponds to high trust, the 60-84 range to medium trust, the 30-59 range to low trust, and the 0-29 range to risky trust. Assuming a trust score of 96, this score falls within the 85-100 range, thus the electronic device can determine the trust level as high trust, corresponding to the 85-100 range.

[0087] Thus, since electronic devices can use AI models to weightedly fuse the characteristics of the initiator and the characteristics of the request to obtain a trust score that indicates the credibility of the request initiator, electronic devices can accurately determine the trust level based on this trust score, thereby improving the accuracy of electronic devices in determining the trust level.

[0088] In some examples, after step 102b above, the permission management method provided in this application embodiment may further include step 201 below.

[0089] Step 201: The electronic device updates the AI ​​model based on the initiator characteristics, request characteristics, trust score, permission management policy, and feedback data on execution permission management.

[0090] Optionally, the feedback data may include, but is not limited to, at least one of the following: data generated by the operation corresponding to the operation request, and data generated by the execution permission management.

[0091] Optionally, the electronic device can use the initiator characteristics, request characteristics, trust score, permission management policy, and feedback data on the execution of permission management as training samples, and use the gradient descent algorithm to retrain the AI ​​model to update the AI ​​model.

[0092] The electronic device can retrain the AI ​​model at intervals of a first time period. This first time period can be, but is not limited to, any of the following: N days, M weeks, K months, etc. N, M, and K are all positive integers.

[0093] It should be noted that for the explanation of using the gradient descent algorithm to retrain the AI ​​model on electronic devices, please refer to the specific description in the relevant technology, and the embodiments of this application will not be repeated here.

[0094] It is understandable that by retraining the AI ​​model, the weights of the AI ​​model can be adjusted to optimize the handling of misjudged cases.

[0095] After updating the AI ​​model, electronic devices can introduce A / B testing to compare the accuracy of the AI ​​model before and after the update, and apply the AI ​​model with higher accuracy.

[0096] Optionally, electronic devices can update the AI ​​model through the trust model iteration module based on initiator characteristics, request characteristics, trust score, permission management policy, and feedback data on execution permission management.

[0097] Thus, since electronic devices can update their AI models based on initiator characteristics, request characteristics, trust scores, access control policies, and feedback data from access control implementation, they can accurately determine trust scores based on the updated AI models during subsequent access control processes. Therefore, the accuracy of trust score determination by electronic devices can be further improved.

[0098] Step 103: The electronic device performs permission management on the operation request according to the permission management policy corresponding to the trust level.

[0099] In this embodiment of the application, the above-mentioned permission management strategy includes any one of the following:

[0100] Grant full permissions to the operation request;

[0101] Grant partial permissions to the operation request;

[0102] Initiate a two-factor authentication process for the requester;

[0103] Intercept operation requests and output alarm information.

[0104] In some examples, when the trust level is Level 1, the access control policy includes granting full permissions to the operation request. In this case, the electronic device can allow the operation request, such as directly executing the corresponding operation based on the request, or sending the operation request to a controlled device. Thus, the electronic device or the controlled device can execute the operation corresponding to the request and send the response data generated from executing the operation back to the request initiator. This Level 1 may include, but is not limited to, the aforementioned high-level trust.

[0105] In some examples, at the second level of trust, the access control policy includes granting partial permissions to the operation request. In this case, the electronic device can allow the operation request while restricting the corresponding operation (e.g., restricting access). This allows the electronic device or controlled device to execute the operation requested, and the electronic device can then anonymize the response data generated from executing the operation and send the anonymized response data back to the request initiator. The first level may include, but is not limited to, the aforementioned medium trust level.

[0106] For example, electronic devices can anonymize sensitive fields in the response data (such as displaying the ID number as *** or returning only a read-only view).

[0107] In some examples, when the trust level is level three, the access control policy includes initiating a secondary authentication process for the request initiator. In this case, the electronic device can return an authentication interface (such as an SMS verification code input interface) to the request initiator, and if the authentication is successful, execute steps 101 to 103 above again. This level three may include, but is not limited to, the aforementioned low trust level.

[0108] Optionally, after performing steps 101 to 103 above, the electronic device can allow the operation request and restrict the operation corresponding to the operation request (e.g., only allow basic functions), so that the electronic device or the controlled device can perform the operation corresponding to the operation request. Then, the electronic device can desensitize the response data generated by performing the operation and send the desensitized response data back to the request initiator.

[0109] In some examples, at trust level four, the access control policy includes intercepting operation requests and outputting alarm information. In this case, the electronic device can intercept the operation request, return an error status code (e.g., HTTP 403 status code) to the request initiator, and output alarm information so that the controlled device can be aware of the request initiator's abnormality. Furthermore, the electronic device can lock the account associated with the request initiator to prevent the request initiator from performing other unauthorized operations. This fourth level may include, but is not limited to, the aforementioned risk trust.

[0110] In some embodiments of this application, multiple fourth correspondences are set in the electronic device. These fourth correspondences can be correspondences between levels and policies. Thus, the electronic device can first determine a level that matches the trust level from the multiple fourth correspondences, and then determine the policy corresponding to that level as the access control policy.

[0111] For example, Table 1 illustrates several fourth correspondences, as shown in Table 1:

[0112] Table 1

[0113]

[0114] Assuming the above operation request corresponds to a payslip query, if the trust level is high, the electronic device can return the complete payslip to the requester; if the trust level is medium, the electronic device can anonymize the payslip (e.g., hide the specific amount) and then return the anonymized payslip to the requester.

[0115] In some embodiments of this application, the electronic device may first determine the permission management policy corresponding to the trust level through a dynamic permission decision engine, and then perform permission management on the operation request according to the permission management policy through the least privilege execution module. The least privilege execution module may be a module in the electronic device or a module in other devices.

[0116] In some embodiments of this application, when the trust level is at least one of the first level, the second level, and the third level, the electronic device can perform the operation corresponding to the operation request through the business service module after performing permission management on the operation request. For example, it can directly perform the operation or send the operation request to the controlled device so that the controlled device can perform the operation.

[0117] This application provides a permission management method. When an electronic device receives an operation request from a request initiator, it obtains the initiator's characteristics and the operation request's characteristics. The initiator's characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. Based on the initiator's characteristics and the request characteristics, the electronic device determines the trust level of the request initiator. Thus, the electronic device can perform permission management on the operation request according to the permission management policy corresponding to the trust level. The permission management policy includes any one of the following: granting the operation request full permissions; granting the operation request partial permissions; initiating a secondary authentication process for the request initiator; intercepting the operation request and outputting alarm information. When an electronic device receives an operation request, it acquires the initiator's characteristics and the request's characteristics. These initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. In other words, the initiator's characteristics can include multi-dimensional features of the request initiator. Based on these multi-dimensional features and the request's characteristics, the electronic device can accurately determine the trust level of the request initiator. This trust level allows it to accurately ascertain whether the request initiator is trustworthy. Based on this trust level, the electronic device can then employ a corresponding access control strategy (i.e., granting full access to the operation request, granting partial access, initiating a secondary authentication process for the request initiator, or intercepting the operation request and outputting an alarm message) to manage access to the operation request. In other words, the electronic device can use different access control strategies (i.e., appropriate strategies) to manage access to the operation request based on whether the request initiator is trustworthy, rather than directly executing the corresponding operation based on the operation request. Therefore, it can prevent the leakage of private data due to the theft of the request initiator's account, thus improving network security.

[0118] The following will use a complete example to illustrate the permission management method provided in the embodiments of this application.

[0119] Figure 4 A schematic diagram of the electronic device architecture in an embodiment of this application is shown. For example... Figure 4 As shown, the electronic device may include seven core modules: an access proxy module, an AI multi-dimensional trust assessment module, a dynamic permission decision engine, a least privilege execution module, a trust model iteration module, a business service module, and a database. These modules work together to achieve intelligent access control throughout the entire process.

[0120] (1) Access Proxy Module: Deployed in the traffic middleware layer between user terminals (e.g., controlled devices) and business services (e.g., business service modules), it intercepts all HTTP / HTTPS and API access requests initiated by user terminals without discrimination, and completes request forwarding, verification and response return without intruding on the original business service architecture, thus achieving seamless interception and verification.

[0121] (2) AI multi-dimensional trust assessment module: The core module of the system, which has a built-in trust scoring model that integrates deep learning and reinforcement learning (such as AI model), reads real-time multi-dimensional trust features (such as initiator features) from the database, completes the dynamic calculation of trust score and trust level determination, and outputs trust level (and trust score).

[0122] (3) Dynamic permission decision engine: It works in conjunction with the AI ​​multi-dimensional trust assessment module to match permission management strategies based on trust levels and issue the permission management strategies accordingly;

[0123] (4) Least Privilege Execution Module: Based on the permission management policy, execute the operation corresponding to the corresponding operation request to realize dynamic adaptation and control of permissions. For example, it can forward a legitimate request to the business service module and return a response to the user terminal according to the permission management policy, or return an interception prompt to the user terminal.

[0124] (5) Trust Model Iteration Module: Collect full access logs, decision results, and security event data, and regularly fine-tune and optimize the AI ​​model in the AI ​​multi-dimensional trust assessment module, and optimize feature weights and scoring logic;

[0125] (6) Database: Real-time storage of trust feature data in all dimensions such as user identity, device, environment, behavior, and historical violations. For example, the trust model iteration module can store record / update features in the database, and / or the AI ​​multi-dimensional trust assessment module can write multi-dimensional trust features into the database.

[0126] (7) Business service module: Provides core business services and only accepts legitimate requests that have passed the verification by the least privileged execution module.

[0127] Figure 5 A flowchart illustrating the permission management method provided in an embodiment of this application is shown. Figure 5 As shown, the permission management method provided in this application embodiment may include the following steps:

[0128] Step 1: Request interception and feature synchronization.

[0129] Action: By accessing the proxy module, all user-initiated business access or API call requests are intercepted in real time.

[0130] Input: User request data (such as API calls, web page access).

[0131] Output: Request features are synchronized to the AI ​​multi-dimensional trust assessment module, while the original request data is temporarily stored.

[0132] Example illustration:

[0133] User A attempts to check their personal payslip via a mobile application (APP) (a sensitive operation). The proxy module intercepts this HTTP request, extracts information such as the URL and headers as raw characteristics, temporarily stores the request body content, and immediately triggers step 2.

[0134] Specifically, step 1 above includes: S1, the user terminal initiates a business / API access request; S2, the access proxy module intercepts and temporarily stores the request data without discrimination; S3, the access proxy module synchronizes the request feature data to the AI ​​multi-dimensional trust assessment module.

[0135] Step 2: Multi-dimensional trust feature extraction.

[0136] Action: The AI ​​multi-dimensional trust assessment module extracts the full-dimensional features corresponding to this request from the trust feature database.

[0137] Input: The initiator identifier of step 1 synchronization (such as user ID, device ID).

[0138] Output: A set of structured features (5 categories: identity, device, environment, behavior, and historical violations).

[0139] Technical details:

[0140] Identity characteristics: Query the permission database to obtain user roles (such as "ordinary employee") and data access scope (such as "data for myself only").

[0141] Device characteristics: Verify terminal security through device fingerprinting technology (such as browser Canvas fingerprint).

[0142] Environmental characteristics: resolve IP geolocation (e.g., "City A / Office Network") and access time (e.g., "Working hours 09:00").

[0143] Behavioral characteristics: Calculate operation frequency (e.g., "number of visits in the last hour") and sensitivity weight (e.g., pay slip = high sensitivity).

[0144] Historical violation characteristics: Retrieve recent violation records from the log database (such as "3 abnormal logins last month").

[0145] Example illustration:

[0146] In response to User A's request, the system extracts the following characteristics: identity as "Finance Department Employee" (high privileges), device as "Registered Mobile Phone" (trusted), environment as "Company Intranet IP" (low risk), behavior as "First-time access to payslip" (normal), and no historical violations. All these characteristics are encapsulated in JSON format and input into step 3.

[0147] Specifically, step 2 above includes: S4, the AI ​​multi-dimensional trust assessment module requests the database to extract identity / environment / behavior / historical violation features; S5, the database returns real-time trust features across all dimensions.

[0148] Step 3: AI Real-time Dynamic Trust Score Calculation

[0149] Action: Based on the pre-trained AI model, the features from step 2 are weighted and fused to generate a trust score of 0-100.

[0150] Input: The multi-dimensional feature set output from step 2 (e.g., initiator features and request features).

[0151] Output: Trust score and level (high score 85-100, medium score 60-84, low score 30-59, risk 0-29).

[0152] Technical details:

[0153] The AI ​​model is a neural network that learns weights autonomously by training with historical data (e.g., behavioral features account for 40% of the weight, environmental features account for 25%, and the total score is calculated by weighting them according to the set proportions).

[0154] Dynamic thresholds replace fixed rules: For example, accessing sensitive data outside of working hours will trigger score decay.

[0155] Example illustration:

[0156] After User A's characteristics were input into the AI ​​model, the calculated score was 92 (high trust score). Because the device is trustworthy and the behavior is normal, the model assigns a high weight to it; if the same request comes from an unfamiliar IP address, the score may drop below 60.

[0157] Specifically, step 3 above includes: S6, AI model calculates trust score → determines trust level; S7, AI multi-dimensional trust assessment module pushes real-time trust information to dynamic permission decision engine, etc.

[0158] Step 4: Dynamic permission decision generation.

[0159] Action: The dynamic permission decision engine matches the permission management strategy based on the trust level in step 3.

[0160] Input: Trust score and trust level from step 3.

[0161] Output: Access decision (allow, restrict, two-factor authentication, or block).

[0162] Example illustration:

[0163] In step 3, user A scores 92 points (high trust score), and the decision engine matches the "direct access" policy, allowing them to access the complete payslip data. If the score is 50 points (low trust score), then SMS verification code secondary authentication is triggered.

[0164] Specifically, step 4 above may include: S8, matching dynamic permission policies; S9, issuing dynamic permission policies.

[0165] Step 5: Execution of Permission Decisions and Request / Response

[0166] Action: The least privilege execution module performs corresponding operations (such as allowing, restricting, or blocking) on ​​the temporarily stored operation requests according to the permission management policy generated in step 4, and returns the final response to the user terminal.

[0167] Input: The permission management policy output in step 4 (such as "direct access" or "two-factor authentication").

[0168] Output: Service response data or security prompts from the user terminal (such as normal data, anonymized content, or blocked pages).

[0169] Technical details: The principle of least privilege is adopted, granting only the minimum necessary privileges corresponding to the decision outcome.

[0170] Allow access: Forward the operation request to the backend business service module (such as microservice API), obtain the original response, and send it back.

[0171] Limitations: De-identify sensitive fields (e.g., display ID card number as ***) or return only a read-only view.

[0172] Secondary authentication: Return to the authentication interface (such as the SMS verification code input page), and re-trigger the step 1 process after successful authentication.

[0173] Interception: Directly return the HTTP 403 status code and security alert information.

[0174] Example illustration:

[0175] In step 4, if User A's request is deemed "high trust," the execution module forwards their payslip query request to the HR system API, retrieves the complete data, and returns it to the mobile app. If the decision is "medium trust," then anonymized payslips (with the specific amount hidden) are returned.

[0176] Specifically, step 5 above may include: S10-S12, or S13. Among them, S10 forwards the legitimate request; S11 returns the business response data; S12 sends back the response / de-identified data / secondary authentication interface; S13 returns the interception prompt + security alarm.

[0177] Step 6: Closed-loop iterative optimization of the model.

[0178] Action: The Trust Model Iteration Module stores all data (features, scores, decisions, feedback) of this request into the database and periodically fine-tunes the AI ​​model to optimize weights and logic.

[0179] Input: Data from the entire process of steps 1-5 (including feature set (i.e., initiator features and request features), trust score, decision results, and user operation feedback).

[0180] Output: Updated AI model and optimized permission management strategy.

[0181] Technical details: Enhance AI model training to improve the accuracy of access control: Regularly (e.g., weekly) extract new data for incremental training; use gradient descent algorithm to fine-tune neural network weights, focusing on optimizing misjudgment cases (e.g., subsequent violations by high-scoring trusted users); introduce A / B testing to compare the accuracy of new and old models, etc.

[0182] Specifically, step 6 above may include: S14, the least privilege execution module synchronizes all data of this access to the trust model iteration module; S15, the trust model iteration module stores feature / score / decision records in the database; S16, the trust model iteration module periodically fine-tunes and optimizes the AI ​​model to the AI ​​multi-dimensional trust assessment module.

[0183] As can be seen from the above, this application has the following significant advantages compared with the prior art:

[0184] (1) Truly achieve zero-trust verification for each request: Completely break the traditional model of "one-time authentication, full access", and trigger a complete trust assessment and permission decision for each user access request, eliminating the risk of account theft, intranet penetration and unauthorized access from the root, and providing security protection without blind spots;

[0185] (2) AI dynamic continuous trust assessment: adopts multi-dimensional feature fusion + deep learning model to replace manual fixed rules, and the trust score is updated in real time, which can adapt to new network attacks and dynamic access scenarios.

[0186] (3) Refined minimum permission dynamic adaptation: Based on trust score and trust level, permissions are scaled up and down in real time. Different trust levels correspond to different permissions. The principle of minimum permission is strictly implemented to avoid excessive permission allocation and to balance security and ease of use in business.

[0187] (4) Non-intrusive and lightweight deployment: Traffic interception is achieved through the access proxy module, without the need to modify the original business system or adjust the business logic, making deployment convenient;

[0188] (5) Self-optimizing closed-loop operation and maintenance: The AI ​​model is autonomously iterated and optimized based on historical data, without the need for frequent manual updates of permission rules and adjustments to verification thresholds, which greatly reduces security operation and maintenance costs and ensures long-term protection effectiveness;

[0189] (6) Strong adaptability to all scenarios: It supports multiple scenarios such as enterprise intranet, cloud services, API interface, mobile terminal, and remote office, and is compatible with various business systems, with extremely strong versatility.

[0190] It should be noted that each of the above method embodiments, or various possible implementations of each method embodiment, can be executed individually or in combination of any two or more. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0191] The permission management method provided in this application can be executed by a permission management device. This application uses the execution of the permission management method by a permission management device as an example to illustrate the permission management device provided in this application.

[0192] Figure 6 This is a schematic diagram of the structure of a permission management device provided in an embodiment of this application. Figure 6 As shown, the access control device 300 includes: an acquisition module 301, a determination module 302, and a management module 303.

[0193] The acquisition module 301, upon receiving an operation request from the request initiator, acquires the initiator's characteristics and the request characteristics of the operation request. The initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. The determination module 302, based on the initiator characteristics and request characteristics acquired by the acquisition module 301, determines the trust level of the request initiator. The management module 303, based on the permission management policy corresponding to the trust level determined by the determination module 302, performs permission management on the operation request. The permission management policy includes any one of the following: granting the operation request full permissions; granting the operation request partial permissions; initiating a secondary authentication process for the request initiator; or intercepting the operation request and outputting alarm information.

[0194] This application provides a permission management device. Upon receiving an operation request, the permission management device acquires the initiator's characteristics and the request's characteristics. These initiator characteristics include at least one of identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. In other words, the initiator's characteristics can include multi-dimensional features of the request initiator. Based on these multi-dimensional and request characteristics, the permission management device can accurately determine the trust level of the request initiator. This trust level allows it to accurately ascertain whether the request initiator is trustworthy. Based on the trust level, the device employs a corresponding permission management strategy (i.e., granting full permissions to the operation request, granting partial permissions to the operation request, initiating a secondary authentication process for the request initiator, or intercepting the operation request and outputting an alarm message) to perform permission management on the operation request. In other words, the permission management device can use different permission management strategies (i.e., appropriate strategies) to perform permission management on the operation request based on whether the request initiator is trustworthy, rather than directly executing the corresponding operation based on the operation request. Therefore, it can prevent the leakage of privacy data due to the theft of the request initiator's account, thus improving network security.

[0195] In some embodiments of this application, the determination module 302 is specifically used to input the initiator features and request features into the AI ​​model, perform weighted fusion of the initiator features and request features through the AI ​​model to obtain a trust score output by the AI ​​model, which is used to indicate the trustworthiness of the request initiator; and determine the trust level based on the trust score.

[0196] Thus, it can be seen that since the permission management device can use an AI model to weightedly fuse the characteristics of the initiator and the characteristics of the request to obtain a trust score that indicates the credibility of the request initiator, the permission management device can accurately determine the trust level based on this trust score, thereby improving the accuracy of the permission management device in determining the trust level.

[0197] In some embodiments of this application, the determining module 302 is specifically used to determine the first weight corresponding to the initiator feature based on the feature type of the initiator feature, and to determine the second weight corresponding to the request feature based on the feature type of the request feature; and to modify the first weight and the second weight according to the request parameters corresponding to the operation request; and to use the modified first weight and the modified second weight to perform weighted fusion of the initiator feature and the request feature.

[0198] Thus, it can be seen that since the permission management device can first determine the first weight corresponding to the initiator's characteristics and the second weight corresponding to the request characteristics, and then adjust the first weight and the second weight according to the request parameters corresponding to the operation request to obtain the accurate first weight (i.e., the corrected first weight) and the accurate second weight (i.e., the corrected second weight), the permission management device can use the accurate first weight and the accurate second weight to perform weighted fusion of the initiator's characteristics and the request characteristics, instead of using inaccurate weights to perform weighted fusion of the initiator's characteristics and the request characteristics, thereby improving the accuracy of the permission management device in determining the trust score.

[0199] In some embodiments of this application, the permission management device 300 provided in this application may further include: an update module, used to update the AI ​​model based on the initiator characteristics, request characteristics, trust score, permission management policy and feedback data of performing permission management after the determination module 302 determines the trust level based on the trust score.

[0200] Thus, since the permission management device can update the AI ​​model based on the initiator's characteristics, request characteristics, trust score, permission management policy, and feedback data from the execution of permission management, it can accurately determine the trust score based on the updated AI model in subsequent permission management processes. Therefore, the accuracy of the permission management device in determining the trust score can be further improved.

[0201] In some embodiments of this application, the above-mentioned operation request includes an initiator identifier of the request initiator. The aforementioned acquisition module 301 is specifically used to retrieve the initiator characteristics corresponding to the initiator identifier from the database.

[0202] Therefore, since the operation request can also include the initiator's identifier, the permission management device can accurately obtain the initiator's characteristics from the database based on the initiator's identifier, thus improving the accuracy of the characteristics obtained by the permission management device.

[0203] The access control device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0204] The permission management device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0205] The permission management device provided in this application embodiment can achieve... Figures 1 to 5 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0206] In some embodiments of this application, such as Figure 7 As shown, this application embodiment also provides an electronic device 400, including a processor 401 and a memory 402. The memory 402 stores a program or instructions that can run on the processor 401. When the program or instructions are executed by the processor 401, they implement the various steps of the above-described permission management method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0207] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0208] Figure 8 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0209] The electronic device 100 includes, but is not limited to, components such as: radio frequency unit 101, network module 102, audio output unit 103, input unit 104, sensor 105, display unit 106, user input unit 107, interface unit 108, memory 109, and processor 110.

[0210] Those skilled in the art will understand that the electronic device 100 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 110 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 8 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0211] The processor 110 is configured to, upon receiving an operation request from a request initiator, obtain the initiator characteristics of the request initiator and the request characteristics of the operation request. The initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. Based on the initiator characteristics and request characteristics, the processor determines the trust level of the request initiator. Based on the access control policy corresponding to the trust level, the processor performs access control on the operation request. The access control policy includes any one of the following: granting the operation request full access; granting the operation request partial access; initiating a secondary authentication process for the request initiator; and intercepting the operation request and outputting alarm information.

[0212] This application provides an electronic device that, upon receiving an operation request, acquires the initiator's characteristics and the request's characteristics. These initiator characteristics include at least one of identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. In other words, the initiator's characteristics can include multi-dimensional features of the request initiator. Based on these multi-dimensional and request characteristics, the electronic device can accurately determine the trust level of the request initiator, thereby accurately ascertaining whether the request initiator is trustworthy. Based on this trust level, the electronic device can employ a corresponding permission management strategy (i.e., granting full permissions to the operation request, granting partial permissions to the operation request, initiating a secondary authentication process for the request initiator, or intercepting the operation request and outputting alarm information) to manage the operation request's permissions. In other words, the electronic device can use different permission management strategies (i.e., appropriate strategies) to manage the operation request's permissions based on whether the request initiator is trustworthy, rather than directly executing the corresponding operation based on the operation request. Therefore, it can avoid the leakage of privacy data due to the theft of the request initiator's account, thus improving network security.

[0213] In some embodiments of this application, the processor 110 is specifically used to input the initiator features and request features into the AI ​​model, perform weighted fusion of the initiator features and request features through the AI ​​model to obtain a trust score output by the AI ​​model, which is used to indicate the trustworthiness of the request initiator; and determine the trust level based on the trust score.

[0214] In some embodiments of this application, the processor 110 is specifically configured to determine a first weight corresponding to the initiator feature based on the feature type of the initiator feature, and determine a second weight corresponding to the request feature based on the feature type of the request feature; and modify the first weight and the second weight according to the request parameters corresponding to the operation request; and use the modified first weight and the modified second weight to perform weighted fusion of the initiator feature and the request feature.

[0215] In some embodiments of this application, the processor 110 is further configured to update the AI ​​model based on initiator characteristics, request characteristics, trust score, permission management policy, and feedback data on execution permission management after determining the trust level based on the trust score.

[0216] In some embodiments of this application, the above operation request includes the initiator identifier of the request initiator.

[0217] Processor 110 is specifically used to retrieve the initiator characteristics corresponding to the initiator identifier from the database.

[0218] It should be understood that, in this embodiment, the input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 106 may include a display panel 1061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 107 includes at least one of a touch panel 1071 and other input devices 1072. The touch panel 1071 is also called a touch screen. The touch panel 1071 may include a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0219] The memory 109 can be used to store software programs and various data. The memory 109 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 109 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 109 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0220] Processor 110 may include one or more processing units; optionally, processor 110 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 110.

[0221] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described permission management method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0222] The processor mentioned above is the processor in the electronic device described in the above embodiments. The readable storage medium mentioned above includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0223] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described permission management method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0224] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0225] This application provides a computer program product that is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described permission management method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0226] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0227] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of 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 computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0228] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for managing access permissions, characterized in that, include: Upon receiving an operation request from the request initiator, the initiator characteristics of the request initiator and the request characteristics of the operation request are obtained. The initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. The trust level of the request initiator is determined based on the initiator characteristics and the request characteristics. Based on the permission management policy corresponding to the trust level, permission management is performed on the operation request; The access control policy includes any one of the following: Grant the operation request full permissions; Grant partial permissions to the operation request; Initiate a two-factor authentication process for the request initiator; The operation request is intercepted and an alarm message is output.

2. The method according to claim 1, characterized in that, Determining the trust level of the request initiator based on the initiator characteristics and the request characteristics includes: The initiator features and the request features are input into an artificial intelligence (AI) model. The AI ​​model performs a weighted fusion of the initiator features and the request features to obtain a trust score output by the AI ​​model. The trust score is used to indicate the trustworthiness of the request initiator. The trust level is determined based on the trust score.

3. The method according to claim 2, characterized in that, The step of weighted fusion of the initiator features and the request features using the AI ​​model includes: Based on the feature type of the initiator feature, a first weight corresponding to the initiator feature is determined, and based on the feature type of the request feature, a second weight corresponding to the request feature is determined. Based on the request parameters corresponding to the operation request, the first weight and the second weight are adjusted; The initiator features and the request features are weighted and fused using the modified first weight and the modified second weight.

4. The method according to claim 2, characterized in that, After determining the trust level based on the trust score, the method further includes: The AI ​​model is updated based on the initiator characteristics, the request characteristics, the trust score, the permission management policy, and the feedback data from the execution permission management.

5. The method according to claim 1, characterized in that, The operation request includes the initiator identifier of the request initiator; obtaining the initiator characteristics of the request initiator includes: Retrieve the initiator feature corresponding to the initiator identifier from the database.

6. A permission management device, characterized in that, include: The acquisition module is used to acquire the initiator characteristics of the request initiator and the request characteristics of the operation request when receiving an operation request from the request initiator. The initiator characteristics include at least one of the following: identity characteristics, device characteristics, environmental characteristics, behavioral characteristics, and historical violation characteristics. The determination module is used to determine the trust level of the request initiator based on the initiator characteristics and request characteristics obtained by the acquisition module. The management module is used to perform permission management on the operation request according to the permission management policy corresponding to the trust level determined by the determining module; The access control policy includes any one of the following: Grant the operation request full permissions; Grant partial permissions to the operation request; Initiate a two-factor authentication process for the request initiator; The operation request is intercepted and an alarm message is output.

7. The apparatus according to claim 6, characterized in that, The determining module is specifically used to input the initiator features and the request features into an artificial intelligence (AI) model, perform weighted fusion of the initiator features and the request features through the AI ​​model to obtain a trust score output by the AI ​​model, the trust score being used to indicate the credibility of the request initiator; and determine the trust level based on the trust score.

8. The apparatus according to claim 7, characterized in that, The determining module is specifically configured to determine a first weight corresponding to the initiator feature based on the feature type of the initiator feature, and determine a second weight corresponding to the request feature based on the feature type of the request feature; and modify the first weight and the second weight according to the request parameters corresponding to the operation request; and use the modified first weight and the modified second weight to perform weighted fusion of the initiator feature and the request feature.

9. The apparatus according to claim 7, characterized in that, The access control device also includes: An update module is used to update the AI ​​model based on the initiator characteristics, the request characteristics, the trust score, the permission management policy, and the feedback data of the execution permission management after the determination module determines the trust level based on the trust score.

10. The apparatus according to claim 6, characterized in that, The operation request includes the initiator identifier of the request initiator; The acquisition module is specifically used to retrieve the initiator feature corresponding to the initiator identifier from the database.

Images