Roolipohjainen pääsynhallinta (role-based access control, RBAC) on tapa päättää, kuka saa tehdä mitä järjestelmässä: oikeudet liitetään rooleihin ja ihmiset määritetään näihin rooleihin. Kenellekään ei anneta oikeuksia yksitellen. Myyjä, talouspäällikkö ja asiakastuen vetäjä saavat kukin sen pääsyn, jonka heidän työnsä vaatii, eikä mitään enempää. Tämä opas selittää, miten RBAC toimii, miten roolit suunnitellaan hallittaviksi, milloin attribuuttipohjainen pääsynhallinta (ABAC) sopii paremmin ja mitä muuttuu, kun tekoälyagentit alkavat lukea ja kirjoittaa yrityksenne dataa.

Tiivistelmä

Sisällysluettelo

Mitä roolipohjainen pääsynhallinta on

RBAC on malli, jolla järjestelmien, sovellusten ja datan käyttöoikeudet myönnetään käyttäjän ennalta määritellyn roolin perusteella. IBM kuvaa sen niin, että ylläpitäjä määrittää kullekin käyttäjälle yhden tai useamman roolin, ja kukin rooli edustaa joukkoa oikeuksia tai käyttöoikeuksia.

Määrittävä piirre on, että kaikki pääsy kulkee roolien kautta. NIST Computer Security Resource Centerin FAQ:n mukaan rooli on pohjimmiltaan joukko oikeuksia, ja käyttäjät saavat oikeuksia vain niiden roolien kautta, jotka heille on määritetty tai jotka he perivät roolihierarkian kautta. Tämä erottaa RBAC:n tavallisista ryhmistä, joissa oikeudet voidaan sitoa sekä käyttäjiin että ryhmiin. NIST toteaa, että tämä luo porsaanreiän, jonka vuoksi käyttäjien ja oikeuksien välisiä suhteita on vaikea hallita.

Konkreettinen esimerkki SaaS-yritykselle:

Rooli Tyypillinen pääsy CRM:ssä Tyypillinen pääsy talousjärjestelmässä Tyypillinen pääsy tuotteen ylläpitoon
Account Executive Omat asiakkuudet ja kaupat, luku- ja kirjoitusoikeus Ei mitään Ei mitään
Sales Manager Tiimin asiakkuudet, ennustenäkymät Laskujen tila vain luku -oikeudella Ei mitään
Finance Controller Asiakastiedot vain luku -oikeudella Täysi laskutus ja raportointi Ei mitään
Customer Success Manager Osoitetut asiakkuudet, uusimiskentät Laskujen tila vain luku -oikeudella Rajatut tenant-asetukset
Support Engineer Asiakkuuksien yhteyshenkilöt vain luku -oikeudella Ei mitään Tenantin diagnostiikka
Järjestelmänvalvoja Konfigurointi Konfigurointi Täysi

Kun uusi myyntipäällikkö aloittaa, määrität hänelle yhden roolin. Et luo uudelleen kymmeniä yksittäisiä käyttöoikeusvalintoja.

Miten RBAC toimii: kolme sääntöä ja neljä osatekijää

NIST-malli perustuu kolmeen sääntöön, jotka on esitetty NIST-julkaisussa Role Engineering: Methods and Standards:

  1. Roolin määrittäminen. Käyttäjä voi käyttää oikeutta vain, jos hänelle on määritetty rooli.
  2. Roolin valtuuttaminen. Käyttäjän aktiivisen roolin on oltava valtuutettu kyseiselle käyttäjälle.
  3. Oikeuden valtuuttaminen. Käyttäjä voi käyttää oikeutta vain, jos se on valtuutettu käyttäjän aktiiviselle roolille.

Samassa julkaisussa todetaan, että NIST ehdotti yhtenäistä RBAC-mallia vuonna 2000 ja että se hyväksyttiin vuonna 2004 yhdysvaltalaiseksi kansalliseksi standardiksi INCITS 359-2004.

