Prioritization and approval automation for effective user access management

Abstract

Systems and methods for efficiently managing user access rights, including processing and revalidating user access requests, are disclosed. A computer-implemented method determines a privilege risk score, a user risk score, and an overall risk score associated with a user access request based on a criticality model and metadata. A criticality level is assigned to the user access request based on the overall risk score, and the computer-implemented method processes the user access request. The user access request is processed automatically or manually based on the assigned criticality level. A plurality of user access requests requiring manual processing are processed based on external input, and the plurality of user access requests are prioritized based on respective assigned criticality levels and processing histories of the plurality of user access requests.

Description

[0001] Cross-reference to related applications This application claims the benefit and priority of U.S. Patent Application No. 18 / 544,527, filed December 19, 2023, entitled “Prioritization and Approval Automation for Effective User Access Rights Management,” filed pursuant to 35 USC § 120, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0002] The following disclosures generally relate to prioritization and processing automation for effectively managing user access rights, including user access requests and user access re-authentication requests, based on the criticality level assigned to user access requests or user access re-authentication requests. Summary of the Invention

[0003] In one aspect, this disclosure partially provides a system for managing user access requests, the system comprising: an access criticality module for determining information associated with a user access request; an access criticality assessment calculation engine for determining a risk score associated with the user access request based on the determined information, and assigning a criticality level to the user access request based on the determined risk score; an automation and priority ranking integrator for determining automatic or manual processing of the user access request based on the assigned criticality level; and an access management module for automatically or manually processing the user access request based on the determination made by the automation and priority ranking integrator.

[0004] In one aspect, this disclosure partially provides a computer-implemented method for managing user access requests, the computer-implemented method comprising: determining a permission risk score for a user access request based on a permission criticality model and permission metadata, the permission risk score relating to a risk associated with an access type of the user access request; determining a user risk score for the user access request based on a user criticality model and user metadata, the user risk score relating to a risk associated with the identity of the user access request; determining an overall risk score for the user access request based on a combination of the permission risk score and the user risk score; assigning a criticality level to the user access request based on the overall risk score, the criticality level being either a first criticality level or a second criticality level greater than the first criticality level; automatically processing the user access request by an access management system based on the first criticality level assigned to the user access request; and processing the user access request by the access management system based on external input received by the access management system based on the second criticality level assigned to the user access request.

[0005] In one aspect, this disclosure partially provides a computer-implemented method for managing multiple user access requests, the computer-implemented method comprising: determining a permission risk score for each of the multiple user access requests based on a permission criticality model and permission metadata, the permission risk score for each user access request relating to a risk associated with the access type of each user access request; determining a user risk score for each user access request based on a user criticality model and user metadata, wherein the user risk score for each user access request relating to a risk associated with the identity of each user access request; and determining a combination of the permission risk score and the user risk score associated with each user access request to determine the access type of each user access request. The process includes: assigning an overall risk score to each user access request; assigning a criticality level to each user access request based on the overall risk score, wherein the criticality level is either a first criticality level or a second criticality level greater than the first criticality level; assigning each user access request to a first group of requests or a second group of requests, wherein the first group of requests includes each user access request assigned the first criticality level, and the second group of requests includes each user access request assigned the second criticality level; automatically processing each user access request in the first group of requests by the access management system; and processing each user access request in the second group of requests by the access management system based on multiple external inputs received by the access management system. Attached Figure Description

[0006] In this description, specific details, such as particular aspects, procedures, techniques, etc., are set forth for purposes of explanation and not limitation in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced in other aspects besides these specific details.

[0007] The accompanying drawings, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate aspects of the concepts included in the claimed disclosure and to explain the various principles and advantages of those aspects. In the drawings, the same reference numerals are used throughout different views to refer to the same or functionally similar elements.

[0008] The systems and methods disclosed herein have been indicated by conventional symbols in the accompanying drawings where appropriate, showing only those specific details relevant to understanding various aspects of this disclosure so as not to obscure the disclosure by means of details obvious to those skilled in the art who benefit from the description herein.

[0009] Figure 1 A flowchart of a user access rights management system according to at least one aspect of this disclosure is shown.

[0010] Figure 2 A method for calculating each of a permission risk score, a user risk score, and a dynamic risk score, according to at least one aspect of this disclosure, is shown.

[0011] Figure 3 A flowchart illustrating a process for determining an authority risk score according to at least one aspect of this disclosure is shown.

[0012] Figure 4 A method for managing user access requests according to at least one aspect of this disclosure is shown.

[0013] Figure 5 A method for managing multiple user access requests according to at least one aspect of this disclosure is shown.

[0014] Figure 6 It is a block diagram of a computer device having a data processing subsystem or component according to at least one aspect of the present disclosure.

[0015] Figure 7 It is a schematic representation of an example system including a host according to at least one aspect of this disclosure, within which a set of instructions is executable for performing any or more of the methods discussed herein. Detailed Implementation

[0016] The following disclosure provides exemplary systems, apparatus, and methods for conducting financial transactions and related activities. While reference may be made to such financial transactions in the examples provided below, the aspects are not limited thereto. That is, the systems, methods, and apparatuses described can be used for any suitable purpose.

[0017] Before discussing specific implementation schemes, aspects, or examples, some descriptions of the terms used in this document are provided below.

[0018] As used herein, the term "computing device" or "computer apparatus" can refer to one or more electronic devices configured to communicate directly or indirectly with or on one or more networks. A computing device can be a mobile device, a desktop computer, etc. As examples, a mobile device can include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, a chip, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device may not be a mobile device, such as a desktop computer. Furthermore, the term "computer" can refer to any computing device that includes the necessary components for sending, receiving, processing, and / or outputting data and typically includes a display device, a processor, memory, an input device, a network interface, etc.

[0019] A "payment network" can refer to an electronic payment system used to accept, transmit, or process transactions made by payment devices for funds, goods, or services. Payment networks can transfer information and funds between issuers, acquirers, merchants, and users of payment devices. An illustrative, non-limiting example of a payment network is VisaNet, operated by Visa, Inc.

[0020] A "payment processing network" can refer to a system that typically receives accumulated transaction information from a gateway processing service at fixed times each day and performs a settlement process. Settlement may involve posting transactions to accounts associated with the payment devices used for the transactions and calculating the net debit or credit balance for each user of the payment device. An exemplary payment processing network is Interlink®.

[0021] A “processing network” can include electronic systems for accepting, transmitting, or processing transactions made by a device. A processing network can transfer information between parties to a transaction (e.g., issuers, acquirers, merchants, device users, etc.).

[0022] As used herein, a "secure element" may include secure computer memory in an electronic device capable of storing sensitive data or applications. A secure element may, but does not necessarily, be physically isolated from other memory in the electronic device. A secure element may include, or be contained within, a hardware security module, a software security module, or other mechanisms that provide secure and controlled access to the data stored therein. A secure element may also include a dedicated cryptographic processor for accessing its contents and performing secure operations.

