RBAC ja ABAC: Pääsynhallintamallit, jotka sinun pitäisi tietää

Johdanto#

Pääsynhallinta on kriittinen osa tietoturvaa kaikissa järjestelmissä. Se varmistaa, että vain valtuutetut käyttäjät voivat käyttää resursseja ja suorittaa toimintoja. Roolipohjainen pääsynvalvonta (RBAC) ja attribuuttipohjainen pääsynvalvonta (ABAC) ovat modernien järjestelmien kaksi suosituinta pääsynhallintamallia. Molemmat mallit ovat laajasti käytössä ja niitä voidaan käyttää pääsynhallintakäytäntöjen tehokkaaseen täytäntöönpanoon. Mutta mitä ne ovat ja miten ne eroavat toisistaan?

Roolipohjainen pääsynvalvonta (RBAC)#

Roolipohjainen pääsynvalvonta (RBAC) esiteltiin ensimmäisen kerran 1990-luvun alussa. Mallin muodollisuus ajoitetaan David Ferraiolon ja Rick Kuhnin julkaisemaan paperiin vuonna 1992. Siitä lähtien RBAC:sta on tullut yksi teollisuuden laajimmin käytetyistä pääsynhallintamalleista.

RBAC:ssa pääsynhallinnan käytännöt perustuvat rooleihin, jotka ovat kokoelmia oikeuksista. Käyttäjille annetaan rooleja (esim. ylläpitäjä, muokkaaja, katselija), ja heidän käyttöoikeutensa määräytyvät tiettyjen resurssien (esim. tiedostojen, tietokantojen, sovellusten) oikeuksien (esim. luominen, muokkaus, poistaminen) perusteella. Se yksinkertaistaa pääsynhallintakäytäntöjen hallintaa ryhmittelemällä käyttäjiä heidän rooliensa perusteella ja määrittämällä rooleille oikeuksia. Käyttäjien lisääminen tai poistaminen rooleista on suoraviivaista, ja muutokset heijastuvat automaattisesti pääsynhallintakäytäntöihin.

RBAC:n keskeiset komponentit#

• Resurssi: Resurssi on entiteetti, johon käyttäjä voi saada pääsyn. Resurssit voivat olla mitä tahansa, kuten tiedostoja, tietokantoja, API:ita tai mikä tahansa muu järjestelmän entiteetti, joka tarvitsee suojelua.
• Oikeus: Oikeus on tietty toiminto, jonka käyttäjä voi suorittaa resurssissa. Esimerkiksi luominen, muokkaaminen, poistaminen, katselu. Oikeuksien määritelmä voi vaihdella järjestelmästä riippuen. Useimmissa tapauksissa oikeudet määritellään resurssitasolla vähimmäisrakeisuudella.
• Rooli: Rooli on kokoelma oikeuksia, jotka määrittelevät joukon toimintoja, joita käyttäjä voi suorittaa. Esimerkiksi ylläpitäjän roolilla voi olla oikeudet luoda, muokata ja poistaa resursseja, kun taas katselijalla voi olla oikeus katsoa resursseja.
• Käyttäjä: Käyttäjä on entiteetti, jolle voidaan määrittää yksi tai useampi rooli. Käyttäjille myönnetään pääsy resursseihin heille määritettyjen roolien oikeuksien perusteella.

RBAC:n variantit#

RBAC:sta on useita variantteja, jotka laajentavat perusmallia vastaamaan monimutkaisempia pääsynhallinnan tarpeita:

• RBAC0: Perusmalli, jossa käyttäjille annetaan rooleja ja rooleille annetaan oikeuksia.
• RBAC1: Lisää roolihierarkioiden käsitteen. Roolit voivat periä oikeuksia muilta rooleilta. Tunnetaan myös hierarkkisena RBAC:na.
• RBAC2: Lisää rajoituksia rooleihin. Rajoituksia voidaan käyttää määrittämään lisäedellytyksiä, jotka on täytettävä, jotta käyttäjä voidaan määrätä rooliin. Tunnetaan myös rajoitepohjaisena RBAC:na.
• RBAC3: Yhdistää RBAC1:n ja RBAC2:n ominaisuudet. Tukee sekä roolihierarkioita että rajoituksia.

