US20140298423A1 - Facilitating separation-of-duties when provisioning access rights in a computing system - Google Patents

Abstract

Systems and methods for managing risk management rules are provided. A risk management rule may be configured at a rule configuration interface are described. The rule configuration interface may include a list of access rights available for selection. Based on input received, one of the access rights may be identified as a base access right and one of the access rights may be identified as a conflicting access right for the risk management rule. The access rights provisioned at the computing system may be monitored to determine whether a user is provisioned with both the base access right and the conflicting access right. If so, a violation review may be created and presented at a violation review interface at which a decision for the violation review is receivable. An exception to the risk management rule may also be configured at an exception configuration interface.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation-in-part of U.S. patent application Ser. No. 13/801,314 entitled “Common Data Model for Identity Access Management Data” and filed on Mar. 13, 2013, which claims the benefit of U.S. Provisional Patent Application No. 61/740,205 entitled “Common Data Model for Identity Access Management Data” and filed on Dec. 20, 2012, each of which are incorporated by reference herein in their entirety.
• This application is also related to commonly-owned U.S. patent application Ser. No. 13/945/638 entitled “Access Requests at IAM System Implementing IAM Data Model,” of U.S. patent application Ser. No. 13/945,669 entitled “Verifying Separation-of-Duties at IAM System Implementing IAM Data Model,” of U.S. patent application Ser. No. 13/945,656 entitled “Access Reviews at IAM System Implementing IAM Data Model,” and of Ser. No. 13/945,679 entitled “Reconciling Access Rights at IAM System Implementing IAM Data Model” each of which were filed on Jul. 18, 2013 and each of which are continuations-in-part of U.S. patent application Ser. No. 13/801,314 identified above which claims the benefit of U.S. Provisional Patent Application No. 61/740,205 also identified above. Each of these continuations-in-part are also incorporated by reference herein in their entirety.
• This application is further related to commonly-owned U.S. patent application entitled “Facilitating Review of Access Rights in a Computing System” and filed with docket number 007131.01447, to U.S. patent application entitled “Reconciliation of Access Rights in a Computing System” and filed with docket number 007131.01448, to U.S. patent application entitled “Computing Resource Inventory System” and filed with docket number 007131.01449, to U.S. patent application entitled “Granular Risk Expression” and filed with docket number 007131.01451, and to U.S. patent application entitled “Quality Assurance Checks of Access Rights in a Computing System” and filed with docket number 007131.01452, each of which were filed on May 1, 2014 and each of which are also incorporated by reference herein in their entirety.
BACKGROUND
• Identity and access management (IAM) refers to the processes, technologies, and policies for managing digital identities and controlling how those identities can be used to access resources. For large business entities having thousands of employees and complex computer systems, IAM can be a challenge.
• As personnel join, leave, and move throughout the enterprise, access rights to various computing resources may need to be updated, e.g., to add, remove, or modify access rights. Furthermore, periodic access reviews may need to be performed to ensure that access rights for personnel do not exceed the scope of their authority. In other words, access reviews may be used to determine whether employees can access only those resources necessary to perform their job duties. Moreover, it may also be important to ensure personnel are not provided with incompatible access rights—combinations of access rights that would allow personnel to carry out incompatible tasks.
• In order to ensure computing systems remain secure, reviews of access rights may be performed periodically. In some organizations, however, access reviews may involve hundreds of thousands of access rights. Reviewing such a large volume of access rights on a regular basis may strain the available resources of that organization. Therefore, a need exists for improved approaches to identity and access management.
BRIEF SUMMARY
• The following presents a simplified summary of various aspects described herein. This summary is not an extensive overview, and is not intended to identify key or critical elements or to delineate the scope of the claims. The following summary merely presents some concepts in a simplified form as an introductory prelude to the more detailed description provided below.
• A first aspect described herein provides a system for managing risk management rules. The system may include at least one processor, memory storing instructions executable at the processor, and a rule configuration interface. Input may be received at the rule configuration interface to configure a risk management rule. The rule configuration interface may also include a list of access rights that are available for selection. Based on the input received, the system may identify one of the access rights as a base access right for the risk management rule and identify one of the access rights as a conflicting access right for the risk management rule. The system may monitor access rights provisioned at the computing system to determine whether a user is provisioned with both the based access right and the conflicting access right.
• A second aspect described herein provides a computer-implemented method for managing risk management rules. A rule configuration interface may be provided at which a risk management rule is configurable in response to receipt of input at the interface. The rule configuration interface may include a list of access rights available for selection. Based on the input received, one of the access rights may be identified as a base access right for the risk management rule and one of the access rights may be identified as a conflicting access right for the risk management rule. The access rights provisioned at the computing system may be monitored to determine whether a user is provisioned with both the base access right and the conflicting access right.
• A third aspect described herein provides non-transitory computer-readable media having instructions that, when executed by a processor of a computing device, cause the computing device to perform steps for managing risk management rules. The instructions, when executed, may cause the computing device to selectively provide various interfaces at a display device in response to input received at the computing device. The interfaces may include a rule configuration interface, an exception configuration interface, and a violation review interface. A risk management rule may be configurable at the rule configuration interface in response to receipt of input at the interface. The rule configuration interface may also include a list of access rights available for selection. An exception to the risk management rule may be configurable at the exception configuration interface in response to input received at the interface. The exception configuration interface may include a list of attribute values available for selection. A decision for a violation review associated with the risk management rule may be receivable at the violation review interface. The violation review interface may include a list of pending violation reviews. The pending violation review list may identify a violation review, the risk management rule associated with the violation review, and the exception to the risk management rule.
• The instructions, when executed, may also cause the computing device to identify one of the access rights as a base access right for a risk management rule and one of the access rights as a conflicting access right for that risk management rule based on the input received at the rule configuration interface. The instructions, when executed, may additionally cause the computing device to associate one of the attributes values with an exception based on the input received at the exception configuration interface. The instructions, when executed, may further cause the computing device to create a violation review in response to determining that a user has been provisioned with both the base access right and the conflicting access right. The instructions, when executed, may cause the computing device to store at a date store a review decision at the violation review interface.
• These and other aspects of the present disclosure will be apparent in view of the detailed description provided below.
BRIEF DESCRIPTION OF THE DRAWINGS
• Aspects of the disclosure may be implemented in certain parts, steps, and embodiments that will be described in detail in the following description and illustrated in the accompanying drawings in which like reference numerals indicate similar elements. It will be appreciated with the benefit of this disclosure that the steps illustrated in the accompanying figures may be performed in other than the recited order and that one or more of the steps disclosed may be optional. It will also be appreciated with the benefit of this disclosure that one or more components illustrated in the accompanying figures may be positioned in other than the disclosed arrangement and that one or more of the components illustrated may be optional.
• FIG. 1 is a block diagram of an example operating environment in which various aspects of the disclosure may be implemented.
• FIG. 2 is a block diagram of an example enterprise-wide computing system.
• FIG. 3A is a block diagram of an example of an implementation of a resource inventory system.
• FIG. 3B is a flowchart of example method steps for evaluating access reports.
• FIG. 4 is block diagram of an example of an implementation of an identity and access management review system.
• FIGS. 5A-M illustrate respective examples of implementations of various interfaces of an identity and access management review system.
• FIG. 6 is a flowchart of example method steps for identifying unused roles.
• FIG. 7 is a flowchart of example method steps for identifying redundant access requests.
• FIG. 8 is a block diagram illustrating an example workflow between components of an identity and access management system for identifying unused entitlements.
• FIG. 9 is a flowchart of example method steps for identifying unused entitlements.
• FIG. 10 is a block diagram illustrating an example workflow between components of an identity and access management system for identifying unactionable action items.
• FIG. 11 is a flowchart of example method steps for identifying unactionable action items.
• FIG. 12 is a block diagram illustrating an example workflow between components of an identity and access management system for conducting expectation reconciliation.
• FIG. 13 is a flowchart of example method steps for performing expectation reconciliation.
• FIG. 14 is a block diagram illustrating an example workflow between components of an identity and access management system for conducting termination reconciliation.
• FIG. 15 is a flowchart of example method steps for performing expectation reconciliation.
• FIG. 16 is a block diagram illustrating an example workflow between components of an identity and access management system for conducting authorization reconciliation.
• FIG. 17 is a flowchart of example method steps for performing authorization reconciliation.
• FIG. 18 is a block diagram illustrating an example workflow between components of an identity and access management system for conducting deviation reconciliation.
• FIG. 19 is a flowchart of example method steps for performing deviation reconciliation.
• FIG. 20 is a flowchart of example method steps for defining risk violation rules and corresponding exceptions.
• FIG. 21 is a block diagram illustrating an example workflow between components of an identity and access management system for expressing granular risk and performing access reviews based on granular risk.
• FIG. 22 is a flowchart of example method steps for expressing granular risk.
• FIG. 23 is a block diagram illustrating an example workflow between components of an identity and access management system for leveraging completed access reviews during subsequent review events.
• FIG. 24 is a flowchart of example method steps for leveraging completed access reviews during subsequent review events.
DETAILED DESCRIPTION
• Aspects of the disclosure related to identity and access management (IAM). Identity and access management may alternatively be referred to as identify management (IdM) as well as access and identity management (AIM). The aspect of the disclosure discussed in further detail below provide improvements to the management of IAM information, the presentation of IAM information, and the review of IAM information. Aspects of the disclosure below may be described in the context of business enterprises and the computer systems of such business enterprises. It will be appreciated, however, that aspects of the present disclosure may selectively implemented at the computer systems of any type of enterprise.
• In general the IAM system described below improves the preparation, management, and review of IAM information by providing a centralized location at which administrators can browse IAM information, perform access reviews, manage risk, and perform other IAM-related activities that will be appreciated with the benefit of this disclosure. This centralized location may, for convenience, be referred to as an IAM dashboard. The aspects of the IAM system described in further detail below include: an inventory system that comprehensively identifies the computing resources deployed in a computing system; an interactive IAM management tool for viewing access rights and pending reviews of such access rights; and various approaches to quality assurance of IAM information, reconciliation of access rights, risk management, and review of access rights. The IAM system described thus provides enterprises the ability to perform thorough and comprehensive reviews of access rights while minimizing redundancy in performing access reviews and fulfilling access requests. The IAM system described also enables an enterprise to quickly and efficiently address any issues associated with access rights provisioned at a computing system or resources deployed in a computing system. These and additional advantages will be appreciated with the benefit of the additional disclosures described in further detail below.
• For convenience individuals that utilize the IAM system described below may be referred to as administrators. An administrator may correspond to one of various types of individuals involved in managing or maintaining computing systems of an enterprise. Such individuals may include, for example: individuals that supervise users and computing resources of a computing system; individuals that engineer roles, user groups, and tasks for a computing system; individuals that perform reviews of access rights at the computing system; individuals that manage risk associated with the computing system; and individuals that provision access rights at the computing system for users and resources. Accordingly administrators may be referred to, in various contexts, as managers, role engineers, reviewers, risk managers, and so forth.
• Additionally the IAM system may provide administrators various reports related to access rights, access requests, and access reviews. The IAM system may provide such reports in various forms. In one example, a report may be a document provided to an administrator as an email attachment. In another example, a report may be the email itself. In a further example, the IAM system may provide the report at the IAM dashboard as part of an interface presented to an administrator. The IAM system may also be selectively configured to employ additional and alternative approaches to providing the various reports described below.
• It is also to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. Rather, the phrases and terms used herein are to be given their broadest interpretation and meaning. The use of “including” and “comprising” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. The use of the terms “mounted,” “connected,” “coupled,” “positioned,” “engaged” and similar terms, is meant to include both direct and indirect mounting, connecting, coupling, positioning and engaging. In addition, “set” as used in this description refers to a collection that may include one element or more than one element. Moreover, aspects of the disclosure may be implemented in non-transitory computer-readable media having instructions stored thereon that, when executed by a processor, cause the processor to perform various steps described in further detail below. As used in this description, non-transitory computer-readable media refers to all computer-readable media with the sole exception being a transitory propagating signal.
• FIG. 1 illustrates a block diagram of at least a portion of an IAM system101 (e.g., a computer server) incommunication system100 that may be used according to an illustrative embodiment of the disclosure. Thesystem101 may have aprocessor103 for controlling overall operation of the system and its associated components, includingRAM105,ROM107, input/output (I/O)module109, andmemory115.
• I/O module109 may include a microphone, keypad, touch screen, and/or stylus through which a user of theIAM system101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored withinmemory115 and/or storage to provide instructions toprocessor103 for enabling thesystem101 to perform various functions. For example,memory115 may store software used by thesystem101, such as anoperating system117,application programs119, and an associateddatabase121.Processor103 and its associated components may allow thesystem101 to run a series of computer-readable instructions to process and respond to access requests and to facilitate access reviews.
• Thesystem101 may operate in a networked environment supporting connections to one or more remote computers, such asterminals141 and151. Theterminals141 and151 may be personal computers or servers that include many or all of the elements described above relative to thesystem101. Alternatively, terminal141 and/or151 may be a data store that is affected by the backup and retention policies stored on thesystem101. The network connections depicted inFIG. 1 include a local area network (LAN)125 and a wide area network (WAN)129, but may also include other networks. When used in a LAN networking environment, thesystem101 is connected to theLAN125 through a network interface oradapter123. When used in a WAN networking environment, thesystem101 may include amodem127 or other means for establishing communications over theWAN129, such as theInternet131. It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used. The existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like is presumed.
• Additionally, one ormore application programs119 used by theIAM system101 according to an illustrative embodiment of the disclosure may include computer executable instructions for invoking functionality related to processing and responding to access requests and to facilitating access reviews.
• TheIAM system101 and/orterminals141 or151 may also be mobile terminals, such as smart phones, personal digital assistants (PDAs), etc. including various other components, such as a battery, speaker, and antennas (not shown).
• The disclosure is operational with numerous other general purpose or special purpose computer system environments or configurations. Examples of well-known computer systems, environments, and/or configurations that may be suitable for use with the disclosure include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices, and the like.
• The disclosure may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. The disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked, for example, through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
• FIG. 2 is an illustration of an example enterprise-wide computing system200. An enterprise-wide computing system200 may maintain multiple distributedcomputing systems202. Eachcomputing system202 may be separate and distinct. Thecomputing systems202 may be physically separated from each other, for example, by location (e.g., North America, Europe, Asia). Additionally or alternatively, thecomputing systems202 may be logically separated from each other, for example, by institution or department (e.g., banking, information technology).
• Thecomputing systems202 may be connected by one ormore communication links206 tocomputer networks204. Thecomputer networks204 may be linked to anIAM system220 via communication links208. Thecomputer networks204 may be any suitable computer networks including the Internet, an intranet, a wide-area network (WAN), a local-area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode network, a virtual private network (VPN), or any combination of any of the same.Communication links206 and208 may be any communication links suitable for communicating betweencomputing systems202 andnetworks204, such as network links, dial-up links, wireless links, hard-wire links, etc. It will be appreciated that the network communications shown are illustrative and other means of establishing communication links between the computing systems and networks may be used. The existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP, HTTPS, and the like is presumed.
• Eachcomputing system202 may include collections ofservers210a,databases210b, and software applications orsoftware programs210c(collectively resources210), where theservers210amay hostdatabases210bandapplications210c. The collections ofservers210a,databases210b, andapplications210cwill be referred to as resources. TheIAM system220 may be employed to manage access rights to physical and logical resources within the enterprise-wide computing system200. The responsibilities of the IAM system in managing access may include processing access requests, provisioning requested access rights, reviewing provisioned access rights, revoking access rights, and other IAM activities.
• Users216 are selectively provisioned with access rights to theseresources210.Resources210 may also be provisioned with access rights in order to access other resources of acomputing system202. Access refers to the ability of a user to perform operations on a resource, such as, for example, create, read, update, delete, and execute. Access to a particular resource is referred to as a permission. A set of permissions may be associated with a task, and a set of tasks may be associated with a role or user group. Individual permissions may also be associated with a role or user group. A permission provisioned to a particular user or resource may be referred to as an entitlement.
• Permissions, entitlements, roles, user groups, and tasks may be collectively referred to as access rights. Accordingly provisioning access rights for auser216 may include associating a resource permission with that user such that the user is entitled to access and capable of accessing theresource210 associated with the permission. Access rights may be similarly provisioned for aresource210 such that the resource is entitled to access and capable of accessing other resources of acomputing system202. When auser216 orresource210 receives an entitlement, corresponding login credentials may be created for the user or resource. Provisioning access rights may also include assigning a particular role, user group, or task to auser216 orresource210. Revoking access rights may include removing associations with permissions, roles, user groups, and tasks. Additional and alternative examples of provisioning and revoking access rights will be appreciated by those skilled in the art.
• Generally, theIAM system220 may include anIAM data store222, anaccess request system224, anIAM security system226, anIAM review system228, and aresource inventory system230. TheIAM data store222 may contain information regarding users, user groups, roles, tasks, resources, access rights, permissions, and entitlements. Theaccess request system224 may be used to request changes to access rights for a particular user, user group, or role. In some examples, theaccess request system224 may be a ticketing system, which provides functionality to submit access requests, generates access request tickets, routes access request tickets to administrators, and changes access rights based on the information in the access request ticket (i.e., fulfillment). The fulfillment process may include either provisioning access rights or revoking access to a particular resource for a particular user, user group, or role, depending on the content of the access request. An access request may include information such as a description of the access rights changes requested, date of request submission, user requesting changes, and a status (e.g., open, closed). When an access request is submitted, the status of the access request may be described as “open.” Once the fulfillment process is complete, the status of the access request may be changed, and the status of the access request may be described as “closed.” Additionally, the access request will be updated with the date the access rights were changed. Access requests may be submitted to grant or provision access rights to a user and may also be submitted to remove or revoke access rights from a user. Access requests requesting access rights be granted or provisioned to a user may be referred to as access grant requests. Access requests requesting access rights be removed or revoked from a user may be referred to as access revocation requests. Access requests requesting a change to a set of access rights associated with a user (e.g., by provisioning a new access right or by revoking an existing access right) may be referred to as an access change request. Furthermore, an access request that has not yet been fulfilled may be referred to as a pending access request, and an access request that has been fulfilled may be referred to as a fulfilled access request.
• TheIAM security system226 may receive access reports from the resources in the enterprise-wide computing system200. Access reports from a particular resource identify all of the access rights currently associated with all users, user groups, and roles for that particular resource. The access rights identified in an access report may thus be referred to as reported access rights. The access reports received by theIAM security system226 may be used to reconcile access rights.
• TheIAM review system228 is an interactive tool which may reconcile access rights, perform reviews, view resource information, define risk management rules and exceptions, and define granular risk. TheIAM review system228 will be discussed in further detail below.
• Theresource inventory system230 may be used to manage all physical and logical resources in the enterprise-wide computing system200. Theresource inventory system230 provides a list of all resources deployed at all of thecomputing systems202 in the enterprise-wide computing system200. Additionally or alternatively, theresource inventory system230 provides a list of all resources deployed at all of thecomputer systems202 in the enterprise-wide computer system200 which require a login. Theresource inventory system230 may also be used to reconcile access rights based on the access reports received by theIAM security system226. Theresource inventory system230 will be discussed in further detail below.
1. Resource Inventory
• InFIG. 3A, a block diagram of an example of an implementation of aresource inventory system230 is shown. As noted above, a resource refers to a computing resource of a computing system. Theresource inventory system230, in this example, includes aresource management module300, a accessreport evaluation module302, and adata store304 that stores resource inventory information. Resource inventory information stored at thedata store304 may include, e.g.,resource information306,resource association information308, andresource access information310.
• Resource information306 may include a list of the computing resources and metadata for aresource210, for example, a unique identifier, type (e.g., server, database, or application), geographic location, network address, business division, resource group, and status (e.g., active or inactive). Theresource information306 that lists theresources210 of the enterprise-wide computing system200 may thus correspond to the resource inventory for the enterprise-wide computer system. It will be appreciated that even if aresource210 is not actively connected to or operating at a computing system202 (i.e., is inactive), theresource inventory system230 may nonetheless store information for that resource in order to maintain a comprehensive inventory of all resources in the enterprise-wide computing system200. Accordingly theresource information306 may include a list of computing resources that comprehensively identify thecomputing resources210 of thecomputing system200. A comprehensive computing resource list that identifies each computing resource of a computing system has advantages over a partial list of the computing resources of the computing system. A comprehensive list of thecomputing resources210 at thecomputing system200 advantageously enables resource managers to obtain a full understanding of the status of the computing system and its individual components. Stated differently, the comprehensive list ofcomputing resources210 advantageously ensures that the computing system does not include any computing resource the resource managers are not aware of. In this way, the resource managers of an enterprise may advantageously review the access rights associated with each computing resource of the computing system to ensure that each computing resource is secured according to the security and IAM policies of the enterprise. It will be appreciated, however, that depending on the goals and policies of an enterprise, the list of computing resources may not identify each computing resource of a computing system despite the advantages of a comprehensive list. For example, a computing system may include computing resources identified as “high priority” and computing resources identified as “low priority.” In this example, theresource information306 may include a computing resource list that identifies the “high priority” computing resources but not the “low priority” computing resources. As seen from this example, a computing resource list that is not comprehensive is nonetheless useful to obtain a full understanding of the “high priority” computing resources of the computing system. Additional and alternative metadata for aresource210 will be appreciated by those skilled in the art.Resource association information308 may, for example, identify associations betweenresources210, e.g., betweenapplications210canddatabases210bfor data storage and retrieval, between applications that interact with each other, and between resources that are located at thesame computing system202. Additional and alternative types of associations betweenresources210 will be appreciated by those skilled in the art.
• Resource access information310 may, for example, identifyusers216 andresources210 that are provisioned with access rights to resources of acomputing system202. Accordinglyresource access information310 may include a list of all current and previous entitlements respectively associated withusers216 andresources210. In this way theresource inventory system230 may provide an access rights history for a particular user or a particular resource. The access rights history may indicate the date when an access right was provisioned and, if removed, the date the access right was revoked. The access rights identified in the access rights history may be referred to as historical access rights and include currently provisioned access rights for a user and previously provisioned access rights for the user.Resource access information310 may also include a list of all permissions respectively associated with eachresource210 of the enterprise-wide computing system200. Additional and alternative types of resource access information will be appreciated by those skilled in the art. Thedata store304 may store theresource information306,resource association information308, andresource access information310 as a set of interrelated database records and in accordance with an IAM data model. In some alternative example implementations, theIAM data store222 may store a portion of the resource inventory information in conjunction with thedata store304 of theresource inventory system230.
• Theresource management module300 may be configured to, in operation, facilitate the maintenance and management of the resource inventory for the enterprise. A resource manager may utilize theresource management module300 to update theresources210 listed in resource inventory. A resource manager may, for example, add anew resource210 to the resource inventory when a new resource is added to acomputing system202, remove an existing resource from the resource inventory when the resource is removed from a computing system, or modify the information for an existing resource, e.g., when the status, location, or network address of the existing resource changes at the enterprise-wide computing system200.
• Resources210 may report to anIAM security system226 on a regular basis. In particular,resources210 may provide periodic (e.g., daily) access reports312. Eachresource210 may provide arespective access report312. Anaccess report312 may indicate the entitlements used to access theresource210 as well as the user, user group, or role associated with the entitlement. It will be appreciated that if an entitlement is not used to access aresource210, then theresource210 may not include that entitlement in theaccess report312.Resources210 may provide respective access reports312 to theIAM security system226 for storage. TheIAM security system226 may include adata store314 that stores access reportinformation316 corresponding to the information in the access reports312. Thedata store314 of theIAM security system226 may store theaccess report information316 as, e.g., a set of related database records respectively corresponding to the access reports received and the entitlements identified in those access reports. Theaccess report information316 may include the date anaccess report312 was received, theresource210 that provided the access report, and a respective set of entitlements and associated users, user groups, roles, resources, and so forth.
• The accessreport evaluation module302 may be in signal communication with theIAM security system226 and thus have access to theaccess report information316. The accessreport evaluation module302 may be configured to, in operation, periodically perform various resource evaluation tasks and generate various types of resource evaluation reports. Resource evaluation tasks may include determining whether a resource has provided an access report as expected and determining whether the access rights reported as having been used to access the resource conform to expectations. Theresource evaluation module302 may, for example, compare theaccess report information316 to theresource information306 and determine whether eachresource210 listed in the resource inventory provided anaccess report312 for the current reporting period. If aresource210 listed in the resource inventory has not provided anaccess report312 for the current reporting period, then the accessreport evaluation module302 may identify the resource as a non-reporting resource in areporting resources report318. If theresource210 has provided anaccess report312 for the current reporting period, then the accessreport evaluation module302 may identify the resource as a reporting resource in thereporting resources report318. The accessreport evaluation module302 may also be configured to, in operation, compare the reported entitlements for a current reporting period to the reported entitlements from a previous reporting period and determine whether the total number of reported entitlements deviate significantly between the reporting periods. If, for example, the total number of reported entitlements has changed in the current reporting period by more than a predetermined difference threshold (e.g., 10%), then the accessreport evaluation module302 may identify theresource210 in anentitlement deviation report320. The difference threshold may be an absolute difference between the total number of access rights reported or may be a percentage of access rights reported for a current reporting period relative to a previous reporting period. As an example, if aresource210 has previously reported an average of around 50,000 entitlements but only reports around 5,000 entitlements for the current reporting period, then the accessreport evaluation module302 may identify that resource in theentitlement deviation report320 due to the significant drop in the number of entitlements reported. The reporting resources report318 and theentitlement deviation report320 may be provided to an administrator who may then advantageously investigate why aresource210 is not providingaccess reports312 or investigate the deviation in the entitlements reported. The reporting resources report318 and theentitlement deviation report320 may be generally referred to as resource evaluation reports. In addition, the accessreport evaluation module302 may selectresources210 for evaluation at the end of the current reporting period.
• Referring now toFIG. 3B, aflowchart350 of example method steps for evaluating access reports312 is shown. AnIAM security system226 may periodically receiveaccess reports312 from respective resources210 (block352), and the IAM security system may storeaccess report information316 corresponding to the information in the access reports received (block354). The accessreport evaluation module302 may then iterate over the resource inventory list by selecting a resource210 (block356) and obtainaccess report information316 associated with the selected resource for the current reporting period (block358). If the selected resource did not provide an access report for the current reporting period (block360:N), then the accessreport evaluation module302 may list the selected resource in a reporting resources report318 (block362) identifying the selected resource as a non-reporting resource in the report.
• If, however, the selected resource did provide an access report for the current reporting period (block360:Y), then the accessreport evaluation module302 may identify the selected resource as a reporting resource in thereporting resources report318. The accessreport evaluation module302 may also obtainaccess report information316 associated with the selected resource for one or more previous reporting periods (block364). Theaccess report information316 for the previous reporting periods may include, for example, a total number of entitlements reported in the immediately preceding period or, additionally or alternatively, an average number of entitlements reported during multiple previous reporting periods. The accessreport evaluation module302 may then compare the current number of reported entitlements to the previous number of reported entitlements (block366). If there has been a significant deviation in the number of entitlements reported during the current reporting period relative to the one or more previous reporting periods (block368:Y), then the access report evaluation module may list the selected resource in an entitlement deviation report320 (block370) and identify the current access report from that resource as an atypical access report in thedeviation report320. A significant deviation may be, for example, a decrease in the total number of reported entitlements above a predetermined threshold (e.g., 10%). The accessreport evaluation module302 may be selectively configured to employ additional or alternative criteria when determining whether a significant deviation has occurred with respect to the number of reported entitlements. Stated more generally, the accessreport evaluation module302 may assess a difference between the total number of access rights reported in the access reports, and determine whether that difference exceeds a predetermined difference threshold.
• If there has not been a significant deviation in the number of reported entitlements during the current reporting period (block368:N), then the selected resource may not be included in theentitlement deviation report320 as the entitlements reported for the current reporting period correspond to what was expected for the current reporting period. In some example implementations, however, the accessreport evaluation module302 may include the resource in theentitlement deviation report320 and identify the current access report from that resource as a typical access report in the entitlement deviation report.
• If resources remain to be evaluated (block372:Y), the accessreport evaluation module302 may select the next resource for evaluation (block374) and repeat the steps described above to determine whether to list the next selected resource in the reporting resources report318 or theentitlement deviation report320. Once each resource has been evaluated (block372:N), the accessreport evaluation module302 may provide the non-reporting resource report to an administrator (block376) and provide the entitlement deviation report to an administrator (block378). The accessreport evaluation module302 may evaluate the access reports312 on a regular basis (e.g., daily). In this way, administrators may quickly identify and address technical issues associated with theresources210 of the enterprise-wide computing system200.
2. Interactive Identity Access Management Tool
• InFIG. 4, a block diagram of an example of an implementation of an identity and access management (IAM)review system228 is shown. TheIAM review system228 may be in signal communication with theIAM data store222, theaccess request system224, and theresource inventory system230. TheIAM review system228 may also be in signal communication with theresources210 of the enterprise-wide computing system200 via one ormore networks204.
• TheIAM data store222 may implement anIAM data model400 and store IAM data in accordance with the IAM data model. IAM date may include, for example,resource information402,permission information404,user information406,role information408,task information410, andentitlement information412. Each of these types of IAM data will be appreciated with the benefit of this disclosure. TheIAM data store222 may also store other types of IAM data not shown inFIG. 4.
• TheIAM review system228 may be implemented as a collection of modules that are configured to, in operation, perform various functions associated with identity access management. The modules may reside at a single location (e.g., one application server) or be distributed across multiple locations (e.g., multiple interconnected application servers). Other approaches to implementing theIAM review system228 will be appreciated by those skilled in the art and may be selectively employed. TheIAM review system228 may also includedata store414 that storesaccess review information416 and riskmanagement rule information418.
• Access review information416 may be related to pending and completed access reviews. Accordingly accessreview information416 may include, e.g., an access review type, the assigned reviewer, the triggering event, the access review decision, an explanation for the decision, the access review status, the due date, the number of days overdue, and the date the access review was completed. TheIAM review system228 may facilitate access reviews of several types of IAMinformation including users216,applications210c,other resources210aand210b, risk violations, and roles. During an access review, a review may approve or reject an entitlement associated with auser216 or aresource210. A reviewer may also route an access review to another individual for clarification of the information under review or for reassignment of the access review to that individual. Accordingly accessreview information416 may also include the individual the access review was routed to and the date the access review was routed. If the reviewer rejects an entitlement under review, the reviewer may submit a request to revoke the access rights associated with the entitlement. Different events may trigger an access review periodic internal reviews, periodic regulatory reviews, and ad hoc risk violation reviews. Access review statuses may include, e.g., “pending,” “complete,” and “routed.” Additional types ofaccess review information416 will be appreciated with the benefit of this disclosure. Access reviews will be discussed in further detail below.
• Riskmanagement rule information418 identifies incompatible roles, tasks, and resource permissions within the enterprise-wide computing system200. As described in further detail below, a risk manager may define risk management rules that indicate which roles, tasks, and resource permissions are incompatible with one another. If a user is provisioned with access rights that violate a defined risk management rule, then a reviewer may be notified and prompted to approve or reject the provisioned access rights. Riskmanagement rule information418 may also include information related to exceptions to risk management rules. Thedata store414 of theIAM review system228 may store the riskmanagement rule information418 as a set of related database records having relationships to thepermission information404,permission information404, andtask information410 in theIAM data store222. Risk management, risk management rules, and exceptions to risk management rules will be discussed in further detail below.
• The modules of theIAM review system228, in this example, include: aninterface module420, a quality assurance (QA)module422, anaccess review module424, arisk management module426, and areconciliation module428. Alternative implementations of theIAM review system228 may include additional or alternative modules that facilitate identity and access management. The modules420-428, in this example, may work together to carry out the functional aspects of theIAM review system228.
• Theinterface module420 may accept input and provide output from an administrator when operating theIAM review system228. An administrator may access and operate theIAM review system228 from aworkstation430, e.g., a desktop computer, a laptop computer, a tablet computer, a palmtop computer, a cellular telephone (“smartphone”), and other types of computing devices. Theinterface module420 may be implemented as a desktop application, a mobile application, or a web application. Theinterface module420 may display various interfaces that include IAM information, access review information, and other types of information that will be appreciated with the benefit of this disclosure. Theinterface module420 may accept input from an administrator to, e.g., view different types of IAM information, receive an access review decision, submit an access request, define risk management rules and exceptions, navigate through the interfaces, and perform other IAM activities that will be appreciated with the benefit of this disclosure. Example interfaces described below with reference toFIGS. 5A-M.
• TheQA module422 may be configured to, in operation, perform various quality assurance checks within theIAM system220. A quality assurance check may be implemented as a quality assurance task carried out by theQA module422. Example quality assurance checks may include evaluation of submitted access requests, roles, entitlements, and data integrity. In particular, theQA module422 may be configured to, in operation, automatically identify when a defined role matches a set of requested access rights, automatically determine whether a set of requested access rights have already been provisioned for a user, automatically identify unused entitlements, and identify circumstances of data incompatibility between components of the enterprise-wide computing system. These example QA checks and their correspond QA tasks will be discussed in further detail below.
• Thereconciliation module428 may be configured to, in operation, perform various reconciliations within theIAM system220. Reconciliations may involve evaluation of permissions, entitlements, access reportinformation316, and access requests. Thereconciliation module428 may be configured to perform different types of reconciliations including, for example: expectation reconciliation in which the reconciliation module compares current entitlements to expected entitlements; termination reconciliation in which the reconciliation module ensures any entitlements for a terminateduser216 are purged from theIAM system220; authorization reconciliation in which the reconciliation module ensures that all current entitlements can be traced to an approved access request; and deviation reconciliation in which the reconciliation module flags access rights that are assigned to users having attributes that appear to deviate from the attributes of the other users assigned such access rights. With respect to termination reconciliation, auser216 may be terminated, for example, when that user ends a term of employment with the enterprise or goes on a leave-of-absence. With respect to deviation reconciliation, auser216 having attributes that deviate from other users may be referred to as an “outlier.”
• Therisk management module426 may be configured to, in operation, facilitate construction of risk management rules and corresponding exceptions. Therisk management module426 may also be configured to, in operation, monitor newly provisioned access rights and compare newly provisioned access rights to the risk management rules. Therisk management module426 may also determine whether any exceptions associated with the risk management rule apply. Therisk management module426 may create risk violation reviews for violated risk management rules and assign the violations to a reviewer. As described in further detail below, a violation severity level may be associated with a risk management rule
• Theaccess review module424 may be configured to, in operation, facilitate completion of access reviews at theIAM review system228. As noted above, access reviews may include reviews ofusers216,applications210c,other resources210aand210b, risk violations, and roles. Theaccess review module424 may retrieveaccess review information416 and provide a list of pending access reviews to be completed by a reviewer. Theaccess review module424 may also be configured to identify previously completed access reviews during subsequent reviews so as to advantageously avoid repeating such access reviews. Theaccess review module424 may also be configured to receive and process the access review decisions of the reviewer which may include creating access requests to revoke access rights or routing access reviews to other individuals for clarification or reassignment. Access reviews will be discussed in further detail below.
• Referring now toFIGS. 5A-M, example interfaces that theinterface module420 may present to the user while interacting with theIAM review system228 are shown. The various interfaces shown inFIGS. 5A-M may collectively correspond to the IAM dashboard mentioned above as the centralized location for managing IAM information. Managers employed at an enterprise may be responsible for conducting reviews of users, applications, and other resources under their supervision. Accordingly, managers are one type of user that may utilize theIAM review system228 to conduct reviews, perform reconciliation, engineer and review roles, and carry out other tasks related to identity and access management. It will be appreciated, however, that other types of users may utilize theIAM review system228 for IAM purposes (e.g., managers may delegate or reassign tasks or reviews to non-manager users). It will also be appreciated that the example interfaces shown in these figures are described below by way of example only. Other implementations of these interfaces may display additional and alternative types of information in additional or alternative arrangements. Such additional and alternative implementations will be appreciated with the benefit of this disclosure.
• InFIG. 5A, an example of an implementation of a first type ofinterface500 of anIAM review system228 is shown. Theexample interface500 inFIG. 5A is amain dashboard interface500, in other words, the main interface from which a manager may navigate through theIAM review system228. The individual that navigates through and interacts with theIAM review system228 may also be referred to as the operator. Themain dashboard interface500 may include one or more portals. In at least one arrangement, themain dashboard interface500 may include a pendingreview portal502, where each listing within the pendingreview portal522 represents a type of review to be completed. Each listing within the pendingreview portal522 corresponds to one or more pending reviews of that type. The review types may includeuser reviews504, application reviews506, resource reviews508, violation reviews510, role reviews511, and other resource-related reviews. For each pending review type, the pendingreview portal502 may display a date the reviews were assigned, a due date for the reviews, and a current status of the reviews (e.g., x of y completed, not started, completed, not submitted). The pendingreview portal502 may also include additional review information, e.g., days until due, days overdue, routing information identifying an individual that the manager routed reviews to for clarification or delegation, and other types of review-related information. To navigate to a review interface, the manager may select one of the pending review types from the pendingreview portal502. For example, selecting “User Reviews”504 inFIG. 5A would bring the manager to the user review interface520 (FIG. 5B). Similarly, selecting “Application Reviews”506 would bring the manager to an application review interface560 (FIG. 5D), selecting “Resource Reviews”508 would bring the manager to a resource review interface590 (FIG. 5F), selecting “Violation Reviews”510 would bring the manager to a violation review interface630 (FIG. 5H), and selecting “Role Reviews”511 would bring the manager to a pending role review interface720 (FIG. 5L).
• Additionally or alternatively, thedashboard interface500 may includeportals listing users216 that the manager supervises (i.e., e.g., all individuals that report to the current manager), as well as applications, other resources, and roles managed by the current manager. For each user, theuser portal512 may display a unique identifier for the user, a last name, a first name, a user type, a location, a business role, a hire date, a termination date, and a review type. To navigate to a user detail interface540 (FIG. 5C), the manager may select one of the users listed in theuser portal512.
• Similarly, the applications portal514, other resources portal516, and role portal517 may respectively display metadata describing applications, other resources, and roles managed by the manager. To navigate to an application detail interface570 (FIG. 5E), the manager may select one of the applications listed in theapplications portal514. To navigate to a resource detail interface610 (FIG. 5G), the manager may select one of the resources listed in theresource portal516. To navigate to a role review interface740 (FIG. 5M), the manager may select one of the roles listed in therole portal517.
• It is appreciated that the information displayed on thedashboard interface500 and on the other interfaces described below (FIGS. 5B-M) is specific to the manager logged into theIAM review system228, as indicated by theinterface header518. For example, the reviews, users, applications, and other resources presented on the various portals of the dashboard are assigned to or associated with the manager.
• InFIG. 5B, an example of an implementation of a second type ofinterface520 of anIAM review system228 is shown. Theexample interface520 inFIG. 5B is a useraccess review interface520. The useraccess review interface520 may include a pending useraccess review portal522, which lists pending user reviews assigned to the manager. Eachuser review524 listed within the useraccess review portal522 represents one user access review assigned to the manager. For each pendinguser access review524, the pending useraccess review portal522 may display a unique user identifier, a last name, a first name, a review type, a resource identifier, an entitlement description a date entitlement was granted, and a name of individual that approved the entitlement. If the user review resulted from a risk violation, then the useraccess review portal522 may also identify the violated rule. The pending useraccess review portal522 may also include additional review information describing the relationship between the user, the resource, and the entitlement (e.g., last date entitlement was used). To navigate to a user detail interface540 (FIG. 5C), the manager may select one of the user reviews524 (e.g., by selecting the user identification, last name, or first name) listed in the pending useraccess review portal522. Additionally or alternatively, to navigate to the risk management rule configuration interface650 (FIG. 5I), the manager may select the risk management rule that was violated for one of the user reviews524 in the pending useraccess review portal522.
• In at least one arrangement, the pending useraccess review portal522 may include a selectableuser interface element526 to request clarification of the entitlement description for a pendinguser access review524. The manager may select theelement526 for a particular pendinguser access review524 in order to obtain more information about the entitlement and thus make a more informed decision on whether to approve the entitlement associated with the pendinguser access review524.
• Further, the pending useraccess review portal522 may include one or more selectable user interface elements for each pendinguser access review524 to allow the manager to process the review. In at least one arrangement, the selectable user interface elements may include anelement528 to approve the entitlement, anelement530 to reject the entitlement, and anelement532 to route the user review to another individual. When the manager selects theelement528 to approve auser access review524, theIAM review system228 may update the user access review record with the date approved and the name of individual that approved the review. If, however, the manager selects theelement530 to reject theuser access review524, theIAM review system228 may automatically create an access request that requests the revocation of the entitlement. The manager may also select theelement532 to route the auser review524 to another individual. Selectingelement532 may cause theIAM review system228 to prompt the manager to select another individual (e.g., another user of the IAM review system228) for delegation or reassignment of the review.
• InFIG. 5C, an example of an implementation of a third type ofinterface540 of anIAM review system228 is shown. Theexample interface540 inFIG. 5C is auser detail interface540. Theuser detail interface540 presents the collection of access rights associated with the selected user, as indicated by theaccess collection header546. In at least one arrangement, theuser detail interface540 may include a currentaccess rights portal542, and a historicaccess rights portal544. The currentaccess rights portal542 provides a listing of the access rights currently associated with the selected user. The historicaccess rights portal544 provides a listing of the access rights previously associated with the selected user.
• In at least one arrangement, for each access right548, the currentaccess rights portal542 may display a unique access right identifier, an access type, an access description, a unique resource identifier of the associated resource, an entitlement description, a date entitlement was granted, and a name of individual that approved the access right. According to at least one aspect, if an access right548 is pending review for entitlement, the currentaccess rights portal542 may include one or more selectable user interface elements for each pending user access review to allow the manager to process the review. In some examples, the selectable user interface elements may include an approveentitlement element528, areject entitlement element530, and aroute review element532. These selectable user interface elements operate in a similar fashion to the selectable user interface elements inFIG. 2 above.
• Similarly, in at least one arrangement, for each access right550, the historicaccess rights portal544 may display the same attributes of access right548 as presented in the current access rights portal. Additionally, for each access right550, the historicaccess rights portal544 may display a date the access right550 was revoked, and an event associated with the revocation (e.g., an end of employment term, transfer to another division or branch, a risk violation, or the result of a regulatory access rights review).
• InFIG. 5D, an example of an implementation of a fourth type ofinterface560 of anIAM review system228 is shown. Theexample interface560 inFIG. 5D is anapplication review interface560. Theapplication review interface560 may include a pending applicationaccess review portal562, which provides a listing of allapplications564 with pending application reviews assigned to the manager, as indicated by theinterface header518. For eachapplication564, theapplication review interface560 may display a unique application identifier, an application description, an individual that last reviewed the application, a date of the last review, a status of the pending application review (e.g., not started, started, completed), and a progress indicator representing the number of access rights that have been reviewed for the access review relative to the total number of access rights to review for the application review. To navigate to an application detail interface570 (FIG. 5E), the manager may select one of theapplications564 listed in theapplications portal514.
• InFIG. 5E, an example of an implementation of a fifth type ofinterface570 of anIAM review system228 is shown. Theexample interface570 inFIG. 5E is anapplication detail interface570. Although an application may be a type of resource, some example implementations of theIAM review system228 may separate reviews and details for applications from reviews and details for other types of resources (e.g., servers, databases). In at least one arrangement, theapplication detail interface570 may include an applicationaccess detail portal572 and an application permissions portal574. The applicationaccess detail portal572 provides a listing of all access rights associated with the selected application, as indicated by theapplication access header580. In some examples, theapplication detail interface570 may include multiple portals such that each portal provides a listing of all access rights associated with the selected application for a particular deployment environment (e.g., live, testing, and development). The application permissions portal574 provides a list of permissions associated with the selected application.
• In at least one arrangement, for each access right576, the applicationaccess detail portal572 may display a unique application identifier, an application name, an environment in which an instance of the application is deployed, a unique resource identifier of the resource that hosts an instance of the application, a resource name, an access type, an entitlement description, a date entitlement was granted, and an individual that granted the entitlement. The applicationaccess detail portal572 may also include additional review information describing the relationship between the application, the resource, and the entitlement (e.g., last date entitlement was used). According to at least one aspect, if an access right576 is pending review of an entitlement, the applicationaccess detail portal572 may include one or more selectable user interface elements for each pending application access review to allow the manager to process the review. In at least one arrangement, the selectable user interface elements may include an approveentitlement element528, areject entitlement element530, and aroute review element532. These selectable user interface elements in a similar fashion to the selectable user interface elements inFIG. 2 above. A manager may thus utilize the applicationaccess detail portal572 to review entitlements to a selected application. If the manager rejects an entitlement to a selected application, theaccess review module424 may automatically submit an access request that requests revocation of the rejected entitlement.
• In at least one arrangement, for eachpermission578, the application permissions portal574 may display a unique permission identifier, the name of the permission, the type of permission (e.g., create, read, write, execute, delete), and a description of the permission. For each permission587, the application permissions portal574 may also indicate whether a review is required for that permission. The applications permissions portal574 may include a user interface element588 (e.g., a text box, radio buttons, checkbox, drop-down menu) allowing the manager to modify whether aparticular permission578 requires review. In response to input received at theuser interface element588 for one of thepermissions578, theIAM review system228 may set a review flag indicating whether review of that permission is required. The review flag of apermission578 may, for example, be set to “Y” when the input indicates that review of the permission is required and set to “N” when the input indicates that review of the permission is not required. Theapplications permission portal574 may also include auser interface element589 allowing the manager to set a risk level for apermission578. As discussed further below, the risk level associated with apermission578 may be utilized to automatically set the review flag of that permission. Individually selecting which permissions of a resource requires review advantageously allows the manager to express risk associated with that resource in a granular fashion. As a result, the total number of reviews to complete for that application may be advantageously reduced. Granular risk expression will be discussed in further detail below.
• InFIG. 5F, an example of an implementation of a sixth type ofinterface590 of anIAM review system228 is shown. Theexample interface590 inFIG. 5F is aresource review interface590. Theresource review interface590 may present a list of resources other than applications (e.g., servers, databases). In some examples, theresource review interface590 may include a resources portal592 and a resource users portal594. The resources portal592 may display a list of resources assigned (e.g., for supervision) to the manager, as indicated by theinterface header518. The resource users portal594 may display a list of users with entitlements to access a selectedresource596. The resource users portal594 may also enable the manager to review the entitlements of the users having access to the selected resource.
• In at least one arrangement, for eachresource596, the resources portal592 may display a unique resource identifier, a resource description, a date the resource was created (or deployed at a computing system), a date the resource was last reviewed, and a name of individual that last reviewed the resource. To navigate to a resource detail interface610 (FIG. 5G), the manager may select one of theresources596 listed in theresources portal592.
• In at least one arrangement, for eachresource review598, the resource users portal594 may display a unique user identifier, a last name, a first name, a user job code, a title, a user location (e.g., geographic region or office), a name of the user's manager, a date entitlement was granted, a name of individual that approved the entitlement, and an indicator of whether the user is an outlier (i.e., whether one or more attributes of the user deviate from the typical attributes of similar users have a similar entitlement).
• According to at least one aspect, the resource users portal594 may include one or more selectable user interface elements for each pendingresource review598 to allow the manager to process the review. In at least one arrangement, the selectable user interface elements may include an approveentitlement element528, areject entitlement element530, and aroute review element532. These selectable user interface elements operate in a similar fashion to the selectable user interface elements inFIG. 2 above. The manager may thus utilize the resources users portal594 to review user entitlements to a selected resource. If the manager rejects an entitlement associated with the selected resource, then theaccess review module424 may automatically create an access request that requests revocation of the rejected entitlement.
• InFIG. 5G, an example of an implementation of a seventh type ofinterface610 of anIAM review system228 is shown. Theexample interface610 inFIG. 5G is aresource detail interface610. Theresource detail interface610 may present details of a particular resource. In at least one arrangement, theresource detail interface610 may include aresource detail header612, a resource permissions portal614, and an associated resources portal616. In at least one arrangement, theresource detail header612 provides the details of the selected resources. For example, theresource detail header612 may include the resource name, resource location, and location description.
• According to one or more aspects, the resource permissions portal614 may provide a listing of all permissions associated with the selected resource, as indicated by theresource detail header612. In at least one arrangement, for eachpermission618, the resource permissions portal614 may display a unique permission identifier, a permission name, a permission type (e.g., create, read, write, execute, delete), and a permission description. For eachpermission618, the resource permissions portal614 may also indicate whether a review is required for that permission. The resource permissions portal614 may include a user interface element620 (e.g., a text box, radio buttons, checkbox, drop-down menu) allowing a resource manager to modify whether a particular permission requires review as described above with reference to theuser interface element588. In this way the manager may similarly express risk associated with the selected resource in a granular fashion thus advantageously reducing the total number of reviews required for that resource.
• In at least one example implementation, the associated resources portal616 may provide a listing of other resources associated with the selected resource. For example, the associated resources portal616 may present other resources the selected resource has entitlements to. Additionally or alternatively, the associated resources portal616 may present other resources having entitlements to the selected resource. For each associatedresource622, the associated resources portal616 may display a unique resource identifier, a resource name, a resource type (e.g., application, server, database), and a resource description. To view resource details for one of the associated resources622 (i.e., to navigate to the resource detail interface610), the manager may select one of the associatedresource622 listed in the associated resources portal616.
• InFIG. 5H, an example of an implementation of an eighth type ofinterface630 of anIAM review system228 is shown. Theexample interface630 inFIG. 5H is aviolation review interface630. In at least one arrangement, theviolation review interface630 may include a risk managementrule violation portal632, which presents pending risk violation reviews. A risk violation review may be triggered by theIAM system220 when a user, application, or other resource is provisioned with incompatible access rights, e.g., combinations of incompatible roles, tasks, or permissions. Access rights may be incompatible, for example, due to separation-of-duties principles.
• For each pendingrisk violation review634, the risk managementrule violation portal632 may display a violation type (e.g., separation-of-duties), a base access right, a conflicting access right, a description of the violation, and information regarding any exceptions to the risk violation. In some examples, there may exist an exception to the risk violation, such that the risk violation is deemed to be acceptable (e.g., when a user is provisioned with access rights for a temporary training period). A manager may thus utilize the risk management rule violations portal632 to review risk violations detected at theIAM system220. If the manager determines that the exception does indeed apply to the risk violation, the manager may approve the risk violation and justify the approval by identifying the applicable exception. If the manager does not approve of the risk violation, then theaccess review module424 may automatically create an access request that requests revocation of the conflicting entitlement that violates the risk management rule. The manager may also view and configure the details of a risk management rule at a risk management rule configuration interface650 (FIG. 5I). To navigate to a risk management rule configuration interface650 (FIG. 5I), the manager may select one of the violations listed in the risk management rule violations portal632.
• Further, the risk management rule violations portal632 may include one or more selectable user interface elements for each pendingrisk violation review634 to allow the manager to process the review. In at least one arrangement, the selectable user interface elements may include an approveentitlement element528, areject entitlement element530, and aroute review element532. These selectable user interface elements operate in a similar fashion to the selectable user interface elements inFIG. 2 above. Additionally, in some examples, if the manager selects the approveentitlement element528, theIAM review system228 may prompt the manager for a justification, which may be stored asreview information416 in a review record at thedata store414.
• InFIG. 5I, an example of an implementation of a ninth type ofinterface650 of anIAM review system228 is shown. Theexample interface650 inFIG. 5I is a risk management rule configuration interface650 (“rule configuration interface”). In at least one example implementation, therule configuration interface650 allows the manager to create risk management rules by identifying rule violations (e.g., incompatible access rights). In at least one arrangement, therule configuration interface650 may allow the manager to create a new risk management rule or modify an existing risk management rule. The risk management configuration interface may include anaccess rights portal652 that lists roles, task, and permissions selectable as base access rights or conflicting access rights for the risk management rule being configured. According to one or more aspects, a risk management rule may be defined by aname654, adescription656, a base access right658, one or moreconflicting access rights660, a violation severity level662 (e.g., low, medium, high, critical), and one or more exceptions664 to the risk management rule. TheIAM system220 may determine whether new access requests violate risk management rules defined and stored in theIAM review system228 based on the base access right and one or more conflicting access rights respectively selected for the risk management rules. If a new access request is determined to violate a risk management rule, theIAM review system228 may trigger a violation review, which may be displayed at the violation review interface630 (FIG. 5H). Additionally, in at least one example implementation, even if a risk management rule exception applies, the violation review may still be triggered, but the applicable exception may be displayed with the violation review at the violation review interface630 (FIG.5H),In this way, theIAM review system228 may ensure that a violations of risk management rules are presented to managers for approval.
• Therule configuration interface650 may identify the access right selected as the base access right658 for the risk management rule being configured. Therule configuration interface650 may also include a list ofaccess rights660 selected as conflicting with the base access right. As seen inFIG. 5I, various combinations of roles, tasks, and permissions may be defined as conflicting access rights (e.g., role-role, role-task, role-permission, task-task, task-permission, and permission-permission). Therule configuration interface650 may include input elements670a-bto add and remove access rights to a risk management rule being configured. A manager may add an access right to the risk management rule as a base or conflicting access right by selecting one of the access rights in theaccess rights portal652 and selecting theinput element670ato add the selected access right to the risk management rule. A manager may remove the base access right658 or one of the conflicting access rights in thelist660 and selecting theinput element670bto remove the selected access right. It will be appreciated that other example implementations (e.g., combination of user interface elements) may be selectively employed to create and modify risk management rules without departing from the scope of the present disclosure.
• In some examples, therule configuration interface650 may also include a list of exceptions664 created for a conflicting access right (e.g., text box, drop-down, add/remove options, etc.) Selecting one of the conflicting access rights in the list ofconflicting access rights660 may cause the exceptions664 associated with the selected conflicting access right to be displayed in the list. The rule configuration interface may include aninput element672 to add a new exception to the conflicting access right selected and aninput element674 to modify an existing exception for the conflicting access right selected. Selecting theelement672 to add or theelement674 to modify an exception may cause the manager to navigate to the riskexception configuration interface680.
• In at least one example implementation, therule configuration interface650 may include selectableuser interface elements676 and678 to respectively save or the changes made to a risk management rule. The manager may select the save element676 to create or modify the risk management rule in theIAM system220 with the selections made in therule configuration interface650. The manager may also select the cancelelement678 to abandon the creation or modification of the risk management rule. Additionally or alternatively, upon selection of the save element676 or the cancel element687, therule configuration interface650 may alert the manager. If the manager selects the save element676, then theIAM review system228 may alert the user to invalid (e.g., empty, blank, invalid) components in the risk configuration portal. If the manager selects the cancelelement678, then theIAM review system228 may ask for confirmation as to whether the manager would like abandon the changes made to the risk management rule.
• InFIG. 5J, an example of an implementation of a tenth type ofinterface680 of anIAM review system228 is shown. Theexample interface680 inFIG. 5J is a riskexception configuration interface680. The riskexception configuration interface680 allows the manager to create and configure exceptions to risk management rules created in the rule configuration interface650 (FIG. 5I). The riskexception configuration interface680 allows the manager to create or modify an exception to a selected risk management rule using selectable user interface elements associated with various types of metadata and logical operators. The riskexception configuration interface680 may display information associated with a selected risk management rule including therule name654, the base access right658, the list of theconflicting access rights660, the violation severity level662 (e.g., low, medium, high, critical), and therule description656.
• To configure a risk exception, the manager may select a logical operator690 (e.g., equals, not equals, greater than, less than, and so on) and one ormore attributes692 to evaluation against a selected attribute. The manager may also select anexpiration date694 for the risk exception being configured. In at least one arrangement, the user may select one or more attributes based on metadata associated with a user (e.g., location, division, job code), an application (e.g., environment), or another resource (e.g., location, permission type). Other types of metadata associated with other components of the IAM system will be appreciated with the benefit of this disclosure and may be selectively employed to configure risk exceptions. Furthermore the riskexception configuration interface680 may allow a user to select multiple values of a particular attribute to be alternatively evaluated against the logical operator (e.g.,job code 1 OR job code 3).
• In at least one example implementation, the riskexception configuration interface650 may include selectableuser interface elements696 and698 to respectively save or cancel the changes made to a risk exception being configured. Thesave element696 and the cancelelement698 may be similar to that described above in relation to the rule configuration interface650 (FIG. 5I).
• InFIG. 5K an eleventh type ofinterface700 of anIAM review system228 is shown. Theexample interface700 inFIG. 5K is arole configuration interface700. In at least one example implementation therole configuration interface700 allows the manager (e.g., role engineers) to create new roles and associate access rights to those roles (e.g., tasks, permissions). Therole configuration interface700 allows the manager to create new roles or modify an existing role. According to one or more aspects, a role may be defined by arole name704, arole description706, and one ormore access rights710. Therole configuration interface700 may also include input elements that allow the manager to specify required attribute values714 that a user must possess in order to be assigned the role such as, e.g., job code, business division, and location. These user attributes prescribe the attributes that users must have in order to be in the group. The one or more access rights may be selected from different sources (e.g., existing roles, resources).
• In at least one arrangement, therole configuration interface700 may include one or more input elements to allow the manager to define the various components of a role. For example, therole configuration interface700 may include a role name input element704 (e.g., text box, etc.), a role description706 (e.g., text box, etc.), such that the manager can set the role name and the role description. Therole configuration interface700 may also include a list of access rights710 (e.g., tasks, permissions) selected for the role being configured. It will be appreciated that other example implementations (e.g., combination of user interface elements) to create and modify roles may be utilized, without departing from the scope of the present disclosure.
• Therole configuration700 may include an accessright portal708 that lists access rights the manager may select to add to the role being configured. As seen inFIG. 5K, a manager may add resource permissions to the role being configured. The manager may select a resource at the accessright portal708, and the access right portal may display a list of permissions associated with the selected resource. The manager may then select one of the permissions to add to the role being configured. The accessright portal708 may also display a description of the resource permission selected. The accessright portal708 may similarly display a list of existing roles the manager may add as a parent role of the role being configured. The manager may select an existing role from the interactive list of roles in order to view tasks and permissions associated with that existing role. The manager may then select one or more of these tasks and permissions to add to the role being configured. Additionally or alternatively, the manager may select one of the existing roles from the access right portal708 as a parent role of the role being configured. In this way the role being configured may inherit the access rights of the role selected as the parent role. In some example implementations, all of the tasks and permissions associated with a parent role may be automatically added to the role being configured. Therole configuration interface700 may also include elements to add and remove selected access rights.
• In some examples, theIAM review system228 may evaluate existing risk management rules when a manger adds access rights to a role being configured in order to determine whether the selected access right violates a risk management rule. If any of the access rights selected for the role are determined to violate a risk management rule, therole configuration interface700 may display aviolation indicator712 with the conflicting access right listed in the list ofaccess rights710 for the role.
• In at least one example implementation, therole configuration interface700 may include selectableuser interface elements716 and718 to respectively save or cancel the changes made to the role being configured. The manager may select thesave element716 to create or modify the role in theIAM system220 with the selections made at therole configuration interface700. The manager may also select the cancelelement718 to abandon the creation or modification of role. Additionally or alternatively, upon selection of thesave element716 or the cancelelement718, theIAM review system228 may alert the current manger. For example, if the manager selects thesave element716,IAM review system228 may alert the user to invalid (e.g., empty, blank, invalid) components at therole configuration interface700. TheIAM review system228 may also alert the manager if the manager attempts to save a role for which a selected access right violates a risk management rule. If the manager selects the cancelelement718, the IAM reviewssystem228 may ask for confirmation as to whether the manager would like abandon the changes made to the role being configured.
• InFIG. 5L a twelfth type ofinterface720 of anIAM review system228 is shown. Theexample interface720 inFIG. 5L is a pendingrole review interface720. The pendingrole review interface720 may include a pendingrole review portal722 and auser portal724. The pendingrole review portal722 may listroles726 with pending access reviews. Theuser portal724 may list users currently assigned to or otherwise associated with a selected role. The pendingrole review portal722 may listroles726,tasks728 associated with a role, andpermissions730 associated with a task. Theroles726 listed in the pendingrole review portal722 may be associated with a pending review. For eachrole726, the pending reviews portal722 may display details for theroles726,tasks728, andpermissions730 listed. Role details may include a role description, a date last reviewed, a date granted, and a name of an individual that approved the role. Eachrole726 listed at the pendingrole review portal722 may be expanded or collapsed to show or hide the tasks and corresponding permissions associated with that role. For example, arole726 may be expanded to show thetasks728 associated with the selected role. For atask728, the pendingrole review portal722 may display a task description and a date granted (e.g., the date the task was assigned to the role). Further, atask728 within the pendingrole review portal722 may be expanded or collapsed to show or hide thepermissions730 associated with the selected task. For apermission730, the pendingrole review portal722 may display a permission description and a date granted (e.g., the date the permission was associated with the task).
• In at least one example implementation, selecting one of theroles726 from the pendingrole review portal722 may causes the users portal724 to list the users assigned the selected role. For auser732, the users portal724 may display a unique user identifier, a last name, a first name, a job code, a job title, a location, the name of the user's manager, a date the role was assigned to user, and a name of an individual that approved the assignment. Additionally or alternatively, the users portal724 may include a selectableuser interface element734 to manually trigger an access review for the role assigned to the selecteduser732. The manager may also select atask728 at the pendingrole review portal722 to display theusers732 assigned to the selected task at theuser portal724. The manager may further select apermission730 to display theusers732 having an entitlement to the selected permission at theuser portal724.
• InFIG. 5M a thirteenth type ofinterface740 of anIAM review system228 is shown. Theexample interface740 inFIG. 5M is arole review interface740. Therole review interface740 may be used to review a role selected at the pendingrole review interface720, as indicated by the role review header748. In at least one arrangement, therole review interface740 may include anaccess review portal742,access rights portal744, and auser portal746. Theaccess review portal742 may provide a listing of pending access reviews associated with the selected role. Theaccess rights portal744 provides a listing of all access rights for the selected role. Theuser portal746 provides a listing of all users assigned to the selected role.
• In at least one arrangement, for each pendingaccess review750 and752 (e.g., tasks, permissions), theaccess review portal742 may display an access right, an access type, an access right description, a date last reviewed, a date granted, a name of an individual that approved the access right, and one or more selectable user interface elements for each pending access right review to allow the manager to process the access right review. In some examples, the selectable user interface elements may include an approve accessright element528, a reject accessright element530, and a route accessright review element532. These selectable user interface elements operate in a similar fashion to the selectable user interface elements inFIG. 2 above. In some examples, eachtask review750 within theaccess review portal742 may be expanded or collapsed to show or hide the permission reviews752 associated with the selectedtask review750. A manager may utilize therole review interface740 to approve or reject tasks and corresponding permissions that are associated with the selected role. If the manager rejects a task or permission for the role, then theaccess review module424 may automatically create an access request that requests the rejected task or permission be removed from the selected role. Furthermore therole review interface740 improves the role review process by separating the pending access reviews750 and752 from all of the access rights associated with the role.
• Theaccess rights portal744 may similar to theaccess review portal742, except that it may display all access rights associated with the selected role. Thus, not all listings in theaccess rights portal744 may require a review. Accordingly, the selectable user interface elements to approve, reject, or route the access review may only appear for those access rights requiring a review.
• In at least one arrangement, for eachuser754, theuser portal746 may display a unique user identifier, a last name, a first name, a job code, and selectable user interface elements to approve, reject, or route the access review for the selected user. These selectable user interface elements operate in a similar fashion to the selectable user interface elements in theaccess review portal742 and inFIG. 2 above. A manager may thus also utilize the role review interface to approve or reject users that are assigned the selected role. If the manager rejects a user assigned to the selected role, then theaccess review module424 may automatically create an access request that requests the user be removed from the role.
• With regard to the interfaces and portals shown (FIGS. 5A-M), the interfaces and portals may include the ability to sort, filter, search, and otherwise manipulate the data displayed through theIAM review system228. ForFIGS. 5A-M, it will be appreciated that the interfaces and portals shown are illustrative and other means of displaying and interacting with theIAM review system228 may be used.
3. Quality Assurance
• TheIAM review system228 may include aquality assurance module422 that, in operation, selectively performs various quality assurance (QA) checks at the enterprise-wide computing system200. QA checks may include, for example: identification of non-use of roles; determination of whether an access request is redundant; identification of unused entitlements; and identification of data incompatibility among the components of the IAM review system. TheQA module422 may perform one or more of these QA checks periodically (e.g., daily, weekly, and so forth) or on demand in response instructions received from an administrator. Identification of non-use of roles may include automatically determining whether requested access rights match a defined role and, if so, refraining from provisioning the access rights specified in the access request. Instead the requestor may be instructed to submit a new access request that specifies the defined role that matches the previously requested access rights. Determining whether an access request is redundant may include automatically evaluating the current access rights of the user and a requested change to those access rights specified in an access change request in order to determine whether the requested change to the access rights has already been fulfilled, e.g., whether a requested access right has already been provisioned or revoked. If so, the access request may be closed, denied, discarded, or otherwise ignored. Identification of unused permissions may include automatically determining which provisioned permissions a user does and does not utilize to access theresources210 of the enterprise-wide computing system200. Identification of data incompatibility among components may include determining whetherresources210 provide access reports with access information structured, arranged, and formatted that enables a review to complete access reviews based on the access report. Identification of data incompatibility may also include determining whether access requests structure, arrange, and format access request information that allows the requested access rights to be subsequently provisioned. If a reviewer cannot complete an access review due to the format of the access information in an access report, the access review may be added to a list of unactionable action items. Similarly, if access rights cannot be provisioned due to the format of the access request information in an access request, the access request may also be added to a list of unactionable action items. By identifying unactionable action items, administrators may ensure referential integrity among the components of the enterprise-wide computing system200. Each of these QA checks will be discussed in further detail below.
• FIG. 6 is aflowchart601 of example method steps for identifying unused roles. An access request may be submitted and received at the IAM review system228 (block603). The access request may specify a user and one or more access rights to provision for the user. Roles in theIAM system220 may be associated with various types of access rights such as permissions forresources210. TheQA module422 may thus automatically compare the access rights requested in the access request to the access rights associated with the roles defined in the IAM system220 (block605). TheQA module422 may obtain a list of defined roles from theIAM data store222. TheQA module422 may then determine whether the access rights requested in the access request match the access rights of a defined role (block607). As noted above, an access request may specify one or more permissions to provision for a specified user. Therefore an access request may match a defined role when each requested access right respectively matches an access right associated with the role, e.g., tasks and permissions. In other words, a set of requested access rights may match a set of access rights associated with a role when the set of requested access rights includes all of the access rights in the set of access rights associated with the role.
• If the requested access rights do not match the access rights of any defined role (block607:N), then theQA module422 may forward the access request to the access request system (e.g., as an access request ticket) for fulfillment (block609). If, however, the requested access rights do match the access rights of one of the defined roles (block607:Y), then theQA module422 may deny the access request (block611), e.g., deny, discard, or otherwise ignore the access request. TheQA module422 may also inform the requestor that the access has been denied (block613), e.g., via an email. TheQA module422 may also instruct the requestor to submit a new access request for the role identified as matching the access request (block615). TheQA module422 may, for example, identify the matching role when informing the requestor that the access request was denied. By enforcing the use of roles to provision access requests, theQA module422 of theIAM review system228 may advantageously ensure an enterprise adheres to recommended identity and access management practices.
• InFIG. 7 aflowchart701 of example method steps for identifying redundant access requests is shown. An access request may specify access rights to add or revoke for a user. An access request may specify, for example, a role, task, or permission to add to or revoke from a user. An access request may be received at the IAM review system228 (block703). The access request may be an access change request as described above and may be submitted to theaccess request system224. TheIAM review system228 may be configured to intercept access requests submitted to theaccess request system224 in order to determine whether the access request is redundant. As described further below, theIAM review system228 may provide the access request to theaccess request system224 if the access request is not redundant. If the access request is redundant, however, theIAM review system228 may not provide the access request to theaccess request system224 and instead deny the access request. Upon receipt of an access request, theQA module422 may retrieve the entitlements for the user specified in the access request (block705). TheQA module422 may retrieve the user entitlements from theIAM data store222. TheQA module422 may then determine the type of access request, i.e., whether to provision new access rights or whether to revoke existing access rights (block707).
• If the access request specifies access rights to add (block707:ADD), then theQA module422 may compare the access rights to add to the current entitlements for the user (block709). If the access request specifies a permission to add, then theQA module422 may determine whether a current entitlement for the user corresponds to the requested permission. If the access request specifies a task to add, then theQA module422 may determine whether each permission associated with the task respectively corresponds to a current entitlement for the user. If the access request specifies a role to add, then theQA module422 may determine whether each permission associated with the role, as well as each permission of any tasks associated with the role, respectively corresponds to a current entitlement for the user. If each permission to add has already been provisioned for the user (block711:Y) then theQA module422 may close access request (block713), e.g., deny, discard, or otherwise ignore the access request. If at least one of the requested access rights has not been provisioned for the user (block711:N), then theQA module422 may forward the access request to theaccess request system224 for provisioning of any access rights not already provisioned for the user (block715).
• If the access request specifies access rights to revoke (block707:REVOKE), then theQA module422 compare the access rights to revoke to the current entitlements for the user (block717). If the access request specifies a permission to revoke, then theQA module422 may determine whether the permission corresponds to one of the current entitlements of the user. If the access request specifies a task to revoke, theQA module422 may determine whether the user is currently associated with the task and may determine whether any of the permissions associated with the task correspond to one of the current entitlements of the user. If the access request specifies a role, then theQA module422 may determine whether the user is currently associated with the role and may determine whether any permissions associated with the role, as well as any permissions of the tasks associated with the role, correspond to a current entitlement of the user. If the user is not currently associated with the task or role and none of the current entitlements for the user correspond to the access rights to revoke (block719:N), then theQA module422 may close the access request (block713), e.g., deny, discard, or otherwise ignore the access request. If the user is still currently associated with the task, still associated with the role, or at least one of the current entitlements of the user corresponds to an access rights to revoke (block719:Y), then theQA module422 may forward access request for revocation of any such access rights that have not yet been revoked (block721).
• By determining whether an access request is redundant, an enterprise may avoid situations where access requests are submitted and proceed all the way to the provisioning stage only to have an administrator determine that the access request has already been fulfilled, i.e., access rights to add have already been provisioned or access rights to remove have already been revoked. TheQA module422 thus advantageously helps an enterprise to avoid wasted efforts, to reduce the number of access requests sent for fulfillment, and to reduce the utilization of computing resources used to fulfill access requests.
• TheQA module422 of theIAM review system228 may also be used to identify unused entitlements. If a user does not utilize an entitlement, then the entitlement may be removed as unnecessary for that user. InFIG. 8, an example workflow between components of theIAM review system228 used to identify unused entitlements is shown. InFIG. 9 a flowchart901 of example method steps for identifying unused entitlements is shown. Aresource210 may periodically provide an access report312 (block903). Theaccess report312 may include a list of entitlements used to access theresource210 since previous access report. Resources may provide access reports to theIAM security system226 that stores access reportinformation316 corresponding to the access reports312. As noted above, an entitlement identifies a permission to access a particular resource provisioned for a user. Theresource inventory system230 may provideresource entitlement list802 that identifies all of the entitlements associated with that resource210 (block905). TheQA module422 may obtain theaccess report information316 from theIAM security system226 and obtain theresource entitlement list802 for that resource from theresource inventory system230. TheQA module422 may then iterate over the resource entitlement list to compare the entitlements for the resource to theaccess report information316. TheQA module422 may select an entitlement (block907) and determine whether the selected entitlement appears in the access report information316 (block909). If the selected entitlement does not appear in the access report information316 (block907:N), then theQA module422 may add the selected entitlement to an unused entitlement report804 (block911) and identify the selected entitlement as an unused entitlement (i.e., an unused access right) in theunused entitlement report804. If the selected entitlement does appear in theaccess report information316, then theQA module422 may determine whether there are additional entitlements to evaluate and, if so (block913:Y), select the next entitlement in theresource entitlement list802 for evaluation (block915). Once all entitlements in theresource entitlement list802 have been evaluated (block913:N), theQA module422 may provide theunused entitlement report804 to the manager of the resource (block915). In some example implementations, theQA module422 may be configured to identify the selected entitlement as a used entitlement (i.e., a used access right) in an entitlement report.
• The resource manager may then investigate why the user having the entitlement has not utilized the entitlement to access the resource. If the resource manager determines the user does not need the entitlement to carry out assigned roles or tasks, then the resource manager may submit an access request to remove the entitlement from the user. The example steps shown inFIG. 9 may be repeated periodically or on-demand for other resources of the enterprise-wide computing system200. In this way, theQA module422 of theIAM review system228 ensures that users only have those entitlements needed to access carry out assigned roles or tasks.
• As an example, a resource may be associated with fifty entitlements used to access that resource. The access report provided by the resource may only indicate that users only utilized forty of those entitlements access the resource. During evaluation of the entitlements associated with the resource, theQA module422 may identify the ten unused entitlements based on the comparison of the access report to the resource entitlement list received from the resource inventory. TheQA module422 may thus add the ten unused entitlements to theunused entitlement report804 and provide the unused entitlement report to the manager of the resource. The resource manager may then submit respective access requests to remove those ten unused entitlements.
• Anaccess report312 may also identify permissions for the resource, roles assigned to users that access the resource, and tasks that involve accessing the resource. TheQA module422 may thus also obtain a resource permission list, resource role list, or a resource task list from theresource inventory system230 for comparison to theaccess report information316. A resource permission list may identify all permissions for a resource. The resource role list may identify roles that are associated with the resource, e.g., roles that are configured to have access to the resource. A resource task list may identify tasks that are associated with the resource, e.g., task that involve accessing the resource. TheQA module422 may perform steps similar to those shown inFIG. 9 to compare a resource permission list, a resource role list, or a resource task list to an access report provided by the resource. TheQA module422 may thus also generate an unused permission report, an unused role report, and an unused task report each of which may be similar to theunused entitlement report804 shown inFIG. 8. TheQA module422 may add a permission to the unused permission list if the access report does not indicate the permission was used to access the resource. TheQA module422 may add a role associated with resource to the unused role list if the access report does not identify any users assigned that role. TheQA module422 may also add a task associated with the resource to the unused task list if the access report does not indicate the resource was accessed during execution of the task. TheQA module422 may provide the unused permission list, unused resource list, or unused task list to the resource manager. The resource manager may then update the resource to remove any unused permissions, may update an unused role to remove association with resource, or may update an unused tasks to remove association with the resource.
• With respect to referential integrity, access rights are the focus of three different activities of identity and access management: i) submitting access requests to add or revoke access rights, e.g., utilizing theaccess request system224; ii) reporting what access rights were used to actually access a resource, e.g., providing resource access reports; and iii) reviewing access rights that have been provisioned for users, e.g., utilizing the IAM review system. Ideally theaccess request system224, theresources210 of the enterprise-wide computing system200, and theIAM review system228 format and arrange access right information in the same way such that access requests, access reports, and access reviews all have the same level of actionable granularity. In other words, there is ideally a relatively high level of referential integrity among the components such that access rights may be requested on the same actionable level with which they are reported and with which they are reviewed.
• In practice, however, the components of the enterprise-wide computing system200 might not format and arrange access right information in the same way. For example, the manner in which aresource210 formats an access report identifying the entitlements used to access the resource may differ from the manner in which access rights are provisioned or revoked for users. Access rights might be named differently, grouped differently, or the number of access rights may differ between components. As an example, an access request may request that a single task be add to a user. The requested task, however, may have been originally created as part of a role and thus cannot be individually add to the user. As a result, the access request, in this example, may be unactionable and remain unfulfilled due to the mismatch between the task requested and the access rights that are available to be provisioned.
• InFIG. 10 an example workflow between components of theIAM review system228 used to identify unactionable action items is shown. InFIG. 11 aflowchart1101 of example method steps for identifying unactionable action items is shown. TheQA module422 may be configured to perform a QA check that identifies unactionable action items. As noted above, action items may include access requests that have not been fulfilled (i.e., unfulfilled access requests) and access reviews that have not been completed (i.e., incomplete access reviews).
• TheQA module422 may obtain a list of action items that have not yet been completed (block1103). Theaccess request system224, for example, may provide list of access requests that have remained unfulfilled, i.e., an unfulfilledaccess request list1002. Theaccess review module424 may also provide a list of access reviews that have not been completed as of their specified due date, i.e., anincomplete review list1004. TheQA module422 may iterate over thelist1002 or1004 of unactionable action items and determine how long the action items have been pending, in other words, calculate a duration an incomplete action item has remained incomplete. For example, theQA module422 may select an incomplete action item from the list (block1105) and compare the duration the incomplete action item has remained incomplete to a predetermined duration threshold (block1107). The duration threshold may depend on the action item type. The predetermined duration threshold for an access request may be, e.g., three days from the date the access request was submitted. The duration threshold for an access review may be, e.g., seven days from the due date of the access review. Alternative duration thresholds may be selectively employed.
• If an action item has remained incomplete for longer than the predetermined duration threshold (block1109:Y), then theQA module422 may add the action item to an unactionable report1006 (block1111) and identify that action item as an unactionable action item in the report. If the action item has not yet been incomplete for longer than the predetermined duration threshold (block1109:N), then theQA module422 may determine whether there are more incomplete action items in thelist1002 or1004 to evaluate (block1113). If so (block1113:Y), then theQA module422 may select the next incomplete action item in thelist1002 or1004 (block1115) and compare the duration the next selected action item has remained incomplete to the predetermined duration threshold. Once theQA module422 has evaluated each incomplete action item in thelist1002 or1004, the QA module may provide theunactionable report1006 to administrator (block1117). The administrator may thus advantageously investigate why action items have not been completed. If action items have not been completed to due to incompatibility issues, then the administrator may initiate efforts to make improve the referential integrity between the system components associated with the incomplete action item as described above.
4. Reconciliation
• As mentioned above, theIAM review system228 may be utilized for reconciliation of access rights. Access right reconciliation may include a systematic analysis of the access rights that have been provisioned for a user in order to determine whether the user has been provisioned with all access rights the user is entitled to and has not been provisioned with access rights the user is not entitled to. Access right reconciliation may also include a systematic analysis of access rights that have been provisioned for a user in order to determine whether the user received such access rights through appropriate channels. An appropriate channel, in this example, may be the access request system224 (FIG. 2) in which an entitlement can be traced back to an approved access request.
• Thereconciliation module428 of the IAM review system228 (FIG. 4) may be configured to perform various types of reconciliation tasks with respect to access rights in an enterprise-wide computing system. Examples of various types of access right reconciliation tasks include: expectation reconciliation, termination reconciliation, authorization reconciliation, and deviation reconciliation. Each of these types of reconciliation will be discussed in further detail below.
• In general, the reconciliation module may generate one or more reports that list or otherwise identify entitlements that should be provisioned or revoked for one or more users. It will be appreciated that, although each type of reconciliation is described independently, one or more of the different types of reconciliation efforts described below may be performed simultaneously or sequentially with the results appearing in a single reconciliation report. In such an example implementation, the reconciliation report may be divided into several sections where each section presents the reconciliation results for a different type of access right reconciliation. In other example implementations, the reconciliation module may provide multiple reconciliation reports where each report presents the reconciliation results for a different type of access right reconciliation.
• Expectation reconciliation refers to ensuring that the actual access rights reported for a user are consistent with the expected access rights for that user. During expectation reconciliation thereconciliation module428 may compare a set of reported entitlements to a set of expected entitlements. Thereconciliation module428 may flag expected entitlements that are not being reported and may also flag reported entitlements that are not expected. Stated differently, expectation reconciliation involves comparing the entitlements a user is reported to have with the entitlements that user is expected to have.
• FIG. 12 illustrates an example workflow between the components of theIAM review system228 for conducting expectation reconciliation.FIG. 13 is aflowchart1300 of example method steps for performing expectation reconciliation. Thereconciliation module428 of theIAM review system228 may receiveaccess report information316 from the IAM security system226 (block1302). Theaccess report information316 may correspond tomultiple access reports312 respectively received fromresources210 of the enterprise-wide computing resources. As noted above, theaccess report information316 may respectively identify the entitlements used to access theresources210. Based on theaccess report information316, thereconciliation module428 may generate a set of reportedentitlements1202 for a particular user (block1304). The set of reportedentitlements1202 may include entitlements a user used to access thevarious resources210 of the enterprise-wide computing system200. Thereconciliation module428 may also receive anaccess request list1204 for that user from the access request system224 (block1306). Theaccess request list1204 may be a list of access requests that requested provisioning of access rights for user. The access rights identified in an access request list may be referred to a requested access rights. Based on theaccess request list1204, thereconciliation module428 may also generate a set of expectedentitlements1206 for the user (block1308). The set of expectedentitlements1206 may exclude access rights that were provisioned but subsequently revoked. Thereconciliation module428 may then compare the set of reportedentitlements1202 to the set of expectedentitlements1206. Based on the comparison, thereconciliation module428 may generate anexpectation reconciliation report1208. Theexpectation reconciliation report1208 may identify a reported access right as either an expected access right or an unexpected access right as shown below. Theexpectation reconciliation report1208 may also identify a requested access right as either a provisioned access right or a non-provisioned access right as also shown below.
• As seen inFIG. 13, thereconciliation module428 may identify unexpected entitlements and potentially missing entitlements in parallel simultaneously or sequentially. For convenience, however, these two aspects of the expectation reconciliation process will be described below as performed sequentially. With respect to reported entitlements, thereconciliation module428 may select a reported entitlement1202 (block1310) and determine whether the selected reported entitlement appears in set of expected entitlements1206 (block1312). If the selected reportedentitlement1202 appears in the set of expected entitlements1206 (block1312:Y), then thereconciliation module428 may indicate in theexpectation reconciliation report1208 that the reported entitlement is expected (block1314), i.e., identify the reported entitlement as an expected entitlement. If, however, the reportedentitlement1202 does not appear in the set of expected entitlements1206 (block1312:N), then thereconciliation module428 may flag the reported entitlement as unexpected in the expectation reconciliation report1208 (block1316), i.e., identify the reported entitlement as an unexpected entitlement. Thereconciliation module428 may then determine whether there are morereported entitlements1202 to evaluate and, if so (block1318:Y), select the next reported entitlement (block1320) to determine whether the next selected reported entitlement appears in the set of expectedentitlements1206. Thereconciliation module428 may repeat the process for each reportedentitlement1202 in the set of reported entitlements.
• With respect to expected entitlements, thereconciliation module428 may select an expected entitlement1206 (block1322) and determine whether the selected expected entitlement appears in set of reported entitlements1202 (block1324). If the selected expected entitlement does appear in set of reported entitlements1202 (block1324:Y), then the reconciliation report may indicate that the selected expected entitlement has been provisioned in the expectation reconciliation report1208 (block1326), i.e., identify the requested entitlement as a provisioned access right. If, however, the selected expectedentitlement1206 does not appear in the set of reportedentitlements1202, then thereconciliation module428 may flag the selected expected entitlement as potentially missing in the expectation reconciliation report1208 (block1328), i.e., identify the requested access right as a non-provisioned access right. Thereconciliation module428 may then determine whether there are moreexpected entitlements1206 to evaluate and, if so (block1330:Y), select the next reported entitlement (block1332) to determine whether the next selected expected entitlement appears in the set of reportedentitlements1202. Thereconciliation module428 may repeat the process for each expectedentitlement1206 in the set of expected entitlements. An expected entitlement may not appear in the set of reportedentitlements1202 if, for example, the access rights corresponding to the entitlement have not been provisioned for the user or if the user has not utilized the entitlement to access the resource associated with the entitlement. to access resource; if not used to access resource, then may be unnecessary and thus revoked.
• Once thereconciliation module428 has evaluated each reportedentitlement1202 in the set of reported entitlements (block1318:N) and evaluated each expectedentitlement1206 in the set of expected entitlements (block1330:N), thereconciliation module428 may provide the expectation reconciliation report1208 (block1332), e.g., to an administrator. The administrator may then advantageously investigate any unexpected or unused entitlements associated with the user. If an entitlement is unexpected or unused, then the administrator may submit respective access requests to revoke any unexpected or unused entitlements.
• Theexpectation reconciliation report1208 may indicate that a reportedentitlement1202 is expected or that an expectedentitlement1206 is provisioned by indicating the entitlement is, e.g., “valid” or “confirmed” in the expectation reconciliation report. In some example implementations, theexpectation reconciliation report1208 may include reported and expected entitlements that have been confirmed as well as unexpected and unused entitlements. In other example implementations, theexpectation reconciliation report1208 may only include unexpected and unused entitlements.
• The expectation reconciliation process may be repeated for multiple users. In some example implementations, theexpectation reconciliation report1208 may include expectation reconciliation results for a single user. In other example implementations, theexpectation reconciliation report1208 may include expectation reconciliation results for multiple users. Expectation reconciliation advantageously allows administrators to identify breakdowns in the process of fulfilling access requests, e.g., determining whether a resource is correctly reporting an entitlement flagged as unused, determining whether the access request is an actionable access request (i.e., requests access rights in a manner such that access rights can be provisioned), and determining whether an access request was closed without provisioning the requested access rights and, if so, why.
• Termination reconciliation refers to ensuring that access rights for a user have all been revoked upon termination of that user. The set of access rights may be all access rights provisioned for a user or a subset of all access rights provisioned for the user. Termination reconciliation may also be performed to purge entitlements for a user that has been placed on leave-of-absence or otherwise identified as inactive within the enterprise. In this way, the enterprise may advantageously ensure that user does not inherit previously provisioned access rights if the user is reactivated within the enterprise.
• FIG. 14 illustrates an example workflow between the components of theIAM review system228 for conducting termination reconciliation. InFIG. 15, aflowchart1500 of example method steps for performing termination reconciliation is shown. Thereconciliation module428 helps to ensure that a set or subset of access rights associated with an inactive user have been revoked. Thereconciliation module428 may determine whether access rights for an inactive user have been revoked by comparing anentitlement history1402 for the inactive user to a list of access rights that have been revoked for the user, i.e., an accessright revocation list1404. The accessrights revocation list1404 may identify fulfilled access revocation requests. If thereconciliation module428 cannot match an entitlement for the inactive user to a corresponding access request requesting revocation of access, then the reconciliation module may include the entitlement in termination reconciliation report1406. Thereconciliation module428 may perform termination reconciliation periodically (e.g., daily, weekly, monthly, and do forth).
• As seen inFIG. 15, thereconciliation module428 may identify a user having an inactive status (block1502) and retrieve anentitlement history1402 for the inactive user (block1504). Thereconciliation module428 may then obtain list of fulfilled access requests that requested revocation of access rights for the inactive user (block1506). Thereconciliation module428 may then iterate over theentitlement history1402 by selecting an entitlement (block1508) and determining whether the accessright revocation list1404 includes a corresponding request to revoke the access rights associated with the selected entitlement (block1510). If the accessright revocation list1404 does not include a corresponding access right revocation request (block1512:N), then thereconciliation module428 may add the selected entitlement to the termination reconciliation report1406 (block1514) to indicate that the selected access right has not yet been revoked, i.e., identify the selected right as an unsuccessfully revoked access right. If the accessright revocation list1404 does include a corresponding access right revocation request (block1512:Y), then thereconciliation module428 may not add the entitlement to the termination reconciliation report1406 as the access rights associated with the selected entitlement have already been revoked. In some example implementations, thereconciliation module428 may add the entitlement to the termination reconciliation report1406 and identify the access right as a successfully revoked access right. If there are more entitlements in theuser entitlement history1402 to evaluate (block1516:Y), thereconciliation module428 may select the next entitlement for evaluation (block1518). Once each entitlement in the inactiveuser entitlement history1402 has been evaluated (block1516:N), thereconciliation module428 may provide the termination reconciliation report1406 to an administrator (block1520). The administrator may then advantageously investigate why entitlements were not revoked, and request revocation of any entitlements that have not yet been revoked. Thereconciliation module428 may repeat the example steps to perform termination revocation shown for additional users.
• Authorization reconciliation refers to ensuring that all of the access rights currently provisioned for a user can be traced to an approved access request.FIG. 16 illustrates an example workflow between the components of theIAM review system228 for conducting authorization reconciliation. InFIG. 17, aflowchart1700 of example method steps for performing authorization reconciliation is shown. For authorization reconciliation, thereconciliation module428 of theIAM review system228 may determine whether currently provisioned access rights for a user can be traced to approved access requests. Thereconciliation module428 may perform authorization reconciliation on a periodic basis (e.g., daily). During authorization reconciliation, thereconciliation module428 may compare the entitlements for a user during a previous reporting period to the entitlements for the user during the current reporting period. Based on the comparison, thereconciliation module428 may identify new access rights provisioned for the user since previous reporting period. Thereconciliation module428 may then compile a set ofnew entitlements1602 provisioned since the previous reporting period.
• Thereconciliation module428 may receive auser entitlement history1604 from the resource inventory system230 (block1702) and evaluate the user entitlement history to identify the set of new entitlements1602 (block1704). As noted above theuser entitlement history1604 may be a type of access rights history that identifies a set of provisioned access rights associated with that user. Thereconciliation module428 may also receive a list ofaccess requests1606 associated with the user from the access request system224 (block1706). The list ofaccess requests1606 may include an access right grant list that identifies a set of approved access grant requests for the user. Thereconciliation module428 may iterate over the list ofnew entitlements1602 by selecting one of the new entitlements (block1708) and determining whether the selected new entitlement corresponds to an access request for the user (block1710). If the selected new entitlement does not correspond to an access request (block1710:N), then thereconciliation module428 may add the selected new entitlement to the authorization reconciliation report1608 (block1712). Thereconciliation module428 may identify the selected new entitlement as an unapproved access right in thereconciliation report1608. If the selected new entitlement does correspond to an access request (block1710:Y), then thereconciliation module428 may determine whether the corresponding access request was approved (block1714). If the corresponding access request was not approved (block1714:N), then thereconciliation module428 may add the selected new entitlement to the authorization reconciliation report1608 (block1712). If the access request was not approved, then thereconciliation module428 may similarly identify the selected new entitlement as an unapproved access right in thereconciliation report1608. If the corresponding access request was approved (block1714:Y), then thereconciliation module428 may identify the selected new entitlement as an approved access right in thereconciliation report1608. Thereconciliation module428 may then determine whether there are any more new entitlements to evaluate and, if so (block1716:Y), select the next new entitlement for evaluation (block1718). Once all new entitlements have been evaluated (block1716:N), thereconciliation module428 may provide theauthorization reconciliation report1608 to an administrator (block1720). The administrator may then advantageously request revocation of the access rights listed in theauthorization reconciliation report1608 that cannot be traced to an approved access request. Thereconciliation module428 may repeat the example steps shown inFIG. 17 for additional users.
• Deviation reconciliation refers to identifying IAM information associated with a user having attributes that deviate from the attributes of users typically associated with such IAM information. The IAM information associated with a user may include various types of access rights, for example, a role assigned to a user or a resource accessed by a user. Accordingly deviation reconciliation may include determining whether one or more attributes for a user that is assigned a particular role are generally consistent with one or more corresponding attributes of users assigned that role. Stated more generally, deviation reconciliation may include determining whether a user associated with an access right has one or more attributes that deviate from corresponding attributes of other users that are also associated with that access right. Deviation reconciliation may also include determining whether one or more attributes for a user that accessed a particular resource are generally consistent with one or more corresponding attributes of users that accessed that resource. One attribute or various combinations of attributes may be utilized to compare users. The attributes may be any user metadata for the users. Example attributes may thus include: job code, job title, geographic location, line-of-business, business division, and other types of IAM information associated with users.
• As an example, deviation reconciliation may flag a user that is assigned a “bank teller” role where the user has a “bank manager” job code. Deviation reconciliation may determine that the “bank teller” role is typically assigned to users having a “bank teller” job code. In this example, deviation reconciliation has utilized the job code attribute to identify the deviation between the user assigned the “bank teller” role and the set of users typically assigned the “bank teller” role. As another example, deviation reconciliation may flag a user geographically located in California that has accessed aresource210 that is typically accessed by users geographically located in Texas. In this other example, deviation reconciliation has utilized the user geographic location attribute to identify the deviation between the user that accessed the resource and the typical users that access the resource. User having attributes that deviate from the attributes of typically users that are assigned a particular role or that access a particular resource may be referred to as “outliers.”
• FIG. 18 illustrates an example workflow between components of theIAM review system228 for conducting deviation reconciliation and identifying outliers. InFIG. 19, aflowchart1900 of example method steps for performing deviation reconciliation is shown. Thereconciliation module428 may receive IAM information from the IAM data store222 (block1902). With respect to user roles, thereconciliation module428 may receiveuser role information1802 from theIAM data store222. With respect toresources210, thereconciliation module428 may receiveaccess report information316 from theIAM security system226 that indicate which users accessed the resource. Thereconciliation module428 may also receiveuser attribute information1804 from the IAM data store (block1904).User attribute information1804 may include, e.g., metadata respectively associated with one or more users.
• Thereconciliation module428 may identify outliers based on a comparison of the respective user attributes for a set of users. Thereconciliation module428 may thus select one or more user attributes (block1906) with which to evaluate a set of users assigned a particular role or that accessed a particular resource. Attributes that may be selected for deviation reconciliation may include, for example, job code, job title, location, business division, and so forth. Thereconciliation module428 may then select a user to evaluate (block1908) and compare the user attributes of the selected user to the user attributes of the other users (block1910). Based on the comparison of user attributes, thereconciliation module428 may calculate an attribute deviation score1806 (“deviation score”) for the selected user (block1912). Thedeviation score1806 may quantify the extent to which the values of the selected attributes of the selected user deviate from the values of the selected attributes of the other users. Stated differently, thedeviation score1806 may quantify a difference between values of one or more attributes of a user and corresponding values of attributes of one or more other users.
• In some example implementations, thedeviation score1806 may be an overall deviation score that is an aggregate of multiple individual attribute deviation scores. An attribute deviation score may quantify the extent to which the value of a particular attribute for the selected user deviates from the values of that user attribute for the other users. For example, an attribute deviation score may correspond to the percentage of users having a particular user attribute value relative to all other users. Thereconciliation module428 may aggregate the individual attribute deviation scores by computing the arithmetic average, the sum, or other type of aggregate value.
• Thereconciliation module428 may determine whether a user is an outlier based on adeviation score1806 obtained for the user. In some example implementations, thereconciliation module428 may compare thedeviation score1806 obtained for the selected user to an attribute deviation threshold1808 (block1914). Depending on the particular implementation, the selected user may be determined to be an outlier if thedeviation score1806 is above or below theattribute deviation threshold1808. If the selected user is determined to be an outlier (block1916:Y), then the reconciliation module may identify the selected user as an outlier in thedeviation reconciliation report1810. If the selected user is not determined to be an outlier (block1916:N), then thereconciliation module428 may determine whether there are more users to evaluate and, if so (block1920:Y), select the next user for evaluation (block1922). Once thereconciliation module428 has evaluated all of the users (block1920:N), the reconciliation module may provide thedeviation reconciliation report1810 to an administrator (block1924). In addition, to identifying the user as an outlier in the deviation reconciliation report, thereconciliation module428 may also automatically create a review for the outlier user (e.g., a role review of an access review) and assign the new review to the manager that supervises the user or the resource. The administrator may then advantageously investigate the roles assigned to the outlier users or the access rights provisioned for the outlier users to determine whether any roles should be removed or whether any access rights should be revoked. Thereconciliation module428 may perform steps similar to those shown by way of example inFIG. 19 in order to identify outliers in a set of users that are each associated with an access right of thecomputing system200.
• As an example, thedeviation threshold1808 may be set to 10% such that a user having a deviation score below 10% is determined to be an outlier and a user having a deviation score at or above 10% is not determined to be an outlier. The job code for a user under evaluation may correspond to “bank manager,” and that user may be assigned the role of “bank teller.” Thereconciliation module428 may determine that 99% of users assigned the role of “bank teller” also have the job code that corresponds to “bank teller.” In contrast thereconciliation module428 may determine that only 1% of users assigned the role of “bank teller” have the job code that corresponds to “bank manager.” Thedeviation score1806 for the user under evaluation may thus be 1%, less than deviation threshold of 10%. Thereconciliation module428 may thus identify the user under evaluation in this example as outlier in the deviation reconciliation report. An administrator may then investigate whether the role of “bank teller” should be removed from the user. In another example, thedeviation score1806 for a user under evaluation may be based on three aggregated deviations scores, e.g., a geographic location deviation score, a job code deviation score, and a business division deviation score. Thereconciliation module428 may aggregate these three attribute deviation scores to obtain an overall deviation score and compare the overall deviation score to thedeviation threshold1808.
5. Risk Management
• TheIAM review system228 may also be utilized to manage risk associated with the enterprise-wide computing system200. Risk management, in this context may include, identifying and responding to potential risk violations as well as managing relatively high-risk resources. Accordingly therisk management module426 of theIAM review system228 may be configured to facilitate these types of risk management.
• A risk manager may, for example, utilize therisk management module426 to define risk violations and exceptions as shown above with reference toFIGS. 5I and 5J. InFIG. 20 aflowchart2000 of example method steps for defining risk management rules and corresponding exceptions is shown. The risk manager may create a new risk management rule using the risk management module426 (block2002). The risk manager may select and add the base access right for the new risk management rule (block2004). The base access right may be a role, task, or permission as described above. The risk manager may then select and add an access right that conflicts with the base access right (block2006). The conflicting access right may also be a role, task, or permission as described above. In this way, therisk management module426 advantageously enables the risk manager to configure various combinations of conflicting access rights, e.g., tasks that conflict with roles, permission that conflict with tasks, and so forth. Therisk management module426 may also enable the risk manager to select a violation severity level for the conflicting access right selected (block2008). Therisk management module426 may utilize the violation severity level when creating a violation review in response to a violation of a risk management rule. Therisk management module426 may, for example, set the due date of the violation review based on the violation severity level of the risk management rule that was violated. The due date may also be relative to the date when the violation of the risk management rule occurred. By way of example, where the violation severity level is “critical” or “high,” the due date may be set as one day from the date the violation occurred; where the violation security level is “medium” or “low,” the due date may be set as three days from the date the violation occurred. Additional and alternative due dates may be selectively employed.
• Therisk management module426 may enable the risk manager to add multiple conflicting access rights to the risk management rule under construction. Accordingly if there are more conflicting access rights to add (block2010:Y), then the risk manager may repeat steps2006-2008 to add additional conflicting access rights. Therisk management module426 may also enable the risk manager to add one or more exceptions to the risk management rule. Accordingly if there are exceptions to the risk management rule (block2012:Y), the risk manager may create a new exception (block2014). As shown above, therisk management module426 may enable the risk manager to configure the risk exception by selecting a logical operator for the exception (block2016) and select an attribute and corresponding attribute value (block2018) for the exception. The risk manager may configure an exception to depend on multiple user attributes. Accordingly if there are additional attributes to add to the exception (block2020:Y), the risk manager may repeat steps2016-2018 to add additional user attributes to the exception. If there are no additional user attributes to add (block2020:N), then the risk manager may save the exception. The risk manager may also add multiple exceptions to a risk management rule under construction. If there are additional exceptions to add (block2024:Y), then the risk manager may repeat steps2014-2022 to add another exception.
• Once the risk manager has added any desired exceptions (block2024:N)—or if there are no exceptions to the risk management rule (block2012:N)—the risk manager may save the new risk violation (block2026). Therisk management module426 may then monitor the access rights provisioned for a user (block2028). If therisk management module426 detects a risk violation, then the risk management module may create a new risk violation review for the detected risk violation (block2030). As described above, theIAM review system228 may present a list of risk management rules that have been violated at a violation review interface630 (FIG. 5H). A violation review interface may identify the risk management rule associated with a pending violation review listed at the violation review interface. A violation review interface may also identify any exceptions that have been added to the risk management rule and whether those exceptions apply. Therisk management module426 may, for example, compare the attribute values selected for the exception to the attribute values of the user associated with the violation review. Therisk management module426 may also determine whether an expiration date for an exception associated with the risk management rule has passed, i.e., when the current date is after the expiration date. A reviewer may then review the risk violation using theaccess review module424 and determine whether any exceptions apply to the risk violation. If the reviewer decides to approve the risk violation, then theaccess review module424 may prompt the reviewer to provide a justification for the approval. The reviewer may, for example, justify the approval of the risk violation by noting the attributes of the user associated with the risk violation match the attributes configured for the risk exception and that the risk exception has not yet expired.
• A risk manager may also, for example, utilize therisk management module426 to express risk associated with resources at a granular permission level. It will be appreciated that in an enterprise-wide computing system some resources may be associated with relatively more risk than other resources. In the banking context, for example, an application capable of moving money between accounts may represent relatively more risk than an application for tracking employee timesheets. Accordingly the application capable of moving money between accounts may be identified as a “high priority” application. User entitlements for “high priority” applications may thus be reviewed frequently. The permissions associated with an application, however, may not all represent the same level of risk. Even in a “high priority” application, some permissions may represent relatively more risk than other permissions. Continuing the previous example, a permission to execute a money transfer may represent relatively more risk than a permission to read customer information associated with the account. Such permissions representing relatively more risk may be similarly identified as “high priority” permissions.
• Therisk management module426 advantageously allows a risk manager to identify “high priority” permissions by indicating which permissions associated with a resource require review as shown above with reference toFIG. 5E andFIG. 5G. Selecting which permissions of a resource require review may be referred to as granular risk expression. Granular risk expression advantageously reduces the number of entitlements that need to be reviewed by the enterprise for effective risk management. Instead of reviewing every entitlement associated with a “high priority” application, reviewers may instead review only those entitlements that represent a relatively high level of risk, e.g., only “high priority” permissions selected as requiring review. In an enterprise-wide computing system having thousands of resources each having dozens of permissions, the total number of user entitlements may be in the hundreds of thousands. This represents potentially hundreds of thousands of access reviews that need to be performed periodically or on-demand. Through granular risk expression, it has been demonstrated that an enterprise may advantageously reduce the number of access reviews to perform by an order of magnitude.
• FIG. 21 illustrates an example workflow between components of theIAM review system228 for expressing granular risk and performing access reviews based on granular risk. InFIG. 22, aflowchart2200 of example method steps for expressing granular risk is shown. A risk manager may navigate to a resource detail interface using theIAM review system228 as described above. The resource detail interface may display a list of resources assigned to the risk manager to supervise (block2202). The risk manager may then select one of the resources (block2204) to display the permissions associated with the selected resource (block2206). The risk manager may then indicate which permissions associated with the selected resource requires review (block2208). TheIAM data store222 may storeresource permission information2102 that includes an indication of whether a resource permission requires review, e.g., a review flag as described above. In this way, a risk manager may manually set the review flag of a permission to aresource210. In some example implementations, however, therisk management module426 may automatically set the review flag for a permission based on a risk level set for that permission. The risk manager may, for example, set a risk level for the resource permission at a resource detail interface, e.g., “1” (low), “2” (medium), or “3” (high). Therisk management module426 may then compare the risk level set for the permission to a risk level threshold (e.g., 2) such that a resource requires review if the risk level for a permission exceeds a risk level threshold. If the risk level set for a permission exceeds the risk level threshold, then therisk management module426 may automatically set the review flag of the permission to indicate the permission requires review. If the risk level set for the permission does not exceed the risk level threshold, then therisk management module426 may automatically set the review flag of the permission to indicate the permission does not require review. The risk manager may also adjust the risk level threshold, and therisk management module426 may reevaluate the respective risk levels of the permissions against the adjusted risk level threshold to determine whether any of the review flags should be update based on the adjusted risk level. Accordingly theresource permission information2102 may additionally or alternatively include respective risk levels that have been selected for resource permissions.
• Therisk management module426 may then obtainentitlement information2104 from the IAM data store222 (block2210) and iterate over a list of entitlements to determine whether any resource permissions associated with the entitlements require review. Therisk management module426 may select an entitlement to review (block2212) and determine whether the resource permission associated with the entitlement requires review (block2214). As noted above a resource permission may require review if a risk manager has indicated review is required or if the risk level for the resource exceeds a risk threshold. If the permission associated with the entitlement requires review (block2214:Y), then therisk management module426 may create an access review2106 for the selected user entitlement (block2216) and assign the access review to a reviewer. If the resource permission does not require review (block2214:N), then therisk management module426 may determine whether there are more user entitlements to evaluate and, if so (block2218:Y), select the next user entitlement for evaluation (block2220).
• The risk management module may also create an entitlement review report2108 that lists permissions that do not require review along with explanation indicating why review of the permission is not required. For example, the entitlement review report2108 may indicate that various resource permissions were not selected as requiring review during granular risk expression or that the respective risk levels associated with the permission do not exceed the risk threshold. If no more user entitlements remain to review (block2218:N), then therisk management module426 may provide the entitlement review report2108 to an administrator for reference during a subsequent period or regulatory review (block2222).
• Therisk management module426 may store information corresponding to the risk management rules and exceptions and information corresponding to the granular risk expression in thedata store414 of theIAM review system228 as riskmanagement rule information418.
6. Access Reviews
• TheIAM review system228 may also improve the access review process within an enterprise. Different types of events may trigger an access review. First enterprises may periodically perform internal access reviews on a regular basis, e.g., bi-monthly, quarterly, yearly, and so forth. Second enterprises may be subject to regulations that require periodic external reviews from regulators. Third risk violations may trigger immediate reviews whenever such risk violations occur. TheIAM review system228 advantageously allows reviewers to leverage previously completed reviews during subsequent access review efforts thereby reducing the number of access reviews to complete. In particular, theIAM review system228 tracks and dates when access reviews are completed such that the enterprise may receive credit for such reviews if still current when a subsequent review is initiated. Access reviews may remain current for a predetermined time period following completion, e.g., a week, a month, ninety days, and so forth.
• As an example, a reviewer may complete a set of user, application, and other resource reviews during a quarterly access review. The following week, regulators may initiate an external regulatory review of the same users, applications, and other resources that were previously reviewed. A reviewer may thus retrieve the access review records for those users, applications, and other resources which indicate they have already been reviewed the previous week. As a result, the reviewer may advantageously avoid repeating such access reviews.
• FIG. 23 illustrates an example workflow between components of theIAM review system228 for leveraging completed access reviews during subsequent review events. InFIG. 24, aflowchart2400 of example method steps for leveraging completed access reviews during subsequent review events is shown. Theaccess review module424 may determine whether an enterprise may get credit for previously completed reviews of access rights during subsequent review events. Stated differently, theaccess review module424 may determine whether previously completed reviews of access rights are accreditable to those access rights during subsequent review event. As described above, a review event may be the start of a new internal review period at the enterprise, an external regulatory review, or a review of access rights in response to detection of a risk violation.
• As described above, an enterprise may periodically perform a set of access reviews (block2402), which may include reviews ofusers216,resources210, or roles defined in theenterprise computing system200. During the access reviews, theIAM review system228 may store access review information416 (block2404), e.g., as access review records at adata store414. Theaccess review information416 may indicate, e.g., whether the access review has been completed, when the access review was performed, the individual that performed the access review, and the type of access review performed (e.g., periodic, regulatory, or risk violation).
• Following completion of a set of access reviews, the enterprise may subsequently encounter a review event (block2406). Upon encountering the review event, theaccess review module424 may select a set of access rights to review (block2408) and retrieve accessright information2302 associated with the selected access rights from the IAM data store222 (block2410). The set of selected access rights may include entitlements users utilize to access theresources210 of the enterprise-wide computing system200. The set of selected access rights may also include entitlements thatresources210 utilize to access other resources of the enterprise-wide computing system200. The set of selected access rights may further include roles defined in the enterprise-wide computing system200. Theaccess review module424 may also receiveaccess review information416 from thedata store414 of theIAM review system228.
• Theaccess review module424 may iterate over the set of selected access rights by selecting one of the access rights (block2414) and comparing the selected access right to theaccess review information416 in order to determine whether an access review has already been completed for the selected access right (block2416). If the selected access right has not yet been reviewed (block2416:N), then theaccess review module424 may create a new access review2304 for the selected access right (block2418) and assign the new access review to a reviewer. If, however, an access review for the selected access right has been completed (block2416:Y), then theaccess review module424 may determine whether the previously completed access review is current (block2420). As noted above, an access review may remain current for a predetermined time period (e.g., 90 days) following completion. If the time period following completion of the access review has not expired, then the access review may be considered to be current. If the time period following completion of the access review has expired, however, then the access review may also be considered as expired, i.e., not current. An expired access review may not be accreditable to an access right during a subsequent review event. If the previously completed access review is not current (block2420:N), then the access review module may create a new access review2304 for the selected entitlement (block2418) and assign the new access review to a reviewer.
• If, however, the previously completed access review is current (block2420:Y), then the access review module may determine that the previously completed access review is accreditable to the selected access right for the current review event and identify the selected access right in a completed access review report2306 (block2422). The completedaccess review report2306 may indicate the date the access review was completed, the event that triggered the completed access review (e.g., periodic, regulatory, or risk violation), and the date of the current review event. If there are more selected access rights to evaluate (block2424:Y), then the access review module may select the next access right in the set of selected access rights for evaluation (block2426). Once each access right in the set of selected entitlements has been compared to the access review information416 (block2424:N), theaccess review module424 may provide the completedaccess review report2306 to a reviewer for use during the review event (block2428). By providing a completedaccess review report2306, a reviewer may advantageously reduce the amount of reviews to complete during subsequent review events by leveraging completed access reviews that are still current.
• Aspects of the disclosure have been described in terms of illustrative embodiments thereof. Numerous other embodiments, implementations, modifications and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps illustrated in the illustrative figures may be performed in other than the recited order, and that one or more steps illustrated may be optional in accordance with aspects of the disclosure.

