Role Based Access Control

Hyper-granular control of user rights is a nightmare to manage and typically results in nasty things like rights/privilege creep and makes for a lot of unknown in your environments.

So what’s to be done?

One thought is audit hell – track specific access by user to all resources and review very regularly – I don’t know about you but I’ve got enough other stuff that needs to get done during the day that I can’t afford to spend that much time keeping up on individuals.

A much less time-intensive idea is to build roles within your network and then assign users to those roles. Then when a user is re-assigned/quits/is fired all you have to do is move the user to a new role or disable their account (yeah that last part is hopefully all you’d need to do for the first scenario as well).

Why isn’t RBAC used more?

In my experience, it’s because by the time anyone really thinks about it, the existing network/user management process has a massive amount of inertia behind it and it “works well enough” – which is fair from an initial ROI perspective.

The traditional method of building a rights structure as needed has the advantage of minimal upfront cost – no real planning and no real implementation cost. Perfect for a small business that is focused on creating products and getting them out the door.

But assuming the business IT needs grow as the company grows there comes a point where essentially everything has to be rethought/rebuilt – either that or the potential security risks accepted and everyone moves on with life.

My profession is network security so you can guess where I line up.

Ease of Management

Security is often looked at as a drag on productivity within companies – something of a necessary evil.

But my personal belief and approach to how I design controls/systems is that security should be a business enabler. If a system gets compromised because of poor control implementation – that’s a drag on business. If the poor control implementation was due to the overhead of upkeep on the control – that’s another drag.

Simplicity is the key to robustness.

There’s a concept in programming called the “Pit of Success” – ideally when another programmer is sitting down to use your code, the code should be straight forward enough that it’s difficult to get wrong – like purposely jumping into a hole.

I think security should have the same approach.

In theory an RBAC model should help to facilitate this – I say in theory because I’ve never actually seen it implemented. But I’ve got some controls to implement at work and practically speaking now would be a good time to put in work so that an actual attempt at RBAC can be made.

We’ll see how this goes and I’ll pass along lessons learned.

Leave a comment

Your email address will not be published.