Lisätietoja näistä varianteista löytyy RBAC-mallit ja niiden kehitys.

RBAC:n edut#

• Yksinkertaisuus: RBAC on helppo ymmärtää ja toteuttaa. Oikeuksien määrittäminen rooleille ja roolien määrittäminen käyttäjille on suoraviivaista.
• Tehokkuus: Se yksinkertaistaa pääsynhallintakäytäntöjen hallintaa ryhmittelemällä käyttäjiä heidän rooliensa perusteella. Käyttäjien lisääminen tai poistaminen rooleista on helppoa ilman, että pääsynhallintakäytäntöjä tarvitsee muuttaa. Erityisesti suurissa organisaatioissa, joissa on hyvin määritellyt oikeusrakenteet, RBAC voi olla erittäin tehokas.
• Läpinäkyvyys: RBAC tarjoaa selkeän yhteyden roolien, oikeuksien ja käyttäjien välillä. Pääsynhallintakäytäntöjä on helppo tarkastaa ja tarkistaa.

RBAC:n haitat#

• Jäykkyys: RBAC voi olla jäykkä, kun määritetään monimutkaisia pääsynhallintakäytäntöjä. Se ei välttämättä sovellu järjestelmiin, joissa pääsynhallintakäytännöt tarvitsevat olla dynaamisempia ja kontekstitietoisia.
• Rakeisuus: RBAC saattaa puuttua tarvittavaa rakeisuutta hienorakeiseen pääsynhallintaan. Pääsynhallintakäytännöt ovat sidoksissa hyvin määriteltyihin rooleihin, ja se voi vaatia lisävaivaa määritellä oikeuksia tarkemmalla tasolla.
• Roolien räjähdys: Suurissa organisaatioissa, joissa on monimutkaisia oikeusrakenteita, roolien lukumäärä voi kasvaa eksponentiaalisesti, mikä johtaa roolien räjähdykseen. Suuren määrän roolien hallinnointi voi olla haastavaa.

Attribuuttipohjainen pääsynvalvonta (ABAC)#

2000-luvun lopulla, kun järjestelmät muuttuivat yhä monimutkaisemmiksi ja dynaamisemmiksi, yhä useammat organisaatiot alkoivat ottaa käyttöön attribuuttipohjaisen pääsynvalvonnan (ABAC) vaihtoehdoksi RBAC:lle. Merkittävä virstanpylväs ABAC:n muodollistamisessa on NIST Special Publication 800-162:n julkaisu vuonna 2014.

ABAC on joustavampi pääsynhallintamalli verrattuna RBAC:hen. Se on valtuutusmalli, joka määrittelee pääsynhallintakäytännöt käyttäjän, resurssin, toiminnon ja ympäristön attribuuttien perusteella. Se mahdollistaa organisaatioille hienorakeisten pääsynhallintakäytäntöjen määrittelyn, jotka voivat mukautua erilaisiin konteksteihin ja olosuhteisiin.

ABAC:n keskeiset komponentit#

• Subjekti: Subjekti on entiteetti, joka pyytää pääsyä resurssiin. Se voi olla käyttäjä, laite, sovellus tai mikä tahansa muu entiteetti, joka tarvitsee pääsyn resursseihin.
• Resurssi: Aivan kuten RBAC:ssa, resurssi on entiteetti, johon subjektilla voi olla pääsy. Resurssit voivat olla tiedostoja, tietokantoja, API:ita tai mitä tahansa järjestelmän entiteettejä.
• Toiminto: Toiminto on tietty operaatio, jonka subjekti voi suorittaa resurssilla. Se voi olla luominen, lukeminen, päivittäminen, poistaminen tai mikä tahansa muu operaatio, joka tarvitsee hallintaa.
• Ympäristö: Ympäristö on konteksti, jossa pääsypyyntö tehdään. Se voi sisältää attribuutteja, kuten vuorokaudenaika, sijainti, verkko, laite jne.
• Attribuutti: Attribuutti on subjektiin, resurssiin, toimintaan tai ympäristöön liittyvä ominaisuus. Attribuutit voivat olla mitä tahansa käyttäjärooleista, osastoista, sijainneista, IP-osoitteista, laitettyypeistä jne.
• Politiikka: Politiikka on sääntö, joka määrittelee ehdot, joiden perusteella pääsy myönnetään tai evätään. Politiikat määritellään attribuuttien perusteella.