Standardissa on neljä osaa, kuten ANSI INCITS 359-2004 -asiakirjassa todetaan:

Tehtävien erottelu on tärkeintä taloushallinnossa. Toimittajamaksun luovan henkilön ei pitäisi olla sama kuin sen hyväksyvän henkilön. Staattinen tehtävien erottelu varmistaa tämän roolia määritettäessä, mikä on yksinkertaisin ja auditoitavin tapa toteuttaa se.

Miten suunnittelet roolit hallittaviksi

Suunnittelussa useimmat RBAC-hankkeet onnistuvat tai epäonnistuvat. Rooliryhmä, joka heijastaa liiketoiminnan toimintatapaa, on helppo selittää ja tarkastaa. Rooliryhmästä, joka heijastaa kunkin työkalun valintaruutuja, tulee sokkelo.

Lähde liiketoiminnan toiminnoista

IBM:n toteutusohjeiden mukaan vankimmat mallit lähtevät liiketoiminnan toiminnoista ja työnkuluista, eivät sovellusten valikoista. Sen sijaan että kysyisit, mitkä ruudut CRM:ssä rastitetaan, kysy, mitä myyjä todellisuudessa tekee, ja ilmaise nämä toiminnot roolimäärityksinä, jotka voidaan kuvata useisiin järjestelmiin.

Tämä viimeinen kohta on käytännöllinen. “Customer Success Manager” -roolin tulisi tarkoittaa samaa CRM-järjestelmässäsi, laskutustyökalussasi, tukipalvelussasi ja kaikissa sisäisissä portaaleissa. Määrittelet sen kerran liiketoimintaroolina ja kuvaat sen sitten kuhunkin järjestelmään.

Yksi liiketoimintarooli kuvattuna neljään järjestelmään

Valitse roolisuunnittelun lähestymistapa

NIST:n roolisuunnittelua käsittelevässä julkaisussa kuvataan kolme lähestymistapaa:

Myös Oraclen identiteettidokumentaatio suosittelee hybridimallia roolilouhintaan. 20–200 hengen yritykselle hybridi on yleensä realistinen. Käytä muutama tunti kunkin toiminnon johtajan kanssa roolien luonnosteluun, vie sitten nykyiset käyttöoikeudet CRM- ja talousjärjestelmästäsi ja katso, missä todellisuus poikkeaa. Yhdistelmä välttää liian teoreettiset roolit eikä rakenna rooleja muutaman poikkeustapauksen ympärille.

Käytännön eteneminen

  1. Kartoita järjestelmät ja data. Listaa järjestelmät, jotka sisältävät asiakas-, liikevaihto- ja tuotetietoja, ja merkitse, mitkä tiedot ovat arkaluonteisia.
  2. Luonnostele roolit toiminnoittain. Aloita laajoista luokista. IBM toteaa, että organisaatiot aloittavat usein erottelemalla ylläpitäjät, asiantuntija- tai edistyneet käyttäjät ja loppukäyttäjät.
  3. Vie todelliset käyttöoikeudet. Hae kunkin henkilön nykyiset käyttöoikeudet jokaisesta järjestelmästä ja ryhmittele samankaltaiset mallit.
  4. Sovita yhteen. Jos jollakulla on huomattavasti enemmän oikeuksia kuin hänen luonnosroolillaan, päätä, onko rooli väärin vai onko henkilö kerännyt oikeuksia, jotka hänen pitäisi menettää.
  5. Nimeä jokaiselle roolille omistaja. Yksi henkilö vastaa siitä, mitä rooli sisältää.
  6. Ota käyttöön, sitten tarkasta. Siirrä ihmiset rooleihin, poista suorat oikeudet ja aikatauluta ensimmäinen tarkastus.

RBAC:n parhaat käytännöt pitkällä aikavälillä

