Zscaler- & Zero Trust-lexicon voor de praktijk · Governance & soevereiniteit

Wat is RBAC?

Definitie

RBAC (Role-Based Access Control, rolgebaseerde toegangscontrole) is een autorisatiemodel dat toegangsrechten koppelt aan rollen in plaats van aan individuele personen. Een rol bundelt de rechten die voor een taak nodig zijn, zoals First Level support of security-analist; gebruikers krijgen hun rechten uitsluitend via de toewijzing van zulke rollen. Dat maakt rechten consistent, navolgbaar en onderhoudbaar: wie van taak wisselt, wisselt van rol, in plaats van individuele rechten te verzamelen. RBAC is daarmee het meest praktische middel om Least Privilege af te dwingen, dus elke persoon en elke dienst alleen de minimaal noodzakelijke rechten te geven.

RBAC in detail

Een RBAC-model bestaat uit drie bouwstenen: gebruikers, rollen en rechten. Rechten hangen aan rollen, gebruikers aan roltoewijzingen; directe individuele rechten voor personen zijn taboe. Daarnaast heeft domain-scoping zich gevestigd: het beperkt bovendien op welk deel van de data een rol werkt, bijvoorbeeld op slechts één locatie, afdeling of tenant. Rechten beantwoorden dan twee vragen: wat mag de rol, en waar geldt dat?

RBAC is af te bakenen van ABAC (Attribute-Based Access Control), dat toegang beslist op basis van attributen en voorwaarden zoals apparaatstatus of locatie. In de praktijk vullen beide elkaar aan: RBAC levert de stabiele basisordening, attribuutgebaseerde voorwaarden verfijnen die situationeel. Het rolmodel is onder meer formeel beschreven in het RBAC-werk van NIST.

Waarom telt RBAC in de Zscaler-praktijk?

Zscaler-beheerconsoles zijn krachtig: wie daar toegang toe heeft, kan beleid voor het hele bedrijf wijzigen. In veel organisaties krijgen helpdeskteams daarom ofwel helemaal geen inzicht, waardoor elk ticket escaleert, ofwel te ruime rechten, waardoor het risico toeneemt. RBAC lost dit dilemma op: lezend inzicht voor de afhandeling van gevallen is een eigen rol, administratief ingrijpen een andere. Zo ziet de First Level wat nodig is voor het geval, zonder iets te kunnen wijzigen.

Ook voor de verantwoording telt het model: NIS2 vereist concepten voor toegangscontrole, DORA beheerste rechtentoekenning in de financiële sector. Een schoon rolmodel met domain-scoping beantwoordt de auditvraag wie waartoe toegang heeft en waarom, rechtstreeks vanuit de structuur, in plaats van te moeten worden gereconstrueerd uit gegroeide individuele rechten.

Veelvoorkomende foutbronnen

RBAC in de praktijk: wat CentaurNexus bijdraagt

CentaurNexus zet RBAC met domain-scoping consequent in voor het Zscaler-beheer: helpdeskrollen krijgen via User Support Center een lezend 360-gradenoverzicht van gebruikers over ZIA, ZPA en ZDX heen, zonder dat Zscaler-beheerdersrechten nodig zijn, en zien daarbij alleen het gebied waarvoor ze verantwoordelijk zijn. Schrijvende acties blijven voorbehouden aan eigen rollen, zijn via het vier-ogen-principe vrij te geven en komen terecht in het append-only bijgehouden audit-spoor. Voor MSP's komt daar Cross-Tenant-Scoping bij: veel klanttenants in één interface, strikt gescheiden. Hoe support zonder beheerdersrechten concreet werkt, laat de gids zien Support Zscaler zonder beheerdersrechten.

Bekijk in de live demo hoe rolgebaseerd inzicht zonder Zscaler-beheerdersrechten werkt.Live demo bekijken

RBAC in de praktijk: waaraan u het herkent

RBAC-tickets klinken allemaal hetzelfde: „Ik heb geen rechten." De oorzaak zit echter bijna nooit alleen in de rol, maar in een van drie plekken.

„Wij hebben dezelfde rol, hij ziet meer dan ik."

Wat het meestal is: Dan verschilt niet de rol, maar het bereik ervan. Dezelfde rol kan naar verschillende tenants, locaties of objectgroepen wijzen.