Claims (20)

What is claimed is:

1. A system for managing risk management rules comprising:

at least one processor;

a rule configuration interface at which a risk management rule is configurable in response to input received at the rule configuration interface wherein the rule configuration interface comprises a list of access rights available for selection; and

memory storing instructions that, when executed by the at least one processor, cause the system to

identify a first access right as a base access right for the risk management rule based on the input received at the rule configuration interface,

identify a second access right as a conflicting access right for the risk management rule based on the input received at the rule configuration interface, and

monitor access rights provisioned at a computing system to determine whether a user is provisioned with both the base access right and the conflicting access right.

2. The system ofclaim 1 wherein:

the instructions, when executed by the at least one processor, further cause the system to

create a violation review associated with the risk management rule responsive to determining that the user has been provisioned with both the base access right and the conflicting access right.

3. The system ofclaim 2 further comprising:

an exception configuration interface at which an exception to the risk management rule is configurable in response to input received at the exception configuration interface.

4. The system ofclaim 3 wherein:

the exception configuration interface comprises a list of attribute values available for selection; and

wherein the instructions, when executed by the at least one processor, further cause the system to associate one of the attribute values with the exception based on the input received.

5. The system ofclaim 4 wherein:

the instructions, when executed by the at least one processor, further cause the system to set an expiration date for the exception in response to the input received at the exception configuration interface.

