Access control method and device, equipment, medium and program product

Abstract

The invention provides an access control method and device, equipment, a medium and a program product. The method is applied to a first device and comprises the steps that a first access request sent by a second device is received, and the first access request is used for requesting to access a first application; determining a first credibility of the first access request; according to the first credibility and a pre-recorded second credibility, determining whether to send the first access request to the first application, so that the first application responds to the first access request; wherein the second credibility comprises the credibility of the second device for an associated account of the first account of the first application.

Description

Technical Field

[0001] The present application relates to the field of identity security technology, and is related to but not limited to access control methods and devices, equipment, media, and program products. Background Art

[0002] Access control refers to the means by which the system restricts the ability of users to use data resources based on their identities and the pre-defined policy groups they belong to. Its main purpose is to protect sensitive information and resources in the system, prevent unauthorized access and operations, and ensure the security, integrity and reliability of the system. Therefore, access control is of paramount importance in application identity management. Summary of the invention

[0003] The access control method, device, equipment, medium, and program product provided by this application include:

[0004] In a first aspect, an embodiment of the present application provides an access control method, which is applied to a first device, and the method includes: receiving a first access request sent by a second device, the first access request being used to request access to a first application; determining a first trust level of the first access request; determining whether to send the first access request to the first application based on the first trust level and a pre-recorded second trust level so that the first application responds to the first access request; wherein the second trust level includes the trust level of the second device for an associated account of the first account of the first application.

[0005] In a second aspect, an embodiment of the present application provides an access control device, comprising: a receiving module, configured to receive a first access request sent by a second device, the first access request being used to request access to a first application; a first determination module, configured to determine a first trust level of the first access request; a second determination module, configured to determine whether to send the first access request to the first application based on the first trust level and a pre-recorded second trust level, so that the first application responds to the first access request; wherein the second trust level includes the trust level of the second device for an associated account of the first account of the first application.

[0006] In a third aspect, an embodiment of the present application provides a first device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, and when the processor executes the program, the method described in the embodiment of the present application is implemented.

[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method provided in the embodiment of the present application.

[0008] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the method provided in the embodiment of the present application.

[0009] It can be understood that in the embodiment of the present application, a first access request sent by a second device is received, a first trust level of the first access request is determined, and whether to send the first access request to the first application is determined based on the first trust level and a pre-recorded second trust level; wherein the second trust level includes the trust level of the second device for the associated account of the first account of the first application. In this way, since the trust level of the associated account associated with the first account is taken into account when determining whether to send the first access information to the first application, it is beneficial to improve the security of the first application.

[0010] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0012] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0013] Figure 1 A schematic diagram of an implementation process of an access control method provided in an embodiment of the present application Figure 1 ;

[0014] Figure 2 A schematic diagram of an implementation flow of determining a fifth degree of trust provided in an embodiment of the present application;

[0015] Figure 3 A schematic diagram of an implementation process for determining whether to send a first access request to a first application provided in an embodiment of the present application Figure 1 ;

[0016] Figure 4 A schematic diagram of an implementation process for determining whether to send a first access request to a first application provided in an embodiment of the present application Figure 2 ;

[0017] Figure 5 A schematic diagram of an implementation process for determining whether to send a first access request to a first application provided in an embodiment of the present application Figure 3 ;

[0018] Figure 6 A schematic diagram of an implementation process of an access control method provided in an embodiment of the present application Figure 2 ;

[0019] Figure 7 A schematic diagram of an implementation process of an access control method provided in an embodiment of the present application Figure 3 ;

[0020] Figure 8 A schematic diagram of attribute data provided in an embodiment of the present application;

[0021] Fig. 9 A schematic diagram of the structure of an access control device provided in an embodiment of the present application;

[0022] Fig.10 A schematic diagram of the structure of the first device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the specific technical solution of the present application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application, but are not used to limit the scope of the present application.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0025] In the following description, reference is made to “some embodiments”, “this embodiment”, “embodiments of the present application” and examples, etc., which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0026] The descriptions of “first, second, third” etc. that appear in the embodiments of the present application are only for illustration and distinction of the description objects. There is no distinction of order, nor do they indicate any special limitation on the number of devices in the embodiments of the present application, and cannot constitute any limitation on the embodiments of the present application.

[0027] To facilitate understanding of the technical solutions of the embodiments of the present application, the following describes the related technologies or terms of the embodiments of the present application. The following related technologies or related terms as optional solutions can be combined with the technical solutions of the embodiments of the present application at will, and they all belong to the protection scope of the embodiments of the present application.

[0028] (1) Identity as a Service

[0029] Identity as a Service (IDaaS) is a cloud-based identity and access management service. Currently, more and more companies are turning to cloud solutions. On the one hand, they can fully connect with cloud applications. On the other hand, cloud standardization allows companies to outsource time-consuming tasks, such as creating new user accounts, verifying access requests, and identity governance.

[0030] (2) Access Control