ABAC:n edut#

• Joustavuus: ABAC voi vastata monimutkaisiin pääsynhallintakäytäntöihin, jotka perustuvat useisiin attribuutteihin. Se mahdollistaa organisaatioille hienorakeisten käytäntöjen määrittelyn, jotka voivat mukautua erilaisiin konteksteihin ja olosuhteisiin.
• Dynaaminen: ABAC-käytännöt voivat olla dynaamisia ja kontekstitietoisia. Pääsynhallintapäätökset voidaan tehdä reaaliaikaisiin attribuutteihin, kuten sijaintiin, vuorokaudenaikaan, laitetyyppiin jne., perustuen.
• Rakeisuus: ABAC tarjoaa hienorakeisen pääsynhallinnan, kun organisaatiot voivat määritellä käytäntöjä useiden attribuuttien perusteella. Toisin kuin roolien ja oikeuksien määrittely, attribuuttipohjaiset käytännöt voivat olla tarkempia.

ABAC:n haitat#

• Monimutkaisuus: ABAC voi olla monimutkaisempaa toteuttaa ja hallita verrattuna RBAC:hen. Attribuuttien ja politiikkojen määrittäminen voi vaatia enemmän vaivaa ja asiantuntemusta. Toisin kuin RBAC, jossa roolit ja oikeudet ovat hyvin rakenteellisia, attribuutit voivat olla dynaamisempia ja samoin politiikat. Suuren määrän attribuuttien ja politiikkojen hallinnointi monimutkaisessa järjestelmässä voi olla haastavaa. Keskitetty politiikan arviointimoottori vaaditaan usein politiikkojen arviointiin.
• Suorituskyky: Attribuuttien arviointi voi vaikuttaa suorituskykyyn, erityisesti reaaliaikaisissa ympäristöissä. Politiikat, jotka perustuvat useisiin attribuutteihin ja reaaliaikaisiin olosuhteisiin, voivat lisätä viivettä pääsynhallintapäätöksissä.

Vertailutaulukko#

Vertailutaulukosta käy ilmi, että RBAC sopii parhaiten järjestelmiin, joissa on hyvin määritellyt oikeusrakenteet ja joissa pääsynhallintakäytännöt ovat melko staattisia. Toisaalta ABAC soveltuu paremmin järjestelmiin, joissa pääsynhallintakäytännöt tarvitsevat olla dynaamisia, kontekstitietoisia ja hienorakeisia.

Esimerkit#

Tapaus: Sairaalajärjestelmä, joka tarvitsee hallita pääsyä potilastietoihin eri henkilöstöjäsenille.

• Henkilöstö: Lääkärit, Hoitajat, Ylläpitäjät
• Resurssit: Potilastiedot
• Oikeudet: Luku, Kirjoitus, Poisto

Tapaus 1#

Pääsynhallintakäytännöt ovat melko yksinkertaisia:

1. Lääkärit voivat lukea ja kirjoittaa potilastietoja.
2. Hoitajat voivat lukea potilastietoja.
3. Ylläpitäjät voivat lukea, kirjoittaa ja poistaa potilastietoja.

RBAC-malli#

Tässä tapauksessa RBAC on yksinkertainen ja tehokas. Voimme määritellä rooleja lääkäreille, hoitajille ja ylläpitäjille sekä määrittää kullekin roolille sopivat oikeudet.

Pääsynhallinnan arviointi on suoraviivaista:

• GET /patient-records: user.permission.includes('luku')
• POST /patient-records: user.permission.includes('kirjoitus')
• DELETE /patient-records: user.permission.includes('poisto')