Hoe u het onderscheidt: Bekijk rol en bereik gescheiden. Wie alleen de rol vergelijkt, vindt geen verschil en zoekt verder op de verkeerde plek.

„De rol klopt, de actie wordt toch geweigerd."

Wat het meestal is: Meestal geldt een tweede voorwaarde: een vier-ogen-vereiste, een schrijfrecht dat voor deze tenant is uitgeschakeld, of een actie die principieel alleen lezend is bedoeld.

Hoe u het onderscheidt: De vraag is niet „mag deze rol dit", maar „is deze actie in deze tenant überhaupt schrijvend bedoeld".

„Na de reorganisatie ontbreken opeens rechten."

Wat het meestal is: De klassieker. Rechten hangen aan groepen, groepen aan de organisatie. Verandert de indeling, dan veranderen de rechten, zonder dat iemand een rol heeft aangeraakt.

Hoe u het onderscheidt: Controleer niet de roltoewijzing, maar het groepslidmaatschap. Daar heeft de wijziging plaatsgevonden.

„Niemand weet meer waarom deze rol dit mag."

Wat het meestal is: Een aanwijzing voor gegroeide rechten. Individuele uitzonderingen blijven bestaan nadat hun aanleiding is verdwenen.

Hoe u het onderscheidt: Dat is een opruimtaak, geen storing. Ze hoort gepland te worden, niet in een ticket afgehandeld.

Rol, bereik en groepslidmaatschap zijn drie verschillende dingen. Worden ze in het ticket op één hoop gegooid, dan kost elk rechtengeval extra navraag.

Verwante begrippen

Audit-spoor Multitenancy EU-datasoevereiniteit NIS2 in de IT-praktijk DORA in de IT-praktijk

Veelgestelde vragen over RBAC

Waar staat RBAC voor?

RBAC staat voor Role-Based Access Control, in het Nederlands rolgebaseerde toegangscontrole. Toegangsrechten worden niet aan individuele personen toegekend, maar gekoppeld aan rollen zoals helpdesk of beheerder; gebruikers krijgen hun rechten via de toewijzing van deze rollen. Dat houdt rechten consistent en controleerbaar en vergemakkelijkt indiensttreding, functiewisseling en uitdiensttreding van medewerkers aanzienlijk.

Wat is het verschil tussen RBAC en ABAC?

RBAC beslist op basis van rollen: wie de rol heeft, heeft de bijbehorende rechten. ABAC beslist op basis van attributen en voorwaarden, zoals apparaatstatus, locatie of tijdstip, en kan daardoor fijnmaziger, maar ook complexer sturen. In de praktijk bewijst de combinatie zich: RBAC als stabiele basisordening, attribuutgebaseerde voorwaarden als situationele verfijning.

Waarom is RBAC zinvol in de Zscaler-praktijk?

Omdat Zscaler-beleid het hele bedrijf raakt, zouden zo min mogelijk personen volledige beheerdersrechten moeten hebben. RBAC maakt het mogelijk lezend inzicht te scheiden van administratief ingrijpen: de helpdesk krijgt zicht op gebruikers- en beleidsstatus voor de afhandeling van gevallen, terwijl wijzigingen voorbehouden blijven aan enkele bevoegden. Dat verlaagt tegelijk risico en escalaties.

Hoeveel rollen heeft een bedrijf nodig?

Zo weinig mogelijk, zoveel als nodig. Een kleine set standaardrollen langs de taken heeft zich bewezen, bijvoorbeeld First Level, Second Level, beheer en audit, aangevuld met enkele beargumenteerde bijzondere rollen. Ontstaat er feitelijk één rol per persoon, dan is het model mislukt en moet het worden geconsolideerd.

Is RBAC een NIS2-vereiste?

NIS2 schrijft geen bepaald model voor, maar vereist concepten voor toegangscontrole en beheerst risicomanagement; bepalend is de betreffende nationale implementatie. RBAC is de gevestigde manier om deze eisen te realiseren en aan te tonen, omdat uit rollen en toewijzingen altijd is af te leiden wie waartoe toegang heeft en waarom.

Informatiebronnen & verder lezen:

Let op: CentaurNexus is een onafhankelijk product van SourcingBlox GmbH en geen aanbod van Zscaler, Inc. Product- en merknamen behoren toe aan hun respectieve eigenaren.