[0031] The main function of access control is to prevent unauthorized user operations and restrict unauthorized users from operating specific devices. Through the access control mechanism, users with different rights levels have their own levels of access rights, and each user can only access the private data resources under the corresponding permissions. In this way, data security can be effectively guaranteed. Therefore, access control is the top priority in application identity management.

[0032] In a related art, a role-based user-role-permission access control (RBAC) model is provided, in which roles are directly associated with permissions. Once the system assigns a role to a user, the user has all permissions associated with the role until the user's access ends. However, RBAC is a static access control mechanism that cannot dynamically adjust the correspondence between user roles (i.e., {userrole}) and role permissions (i.e., {role-permission}).

[0033] In another related technology, a trust-based IoT access control model is provided, which combines the advantages of RBAC and attribute-based access control (ABAC) access control models, and proposes an access control model based on user trust and attributes. By introducing user trust analysis, a more flexible authorization mechanism is established, and key data such as the user's overall trust and access control policy are stored on the blockchain, and its security is ensured by using the security features of the blockchain such as immutability and traceability; thereby enhancing the permission granularity, dynamics and security of the original access control model, but it is not suitable for IDaaS scenarios.

[0034] Among them, RBAC has the following three shortcomings in the IDaaS usage scenario:

[0035] (1) The allocation of access rights is static. The rights obtained by users are permanent within a certain period of time and will not be released after the operation is completed, that is, "once authorized, lifetime use". The access control system cannot manage the subsequent behavior of users, resulting in the problem of user rights abuse and introducing unsafe factors. Since the subsequent access to applications or functions is not monitored in real time, some internal personnel will take risks and steal confidential information of organizations or enterprises in exchange for illegal benefits because they cannot resist the temptation of interests.

[0036] (2) User access rights cannot be granted automatically. User rights need to be manually set by the system administrator, which is prone to two problems. On the one hand, when the number of users is large, the number of user role assignments increases sharply with the growth of the number of users, which increases the workload of the administrator and the management and maintenance costs. On the other hand, the administrator is bound to make mistakes during the manual setting process, resulting in the inability of legitimate users to access or the leakage of private data.

[0037] (3) The granularity of access control is relatively coarse. The granularity of access control is relatively coarse in two aspects. On the one hand, due to the coarse division of users, the same permissions are granted to different users. On the other hand, due to the broad division of permissions, users are granted not only the permissions required to complete the task, but also other permissions with a wider range.

[0038] (4) The relationship between the trust of ordinary users and the trust of the administrator who created the user is not considered. The historical trust is not fully utilized and is simply weighted.

[0039] In view of this, an embodiment of the present application provides an access control method. Figure 1 A schematic diagram of an implementation process of an access control method provided in an embodiment of the present application Figure 1 ,like Figure 1 As shown, the method includes the following steps 101 to 103:

[0040] Step 101, receiving a first access request sent by a second device, where the first access request is used to request access to a first application;

[0041] Step 102, determining a first trust level of the first access request;

[0042] Step 103, based on the first trust and the pre-recorded second trust, determine whether to send the first access request to the first application so that the first application responds to the first access request; wherein the second trust includes the trust of the second device for the associated account of the first account of the first application.

[0043] It can be understood that in the embodiment of the present application, a first access request sent by a second device is received, a first trust level of the first access request is determined, and whether to send the first access request to the first application is determined based on the first trust level and a pre-recorded second trust level; wherein the second trust level includes the trust level of the second device for the associated account of the first account of the first application. In this way, since the trust level of the associated account associated with the first account is taken into account when determining whether to send the first access information to the first application, it is beneficial to improve the security of the first application.

[0044] This is because some attacks use an existing account to create a new account, and then use the created new account to perform some dangerous operations. Therefore, determining whether to send the first access request to the first application based on the trust of the associated account associated with the first account is beneficial to improving the security of the first application, thereby ensuring the system security of the system where the first application is located.

[0045] The following describes further optional implementations and related terms of each of the above steps.

[0046] In step 101, a first access request sent by a second device is received, where the first access request is used to request access to a first application.

[0047] It should be understood that in the embodiments of the present application, there is no limitation on the first application, and the first application may be any application in the system.

[0048] In step 102, a first trust level of a first access request is determined.

[0049] It should be understood that in the embodiment of the present application, the trust level is not limited. The trust level is used to characterize the credibility of the access request sent by the second device, thereby determining whether to send the access request to the application to be accessed based on the credibility, so that the application to be accessed responds to the access request.

[0050] In some embodiments, the trust level can be calculated based on the following information: historical interaction records, behavior pattern analysis and / or security authentication information; wherein the historical interaction records include: number of logins, operation behaviors, access frequency, etc.; the behavior patterns include: abnormal behaviors or potential security threat behaviors, etc.; the security authentication information includes: digital certificates, password strength, biometric recognition, etc.

[0051] Trust is a dynamically changing value that adjusts as the requester's behavior and environment change. For example, if the requester exhibits abnormal behavior or suffers a security attack, its trust may decrease; whereas if it continues to exhibit good behavior patterns and passes security authentication, its trust may increase.

