RBAC Roles vs Business functions

I am sure that this question was asked a lot of times before. I have been searching on the internet for many days, but everytime I am getting more and more confused. I've read the 359-2012 standard and also books, but still.

What really is a role for RBAC? I have seen a lot of confusion where people tend to name as roles the business role that a user may have e.g. Security Analyst or HR Assistant. To my understanding this is not the role. The role is something that makes sense in a system. For example, I am an InfoSec Analyst, this is my business role. For RBAC, my roles will be assigned on a per system case. I.e. in a database I may have the role of Database_Admin, in another system I may have the role of System_User, in a CRM I may be CRM_PowerUser, to access files on the FTP server I may hold the role of FTP_ReadOnly. So, I have multiple roles, that are system/application/resource specific.

On the business side we can say that I am an InfoSec Analyst which is a security department employee which is also a general employee. Each one "inherits" the one before it. Each of these business roles give access to systems/applications/resources.

To summarise, I have business functions of InfoSec Analyst -> Security employee -> general employee and each one of these business functions give me access to specific roles (as mentioned above).

Does this make sense? Am I understanding something wrong?

Solution

When I implemented an RBAC-system, each user could be assigned multiple roles.

This is nice, because ...

Subject-Roles:

Peter +---- Company3000-Employee
      |
      +---- London-Department
      |
      +---- CoreSystem-Backend-Developer

That way, you don't have to cherry pick each and every permission for each and every user.

Then, a role could inherit multiple roles. This is nice, because ...

Role-Roles:

London-Department +---- London-Visitor
                  |
                  +---- London-Permament +---- London-Temporary

That way, you can group related permission groups. Here, London-Permament derives all rights from London-Temporary (e.g. using the Main Entrance for exit AND entry, whereby a visitor should only be able to exit, but not entry alone).

Finally, you have Role-Permissions:

Role-Permissions:

London-Visitor +---- [permitted to exit building]

London-Permanent +-- [permitted to use parking deck]
                 |
                 +-- Longon-Temporary -- [permitted to enter building]

It's a matter of taste and requirement how deep you want to nest it all. E.g., you could also model it so that London-Temporary derives from London-Visitor (though this would impede limits when temporarily revoking entry-access to only visitors, e.g. in chemical factories, when only visitors should be forbidden to enter).

In this example, Job is separated from Location, and they are both separated from the hierarchy ladder. This makes sense:

- Peter should have access to his documents in his cloud-storage, never mind _where_ he is physically.
- Peter should not be able to just enter a Company3000 office in Germany without being handed a pass.

And so on.

The whole system can become complex, but it allows to rather accurately model the requirements of most companies. For small companies, it is probably way over the requirements.

This basically is my interpretation/implementation of RBAC. It supports only additive rights, e.g. inheritance always adds permissions, but does not remove any.

It also does not include constrained RBAC, i.e. separation of duties; e.g. atomic war buttons that require two person's keys.