RBAC en ABAC: De toegangscontrolemodellen die je moet kennen

Introductie#

Toegangscontrole is een cruciaal aspect van beveiliging in elk systeem. Het zorgt ervoor dat alleen geautoriseerde gebruikers toegang hebben tot middelen en acties kunnen uitvoeren. Role-based access control (RBAC) en attribute-based access control (ABAC) zijn twee van de meest populaire toegangscontrolemodellen die in moderne systemen worden gebruikt. Beide modellen zijn wijdverspreid en kunnen effectief worden gebruikt om toegangscontrolebeleid af te dwingen. Maar wat zijn ze en hoe verschillen ze?

Role-based access control (RBAC)#

Role-based access control (RBAC) werd voor het eerst geïntroduceerd in de vroege jaren 1990. De formalisering van het model wordt toegeschreven aan David Ferraiolo en Rick Kuhn in een artikel dat in 1992 werd gepubliceerd. Sindsdien is RBAC een van de meest gebruikte toegangscontrolemodellen in de industrie geworden.

In RBAC zijn toegangscontrolebeleid gebaseerd op rollen, die verzamelingen van permissies zijn. Gebruikers worden rollen toegewezen (bijv. beheerder, redacteur, kijker), en hun toegangsrechten worden bepaald door de permissies (bijv. maken, bewerken, verwijderen) voor specifieke middelen (bijv. bestanden, databases, toepassingen). Het vereenvoudigt het beheer van toegangscontrolebeleid door gebruikers te groeperen op basis van hun rollen en permissies aan rollen toe te wijzen. Het is eenvoudig om gebruikers aan rollen toe te voegen of te verwijderen, en de wijzigingen worden automatisch weerspiegeld in het toegangscontrolebeleid.

Belangrijke componenten van RBAC#

• Middel: Een middel is een entiteit waartoe een gebruiker toegang kan hebben. Middelen kunnen van alles zijn, van bestanden, databases, APIs, of elke andere systeementiteit die beschermd moet worden.
• Permissie: Een permissie is een specifieke actie die een gebruiker kan uitvoeren op een middel. Bijvoorbeeld maken, bewerken, verwijderen, bekijken. De definitie van permissies kan variëren afhankelijk van het systeem. In de meeste gevallen worden permissies gedefinieerd op het niveau van het middel met een minimale granulariteit.
• Rol: Een rol is een verzameling permissies die een reeks acties definiëren die een gebruiker kan uitvoeren. Bijvoorbeeld, een beheerdersrol kan permissies hebben om middelen te maken, te bewerken en te verwijderen, terwijl een kijkersrol permissie heeft om middelen te bekijken.
• Gebruiker: Een gebruiker is een entiteit die één of meer rollen kan hebben. Gebruikers krijgen toegang tot middelen op basis van de permissies die aan de rollen zijn gekoppeld.

RBAC-varianten#

Er zijn verschillende varianten van RBAC die het basismodel uitbreiden om aan complexere toegangscontrolerequirements te voldoen:

• RBAC0: Het basismodel waarin gebruikers rollen toegewezen krijgen en rollen permissies toegewezen krijgen.
• RBAC1: Voegt het concept van rolhiërarchieën toe. Rollen kunnen permissies van andere rollen erven. Dit wordt ook wel hiërarchisch RBAC genoemd.
• RBAC2: Voegt beperkingen toe aan rollen. Beperkingen kunnen worden gebruikt om aanvullende voorwaarden te definiëren waaraan moet worden voldaan voordat een gebruiker een rol toegewezen kan krijgen. Dit wordt ook wel constraint-based RBAC genoemd.
• RBAC3: Combineert de kenmerken van RBAC1 en RBAC2. Het ondersteunt zowel rolhiërarchieën als beperkingen.

Voor meer informatie over deze varianten, raadpleeg RBAC-modellen en hun evolutie.

Voordelen van RBAC#

• Eenvoud: RBAC is eenvoudig te begrijpen en te implementeren. Het toewijzen van permissies aan rollen en rollen aan gebruikers is rechttoe rechtaan.
• Efficiëntie: Het vereenvoudigt het beheer van toegangscontrolebeleid door gebruikers te groeperen op basis van hun rollen. Het is eenvoudig om gebruikers aan rollen toe te voegen of te verwijderen zonder het toegangscontrolebeleid te wijzigen. Vooral in grote organisaties met goed gedefinieerde permissiestructuren kan RBAC zeer efficiënt zijn.
• Transparantie: RBAC biedt een duidelijke mapping tussen rollen, permissies en gebruikers. Het is eenvoudig om toegangscontrolebeleid te controleren en te herzien.