[0052] In some embodiments, the first trust level includes: a fifth trust level; Figure 2 A schematic diagram of an implementation flow of determining a fifth degree of trust provided in an embodiment of the present application is as follows: Figure 2 As shown, the fifth trust level may be determined through the following steps 201 to 204;

[0053] Step 201, determining the historical access information and current access information of the second device to the first application; wherein the access information includes: the access IP address and access time;

[0054] Step 202, classifying the historical access information to obtain multiple different categories of historical access information;

[0055] Step 203, determining the category of current access information according to the multiple different categories of historical access information;

[0056] Step 204: Determine the fifth degree of trust according to the historical access information corresponding to the category of the current access information.

[0057] It can be understood that in the embodiment of the present application, the historical access information and current access information of the second device to the first application are determined; wherein the access information includes: the accessed Internet Protocol (IP) address and the access time; the historical access information is classified to obtain multiple different categories of historical access information; the category of the current access information is determined based on the multiple different categories of historical access information; the fifth trust level is determined based on the historical access information corresponding to the category of the current access information. In this way, determining the fifth trust level based on the historical access information belonging to the same category as the current access information is beneficial to making the determined first trust level more accurate. In this way, based on the more accurate trust level, it is determined whether to send the first access information to the first application, thereby improving the security of the first application, and further ensuring the system security of the system where the first application is located.

[0058] This is because it is more likely that an access request is sent using an IP address in the office area during office hours, while if an access request is sent using an IP address outside the office area during office hours, it means that the access request at this time is not trustworthy. If all historical access information is used to calculate the trustworthiness of the current access request, the calculated trustworthiness may not be accurate enough. Therefore, using historical access information that belongs to the same category as the current access information to determine the fifth trustworthiness is beneficial to making the determined first trustworthiness more accurate.

[0059] It should be understood that in the embodiments of the present application, the access information is not limited, and the access information may also include access information of other dimensions besides the IP address and access time of the access; for example, access duration, accessed pages, operating system used for access, browser type and version, and other information.

[0060] It should be understood that in the embodiments of the present application, the method for classifying the historical access information is not limited, and classifying the historical access information means classifying the historical access information into different categories. In some embodiments, the historical access information can be classified by unsupervised learning technology; the historical access information can also be classified by supervised learning technology; and the historical access information can also be classified by semi-supervised learning technology.

[0061] In some embodiments, determining the fifth trust level based on historical access information corresponding to the category of the current access information includes: determining a third weight of the historical access information within a preset time window; wherein the third weight is negatively correlated with the second distance; the second distance includes: the time distance between the historical access time and the current access time; determining the fifth trust level based on the trust level of the historical access information and the corresponding third weight.

[0062] It can be understood that in the embodiment of the present application, the corresponding third weight is assigned to the historical access information according to the time distance between the historical access time and the current access time; wherein the third weight is negatively correlated with the time distance; and the fifth trust is determined according to the trust of the historical access information and the third weight. In this way, it is beneficial to make the fifth trust determined according to the third weight more in line with the access habits of the second device, thereby obtaining a fifth trust that is more in line with the actual situation, and further beneficial to obtain a more accurate first trust. In this way, based on a more accurate trust, it is determined whether to send the first access information to the first application, which is beneficial to improve the security of the first application and ensure the system security of the system where the first application is located.

[0063] This is because the user's access habits may change, so giving a greater weight to historical access information that is closer to the current access time, and giving a smaller weight to historical access information that is farther away from the current access time, is beneficial to making the determined fifth trust level more in line with the access habits of the second device.

[0064] It should be understood that in the embodiments of the present application, the preset time window is not limited, and the preset time window can be set according to actual conditions.

[0065] For example, as a possible implementation method: according to the IDaaS application scenario, the risks of access requests initiated by IPs in the office area and outside the office area during working hours and after get off work hours are not comparable. That is, the high trust in access requests initiated by an account in the office area does not mean that access requests initiated outside the office area are safe. On the contrary, the risk may be higher. Because the use of historical access information needs to consider whether it conforms to the rules of historical use, once an abnormality occurs, the trust should be immediately lowered to achieve the effect of identifying risks. Therefore, historical access information can be clustered, and the trust of historical access information in the time window in this category can be used to calculate the fifth trust. Among them, the calculation formula for the fifth trust is as follows:

[0066]

[0067] Among them, T i (i=1,2,…,h) represents the trust of the i-th historical access information in the time window that belongs to the same category as the current access information, h is the preset time window, δ i Indicates T i The corresponding third weight has a certain attenuation.

[0068] In step 103, based on the first trust and the pre-recorded second trust, determine whether to send the first access request to the first application so that the first application responds to the first access request; wherein the second trust includes the trust of the second device for the associated account of the first account of the first application.

[0069] It should be understood that in the embodiments of the present application, the associated account is not limited. In some embodiments, the associated account includes an account that has a management relationship with the first account. For example, account A creates account B, and account B creates account C; if account B is the first account, then account A and account C are associated accounts of account B.