[0023] As used herein, the term "server" can include one or more computing devices, which may be individual, independent machines located in the same or different locations, owned or operated by the same or different entities, and may further be one or more clusters of distributed computers or "virtual" machines housed within a data center. Those skilled in the art will understand and appreciate that the functionality performed by a single "server" may be distributed across multiple different computing devices for various reasons. As used herein, "server" is intended to refer to all such scenarios and should not be construed as or limited to a particular configuration. Furthermore, a server as described herein may, but does not necessarily, reside in (or be operated by) an agent of a merchant, payment network, financial institution, healthcare provider, social media provider, government agency, or any of the aforementioned entities. The term "server" may also refer to or include one or more processors or computers, storage devices, or similar computer arrangements that facilitate multi-party communication and processing through a network environment such as the Internet, but it should be understood that communication may be facilitated through one or more public or private network environments, and various other arrangements are possible. Furthermore, multiple computers (e.g., servers) or other computerized devices (e.g., point-of-sale devices) communicating directly or indirectly in a network environment can constitute a "system" (e.g., a merchant's point-of-sale system). As used herein, references to "server" or "processor" can refer to a previously stated server and / or processor, different servers and / or processors, and / or combinations of servers and / or processors, stated as performing a prior step or function. For example, as used in the specification and claims, a first server and / or first processor stated as performing a first step or function can refer to the same or different servers and / or processors stated as performing a second step or function.

[0024] A "server computer" can typically be a single, powerful computer or a cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers functioning as a single unit. A server computer can be associated with an entity such as a payment processing network, wallet provider, merchant, authentication cloud, acquirer, or issuer. In one instance, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any combination of hardware, software, other logic, or foregoing for serving requests from one or more client computers. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations for serving requests from one or more client computers. In some embodiments or aspects, a server computer can provide and / or support payment network cloud services.

[0025] As used herein, the term “system” may refer to one or more computing devices or a combination of computing devices (e.g., processor, server, client device, software application, components of such computing devices and / or the like).

[0026] "User" can include an individual. In some embodiments or aspects, a user can be associated with one or more personal accounts and / or mobile devices. A user can also be referred to as a cardholder, account holder, or consumer.

[0027] Almost all business entities, especially those with a large number of employees (hereinafter referred to as users), use user access rights management systems. These systems may differ between business entities, but the general outcome is the same. That is, any such system can manage each user's access rights to certain systems, services, etc., used by the business entity. For example, senior executives might have significant user access rights granted to most or all systems, services, etc., while users in entry-level positions might have minimal user access rights to the same systems, services, etc.

[0028] One of the challenges of using a user access rights management system (MARS) is managing a large volume of user access requests or re-authentication requests, which in some cases can result in the MARS handling over a million tasks at any given time. Consequently, reviewers struggle to make diligent and informed decisions regarding each user access request or re-authentication request. For example, due to the sheer volume of tasks, a relatively small team of reviewers might "go through the motions" approving tasks without properly considering each contributing factor, potentially increasing the risk of errors. Any such error can significantly impact a business entity or pose a serious security risk. For instance, if senior executives are not properly granted access to the necessary systems, services, etc., required for their positions, there could be substantial delays in completing tasks. Furthermore, if users holding entry-level positions are mistakenly granted access to high-level systems, services, etc., they could access critical information and pose a serious security risk to the business entity. Therefore, in situations where a MARS must handle a large number of tasks (such as user access requests or user access re-authentication requests), it is crucial to establish quality automation and prioritization techniques. However, currently, a complete, exhaustive, and scalable methodology for properly automating and prioritizing each task is lacking. Therefore, this disclosure provides a solution for implementing an automated and prioritization method to accurately and efficiently complete each task of a user access rights management system.

[0029] Additionally, risks may arise from the fact that user access rights management systems only review and process user access rights during mandatory access reverification periods. For example, a business entity might reverify user access rights only once a year, every six months, etc. Therefore, any such user who may change positions or be relieved of duties between two mandatory access reverification periods may possess incorrect user access rights until the next mandatory access reverification period. This could significantly impact the business entity or pose a serious security risk. For instance, if a user is promoted to a high-level executive position but their user access rights are not updated accordingly, there could be considerable delays in completing their work. Furthermore, if a user is relieved of their duties but their user access rights are not updated or removed, they may continue to access critical information after their term ends, which could pose a serious security risk to the business entity. Therefore, it may be desirable to further incorporate continuous or on-demand user access reverification requests into the solutions disclosed herein.

[0030] In summary, the solution disclosed herein provides a user access rights management system that combines automation and prioritization methods with continuous or on-demand user access re-authentication requests. The disclosed user access rights management system can be used by any business entity to accurately manage large numbers of user access requests or re-authentication requests, although reviewers are relatively few and further, although several contributing factors vary. In short, the solution disclosed herein can first utilize an access criticality module and an access criticality assessment calculation engine. The access criticality module can determine a permission risk score, a user risk score, and a dynamic risk score for at least one user access request or re-authentication request, the dynamic risk score which may be referred to herein as the overall risk score and is a combination of the permission risk score and the user risk score. The access criticality assessment calculation engine can combine each of the permission risk score, the user risk score, and the dynamic risk score. The solution can also assign a criticality level to the at least one user access request or re-authentication request based on the combined risk score and send information related to the criticality level to at least one repository. An automation and prioritization integrator can then determine, based on the assigned criticality level, whether to automatically or manually process (e.g., automatically or manually grant or deny) the at least one user access request or re-authentication request. Finally, during processing, user access can be granted or denied to the user associated with the at least one user access request or re-authentication request. Additional details and features related to the solution disclosed herein are described in more detail below.

[0031] Now, regarding the attached diagram, Figure 1 A flowchart of a user access rights management system 100 according to at least one aspect of this disclosure is shown. The user access rights management system 100 may include an access criticality module 102, an access criticality assessment calculation engine 104, a repository and automation policy module 106, an automation and prioritization integrator 108, and an access management module 110. In summary, the user access rights management system 100 provides a solution that combines automation and prioritization methods with continuous or on-demand user access re-authentication requests to allow commercial entities such as payment networks (e.g., Visa) to accurately manage user access rights.

[0032] In at least one aspect, the user access rights management system 100 begins with an access criticality module 102, which further includes a permission criticality model 102a, a user criticality model 102b, and a dynamic criticality model 102c.

[0033] The access criticality model 102a can determine the nature of a user's access request or re-authentication, as well as the context in which the access is requested. In summary, the nature of the access and the context in which it is requested may influence the associated access risk score, and therefore the criticality level, which will be determined later. A first non-restrictive example shows that read-only access to a document may be less risky than full access to a document, which may include the ability to edit the document. A second non-restrictive example shows that access to low-risk application data may be less risky than access to high-risk application data. A third non-restrictive example shows that access to low-risk network areas may be less risky than access to high-risk network areas. A fourth non-restrictive example shows that access to different data categories corresponds to different associated risk scores, and therefore different criticality levels. For example, access to highly categorized data may correspond to a higher associated risk score, and therefore a higher criticality level, compared to access to uncategorized data.

[0034] User Criticality Model 102b can determine the nature of a user's identity, which can influence the associated user risk score and thus the criticality level, to be determined later. A first non-restrictive example shows that granting access to a temporary or contracted user is riskier than granting access to a full-time user. A second non-restrictive example shows that granting executive-level access is riskier than granting entry-level access. For example, if executive-level access is accidentally granted, significant damage and loss may occur due to a security breach, while, on the other hand, accidentally granting entry-level access may result in minimal damage and loss (if any). A third non-restrictive example shows that granting access to a user who has changed positions (e.g., transferred from one department to another or promoted / demoted) is riskier than granting access to a user who has not changed positions or requiring re-authentication of access.

[0035] The dynamic criticality model 102c can determine associated risks based on a combination of data collected by the permission criticality model 102a and the user criticality model 102b. A first non-restrictive example shows that a user access request or re-authentication that violates segregation of duties is always very risky. A second non-restrictive example shows that granting temporary, time-limited, or timely access is always less risky than granting full access. A third non-restrictive example shows that team outliers are considered suspicious and risky. For example, if only one or a few users on a team are requesting access or re-authentication, the request can be considered suspicious and risky. A fourth non-restrictive example shows that granting access to a user who has not been previously vetted is riskier than granting access to a user who has been vetted at least once in the past. A fifth non-restrictive example shows that granting access to a new user is riskier than granting access or re-authentication to a pre-existing user. A sixth non-restrictive example shows that granting access to a system used by a large group is riskier than granting access to a system used by a small group. For example, a user with editable access to a document that is publicly viewable is at greater risk than a user with editable access to a document that is only viewable by a selected minority.

[0036] In summary, the permission criticality model 102a, the user criticality model 102b, and the dynamic criticality model 102c can determine the risks associated with user access requests or user access re-authentication requests. In at least one aspect, the associated risks determined from each of the permission criticality model 102a, the user criticality model 102b, and the dynamic criticality model 102c can be sent, respectively, to the permission risk scorer 104a, the user risk scorer 104b, and the dynamic risk scorer 104c included in the access criticality assessment calculation engine 104.

[0037] Permission risk scorer 104a can be responsible for calculating permission risk scores based on data collected from permission criticality model 102a and permission metadata. In at least one aspect, permission metadata may include information corresponding to each contributing factor of permission data, such as a risk score value. User risk scorer 104b can be responsible for calculating user risk scores based on data collected from user criticality model 102b and user metadata. In at least one aspect, user metadata may include information corresponding to each contributing factor of user data, such as a risk score value. Dynamic risk scorer 104c can be responsible for calculating dynamic risk scores based on data collected from dynamic criticality model 102c and a combination of permission metadata and user metadata.

[0038] In at least one aspect, after the access criticality assessment calculation engine 104 calculates the permission risk score, user risk score, and dynamic risk score respectively through the permission risk scorer 104a, user risk scorer 104b, and dynamic risk scorer 104c, the user access rights management system 100 can assign a criticality level to the user access request or re-authentication request. In at least one aspect, the criticality level can be at least one of a first criticality level or a second criticality level greater than the first criticality level. In another aspect, the criticality level can be at least one of a first criticality level (such as a "low" criticality level), a second criticality level greater than the first criticality level (such as a "medium" criticality level), a third criticality level greater than the second criticality level (such as a "high" criticality level), or a fourth criticality level greater than the third criticality level (such as a "critical" criticality level). In yet another aspect, the criticality level can be any of an unlimited number of criticality levels, where each criticality level can correspond to a numerical value. As mentioned above, the number of examples of criticality levels is not limited to this. In all respects, the criticality level is assigned based at least on a combination of permission risk score, user risk score, and dynamic risk score calculated by the access criticality assessment calculation engine 104.

[0039] After assigning a criticality level to a user access request or re-authentication request, the user access rights management system 100 stores the assigned criticality level in at least one repository 106a, which is included in the repository and automation policy module 106. The at least one repository 106a may also store additional user access requests or re-authentication requests and their criticality levels. The at least one repository 106a may also store the processing history of all users of any such business entity, including previously granted or denied user access requests or re-authentication requests, and timestamps of those requests.

[0040] The repository and automation policy module 106 also includes an automation policy 106b, which defines how automation and prioritization decisions should be made based on the assigned criticality level associated with the user corresponding to the user's access request or re-authentication request, and the processing history. A series of non-limiting examples are provided below with respect to at least one aspect, wherein the user access rights management system 100 includes two criticality levels, such as the first and second criticality levels disclosed above. Additionally, a series of non-limiting examples are provided below with respect to another aspect, wherein the user access rights management system 100 includes four criticality levels, such as the "low," "medium," "high," and "critical" criticality levels detailed above.

[0041] A first non-limiting example of an automation policy 106b, including two criticality levels, illustrates that user access requests or re-authentication requests assigned to the second criticality level must always require manual review and processing. A second non-limiting example illustrates that user access requests or re-authentication requests assigned to the first criticality level can be automatically reviewed and processed. However, this may further depend on the criticality level of the user access request or re-authentication request and each or a combination thereof in the processing history. For example, if a user access request or re-authentication request has not been manually reviewed and processed at least once in the past, it may not be processed automatically. A third non-limiting example illustrates that user access requests or re-authentication requests assigned to the first criticality level may require frequent manual review and processing. The required frequency of manual review and processing can be determined by the criticality level of the user access request or re-authentication request and each or a combination thereof in the processing history.

[0042] The first non-limiting example of the automation strategy 106b, which includes four criticality levels, shows that user access requests or re-authentication requests assigned a "high" or "critical" criticality level must always require manual review and processing. The second non-limiting example shows that user access requests or re-authentication requests assigned a "low" or "medium" criticality level can be automatically reviewed and processed. However, this may further depend on the criticality level of the user access request or re-authentication request and each or a combination thereof in the processing history. For example, if a user access request or re-authentication request has not been manually reviewed and processed at least once in the past, it may not be processed automatically. The third non-limiting example shows that user access requests or re-authentication requests assigned a "low" or "medium" criticality level may require frequent manual review and processing. The required frequency of manual review and processing can be determined by the criticality level of the user access request or re-authentication request and each or a combination thereof in the processing history.

[0043] Additional, non-limiting examples illustrate that automation policy 106b can balance the total number of manual and automated processes for said multiple user access requests or re-authentication requests based on the number of available resources (such as the number of reviewers) and the criticality level associated with each of the multiple user access requests or re-authentication requests. That is, to ensure accurate and timely processing, automation policy 106b can provide a balance between manual and automated processing. For example, during a period comprising an overwhelming number of user access requests or re-authentication requests, automation policy 106b can instruct the user access rights management system 100 to automatically process user access requests or re-authentication requests that have been assigned a relatively low criticality level, even if they typically require manual review and processing, such as when the user access requests or re-authentication requests have not been manually reviewed and processed in the past.

[0044] In summary, the repository and automation policy module 106 acts as an important part of the user access rights management system 100 by assigning criticality levels to user access requests or re-authentication requests, storing the assigned criticality levels in at least one repository 106a, and providing automation policies 106b that define how automation and prioritization decisions should be made in the user access rights management system 100. In at least one aspect, the assigned criticality levels and the processing history associated with the user access request or re-authentication request, as well as each of the automation policies 106b, can be provided to the automation and prioritization integrator 108.

[0045] In at least one aspect, the automation and prioritization integrator 108 can determine whether a user access request or re-authentication request should be processed manually or automatically based on information received from the repository and automation policy module 106. Furthermore, for user access requests or re-authentication requests determined to require manual review and processing, the automation and prioritization integrator 108 can generate a priority order based on each or a combination of the criticality level and processing history corresponding to the user access request or re-authentication request. For example, in at least one aspect, a user access request or re-authentication request with a high criticality level may take precedence over another user access request or re-authentication request with a low criticality level. In another aspect, a user access request or re-authentication request with no processing history may take precedence over another user access request or re-authentication request that has been processed at least once previously. In yet another aspect, a user access request or re-authentication request with a high criticality level and no processing history may take precedence over another user access request or re-authentication request with a low criticality level that has been processed at least once previously. It should be noted that other combinations of criticality level and processing history are possible, although not all possible combinations are disclosed herein. Therefore, the examples disclosed above are not limited to these.

[0046] In at least one aspect, the automation and prioritization integrator 108 can also generate a priority ranking list for display on a user interface used by the reviewer. Furthermore, the automation and prioritization integrator 108 can generate visual indicators for each task, corresponding to a priority level determined by the automation and prioritization integrator 108, for display on the user interface used by the reviewer. By generating each or both of the priority ranking list and visual indicators for each task, the reviewer can efficiently and accurately review and process tasks requiring manual review and processing based on the determined priorities.

[0047] In at least one aspect, the automation and prioritization integrator 108 can also generate on-demand user access re-authentication or reprocessing based on determining that the assigned criticality level of a user access request or re-authentication request differs from the previously assigned criticality level of a user access request or re-authentication request associated with previous processing of the user access request or re-authentication request. In at least one aspect, the automation and prioritization integrator 108 can generate on-demand access re-authentication or reprocessing based on a change in criticality level exceeding predetermined criteria. In a non-limiting example, such predetermined criteria may include changes from criticality levels that allow automated processing to criticality levels that require manual review and processing.

[0048] In at least one aspect, the automation and prioritization integrator 108 can also initiate schedule-based user access re-authentication or reprocessing. Since the automation and prioritization integrator 108 generates on-demand user access re-authentication or reprocessing, schedule-based user access re-authentication or reprocessing may be less frequent. Nevertheless, schedule-based user access re-authentication or reprocessing can be once a year, once every six months, once every three months, etc.

[0049] Based on the automation and prioritization integrator 108, and due to the assigned criticality level and the determination of the processing history associated with the user access request or re-authentication request, the access management module 110 can initiate prioritized manual processing 110a or automatic processing 110b. In at least one aspect, manual processing 110a may include manual approval (e.g., granting access) or disapproval (e.g., denying access). In at least one aspect, automatic processing 110b may include automatic approval (e.g., granting access) or disapproval (e.g., denying access). Thus, the user access request or re-authentication request can be completed, and access can be granted or denied to the user associated with the user access request or re-authentication request. Additionally, the prioritized manual processing 110a or automatic processing 110b will be provided to the at least one repository 106a, such that the processing history associated with the user access request or re-authentication request can be updated in the repository and the automation policy module 106.

[0050] In at least one aspect, the user access rights management system 100 may also include continuous, on-demand, or scheduled updates to determine updated permission risk scores, updated user risk scores, and updated dynamic risk scores. In summary, updated permission risk scores, updated user risk scores, and updated dynamic risk scores can be combined to assign updated criticality levels to user access requests or re-authentication requests. As a result, the user access rights management system 100 can process user access requests or re-authentication requests manually or automatically based on changes between updated criticality levels and previously assigned criticality levels associated with the user access request or re-authentication request. By utilizing continuous, on-demand, or scheduled updates, the user access rights management system 100 can allow business entities to accurately manage large numbers of user access requests or re-authentication requests, even with relatively few reviewers and further, even as several contributing factors change.

[0051] Figure 2 A method 200 for calculating each of a permission risk score, a user risk score, and a dynamic risk score, according to at least one aspect of this disclosure, is shown. In at least one aspect, method 200 may include: a first step 202 for calculating a permission criticality model (such as...) Figure 1 The permission risk score for user access requests or re-authentication requests executed by the permission criticality model 102a); the second step 204 is used to calculate the permission risk score for user access requests or re-authentication requests executed by the user criticality model (such as the permission criticality model 102a); Figure 1 The user risk score for user access requests or re-authentication requests executed by the user criticality model 102b; and the third step 206, for calculating the user risk score for user access requests or re-authentication requests executed by the dynamic criticality model (such as the user criticality model 102b); and the third step 206, for calculating the user risk score for user access requests or re-authentication requests executed by the dynamic criticality model (such as the user criticality model 102b). Figure 1The dynamic criticality model 102c) performs dynamic risk scoring on user access requests or re-authentication requests. Therefore, it should be noted that the combination of the first step 202, the second step 204, and the third step 206 forms, for example, a dynamic risk score for user access requests or re-authentication requests. Figure 1 This forms the basis for accessing the critical module 102. Each of the first step 202, the second step 204, and the third step 206 is described in more detail below.