Nadelen van RBAC#

• Starheid: RBAC kan star zijn als het gaat om het definiëren van complexe toegangscontrolebeleid. Het is mogelijk niet geschikt voor systemen waar toegangscontrolebeleid dynamischer en contextbewuster moet zijn.
• Granulariteit: RBAC kan de granulariteit missen die nodig is voor fijnmazige toegangscontrole. Het toegangscontrolebeleid is gekoppeld aan goed gedefinieerde rollen, en het kan extra inspanning vergen om permissies op een fijner niveau te definiëren.
• Rol-explosie: In grote organisaties met complexe permissiestructuren kan het aantal rollen exponentieel groeien, wat leidt tot een rol-explosie. Het beheren van een groot aantal rollen kan een uitdaging zijn.

Attribute-based access control (ABAC)#

In de late jaren 2000, toen systemen complexer en dynamischer werden, gingen steeds meer organisaties attribute-based access control (ABAC) als alternatief voor RBAC adopteren. Een belangrijk mijlpaal in de formalisering van ABAC is de publicatie van de NIST Special Publication 800-162 in 2014.

ABAC is een flexibeler toegangscontrolemodel vergeleken met RBAC. Het is een autorisatiemodel dat toegangscontrolebeleid definieert op basis van de attributen van de gebruiker, het middel, de actie en de omgeving. Het stelt organisaties in staat fijnmazige toegangscontrolebeleid te definiëren die zich kunnen aanpassen aan verschillende contexten en omstandigheden.

Belangrijke componenten van ABAC#

• Onderwerp: Een onderwerp is een entiteit die toegang tot een middel aanvraagt. Het kan een gebruiker, een apparaat, een toepassing, of een andere entiteit zijn die toegang tot middelen nodig heeft.
• Middel: Net als in RBAC is een middel een entiteit waartoe een onderwerp toegang kan hebben. Middelen kunnen bestanden, databases, APIs, of elke andere systeementiteit zijn.
• Actie: Een actie is een specifieke operatie die een onderwerp op een middel kan uitvoeren. Het kan creëren, lezen, bijwerken, verwijderen, of elke andere operatie zijn die gecontroleerd moet worden.
• Omgeving: De omgeving is de context waarin het toegangsverzoek wordt gedaan. Het kan attributen bevatten zoals tijd van de dag, locatie, netwerk, apparaat, enz.
• Attribuut: Een attribuut is een kenmerk van een onderwerp, middel, actie, of omgeving. Attributen kunnen van alles zijn, van gebruikersrollen, afdeling, locatie, IP-adres, apparaattype, enz.
• Beleid: Een beleid is een regel die de voorwaarden definieert waaronder toegang wordt toegekend of geweigerd. Beleid is gedefinieerd op basis van de attributen.

Voordelen van ABAC#

• Flexibiliteit: ABAC kan complexe toegangscontrolebeleid accommoderen die gebaseerd zijn op meerdere attributen. Het stelt organisaties in staat fijnmazige beleid te definiëren die zich kunnen aanpassen aan verschillende contexten en omstandigheden.
• Dynamiek: ABAC-beleid kan dynamisch en contextgevoelig zijn. Toegangscontroledoordingen kunnen worden genomen op basis van real-time attributen zoals locatie, tijd van de dag, apparaattype, enz.
• Granulariteit: ABAC biedt fijnmazige toegangscontrole door organisaties in staat te stellen beleid op basis van meerdere attributen te definiëren. In tegenstelling tot het definiëren van rollen en permissies, kunnen attributengebaseerde beleidsregels fijner zijn.

Nadelen van ABAC#