[0070] In some embodiments, Figure 3 As shown, step 103 can be implemented through the following steps 301 to 303:

[0071] Step 301, determining a first weight according to the degree of association between the first account and the associated account; wherein the first weight is positively correlated with the degree of association;

[0072] Step 302, determining a third trust level according to the trust level of the associated account and the first weight;

[0073] Step 303: Determine whether to send the first access request to the first application according to the first trust level and the third trust level.

[0074] It can be understood that in the embodiment of the present application, the first weight is determined according to the degree of association between the first account and the associated account; wherein the first weight is positively correlated with the degree of association; the third trust is determined according to the trust of the associated account and the first weight; and whether to send the first access request to the first application is determined according to the first trust and the third trust. In this way, the greater the degree of association between the associated account and the first account, the greater the first weight assigned to it; conversely, the smaller the degree of association between the associated account and the first account, the smaller the first weight assigned to it; based on this, the third trust is determined; thus, it is beneficial to obtain a more accurate trust. In this way, based on a more accurate trust, it is determined whether to send the first access information to the first application, which is beneficial to improve the security of the first application and ensure the system security of the system where the first application is located.

[0075] This is because, if an administrator wants to perform some dangerous operations, he is more likely to create an account directly associated with him to perform the dangerous operations. Therefore, the first weight is determined according to the degree of association between the first account and the associated account; and the first weight is positively correlated with the degree of association; which is beneficial to obtain a more accurate trust level.

[0076] It should be understood that in the embodiments of the present application, the degree of association is not limited. In some embodiments, the degree of association refers to the degree of management relationship between the associated account and the first account. For example, account A creates account B, account B creates account C, and account C creates account D; if account B is the first account, then the degree of management relationship between account A and account B is less than the degree of management relationship between account D and account B.

[0077] In some embodiments, the first weight is determined based on an association relationship between the first account and an account created by a system where the first application is located, wherein the association relationship is positively correlated with the first weight.

[0078] It should be understood that in the embodiment of the present application, the account created by the system has the highest trust, and the more distant the association relationship between the first account and the account created by the system, the lower the trust.

[0079] In some embodiments, Figure 4As shown, step 303 can be implemented through the following steps 401 to 403:

[0080] Step 401, determining a second weight according to the number of successful accesses of the second device to the first application; wherein the second weight is negatively correlated with the number of successful accesses;

[0081] Step 402, determining a fourth trust level according to the third trust level and the second weight;

[0082] Step 403: Determine whether to send the first access request to the first application according to the first trust level and the fourth trust level.

[0083] It can be understood that in the embodiment of the present application, the second weight is determined according to the number of successful accesses of the second device to the first application, and the second weight is negatively correlated with the number of successful accesses; the fourth trust is determined according to the third trust and the second weight; and whether to send the first access request to the first application is determined according to the first trust and the fourth trust. In this way, since the more successful accesses, the smaller the probability that the first account is created maliciously, a smaller weight is assigned to it; conversely, the fewer successful accesses, it cannot be ruled out that the first account is created maliciously, so a larger weight is assigned to it; based on this, the fourth trust is determined, so that the determined fourth trust is more accurate. In this way, based on a more accurate trust, it is determined whether to send the first access information to the first application, which is beneficial to improving the security of the first application and ensuring the system security of the system where the first application is located.

[0084] For example, as a possible implementation method, assume that there are n associated users u1, u2, ..., u n , then the formula for the third trust degree is:

[0085]

[0086] in, Indicates the associated account u i The trust level of the account, U(i) represents the associated account u i For the first account u the first weight.

[0087] Accordingly, the formula for the fourth degree of trust is:

[0088]

[0089] Where k is the number of successful accesses of the second device to the first application, and a is a constant.

[0090] In some embodiments, Figure 5 As shown, step 103 can be implemented through the following steps 501 to 504:

[0091] Step 501, determining a sixth trust level according to the first trust level and a pre-recorded second trust level;

[0092] Step 502: When the sixth trust level is greater than or equal to the trust level threshold, activate the role corresponding to the first account;

[0093] Step 503, verifying the role authority of the role;

[0094] Step 504: if the verification fails, initiate an approval process; the approval process is used to approve whether to send the first access request to the first application.

[0095] It can be understood that in the embodiment of the present application, when the sixth trust level is greater than the trust threshold, the first access request is not directly sent to the first application, but the role authority is verified, and if the verification fails, an approval process is generated. In this way, compared with directly sending the first access request to the first application, it is beneficial to improve the security of the first application, thereby improving the security of the system where the first application is located.

[0096] It should be understood that in the embodiments of the present application, the trust threshold is not limited. The trust threshold can be preset or set according to actual conditions. For example, if the first application or the system where the first application is located suffers from more risky behaviors during a period of time, a larger trust threshold can be set.

[0097] In the embodiments of the present application, role permissions refer to the rights of a role to access system / application functions and resources. These permissions can be access permissions to specific functions, or permissions to read, write, or modify specific data. Role permissions are the basis for defining the responsibilities and permissions of a role in a system / application. By assigning permissions to roles, user permission management can be simplified, and permissions can be allocated and controlled according to the user's responsibilities and roles.