[0052] Step 202 can aggregate data from the Configuration Management Database (CMDB), Identity and Access Management Database (IAM DB), and various target applications (202a). Target applications can include at least one of the applications, systems, or services from which the user access request is requesting access permission. Aggregated data can include application data associated with the user access request or re-authentication request, such as relevant recovery layers, data criticality levels, data classification levels, networks, etc. In other words, aggregated data can include information related to the importance of application data. Additionally, aggregated data can include permission data related to the environment, privileges, etc., associated with the user access request or re-authentication. Step 202 can also analyze the aggregated data (202b) and pass it to the input of the rules engine. The rules engine is highly configurable based on changing security environments and can further provide metadata related to the aggregated data. Finally, step 202 can also calculate a permission risk score (202c) based on the metadata generated from the rules engine.

[0053] The second step 204 can aggregate data from the human resources system (204a), which may include data related to the user's type, user hierarchy, location, and years of service associated with the user's access request or re-authentication. For example, user type may involve whether the user is a temporary, contracted, or full-time user. User hierarchy may involve whether the user holds an entry-level or executive position. User location may involve whether the user is in a nearby location, or whether the user is in a different city, state, or country, which could indicate a fraudulent user attempting a cyberattack on a business entity's system or services. Years of service may involve whether the user is a long-term user, a trusted user, or a new employee. Finally, the second step 204 can also calculate a user risk score (204b) based on each or a combination of the above contributing factors.

