RBAC. It's been around a while. Pretty much since access control systems were embedded in to distributed operating systems. It often appears in many different forms, especially at an individual system level, in the form of groups, or role based services, access rules and so on. Ultimately, the main focus is the grouping of people and their permissions, in order to accelerate and simplify user account management.
Enterprise role management has become quite a mature sub-component of identity and access management in the last few years. Specialist vendors developed singularly focused products, that acted as extensions to the provisioning tooling. These products developed features such as role mining, role approval management, segregation of duties analysis, role request management and so on. Their general feature set was that of an 'offline' identity analytics database, that could help identify how users and their permissions could be grouped together, either based on business and functional groupings or system level similarities. Once the roles had been created, they would then be consumed either by a provisioning layer, or via an access request interface. The underlying premise, being that access request management would be simplified due to business friendly representations of the underlying permissions and the account creation and fulfillment process would be accelerated.
The Issues & Implementation Failures
The process of developing an RBAC model was often beset with several problems. IAM encompasses numerous business motives and touch points - which is why many still argue identity management is a business enabler more than a security topic - and developing roles across multiple business units and systems is time consuming and complex. A strong and detailed understanding of the underlying business functions, teams, job titles and processes is required, as well the ability to perform analysis of the required permissions for each functional grouping. Whilst this process is certainly mature and well documented, implementation is still an effort laden task, requiring multiple iterations and sign off, before an optimal model can be released. Once a model is then available for use, it requires continual adaption as systems alter, teams change, job titles get created and so on. Another major issue with RBAC implementation, is the often mistaken view, that all users and all system permissions must be included in such an approach. Like any analytic model, exceptions will exist and they will need managing as such, not necessarily be forced into the RBAC approach.
Speeding up Role Creation
Role creation is often accomplished using mining or engineering tools. These tools take offline data such as human resources and business functional mappings, as well as system account and permissions data. Using that data, the process is to identify groupings at the business level (known as top down mining) as well as identifying similarities at the permissions level (known as bottom up mining). Both processes tend to be iterative in nature, as the results are often inconsistent, with difficulties surrounding agreement on user to functional mapping and of function to permissions mapping.
One of the key ways of speeding up this process, is to use what is known as 'silent migration'. This approach allows roles to be created and used without change to the users underlying permissions set. This instantly removes the need for continual approval and iteration in the initial creation step. The silent migration consists of initially mapping users into their functional grouping. For example, job title, team, department and so on. The second step is to analyse the system permissions for users in each functional grouping only. Any permissions identified across all users in the grouping are applied to the role. No more, no less. With it, no changes are therefor made to the users permissions. This process is simply performing an intersection or each users' permissions.
Focus on the Exceptions
Once the users of each functional grouping have had their permissions migrated into the role, it's now important to identify any user associated permissions that are left over. These can simply be known as exceptions, or permissions of high risk. They're high risk, as they are only assigned to specific individuals and not the group. This association could well be valid - a line manager for example may have different permissions - but as a first pass, they should be reviewed first. To identify which are exceptions, a simple subtraction can be done between the users current permissions (as identified by their target system extract) and the permissions associated with their functional grouping. Anything left needs reviewing.
This approach can also help with the acceleration of access review strategies. Instead of looking to review every user, every permission and every functional grouping, simply analyse anything which is anomalous, either via peer comparison or functional grouping.
RBAC is a complex approach, but can provide value in many access review and access request use cases. It just isn't a catch all, or perhaps approach for every system and user. Specific application using a more simplified approach can reap rewards.
By Simon Moffatt