RBAC och ABAC: De åtkomstkontrollmodeller du bör känna till

Introduktion#

Åtkomstkontroll är en kritisk aspekt av säkerhet i alla system. Det säkerställer att endast auktoriserade användare kan komma åt resurser och utföra åtgärder. Rollbaserad åtkomstkontroll (RBAC) och attributbaserad åtkomstkontroll (ABAC) är två av de mest populära åtkomstkontrollmodellerna som används i moderna system. Båda modellerna är allmänt antagna och kan användas för att effektivt genomdriva åtkomstkontrollpolicys. Men vad är de och hur skiljer de sig?

Rollbaserad åtkomstkontroll (RBAC)#

Rollbaserad åtkomstkontroll (RBAC) introducerades först i början av 1990-talet. Formaliseringen av modellen tillskrivs David Ferraiolo och Rick Kuhn i ett papper publicerat 1992. Sedan dess har RBAC blivit en av de mest använda åtkomstkontrollmodellerna i branschen.

I RBAC är åtkomstkontrollpolicys baserade på roller, som är samlingar av rättigheter. Användare tilldelas roller (t.ex. administratör, redaktör, tittare), och deras åtkomsträttigheter bestäms av rättigheterna (t.ex. skapa, redigera, radera) för specifika resurser (t.ex. filer, databaser, applikationer). Det förenklar hanteringen av åtkomstkontrollpolicys genom att gruppera användare baserat på deras roller och tilldela rättigheter till roller. Det är enkelt att lägga till eller ta bort användare från roller, och ändringarna kommer automatiskt att återspeglas i åtkomstkontrollpolicys.

Nyckelkomponenter av RBAC#

• Resurs: En resurs är en enhet som en användare kan komma åt. Resurser kan vara allt från filer, databaser, API:er eller någon annan systemenhet som behöver skyddas.
• Rättighet: En rättighet är en specifik åtgärd som en användare kan utföra på en resurs. Till exempel, skapa, redigera, radera, visa. Definitionen av rättigheter kan variera beroende på systemet. I de flesta fall definieras rättigheter på resursnivå med en minimal finkornighet.
• Roll: En roll är en samling av rättigheter som definierar en uppsättning åtgärder som en användare kan utföra. Till exempel, en administratörsroll kan ha rättigheter att skapa, redigera och radera resurser, medan en tittarroll kan ha rättighet att visa resurser.
• Användare: En användare är en enhet som kan tilldelas en eller flera roller. Användare beviljas åtkomst till resurser baserat på de rättigheter som är associerade med de roller de är tilldelade.

RBAC-varianter#

Det finns flera varianter av RBAC som utökar den grundläggande modellen för att tillgodose mer komplexa åtkomstkontrollkrav:

• RBAC0: Den grundläggande modellen där användare tilldelas roller och roller tilldelas rättigheter.
• RBAC1: Lägger till konceptet rollhierarkier. Roller kan ärva rättigheter från andra roller. Det är också känt som hierarkisk RBAC.
• RBAC2: Lägger till begränsningar för roller. Begränsningar kan användas för att definiera ytterligare villkor som måste uppfyllas för att en användare ska kunna tilldelas en roll. Det är också känt som begränsningsbaserad RBAC.
• RBAC3: Kombinerar funktionerna i RBAC1 och RBAC2. Det stöder både rollhierarkier och begränsningar.

För mer information om dessa varianter, se RBAC-modeller och deras utveckling.

Fördelar med RBAC#

• Enkelhet: RBAC är lätt att förstå och implementera. Att tilldela rättigheter till roller och roller till användare är enkelt.
• Effektivitet: Det förenklar hanteringen av åtkomstkontrollpolicys genom att gruppera användare baserat på deras roller. Det är enkelt att lägga till eller ta bort användare från roller utan att ändra åtkomstkontrollpolicys. Särskilt i stora organisationer med väldefinierade rättighetsstrukturer kan RBAC vara mycket effektivt.
• Transparens: RBAC ger en tydlig kartläggning mellan roller, rättigheter och användare. Det är enkelt att granska och granska åtkomstkontrollpolicys.

Nackdelar med RBAC#

• Styvhet: RBAC kan vara stel när det gäller att definiera komplexa åtkomstkontrollpolicys. Det kan inte vara lämpligt för system där åtkomstkontrollpolicys behöver vara mer dynamiska och kontextmedvetna.
• Finkornighet: RBAC kan sakna den finkornighet som krävs för finkornig åtkomstkontroll. Åtkomstkontrollpolicys är bundna till väldefinierade roller, och det kan kräva extra ansträngning för att definiera rättigheter på en mer detaljerad nivå.
• Rollexplosion: I stora organisationer med komplexa rättighetsstrukturer kan antalet roller växa exponentiellt, vilket leder till en exploderande mängd roller. Att hantera ett stort antal roller kan vara utmanande.

Attributbaserad åtkomstkontroll (ABAC)#

I slutet av 2000-talet, när system blev mer komplexa och dynamiska, började fler och fler organisationer att anta attributbaserad åtkomstkontroll (ABAC) som ett alternativ till RBAC. En anmärkningsvärd milstolpe i formaliseringen av ABAC är publiceringen av NIST Special Publication 800-162 2014.