[0098] In some embodiments, if the approval is passed, the first access request is sent to the first application; if the approval is not passed, an alarm signal is output and the first access request is recorded.

[0099] In some embodiments, the approval process may be generated based on the importance of the application being accessed and / or the current permission structure of the system where the application is located.

[0100] In some embodiments, Figure 6 A schematic diagram of an implementation process of an access control method provided in an embodiment of the present application Figure 2 ,like Figure 6 As shown, the method includes the following steps 601 to 603:

[0101] Step 601, when the sixth trust level is less than the trust level threshold, verify whether the first access request is a risky behavior;

[0102] Step 602, if the first access request is not a risky behavior, perform secondary authentication on the first account;

[0103] Step 603: re-determine the first trust level of the first access request; and determine whether to send the first access request to the first application according to the first trust level and a pre-recorded second trust level.

[0104] It can be understood that in the embodiment of the present application, when the sixth trust level is less than the trust level threshold, it is verified whether the first access request is a risky behavior; when the first access request is not a risky behavior, the first account is authenticated twice; the first trust level of the first access request is re-determined; and according to the first trust level and the pre-recorded second trust level, it is determined whether to send the first access request to the first application. In this way, a secondary authentication is performed on possible risky behaviors; it is beneficial to ensure that the non-risky first access request is sent to the first application, and to avoid the phenomenon that a legitimate account cannot access the first application.

[0105] It should be understood that in the embodiments of the present application, the specific implementation method of the secondary authentication is not limited. In some embodiments, the secondary authentication method includes: face authentication, mobile phone number authentication, ID card number authentication, SMS verification code authentication, email verification code authentication, etc.

[0106] In some embodiments, if the first access request is a risky behavior, an alarm signal is output and the first access request is recorded.

[0107] It can be understood that in the embodiment of the present application, when the current access operation is a risky behavior, an alarm signal is output and the first access request is recorded. In this way, intercepting risky behavior is beneficial to improving the security of the first application, thereby improving the security of the system where the first application is located.

[0108] The following examples describe possible implementations of the access control methods described in one or more of the above embodiments.

[0109] The embodiment of the present application provides a design of an intelligent application access control system based on application identity based on trust (i.e., an example of an access control method), which provides a more intelligent access control method in the IDaaS usage scenario; realizes dynamic authorization management, automatic granting of user permissions and more fine-grained access control.

[0110] The embodiment of the present application provides a user trust calculation model in the IDaaS application scenario, which is composed of current trust, recommended trust, and predicted trust based on historical data. Among them, the recommended trust takes into account the influence of trust between users; clustering the user's historical access information (i.e., an example of classifying the historical access information through unsupervised learning technology), using the historical access information of the same category to update the trust, and making better use of the historical access information.

[0111] The access control method provided in the embodiment of the present application can identify risky behaviors and set various response measures such as interception and secondary authentication; when dynamically adjusting access rules, the approval process is dynamically generated based on the importance of the access application and the current authority structure of the system.

[0112] When a user accesses an application (i.e., the second device sends a first access request), the specific process is as follows:

[0113] 11. When a user initiates an access request (ie, an example of a first access request), user-related data is collected according to the user trust model, and the user trust T (ie, an example of a sixth trust) is calculated.

[0114] 12. Calculate the trust level T' (an example of a trust threshold) required for the user to activate his or her own permissions. If T ≥ T', it means that the user's trust level is high enough, and the user's permissions are activated. If T < T', it means that the user's trust level is not high enough, and it is necessary to determine whether the user's access behavior is risky. If there is no risk, perform secondary authentication. After secondary authentication, recalculate the user's trust level. If the user still cannot meet the trust level required to activate permissions after secondary authentication, it is considered that the access behavior is risky.

[0115] 13. After activating the user role, determine whether the current role has permission to access the application (i.e., an example of the first application). If yes, allow the second device to access the application and record the access operation for retraining the prediction trust model. Publish the trust of the first account to facilitate the calculation of the trust of the associated account.

[0116] 14. If the role does not have permission to access the application, the authorization approval process can be automatically triggered because the trust of the first access request meets the conditions. If approved, the second device can obtain permission to access the application, access the application, and record the access operation.

[0117] 15. If the approval is not passed, an alarm will be automatically triggered, and the first access request will be considered a risky operation, and the user access operation will be recorded.

[0118] For example, as a possible implementation, Figure 7A schematic diagram of an implementation process of an access control method provided in an embodiment of the present application Figure 3 ,like Figure 7 As shown, the method includes the following steps 701 to 713:

[0119] Step 701: The user initiates an application access request;

[0120] Step 702, calculating the user's trustworthiness;

[0121] Step 703: whether the user's trust meets the trust required for activating the role; if so, execute step 704; if not, execute step 709;

[0122] Step 704, activating the role;

[0123] Step 705, verify the role authority; if the role authority verification passes, execute step 706; if the role authority verification fails, execute step 707;