[0054] Step 3, 206, can determine whether the user access request or re-authentication request (206a) is an outlier compared to the peer group. For example, as disclosed above, if only one or a few users of the team are requesting access or re-authentication, the request can be considered suspicious and risky. Step 3, 206, can also determine whether the user access request or re-authentication request (206b) violates segregation of duties. For example, if the user access request or re-authentication request is requesting access to all systems, services, etc., required to complete a task without assistance, the request can be considered suspicious and risky. Step 3, 206, can also determine whether the user access request or re-authentication request (206c) has been processed at least once previously. As disclosed above, any user who has not been processed at least once previously poses a greater risk than a user who has been processed at least once previously. Finally, Step 3, 206, can also calculate a dynamic risk score (206d) based on each or a combination of the above contribution factors.

[0055] In at least one aspect, method 200 may also aggregate each of permission risk score, user risk score, and dynamic risk score at access key score aggregator application programming interface 208, said access key score aggregator application programming interface 208 being capable of performing operations with access key assessment calculation engine (such as... Figure 1 The access criticality assessment calculation engine 104 has essentially the same functionality. That is, the access criticality score aggregator application programming interface 208 can combine each of the calculated permission risk score, user risk score, and dynamic risk score, and thus assign a criticality level to a user access request or re-authentication request. As disclosed above, in at least one aspect, the criticality level can be at least one of a first criticality level or a second criticality level greater than the first criticality level. In another aspect, the criticality level can be at least one of a first criticality level (such as a "low" criticality level), a second criticality level greater than the first criticality level (such as a "medium" criticality level), a third criticality level greater than the second criticality level (such as a "high" criticality level), or a fourth criticality level greater than the third criticality level (such as a "critical" criticality level). In yet another aspect, the criticality level can be any of an unlimited number of criticality levels, where each criticality level can correspond to a numerical value. As mentioned above, the number of examples of criticality levels is not limited to this. In all respects, the criticality level is assigned based on a combination of the permission risk score, user risk score, and dynamic risk score calculated in each of the first step 202, the second step 204, and the third step 206, respectively.

[0056] In at least one aspect, method 200 can also process user access requests or re-authentication requests from end user 212 at user access request processing portal 210, which can perform operations such as... Figure 1 The access management module 110 has essentially the same functions as the access management module. That is, the user access request processing portal 210 can process user access requests or re-authentication requests manually or automatically. Similar to... Figure 1 The access management module 110 and the user access request processing portal 210 can use the criticality level of the user access request or re-authentication request and each or a combination thereof in the processing history to determine whether the user access request or re-authentication request can be processed manually or automatically.

[0057] Figure 3 A flowchart 300 illustrating the process for determining an authority risk score according to at least one aspect of this disclosure is shown. In at least one aspect, Figure 3 The determined authority risk score can be compared with Figure 1 and Figure 2 The calculated permission risk scores for each graph in the diagram are substantially the same. In at least one aspect, process flowchart 300 may include a business rules engine 302, which may collect data from each of the configuration management database (CMDB) 304 and the identity and access management (IAM) database 306, and may receive dynamic business rules 308 (which may be necessary for calculating permission risk scores) and key score mappings 310, and may also provide the calculation results to the rules engine database 312.

[0058] In at least one aspect, the configuration management database 304 can aggregate application data associated with user access requests or re-authentication requests, such as relevant recovery layers, data criticality levels, data classification levels, networks, etc. After aggregating the application data, the configuration management database 304 can provide the application data as input to the business rules engine 302. The identity and access management database 306 can aggregate permission data from each of at least one UNIX server 306a, at least one Windows server 306b, at least one Lightweight Directory Access Protocol (LDAP) 306c, at least one connected application 306d, and / or at least one disconnected application 306e. After aggregating the permission data, the identity and access management database 306 can provide the permission data as input to the business rules engine 302.

[0059] In at least one aspect, dynamic business rules 308 may include rules or instructions for use in a computation engine, such as business rules engine 302. In at least one aspect, a key score mapping 310 may map the computation results of business rules engine 302 to help determine permission risk scores based on multiple contribution factors. Furthermore, in at least one aspect, the computation results of business rules engine 302 may be sent to a rules engine database 312 for storage, which may further synchronize permission risk scores with permission catalog 314.

[0060] Figure 4 A method 400 for managing user access requests according to at least one aspect of this disclosure is shown. Now, it will be discussed in conjunction with... Figure 1 The user access management system 100 shown is described together. Figure 4 Method 400 is shown. Therefore, now refer to Figure 1 and Figure 4 In at least one aspect, according to method 400, permission risk scorer 104a determines a permission risk score for a user access request 402 based on a permission criticality model 102a and permission metadata, wherein the permission risk score relates to the risk associated with the access type of the user access request. User risk scorer 104b determines a user risk score for a user access request 404 based on a user criticality model 102b and user metadata, wherein the user risk score relates to the risk associated with the identity of the user access request. Dynamic risk scorer 104c determines a dynamic risk score for a user access request 406 based on a dynamic criticality model 102c and a combination of the permission risk score and the user risk score. In at least one aspect, after each of the determinations described above, method 400 further assigns a criticality level 408 to the user access request via an access criticality assessment calculation engine 104 and based on the dynamic risk score, wherein the criticality level is one of a first criticality level or a second criticality level greater than the first criticality level. In at least one aspect, method 400 further processes user access requests 410 automatically via access management module 110 and based on a first criticality level, or processes user access requests 412 based on external input received by user access rights management system 100 via access management module 110 and based on a second criticality level. In summary, each of 402, 404, 406, 408, 410, and 412 provides a method 400 for accurately and effectively managing user access requests. As will be understood by those skilled in the art, method 400 can be performed by any suitable computer device, computer system, etc.

[0061] Figure 5 A method 500 for managing multiple user access requests is shown according to at least one aspect of this disclosure. It will now be discussed in conjunction with... Figure 1 The user access management system 100 shown is described together. Figure 5 Method 500 is shown. Therefore, now refer to Figure 1 and Figure 5 In at least one aspect, according to method 500, permission risk scorer 104a determines 502 a permission risk score for each of a plurality of user access requests based on permission criticality model 102a and permission metadata, wherein the permission risk score for each user access request relates to the risk associated with the access type of each user access request. User risk scorer 104b determines 504 a user risk score for each user access request based on user criticality model 102b and user metadata, wherein the user risk score for each user access request relates to the risk associated with the identity of each user access request. Dynamic risk scorer 104c determines 506 a dynamic risk score for each user access request based on dynamic criticality model 102c and a combination of permission risk score and user risk score associated with each user access request. In at least one aspect, after each of the determinations described above, method 500 further assigns 508 a criticality level to each user access request via access criticality assessment calculation engine 104 and based on the dynamic risk score for each user access request, wherein the criticality level is one of a first criticality level or a second criticality level greater than the first criticality level.

[0062] In at least one aspect, method 500 further assigns 510 each user access request to a first group of requests or a second group of requests via an automation and priority sorting integrator 108 and based on an automation policy 106b, wherein the first group of requests includes each user access request assigned a first criticality level, and wherein the second group of requests includes each user access request assigned a second criticality level. In at least one aspect, method 500 further automatically processes 512 each user access request in the first group of requests by access management module 110. In at least one aspect, method 500 further processes 514 each user access request in the second group of requests by access management module 110 based on external input received by user access rights management system 100. In summary, each of 502, 504, 506, 508, 510, 512, and 514 provides a method 500 for accurately and efficiently managing multiple user access requests. As will be understood by those skilled in the art, method 500 can be performed by any suitable computer device, computer system, etc.

[0063] The aforementioned prioritization and processing automation for effectively managing user access rights (including user access request processing and user access re-authentication) based on determined criticality levels may include or utilize multiple computer devices, computer systems, etc. In other words, to utilize the systems and methods disclosed herein, at least one of a computer device, computer system, or the like may be implemented. The following section discusses... Figure 6 The computer device 3000 shown in the image and Figure 7 The computer system 4000 shown herein describes each of these computer devices, computer systems, etc. in more detail, providing connectivity between the solutions disclosed herein and how such solutions can be implemented within commercial entities such as payment networks, processing networks, payment processing networks, etc.

[0064] Figure 6 It is a block diagram of a computer device 3000 having a data processing subsystem or component according to at least one aspect of this disclosure. Figure 6 The subsystems shown are interconnected via system bus 3010. Additional subsystems are shown, such as printer 3018, keyboard 3026, fixed disk 3028 (or other memory including computer-readable media), and monitor 3022 coupled to display adapter 3020. Peripheral devices and input / output (I / O) devices coupled to I / O controller 3012 (which may be a processor or any suitable controller) can be connected to the computer system via any number of means known in the art (e.g., serial port 3024). For example, serial port 3024 or external interface 3030 can be used to connect the computer device to a wide area network (e.g., the Internet), a mouse input device, or a scanner. The interconnection via the system bus allows central processing unit 3016 to communicate with each subsystem and allows control over the execution of instructions from system memory 3014 or fixed disk 3028 and the exchange of information between subsystems. System memory 3014 and / or fixed disk 3028 may be embodied in computer-readable media.

[0065] Figure 7This is a schematic diagram of an exemplary computer system 4000 including a host 4002, according to at least one aspect of this disclosure, within which a set of instructions is executable for performing any one or more of the methods discussed herein. In various aspects, the host 4002 operates as a standalone device or can be connected (e.g., network-connected) to other machines. In a network deployment, the host 4002 may operate as a server or client machine in a server-client network environment, or as a peer-to-peer (or distributed) network environment. The host 4002 may be a computer or computing device, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a portable music player (e.g., a portable hard disk audio device, such as a Moving Picture Experts Group Audio Layer 3 (MP3) player), a network appliance, a network router, a switch, or a bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) specifying the actions to be taken by said machine. Furthermore, although only a single machine is shown, the term "machine" should also be understood to include any set of machines that individually or collectively execute a set (or more sets) of instructions to perform any one or more of the methods discussed herein.

