At this point in the identity management process it is time to consider what access the companyâ€™s job functions should have to begin creating roles and rules. This is the first step in automating provisioning and de-provisioning. Even without automation, creating and managing the roles and rules will make manual provisioning (and auditing!) quite a bit faster and definitely more accurate.
Itâ€™s taken this long to get here for a few reasons:
- The initial user cleanups provided information on whoâ€™s who in the organization, and ensured that unused accounts were eliminated â€“ no sense in role-basing users who arenâ€™t around anymore, right?
- The secondary user cleanups hopefully gave some ideas of what access users have, and provided the baseline data to do the discovery work that weâ€™ll discuss this month.
- The HR work set expectations of whatâ€™s available in the HR system, and also allowed the IDM team and the HR administrators to build a relationship and a common vocabulary. This will help the IDM team to ask questions in the right way, and the HR team to know how to interpret and answer those questions.
In the event the above exercises are still ongoing, I suggest you complete those as much as possible before starting on this one as they build the foundation for continued success.
Ready for roles and rules? Letâ€™s get started!
But first, a little technical accuracy: Enterprise Roles and IT Roles
There are two different levels of roles â€“ enterprise roles and IT roles.
An enterprise role is a high-level entity, like â€œaccounts payable clerk.â€ The enterprise role generally corresponds to the personâ€™s job title and is a larger bucket which contains multiple IT roles. However, since the enterprise role is a construct of identity management, it may not correspond exactly to a job code in the HR system. For example, the HR system may have a job code for â€œfinance analyst,â€ which might contain the enterprise roles â€œaccounts payable clerkâ€ and â€œaccounts receivable clerk.â€ More on this later.
An IT role is the set of permissions assigned to a particular enterprise role on a specific system. So using our previous example, the enterprise role called â€œaccounts payable clerkâ€ might contain all of the following IT roles:
- Email role of â€œstandard email accessâ€
- Internet role of â€œinternet access deniedâ€
- Financial system role of â€œaccounts payable clerkâ€
In many cases, there will only be one IT role on each system that corresponds to an enterprise role, but thatâ€™s not always true. Similarly, multiple enterprise roles can contain the same IT role.
For the purposes of this blog, itâ€™s not necessary to be quite so technically accurate. I will generally use the term â€œroleâ€ to mean enterprise role, and â€œpermissionsâ€ to refer to whatever IT roles may apply. Where better accuracy is needed, Iâ€™ll be specific.
Roles vs. Rules
Rules transcend roles and either help the decision process of who gets what, or they provide caveats. For example:
- All roles in the IT department get â€œstandard email accessâ€ except VPs, who get â€œexecutive email access.â€
- The following Accounts Payable permissions may not be granted if the user is already assigned Accounts Receivable permissions
- Anyone above manager is entitled to â€œinternet access permitted.â€
The bulk of the work is actually in identifying the roles, so that will be the focus of this blog. Rules generally come after the fact, to plug holes and normalize permissions (i.e., theyâ€™re a higher level of maturity).
As with everything else weâ€™ve done to date, this exercise is largely about brute-force effort coupled with some intelligent data analysis. At the end of the day the steps are as follows:
- Identify the enterprise roles (based on a combination of HR data)
- Design and test the IT roles/rules needed by each enterprise role
- Implement new IT roles (or full enterprise roles), and clean up old access
Weâ€™ll continue in the next segment by identifying enterprise roles.