6. The system ofclaim 3 further comprising:

a violation review interface at which a review decision for the violation review is receivable;

wherein the violation review interface comprises a pending violation review list that identifies the violation review and the risk management rule associated with the violation review; and

wherein the instructions, when executed at the at least one processor, further cause the system to store, at a data store, the review decision received at the violation review interface.

7. The system ofclaim 6 wherein:

the pending violation review list further identifies an exception associated with the risk management rule and whether the exception applies to the risk management rule.

8. The system ofclaim 6 wherein:

the instructions, when executed by the at least one processing unit, further cause the system to,

responsive to determining that the review decision indicates approval of violation of the risk management rule,

prompt for a justification of the approval of the violation of the risk management rule, and

store the justification at the data store with the review decision.

9. The system ofclaim 3 wherein:

the instructions, when executed, further cause the system to

determine whether the exception applies to the risk management rule based on a comparison of an attribute value associated with the exception to a corresponding attribute value of a user associated with the violation review.

10. The system ofclaim 9 wherein:

the instructions, when executed, cause the system to determine whether the exception applies to the risk management rule further based on a comparison of an expiration date set for the exception to a current date.

11. A computer-implemented method for managing risk management rules comprising:

providing a rule configuration interface at which a risk management rule is configurable in response to input received at the rule configuration interface wherein the rule configuration interface comprises a list of access rights available for selection;

