Last time we discussed how to drive Least Privilege by automatically expiring access and by eliminating generic accounts. To this point, the four approaches we've discussed are pretty low-effort. Today we'll talk about some higher-effort approaches that are especially popular in bigger businesses but can be cheap and easy. Let's get started.
Role Based Access Control
Here’s a wild idea: what if you organized your staff, figured out what access each role needs, then gave people access based on the role they serve?
To some of you, this sounds like the most obvious idea and you’re probably already doing it. To others, this sounds like a massive pain even after the project is finished. You’re both right, and Role Based Access Control (RBAC) is a divisive topic on identity teams. I’ll speak to each perspective in turn:
To Those Who Find It Obvious
RBAC is the identity equivalent of arranging your tools tidily with little cutouts to show where each goes. It appeals to people who like things in their place, those who can’t stand messiness.
In general, this Everything-In-Its-Place strategy can yield huge efficiency gains throughout a business. Toyota even codified it and named it 5S, which is now a foundational technique taught to 6Sigma Green Belts.
The risk lies in overapplying it. Organizing and building these systems takes time and preparation. In a system that doesn’t change frequently, that effort provides good value. If your system is temporary, the loss of agility from setting up an organized system may not be worth it.
Consider: a plumber may organize her truck so that she can quickly get exactly the tools and parts she needs. Not only is she faster because she doesn’t have to search for them, but the time for each job is more predictable and consistent. She is more profitable.
However, when she’s on a job replacing a toilet, she doesn’t choose optimal places for each tool and tape them out: one job takes an hour and organizing her workspace around that busted toilet would take 20 minutes. Not profitable.
RBAC makes most sense for cut-and-dried access that doesn’t change much. Your sales team may need read-only access to parts of your ERP, and your Distribution, Accounting, and Manufacturing teams may need read and write access to their parts, and each kind of access won’t warrant change for years.
On the other hand, RBAC is a terrible idea for temporary or adhoc access. A project team working on a new product or a bid doesn’t make sense to codify into roles – the access won’t be needed after the project is complete.
It will be tempting for people with organizing personalities to put everything in its place in an adhoc or quickly-changing environment. Resist this urge and rely on other techniques to deliver least-privilege.
To Those Who Think This Will Be a Pain
The world is full of failed attempts to organize things. Most of the failures attempt to shoehorn everyone’s needs into some standard set and treat them all the same. What’s worse, the needs change, and even if the original system worked, it quickly gets out of date. Organizers never seem to appreciate the effort that must be continually applied to keep a system delivering the original promised value.
A badly organized system can be worse than no organization at all.
Creating roles may be easy enough, but what about the effort to adjust when a manager leaves and their team’s role splits? Do you really expect to re-assess and create two new roles right when the team is in turmoil and figuring out new ways of doing things? What if a service loses its biggest customer, so you have to let 2/3 of the team go and roll them into a new group that also does other things? Do you rebuild the roles to cover the new team or just leave the access with a smaller sub-team?
Things change and defining access more tightly means you have to adjust them more frequently. Often people underestimate the long-term cost of maintaining the systems they build.
But consider the alternative: If your business mostly provides access adhoc, requests will be common. Your teams will overshare, either blindly clicking “accept” on any access request, or provisioning access to everyone at once to save time. If you have anything worth stealing, any account can be used to steal it.
Even with its warts, being organized is still worth it. If access is complicated and frequently used, you can avoid a lot of wasted time by figuring out what’s needed, then delivering it consistently.
The best way to prevent an organization system from going out of date is to reduce the barrier to change. If people believe it will take 5 hours to adjust access, they will put it off until they waste that much time per month. If people believe it takes 5 minutes, they won’t hesitate at all. Making things easier to change encourages improvement. It’s perfectly possible to do RBAC with no extra tech and limit your cost of change to 5 minutes. Adjusting access to fit those roles will take longer and may be worth tech, depending on your system. We discuss some easy ways to do this in other articles.
The next best fix is to decentralize the maintenance. Your accounting manager will understand what kind of access their team needs better than anyone else – assign him with the responsibility of defining his teams roles and adjusting as needed. You may need some light oversight and education to ensure those leaders take the responsibility seriously. If you’re at a larger organization, you can even gamify their performance.
The final fix is to avoid being over-proscriptive. Organizing roles to the exact set of access required requires frequent adjustment. Remember the goal: to substantially reduce the amount of damage that the average account can do. Granularly defining access gets diminishing returns on this goal. Choose a middle ground that your teams won’t resent in 6 months.
RBAC final thoughts
Often applications will be designed for either adhoc access or for role-based access, and help you manage access. Almost every RBAC-designed system will be built to automate some specific kind of work, so you see more and more of them at larger companies where the teams become big enough to warrant their own automation and workflow systems. While adhoc systems can be built to provide some access in an RBAC model, it almost never works to do adhoc access in a RBAC system. If someone needs adhoc access to some information in an RBAC system, copy it to an adhoc system and grant them access through that. Some examples:
Adhoc systems
Gsuite
Microsoft 365
fileshares (dropbox, box.com, etc)
CRMs
RBAC systems
Customer Service/ticketing
IT Management
Case Management
ERP/MRP
Finance: GL, Accounts Payable, Accounts Receivable
Segregation of Duties (SoD)
Originally codified by financial auditors to prevent employees from writing themselves fat checks out of the company account, this technique boils down to: “Make sure that no one person can invisibly do things that would really hurt the company.” There are piles of scenario-specific techniques; Wikipedia has more written on this than you could read in a week.
It’s not worth your time to learn about each. Instead, consider what kinds of actions could really hurt your business, and then figure out how to re-jigger them so that they take two people. Most strategies also use some tiering to involve higher-ranked people in higher-risk activities. Some examples actions that often warrant SoD are:
· Reimbursing employees
· Paying vendors
· Creating employees in payroll
· Managing inventory
· Committing code
· Granting access to secrets
· Signing contracts
Often SoD can be partially achieved by creating alerts for medium-risk actions. While it doesn't provide the full protection of another person being involved in the process, notifying someone can help detect or even deter malicious activity.
Often RBAC can be a great mechanism for ensuring that the SoD rules you designed are followed.
Comments