RBAC (Role-Based Access Control)

What is RBAC (Role-Based Access Control)?

RBAC is access control organised around roles. You attach permissions to a role, then give people the role. Nobody receives permissions directly, so access follows what someone does for a living instead of a list kept per person.

A new accountant joins and you add them to the finance role. That role already grants read access to invoices, payment reports and export files, so the new hire can work on day one without anyone handing out those rights one by one. When they change teams, you swap the role. When they leave, you remove it. The permissions never travel with the person.

That separation is the point of the model. Permissions change rarely, but people and job functions change constantly. RBAC lets you manage the stable thing, what a role may do, apart from the volatile thing, who currently holds it.

The NIST model: roles, hierarchies and separation of duties

The reference model most tools follow is the NIST standard, published as ANSI/INCITS 359 (first ratified in 2004 and revised in 2012). It names four building blocks: users, roles, permissions and the assignments that connect them. A permission is the right to perform an operation on an object, such as reading a table or deleting a report.

Two ideas from that model turn up everywhere in practice. The first is the role hierarchy. Roles sit in a senior-to-junior order, and a senior role inherits everything its junior roles can do. A 'senior analyst' role can carry every permission of the 'analyst' role plus a few extra, so you describe the difference once rather than re-listing the shared permissions.

The second is separation of duties, a constraint that stops one person from holding a dangerous combination of roles. Static separation blocks the assignment itself: the colleague who creates a supplier payment cannot also be given the role that approves it. Dynamic separation is softer and works per session, letting someone hold two sensitive roles but not use both at once. Both exist so that fraud needs two people rather than one.

RBAC in a Microsoft Fabric workspace

If you work in Power BI or Microsoft Fabric, you already use RBAC every day. A Fabric workspace has four built-in roles, and each one is a fixed bundle of permissions:

• Viewer. Can open and read everything in the workspace but change nothing. This is the role for people who only consume reports.

• Contributor. Can create and edit items such as reports, notebooks and pipelines, on top of everything a viewer can do.

• Member. Everything a contributor has, plus the right to share content and add other people to the workspace.

• Admin. Full control, including managing permissions, adding other admins and deleting the workspace.

You rarely assign these to individuals. You put a security group or Microsoft 365 group into a role and manage membership in the group instead. A finance team lands in the Viewer role on the reporting workspace, the two analysts who build the reports get Contributor, and the BI lead gets Member. If a person sits in several groups, Fabric gives them the highest permission any of those roles grants.

Role explosion and the case for ABAC

RBAC stays clean while roles map neatly onto job functions. It strains when access has to depend on fine detail. The moment one team needs the Belgian records only, another a single project, and a third only during month-end close, a single 'analyst' role can no longer express it. You start minting 'analyst-BE', 'analyst-project-x' and 'analyst-month-end', and dozens of near-identical variants follow. This is role explosion: roles multiply faster than anyone can audit, and the model meant to simplify access becomes the thing nobody fully understands.

Role explosion is the usual reason teams look at ABAC (attribute-based access control), which decides access from attributes rather than from a fixed role. The trade is manageability against expressiveness: RBAC is easy to reason about and audit when job functions are stable, while ABAC handles conditional, context-dependent access at the cost of policies that are harder to follow. Plenty of real systems run both, roles for the coarse decision and attributes for the fine one.

What to watch out for with RBAC

RBAC is a coarse gate. In a data platform it usually decides whether you reach a workspace, a semantic model or a lakehouse at all. Finer controls sit inside that gate: row level security filters which rows of a dataset a person sees, and object level security hides whole tables or columns. Getting you into the room is RBAC's job; deciding what you see once you are inside is theirs.

A few habits keep an RBAC setup healthy and make it a dependable base for data governance:

• Keep roles to least privilege. A role should grant exactly what the task needs and nothing held back 'just in case'. A role that makes everyone an admin is still RBAC, but it throws away the reason you adopted it.

• Watch permission build-up. People collect group memberships over the years and quietly gather access nobody signed off on. Review who holds which role on a fixed schedule.

• Bind roles to groups, not people. Managing access through security groups keeps every joiner and leaver a one-line change and keeps the audit trail readable.