identifying a first access right as a base access right for the risk management rule based on the input received at the rule configuration interface;

identifying a second access right as a conflicting access right for the risk management rule based on the input received at the rule configuration interface; and

monitoring access rights provisioned at a computing system to determine whether a user is provisioned with both the base access right and the conflicting access right.

12. The computer-implemented method ofclaim 11 further comprising:

creating a violation review associated with the risk management rule responsive to determining that the user has been provisioned with both the base access right and the conflicting access right.

13. The computer-implemented method ofclaim 12 further comprising:

providing an exception configuration interface at which an exception to the risk management rule is configurable in response to input received at the exception configuration interface wherein the exception configuration interface comprises a list of attribute values available for selection; and

associating one of the attribute values with the exception based on the input received at the exception configuration interface; and

setting an expiration date for the exception based on the input received at the exception configuration interface.

14. The computer-implemented method ofclaim 13 further comprising:

determining whether the exception applies to the risk management rule based on

i) a comparison of the attribute value associated with the exception to a corresponding attribute value of a user associated with the violation review, and

ii) a comparison of the expiration date set for the exception to a current date.

15. The computer-implemented method ofclaim 12 further comprising:

providing a violation review interface at which a review decision for the violation review is receivable wherein the violation review interface comprises a pending violation review list that identifies the violation review and the risk management rule associated with the violation review; and

