Identity and Access Management (IAM) historically consists of the three A’s
- Authentication
- What acccount is being accessed?
- Authorization
- Is this account allowed access to this machine?
- Access Control
- What resources are you allowed to use?
Companies spend a lot of time and effort on the Authentication side of the problem. Single signon solutions for web apps, Active Directory for servers (even Unix machines), OAuth for federated access to external resources, 2 Factor for privileged access… there’s a lot of solutions around and many companies know what they should be doing, here.
Well, small caveat… we’re pretty good at centrally managed infrastructure, but there’s a tendancy for application developers to try and introduce their own authentication store because it makes their life easier; keep an eye out for that! It will cause problems down the line; when Harry leaves the company have you found all the places his account may be stored? Do all these places follow your controls around password management? Do they follow properly audited access processes? And so on…
Why do we need RBAC
The problem starts to happen when we look at Authorization and Access Control. There’s a tendency to grant access on an individual basis, so you end up with “Tom can login to Servers 1,2,3,4; Dick can login to Servers 1,2,3; Harry can login to Servers 1,2,4”.
On the face of it, this looks OK… each person has the access they need to do their job, and no more.
But do they? Tom, Dick and Harry are all colleagues; they work together. Tom has called in sick and Dick is covering… except Dick can’t login to Server 4. Oops!
When Fred joins the team, what servers should he have access to? One “work-around” is to copy the access of someone else in the team (who?) but this can still break when the company gets Server 5; who gets access to that?
This problem gets massively worse as the number of servers and number of people grow.
RBAC
There were some hints in the previous section on how this can be solved; we can define roles. “This is the SA team”; “The SA team can login to Servers 1,2,3,4”; “Tom, Dick and Harry are SAs”.
We end up with a simple configuration:
Role Description
Role Members
Role Permissions
When Fred joins the team he gets added to the “SA team” membership and, magically, he has access to the servers he needs.
People can also be in more than one role. This tends to happen when people move roles or have multiple responsibilities; for example some may be a developer for application A and application B; he would be in both of those roles at the same time.
Servers have roles too!
The previous section mentioned “SA team can login to Servers 1,2,3,4”. Imagine we also had “DBA team can login to Servers 1,2,3,4”. When Server 5 comes along we need to work out all these rules and add the server to it.
Instead we can say “This is a Unix Server” “This is a Server for Application A” “This is an Oracle Server”
These are, effectively, roles for servers. So now when Server 5 arrives we can add it to the correct roles based on what it is going to be used for.
Results
Now we can have rules that say things like
"Corporate Unix SAs" "can login to" "All Unix machines"
"Corporate Unix SAs" "can NOT login to" "Application A Machines"
"Application A SAs" "can login to" "Application A Machines"
"Application A Developers" "can login to" "App A Dev machines"
"Oracle DBAs" "can login to" "Oracle servers"
It’s a pretty simple list. We can extend this to access controls on the machine as well; eg
"Application A SAs" "can run as root" "/bin/ls" "on Application A Machines"
Implementation
This is where things get a little harder. From a technology perspective, a role maps quite nicely into a group. In the old Unix days we had Netgroups to control this sort of thing. With Active Directory, security groups. Or you may want to bring in third party tooling to help manage this.
The problem is in defining the roles. And you will get this wrong. Everyone does!
There is a temptation to minimise disruption when going from a disorganised authorisations model to an RBAC one; we can attempt to discover roles, based on actual activity, perhaps role up via the HR database to a consistent manager. Tools exist to try and assist in this data analysis and third party organisations are willing to provide professional services to assist in this (for a fee, of course!).
Alternatively you may want to “start fresh” and build a parallel structure to your existing AAA solution, define the roles and then migrate servers into it (e.g. application by application). This can take more time, but may result in a cleaner structure; we haven’t discovered roles; we’ve defined them.
Either way there’s a transition period and a testing period. You won’t do this in one weekend!
Other benefits of RBAC; auditing!
If you’re in a controlled environment with external audit constraints then a typical question asked is “who can login to your application servers, and why?”
RBAC makes this easier to understand…
- My server is a “Unix machine” - Unix SAs can login to them.
- My server is a “Database server” - DBAs can login to them.
- My server runs Application A in production - AppA support can login to them.
Now we can look into these groups and get the list of people.
If the auditor asks “Why can Harry login this server” we can say “Harry is a Unix SA; Unix SAs can login to my servers”.
It becomes very easy to explain to auditors the who and why. And the results are consistent; there’s no “Why can Tom login to server 4, but Dick can’t?”
Beyond RBAC - ABAC
RBAC is a simple model, but it requires role maintenance. When someone joins the company we need to have him added to roles; when someone changes job we need to verify their new roles; we typically need regular recertification that roles are still accurate.
Attribute Based Access Control (ABAC), on the other hand, grants access based on things we know about.
Tom is based in New York
Tom has job code 12345
Tom is a US Citizen
Tom has passed enhanced vetting
Tom reports to John
...
With ABAC we can write rules based on those things:
People who are based in the USA *AND*
who are US Citizens or Green Card holders *AND*
passed enhanced vetting *AND*
have job code 12345
Can access Unix servers THAT
are running government applications *AND*
are running Oracle
That’s one complicated rule! But now it’s pretty much self-supporting; all the information comes from upstream systems (e.g. the HR database, the CMDB). When Tom changes role, his job code changes and so he automatically loses access. Of course we rely on good data from those upstream systems…
Now very few systems currently support ABAC; they’re group based and thus RBAC. It’s not uncommon to have batch jobs that run regularly and try to build RBAC groups out of ABAC rules. This isn’t as clean as a full ABAC solution, but it allows you to write rules in an ABAC manner while still working with RBAC technologies.
Summary
It’s surprising, to me, how many organisations are still at the “unique access rights” stage. It just makes life hard, and there’s no consistency of access and control.
RBAC requires a management layer to process it properly, but when this has been achieved then it becomes a lot easier to manage and control access in an environment.
Of course, if you only have one security boundary (everyone can access everything) then such a process is just unnecessary overhead!