ABAC är en mer flexibel åtkomstkontrollmodell jämfört med RBAC. Det är en auktorisationsmodell som definierar åtkomstkontrollpolicys baserat på attributen hos användaren, resursen, åtgärden och miljön. Det tillåter organisationer att definiera finkorniga åtkomstkontrollpolicys som kan anpassa sig till olika sammanhang och förhållanden.

Nyckelkomponenter av ABAC#

• Ämne: Ett ämne är en enhet som begär åtkomst till en resurs. Det kan vara en användare, en enhet, en applikation eller någon annan enhet som behöver komma åt resurser.
• Resurs: Precis som i RBAC är en resurs en enhet som ett ämne kan komma åt. Resurser kan vara filer, databaser, API:er eller någon annan systemenhet.
• Åtgärd: En åtgärd är en specifik operation som ett ämne kan utföra på en resurs. Det kan vara att skapa, läsa, uppdatera, radera eller någon annan operation som behöver kontrolleras.
• Miljö: Miljön är sammanhanget i vilket åtkomstbegäran görs. Det kan inkludera attribut som tid på dygnet, plats, nätverk, enhet, etc.
• Attribut: Ett attribut är en egenskap hos ett ämne, resurs, åtgärd eller miljö. Attribut kan vara allt från användarroller, avdelning, plats, IP-adress, enhetstyp, etc.
• Policy: En policy är en regel som definierar de villkor under vilka åtkomst beviljas eller nekas. Policys definieras baserat på attributen.

Fördelar med ABAC#

• Flexibilitet: ABAC kan tillgodose komplexa åtkomstkontrollpolicys som är baserade på flera attribut. Det tillåter organisationer att definiera finkorniga policys som kan anpassa sig till olika sammanhang och förhållanden.
• Dynamik: ABAC-policys kan vara dynamiska och kontextmedvetna. Åtkomstkontrollbeslut kan baseras på realtidsattribut som plats, tid på dygnet, enhetstyp, etc.
• Finkornighet: ABAC ger finkornig åtkomstkontroll genom att tillåta organisationer att definiera policys baserat på flera attribut. Till skillnad från att definiera roller och rättigheter kan attributbaserade policys vara mer detaljerade.

Nackdelar med ABAC#

• Komplexitet: ABAC kan vara mer komplext att implementera och hantera jämfört med RBAC. Att definiera attribut och policys kan kräva mer ansträngning och expertis. Till skillnad från RBAC, där roller och rättigheter är välstrukturerade, kan attribut vara mer dynamiska och så även policys. Att hantera ett stort antal attribut och policys i ett komplext system kan vara utmanande. En centraliserad policyutvärderingsmotor krävs ofta för att utvärdera policys.
• Prestanda: Attribututvärdering kan påverka prestanda, särskilt i realtidsmiljöer. Policys baserade på flera attribut och realtidsförhållanden kan introducera fördröjningar i åtkomstkontrollbeslut.

Jämförelsetabell#

Från jämförelsetabellen är det tydligt att RBAC är bäst lämpat för system med väldefinierade rättighetsstrukturer och där åtkomstkontrollpolicys är relativt statiska. Å andra sidan är ABAC mer lämpligt för system där åtkomstkontrollpolicys behöver vara dynamiska, kontextmedvetna och finkorniga.

Exempel#

Scenario: Ett sjukhussystem som behöver hantera åtkomst till patientjournaler för olika personalmedlemmar.

• Personal: Läkare, Sjuksköterskor, Administratörer
• Resurser: Patientjournaler
• Rättigheter: Läsa, Skriva, Radera

Fall 1#

Åtkomstkontrollpolicys är relativt enkla:

1. Läkare kan läsa och skriva patientjournaler.
2. Sjuksköterskor kan läsa patientjournaler.
3. Administratörer kan läsa, skriva och radera patientjournaler.

RBAC-modell#

I detta fall är RBAC enkel och effektiv. Vi kan definiera roller för läkare, sjuksköterskor och administratörer och tilldela de lämpliga rättigheterna till varje roll.

Åtkomstkontrollutvärderingen är enkel:

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

ABAC-modell#

I detta fall kan ABAC vara överflödigt, men det kan fortfarande användas för att definiera finkorniga policys baserade på attribut som avdelning, roll, etc.

Attribut:

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

Policys:

• Policy 1: Tillåt läsåtkomst baserat på user.role och resource.name
  • subject: Användare med roll doctor, nurse, admin
  • resource: Resurs med namn patient-record
  • action: read
  • effect: tillåt
  • rationale: "Tillåt läsåtkomst till patientjournaler för alla roller"
• Policy 2: Redigera åtkomst för läkare och administratörer
  • subject: Användare med roll doctor, admin
  • resource: Resurs med namn patient-record
  • action: write
  • effect: tillåt
  • rationale: "Tillåt skrivåtkomst till patientjournaler för läkare och administratörer"
