I have described the foundation for Identity Governance in my post here. Now it's time to use those pieces and make something use full of them.
The very common problem that often still exists (you would think that after so much has been written on the subject already, that people would understand ;-) is that there is a misconception that identity management is provisioning. I visit a lot of clients and they expect me to talk about how to connect to target systems and create accounts in them. Provisioning and reconciliation are important elements of the whole puzzle but are they certainly not enough?
I like to look at identity management system as a living organism. It has a muscles that can do wonderful things. That's provisioning, reconciliation, request and acceptance workflows, you need them to keep organization alive. But as with any organism, you need brains to tell muscles what to do. The brains of identity management is analytical part. These are the process that support roles life cycle, certification processes, SOD (Segregation of Duties). Without them you end up with very nice integrated system that doesn't know what to do and might be insecure.
How so? Ask yourself what is the main reason for Identity Management system? You might want to do automation to speed up certain process. It's true but the main reason most of the time is to manage access to information in secure way. There are principals that we may use to help us like, least privileges or sod.
The first element of governance we have to look at are the roles and their life cycle support. Before we dive into the details it's important to understand what roles are. There are many flavors so which ones are we talking about here? There are IT systems that have roles inside them like database for example (DB Admin role). These are technical roles. We are dealing with business roles. They represent collection of privileges, possibly in multiple applications, assigned to an employee that allows him to perform his job. This collection is usually named after the position that person has like analyst role, marketing manager role. Keep in mind that a person might be acting in few roles depending on the task. This means one might have few business roles assigned to him. For example "Employee role" is something all people working in organization have. This role might contain email access and AD account but financial analyst role is assigned to someone performing such job in addition to being employee.
Every identity management system allows you to create and modify roles but is it enough? Obviously the first step in RBAC (Role Based Access Control) is to create roles. It might be much more complicated than it sounds.
You can do this manually but it can be very challenging especially for larger organization with many applications. Imagine excel with a list of all systems, privileges in those systems, accounts, and all the identities. Now you would have to come up with, what some of those users have in common (same positions , similar accounts and privileges). That's only the beginning. Even if you come up with few roles what happens next year when you have to verify if something changed? How easy would that be in excel?
That's why some vendors provide automated role mining tools to help with role discovery. Such tools allow to run data mining algorithms on your identity information and help you discover possible roles that are hiding in side. When organization goes thought changes you can run those algorithms again and see if there are any modifications to existing roles or new roles.
As convenient as RBAC sounds there is a down side to it. If you don't manage your set of roles properly "role explosion" might happen. You might keep adding new roles as business changes without proper validation and you end up with more roles then employees (I have see it with my own eyes). One of the mechanisms to avoid that is to use role comparison. Such tool can compare roles and provide a hints as to similarities. For example 90% entitlements in Role A and Role B are the same. This might be a candidate to make one role AB and get rid of the 10% entitlements to request and approval workflows. If you perform such validation on regular basis you make sure you don't have unnecessary redundancies.
When you make changes to role you want to know what and when was it changed and be able to roll back to previous state if the new setup goes wrong. This requires versioning and audit. You might also need to keep track of changes for regulatory purposes.
There is one more important aspect to roles that is easily omitted, ownership. Why is it important?
When you have defined a role, once a new person get hired or changes position she will be assigned a role automatically and corresponding accounts and entitlements will follow with no further approval (you can still have approvals with roles but what is the point of having the roles in the first place than?). This means that roles grant access to information. Since all access to information should be governed by business owners (described here) roles should be approved by business owners too. What if the role contains access to information with more than one owner? Naturally such role should be approves by each individual information owner in his or her part.
As a result we have come up with a preferred process of building roles.
Roles allow automation of access assignment process. But when you currently have a mess in your access if you create roles based on it you will just automate the mess and this is not our goal (remember our goal is "least privileges"). I will write about how to deal with this situation in my next post.
Those of you who read my previous post might ask: Ii took us a lot of work to assign risk levels to entitlements, can we use these in roles somehow?That is an excellent question and answer is yes. Once you have defined a role, you can calculate it's risk level based on the highest risk of all entitlements that are included in it. Role risk level is valuable information for business approves or certifies to guide them on to the possible damage a mistake in a role might cause.
As you can see there are many sides to successful RBAC. Very important thing to remember it that role management is a process not a project. This means that you have to constantly review the roles and make changes according to changes in the environment. You have to monitor the quality of the roles and there is a process for it, it's called certification (but that is a story for next post).
The first element of governance we have to look at are the roles and their life cycle support. Before we dive into the details it's important to understand what roles are. There are many flavors so which ones are we talking about here? There are IT systems that have roles inside them like database for example (DB Admin role). These are technical roles. We are dealing with business roles. They represent collection of privileges, possibly in multiple applications, assigned to an employee that allows him to perform his job. This collection is usually named after the position that person has like analyst role, marketing manager role. Keep in mind that a person might be acting in few roles depending on the task. This means one might have few business roles assigned to him. For example "Employee role" is something all people working in organization have. This role might contain email access and AD account but financial analyst role is assigned to someone performing such job in addition to being employee.
Every identity management system allows you to create and modify roles but is it enough? Obviously the first step in RBAC (Role Based Access Control) is to create roles. It might be much more complicated than it sounds.
You can do this manually but it can be very challenging especially for larger organization with many applications. Imagine excel with a list of all systems, privileges in those systems, accounts, and all the identities. Now you would have to come up with, what some of those users have in common (same positions , similar accounts and privileges). That's only the beginning. Even if you come up with few roles what happens next year when you have to verify if something changed? How easy would that be in excel?
That's why some vendors provide automated role mining tools to help with role discovery. Such tools allow to run data mining algorithms on your identity information and help you discover possible roles that are hiding in side. When organization goes thought changes you can run those algorithms again and see if there are any modifications to existing roles or new roles.
As convenient as RBAC sounds there is a down side to it. If you don't manage your set of roles properly "role explosion" might happen. You might keep adding new roles as business changes without proper validation and you end up with more roles then employees (I have see it with my own eyes). One of the mechanisms to avoid that is to use role comparison. Such tool can compare roles and provide a hints as to similarities. For example 90% entitlements in Role A and Role B are the same. This might be a candidate to make one role AB and get rid of the 10% entitlements to request and approval workflows. If you perform such validation on regular basis you make sure you don't have unnecessary redundancies.
When you make changes to role you want to know what and when was it changed and be able to roll back to previous state if the new setup goes wrong. This requires versioning and audit. You might also need to keep track of changes for regulatory purposes.
There is one more important aspect to roles that is easily omitted, ownership. Why is it important?
When you have defined a role, once a new person get hired or changes position she will be assigned a role automatically and corresponding accounts and entitlements will follow with no further approval (you can still have approvals with roles but what is the point of having the roles in the first place than?). This means that roles grant access to information. Since all access to information should be governed by business owners (described here) roles should be approved by business owners too. What if the role contains access to information with more than one owner? Naturally such role should be approves by each individual information owner in his or her part.
As a result we have come up with a preferred process of building roles.
- First we have to gather all identity information in one place.
- Second step is to come up with role candidates using role mining tools.
- And third step is to obtain role approvals from information owners that are part of each individual role.
Roles allow automation of access assignment process. But when you currently have a mess in your access if you create roles based on it you will just automate the mess and this is not our goal (remember our goal is "least privileges"). I will write about how to deal with this situation in my next post.
Those of you who read my previous post might ask: Ii took us a lot of work to assign risk levels to entitlements, can we use these in roles somehow?That is an excellent question and answer is yes. Once you have defined a role, you can calculate it's risk level based on the highest risk of all entitlements that are included in it. Role risk level is valuable information for business approves or certifies to guide them on to the possible damage a mistake in a role might cause.
As you can see there are many sides to successful RBAC. Very important thing to remember it that role management is a process not a project. This means that you have to constantly review the roles and make changes according to changes in the environment. You have to monitor the quality of the roles and there is a process for it, it's called certification (but that is a story for next post).
No comments:
Post a Comment