IBM:n ohjeiden mukaan RBAC:n pitkäaikainen toimivuus riippuu hallinnasta: määräaikaisista käyttöoikeustarkastuksista, jotka keskittyvät poikkeuksiin ja poikkeaviin tapauksiin, joiner-mover-leaver-prosesseista, jotka muuttavat rooleja automaattisesti HR-tapahtumien perusteella, sekä aikarajatuista, hyväksytyistä poikkeuksista epätavallisiin käyttöoikeuksiin.

Toteuta vähimmän oikeuden periaate suunnittelun kautta

Avatierin yritysten RBAC-parhaiden käytäntöjen opas luettelee neljä mekanismia, jotka tuottavat vähimmän oikeuden periaatteen:

Toinen kohta unohtuu useimmin. Tiimiä vaihtavat ihmiset keräävät oikeuksia. Kahden tai kolmen siirron jälkeen asiakkuuspäällikön hallussa voi olla myyntiputken ja laskutuksen oikeuksia, joita kukaan ei ole tarkoittanut.

Estä roolien räjähdysmäinen kasvu

Sama lähde kutsuu roolien räjähdysmäistä kasvua hallitsevaksi virhetilaksi: jokaiselle poikkeustapaukselle luodaan uusi erillinen rooli. Ennaltaehkäisy on halvempaa kuin jälkisiivous. Anna jokaiselle roolille omistaja, yhdistele mieluummin olemassa olevia rooleja kuin luot uusia ja uusi roolien hyväksyntä aikataulun mukaan. Hyödyllinen testi: jos ehdotetulla roolilla olisi vain yksi haltija, kyse on todennäköisesti poikkeuksesta eikä roolista. Käsittele se määräaikaisena, hyväksyttynä poikkeuksena.

Pidä ylläpito kevyenä

Okta huomauttaa, että RBAC ei vaadi intensiivistä ylläpitoa: käyttöoikeudet seuraavat rooleja, joten uusi tehtävänkuva muuttuu uudeksi rooliksi, joka annetaan monelle henkilölle pienellä ylläpitäjän vaivalla. Tämä pätee vain, jos roolijoukko pysyy pienenä ja siistinä, minkä vuoksi omistajuus ja katselmointi ovat tärkeitä.

Lyhyt tarkistuslista

RBAC vs. ABAC: kumpaa tarvitset?

ABAC päättää pääsystä arvioimalla käyttäjän, resurssin, toiminnon ja joskus ympäristön attribuutteja politiikkaa vasten. NIST SP 800-162 määrittelee sen näin ja toteaa, että ACL:t ja RBAC ovat käytettyjen attribuuttien kannalta tietyllä tavalla ABAC:n erikoistapauksia.

Selkokielellä: RBAC kysyy “mikä on tehtäväsi?” ABAC kysyy “mikä on tehtäväsi, mihin kosket, kuinka paljon on pelissä ja mistä käsin?”

Oktan vertailun mukaan RBAC sopii pieniin, yksinkertaisesti rakennettuihin työryhmiin ja ympäristöihin, joissa tehtävänkuvat on selkeästi määritelty. ABAC sopii maantieteellisesti hajautuneisiin tai ajallisesti rajattuihin työryhmiin sekä tilanteisiin, joissa pääsyn tarve vaihtelee asiakirjakohtaisesti eikä roolin mukaan.

Kysymys RBAC ABAC
Päätöksen peruste Rooli Käyttäjän, resurssin, toiminnon ja kontekstin attribuutit
Helpoin selittää tarkastajalle Kyllä Vaatii enemmän työtä
Hoitaa tapauksen “vain tietyn summan alle jäävät kaupat” Kömpelö, lisää herkästi rooleja Luontevaa
Hoitaa tapauksen “vain oman alueesi tilit” Vaatii roolin jokaiselle alueelle Luontevaa
Käyttöönoton vaiva Pienempi Suurempi

