Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application more apparent, the specific technical solutions of the present application will be described in further detail below with reference to the accompanying drawings in the embodiments of the present application. The following examples are illustrative of the application and are not intended to limit the scope of the application.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the application only and is not intended to be limiting of the application.
In the following description reference is made to "some embodiments," "this embodiment," "an embodiment of the application," and examples, etc., which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with one another without conflict.
The descriptions of the "first, second, third" and the like in the embodiments of the present application are used for illustration and distinction of description objects, and are not used for order division, nor do they represent the special limitation of the number of the devices in the embodiments of the present application, and are not intended to constitute any limitation of the embodiments of the present application.
In order to facilitate understanding of the technical solutions of the embodiments of the present application, the following description will explain related technologies or terms of the embodiments of the present application. The following related arts or related arts may be arbitrarily combined with the technical solutions of the embodiments of the present application as an alternative, which all fall within the scope of the embodiments of the present application.
(1) Identity as a service
The identity-as-service (IDENTITY AS A SERVICE, IDAAS) is based on cloud identity and access management services, so that more and more enterprises start to tend to use clouding schemes, on one hand, the cloud-as-service (IDENTITY AS A SERVICE, IDAAS) can be fully communicated with applications on the cloud, and on the other hand, the standardization of clouding can enable the enterprises to outsource time-consuming work, such as creating new user accounts, verifying access requests, identity management and the like.
(2) Access control
The main function of the access control is to prevent unauthorized user operations and limit the operations of unauthorized users on specific devices. Through an access control mechanism, users with different right levels have access rights of respective levels, and each user can only access the private data resources under the corresponding rights of operation. Therefore, the safety of the data can be effectively ensured. Thus access control is a major issue in application identity management.
In a related art, a Role-rights access control (RBAC) based model is provided in which roles are directly associated with rights, and once the system assigns a Role to a user, the user has all the rights associated with the Role until the user access is completed. RBAC is a static access control mechanism that is unable to dynamically adjust the correspondence between user roles (i.e., { userrole }) and role permissions (i.e., { role-permission }).
In another related technology, an internet of things access control model based on trust is provided, the advantages of RBAC and access control (Attribute based access control, ABAC) based on attributes are combined, an access control model based on user trust and attributes is provided, a more flexible authorization mechanism is built by introducing user trust analysis, key data such as user overall trust and access control strategies are stored on a blockchain, security is guaranteed by utilizing security features such as tamper-proof and traceability of the blockchain, and therefore authority granularity, dynamic property and security of an original access control model are enhanced, but the access control model is not suitable for IDaaS scenes.
Among them, RBAC has the following three disadvantages in IDaaS usage scenarios:
(1) The allocation of access rights is static. Some rights that the user obtains are permanent for a certain period of time and are not released by the completion of the operation, i.e. "one-time grant life enjoyment". The access control system cannot manage the follow-up actions of the user, so that the problem of misuse of the user permission is caused, and unsafe factors are introduced. Because the subsequent access application or function process is not supervised in real time, some internal personnel can be in danger because the benefit temptation cannot be disabled, and confidential information of an organization or an enterprise is stolen to be replaced by illegal benefits.
(2) The user access rights cannot be granted automatically. The user rights need to be set manually by a system administrator, which is prone to two problems. On the one hand, when the number of users is large, the number of user role allocation is increased sharply along with the increase of the number of users, the workload of an administrator is large, and the management and maintenance cost is high. On the other hand, the administrator is also unavoidably wrong in the process of manual setting, which causes the consequences that legal users cannot access or privacy data is leaked.
(3) The access control granularity is coarse. The coarser granularity of access control is mainly manifested in two aspects. On the one hand, since the user division is coarser, the same rights are granted to users that are classified as still different. On the other hand, since the rights division is wider, the user is granted not only rights required to complete the task, but also other rights with a wider range.
(4) The relation between the trust level of the common user and the trust level of the administrator creating the user is not considered, and the use of the historical trust level is not sufficient, but simply weighted.
In view of this, an embodiment of the present application provides an access control method, and fig. 1 is a schematic implementation flow diagram of the access control method provided in the embodiment of the present application, as shown in fig. 1, and the method includes steps 101 to 103 as follows:
Step 101, receiving a first access request sent by a second device, where the first access request is used for requesting to access a first application;
Step 102, determining a first trust degree of the first access request;
Step 103, determining whether to send the first access request to the first application according to 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 comprises the trust level of the second equipment on the associated account of the first application.
It can be appreciated that in the embodiment of the 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 the first access request is sent to a first application is determined according to the first trust level and a pre-recorded second trust level, wherein the second trust level comprises the trust level of the second device on an associated account of a first account of the first application. In this way, since the trust degree of the associated account number associated with the first account number is taken into consideration when determining whether to transmit the first access information to the first application, it is beneficial to improve the security of the first application.
This is because there are some attacks to create a new account using an existing account, and thus some dangerous operations are performed using the created new account. Therefore, based on the trust degree of the associated account number associated with the first account number, whether to send the first access request to the first application is determined, which is beneficial to improving the security of the first application, so that the system security of the system where the first application is located is ensured.
Further alternative embodiments of the above steps, and related terms, etc., are described below, respectively.
In step 101, a first access request sent by a second device is received, the first access request being for requesting access to a first application.
It should be understood that, in the embodiment of the present application, the first application is not limited, and the first application may be any application in the system.
At step 102, a first degree of trust of a first access request is determined.
It should be understood that, in the embodiment of the present application, the trust degree is not limited, and the trust degree is used to characterize the trust degree of the access request sent by the second device, so as to determine whether to send the access request to the application to be accessed according to the trust degree, so that the application to be accessed responds to the access request.
In some embodiments, the confidence level may be calculated based on historical interaction records including login times, operational behaviors, access frequency, etc., behavior pattern including abnormal behaviors or potential security threat behaviors, etc., behavioral pattern analysis, and/or security authentication information including digital certificates, password strength, biometric identification, etc.
Trust is a dynamically changing value that adjusts to changes in the behavior and environment of the access requestor. For example, if an access requester exhibits abnormal behavior or suffers from a security attack, its trust level may be reduced, while if it continues to exhibit a good behavior pattern and passes security authentication, its trust level may be increased.
In some embodiments, the first confidence level includes a fifth confidence level, fig. 2 is a schematic flowchart of an implementation for determining the fifth confidence level according to an embodiment of the present application, as shown in fig. 2, the fifth confidence level may be determined by the following steps 201 to 204;
Step 201, determining historical access information and current access information of the second equipment to the first application, wherein the access information comprises an accessed IP address and access time;
step 202, classifying the history access information to obtain a plurality of different types of history access information;
Step 203, determining the category of the current access information according to the historical access information of the plurality of different categories;
Step 204, determining the fifth trust level according to the historical access information corresponding to the category of the current access information.
It can be appreciated that in the embodiment of the application, the historical access information and the current access information of the second device to the first application are determined, wherein the access information comprises an accessed internet protocol (Internet Protocol, IP) address and access time, the historical access information is classified to obtain a plurality of different types of historical access information, the type of the current access information is determined according to the plurality of different types of historical access information, and the fifth trust degree is determined according to the historical access information corresponding to the type of the current access information. Therefore, the fifth trust degree is determined according to the historical access information belonging to the same category with the current access information, and the determined first trust degree is more accurate, so that whether the first access information is sent to the first application is determined based on the more accurate trust degree, the safety of the first application is improved, and the system safety of a system where the first application is located is further ensured.
This is because it is more likely that the access request is transmitted using the IP address of the office area at the office time, and if the access request is transmitted using the IP address outside the office area at the office time, it is interpreted that the reliability of the access request at this time is not high. If the confidence level of the current access request is calculated using all the historical access information, the calculated confidence level may be inaccurate. Therefore, the fifth confidence level is determined by using the historical access information belonging to the same category as the current access information, which is beneficial to making the determined first confidence level more accurate.
It should be understood that, in the embodiment of the present application, the access information is not limited, and the access information may further include access information of other dimensions besides the accessed IP address and access time, for example, information such as access duration, access page, access operating system used by access, browser type and version, and the like.
It should be understood that, in the embodiment of the present application, the manner of classifying the historical access information is not limited, and classifying the historical access information refers to classifying the historical access information into different categories. In some embodiments, the historical access information may be classified by an unsupervised learning technique, may be classified by a supervised learning technique, and may be classified by a semi-supervised learning technique.
In some embodiments, the determining the fifth confidence level according to the 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 inversely related to a second distance, the second distance includes a time distance between the historical access time and the current access time, and determining the fifth confidence level according to the confidence level of the historical access information and the corresponding third weight.
It can be appreciated that in the embodiment of the application, a corresponding third weight is given 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 inversely related to the time distance, and the fifth trust degree is determined according to the trust degree of the historical access information and the third weight. Therefore, the determined fifth trust degree is more fit with the access habit of the second device according to the third weight, so that the fifth trust degree which is more fit with the actual situation is obtained, and further, the more accurate first trust degree is obtained.
This is because the access habits of the user may change, so that historical access information closer to the current access time is given a greater weight, and historical access information farther from the current access time is given a lesser weight, which is beneficial to making the determined fifth confidence level more consistent with the access habits of the second device.
It should be understood that, in the embodiment of the present application, the preset time window is not limited, and the preset time window may be set according to actual situations.
Illustratively, as one possible implementation manner, according to IDaaS application scenarios, on-duty time and off-duty time, the risk of initiating an access request is not comparable to the IP in the office area and the IP outside the office area, i.e., the trust of an access request initiated by an account in the office area is high, and cannot represent that the access request initiated outside the office area is safe, but the risk is higher. Because for the use of the historical access information, whether the historical use rule is met needs to be considered, once the abnormality occurs, the trust degree should be reduced immediately, and the effect of identifying the risk is achieved. Thus, historical access information may be clustered and a fifth confidence level calculated using the confidence levels of the historical access information within the time window in the category. The calculation formula of the fifth trust degree is as follows:
Wherein, T i (i=1, 2,.., h) represents the trust degree of the i-th historical access information belonging to the same category as the current access information recorded in the time window, h is a preset time window, δ i represents a third weight corresponding to T i, and has a certain attenuation.
In step 103, whether to send the first access request to the first application is determined according to 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 comprises the trust level of the associated account number of the first application by the second device.
It should be understood that, in the embodiment of the present application, the associated account number is not limited. In some embodiments, the associated account includes an account having a management relationship with the first account. For example, account A creates account B and account B creates account C, and if account B is the first account, account A and account C are associated accounts of account B.
In some embodiments, as shown in fig. 3, step 103 may be implemented by steps 301 through 303 as follows:
Step 301, determining a first weight according to the association degree between a first account and the associated account, wherein the first weight is positively related to the association degree;
Step 302, determining a third trust degree according to the trust degree of the associated account and the first weight;
Step 303, determining whether to send the first access request to the first application according to the first trust level and the third trust level.
It can be appreciated that in the embodiment of the application, the first weight is determined according to the association degree between the first account and the associated account, wherein the first weight is positively correlated with the association degree, the third trust degree is determined according to the trust degree of the associated account and the first weight, and whether the first access request is sent to the first application is determined according to the first trust degree and the third trust degree. The method comprises the steps of determining a first account number, determining a first access information, determining a second account number, determining a third trust level, determining whether to send the first access information to a first application based on the third trust level, determining whether to send the first access information to the first application based on the third trust level, and determining the security of the system where the first application is located.
This is because if a certain administrator wants to perform some dangerous operations, it is more likely to create an account directly associated with the administrator to perform dangerous operations, so that the first weight is determined according to the association degree between the first account and the associated account, and the first weight is positively correlated with the association degree, which is beneficial to obtaining more accurate trust degree.
It should be understood that, in the embodiment of the present application, the degree of association is not limited. In some embodiments, the association degree refers to a degree of how far and how near the associated account is in a management relationship with the first account. For example, account A creates account B, account B creates account C, account C creates account D, and if account B is the first account, the distance of the management relationship between account A and account B is smaller than that between account D and account B.
In some embodiments, a first weight is determined according to an association relationship between the first account and an account created by a system where the first application is located, where the association relationship is positively related to the first weight.
It should be understood that in the embodiment of the present application, the trust degree of the account created by the system is highest, and the farther the association relationship between the first account and the account created by the system is, the lower the trust degree is.
In some embodiments, as shown in fig. 4, step 303 may be implemented by steps 401 through 403 as follows:
Step 401, determining a second weight according to the success times of the second equipment to access the first application, wherein the second weight is inversely related to the success times;
step 402, determining a fourth confidence level according to the third confidence level and the second weight;
Step 403, determining whether to send the first access request to the first application according to the first trust level and the fourth trust level.
It can be appreciated that in the embodiment of the present application, the second weight is determined according to the number of successes of the second device to access the first application, and the second weight is inversely related to the number of successes, the fourth confidence level is determined according to the third confidence level and the second weight, and whether to send the first access request to the first application is determined according to the first confidence level and the fourth confidence level. In this way, the more the number of successful access times is, the smaller the probability that the first account is maliciously created is, the smaller the weight is given to the first account, otherwise, the fewer the number of successful access times is, the larger the weight is given to the first account because the first account cannot be maliciously created, the fourth trust degree is determined based on the first account, so that the determined fourth trust degree is more accurate, and therefore, based on the more accurate trust degree, whether the first access information is sent to the first application is determined, the security of the first application is improved, and the security of a system where the first application is located is guaranteed.
Illustratively, as one possible implementation, assuming that there are n associated users u 1,u2,…,un, the third confidence level is formulated as:
Wherein, Representing the trust level of the associated account U i, U (i) represents the first weight of the associated account U i with respect to the first account U.
Accordingly, the fourth confidence level is given by:
Where k is the number of successes of the second device to access the first application and a is a constant.
In some embodiments, as shown in fig. 5, step 103 may be implemented by steps 501 through 504 as follows:
step 501, determining a sixth confidence level according to the first confidence level and the second confidence level recorded in advance;
Step 502, activating a role corresponding to the first account under the condition that the sixth trust degree is greater than or equal to a trust degree threshold;
step 503, verifying the role authority of the role;
and step 504, initiating an approval process if the verification fails, wherein the approval process is used for approving whether the first access request is sent to the first application.
It may be appreciated that in the embodiment of the present application, in the case where the sixth confidence level is greater than the confidence threshold, the first access request is not directly sent to the first application, but the right is checked, and in the case where the check is not passed, an approval process is generated. Therefore, compared with the method that the first access request is directly sent to the first application, the method is beneficial to improving the safety of the first application, and therefore the safety of a system where the first application is located is improved.
It should be understood that in the embodiment of the present application, the trust threshold is not limited. The trust threshold may be preset, or may be set according to actual situations. For example, if the first application or the system in which the first application is located is subject to more risk behavior for a certain period of time, a greater confidence threshold may be set.
In the embodiment of the application, the role authority refers to the right of the role to access the system/application functions and resources. These rights may be access rights to specific functions, or read, write or modify rights to specific data. Role rights are the basis for defining roles' responsibilities and rights in the system/application. By assigning rights to roles, user rights management can be simplified and rights assignment and control can be performed according to the responsibilities of the user and roles.
In some embodiments, the first access request is sent to the first application if the approval passes, and an alert signal is output and the first access request is recorded if the approval does not pass.
In some embodiments, the approval process may be generated based on the importance of the application being accessed and/or the current rights structure of the system in which the application is located.
In some embodiments, fig. 6 is a second implementation flowchart of an access control method according to an embodiment of the present application, as shown in fig. 6, where the method includes steps 601 to 603 as follows:
Step 601, verifying whether the first access request is a risk action if the sixth confidence level is smaller than the confidence threshold;
step 602, performing secondary authentication on the first account under the condition that the first access request is not a risk behavior;
And determining whether to send the first access request to the first application according to the first trust level and a pre-recorded second trust level.
It can be appreciated that in the embodiment of the present application, if the sixth confidence level is smaller than the confidence level threshold, whether the first access request is a risk action is verified, if the first access request is not a risk action, the second authentication is performed on the first account, the first confidence level of the first access request is redetermined, and whether the first access request is sent to the first application is determined according to the first confidence level and the second confidence level recorded in advance. The method and the device are beneficial to ensuring that the first non-risk access request is sent to the first application, and avoiding the phenomenon that the legal account cannot access the first application.
It should be understood that, in the embodiment of the present application, a specific implementation manner of the secondary authentication is not limited. In some embodiments, the secondary authentication mode comprises face authentication, mobile phone number authentication, identity card number authentication, short message authentication code authentication, mailbox authentication code authentication and the like.
In some embodiments, in the event that the first access request is a risky behavior, an alert signal is output and the first access request is recorded.
It may be appreciated that in the embodiment of the present application, in the case that the current access operation is a risk action, an alarm signal is output and the first access request is recorded. Therefore, the risk behaviors are intercepted, and the security of the first application is improved, so that the security of a system where the first application is located is improved.
Possible implementations of the access control method described in one or more of the above embodiments are described by way of example below.
The embodiment of the application provides an application identity intelligent application access control system design (namely an example of an access control method) based on trust, provides a more intelligent access control method in IDaaS use scenes, and realizes dynamic authorization management, automatic authorization of user permission and finer-granularity access control.
The embodiment of the application provides a user trust degree calculation model in IDaaS application situations, which consists of current trust degree, recommended trust degree and predicted trust degree based on historical data. The method comprises the steps of recommending the trust degree, clustering historical access information of users (namely, an example of classifying the historical access information through an unsupervised learning technology), updating the trust degree by using the historical access information of a uniform category, and more fully using the historical access information.
The access control method provided by the embodiment of the application can identify risk behaviors, set various countermeasures such as interception, secondary authentication and the like, and dynamically generate an approval process according to the importance of access application and the current authority structure of the system when dynamically adjusting the access rule.
When a user accesses a certain application (i.e. the second device sends a first access request), the specific flow is as follows:
When a user initiates an access request (i.e. an example of a first access request), user-related data is collected according to a user trust model, and a user trust T (i.e. an example of a sixth trust) is calculated.
12, Calculating the trust degree T '(namely an example of a trust degree threshold) required by the user to activate the self authority, and activating the authority of the user if T is more than or equal to T' which indicates that the trust degree of the user is high enough. If T < T', it is indicated that the user trust is not high enough, it is necessary to determine whether the access behavior of the user is at risk. If there is no risk, a secondary authentication is performed. And after the secondary authentication, recalculating the user trust degree. If the user is not able to meet the trust level required by the activation right after the user performs the secondary authentication, the access behavior is considered to be at risk.
13, After activating the user role, it is determined whether the current role has permission to access the application (i.e., an example of the first application). If so, the second device is made to access the application and the access operation is recorded for retraining the predictive confidence model. And issuing the trust degree of the first account number, so that the trust degree of the associated account number can be conveniently calculated.
14, If the role does not have the authority to access the application, since the trust degree of the first access request meets the condition, the authorization approval process can be automatically triggered. If the second device passes the approval, the second device can acquire the authority of accessing the application, access the application and record the access operation.
And 15, if the approval is not passed, automatically triggering an alarm, considering the first access request as a risky operation, and recording the user access operation.
As a possible implementation manner, fig. 7 is a schematic diagram of a third implementation flow of an access control method according to an embodiment of the present application, as shown in fig. 7, and the method includes the following steps 701 to 713:
step 701, a user initiates an application access request;
step 702, calculating the trust of the user;
Step 703, if the user trust meets the trust required for activating the character, executing step 704, if not, executing step 709;
step 704, activating a role;
Step 705, checking the role authority, if the role authority check is passed, executing step 706, if the role authority check is not passed, executing step 707;
Step 706, accessing an application;
Step 707, initiating an approval process;
step 708, if pass approval, execute step 706 if yes, otherwise execute step 711;
Step 709, if so, executing step 711, otherwise executing step 710;
Step 710, secondary authentication, re-executing step 702;
Step 711, generating an alarm;
Step 712, recording user access operations;
In step 713, user confidence is published.
The specific calculation method of the user trust degree is as follows:
The trust level T (u) of the user u is composed of the current trust level T C (u), the recommended trust level T R (u) and the historical trust level T H (u) based on the historical access information. The calculation formula of the trust degree T (u) is as follows:
T(u)=αTC(u)+βTR(u)+μTH(u)
Wherein α > β > μ, α+β+μ=1.
21, Current credit
The current confidence level T C (u) is Fuzzy ANALYTIC HIERARCHY Process (FAHP). The method divides the user behavior into n attributes, and then divides each attribute into a plurality of data, thereby refining the fuzzy and uncertain user behavior credit assessment problem into a simple and definite credit weighting summation problem.
Fig. 8 is a schematic diagram of attribute data provided by the embodiment of the application, wherein, as shown in fig. 8, a target layer comprises user current trust evaluation, a quasi-side layer comprises reliable attribute P, performance attribute R and security attribute S, wherein, the reliable attribute data comprises data transmission error rate, data transmission packet loss rate, connection establishment success rate and fault service frequency, the performance attribute data comprises delay of link release, central processing unit (Central Processing Unit, CPU) utilization, average response time, storage capacity, IP address and access duration, and the security attribute data comprises whether loopholes exist, scanning port frequency, override operation frequency, guessing user name frequency and guessing password frequency.
The attribute data may be obtained through the use of network traffic monitoring tools, monitoring systems, and the like. Carrying out standardization processing on the obtained attribute data to obtain a user behavior data matrix E= (E ij)mn. Through a calculation method of a hierarchical analysis method, a weight vector W is calculated, wherein the calculation formula of the weight vector W is as follows:
Wherein, As the weight of the security attribute S,As the weight of the reliable attribute P,Is the weight of the performance attribute R.
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= (F 1,f2,…,fm). The calculation formula of the trust evaluation vector F is as follows:
22, recommended credit
The trust level of the user u is strongly related to the trust level of the administrator creating the user, and once the trust level of the administrator is reduced, the trust level of the user related to the administrator is reduced. The manager created by the system has the highest trust, and the farther the manager created by the system is, the lower the trust. In addition, the user trust level is also related to the accessed application, and after the user accesses the application, the recommended trust level of the application for the user is generated. In summary, the user recommendation confidence level T R (u) includes an application recommendation confidence levelUser-associated confidence levelThe calculation formula of the user recommendation trust degree T R (u) is as follows:
Wherein k is the total number of user accesses, a is a constant, a is used for adjusting weights of application recommendation trust and user association trust in different stages, when a user performs access operation for the first time, the number of accesses k is 0, and the user recommendation trust T R (u) is mainly determined by the user association trust Deciding that as the user's access volume increases, k increases,Weight reduction of (2) application recommendation confidenceIs mainly composed of T R (u)And (5) determining.
Assuming that there are n applications a 1,a2,…,an, then the expression of the application recommendation confidence level:
where F i (u) represents the confidence of application a i in user u and A (i) represents the recommendation weight factor for application i. The calculation formula of F i (u) is as follows:
Assuming that there are N trusted access organizations s= (S 1,s2,...,sn), T and N represent the historical confidence of the service organization S i with user u and the number of successful accesses, respectively.
Assuming that there are n associated users u 1,u2,…,un, the third confidence level is given by:
Wherein, Representing the trust level of the associated account U i, U (i) represents the first weight of the associated account U i with respect to the first account U.
23, Historical trust calculation
According to IDaaS application scenarios, the working time and the working time are not comparable with the IP in the office area and the IP outside the office area, namely, the trust degree of the access request initiated by an account in the office area is high, the access request initiated outside the office area cannot be represented to be safe, and the risk is higher. Because for the use of the historical access information, whether the historical use rule is met needs to be considered, once the abnormality occurs, the trust degree should be reduced immediately, and the effect of identifying the risk is achieved. Thus, historical access information may be clustered and a fifth confidence level calculated using the confidence levels of the historical access information within the time window in the category. The calculation formula of the fifth trust degree is as follows:
Wherein, T i (i=1, 2,.., h) represents the trust degree of the i-th historical access information belonging to the same category as the current access information recorded in the time window, h is a preset time window, δ i represents a third weight corresponding to T i, and has a certain attenuation.
24, Judging whether the user access behavior has risks or not, wherein the judging method is as follows:
in the first access, after the second authentication, the user trust level is recalculated. If the user is not able to meet the trust level required by the activation right after the user performs the secondary authentication, the access behavior is considered to be at risk.
If the secondary authentication is triggered for multiple times within a period of time by the same user, and a certain threshold value is reached, for example, 10 times a day, the user is considered to have risk of accessing, the user trust degree lifting times are limited, malicious triggering of the secondary authentication is prevented, and the trust degree is improved.
It can be understood that in the access control method provided by the embodiment of the application, the influence of the trust degree between users is considered, and the trust degree calculation model is improved. And, considering the influence between users, the trend is decreasing as the number of accesses increases. The influence of IP addresses, time periods and the like in the historical access information is considered, the historical access information is clustered, the same type of historical access information is used for updating the user trust level, rules in the historical access information are mined, and the method has important significance in identifying risks and reducing useless access information. When the access rule is dynamically adjusted, an approval process is dynamically generated according to the importance of the access application and the current authority structure of the system. And setting various countermeasures such as interception, secondary authentication and the like for the risk behaviors.
It should be noted that although the steps of the methods of the present application are depicted in the accompanying drawings in a particular order, this does not require or imply that the steps must be performed in that particular order, or that all illustrated steps be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to be performed, and/or one step decomposed into multiple steps to be performed, etc., or steps in different embodiments combined into new solutions.
Based on the foregoing embodiments, the embodiments of the present application provide an access control device, where the access control device includes each module included, and each unit included in each module may be implemented by a processor, and certainly may also be implemented by a specific logic circuit, where in an implementation process, the processor may be an AI acceleration engine (such as an NPU, etc.), a GPU, a Central Processing Unit (CPU), a Microprocessor (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.
Fig. 9 is a schematic structural diagram of an access control device according to an embodiment of the present application, as shown in fig. 9, an access control device 90 includes a receiving module 901, a first determining module 902, and a second determining module 903, where:
A receiving module 901, 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 determining module 902 configured to determine a first degree of trust of the first access request;
The second determining module 903 is configured to determine, according to the first trust level and a second pre-recorded trust level, whether to send the first access request to the first application, so that the first application responds to the first access request, where the second trust level includes a trust level of an associated account of the first application by the second device.
In some embodiments, the second determining module 903 is configured to determine a first weight according to a degree of association between the first account and the associated account, where the first weight is positively related to the degree of association, determine a third degree of trust according to the degree of trust of the associated account and the first weight, and determine whether to send the first access request to the first application according to the first degree of trust and the third degree of trust.
In some embodiments, the second determining module 903 is configured to determine a second weight according to a number of successes of the second device to access the first application, where the second weight is inversely related to the number of successes, determine a fourth degree of trust according to the third degree of trust and the second weight, and determine whether to send the first access request to the first application according to the first degree of trust and the fourth degree of trust.
In some embodiments, the first confidence level includes a fifth confidence level, a first determining module 902 configured to determine historical access information and current access information of the second device to the first application, where the access information includes an accessed IP address and access time, classify the historical access information to obtain a plurality of different types of historical access information, determine a type of current access information according to the plurality of different types of historical access information, and determine the fifth confidence level according to the historical access information corresponding to the type of current access information.
In some embodiments, the first determining module 902 is configured to determine a third weight of the historical access information within a preset time window, where the third weight is inversely related to a second distance, where the second distance includes a time distance between the historical access time and the current access time, and determine a fifth confidence level according to the confidence level of the historical access information and the corresponding third weight.
In some embodiments, the second determining module 903 is configured to determine a sixth trust level according to the first trust level and the second trust level that is recorded in advance, activate a role corresponding to the first account number when the sixth trust level is greater than or equal to a trust level threshold, verify a role authority of the role, and initiate an approval process when the verification is not passed, where the approval process is used to approve whether to send the first access request to the first application.
In some embodiments, the second determining module 903 is configured to verify whether the first access request is a risk action if the sixth confidence level is less than the confidence threshold, perform a second authentication on the first account if the first access request is not a risk action, re-determine a first confidence level of the first access request, and determine whether to send the first access request to the first application according to the first confidence level and a pre-recorded second confidence level.
In some embodiments, the second determining module 903 is configured to output an alert signal and record the first access request if the first access request is a risk action.
The description of the apparatus embodiments above is similar to that of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, please refer to the description of the embodiments of the method of the present application.
It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation. In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units. Or in a combination of software and hardware.
It should be noted that, in the embodiment of the present application, if the method is implemented in the form of a software functional module, and sold or used as a separate product, the method may also be stored in a computer readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing a first device to execute all or part of the methods described in the embodiments of the present application. The storage medium includes various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the application are not limited to any specific combination of hardware and software.
An embodiment of the present application provides a first device, and fig. 10 is a schematic structural diagram of the first device provided in the embodiment of the present application, as shown in fig. 10, the first device 100 includes a memory 1001 and a processor 1002, where the memory 1001 stores a computer program that can be run on the processor 1002, and the processor 1002 implements steps in the method provided in the embodiment described above when executing the program.
It should be noted that the memory 1001 is configured to store instructions and applications executable by the processor 1002, and may also be cached in the processor 1002 and data (for example, image data, audio data, voice communication data, and video communication data) to be processed or already processed by each module in the first device 100, and may be implemented by a FLASH memory (FLASH) or a random access memory (Random Access Memory, RAM).
In an embodiment of the present application, the first device 100 may be, for example, a mobile phone, a tablet computer, a notebook computer, a palm computer, a Personal digital assistant (Personal DIGITAL ASSISTANT, PDA), a wearable device, etc., which is not limited herein.
An embodiment of the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the method provided in the above-described embodiment.
Embodiments of the present application provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform the steps of the method provided by the method embodiments described above.
It is noted here that the description of the first device, the storage medium and the computer program product embodiments above is similar to the description of the method embodiments described above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the first device, the storage medium and the computer program product embodiments of the present application, reference is made to the description of the method embodiments of the present application.
It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" or "some embodiments" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" or "in some embodiments" in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application. The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments. The foregoing description of various embodiments is intended to highlight differences between the various embodiments, which may be the same or similar to each other by reference, and is not repeated herein for the sake of brevity.
The term "and/or" is used herein to describe only one association relationship that associates objects, meaning that there may be three relationships, e.g., object a and/or object B, and that there may be three cases where object a alone exists, object a and object B together, and object B alone.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described embodiments are merely illustrative, e.g., the division of the modules is merely a logical division of functionality, and may be implemented in other manners, e.g., multiple modules or components may be combined or integrated into another system, or some features may be omitted, or not performed. In addition, the various components shown or discussed may be coupled or directly coupled or communicatively coupled to each other via some interface, whether indirectly coupled or communicatively coupled to devices or modules, whether electrically, mechanically, or otherwise.
The modules described as separate components may or may not be physically separate, and components displayed as modules may or may not be physical modules, may be located in one place or distributed on a plurality of network units, and may select some or all of the modules according to actual needs to achieve the purpose of the embodiment.
In addition, each functional module in each embodiment of the present application may be integrated in one processing unit, or each module may be separately used as a unit, or two or more modules may be integrated in one unit, where the integrated modules may be implemented in hardware or in a form of hardware plus a software functional unit.
It will be appreciated by those of ordinary skill in the art that implementing all or part of the steps of the above method embodiments may be implemented by hardware associated with program instructions, where the above program may be stored in a computer readable storage medium, where the program when executed performs the steps comprising the above method embodiments, where the above storage medium includes various media that may store program code, such as a removable storage device, a Read Only Memory (ROM), a magnetic disk, or an optical disk.
Or the above-described integrated units of the application may be stored in a computer-readable storage medium if implemented in the form of software functional modules and sold or used as separate products. Based on such understanding, the technical solution of the embodiments of the present application may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing a first device to execute all or part of the methods described in the embodiments of the present application. The storage medium includes various media capable of storing program codes such as a removable storage device, a ROM, a magnetic disk, or an optical disk.
The methods disclosed in the method embodiments provided by the application can be arbitrarily combined under the condition of no conflict to obtain a new method embodiment.
The features disclosed in the several product embodiments provided by the application can be combined arbitrarily under the condition of no conflict to obtain new product embodiments.
The features disclosed in the embodiments of the method or the apparatus provided by the application can be arbitrarily combined without conflict to obtain new embodiments of the method or the apparatus.
The foregoing is merely an embodiment of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.