[0066] Example computer system 4000 includes a host 4002, on which a host operating system (OS) 4004 runs on one or more processors / processor cores 4006 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both) and various memory nodes 4008. The host OS 4004 may include a super manager 4010 capable of controlling functions and / or communicating with virtual machines (“VMs”) 4012 running on machine-readable media. VM 4012 may also include a virtual CPU or vCPU 4014. Memory nodes 4008 may be linked or pinned to virtual memory nodes or vNodes 4016. When a memory node 4008 is linked or pinned to a corresponding vNode 4016, data can subsequently be directly mapped from the memory node 4008 to its corresponding vNode 4016.

[0067] All the various components shown in host 4002 can be connected to and linked to each other, or communicate with each other via a bus (not shown) or via other coupling or communication channels or mechanisms. Host 4002 may also include a video display, audio devices or other peripheral devices 4018 (e.g., liquid crystal display (LCD), alphanumeric input devices (including, for example, a keyboard), cursor control devices (e.g., a mouse), voice recognition or biometric authentication units, external drives, signal generation devices (e.g., speakers)), persistent storage devices 4020 (also referred to as disk drive units), and network interface devices 4022. Host 4002 may also include a data encryption module (not shown) for encrypting data. The components disposed in host 4002 are those commonly found in computer systems suitable for use with aspects of this disclosure, and are intended to represent a broad category of such computer components known in the art. Thus, computer system 4000 may be a server, a minicomputer, a mainframe computer, or any other computer system. The computer may further include different bus configurations, networking platforms, multiprocessor platforms, etc. It can use various operating systems, including UNIX, LINUX, WINDOWS, QNX ANDROID, IOS, CHROME, TIZEN and other suitable operating systems.

[0068] Disk drive unit 4024 may also be a solid-state drive (SSD), hard disk drive (HDD), or other drive including computer or machine-readable media on which one or more sets of instructions and data structures (e.g., data / instructions 4026) embodying or utilizing any one or more of the methods or functions described herein are stored. Data / instructions 4026 may also reside wholly or at least partially within main memory node 4008 and / or processor 4006 during execution by host 4002. Data / instructions 4026 may be further sent or received via network 4028 via network interface device 4022 utilizing any of several well-known transport protocols (e.g., Hypertext Transfer Protocol (HTTP)).

[0069] Processor 4006 and memory node 4008 may also include machine-readable media. The term "computer-readable media" or "machine-readable media" should be considered as including a single or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) storing one or more sets of instructions. The term "computer-readable media" should also be understood to include any medium capable of storing, encoding, or carrying a set of instructions for execution by host 4002 and causing host 4002 to perform any one or more of the methods of this application, or any medium capable of storing, encoding, or carrying data structures utilized by or associated with such set of instructions. Therefore, the term "computer-readable media" should be understood to include, but is not limited to, solid-state memory, optical and magnetic media, and carrier signals. Such media may also include, but is not limited to, hard disks, floppy disks, flash memory cards, digital video optical discs, random access memory (RAM), read-only memory (ROM), etc. The exemplary aspects described herein may be implemented in an operating environment including software installed on a computer, in hardware, or in a combination of software and hardware.

[0070] Those skilled in the art will recognize that an Internet service can be configured to provide Internet access to one or more computing devices coupled to the Internet service, and that computing devices may include one or more processors, buses, memory devices, display devices, input / output devices, etc. Furthermore, those skilled in the art will understand that an Internet service can be coupled to one or more databases, repositories, servers, etc., which can be used to implement any aspect of the various aspects of this disclosure as described herein.