Useimmat kasvavat SaaS-yritykset eivät valitse vain toista. Oktan identiteettitiimi toteaa, että monet organisaatiot käyttävät hybridimallia: RBAC:ia laajoihin käyttöoikeustasoihin ja ABAC:ia hienojakoisiin kontrolleihin. Avatier toteaa saman toisesta suunnasta: RBAC on perustaso, ja kontekstista riippuvat päätökset, kuten aika, sijainti, summa tai laite, kuuluvat sen päälle kerrostettavalle ABAC:ille. Käytännön sääntö on aloittaa RBAC:illa ja lisätä attribuuttisääntöjä vain siellä, missä roolien määrä muuten moninkertaistuisi, esimerkiksi alue- tai kauppakokorajoissa.

Sisäiset työkalut ja RBAC

Sisäisissä työkaluissa pääsynhallinta pettää huomaamatta. CRM:stä tehty taulukkovienti, yhden kehittäjän rakentama hallintapaneeli, linkillä jaettu talousdashboard: jokainen on paikka, jossa roolit ohitetaan. Kolme tapaa auttaa:

Jos rakennatte tai ostatte sisäisiä portaaleja, kysykää, miten roolit määritellään, kuka niitä voi muuttaa ja kirjataanko muutokset lokiin. Näitä kysymyksiä tietoturvatarkastaja tai asiakkaan kyselylomake kysyy.

RBAC, kun tekoälyagentit tulevat kuvaan

Tekoäly muuttaa pääsykysymystä yhdellä erityisellä tavalla: avustaja tai agentti voi ulottua useiden järjestelmien yli yhdellä pyynnöllä. Jos se on kytketty laajalla palvelutilillä, se voi palauttaa tietoja, joita kysyjällä ei ole koskaan ollut oikeutta nähdä.

Ratkaisu ei ole uusi tietoturvamalli. Se on jo käytössänne olevan mallin soveltaminen:

On myös yksi paikka, johon tekoäly ei kuulu: päätös siitä, kuka saa pääsyn. Roolien myöntäminen, muuttaminen ja hyväksyminen tulee jättää nimetyille ihmisille, jotka noudattavat yrityksenne käytäntöä. Agentti voi valmistella tarkistuslistan tai nostaa esiin poikkeamat, mutta päätöksen omistaa ihminen.

Sääntely osoittaa samaan suuntaan. GDPR, NIS2 ja EU AI Act koskevat kaikki sitä, miten dataa ja järjestelmiä hallitaan, ja hyvin suunniteltu pääsynhallinta on yksi yleinen rakennuspalikka, kun yritykset työstävät näitä vaatimuksia. RBAC ei yksinään tee yrityksestä vaatimustenmukaista, eikä tämä artikkeli ole oikeudellista neuvontaa. Kysykää lakimieheltänne, mitä teihin sovelletaan.

Lisätietoa siitä, miten hallintamalli ja tekoäly liittyvät toisiinsa, löydätte tekstistä tekoälyn hallintamalli B2B SaaS -yrityksille.

Näkökulma

Näemme saman kaavan 20–200 hengen SaaS-yrityksissä. Rooleja ei koskaan suunniteltu. Pääsyoikeudet kasvoivat jokaisen uuden työkalun myötä, ja sitten tekoäly saapui ja alkoi lukea kaikkea tätä.

Siksi rakennamme kiinteässä järjestyksessä. Ensin datapohja: CRM- ja talousdatanne sovittuna totuuden lähteenä, rooleilla, jotka tarkoittavat samaa jokaisessa järjestelmässä. Sitten tekoälykerros, joka yhdistää datan assistenttiin, jota tiiminne jo käyttää. Sitten osastokohtaiset agentit taloudelle, myynnille ja asiakasmenestykselle. Jokainen kerros perii sen alla olevan kerroksen pääsysäännöt.