[0124] Step 706, access the application;

[0125] Step 707, initiate the approval process;

[0126] Step 708, whether it is approved; if yes, go to step 706; otherwise, go to step 711;

[0127] Step 709, whether it is a risky behavior; if yes, execute step 711; otherwise, execute step 710;

[0128] Step 710, secondary authentication; re-execute step 702;

[0129] Step 711, generating an alarm;

[0130] Step 712, recording user access operations;

[0131] Step 713: Publish the user's trustworthiness.

[0132] The specific calculation method of user trust is as follows:

[0133] The trust level T(u) of user u is determined by the current trust level T C (u), recommendation trust T R (u) and the historical trust T based on historical access information H (u). The calculation formula of trust T(u) is as follows:

[0134] T(u)=αT C (u)+βT R (u)+μT H (u)

[0135] Among them, α>β>μ, α+β+μ=1.

[0136] 21. Current credit rating

[0137] Current credit rating T C (u) The fuzzy analytic hierarchy process (FAHP) is used. This method first divides the user behavior into n attributes, and then divides each attribute into multiple data, thereby refining the fuzzy and uncertain user behavior credit assessment problem into a simple and clear credit weighted sum problem.

[0138] Figure 8 A schematic diagram of attribute data provided in an embodiment of the present application, such as Figure 8 As shown, the target layer includes: user's current trust evaluation; the quasi-side layer includes: reliability attribute P, performance attribute R, and security attribute S; among them, the reliability attribute data include: data transmission bit error rate, data transmission packet loss rate, connection establishment success rate, and number of fault services; the performance attribute data include: link release delay, central processing unit (CPU) utilization, average response time, storage capacity, IP address, and access time; the security attribute data include: whether there is a vulnerability, the number of port scans, the number of bypass operations, the number of username guesses, and the number of password guesses.

[0139] Attribute data can be obtained by using network traffic monitoring tools, monitoring systems, etc. The obtained attribute data is standardized to obtain the user behavior data matrix E = (e ij ) mn The weight vector W is calculated by the calculation method of the hierarchical analysis method. The calculation formula of the weight vector W is as follows:

[0140]

[0141] in, is the weight of the security attribute S, is the weight of the reliable attribute P, is the weight of the performance attribute R.

[0142] The trust evaluation vector F is calculated using the user behavior data matrix E and the weight vector W. The diagonal value of the E×W matrix is ​​the trust evaluation value vector F = (f1, f2, ..., f m ). The calculation formula of the trust evaluation vector F is as follows:

[0143]

[0144] 22. Recommended credit

[0145] The trust of user u is strongly related to the trust of the administrator who created the user. Once the trust of the administrator decreases, the trust of the users related to him will also decrease. The administrator created by the system has the highest trust. The more distant the relationship with the administrator created by the system, the lower the trust. In addition, the user's trust is also related to the applications visited. After the user visits the application, a recommendation trust of the application for the user will be generated. In summary, the user's recommendation trust T R (u) Includes: Application recommendation trust User-associated trust Among them, user recommendation trust T R The calculation formula of (u) is as follows:

[0146]

[0147] Among them, k is the total number of user visits, a is a constant, and a is used to adjust the weights of application recommendation trust and user association trust at different stages. When the user performs the first visit operation, the number of visits k is 0, and the user recommendation trust T R (u) Mainly by user-associated trust Decision; As the number of user visits increases, k increases, The weight of the application recommendation is reduced, and the application recommendation trust The weight of T increases. R (u) Mainly composed of Decide.

[0148] Assume there are n applications a1, a2, …, a n , then the application recommends the expression of credit:

[0149]

[0150] Among them, F i (u) indicates application a i For the trust of user u, A(i) represents the recommendation weight factor of application i. i The calculation formula of (u) is as follows:

[0151]

[0152] Assume that there are n trusted access organizations S = (s1, s2, ..., s n ), T and N represent service organizations s i The historical credit rating and number of successful visits of user u.

[0153] Assume there are n associated users u1,u2,…,u n , then the formula for the third trust degree is:

[0154]

[0155] in, Indicates the associated account u i The trust level of the account, U(i) represents the associated account u i For the first account u the first weight.

[0156] 23. Historical Trust Calculation

[0157] According to the IDaaS application scenario, the risks of access requests initiated by IPs in the office area and outside the office area during working hours and after get off work are not comparable. That is, the high trust in access requests initiated by an account in the office area does not mean that access requests initiated outside the office area are safe. On the contrary, the risk may be higher. Because the use of historical access information needs to consider whether it conforms to the rules of historical use, once an abnormality occurs, the trust should be immediately reduced to achieve the effect of identifying risks. Therefore, historical access information can be clustered, and the trust of historical access information within the time window in this category can be used to calculate the fifth trust. Among them, the calculation formula for the fifth trust is as follows:

[0158]

[0159] Among them, T i (i=1,2,…,h) represents the trust of the i-th historical access information in the time window that belongs to the same category as the current access information, h is the preset time window, δ i Indicates T i The corresponding third weight has a certain attenuation.

