RBAC

Wat is RBAC?

RBAC (Role-Based Access Control) is een model voor toegangsbeheer waarin gebruikers hun rechten niet rechtstreeks krijgen, maar via een rol die past bij hun functie, zoals operator, onderhoudsmonteur of engineer. U beheert dus toegang per functiegroep in plaats van per persoon. RBAC is het meest gebruikte toegangsmodel in zowel IT als OT en is formeel gestandaardiseerd als ANSI/INCITS 359. In industriële omgevingen bepaalt RBAC wie een HMI mag bedienen, wie setpoints mag wijzigen en wie een PLC-programma mag aanpassen.

🕰️ Waar komt RBAC vandaan?

Het idee van rollen bestond al in mainframes en databases, maar RBAC als formeel model is ontwikkeld bij het Amerikaanse NIST:

Een economische studie van RTI International uit 2010 schatte dat het RBAC-werk van NIST de industrie ongeveer 1,1 miljard dollar had bespaard, vooral door efficiënter beheer van rechten en minder uitval.

🔧 Hoe werkt RBAC?

Het standaardmodel kent vier basiselementen:

• Gebruikers - personen, maar ook serviceaccounts of processen
• Rollen - een functie binnen de organisatie, zoals Operator of OT Engineer
• Rechten (permissions) - toestemming om een bewerking uit te voeren op een object, bijvoorbeeld “setpoint wijzigen” op een regelkring
• Sessies - een gebruiker activeert tijdens een sessie één of meer van zijn rollen

Rechten hangen aan rollen en gebruikers worden lid van rollen. Een gebruiker krijgt toegang dus via de rol, nooit rechtstreeks. Verandert iemand van functie, dan wisselt u alleen de rol; de rechten volgen vanzelf.

🧱 Welke varianten van RBAC zijn er?

ANSI/INCITS 359 deelt RBAC op in vier componenten die op elkaar voortbouwen:

De laatste twee vormen samen constrained RBAC. Functiescheiding (segregation of duties) is ook een aparte maatregel in ISO 27002 (control 5.3).

🔄 Wat is het verschil tussen RBAC, ABAC, DAC en MAC?

RBAC is niet het enige toegangsmodel. ABAC is door NIST beschreven in SP 800-162 (januari 2014) en beslist op basis van attributen van gebruiker, object, actie en omgeving.

In de praktijk worden modellen gecombineerd: RBAC als basis, aangevuld met attributen zoals “alleen vanaf het engineeringstation” of “alleen tijdens een goedgekeurd onderhoudsvenster”.

🏭 Hoe ziet RBAC eruit in een OT-omgeving?

In OT draait RBAC om het beschermen van het fysieke proces. Een typische rolindeling:

Moderne OT-software ondersteunt dit direct. Siemens gebruikt vanaf TIA Portal V19 (S7-1500 vanaf firmware 3.1, S7-1200 vanaf firmware 4.7) User Management & Access Control (UMAC), met rollen en functierechten voor PLC en WinCC Unified. Rockwell Automation doet hetzelfde met FactoryTalk Security. Beide kunnen gebruikers centraal beheren en koppelen aan Active Directory.

🔐 Wat eisen IEC 62443 en andere normen van RBAC?

Binnen de normenreeks IEC 62443 is deel IEC 62443-3-3 het meest expliciet. System requirement SR 2.1 Authorization enforcement eist dat het industriële automatiseringssysteem (control system) de toegekende rechten van alle menselijke gebruikers kan afdwingen, ter ondersteuning van functiescheiding en least privilege. De uitbreidingen zijn per security level verplicht:

Voor afzonderlijke componenten staat dezelfde eis in IEC 62443-4-2 (CR 2.1). Net als andere beveiligingsnormen schrijven ISO 27001 en ISO 27002 RBAC niet letterlijk voor, maar vragen een toegangsbeleid (5.15), beheer van toegangsrechten (5.18) en beperking van bevoorrechte rechten (8.2). RBAC is de gangbaarste manier om daaraan te voldoen. Hetzelfde geldt voor NIS2 artikel 21, dat beleid voor toegangsbeveiliging verplicht stelt, en voor de Cyberbeveiligingswet als Nederlandse uitwerking. Overheidsorganisaties toetsen hun rollen ook aan de BIO.

🛠 Hoe implementeert u RBAC stap voor stap?

Het ontwerpen van rollen heet role engineering. Een beproefde aanpak:

1. Inventariseer functies en taken - welke functies zijn er, en welke taken voeren ze uit op welke systemen?
2. Analyseer bestaande rechten (role mining) - groepeer gebruikers met vergelijkbare rechten en ontdek welke rechten niemand gebruikt.
3. Ontwerp een beperkte set rollen - begin met 4 tot 6 basisrollen per systeem en voeg alleen rollen toe als een taak dat echt vereist.
4. Leg functiescheiding vast - benoem welke rollen elkaar uitsluiten, zoals ontwikkelen en vrijgeven van PLC-code.
5. Automatiseer de toewijzing - koppel rollen aan groepen in Active Directory of een IAM-systeem, zodat in- en uitdienst en functiewissels direct doorwerken.
6. Bescherm bevoorrechte rollen extra - met MFA en PAM voor beheer- en engineeringrollen.
7. Herzie periodiek - controleer rollen en lidmaatschappen in een access review; gangbaar is eens per kwartaal voor bevoorrechte rollen en jaarlijks voor overige rollen, en leg dit vast voor de audit en uw compliance-dossier.

⚠️ Welke valkuilen kent RBAC?

• Rolexplosie - elke uitzondering wordt een nieuwe rol, tot er meer rollen zijn dan gebruikers en niemand het overzicht heeft.
• Rechtenophoping - medewerkers die van functie wisselen, houden hun oude rollen erbij.
• Gedeelde accounts - in OT staat vaak één account “operator” op een HMI. Dan werkt RBAC wel per rol, maar is niet te herleiden wie iets deed; dat ondermijnt logging en onderzoek.
• Te ruime standaardrollen - een “admin”-rol die iedereen krijgt omdat het makkelijk is, maakt het model zinloos.
• Geen noodprocedure - zonder break-glass-account kan een storing ‘s nachts niet worden opgelost; met een slecht beheerd account ontstaat juist een achterdeur.

❓ Veelgestelde vragen

Wat is het verschil tussen RBAC en least privilege?

Least privilege is het principe dat iemand alleen de rechten krijgt die nodig zijn voor zijn taak. RBAC is een model om dat principe uit te voeren: door rollen smal te ontwerpen, krijgt elke gebruiker via zijn rol precies de benodigde rechten.

Is RBAC verplicht onder NIS2?

NIS2 noemt RBAC niet bij naam, maar verplicht organisaties in artikel 21 wel tot beleid voor toegangsbeveiliging. RBAC is in de praktijk de gebruikelijkste manier om dat aantoonbaar te regelen. Een auditor zal vooral willen zien dat rechten op functie zijn gebaseerd en periodiek worden herzien.

Hoeveel rollen heeft een RBAC-model nodig?

Een RBAC-model heeft zo weinig rollen nodig als mogelijk, zolang functiescheiding gewaarborgd blijft. Voor een HMI- of SCADA-omgeving volstaan vaak vier tot zes rollen, zoals operator, supervisor, onderhoud, engineer en beheerder. Groeit het aantal rollen richting het aantal gebruikers, dan is er sprake van rolexplosie.

Wat is rolexplosie bij RBAC?

Rolexplosie ontstaat wanneer een organisatie voor elke uitzondering een nieuwe rol aanmaakt, waardoor er honderden overlappende rollen ontstaan. Het RBAC-model wordt dan onoverzichtelijk en lastig te auditen. Oplossingen zijn het opschonen via role mining en het gebruiken van attributen (ABAC) voor uitzonderingen.

Kan RBAC worden gebruikt op PLC’s?

Ja, moderne PLC’s en engineeringsoftware ondersteunen RBAC, bijvoorbeeld Siemens S7-1500 met UMAC in TIA Portal en Rockwell met FactoryTalk Security. Oudere PLC’s kennen vaak alleen een wachtwoord per toegangsniveau. Daar dwingt u RBAC af op het engineeringstation en de jump server daarvoor.

Wat is het verschil tussen RBAC en ABAC?

RBAC beslist over toegang op basis van de rol van een gebruiker, ABAC op basis van meerdere attributen zoals tijd, locatie en apparaat. RBAC is eenvoudiger te beheren en te auditen, ABAC is flexibeler. Veel organisaties combineren beide: RBAC als basis en ABAC voor contextregels.

📌 Samengevat

RBAC regelt toegang op basis van functie of rol, niet per individu: eenvoudig te beheren, schaalbaar en goed te auditen. In OT is RBAC volgens IEC 62443-3-3 SR 2.1 een kerneis vanaf security level 2. Houd het aantal rollen klein, leg functiescheiding vast en herzie rollen periodiek, dan ondersteunt RBAC ook uw naleving van ISO 27001 en NIS2.