ABAC-malli#

Tässä tapauksessa ABAC voi olla liiallinen, mutta sitä voidaan silti käyttää hienorakeisten käytäntöjen määrittelyssä attribuuttien, kuten osaston, roolin jne. perusteella.

Attribuutit:

• user.role: lääkäri, hoitaja, ylläpitäjä
• resource.name: potilastieto
• action: luku, kirjoitus, poisto

Politiikat:

• Politiikka 1: Salli lukuoikeus user.rolen ja resource.namen perusteella
  • subject: Käyttäjä roolilla lääkäri, hoitaja, ylläpitäjä
  • resource: Resurssi nimellä potilastieto
  • action: luku
  • effect: sallia
  • rationale: "Salli lukuoikeus potilastietoihin kaikille rooleille"
• Politiikka 2: Muokkausoikeus lääkäreille ja ylläpitäjille
  • subject: Käyttäjä roolilla lääkäri, ylläpitäjä
  • resource: Resurssi nimellä potilastieto
  • action: kirjoitus
  • effect: sallia
  • rationale: "Salli kirjoitusoikeus potilastietoihin lääkäreille ja ylläpitäjille"
• Politiikka 3: Poisto-oikeus ylläpitäjille
  • subject: Käyttäjä roolilla ylläpitäjä
  • resource: Resurssi nimellä potilastieto
  • action: poisto
  • effect: sallia
  • rationale: "Salli poisto-oikeus potilastietoihin ylläpitäjille"

Jokaisessa luku-/kirjoitus-/poistopyynnössä politiikkamoottori arvioi kaikki asiaankuuluvat politiikat attribuuttien perusteella ja tekee pääsynhallintapäätöksen.

Vertailu#

Tässä tapauksessa pääsynhallintakäytännöt ovat yksinkertaisia ja hyvin jäsenneltyjä. Ne tarvitsevat vain yhden tason oikeustarkistuksen määrittääkseen, onko käyttäjällä pääsy resurssiin. Kuvitellaan, että sairaalajärjestelmässä on monimutkaisempi rakenne useilla osastoilla, rooleilla ja oikeuksilla:

• RBAC-mallissa potilastietoresurssin pääsynhallinnan arviointiprosessi pysyy yksinkertaisena ja suoraviivaisena, olipa käyttäjällä luku, kirjoitus tai poisto -oikeus;
• ABAC:ssa taas tarvitaan lisäattribuutteja, kuten department-id ja doctor-id. Entä jos IoT-laitteen tarvitsee päästä käsiksi potilastietoihin? Poliittisen arvioinnin yhteydessä on otettava käyttöön uusi attribuutti device-id. Entä jos väliaikaisesti myönnetään luku-oikeus harjoittelijalääkärille?

Lopuksi RBAC on parempi valinta. RBAC on yksinkertainen ja tehokas järjestelmissä, joissa on hyvin määritellyt oikeusrakenteet ja joissa pääsynhallintakäytännöt ovat staattisia.

Tapaus 2#

Sama sairaalajärjestelmä, nyt lisätään uusi rooli potilas ja uusi attribuutti potilas-id.

Pääsynhallintakäytännöt ovat:

1. Lääkärit voivat lukea ja kirjoittaa potilastietoja.
2. Hoitajat voivat lukea potilastietoja.
3. Ylläpitäjät voivat lukea, kirjoittaa ja poistaa potilastietoja.
4. Potilaat voivat lukea omia tietojaan.

RBAC-malli#

Tässä tapauksessa vanhan luku-oikeuden lisäksi on otettava käyttöön uusi oikeus luku-oma. Voimme määritellä rooleja lääkäreille, hoitajille, ylläpitäjille ja potilaille sekä määrittää kullekin roolille sopivat oikeudet.

Nyt pääsynhallinnan arviointi on hieman monimutkaisempaa, erityisesti potilastietojen luku toiminnon osalta:

• GET /patient-records: user.permission.includes('luku')
• POST /patient-records: user.permission.includes('kirjoitus')
• DELETE /patient-records: user.permission.includes('poisto')
• GET /patient-records/:patient-id: user.permission.includes('luku-oma') && user.id === patient-id || user.permission.includes('luku')