[0160] 24. Whether the user's access behavior is risky can be determined as follows:

[0161] In a visit, after the second authentication, the user's trust is recalculated. If the user still cannot meet the trust required to activate the permission after the second authentication, it is considered that the access behavior is risky.

[0162] If the same user triggers secondary authentication multiple times within a period of time and reaches a certain threshold, such as 10 times a day, the user's access is considered to be risky, and the number of times the user's trust is increased is limited to prevent malicious triggering of secondary authentication and improve trust.

[0163] It can be understood that in the access control method provided in the embodiment of the present application, the influence of trust between users is taken into account, and the trust calculation model is improved. In addition, considering the influence between users, it shows a decreasing trend with the increase of the number of visits. Taking into account the influence of IP addresses, time periods, etc. in historical access information, the historical access information is clustered, and the historical access information of the same category is used to update the user trust, and the rules in the historical access information are mined, which is of great significance for identifying risks and reducing useless access information. When dynamically adjusting the access rules, the approval process is dynamically generated according to the importance of the access application and the current authority structure of the system. Set up a variety of countermeasures such as interception and secondary authentication for risky behaviors.

[0164] It should be noted that although the steps of the method in the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.; or, steps in different embodiments may be combined into a new technical solution.

[0165] Based on the foregoing embodiments, an embodiment of the present application provides an access control device, which includes the modules included and the units included in the modules, which can be implemented by a processor; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be an AI acceleration engine (such as NPU, etc.), GPU, central processing unit (CPU), microprocessor (MPU), digital signal processor (DSP) or field programmable gate array (FPGA), etc.

[0166] Fig. 9 A schematic diagram of the structure of an access control device provided in an embodiment of the present application is shown in FIG. Fig. 9 As shown, the access control device 90 includes a receiving module 901, a first determining module 902 and a second determining module 903, wherein:

[0167] A receiving module 901 is configured to receive a first access request sent by a second device, where the first access request is used to request access to a first application;

[0168] A first determination module 902, configured to determine a first trust level of the first access request;

[0169] The second determination module 903 is configured to determine whether to send the first access request to the first application based on the first trust and a pre-recorded second trust, so that the first application responds to the first access request; wherein the second trust includes the trust of the second device for an associated account of the first account of the first application.

[0170] In some embodiments, the second determination module 903 is configured to determine a first weight based on the degree of association between the first account and the associated account; wherein the first weight is positively correlated with the degree of association; determine a third trust based on the trust of the associated account and the first weight; and determine whether to send the first access request to the first application based on the first trust and the third trust.

[0171] In some embodiments, the second determination module 903 is configured to determine a second weight based on the number of successful times the second device accesses the first application; wherein the second weight is negatively correlated with the number of successful times; determine a fourth trust based on the third trust and the second weight; and determine whether to send the first access request to the first application based on the first trust and the fourth trust.

[0172] In some embodiments, the first trust level includes: a fifth trust level; a first determination module 902, configured to determine the historical access information and current access information of the second device to the first application; wherein the access information includes: the IP address of the access and the access time; classifying the historical access information to obtain multiple different categories of historical access information; determining the category of the current access information based on the multiple different categories of historical access information; determining the fifth trust level based on the historical access information corresponding to the category of the current access information.

[0173] In some embodiments, the first determination module 902 is configured to determine a third weight of historical access information within a preset time window; wherein the third weight is negatively correlated with the second distance; the second distance includes: the time distance between the historical access time and the current access time; and determine the fifth trust based on the trust of the historical access information and the corresponding third weight.

[0174] In some embodiments, the second determination module 903 is configured to determine a sixth level of trust based on the first level of trust and a pre-recorded second level of trust; when the sixth level of trust is greater than or equal to a trust threshold, activate the role corresponding to the first account; verify the role permissions of the role; and when the verification fails, initiate an approval process; the approval process is used to approve whether to send the first access request to the first application.

[0175] In some embodiments, the second determination module 903 is configured to verify whether the first access request is a risky behavior when the sixth trust level is less than the trust level threshold; perform secondary authentication on the first account when the first access request is not a risky behavior; re-determine the first trust level of the first access request; and determine whether to send the first access request to the first application based on the first trust level and a pre-recorded second trust level.

[0176] In some embodiments, the second determination module 903 is configured to output an alarm signal and record the first access request if the first access request is a risky behavior.

[0177] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0178] It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processing unit, or may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit. It may also be implemented in the form of a combination of software and hardware.

[0179] It should be noted that in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can be essentially or partly embodied in the form of a software product that contributes to the relevant technology. The computer software product is stored in a storage medium, including several instructions to enable the first device to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0180] This embodiment of the application provides a first device, Fig.10 A schematic diagram of the structure of the first device provided in the embodiment of the present application, such as Fig.10As shown, the first device 100 includes a memory 1001 and a processor 1002, wherein the memory 1001 stores a computer program that can be run on the processor 1002, and the processor 1002 implements the steps in the method provided in the above embodiment when executing the program.

