I would like to compare current access on accounts with theorical access. For instance, a worker with jobtitle A in department B should only have entitlement C in one application. If the worker account in this application doesn’t match that (missing entitlement or other entitlements found), I would like ISC to tell me that there’s an issue regarding this user.
Is it possible to achieve that out of the box ?
On the other hand, if this is not possible, is there any functionality in ISC that allows us to compare access between what we see on the accounts and what we see on the identities ?
For instance, let’s suppose we have the following :
An identity with a business role that includes entitlement C for one application. The business role, given based on jobtitle and departement, somehow represents theorical access.
An account (correlated to that identity) with entitlement C because of the role, but somehow the account also has entitlement D on this application.
I would like ISC to tell me that the entitlement D is not good because it doesn’t come from the role assignment. But also tell me for instance some entitlements are missing from this same role assignment (if it happens).
Overall, I checked the identity outlier and the access intelligence center but I didn’t find anything that can really answer my needs. The only solution I found so far is to use ISC APIs to get identities and accounts entitlement data and do some comparison. But this approach seems overcomplicated.
For instance, I know of a software named Brainwave GRC that can achieve this out of the box by loading theorical access and current access, and then produce easily some dashboard to find issues immediately.
I very often look at access questions like this in systems. For example, if I am releasing new roles, I want to know how many provisioning events are going to occur before the role is implemented and after the role is implemented I want to make sure that all users got the correct access. Also, after the role is implemented, I may want to make sure that it the users are up-to-date if missing functionality will cause a critical delay. So, I might look for this type of access issue so that I can proactively correct it. Keep in mind that if a user has an entitlement removed that is part of a role in ISC, SailPoint will not correct it until the next time the user has a data change from their authoritative source and the user data is processed (it does not get corrected during the nightly refresh.)
For missing access, look at the Search functionality first. You can search for users that don’t match your criteria. For example, you can find users with a particular job title that don’t have a particular critical entitlement. For example, if I want to find users who are in the Call Center but don’t have the itil entitlement I can use this search:
(attributes.jobTitle:"Call Center Representative" AND NOT @access(name:itil))
or if I want to find users who have one entitlement but not another:
(@access(name:“agent_workspace_user”) AND NOT @access(name:itil))
If I want the information on a regular basis, from the search, I can save the search and create a subscription that can send emails with users that are not correct. I can also turn this into a general policy and setup subscriptions.
As far as the users that have conflicting entitlements, the search options above will work but keep in mind that you also have SoD policies. In an SoD policy, you can create two lists of access that conflict, if a user has entitlement c but should not have entitlement d that would be a violation and can be reported on.
You can review the results manually or you can use the search in a workflow to trigger additional actions such as opening a service desk ticket for the application owner or triggering a certification campaign.
While a business role model is supposed to allow only what users should access, it is not perfect to control everything is alright.
For instance, ISC cannot control what happens in the target application. So if some people directly manage users rights in the application (they shouldn’t but reality shows otherwise), we would need to notice it and fix that.
Or if for some reasons some access are often provided outside business roles, even from an ISC manual access request, it would help us understand that theorical access might not be up to date anymore and that some changes are necessary on the business roles model.
While certifications can help us notice potential issues from time to time, it still relies on users to check and verify and it is not perfect once again : different decisions could be made by different people, at different times regarding the need to keep or remove some rights. We need one unique trustworthy source for theorical access.
Am not sure why theory is required for a business? to make axioms or to propose hypothesis? why there will be conflict with theory and reality in business? Of course AI gives insights
I’ve written a PS script that gets all Roles and their underlying AccessProfiles, then gets all users’ roles and accessProfiles, then runs a comparison of tooMuch & tooLittle access.
It helps to show if people have historic access that hasn’t been provisioned by RBAC
If this is what you are talking about, let me know and I’ll pop the script into here for you.