• Complexiteit: ABAC kan complexer zijn om te implementeren en beheren in vergelijking met RBAC. Het definiëren van attributen en beleid kan meer inspanning en expertise vereisen. In tegenstelling tot RBAC, waar rollen en permissies goed gestructureerd zijn, kunnen attributen dynamischer zijn en dus ook de beleidsregels. Het beheren van een groot aantal attributen en beleid in een complex systeem kan een uitdaging zijn. Een gecentraliseerde beleidsgeëvalueerde motor is vaak vereist om de beleidsregels te evalueren.
• Prestaties: Attribuutevaluatie kan invloed hebben op de prestaties, vooral in real-time omgevingen. Beleid op basis van meerdere attributen en real-time condities kunnen latentie introduceren in toegangscontroles.

Vergelijkingstabel#

Uit de vergelijkingstabel blijkt duidelijk dat RBAC het meest geschikt is voor systemen met goed gedefinieerde permissiestructuren en waarbij toegangscontrolebeleid relatief statisch is. Aan de andere kant is ABAC geschikter voor systemen waar toegangscontrolebeleid dynamisch, contextbewust, en fijnmazig moet zijn.

Voorbeelden#

Scenario: Een ziekenhuissysteem dat toegang tot patiëntendossiers voor verschillende personeelsleden moet beheren.

• Personeel: Artsen, Verpleegkundigen, Beheerders
• Middelen: Patiëntendossiers
• Permissies: Lezen, Schrijven, Verwijderen

Case 1#

De toegangscontrolebeleid zijn relatief eenvoudig:

1. Artsen kunnen patiëntendossiers lezen en schrijven.
2. Verpleegkundigen kunnen patiëntendossiers lezen.
3. Beheerders kunnen patiëntendossiers lezen, schrijven en verwijderen.

RBAC-model#

In dit geval is RBAC eenvoudig en effectief. We kunnen rollen definiëren voor artsen, verpleegkundigen en beheerders, en de juiste permissies aan elke rol toewijzen.

De toegangscontrole-evaluatie is eenvoudig:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC-model#

In dit geval kan ABAC overdreven zijn, maar het kan nog steeds worden gebruikt om fijnmazige beleid te definiëren op basis van attributen zoals afdeling, rol, enz.

Attributen:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

Beleid:

• Beleid 1: Toestaan van leesrechten gebaseerd op user.role en resource.name
  • Onderwerp: Gebruiker met rol doctor, nurse, admin
  • Middel: Middel met naam patient-record
  • Actie: read
  • Effect: toestaan
  • Verklaring: "Toestaan van leesrechten op patiëntendossiers voor alle rollen"
• Beleid 2: Bewerken van toegang voor artsen en beheerders
  • Onderwerp: Gebruiker met rol doctor, admin
  • Middel: Middel met naam patient-record
  • Actie: write
  • Effect: toestaan
  • Verklaring: "Toestaan van schrijfrechten op patiëntendossiers voor artsen en beheerders"
• Beleid 3: Verwijderen van toegang voor beheerders
  • Onderwerp: Gebruiker met rol admin
  • Middel: Middel met naam patient-record
  • Actie: delete
  • Effect: toestaan
  • Verklaring: "Toestaan van verwijderrechten op patiëntendossiers voor beheerders"

Voor elk lees/schrijf/verwijderverzoek evalueert de beleidsmotor alle relevante beleid op basis van de attributen en doet een toegangscontroledroging.

Vergelijking#

In dit geval zijn de toegangscontrolebeleid eenvoudig en gestructureerd. Het vereist slechts een enkele niveautoestemmingcontrole om te bepalen of een gebruiker toegang heeft tot een middel. Stel je voor dat het ziekenhuissysteem een complexere structuur heeft met meerdere afdelingen, rollen en permissies:

• In een RBAC-model blijft het evaluatieproces voor toegangscontrole van het patiëntendossiersmiddel eenvoudig en rechttoe rechtaan, ongeacht of de gebruiker de read, write, of delete toestemming heeft;
• ABAC moet daarentegen aanvullende attributen zoals department-id en doctor-id betrekken. Wat als een IoT-apparaat toegang tot de patiëntendossiers nodig heeft? Het zal een nieuw attribuut device-id in de beleidsbeoordeling moeten introduceren. Hoe zit het met het tijdelijk toekennen van de read toestemming aan een coassistent?

Kortom, RBAC is een betere keuze. RBAC is eenvoudig en efficiënt voor systemen met goed gedefinieerde permissiestructuren en waarbij toegangscontrolebeleid statisch is.

Case 2#