storing the review decision received at the violation review interface at a data store.

16. The computer-implemented method ofclaim 15 wherein:

the pending violation review list further identifies an exception associated with the risk management rule and whether the exception applies to the risk management rule.

17. The computer-implemented method ofclaim 15 wherein the review decision indicates approval of violation of the risk management rule is approved and further comprising:

responsive to determining that the review decision indicates approval of violation of the risk management rule,

prompting for a justification of the approval of the violation of the risk management rule, and

storing the justification at the data store with the review decision.

18. Non-transitory computer-readable media having instructions, that when executed by a processor of a computing device, cause the computing device to:

selectively provide a plurality of interfaces at a display device in response to input received at the computing device wherein the plurality of interfaces include

i) a rule configuration interface at which a risk management rule is configurable in response to input received at the rule configuration interface wherein the rule configuration interface comprises a list of access rights available for selection,

ii) an exception configuration interface at which an exception to the risk management rule is configurable in response to input received at the exception configuration interface wherein the exception configuration interface comprises a list of attribute values available for selection, and

iii) a violation review interface at which a review decision for a violation review associated with the risk management rule is receivable wherein the violation review interface comprises a pending violation review list that identifies the violation review, the risk management rule associated with the violation review, and the exception to the risk management rule;

identify a first access right as a base access right and a second access right as a conflicting access right for the risk management rule based on the input received at the rule configuration interface;

associate one of the attribute values with the exception based on the input received at the exception configuration interface;

create the violation review responsive to determining that the user has been provisioned with both the base access right and the conflicting access right; and

store, at a data store, the review decision received at the violation review interface.

19. The non-transitory computer-readable media ofclaim 18 wherein:

the rule configuration interface further comprises a plurality of violation severity levels available for selection;

the instructions, when executed by the processor of the computing device, further cause the computing device to

identify one of the violation severity levels as a selected violation severity level for the risk management rule based on the input received at the rule configuration interface; and

the pending violation review list further identifies the selected violation severity level of the risk management rule.

20. The non-transitory computer-readable media ofclaim 19 wherein the instructions, when executed by the processor, further cause the computing device to:

set a due date for the violation review based on the selected violation severity level of the risk management rule.

Images