Kirjoittaja: Veli-Pekka Vähälummukka, Trivoren Program Director
Moniroolinen arki pohjoismaisissa organisaatioissa
Vierailetpa missä tahansa suuressa suomalaisessa sairaalassa, niin takuuvarmasti tapaat lääkäreitä, jotka ovat samalla yliopiston tutkijoita. Osalla on vakituinen virka yhdessä sairaalassa, määräaikainen dosentuuri yliopistolla ja sijaisjärjestely toiseen hyvinvointialueeseen – kaikki samanaikaisesti voimassa. Jokaiseen rooliin liittyy eri järjestelmien käyttöoikeudet: potilastietojärjestelmä kliiniseen työhön, tutkimustietokannat yliopiston hankkeisiin ja erillinen potilaskertomusjärjestelmä sijaistyöhön.
Terveydenhuolto on näkyvin esimerkki, mutta sama rakenne toistuu kaikkialla pohjoismaisessa työelämässä. Opettaja voi hoitaa vakituista virkaansa, sijaistaa kollegaa toisessa aineessa ja vetää kerhotoimintaa – siis kolme erillistä suhdetta samaan työnantajaan, joista jokainen edellyttää omia järjestelmäoikeuksia. Julkisella sektorilla kuntien työntekijä saattaa istua samalla alueellisessa lautakunnassa ja johtaa kuntien yhteistä hanketta, kumpikin omalla mandaatillaan ja omilla käyttöoikeuksillaan.
Pohjoismaissa tämä on rakenteellisesti yleisempää kuin monilla muilla markkinoilla. Vahva työsuhdeturva tarkoittaa, että ihmiset kerryttävät rooleja sen sijaan, että vaihtaisivat yhdestä toiseen. Määräaikaiset sopimukset ovat arkipäivää sote-sektorilla ja koulutuksessa. Kunnallinen hallinto asettaa saman henkilön rutiininomaisesti useaan luottamustehtävään. Ja pohjoismainen erikoislääkärimalli, jossa asiantuntijat työskentelevät säännöllisesti organisaatiorajojen yli, lisää kerroksen lisää monimutkaisuutta.
Identiteetin- ja pääsynhallinnalle tämä tuottaa ongelman, joka nousee esiin joka viikko operatiivisessa arjessa. Mitkä käyttöoikeudet ovat voimassa, kun henkilöllä on kaksi aktiivista sopimusta? Mitä tapahtuu, kun yksi sopimus päättyy mutta kaksi muuta jatkuu? Useimmat IAM-järjestelmät käsittelevät henkilöä yhtenä kokonaisuutena, jolla on yksi työsuhteen tila. Kun henkilö jättää yhden roolin, järjestelmä joutuu valitsemaan kahdesta vaihtoehdosta: passivoi identiteetin tai jättää kaiken ennalleen. Kumpikaan ei ole oikein.
Yleisin käytäntö on passivoida henkilö kokonaan. Se tappaa pääsyn kaikkiin aktiivisiin rooleihin. Vaihtoehto on olla passivoimatta, jolloin päättyneen roolin käyttöoikeudet jäävät roikkumaan voimassa olevien rinnalle. Molemmat polut tuottavat operatiivisia ongelmia, molemmat tuottavat vaatimustenmukaisuusriskejä ja molemmat syövät IT-tiimin aikaa manuaaliseen siivoamiseen, jota ei pitäisi tarvita lainkaan.
Miksi perinteinen roolimalli ei riitä
Useimmissa organisaatioissa käytössä oleva IAM-arkkitehtuuri on suunniteltu yksinkertaisempaan maailmaan: yksi henkilö, yksi työsuhde, yksi roolijoukko. Identiteettiobjekti edustaa ihmistä. Roolit kiinnitetään suoraan identiteettiin. Työsuhteen tila, aktiivinen tai passiivinen, ohjaa sitä onko pääsy päällä vai pois.
Tämä toimii riittävän hyvin, kun jokaisella henkilöllä on täsmälleen yksi suhde organisaatioon. Ja se hajoaa heti, kun tämä oletus ei enää pidä.
Kun sairaala tarvitsee lääkärille pääsyn kliinisiin järjestelmiin, mutta sama henkilö on jo järjestelmässä tutkijana, IT-tiimi improvisoi. He tekevät manuaalisia roolimäärityksiä normaalin provisioinnin ohi. He rakentavat poikkeuslistoja ja myöntävät ”väliaikaisia” korotettuja oikeuksia, jotka hiljaa muuttuvat pysyviksi, koska kukaan ei omista niiden tarkistusprosessia. He merkitsevät tilin muistiinpanolla Excel-taulukkoon, jotta joku muistaa tarkistaa asian seuraavassa käyttöoikeuskatselmuksessa.
Nämä kiertotiet toimivat siinä mielessä, että ihmiset saavat tarvitsemansa pääsyn. Mutta ne synnyttävät toisenlaisen ongelman: jäljitysketju menettää merkityksensä. Kun käyttöoikeus on myönnetty esihenkilön ja IT-tukihenkilön välisen keskustelun perusteella eikä sääntöpohjaisen politiikan kautta, auditoijalle ei voi osoittaa, miksi henkilöllä on kyseiset oikeudet. Voi ainoastaan osoittaa, että joku painoi joskus nappia.
NIS2-direktiivin kansallinen toimeenpano – kyberturvallisuuslaki – on nyt voimassa Suomessa. Se edellyttää, että pääsynhallinta noudattaa dokumentoituja toimintaperiaatteita ja jäljitettäviä päätösketjuja. ISO 27001, jota monet pohjoismaiset organisaatiot käyttävät perusviitekehyksenään, vaatii samaa. Manuaalisesti koottu roolien kokoelma ilman hallintalogiikkaa ei täytä kumpaakaan vaatimusta.
Seuraukset eivät ole teoreettisia. Tammikuussa 2025 nousi julkisuuteen tapaus HUSissa, jossa lääkäri oli käynyt katsomassa entisen esimiehensä potilastietoja ilman hoitosuhdetta. Tapauksesta tuli rikosasia. Vaikka juurisyy oli yksittäisen henkilön väärinkäytös, rakenteellista kysymystä on vaikea sivuuttaa: miksi pääsy oli ylipäätään olemassa? Hyvin hallitussa identiteettimallissa potilastietojen käyttöoikeus pitäisi olla sidottu aktiiviseen hoitosuhteeseen, eli sopimukseen, eikä laajaan rooliin, joka elää sen jälkeenkin, kun sen perustellut tehtävä on päättynyt.
HUS-tapaus on ääriesimerkki, mutta sen taustalla oleva kuvio on arkinen. Jokaisessa organisaatiossa, joka pyörittää perinteistä roolimallia, tietty osuus nykyisistä käyttöoikeuksista ei ole jäljitettävissä ajankohtaiseen liiketoimintaperusteeseen. Mitä suurempi organisaatio ja mitä enemmän moniroolisia työntekijöitä, sitä leveämmäksi tuo aukko kasvaa.
Sopimusperusteinen identiteettimalli käytännössä
Perinteiselle roolimallille on vaihtoehto, ja se lähtee liikkeelle toisenlaisesta perusobjektista. Sen sijaan, että roolit kiinnitetään suoraan henkilöön, henkilön ja käyttöoikeuksien väliin tuodaan uusi kerros: sopimus.
Sopimus on tässä yhteydessä deklaratiivinen kuvaus henkilön ja organisaation välisestä suhteesta. Se ei ole juridinen asiakirja, vaan tietomalli-objekti, joka edustaa tiettyä tehtävää, työsuhdetta, mandaattia tai toimeksiantoa. Jokaisella sopimuksella on omat metatietonsa: alkamispäivä, päättymispäivä, tarkistuspäivämäärät, organisaatioyksikkö ja säännöt, jotka ohjaavat, mitä tapahtuu sopimuksen päättyessä.
Yhdellä henkilöllä voi olla useita sopimuksia samanaikaisesti voimassa. Aiemman esimerkkimme sairaalalääkärillä olisi kolme: yksi vakituiselle kliiniselle tehtävälle, yksi yliopiston tutkimustehtävälle ja yksi sijaisjärjestelylle. Kukin sopimus hallitsee itsenäisesti niitä käyttöoikeuksia, joita se perustelee.
Tällä on useita käytännön seurauksia, jotka muuttavat identiteettihallinnan arkea:
- Rinnakkaiset sopimukset. Kun opettaja ottaa sijaistehtävän toisessa aineessa, luodaan uusi sopimus. Se elää rinnakkain vakituisen sopimuksen kanssa. Kumpikin sopimus ohjaa omaa käyttöoikeusjoukkoaan. Ei törmäyksiä, ei manuaalisia ohituksia, ei epäselvyyttä siitä, miksi mikäkin oikeus on olemassa.
- Tulevaisuuteen ajoittaminen. Ensi vuosineljänneksellä aloittavan uuden työntekijän sopimus voidaan luoda tänään. Sopimukselle asetetaan tuleva alkamispäivä. Provisiointi tapahtuu ennakkoon – tilit luodaan, käyttöoikeudet valmistellaan – mutta mikään ei aktivoidu ennen sopimuksen alkamispäivää. Ei enää ensimmäisen työpäivän kaaosta, jossa uusi työntekijä istuu työpisteellään odottamassa IT:n kirimistä perässä.
- Itsenäinen elinkaari. Kun sijaussopimus päättyy, vain siihen sidotut käyttöoikeudet poistetaan. Lääkärin vakituinen sairaalan sopimus ja yliopistosopimus jatkavat häiriöttä. Koko identiteettiä ei tarvitse kytkeä päälle tai pois. Jokainen sopimus hallitsee omaa elinkaartaan itsenäisesti.
- Sijaishallinta ja poissaolot. Kun työntekijä jää vanhempainvapaalle, hänen sopimuksensa voidaan pysäyttää ja sijaistajalle luodaan aikarajattu sopimus. Sijainen saa täsmälleen tarvitsemansa käyttöoikeudet, jotka on rajattu poissaolon kestoon. Kun alkuperäinen työntekijä palaa, hänen sopimuksensa jatkuu ja sijaisen käyttöoikeudet päättyvät automaattisesti.
- Sopimuksiin rajattu käyttöoikeuksien hallinta. RBAC (roolipohjainen), OrBAC (organisaatiopohjainen) ja ABAC (attribuuttipohjainen) pääsynhallinta ovat kaikki edelleen käytössä, mutta ne rajataan sopimuksiin sen sijaan, että ne kiinnitettäisiin suoraan henkilöön. Tämä tarkoittaa, että samalla henkilöllä voi olla eri oikeustasot eri konteksteissa, eri politiikkojen hallinnassa, ilman ristiriitoja käyttöoikeusmallissa.
Tuotantototeutuksessa – esimerkiksi Trivoren eIAM-alustalla, joka käyttää sopimusperusteista mallinnusta keskeisenä arkkitehtuuriperiaatteenaan – sopimukset käsittelee sääntömoottori, joka muuntaa ne konkreettisiksi käyttöoikeuksiksi. Muutokset välitetään tapahtumaväylän kautta alavirtajärjestelmiin. Sopimus on totuuden lähde; käyttöoikeudet johdetaan siitä. Tämä tarkoittaa, että järjestelmä pystyy aina vastaamaan kysymykseen: ”Miksi tällä henkilöllä on tämä käyttöoikeus?” Vastaus ei koskaan ole ”koska joku pyysi sitä kolme vuotta sitten”. Se on aina ”koska tämä aktiivinen sopimus edellyttää sitä.”
Todelliset tulokset
Sopimusperusteiseen identiteettimalliin siirtyneet organisaatiot raportoivat johdonmukaisia operatiivisia parannuksia, vaikka yksityiskohdat vaihtelevat toimialan ja mittakaavan mukaan.
Nopeampi perehdytys moniroolisille työntekijöille. Kun uusi sopimus on ainoa asia, jota tarvitaan määritellyn käyttöoikeusjoukon myöntämiseen, henkilön ottaminen toiseen tai kolmanteen rooliin vaatii minuutteja hallinnollista työtä – ei päivien mittaista IT-pyyntöprosessia. Tulevaisuuteen ajoitetut sopimukset tarkoittavat, että käyttöoikeudet ovat valmiina ennen ensimmäistä työpäivää.
Siisti offboarding ilman sivuvahinkoja. Yhden roolin päättyminen ei enää laukaise kiirettä selvittää, mitä muuta henkilö vielä tarvitsee. Päättynyt sopimus vie mukanaan omat käyttöoikeutensa. Kaikki muu pysyy. Tämä poistaa yhden yleisimmistä IT-eskalaatioiden lähteistä: ihmiset menettävät käyttöoikeudet, joita he vielä tarvitsevat, koska joku passivoi väärän asian.
Jäljitettävä kirjausketju. Jokainen käyttöoikeus on linkitetty sopimukseen. Jokaisella sopimuksella on omistaja, peruste ja elinkaari. Auditoija pystyy jäljittämään minkä tahansa oikeuden siihen liiketoimintasuhteeseen, joka sen valtuutti. Tämä ei ole jälkikäteen tuotettua dokumentaatiota – se on rakennettu osaksi operatiivista mallia.
Vähemmän manuaalista IT-työtä. Suunnittelutavoite rutiininomaisille JML-prosesseille (tulijat, siirtyjät, lähtijät) on 80 prosentin automaatioaste. Se tarkoittaa, että valtaosa sopimusten luomisesta, käyttöoikeuksien provisioinnista, käyttöoikeuksien poistosta ja sopimusten päättämisestä tapahtuu ilman, että ihminen koskee tikettiin. IT-tiimit käyttävät aikansa poikkeuksiin ja monimutkaisiin tapauksiin rutiininomaisen tuli-siirtyi-lähti-prosessoinnin sijaan.
Vahvempi NIS2-vaatimustenmukaisuusasema. NIS2 edellyttää dokumentoituja pääsynhallintapolitiikkoja, jäljitettävää päätöksentekoa ja kykyä osoittaa, että käyttöoikeudet ovat oikeassa suhteessa liiketoimintatarpeeseen. Sopimusperusteinen malli tarjoaa rakenteellisen perustan kaikille kolmelle vaatimukselle, koska sopimus itse on dokumentoitu, auditoitava perustelu jokaiselle sen myöntämälle oikeudelle.
Onko identiteettimallisi sopimustietoinen?
Jos hallinnoit identiteettejä suuressa organisaatiossa, jossa on moniroolisia työntekijöitä, alihankkijoita tai monimutkaisia henkilöstörakenteita, nämä viisi kysymystä kannattaa esittää nykyisestä järjestelmästäsi:
1. Pystyykö IAM-järjestelmäsi esittämään kaksi aktiivista työsuhdetta samalle henkilölle ilman kahden erillisen identiteetin luomista? Jos vastaus on ei, joudut joko monistamaan identiteettejä (mikä luo omat hallintapainajaisensa) tai pakottamaan monirooliset ihmiset yhteen tasaiseen rakenteeseen, joka ei pysty mallintamaan heidän todellista tilannettaan.
2. Kun yksi työsuhde päättyy, poistaako järjestelmäsi vain kyseiseen työsuhteeseen sidotut käyttöoikeudet? Vai passivoiko se koko identiteetin tai jättääkö se kaikki oikeudet voimaan, koska joku pelkää rikkovansa muut roolit?
3. Voitko ajoittaa käyttöoikeuksien aktivoinnin tulevaisuuteen, sidottuna ensi kuussa alkavaan sopimukseen? Vai tapahtuuko provisiointi vasta, kun joku lähettää tiketin alkamispäivänä tai sen jälkeen?
4. Voitko mallintaa sijaisuussuhteita automaattisella päättymisellä? Kun joku hoitaa poissaolevan kollegan tehtäviä, onko sijaisen käyttöoikeuksilla sisäänrakennettu päättymispäivä vai jäävätkö ne voimaan, kunnes joku muistaa poistaa ne?
5. Pystytkö osoittamaan auditoijalle minkä tahansa käyttäjän kohdalla, mikä liiketoimintasuhde perustelee jokaisen hänen nykyisistä käyttöoikeuksistaan?
Jos useampi kuin yksi näistä kysymyksistä paljasti aukon, ongelma on todennäköisesti arkkitehtuurinen. Lisäprosessien kerrostaminen perinteisen roolimallin päälle ei ratkaise sitä – se lisää kustannuksia ja monimutkaisuutta korjaamatta perimmäistä ongelmaa.
Sopimusperusteinen identiteettimallinnus on yksi tapa ratkaista nämä aukot rakenteellisesti. Jos haluat selvittää, miltä se näyttäisi teidän ympäristössänne, se on keskustelun arvoinen asia.