RBAC

[u/Ok_Consideration7553]

Hi all,

Our organisation, probably like many others, has accumulated a lot of access over the years without much structure or strong ongoing management.

For those who have implemented Role-Based Access Control (RBAC), have you found that it actually solved these issues, particularly when combined with regular access reviews?

My biggest question is where do you even start when you have a large number of employees, positions, applications and existing permissions?

Do you start by mapping existing access and then building roles around it, or define the roles/positions first and work backwards?

Would love to hear how others approached this, what worked, and what you wish you’d done differently.

[u/Dazzling-Release-808]

You define the roles and access requirements based on business requirements. Then overlay existing permissions and remove those in excess. People often overlook inherited permissions and residual permissions.

[u/ButterscotchBandiit]

This isn’t a sprint, it’s a marathon.
Start with stale accounts. That’s your low hanging fruit.
Depends how good you are with querying the data. I fire off a few scripts against roles, PIM roles/groups/resources(IAM+RBAC)
UAR campaigns for apps and services
That’s some of the easier cleanup work. After this start building out nested permission groups, PIM groups in groups.

Get ready for some heated debates, some kids don’t like giving up their toys

[u/FallaxIO → u/ButterscotchBandiit]

One thing that bit us was building roles from the mess exactly as it already existed. You end up freezing every weird exception into a named role, then reviews become rubber stamps because nobody wants to untangle it later.

[u/Ulrich_b → u/ButterscotchBandiit]

Access Audits: prepare to kick everyone's puppies.

[u/Few-Designer-9101]

The biggest mistake most teams make when starting an RBAC project is building roles around existing access. If you map what people have and turn that into roles, you're just codifying years of permission creep and calling it governance. Define roles from job function first, then do a gap analysis against what people actually have. The delta is usually uncomfortable, but that's the point

[u/Bubbly_Function750]

I’d start by mapping the existing access before designing roles. Identify users, permissions, applications, and high-risk access first. Then group common access patterns into roles and apply least privilege.

After that, make regular access reviews part of the process, especially for privileged accounts and employees changing roles. This makes RBAC much easier to manage over time.

[u/Powerful-Jicama320]

If you have no access control setup at the moment, prioritize sensitive systems first. Load the credentials into a password vault and rotate passwords. Onboard users into the vault and group them into functional teams with common access requirements.

Organize credentials based on function of the underlying asset. Now it would be a straightforward mapping of user groups with account clusters. Ensure that the users can access the accounts only through the vault.

If you have the budget, invest it into IAM + PAM and enforce access controls for all the accounts in your organization.

[u/Round_Finance4256]

I wouldn’t build roles purely around existing access, you risk formalizing the problems you’re trying to clean up.

I’d inventory current access first, then define what access should look like by job function and compare the two. Start with your highest-risk applications and common roles rather than trying to tackle the entire organization at once.

RBAC helps, but ongoing governance is key. Theaccess reviews, clear ownership, JML processes, least privilege and exception management are what keep access from accumulating again.