[0071] Computer program instructions may also be loaded onto a computer, server, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0072] For example, a suitable network may include any one or more of the following, or connected to any one or more of them: local intranet, PAN (Personal Area Network), LAN (Local Area Network), WAN (Wide Area Network), MAN (Metropolitan Area Network), Virtual Private Network (VPN), Storage Area Network (SAN), Frame Relay connection, Advanced Intelligent Network (AIN) connection, Synchronous Fiber Network (SONET) connection, digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, Ethernet connection, ISDN (Integrated Services Digital Network) line, dial-up port (e.g., V.90, V.34 or V.34bis), dual analog modem connection, cable modem, ATM (Asynchronous Transfer Mode) connection, or FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. In addition, communications may include links to any of a variety of wireless networks, including WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular telephone networks, GPS (Global Positioning System), CDPD (Cellular Digital Packet Data), RIM (Room Photograph) full-duplex paging networks, Bluetooth radio, or IEEE 802.11-based radio frequency networks. Network 4030 may also include or interface with any one or more of the following: RS-232 serial connection, IEEE-1394 (FireWire) connection, Fibre Channel connection, IrDA (Infrared) port, SCSI (Small Computer System Interface) connection, USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interfaces or connections, mesh or Digi® network connections.

[0073] Broadly speaking, a cloud-based computing environment is a resource that typically combines large groups of processors (e.g., within a web server) with computing power and / or large groups of computer memory or storage devices with storage capacity. Systems providing cloud-based resources may be available only to their owners, or such systems may be accessible to external users who deploy applications within the computing infrastructure to benefit from large computing or storage resources.

[0074] For example, a cloud consists of a network of web servers comprising multiple computing devices (e.g., host 4002), where each server 4030 (or at least several) provides processor and / or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user's workload requirements for the cloud change in real time, sometimes dramatically. The nature and extent of these changes usually depend on the type of business associated with the user.

[0075] It is worth noting that any hardware platform suitable for performing the processes described herein is suitable for use with the technology. As used herein, the terms "computer-readable storage medium" and "computer-readable storage media" refer to any one or more media that participate in providing instructions to the CPU for execution. Such media can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical discs or magnetic disks, such as fixed disks. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wires, and optical fibers, which include conductors comprising one side of a bus. Transmission media can also take the form of acoustic or optical waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, floppy disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, digital video discs (DVDs), any other optical media, any other physical media with markings or perforations, RAM, PROMs, EPROMs, EEPROMs, FLASH EPROMs, any other memory chips or data exchange adapters, carrier waves, or any other media from which a computer can read.

[0076] Various forms of computer-readable media can participate in loading one or more sequences of one or more instructions to the CPU for execution. A bus carries data to system RAM, from which the CPU fetches and executes instructions. Instructions received from system RAM may optionally be stored on a fixed disk before or after execution by the CPU.

[0077] Computer program code used to perform operations on aspects of this technology can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and regular procedural programming languages ​​such as the "C" programming language, Go, Python, or other programming languages, including assembly language. The program code can execute entirely on the user's computer, partially on the user's computer, or as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can connect to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or can connect to an external computer (e.g., via the Internet using an Internet service provider).

[0078] Examples of devices and methods according to various aspects of this disclosure are provided below in the numbered clauses. An aspect of the device or method may include any one or more of the numbered clauses described below, and any combination thereof.

[0079] Clause 1: A system for managing user access requests, the system comprising: an access criticality module for determining information associated with a user access request; an access criticality assessment calculation engine for determining a risk score associated with the user access request based on the determined information, and assigning a criticality level to the user access request based on the determined risk score; an automation and prioritization integrator for determining automatic or manual processing of the user access request based on the assigned criticality level; and an access management module for automatically or manually processing the user access request based on the determination made by the automation and prioritization integrator.

[0080] Clause 2: The system according to Clause 1, wherein the access criticality module further comprises: a permission criticality model for determining information associated with the access type of the user access request; a user criticality model for determining information associated with the identity of the user access request; and a dynamic criticality model for determining information associated with the combination of the access type and the identity of the user access request.

[0081] Clause 3: The system according to any one of Clauses 1 or 2, wherein the access criticality assessment calculation engine further comprises: a permission risk scorer for determining a risk score associated with the access type of the user access request; a user risk scorer for determining a risk score associated with the identity of the user access request; and a dynamic risk scorer for determining a risk score associated with the combination of the access type and the identity of the user access request.

[0082] Clause 4: The system described in any of Clauses 1 to 3 further includes a repository and automation policy module, which includes a repository and automation policy.

[0083] Clause 5: A system according to any of Clauses 1 to 4, wherein the repository stores the processing history of the user access requests, and wherein the automation policy defines how the determination of the automation and priority sorting integrator is made.

[0084] Clause 6: A system according to any of Clauses 1 to 5, wherein the access management module is configured to generate a priority order of the user access requests based on an assigned criticality level and based on the determination that the user access requests will be manually processed.

[0085] Clause 7: A system pursuant to any of Clauses 1 to 6, wherein the generated priority ordering includes a visual indicator visible to the reviewer of the user access request, and wherein the visual indicator corresponds to the assigned criticality level.

[0086] Clause 8: A computer-implemented method for managing user access requests, the computer-implemented method comprising: determining a permission risk score for a user access request based on a permission criticality model and permission metadata, wherein the permission risk score relates to a risk associated with the access type of the user access request; determining a user risk score for the user access request based on a user criticality model and user metadata, wherein the user risk score relates to a risk associated with the identity of the user access request; determining an overall risk score for the user access request based on a combination of the permission risk score and the user risk score; assigning a criticality level to the user access request based on the overall risk score, wherein the criticality level is one of a first criticality level or a second criticality level greater than the first criticality level; automatically processing the user access request by an access management system based on the first criticality level assigned to the user access request; and processing the user access request by the access management system based on external input received by the access management system based on the second criticality level assigned to the user access request.

[0087] Clause 9: The computer-implemented method according to Clause 8, wherein determining the permission risk score comprises: collecting data from at least one of a configuration management database, an identity and access management database, or a target application, wherein the data includes at least one of permission data or application data; sending the data to a rules engine to generate the permission metadata; and calculating the permission risk score based on the permission metadata.

[0088] Clause 10: A computer-implemented method according to any one of Clauses 8 or 9, wherein determining the user risk score comprises: collecting data from a human resources system, wherein the data includes at least one of the user type, user hierarchy level, user location, or user service years associated with the user access request; and calculating the user risk score based on the data.

[0089] Clause 11: A computer-implemented method according to any one of Clauses 8 to 10, wherein determining the overall risk score further comprises: determining that the user access request is an outlier compared to multiple user access requests associated with multiple users in a peer group; or determining that the user access request violates separation of duties; or determining that the user access request has previously been processed by external input received by the access management system; and calculating the overall risk score based on each determined combination.

[0090] Clause 12: A computer-implemented method according to any one of Clauses 8 to 11 further comprises: determining an updated permission risk score for the user access request; determining an updated user risk score for the user access request; determining an updated overall risk score for the user access request based on a combination of the updated permission risk score and the updated user risk score; assigning an updated criticality level to the user access request based on the updated overall risk score, wherein the updated criticality level is one of a first criticality level or a second criticality level; generating a user access reprocessing request based on the updated criticality level being different from the criticality level; and maintaining user access based on the updated criticality level being the same as the criticality level.

[0091] Clause 13: The computer-implemented method according to any one of Clauses 8 to 12 further comprises: automatically processing the user access reprocessing request by the access management system based on the updated criticality level being the first criticality level and the criticality level being the second criticality level; and processing the user access reprocessing request by the access management system based on external input received by the access management system based on the updated criticality level being the second criticality level and the criticality level being the first criticality level.

[0092] Clause 14: The computer-implemented method according to any one of Clauses 8 to 13 further includes storing the user access request in a processing history repository based on the user access request being processed.

[0093] Clause 15: A computer-implemented method for managing multiple user access requests, the computer-implemented method comprising: determining a permission risk score for each user access request among a plurality of user access requests based on a permission criticality model and permission metadata, wherein the permission risk score for each user access request relates to a risk associated with the access type of each user access request; determining a user risk score for each user access request based on a user criticality model and user metadata, wherein the user risk score for each user access request relates to a risk associated with the identity of each user access request; and determining an overall risk for each user access request based on a combination of the permission risk score and the user risk score associated with each user access request. Risk scoring; assigning a criticality level to each user access request based on the overall risk score, wherein the criticality level is either a first criticality level or a second criticality level greater than the first criticality level; assigning each user access request to a first group of requests or a second group of requests, wherein the first group of requests includes each user access request assigned the first criticality level, and wherein the second group of requests includes each user access request assigned the second criticality level; each user access request in the first group of requests is automatically processed by the access management system; and each user access request in the second group of requests is processed by the access management system based on multiple external inputs received by the access management system.