ABAC-malli#

Päivitetään nyt attribuutit ja politiikat ABAC-mallissa vastaamaan uusia vaatimuksia.

Attribuutit:

• user.role: lääkäri, hoitaja, ylläpitäjä, potilas
• user.id: potilaan-id
• resource.name: potilastieto
• resource.patient-id: potilas-id
• action: luku, kirjoitus, poisto

Politiikat:

• Politiikka 1: Salli lukuoikeus kaikkiin potilastietoihin
  • subject: Käyttäjä roolilla lääkäri, hoitaja, ylläpitäjä
  • resource: Resurssi nimellä potilastieto
  • action: luku
  • effect: sallia
  • rationale: "Salli lukuoikeus potilastietoihin kaikille henkilöstölle ja potilaalle itselleen"
• Политика 2: Salli kirjoitusoikeus kaikkiin potilastietoihin lääkäreille ja ylläpitäjille
  • subject: Käyttäjä roolilla lääkäri, ylläpitäjä
  • resource: Resurssi nimellä potilastieto
  • action: kirjoitus
  • effect: sallia
  • rationale: "Salli kirjoitusoikeus potilastietoihin lääkäreille ja ylläpitäjille"
• Политика 3: Salli poisto-oikeus kaikkiin potilastietoihin ylläpitäjille
  • subject: Käyttäjä roolilla ylläpitäjä
  • resource: Resurssi nimellä potilastieto
  • action: poisto
  • effect: sallia
  • rationale: "Salli poisto-oikeus potilastietoihin ylläpitäjille"
• Politiikka 4: Salli lukuoikeus omaan potilastietoon
  • subject: Käyttäjä roolilla potilas
  • resource: Resurssi nimellä potilastieto
  • action: luku
  • condition: user.id === resource.patient-id
  • effect: sallia
  • rationale: "Salli lukuoikeus omaan potilastietoon"

Vertailu#

Tässä tapauksessa pääsynhallintakäytännöt ovat monimutkaisempia ja kontekstitietoisia. Potilastietoresurssin pääsynhallinnan arviointiprosessi vaatii useiden tasojen oikeustarkistuksia määrittääkseen, onko käyttäjällä pääsy resurssiin.

• RBAC-mallissa potilastietoresurssin pääsynhallinnan arviointiprosessi vaatii useita tasoja oikeustarkistuksia määrittääkseen, onko käyttäjällä pääsy resurssiin. Esimerkiksi, jotta voidaan määrittää, onko potilaalla pääsy omiin tietohinsa, järjestelmän on tarkistettava, onko käyttäjällä luku-oma -oikeus ja vastaavaako käyttäjän id potilaan id:tä.
• ABAC-mallissa taas pääsynhallinnan arviointiprosessi voi olla suoraviivaisempi. Politiikat voidaan määritellä käyttäjän, resurssin ja toiminnon attribuuttien perusteella. Esimerkiksi, jotta voidaan määrittää, onko potilaalla pääsy omiin tietohinsa, politiikkamoottori voi arvioida politiikkaa käyttäjän id:n ja potilaan id:n perusteella.

Tässä tapauksessa ABAC voi olla parempi valinta. ABAC on sopivampi järjestelmiin, joissa pääsynhallintakäytännöt tarvitsevat olla dynaamisia, kontekstitietoisia ja hienorakeisia.

Yhteenveto#

Valinta RBAC:n ja ABAC:n välillä riippuu järjestelmän erityisvaatimuksista. RBAC sopii parhaiten järjestelmiin, joissa on hyvin määritellyt oikeusrakenteet ja joissa pääsynhallintakäytännöt ovat staattisia. ABAC on sopivampi järjestelmiin, joissa pääsynhallintakäytännöt tarvitsevat olla dynaamisia, kontekstitietoisia ja hienorakeisia. Käytännössä organisaatiot saattavat valita yhdistelmän molempia malleja saavuttaakseen halutun tason pääsynhallinnan.