RBAC (Role-Based Access Control)

Role-based access control, or RBAC, grants people rights through the job they do instead of one at a time. An admin defines a role, attaches a set of rights to it, and then puts people into the role. Nobody is granted anything directly. Change what a role can do and every holder changes with it. Move someone between roles and their rights move too. That one extra step is the whole idea, and it is why the model scales where a per-person list does not.

The approach was set out formally by NIST in the early 1990s and later written up as a standard, and NIST's own page on role-based access control still describes the core model. Payments teams meet it through the card rules, not through theory. PCI DSS asks for access limited to what a job needs, and the current wording sits in the PCI Security Standards Council document library. Showing an assessor a clean role map is far easier than showing them 400 single accounts.

Roles, Rights And People

Three things have to be kept apart in your head. A right is a single thing a system allows, such as issuing a refund or exporting a settlement file. A role is a named bundle of rights that matches a real job, and a person is then placed in one or more roles. The bundle is where the thinking goes. A role that mirrors an org chart, and not the work, tends to grow until it means nothing.

Least Access Is The Point

The rule behind all of it is that people get what the job needs and no more. It sounds obvious and it is broken all the time. The usual route is a support role that quietly gains the right to change bank details because one person once needed it. The test worth applying is simple: if this account were taken over tomorrow, what could it do? Anything on that list that the job does not require is a finding waiting to happen, and an assessor is likely to find it before you do.

Duties That Should Not Meet

Some pairs of rights are dangerous together even when each is fine alone. Creating a payee and approving a payout is the classic example, and adding a supplier and then releasing the first payment to them is the same shape wearing different clothes. RBAC deals with this by making the two roles exclusive, so one person cannot hold both. Where headcount makes that awkward, the usual answer is a second approver, not a merged role.

Where Payments Teams Trip Up

Four patterns come up again and again. Roles that grew from a single request and now carry rights nobody remembers granting. A shared login used by a whole team, which destroys any link between an action and a person and makes every log entry useless the moment you need one. Contractors left in a role months after the work ended. And a break-glass account with full rights and no monitoring on it. Each is cheap to guard against and slow to unpick once it is in place.

It Only Works With Identity Underneath

A role is far less effective if the system cannot tell who is using it. That makes user authentication the floor beneath RBAC, and for anything touching money the bar should be higher than a password. Two-factor authentication is the common step up, through a one-time password or a hardware key such as a YubiKey token. Strong roles over a weak sign-in give a false sense of order.

RBAC Beside The Other Controls

Access control is one layer among several and does different work from the rest. A network firewall decides what can reach a system at all. Public key infrastructure decides whether two systems can trust each other. RBAC decides what a person may do once inside. This piece on security layers in modern payment stacks sets out how the layers sit together, and none of them substitutes for another.

Reviewing Roles Without It Becoming Theatre

An annual access review that everyone rubber-stamps can be worse than none, because it creates a record saying the rights were checked. A review that works is short, specific and owned by the manager who knows the job. Give them the role, the people in it, and what it can do, then ask which names should not be there. Removing access on the day someone changes job often matters more than any single review, since a review only catches what the leaver process missed in the first place.

What An Assessor Will Ask For

Expect a request for the role list, who is in each one, evidence that joiners and leavers are dealt with, and proof that the review actually happened. A qualified security assessor wants a control that runs, not a document that exists. Testing the leaver path on purpose, the way you would test any other process during user acceptance testing, is a quick way to know whether it works.

Getting Roles Right From The Start

Write roles around jobs people actually do, not around the org chart. Keep the number small. Someone should be able to hold them all in mind. Name the pairs that should not meet, and enforce the split. Ban shared logins for anything that moves money. Tie role changes to the joiner and leaver process so they happen on the day. Review by manager, not by spreadsheet. And log what roles allow, since a control nobody can evidence counts for little. This piece on managing security across several providers covers the same problem across more than one system.

‍