Security: Why RBAC

Why RBAC?

This Company is making large and complex software systems. Their source code is in the repository. The source can be tagged. From time to time they perform the Production Release (PR) by Deploying the binaries.

The process they need is a repeatable and well-managed workflow.

Team members’ responsibilities are described with well-named roles. To automatize the whole workflow, activities are also well-named and defined as “permissions”.

So how is all that helping? How is the team organized following these realizations? Here is how:  They mandate Role Based Access Control (RBAC) to the company assets. Here is a simplified but true picture.

 

Image Credit: Ron Gutierrez on Quora https://www.quora.com/What-does-the-role-based-access-control-model-mean-in-workforce-management
Three-member team and RBAC
  • RBAC mandates advanced access by assigning a set of permissions associated with roles
  • It supports well-established security principles: the principle of least privilege, the principle of separation of responsibilities, and the principle of data abstraction
    • The principle of least privilege — Limit the number and size of permissions associated with the roles
    • The principle of separation of responsibilities — Assign more than 1 role that is mutually restrained in the process of completing important tasks
    • The principle of data abstraction — It provides a clear separation of the different permissions in terms of the operations that applies to different users.

Different types of users can access different types of access rights (aka “permissions”) to perform their duties based on their job functions and responsibilities.

Naming is hard, thus let us focus, on how we define (name) the Roles and Permissions.

Roles

  • Roles can be named by many criteria, including permissions, responsibilities, cost centers, and business operation processes.
  • User identity cannot determine the role because permissions are tied to roles.
  • Roles are organized around access management and likely not change regardless of activities, identities, functions, etc.

Permissions

  • RBAC implementors should define permissions as names that make use of a set of resources to perform an action on a protected object.
    • The operation of the function module (add, remove, update, edit, review, upload), the access to the menu, a press button on the page
    • In some system designs, functional operations can be regarded as files, categories, menus, page elements, modules, data, fields, etc.

The process of RBAC component naming is answering

  • Who — User or role of the permission
  • What — Resource
  • How — Specific permission

Just add the “When” and you have the Workflow you need.

And now the key discovery

RBAC (implemented and used) is critical to allow security processes and tools to do their jobs

Company resources can be used only through company-secured workstations. Everyone has to log in (to the company workstation ) with a name and password and is given the role (by the system) upon that mandatory login. Thus the security system knows the Who, What, and When, of each activity on the protected resource (source repositories in this case), done on that machine.

But what if suddenly, passwords are not secret anymore?

Mandatory access control (MAC)

With MAC, your ability to do something doesn’t let you share that ability with others.

Two-factor login

A diagram demonstrating two-factor authentication, wherein a user is able to log in with a password and a key sent to their personal device, and an attacker is only able to provide a password and is therefore denied access by the second factor, which is a key.
Passwords can be shared, but hardware security tokens cannot.

You can use 2FA to restrict login to a computer or a service so that only a particular person can do it. And if that person isn’t an admin on the computer, they (supposedly, if the computer is perfectly locked down) won’t be able to share that computer further, not even by sharing their password. Login is mandatory, and sharing the second factor is (supposed to be) impossible.

The legacy, I am responsible for has no RBAC “inside”

You too can design and implement the RBAC system. It is not mandatory to buy one or to refactor the legacy code and legacy data. Build it and deploy it in a container. It is equally functional and useful as any other you thought you have to buy to use it.  That is a key realization for people fighting technical debt, and trying to secure and manage multi-user complex legacy systems.

(none of the diagrams used here are mine. If you tell me who is the author I will promptly publish that information)