[0181] It should be noted that the memory 1001 is configured to store instructions and applications executable by the processor 1002, and can also cache data to be processed or processed by the processor 1002 and each module in the first device 100 (for example, image data, audio data, voice communication data, and video communication data), which can be implemented through flash memory (FLASH) or random access memory (Random Access Memory, RAM).

[0182] In the embodiment of the present application, the first device 100 can be, for example, a mobile phone, a tablet computer, a laptop computer, a PDA, a personal digital assistant (PDA), a wearable device, etc., which is not specifically limited here.

[0183] An embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the method provided in the above embodiment are implemented.

[0184] An embodiment of the present application provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the steps of the method provided in the above method embodiment.

[0185] It should be noted here that the description of the above first device, storage medium and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the first device, storage medium and computer program product embodiments of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0186] It should be understood that "one embodiment" or "an embodiment" or "some embodiments" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in one embodiment" or "in some embodiments" appearing throughout the specification may not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The above-mentioned sequence numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments. The above description of each embodiment tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. For the sake of brevity, this article will not repeat them.

[0187] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist at the same time, and object B exists alone.

[0188] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0189] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as: multiple modules or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical, mechanical or other forms.

[0190] The modules described above as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules; they may be located in one place or distributed on multiple network units; some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.

[0191] In addition, all functional modules in the embodiments of the present application may be integrated into one processing unit, or each module may be a separate unit, or two or more modules may be integrated into one unit; the above-mentioned integrated modules may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0192] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.

[0193] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for the first device to execute all or part of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks or optical disks.

[0194] The methods disclosed in several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0195] The features disclosed in several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0196] The features disclosed in several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0197] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An access control method, characterized in that: The method is applied to a first device, and the method includes: receiving a first access request sent by a second device, where the first access request is used to request access to a first application; determining a first trust level of the first access request; Determine whether to send the first access request to the first application based on the first trust and a pre-recorded second trust, so that the first application responds to the first access request; wherein the second trust includes the trust of the second device for an associated account of the first account of the first application.

2. The method according to claim 1, characterized in that The determining, according to the first trust level and a pre-recorded second trust level, whether to send the first access request to the first application includes: Determining a first weight according to the degree of association between the first account and the associated account; wherein the first weight is positively correlated with the degree of association; Determining a third trust level according to the trust level of the associated account and the first weight; Determine whether to send the first access request to the first application according to the first trust level and the third trust level.

3. The method according to claim 2, characterized in that The determining, according to the first trust level and the third trust level, whether to send the first access request to the first application further includes: Determine a second weight according to the number of successful times the second device accesses the first application; wherein the second weight is negatively correlated with the number of successful times; Determining a fourth trust level according to the third trust level and the second weight; Determine whether to send the first access request to the first application according to the first trust level and the fourth trust level.

4. The method according to claim 1, characterized in that: The first trust level includes: a fifth trust level; and the determining the first trust level of the first access request includes: Determine historical access information and current access information of the second device to the first application; wherein the access information includes: an accessed IP address and an access time; Classifying the historical access information to obtain multiple different categories of historical access information; Determining the category of current access information according to the multiple different categories of historical access information; The fifth degree of trust is determined according to the historical access information corresponding to the category of the current access information.

5. The method according to claim 4, characterized in that The determining the fifth trust level according to the historical access information corresponding to the category of the current access information includes: Determine a third weight of the historical access information within a preset time window; wherein the third weight is negatively correlated with a second distance; the second distance includes: a time distance between the historical access time and the current access time; A fifth degree of trust is determined according to the degree of trust of the historical access information and the corresponding third weight.

6. The method according to any one of claims 1 to 5, characterized in that: The determining, according to the first trust level and a pre-recorded second trust level, whether to send the first access request to the first application includes: Determining a sixth trust level according to the first trust level and a pre-recorded second trust level; When the sixth trust level is greater than or equal to a trust level threshold, activating the role corresponding to the first account; Verify the role permissions of the role; If the verification fails, an approval process is initiated; the approval process is used to approve whether to send the first access request to the first application.

7. The method according to claim 6, characterized in that The method further comprises: When the sixth trust level is less than the trust level threshold, verifying whether the first access request is a risky behavior; If the first access request is not a risky behavior, performing secondary authentication on the first account; Re-determining a first trust level of the first access request; and determining whether to send the first access request to the first application based on the first trust level and a pre-recorded second trust level.

8. The method according to claim 7, characterized in that The method further comprises: In the case that the first access request is a risky behavior, an alarm signal is output and the first access request is recorded.

9. An access control device, characterized in that: The device comprises: A receiving module, configured to receive a first access request sent by a second device, where the first access request is used to request access to a first application; A first determination module, configured to determine a first trust level of the first access request; The second determination module is configured to determine whether to send the first access request to the first application based on the first trust and a pre-recorded second trust, so that the first application responds to the first access request; wherein the second trust includes the trust of the second device for an associated account of the first account of the first application.

10. A first device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 8 is implemented.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

12. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images