Zelfde ziekenhuissysteem, laten we nu een nieuwe rol patiënt en een nieuw attribuut patient-id introduceren.

De toegangscontrolebeleid is:

1. Artsen kunnen patiëntendossiers lezen en schrijven.
2. Verpleegkundigen kunnen patiëntendossiers lezen.
3. Beheerders kunnen patiëntendossiers lezen, schrijven en verwijderen.
4. Patiënten kunnen hun eigen dossiers lezen.

RBAC-model#

In dit geval, naast de oude read toestemming, moeten we een nieuwe toestemming read-own invoeren. We kunnen rollen definiëren voor artsen, verpleegkundigen, beheerders en patiënten, en de juiste permissies aan elke rol toewijzen.

Nu is de toegangscontrole-evaluatie iets complexer, vooral voor de read patiëntendossier-actie:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC-model#

Laten we nu de attributen en beleid in het ABAC-model bijwerken om aan de nieuwe vereisten te voldoen.

Attributen:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

Beleid:

• Beleid 1: Toestaan van leesrechten voor alle patiëntendossiers
  • Onderwerp: Gebruiker met rol doctor, nurse, admin
  • Middel: Middel met naam patient-record
  • Actie: read
  • Effect: toestaan
  • Verklaring: "Toestaan van leesrechten op patiëntendossiers voor alle medewerkers en de patiënt zelf"
• Beleid 2: Toestaan van schrijfrechten voor alle patiëntendossiers voor artsen en beheerders
  • Onderwerp: Gebruiker met rol doctor, admin
  • Middel: Middel met naam patient-record
  • Actie: write
  • Effect: toestaan
  • Verklaring: "Toestaan van schrijfrechten op patiëntendossiers voor artsen en beheerders"
• Beleid 3: Toestaan van verwijderrechten voor alle patiëntendossiers voor beheerders
  • Onderwerp: Gebruiker met rol admin
  • Middel: Middel met naam patient-record
  • Actie: delete
  • Effect: toestaan
  • Verklaring: "Toestaan van verwijderrechten op patiëntendossiers voor beheerders"
• Beleid 4: Toestaan van leesrechten voor eigen patiëntendossiers
  • Onderwerp: Gebruiker met rol patient
  • Middel: Middel met naam patient-record
  • Actie: read
  • Voorwaarde: user.id === resource.patient-id
  • Effect: toestaan
  • Verklaring: "Toestaan van leesrechten op eigen patiëntendossiers"

Vergelijking#

In dit geval zijn de toegangscontrolebeleid complexer en contextbewuster. Het evaluatieproces voor toegangscontrole van het patiëntendossiersmiddel vereist meerdere niveautoestemmingcontroles om te bepalen of een gebruiker toegang heeft tot een middel.

• In een RBAC-model vereist het evaluatieproces voor toegangscontrole van het patiëntendossiersmiddel meerdere niveautoestemmingcontroles om te bepalen of een gebruiker toegang heeft tot een middel. Bijvoorbeeld, om te bepalen of een patiënt toegang heeft tot zijn eigen dossiers, moet het systeem controleren of de gebruiker de read-own toestemming heeft en of de gebruikers-ID overeenkomt met de patiënt-ID.
• In een ABAC-model kan het evaluatieproces voor toegangscontrole eenvoudiger zijn. Het beleid kan worden gedefinieerd op basis van de attributen van de gebruiker, het middel, en de actie. Bijvoorbeeld, om te bepalen of een patiënt toegang heeft tot zijn eigen dossiers, kan de beleidsmotor het beleid evalueren op basis van de gebruikers-ID en de patiënt-ID.

In dit geval kan ABAC beter passen. ABAC is geschikter voor systemen waar toegangscontrolebeleid dynamisch, contextbewust, en fijnmazig moet zijn.

Conclusie#

De keuze tussen RBAC en ABAC hangt af van de specifieke vereisten van het systeem. RBAC is het meest geschikt voor systemen met goed gedefinieerde permissiestructuren en waarbij toegangscontrolebeleid statisch is. ABAC is geschikter voor systemen waar toegangscontrolebeleid dynamisch, contextbewust, en fijnmazig moet zijn. In de praktijk kunnen organisaties ervoor kiezen een combinatie van beide modellen te gebruiken om het gewenste niveau van toegangscontrole te bereiken.