Approaching RBAC - Where to Start?

Approaching RBAC

    I began my career in IAM (Identity Access Management) working on a large team that solely handled provisioning for a large financial institution.  At the time I didn't know what IAM and IGA were, but I enjoyed my work.  

    Fast Forward almost 7 years and I found myself on in an IT group at another financial institution and an opportunity to start an IAM team arose.  I jumped at the opportunity and became the first and only member of the IAM team.  Over time the team grew, and I went from performing all tasks to working as an analyst.

    In my role I found myself being tasked with implementing RBAC, or Role-Based Access.  Initially it seemed to be an easy enough task, but as I dug in I found there was far more complexity than I initially realized.  There were many challenges, both technical and administrative but I found myself making progress with RBAC.     

    After a few years I found myself moving to another organization, and my primary focus was to be RBAC.  At that time I decided to look back on the work I had completed while building RBAC and noticed a missed opportunity.

    I found that I was mostly focusing on RBAC from a departmental approach.  Specifically, I would review all of the access for a particular department and build a matrix of that access and present it to the department heads.  This was usually met excitement, but I always struggled to move forward with approvals from the department heads.  I also found that when I was working on application-specific RBAC for a newly onboarded application I seemed to have a higher success rate.

    My takeaway from this what that going forward I should try to include more application-specific analysis, especially for departments with access to a lot of applications.  I believe I had been overwhelming some department heads with a huge matrix of information.  Starting with a single app and building from that seemed like it may be a better approach.

    In the last 2 years I have worked at this from both sides and have found that some departments are happy to review a lot of data.  Those departments typically have a better understanding of how their applications are used or have some kind of new-hire checklist that easily translates into building RBAC.  In my recent experience I have had better success at the application level, working with both department heads and application SMEs to define access within a single application.  Fortunately these efforts have largely been project-backed and require approval before moving forward.

I have found that more departments feel that they’re getting more “bang for their buck” if they’re able to complete RBAC for their primary applications.  If a department uses 5 apps, but 4 are only used quarterly they typically want to focus on the 1 app that is used on a daily basis by all members of the team.

    Going forward I plan to continue with this two-pronged approach, but intend to offer a simplified solution of "starting with one app" for departments that may feel overwhelmed when presented with a much larger, multi-app RBAC proposal.

-Lee LeTourneau 10/30/2024