A
long time ago I wrote the following statement on my LinkedIn profile:
"RBAC is EOL". And in my not so youthful
overconfidence I mentioned this during an intake with a potential
customer, who asked me how they could introduce Role Based Access Control (RBAC) as conveniently
as possible. That talk never materialized into an assignment…
‘RBAC
is EOL’ clearly was a premature statement. I must admit Role Based
Access Control is far from End-Of-Life. Rather, in practice, we see
RBAC becoming more popular and we see more and more organizations
starting RBAC projects. Following on the heels of financials and
government, other industries are becoming aware of the need to
address authorization management. IAM projects and RBAC solutions are
increasingly embraced and most of the major information systems, such
as SAP, Oracle EBS, CODA, EPIC, Salesforce, Chipsoft, have been built
in such a way that RBAC is the de facto authorization model. RBAC is
a well-known, but not well understood, way to think about
authorizations and access control. Surely I can help customers with
that, of course ;)
Why
on earth do we use RBAC?
RBAC
promises to be a simple access control model, but it’s very
difficult in theory, here’s a link to the original NIST
publication: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf
But also in real life RBAC is very complex. Let me explain why RBAC should be EOL.
First
let me explain why we use RBAC: Ease of operation.
Yes,
really, that's really the only reason that we use RBAC. It is an easy
understandable method to grant access to read a file, a record or to
allow access to a location for a person. It’s also easy to control
access: you can find out if a person has access, you may well be able
to explain why that is the case and whether the granted access is
correct.
Because
of use of the concept of a 'role', we can disconnect an
'authorization' from a 'someone'. That saves a lot of administration.
If two employees have to perform the same tasks, they need to have
the same authorizations. If we give both persons the same ‘role’,
then they have the same permissions, at least if the permissions that
are required for execution of those tasks are bound to that same
role. If someone else is assigned the same role, that person will
also get the same permissions. So it's really a lot easier to grant
permission by assigning roles than to provide the individual
authorizations to everyone separately. We start having problems when
there are roles within roles, nested roles: In that case it’s
getting foggy what authorizations a person effectively has. The best
thing about direct assignment of authorizations is that it’s much
easier to show what permissions someone has effectively. You can tell
right away after all. Not that we gain much insight because after
all, we still have to interpret all these granted permissions once
again for every individual assignment of authorizations. Role
management does make life easier.
But
by just managing roles we’re not done yet. On the contrary. There
is not one single type of role, there are different kinds of roles
and different levels of roles and of course there are nested roles.
There are roles in an organization and there are roles in
applications. No, these are not the same!
There
are lots of roles in an organization. And there are also positions in
an organization. Positions in an organization result in a view of an
organization for providing a wage to employees and it a position is
created in the hierarchy of an organization. But roles are a view on
combined activities within an organization, our way of organizing
authorizations. It may look like a position, but it is not.
And
here the difficulties start. Is there a relation between a position
and a role. Is there a hierarchy? Can people have more than one
position and more than one role? Can roles be shared between
departments? And do all identical positions result in the identical
roles? So, as you can see, the easy concept is getting a bit less
easy.
In
RBAC, roles are assigned in order to grant authorizations to perform
certain tasks. Roles are in fact a set of tasks carried out by a
person. A credit manager uses the financial system (the debt
management part of course), Office365 (the share of his or her
department perhaps?), the intranet, perhaps a module in a CRM system.
In addition, a credit manager must have access to the sales
administration, e-banking environment, the general ledger. But there
are other roles with overlapping authorizations, roles for people
that have an almost similar set of applications, but with different
access within. That means that an authorization cannot be related to
a single person. Here the perceived advantage of RBAC disappears.
Tasks
Now,
who decides which tasks our staff with the role credit management has
to execute? The hierarchical manager of our employee. And perhaps
there’s also a process owner. But these managers have a different
focus… the line manager obviously wants optimal performance within
his department, but the process owner has different requirements,
such as competent, capable and high-quality staff and separation of
duties within the process. This can result in conflicting interests.
A line manager wants to perform as many operations with a full
occupancy, but the process owner wants a high-quality high governance
process.
However,
there is still another important player: the system owner. The line
manager may well want an employee to perform various tasks, but that
collection of tasks should be supported in the information system in
the same way. What if the role model developed in an information
system conflicts with the organization roles and process roles? This
is not a theoretical issue, this happens every day in every
organization.
Authorizations
Last
but not least: what effective authorizations are there in a role?
Employees in AGSAPAX-IAM-DEB-Linux-WS seems to get access to
GRXACZP-LEDG02Q-File Transfer-RW. Is this? Who knows if this access
rule (the kind you see in a lot of Excel sheets) is permitted? And is
this authorization granted explicitly or implicitly? Who's in that
group? Is that correct? Is that authorization still accurate and up
to date? Is the authorization not too broad? How much do these rights
cost? Who granted such access rights? Who linked these authorizations
to the role? Has this been approved?
In
my experience there are dozens more of these question. And they all
lead to the same conclusion: the RBAC model may look like a practical
access management method, but it is not. There are so many
complications that have to be managed, that it’s hard to be in
control.
Done
with complaining. What are we going to do about it?
In
part 2 in this series we start migrating from roles to attributes, my holy grail
and I’ll introduce a hybrid ABAC
model.
(this blog first appeared in Dutch at https://www.cqure.nl/kennisplatform/van-rbac-naar-abac-deel-1)