Näkemyksemme mukaan agenttiin ei pidä koskaan luottaa enemmän kuin sitä käyttävään ihmiseen. Se toimii kyseisen henkilön oikeuksien rajoissa, pyytää hyväksyntää silloin, kun toiminnolla on merkitystä, ja jättää jälkeensä auditointijäljen. Roolisuunnittelu ei ole tekoälyprojektin sivutehtävä. Se on sen ensimmäinen osa.

Claus Nielsen

Missä NordOps Consulting tulee mukaan

Jos tiiminne käyttää jo tekoälyä mutta kukaan ei omista sitä, miten se koskettaa dataanne, pääsynhallinnan suunnittelu on hyvä paikka aloittaa. NordOps Consulting toimii Fractional Chief AI Officer -roolissa eurooppalaisille B2B SaaS -yrityksille: yksi nimetty henkilö, joka päättää, missä tekoäly tuottaa tulosta, rakentaa datapohjan ja luo agentit, joita ihmisenne käyttävät selkeällä kielellä, oikeuksien rajoissa ja auditointijäljen kera.

AI Readiness Assessment on selkeästi rajattu aloituspiste, hinta alkaen €4,500. Jatkuvaan omistajuuteen tarkoitettu Fractional CAIO -sopimus alkaa hinnasta €1,500 kuukaudessa. Voitte myös aloittaa maksuttomalla 30 minuutin tutustumispuhelulla sivustomme kautta. Nähdäksenne, miten työ etenee vaiheittain, lukekaa miten se toimii, tai tutustukaa Admin Portaliin, jossa käyttäjien roolit ja pääsyoikeudet hallitaan agenttien rinnalla.

UKK

Mitä eroa on roolilla ja oikeudella?

Oikeus on yksittäinen sallittu toiminto resurssiin, kuten laskun lukeminen tai kaupan muokkaaminen. Rooli on nimetty oikeuksien joukko, joka vastaa työtehtävää. Käyttäjille annetaan rooleja, ja roolit sisältävät oikeudet.

Riittääkö RBAC vai tarvitsenko ABAC:n?

Useimmille tiimeille RBAC on oikea lähtökohta, koska sen voi selittää ja auditoida helposti. Lisää ABAC-sääntöjä vasta, kun konteksti on merkityksellinen, esimerkiksi kun pääsyä rajataan alueen, kaupan koon tai ajan mukaan. Monet organisaatiot käyttävät molempia: RBAC:ia laajoihin tasoihin ja ABAC:ia hienojakoisiin yksityiskohtiin.

Kuinka monta roolia yrityksellä pitäisi olla?

Vakiomäärää ei ole. Sido roolit todellisiin työtehtäviin, anna jokaiselle omistaja ja käsittele kertaluonteiset tarpeet määräaikaisina poikkeuksina. Jos roolilla olisi vain yksi haltija, se on merkki siitä, että kyse on poikkeuksesta eikä roolista.

Kuinka usein rooleja ja pääsyoikeuksia pitäisi tarkistaa?

Määrittäkää säännöllinen aikataulu ja tehkää lisäksi tarkistus aina, kun joku vaihtaa tehtävää tai lähtee. IBM:n ohjeistus suosittelee määräajoin tehtäviä pääsyoikeuksien tarkistuksia, jotka keskittyvät poikkeuksiin ja poikkeaviin tapauksiin, sekä HR-tapahtumien laukaisemia automaattisia muutoksia. Valitkaa rytmi, jota tiiminne pystyy noudattamaan, sillä väliin jäänyt tarkistus on huonompi kuin kevyempi tarkistus.

Miten tekoälyagentit tulisi käsitellä RBAC-mallissa?

Kohdelkaa niitä henkilön puolesta toimivina, kyseisen henkilön roolilla eikä sitä laajemmilla oikeuksilla. Erottakaa luku- ja kirjoitusoikeudet, vaatikaa hyväksyntä arkaluonteisille toiminnoille ja pitäkää lokia jokaisesta toiminnosta. Päätökset siitä, kuka saa pääsyn, tulee jättää ihmisille.

Lähteet