[0094] Clause 16: The computer-implemented method according to Clause 15, wherein determining the permission risk score for each user access request comprises: collecting data from at least one of a configuration management database, an identity and access management database, or a target application, wherein the data includes at least one of permission data or application data; sending the data to a rules engine, wherein the rules engine generates the permission metadata; and calculating the permission risk score based on the permission metadata.

[0095] Clause 17: A computer-implemented method pursuant to any of Clauses 15 or 16, wherein determining the user risk score for each user access request comprises: collecting data from a human resources system, wherein the data includes at least one of the user type, user hierarchy level, user location, or user years of service associated with each user access request; and calculating the user risk score based on the data.

[0096] Clause 18: A computer-implemented method according to any one of Clauses 15 to 17, wherein determining the overall risk score for each user access request further comprises: determining whether each user access request is an outlier compared to multiple user access requests associated with multiple users in a peer group; determining whether each user access request violates separation of duties; determining whether each user access request has previously been processed by external input received by the access management system; and calculating the overall risk score based on each determined combination.

[0097] Clause 19: The computer-implemented method according to any one of Clauses 15 to 18 further comprises: prioritizing each user access request in the second set of requests based on at least one of the criticality level or processing history associated with each user access request, wherein processing each user access request in the second set of requests by the access management system based on external input received by the access management system is also based on the priority ranking of each user access request.

[0098] Clause 20: The computer-implemented method pursuant to any of Clauses 15 to 19 further includes storing each user access request in a processing history repository based on each user access request being processed.

[0099] The foregoing detailed description has illustrated various forms of the system and / or process using block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, and / or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof, as long as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations. Those skilled in the art will recognize that some aspects of the forms disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuit systems and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein are capable of being distributed as one or more program products in various forms, and will understand that the illustrative form of the subject matter described herein applies regardless of the specific type of signal-bearing medium used to actually perform the distribution.

[0100] Instructions for programming logic to execute various disclosed aspects may be stored in the system's memory, such as dynamic random access memory (DRAM), cache, flash memory, or other memory. Furthermore, instructions may be distributed via a network or by means of other computer-readable media. Therefore, machine-readable media may include any means for storing or transmitting information in a machine-readable (e.g., computer-readable) form, but are not limited to floppy disks, optical disks, compressed optical disks, read-only memory (CD-ROM) and magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage devices for transmitting information via the Internet via electrical, optical, acoustic, or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, non-transient computer-readable media include any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0101] Any software component or function described in this application may be implemented as processor-executable software code using, for example, conventional or object-oriented techniques, in any suitable computer language (e.g., Python, Java, C++, or Perl). The software code may be stored as a series of instructions or commands on a computer-readable medium, such as RAM, ROM, magnetic media (e.g., hard disk or floppy disk), or optical media (e.g., CD-ROM). Any such computer-readable medium may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

[0102] As used in any aspect of this document, the term "logic" may refer to an application, software, firmware, and / or circuit system configured to perform any of the foregoing operations. Software may be embodied as a software package, code, instructions, instruction sets, and / or data recorded on a non-transitory computer-readable storage medium. Firmware may be embodied as hard-coded (e.g., non-volatile) code, instructions, or instruction sets and / or data in a memory device.

[0103] As used in any aspect of this document, the terms “component,” “system,” “module,” etc., can refer to computer-related entities, namely hardware, a combination of hardware and software, software, or software in execution.

[0104] As used in any aspect of this document, "algorithm" refers to a self-consistent sequence of steps that produce a desired result, where "step" refers to the manipulation of physical quantities and / or logical states, which may (though not necessarily) take the form of electrical or magnetic signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. These signals are typically referred to as bits, values, elements, symbols, characters, items, numbers, etc. These and similar terms may be associated with appropriate physical quantities and are merely convenient labels applied to these quantities and / or states.

[0105] The network may include a packet-switched network. Communication devices may be able to communicate with each other using selected packet-switched network communication protocols. An example communication protocol may include an Ethernet communication protocol that may allow communication using Transmission Control Protocol / Internet Protocol (TCP / IP). The Ethernet protocol may conform to or be compatible with the Ethernet standard entitled "IEEE 802.3 Standard" and / or subsequent versions of this standard, published by the Institute of Electrical and Electronics Engineers (IEEE) in December 2008. Alternatively or additionally, communication devices may be able to communicate with each other using the X.25 communication protocol. The X.25 communication protocol may conform to or be compatible with standards issued by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). Alternatively or additionally, communication devices may be able to communicate with each other using the Frame Relay communication protocol. Frame Relay communication protocols may conform to or be compatible with standards issued by the Consultative Committee for International Telegraph and Telephone (CCITT) and / or the American National Standards Institute (ANSI). Alternatively or additionally, transceivers may be able to communicate with each other using Asynchronous Transfer Mode (ATM) communication protocols. ATM communication protocols may conform to or be compatible with the ATM standard entitled "ATM-MPLS Network Interworking 2.0" published by the ATM Forum in August 2001 and / or subsequent versions of this standard. Of course, this document also considers different and / or back-end connectivity network communication protocols.

[0106] Unless explicitly stated in the foregoing disclosure, it should be understood that throughout this disclosure, discussions using terms such as “processing,” “computing,” “operation,” “determining,” “displaying,” etc., refer to the actions and processes of a computer system or similar electronic computing device that manipulate data represented as physical (electronic) quantities in computer system registers and memories and transform them into other data similarly represented as physical quantities in computer system memories or registers or other such information storage, transmission, or display devices.

[0107] One or more components may be referred to herein as “configured to,” “configurable to,” “operable as,” “suitable for,” “capable of,” “compliant to,” etc. Those skilled in the art will recognize that, unless the context otherwise requires, “configured to” can generally encompass active state components and / or inactive state components and / or standby state components.

[0108] Those skilled in the art will recognize that, in general, the terms used herein, and especially in the appended claims (e.g., the body of the appended claims), are typically intended as “open-ended” terms (e.g., the term “including” should be interpreted as “including but not limited to”, the term “having” should be interpreted as “having at least”, the term “includes” should be interpreted as “includes but is not limited to”, etc.). Those skilled in the art will further understand that if a particular number of the introduced claim statements are intended, then such intent will be expressly stated in the claims, and where no such statements are present, such intent does not exist. For example, to aid understanding, the appended claims may contain the introductory phrases “at least one” and “one or more” to introduce the claim statements. However, the use of such phrases should not be construed as limiting any particular claim containing such a claim statement to a claim containing only one such statement by introducing the claim statement with the indefinite article "a(a)" or "an", even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a(a)" or "an" (e.g., "a(a)" and / or "an" should generally be interpreted as meaning "at least one" or "one or more"); the same applies to the use of definite articles for introducing the claim statement.

