Climbing Mount RBAC: shun the snowy bit
By user12587121 on Aug 10, 2009
There is an image I use that offers an informal way to understand one process for creating roles as part of an Enterprise Role Model (ERM) project. You will probably never capture 100% of your entitlements in your ERM, but you will capture enough to realize significant Return on Investment (ROI) by improvements to business, infrastructure and compliance processes. Presenting it in this way as 'Mount RBAC' is an idea I first saw expressed by Squire Earl in the green pastures of the Sun campus in Austin, Texas.
So here is the image:
Where to start: the bottom
Start with the observation that there are typically small sets of entitlements that most users will receive. Usually this is not hard to identify: for example desktop login and email access. Other candidates at this level would be an entry in and anonymous search access to a corporate white pages directory. Typically this role would be called something like 'BaseAccess' or 'Employee'. This level of the model can be thought of as being linked to the notion of worker type. Typical worker types might be permanent employees, contractors, interns and so on. We can think of these roles as being quite crude: they capture large numbers of users and define vanilla access to standard systems. This approach also obeys the principle of least privilege: we will then go on to add additional entitlements to the user based on a finer grained analysis of his business functions and HR attributes. We can see that this aids automation of the hiring process, for, once a worker is identified with a type we can provision the systems required to get him productive on day one of his job.
Where next: finer grained entitlements
We can proceed with analyzing the HR attributes to uncover further role definitions, linking entitlements to sets of users defined at the large scale in structures like 'Division', continuing down to 'Department' 'and 'JobFunction' or 'JobTitle'. Of course the sets are not necessarily all contained inside one another Russian doll style: other attributes like 'Location' or 'BuildingNumber' or say 'ProjectName' are orthogonal to the pure job function and business activities structures. What we find is that as we move to finer grained analysis it becomes more useful to use tooling to uncover the relationships between entitlements and sets of users. So we can kick start the ERM definition process by _defining_ obvious roles but use a tool based role mining process once we have exhausted the more easily defined roles. Experience here is that efforts that rely solely on the definition approach tend to flounder in the mire of committee like attempts to determine what the roles should be. A better approach at this level of granularity is to let tooling mine out the existing relationships and use those roles as the basis from which to refine further.
Where to stop: the snowy bit
Now one problem projects can run into is 'role explosion'. The problem there is that so many roles are identified that managing those roles starts to be even more costly than managing the original lists of entitlements that we started out with. This is why Mount RBAC has a snowy bit: we recognize up front that there will be aspects of a user's access rights that are exceptional, temporary or otherwise not worth the effort of bringing into the role model. This does not pose an audit or compliance risk because we do track those entitlements even though they lie outside the role model.
If you put your project's Business Analysts, HR, IT people, and middleware software in a giant bucket and shook it for 12 months the chances of a meaningful ERM deployment emerging is pretty low. An alternative is an evolutionary path, each step offering tangible ROI. The refinement process described here where we start with large sets of users and work towards smaller sets with finer grained business roles provides one such approach. At appropriate points you will need to deploy the right tooling--and stop when you start to get cold feet.