• Policy 3: Radera åtkomst för administratörer
  • subject: Användare med roll admin
  • resource: Resurs med namn patient-record
  • action: delete
  • effect: tillåt
  • rationale: "Tillåt radering av patientjournaler för administratörer"

För varje läs-/skriv-/raderingsförfrågan utvärderar policy-motorn alla relevanta policys baserat på attributen och fattar ett åtkomstkontrollbeslut.

Jämförelse#

I detta fall är åtkomstkontrollpolicys enkla och välstrukturerade. Det kräver endast en enkelnivåkontroll för att avgöra om en användare har åtkomst till en resurs. Föreställ dig att sjukhussystemet har en mer komplex struktur med flera avdelningar, roller och rättigheter:

• I en RBAC-modell kommer åtkomstkontrollutvärderingsprocessen för patientjournalresursen fortfarande att vara enkel och rak, om användaren har read, write, eller delete-rättigheten;
• ABAC, å andra sidan, behöver involvera ytterligare attribut som department-id och doctor-id. Vad händer om en IoT-enhet behöver komma åt patientjournaler? Det kommer att kräva ett nytt attribut device-id för att introduceras i policyutvärderingen. Hur skulle det vara att ge read-rättighet temporärt till en praktikantläkare?

I slutsats är RBAC en bättre passform. RBAC är enkelt och effektivt för system med väldefinierade rättighetsstrukturer och där åtkomstkontrollpolicys är statiska.

Fall 2#

Samma sjukhussystem, nu låt oss introducera en ny roll patient och ett nytt attribut patient-id.

Åtkomstkontrollpolicys är:

1. Läkare kan läsa och skriva patientjournaler.
2. Sjuksköterskor kan läsa patientjournaler.
3. Administratörer kan läsa, skriva och radera patientjournaler.
4. Patienter kan läsa sina egna journaler.

RBAC-modell#

I detta fall, förutom den gamla read-rättigheten, behöver vi införa en ny rättighet read-own. Vi kan definiera roller för läkare, sjuksköterskor, administratörer och patienter och tilldela de lämpliga rättigheterna till varje roll.

Nu är åtkomstkontrollutvärderingen lite mer komplex, särskilt för read-åtgärden av patientjournal:

• 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-modell#

Nu låt oss uppdatera attributen och policys i ABAC-modellen för att tillgodose de nya kraven.

Attribut:

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

Policys:

• Policy 1: Tillåt läsåtkomst till alla patientjournaler
  • subject: Användare med roll doctor, nurse, admin
  • resource: Resurs med namn patient-record
  • action: read
  • effect: tillåt
  • rationale: "Tillåt läsåtkomst till patientjournaler för all personal och patienten själv"
• Policy 2: Tillåt skrivåtkomst till alla patientjournaler för läkare och administratörer
  • subject: Användare med roll doctor, admin
  • resource: Resurs med namn patient-record
  • action: write
  • effect: tillåt
  • rationale: "Tillåt skrivåtkomst till patientjournaler för läkare och administratörer"
• Policy 3: Tillåt radera åtkomst till alla patientjournaler för administratörer
  • subject: Användare med roll admin
  • resource: Resurs med namn patient-record
  • action: delete
  • effect: tillåt
  • rationale: "Tillåt radering av patientjournaler för administratörer"
• Policy 4: Tillåt läsåtkomst till egna patientjournaler
  • subject: Användare med roll patient
  • resource: Resurs med namn patient-record
  • action: read
  • condition: user.id === resource.patient-id
  • effect: tillåt
  • rationale: "Tillåt läsning av egna patientjournaler"

Jämförelse#

I detta fall är åtkomstkontrollpolicys mer komplexa och kontextmedvetna. Åtkomstkontrollutvärderingsprocessen för patientjournalresursen kommer att kräva flera nivåer av rättighetskontroller för att avgöra om en användare har åtkomst till en resurs.

• I en RBAC-modell kommer åtkomstkontrollutvärderingsprocessen för patientjournalresursen att kräva flera nivåer av rättighetskontroller för att avgöra om en användare har åtkomst till en resurs. Till exempel, för att avgöra om en patient har åtkomst till sina egna journaler, behöver systemet kontrollera om användaren har read-own-rättigheten och om användar-id matchar patient-id.
• I en ABAC-modell kan åtkomstkontrollutvärderingsprocessen vara mer rak. Policys kan definieras baserat på attributen hos användaren, resursen och åtgärden. Till exempel, för att avgöra om en patient har åtkomst till sina egna journaler, kan policy-motorn utvärdera policyn baserat på användar-id och patient-id.

I detta fall kan ABAC vara en bättre passform. ABAC är mer lämplig för system där åtkomstkontrollpolicys behöver vara dynamiska, kontextmedvetna och finkorniga.

Slutsats#

Valet mellan RBAC och ABAC beror på systemets specifika krav. RBAC är bäst lämpat för system med väldefinierade rättighetsstrukturer och där åtkomstkontrollpolicys är statiska. ABAC är mer lämpligt för system där åtkomstkontrollpolicys behöver vara dynamiska, kontextmedvetna och finkorniga. I praktiken kan organisationer välja att använda en kombination av båda modellerna för att uppnå önskad nivå av åtkomstkontroll.