[0109] Furthermore, even when a specific number is explicitly stated in the introduced claims, those skilled in the art will recognize that such a statement should generally be interpreted as meaning at least the stated number (e.g., the simple statement "two statements" without other modifiers generally means at least two statements, or two or more statements). Moreover, in these cases where the convention of "at least one of A, B, and C" is used, such a construction is generally intended to be in the sense that those skilled in the art would understand the convention to be (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In these cases where the convention of "at least one of A, B, or C" is used, such a construction is generally intended to be in the sense that those skilled in the art would understand the convention to be (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that, generally, unless the context otherwise indicates, separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of including one term, either term, or both terms. For example, the phrase "A or B" will generally be understood to include the possibility of including "A" or "B" or "A and B".

[0110] Regarding the appended claims, those skilled in the art will understand that the operations described herein can generally be performed in any order. Furthermore, although the various operation flowcharts are presented sequentially, it should be understood that the various operations can be performed in any order other than those shown, or can be performed simultaneously. Unless the context otherwise requires, instances of such alternative orderings can include overlapping, interleaving, interruption, reordering, ascending, preparatory, supplementary, simultaneous, inverted, or other variations of ordering. Unless the context otherwise requires, terms such as “in response to,” “related to,” or other past tense adjectives are generally not intended to exclude such variations.

[0111] It is worth noting that any reference to "an aspect," "one aspect," "an example," "an example," etc., means that a particular feature, structure, or characteristic described in connection with said aspect is included in at least one aspect. Therefore, the phrases "in an aspect," "in one aspect," "in an example," and "in an example" appearing throughout the specification do not necessarily all refer to the same aspect. Furthermore, a particular feature, structure, or characteristic may be combined in one or more aspects in any suitable manner.

[0112] As used herein, unless the context clearly indicates otherwise, the singular forms “a”, “an”, and “the” include plural referents.

[0113] Any patent application, patent, non-patent publication, or other disclosure cited in this specification and / or listed in any application data sheet is incorporated herein by reference so that the incorporated material is not inconsistent with it. Therefore, and to the extent necessary, any conflicting material incorporated by reference as expressly set forth herein supersedes any conflicting material. It is claimed that any material or portion thereof incorporated herein by reference that conflicts with existing definitions, statements, or other disclosures set forth herein will be incorporated only to the extent that the incorporated material does not conflict with existing disclosures. This is not an admission that they are prior art.

[0114] In summary, the numerous benefits arising from adopting the concepts described herein have been described. One or more forms of the foregoing description have been presented for illustrative and descriptive purposes. They are not intended to be exhaustive or limited to the precise forms disclosed. Modifications or variations are possible in light of the foregoing teachings. The aforementioned forms have been chosen and described to illustrate principles and practical applications, thereby enabling those skilled in the art to utilize the various forms and make various modifications suitable for the particular purpose contemplated. The overall scope is intended to be defined by the claims filed herein.

Claims

1. A system for managing user access requests, the system comprising: Access critical module, which is used to determine information associated with a user access request; Access criticality assessment calculation engine, which is used to determine a risk score associated with the user access request based on the determined information, and to assign a criticality level to the user access request based on the determined risk score; An automation and priority sorting integrator, which is used to determine whether the user access request is processed automatically or manually based on an assigned criticality level; as well as An access management module is used to automatically or manually process user access requests based on the determination of the automation and priority sorting integrator.

2. The system according to claim 1, wherein the access-critical module further comprises: A permission criticality model, which is used to determine information associated with the access type of the user's access request; The user key model determines the information associated with the identity of the user's access request; as well as A dynamic keyness model is used to determine information associated with the combination of the access type and the identity of the user access request.

3. The system according to claim 1, wherein the access criticality assessment calculation engine further comprises: A permission risk scorer, which is used to determine a risk score associated with the access type of the user's access request; User risk scorer, the user risk scorer being used to determine a risk score associated with the identity of the user's access request; as well as A dynamic risk scorer is used to determine a risk score associated with the combination of the access type and the identity of the user's access request.

4. The system according to claim 1 further includes a repository and automation policy module, wherein the repository and automation policy module includes a repository and an automation policy.

5. The system of claim 4, wherein the repository stores the processing history of the user access requests, and wherein the automation policy defines how the determination of the automation and priority sorting integrator is made.

6. The system of claim 1, wherein the access management module is configured to generate a priority order of the user access requests based on the assigned criticality level and based on the determination that the user access requests will be manually processed.

7. The system of claim 6, wherein the generated priority ranking includes a visual indicator visible to the user access request reviewer, and wherein the visual indicator corresponds to the assigned criticality level.

8. A computer-implemented method for managing user access requests, the computer-implemented method comprising: The permission risk score of a user access request is determined based on the permission criticality model and permission metadata, wherein the permission risk score involves the risk associated with the access type of the user access request; Based on the user key model and user metadata, a user risk score is determined for the user access request, wherein the user risk score relates to the risk associated with the identity of the user access request. The overall risk score of the user access request is determined based on the combination of the permission risk score and the user risk score. The user access request is assigned a criticality level based on the overall risk score, wherein the criticality level is either a first criticality level or a second criticality level that is greater than the first criticality level. The user access request is assigned to the first criticality level and is automatically processed by the access management system. as well as The user access request is assigned based on the second criticality level, and the access management system processes the user access request based on the external input received by the access management system.

9. The computer-implemented method according to claim 8, wherein determining the permission risk score includes: Data is collected from at least one of a configuration management database, an identity and access management database, or a target application, wherein the data includes at least one of permission data or application data. The data is sent to the rules engine to generate the permission metadata; as well as The permission risk score is calculated based on the permission metadata.

10. The computer-implemented method of claim 8, wherein determining the user risk score comprises: Data is collected from the human resources system, wherein the data includes at least one of the user type, user hierarchy level, user location, or user years of service associated with the user access request; as well as The user risk score is calculated based on the data.

11. The computer-implemented method of claim 8, wherein determining the overall risk score further comprises: The user access request was determined to be an outlier compared to multiple user access requests associated with multiple users in the peer group; or The user access request was determined to violate the separation of duties rule. or It is determined that the user access request has previously been processed by external input received by the access management system; as well as The overall risk score is calculated based on each specific combination.

12. The computer-implemented method according to claim 8, further comprising: Determine the updated permission risk score for the user's access request; Determine the updated user risk score for the user access request; The overall risk score for the updated user access request is determined based on a combination of the updated permission risk score and the updated user risk score. An updated criticality level is assigned to the user access request based on the updated overall risk score, wherein the updated criticality level is one of the first criticality level or the second criticality level. Based on the fact that the updated criticality level is different from the criticality level, a user access reprocessing request is generated; as well as User access is maintained based on the updated criticality level being the same as the criticality level.

13. The computer-implemented method according to claim 12, further comprising: Based on the fact that the updated criticality level is the first criticality level and the criticality level is the second criticality level, the access management system automatically processes the user access reprocessing request; as well as Based on the fact that the updated criticality level is the second criticality level and the criticality level is the first criticality level, the access management system processes the user access reprocessing request based on the external input received by the access management system.

14. The computer-implemented method of claim 8 further includes storing the user access request in a processing history repository based on the user access request being processed.

15. A computer-implemented method for managing multiple user access requests, the computer-implemented method comprising: Based on the permission criticality model and permission metadata, a permission risk score is determined for each user access request among multiple user access requests, wherein the permission risk score for each user access request involves the risk associated with the access type of each user access request. Based on the user key model and user metadata, a user risk score is determined for each user access request, wherein the user risk score for each user access request relates to the risk associated with the identity of each user access request. The overall risk score for each user access request is determined based on a combination of the permission risk score and the user risk score associated with each user access request. A criticality level is assigned to each user access request based on the overall risk score, wherein the criticality level is either a first criticality level or a second criticality level that is greater than the first criticality level. Each user access request is assigned to either a first group of requests or a second group of requests, wherein the first group of requests includes each user access request assigned to the first criticality level, and wherein the second group of requests includes each user access request assigned to the second criticality level. Each user access request in the first group of requests is automatically processed by the access management system. as well as Based on multiple external inputs received by the access management system, each user access request in the second group of requests is processed by the access management system.

16. The computer-implemented method of claim 15, wherein determining the permission risk score for each user access request comprises: Data is collected from at least one of a configuration management database, an identity and access management database, or a target application, wherein the data includes at least one of permission data or application data. The data is sent to the rules engine, whereby the rules engine generates the permission metadata. as well as The permission risk score is calculated based on the permission metadata.

17. The computer-implemented method of claim 15, wherein determining the user risk score for each user access request comprises: Data is collected from the human resources system, wherein the data includes at least one of the following: user type, user hierarchy level, user location, or user years of service associated with each user access request; as well as The user risk score is calculated based on the data.

18. The computer-implemented method of claim 15, wherein determining the overall risk score for each user access request further comprises: Determine whether each user access request is an outlier compared to multiple user access requests associated with multiple users in the peer group; Determine whether each user access request violates the separation of duties; Determine whether each user access request has been previously processed by external input received by the access management system; as well as The overall risk score is calculated based on each specific combination.

19. The computer-implemented method according to claim 15, further comprising: Each user access request in the second group of requests is prioritized based on at least one of the criticality level or processing history associated with each user access request. The access management system processes each user access request in the second group of requests based on the external input received by the access management system and also sorts each user access request by priority.

20. The computer-implemented method of claim 15 further includes storing each user access request in a processing history repository based on each user access request being processed.

Images