IAM ja IGA käytännössä: Näin yhdistät sujuvan työnteon ja tiukan tietoturvan

Kuvitellaan tilanne: uusi työntekijä, Laura, aloittaa maanantaiaamuna taloushallinnossa. Hän saa itselleen työläppärin, sähköpostitunnukset sekä pääsyn useisiin järjestelmiin. Teoriassa kaiken pitäisi siis olla kuten pitääkin ja työn lähteä käyntiin sujuvasti.

Mutta kuka päätti, mihin järjestelmiin Laura pääsee käsiksi? Ja kuka varmistaa, että oikeudet pysyvät ajan tasalla myös puolen vuoden päästä, kun hänen roolinsa muuttuu?

Moni organisaatio törmää vastaaviin haasteisiin. Siinä vaiheessa esiin nousevat IAM ja IGA, jotka mainitaan usein yhdessä ja jotka myös sekoittuvat helposti keskenään.

IAM ja IGA liittyvät molemmat identiteetteihin ja käyttöoikeuksiin. Näkökulmat kuitenkin eroavat selvästi:

IAM vastaa kysymykseen, kuka käyttäjä on ja mihin hän pääsee.
IGA puolestaan arvioi, pitäisikö käyttäjällä ylipäätään olla kyseinen pääsy.

Toisin sanoen IAM myöntää käyttöoikeuden. IGA varmistaa, että oikeus perustuu sääntöihin ja vastaa organisaation linjauksia.

IAM mahdollistaa sujuvan käyttäjäelinkaaren hallinnan

IAM muodostaa identiteetinhallinnan teknisen perustan. Sen ytimessä toimivat käyttäjän tunnistaminen, valtuuttaminen ja pääsyn mahdollistaminen sovelluksiin.

Kun uusi työntekijä aloittaa ja saa tunnukset, roolit sekä pääsyn yrityksen palveluihin, hoitaa IAM prosessin. Se varmistaa, että kirjautuminen toimii, oikeudet osuvat kohdalleen ja käyttökokemus pysyy sujuvana. Samalla automaatio vähentää manuaalista työtä ja virheiden riskiä.

Lauran tapauksessa IAM käynnistää automaattisesti useita tapahtumia: järjestelmä luo käyttäjätunnuksen, liittää hänet oikeaan rooliin ja avaa pääsyn taloushallinnon sovelluksiin. Ensimmäinen kirjautuminen onnistuu ilman tukipyyntöjä, ja työ pääsee alkamaan heti.

Ilman IAM-ratkaisua samat vaiheet vaatisivat useita manuaalisia toimenpiteitä eri tiimeiltä. Yksi virhe riittäisi katkaisemaan pääsyn tai avaamaan oikeuksia liikaa.

IGA tuo käyttöoikeuksiin hallinnan ja valvonnan

Muutaman kuukauden kuluttua Laura siirtyy uuteen tehtävään. Osa vanhoista käyttöoikeuksista ei enää kuulukaan hänen rooliinsa, mutta ne eivät maagisesti katoa itsestään. Tässä vaiheessa IGA astuu kuvaan.

IGA ohjaa käyttöoikeuksien tarkastuksen, pyytää esihenkilöltä hyväksynnän ja poistaa tarpeettomat oikeudet. Samalla järjestelmä tallentaa audit trailin, josta selviää, kuka hyväksyi muutoksen ja millä perusteella.

IGA lähestyy käyttöoikeuksia governance-näkökulmasta. Se arvioi pääsyn oikeellisuutta ja turvallisuutta sen sijaan, että keskittyisi tekniseen toteutukseen. Tarkasteluun nousevat riskitasot, minimikäyttövaltuudet ja sääntelyn vaatimukset.

Samalla määritellään, kuka hyväksyy käyttöoikeuden ja kuka omistaa sen. Politiikat, sertifioinnit ja audit trailit kattavat oikeuksien koko elinkaaren ja estävät niiden huomaamattoman kasaantumisen.

Rajat hämärtyvät käytännössä

IAM ja IGA toimivat kuin työpaikan kulunvalvonta ja esihenkilön päätösvalta. IAM huolehtii siitä, että kulkukortti toimii ovella. IGA varmistaa, että kortti avaa juuri ne ovet, jotka työntekijän tehtävät edellyttävät.

Nykyisin raja IAM:n ja IGA:n välillä ei enää pysy yhtä selkeänä kuin aiemmin. IAM-ratkaisut sisältävät yhä useammin IGA:lle tyypillisiä toimintoja, kuten käyttöoikeuspyyntöjen hyväksyntäketjuja, kevyitä access review -toimintoja ja yksinkertaista riskilogiikkaa.

Samaan aikaan IGA-ratkaisut laajenevat IAM-alueelle. Ne lisäävät automaattista provisiointia, roolien teknistä orkestrointia ja identiteetin elinkaaren ohjausta taustajärjestelmiin. Toiminnot limittyvät teknisesti, vaikka lähestymistavat eroavat edelleen toisistaan.

Käytännössä Laura voi nyt pyytää uutta käyttöoikeutta suoraan portaalista. IAM hoitaa teknisen toteutuksen. IGA määrittää hyväksyntäketjun ja arvioi riskin. Käyttäjän näkökulmasta prosessi näyttäytyy yhtenä kokonaisuutena.

Molempia tarvitaan modernissa identiteettistrategiassa

IAM luo perustan identiteetin tekniselle hallinnalle ja sujuvalle pääsylle. IGA taas varmistaa, että pääsy pysyy hallittuna, läpinäkyvänä ja riskienhallinnan mukaisena.

Lauran työpäivä pysyy sujuvana vain silloin, kun pääsyt toimivat oikein ja oikeudet vastaavat todellista tarvetta. IAM mahdollistaa työnteon ja IGA varmistaa, että työ tapahtuu hallitusti ja turvallisesti.

Yhdessä ne muodostavat identiteettistrategian, joka tukee sekä liiketoimintaa että riskienhallintaa. Raja ei enää muistuta selkeää viivaa, vaan jatkumoa, jossa painotukset vaihtelevat organisaation tarpeiden mukaan.

Miten IAM ja käyttövaltuushallinta toimii – lyhyt oppimäärä käytännön esimerkein

Organisaatioissa on tärkeää, että oikeat ihmiset ja palvelut pääsevät oikeisiin tietoihin – mutta eivät enempään kuin on tarpeen. Tämä onnistuu, kun identiteetin- ja pääsynhallinta (IAM) sekä käyttövaltuushallinta (KVH) ovat kunnossa.

IAM kattaa kaiken sen, miten organisaation käyttäjät tunnistetaan ja miten heidän pääsyään tietoihin hallitaan. KVH on osa tätä kokonaisuutta: se keskittyy käyttöoikeuksien myöntämiseen, muuttamiseen ja poistamiseen elinkaaren eri vaiheissa.

Tieto on kaiken ydin ja omaisuus, jota IAM:n avulla suojellaan

Organisaation arvokkain omaisuus on tieto, kuten asiakastiedot, sopimukset, henkilöstödata ja suunnitelmat. Tietoaineistot ovat hajallaan eri järjestelmissä, mutta yhdessä ne muodostavat tietovarannon, jota IAM ja KVH suojaavat.

Käytännön esimerkkejä

Terveydenhuolto: Potilastiedot löytyvät potilastietojärjestelmästä, laboratoriotulokset erillisestä järjestelmästä ja kuvantamistiedot PACS-järjestelmästä. Lääkäri tarvitsee pääsyn kaikkiin näihin tietoihin hoitaakseen potilasta turvallisesti. KVH auttaa varmistamaan, että vain hoitohenkilökunta näkee tiedot ja vain silloin, kun heillä on siihen lupa.
Pankki: Asiakastiedot sijaitsevat CRM:ssä, maksutiedot maksujärjestelmässä ja luottopäätökset riskienhallintajärjestelmässä. Kassatyöntekijä pääsee maksutietoihin, mutta ei näe luottopäätöksiä, kun taas riskienhallintatiimi käsittelee luottopäätökset. IAM ja KVH pitävät tiedot turvassa ja varmistavat, että kukin pääsee vain tarpeelliseen tietoon.

Identiteetti ja sopimus luovat perustan

Kaikki alkaa identiteetistä – henkilöstä, palvelusta tai laitteesta. Kun henkilö liittyy organisaatioon, tehdään sopimus, jossa sovitaan esimerkiksi työ-/virkasuhteen ehdoista. Usein yhdellä henkilöllä voi olla useita sopimuksia, sillä hänellä voi olla useita rooleja tai erilaisia työsuhteita tai hän voi olla organisaation palveluksessa sekä suoraan että palveluntarjoajan kautta.

Vastaavasti IAM-maailmassa digitaalinen identiteetti syntyy samalla, kun siihen liitetään sopimukset, joiden perusteella myönnetään käyttöoikeuksia. Monisopimushallinta on olennainen osa toimivaa IAM-ratkaisua.

Käytännön esimerkkejä

Terveydenhuolto: Uusi lääkäri liittyy sairaalan henkilökuntaan ja saa automaattisesti pääsyn potilastietojärjestelmään, reseptipalveluun sekä hoitosuunnitelmiin. Hän pystyy heti tarkistamaan potilastiedot ja määräämään tarvittavat lääkkeet, ilman että IT-osaston täytyy käsin myöntää oikeuksia.
Julkishallinto: Uusi virkamies aloittaa virastossa ja saa heti pääsyn asianhallintajärjestelmään, sähköpostiin ja dokumenttiarkistoon. Hän voi osallistua kokouksiin, käsitellä asiakirjoja ja hoitaa tehtävänsä turvallisesti heti ensimmäisestä päivästä alkaen.
Koulutus: Uusi opettaja saa tunnukset oppimisympäristöön ja sähköiseen arviointijärjestelmään. Hän voi heti luoda oppitunteja, seurata opiskelijoiden suorituksia ja palauttaa arviointeja, ilman viiveitä tai ylimääräistä byrokratiaa.

Pääsy perustuu rooleihin ja tehtäviin

Oikeudet määräytyvät työtehtävien mukaan. Näin varmistetaan, että jokainen pääsee vain siihen tietoon, mitä tehtävissään tarvitsee. Käyttöoikeudet koostetaan usein rooleihin, jotka voivat olla esimerkiksi ”HR-asiantuntija” tai ”IT-tuki”. Roolit puolestaan jaetaan usein ryhmien kautta, jolloin hallinta helpottuu.

Käytännön esimerkkejä:

Pankki: Kassatyöntekijä käsittelee asiakasmaksutapahtumia kassalla. Hän näkee kaikki maksutiedot, mutta ei pääse lukemaan tai muuttamaan luottopäätöksiä. Tämä varmistaa, että arkaluonteiset päätökset pysyvät riskienhallintatiimin vastuulla.
Teollisuus: Huoltoteknikko pääsee käsiksi koneiden huoltotietoihin ja huoltokirjauksiin. Hän ei näe tuotannon suunnittelujärjestelmää, joten suunnittelutiedot pysyvät hallinnon vastuulla. Näin tuotannon tiedot pysyvät turvassa ja virheet vähenevät.

Politiikat ja ehdot täydentävät rooleja

Roolien kautta annettujen oikeuksien tarkkuus ei aina riitä. Politiikat (Policy-Based Access Control, PBAC) ja ehdot (Attribute-Based Access Control, ABAC) tuovat käyttöoikeuksiin joustavuutta ja turvallisuutta.

Käytännön esimerkkejä

Attribute-Based Access Control (ABAC): Terveydenhuollossa lääkäri pääsee käsiksi potilastietoihin vain, jos hän työskentelee sairaalan verkossa ja potilas kuuluu hänen hoitovastuulleen. Näin lääkäri voi hoitaa potilasta turvallisesti, mutta ulkopuoliset eivät pääse tietoihin edes vahingossa.
Policy-Based Access Control (PBAC): Pankissa luottopäätöksiä saa tehdä vain riskienhallintaryhmän jäsen, joka on kirjautunut sisäverkon kautta. Politiikka yhdistää useita ehtoja yhdeksi kokonaisuudeksi ja estää väärinkäytökset, samalla kun oikeat käyttäjät voivat hoitaa tehtävänsä sujuvasti.

Käyttövaltuushallinta (KVH) hallitsee elinkaaren

KVH prosessi varmistaa, että oikeudet ovat ajan tasalla. Se sisältää muun muassa: JML-prosessin (Joiner, Mover, Leaver), pääsypyynnöt ja hyväksynnät, provisioinoinnin eri järjestelmiin sekä säännölliset tarkastukset ja auditoinnit

Käytännön esimerkkejä

Terveydenhuolto: Kun sijaislääkäri lähtee, käyttövaltuushallinta poistaa automaattisesti kaikki hänen käyttöoikeutensa, jotta potilastiedot pysyvät turvassa, eikä kukaan ulkopuolinen pääse niihin käsiksi.
Teollisuus: Työntekijän siirtyessä tuotannosta hallintoon vanhat oikeudet poistuvat ja uudet lisätään automaattisesti. Näin hän pääsee heti kiinni hallinnon tehtäviin, mutta ei enää vahingossakaan muokkaa tuotantotietoja.
Koulutus: Kun opiskelija valmistuu, hänen tunnuksensa poistetaan kaikista järjestelmistä, mikä estää pääsyn koulun tietoihin ja varmistaa tietoturvan.

IAM ja KVH integroivat teknologian ja turvallisuuskulttuurin. Kun identiteetit, roolit ja politiikat toimivat oikein, organisaatio pystyy suojaamaan tietonsa ja tekemään työnsä tehokkaasti.

Kun kaikki on hallinnassa

Kun identiteetit, roolit ja oikeudet on määritelty selkeästi, arki sujuu ilman turhia esteitä – ja tieto pysyy turvassa.

Hyvin rakennettu IAM ja käyttövaltuushallinta tukevat organisaation toimintaa monella tasolla: ne nopeuttavat uusien työntekijöiden aloitusta, helpottavat tehtävävaihdoksia, vähentävät virheitä ja tukevat tietosuojavaatimusten noudattamista. Kun oikeudet pysyvät ajan tasalla ja prosessit toimivat automaattisesti, työ tehostuu, työntekijöiden tyytyväisyys paranee ja myös IT:n kuorma kevenee.

Tärkeintä on ymmärtää, että IAM ei ole kertaluonteinen projekti, vaan jatkuva prosessi – osa organisaation hyvää hallintoa ja tietoturvakulttuuria. Kun identiteettien ja käyttöoikeuksien hallinta on kunnossa, tieto on oikeissa käsissä oikeaan aikaan – ja kaikki toimii niin kuin pitääkin.

Zero Trust: Tietoturvan sipuli, joka pysäyttää hyökkääjän

Ei niin kaukaisessa historiassa yrityksen tietoturva perustui palomuuriin. Rakenne muistutti linnaa ja vallihautaa: kun pääsit portista sisään, olit turvassa. Se aika on ohi.

Nykyään data on pilvessä ja työntekijät voivat työskennellä missä tahansa. Siksi vanha malli, jossa sisäverkkoon pääsy tarkoitti automaattista luottamusta, ei enää toimi. Tätä ongelmaa ratkaisemaan on rakentunut Zero Trust -ajattelu.

Zero Trust kuulostaa ehkä siltä, että emme luota kehenkään. Ja teknisesti se pitää paikkansa. Malli nojaa yksinkertaiseen periaatteeseen: kukaan ei saa luottamusta ilman tarkistusta. Jokainen käyttäjä, laite ja sovellus tarkistetaan joka kerta, kun ne haluavat käyttää jotain resurssia. Toisin kuin perinteisessä mallissa, luottamus ei perustu pelkästään sijaintiin tai verkkoon, vaan jatkuvaan varmistukseen.

Kerros kerrokselta vahvempi suoja

Miksi tämä sitten on tärkeää? Koska pilvimaailmassa hyökkääjät eivät enää kolkuttele portilla, vaan he ovat jo sisällä. Jos järjestelmäsi luottaa sokeasti sisäverkkoon, olet pulassa.

Zero Trust estää tämän tarkistamalla kaiken, aina. Se ei ole yksi työkalu, vaan kokonainen arkkitehtuuri, jossa jokainen kerros lisää suojaa.

Voit ajatella sitä esimerkiksi kuin sipulia: jos hyökkääjä pääsee yhden kerroksen läpi, seuraava pysäyttää hänet. Näin pienennetään todennäköisyyttä siitä, että murtautuja pääsee käsiksi arvokkaaseen dataan ja tehdään murtautumisesta niin kallista, ettei sitä edes kannata yrittää.

Kerroksellisuus näkyy monella tasolla:

Monivaiheinen tunnistus varmistaa, ettei pelkkä salasana riitä.
Laitetarkistus estää pääsyn, jos kone on epäluotettava.
Pienimmän oikeuden periaate taas rajoittaa käyttäjän pääsyn vain siihen, mitä hän työssään tarvitsee.

Ja jos kaikki tämä pettää, jatkuva valvonta ja käyttäytymisanalytiikka voivat silti havaita poikkeavan toiminnan ja katkaista istunnon. Jokainen kerros tekee hyökkäyksestä hitaamman, kalliimman ja helpommin havaittavan.

Konkreettinen esimerkki: Näin Zero Trust torjuu hyökkäyksen

Kuvitellaan valitettavan yleinen tilanne, jossa hyökkääjä saa haltuunsa työntekijän salasanan tietojenkalastelulla. Perinteisessä mallissa tämä voisi tarkoittaa täyttä pääsyä sisäverkkoon ja kriittisiin järjestelmiin. Sen sijaan Zero Trust -malli rakentaa useita esteitä hyökkääjän tielle.

Ensimmäinen este on monivaiheinen tunnistus, jolloin pelkkä salasana ei enää riitä. Jos hyökkääjä onnistuu ohittamaan sen, laitetarkistus huomaa, että kirjautuminen tulee tuntemattomalta koneelta ja estää pääsyn. Jos laitekin hyväksytään – vaikkapa varastetun yritysläppärin avulla – käyttäjän oikeudet ovat rajatut, eikä hyökkääjä pääse käsiksi kaikkeen, vaan vain siihen, mitä kyseinen työntekijä tarvitsee. Ja jos hyökkääjä yrittää ladata massoittain tiedostoja, käyttäytymisanalytiikka havaitsee poikkeaman ja katkaisee istunnon.

Lopputulos: hyökkääjä joutuu ylittämään monta estettä, ja jokainen niistä lisää mahdollisuuden havaita ja pysäyttää hyökkäys ennen kuin arvokas data vaarantuu.

Zero Trust ei siis ole epäluottamusta ihmisiin, vaan epäluottamusta oletuksiin. Ja se on hyvä asia.

Mikä on OIDC ja miksi se on tärkeä?

Organisaatioissa, joissa käytetään useita digitaalisia palveluita, on käyttäjien tunnistaminen keskeinen turvallisuus-, kustannus- ja hallintakysymys. Kun henkilöstö, asiakkaat tai kumppanit liikkuvat useissa järjestelmissä, nousee identiteetin- ja pääsynhallinta (IAM)olennaiseen rooliin. Yksi ratkaiseva komponentti tässä kokonaisuudessa on OpenID Connect (OIDC).

Vaikka OIDC ei lyhenteenä tai teknologiana olisikaan tuttu, niin uskaltaisin väittää, että meistä jokainen on OIDCta hyödyntävää palvelua käyttänyt useamman kerran viimeisen viikon aikana. Jos olet kirjautunut johonkin palveluun pankkitunnuksilla tai lukenut vaikkapa gmailia, niin mitä suurimmalla todennäköisyydellä OIDC on se protokolla, jolla noihin palveluihin kirjauduit.

OIDC on moderni, standardoitu protokolla, jonka avulla käyttäjien kirjautuminen voidaan keskittää yhteen luotettuun identiteetinhallintapalveluun. Sen avulla organisaatio voi hallita käyttäjätunnuksia, oikeuksia ja tunnistautumista yhtenäisesti, sen sijaan, että jokainen sovellus tai järjestelmä toteuttaisi oman, irrallisen kirjautumisratkaisunsa.

Kuka omistaa käyttäjien digitaalisen identiteetin?

Yksi kriittinen, mutta usein aliarvioitu näkökulma tunnistautumiseen on identiteetin omistajuus. Kun käyttäjähallinta hajautuu eri palveluihin ja ulkoisiin kirjautumisjärjestelmiin, menettää organisaatio hallinnan käyttäjäidentiteeteistään ja samalla myös näkyvyyden, vastuun sekä mahdollisuuden valvoa pääsyjä.

OIDC tuo identiteetit takaisin organisaation hallintaan. Vaikka sovellukset tulevat eri toimittajilta tai valmiina palveluina, säilyy identiteetti omassa järjestelmässä. Yksittäiset sovellustoimittajat eivät siis enää ohjaa pääsyä käyttäjätietoihin.

Erityisesti muutostilanteissa tämä tuo turvaa. Palveluntarjoajan vaihtuessa, liiketoiminnan laajentuessa tai palvelun päättyessä organisaatio säilyttää jatkuvuuden. Tunnistus ei sitoudu teknologiaan tai kumppaniin, vaan pysyy omissa käsissä.

Kustannussäästöjä kehityksessä, tuessa ja riskienhallinnassa

Kun kirjautuminen toteutetaan OIDC:n avulla keskitetysti, yksittäisten sovellusten ei tarvitse sisältää omaa käyttäjähallintaa. Tämä tarkoittaa vähemmän kehitystyötä, ylläpitoa ja tietoturva-auditointeja. Sovellukset käyttävät siis vain yhtä ja samaa tunnistuspalvelua, ja myös käyttäjätunnukset hallitaan yhdestä paikasta.

Myös tukitarve kevenee. Yksi tunnus, yksi kirjautuminen ja selkeät käyttöoikeudet pienentävät huomattavasti salasanoihin ja käyttöoikeuksiin liittyviä tukipyyntöjä, joiden tiedetään olevan yksi IT-tuen suurimmista yksittäisistä kulueristä.

Riskienhallinta tehostuu, sovellukset eivät käsittele salasanoja ja pääsynvalvonta tapahtuu keskitetysti. Käyttäjien poistaminen, monivaiheinen tunnistautuminen (MFA) ja roolipohjainen pääsynhallinta hoituvat samasta paikasta.

Skaalautuvuutta ja joustavuutta liiketoiminnan muuttuessa

Kun tunnistautuminen on irrotettu yksittäisistä järjestelmistä ja toteutettu OIDC:n avulla, organisaatio voi nopeammin ottaa käyttöön uusia palveluita, vaihtaa toimittajia tai yhdistää järjestelmiä. Identiteetti pysyy koko ajan omissa käsissä, ja integraatiot tapahtuvat standardoidulla tavalla.

Tämä on kriittistä erityisesti silloin, kun organisaatio kasvaa, toimii monitoimittajaympäristössä tai tarjoaa palveluita eri käyttäjäryhmille, kuten työntekijöille, kumppaneille tai asiakkaille.

OIDC on liiketoimintapäätös, eikä pelkkä tekninen valinta

OIDC muodostaa IAM-arkkitehtuurin ytimen ja on ratkaiseva työkalu turvallisen ja skaalautuvan digitaalisen ympäristön rakentamisessa. Sen avulla organisaatio voi pitää käyttäjäidentiteetit omassa hallinnassaan sekä vähentää IT-kustannuksia kehityksessä, tuessa ja ylläpidossa. Lisäksi OIDC parantaa tietoturvaa ja vähentää riskejä, nopeuttaa integraatioita ja palveluiden käyttöönottoa sekä varmistaa jatkuvuuden palveluntarjoajista riippumatta.

Lopulta kyse on siitä, haluaako organisaatio olla riippuvainen yksittäisistä järjestelmistä ja toimittajista – vai hallita omaa digitaalista tulevaisuuttaan. OIDC ei ole enää pelkkä tekninen standardi, vaan strateginen valinta, joka määrittää, kuinka joustavasti ja turvallisesti organisaatio pystyy toimimaan myös huomenna. Siksi jokaisen uuden järjestelmän tai palvelun kohdalla kannattaa varmistaa, että se tukee OIDC:tä vahvasti ja helppokäyttöisesti.

Minimikäyttöoikeuden periaate: Miksi ”samat käyttöoikeudet kuin Kallella” -malli ei toimi

Mikä on minimikäyttöoikeuden periaate?

Yksi keskeisimmistä tietoturvaperiaatteista on minimikäyttöoikeuden periaate (principle of least privilege). Ajatus ei ole uusi, mutta sen jalkauttaminen organisaatioiden arkeen vaikuttaisi olevan monilla vielä kesken. Julkishallinnon osalta periaate on nähty niin tärkeäksi, että sen perusajatus on kirjattuna jopa lakiin (Laki julkisen hallinnon tietohallinnasta, 16 §).

Käytännössä periaate tarkoittaa, että oikeuksia myönnetään vain sen verran kuin tehtävien hoitaminen ehdottomasti vaatii – ei enempää, eikä varmuuden vuoksi.

Jos tätä periaatetta ei noudateta, käyttöoikeudet alkavat helposti kasautua. Työntekijä vaihtaa tehtävää, osallistuu projekteihin, hoitaa tuurausta tai saa käyttöönsä uuden järjestelmän, ja samalla oikeuksia myönnetään lisää. Useinkaan niitä ei kuitenkaan poisteta, kun tilanne muuttuu.

Tyypillinen esimerkki tästä on tilanne, jossa uudelle työntekijälle pyydetään ”samat käyttöoikeudet kuin Kallella”, ajattelematta, että Kalle on ollut organisaatiossa vuosia, osallistunut useisiin projekteihin ja hoitanut useita rooleja. Hänen oikeutensa eivät siis enää vastaa yksittäistä tehtävänkuvaa, vaan sisältävät kertyneitä pääsyjä moneen järjestelmään. Kun nämä oikeudet kopioidaan sellaisenaan toiselle henkilölle, annetaan samalla pääsy myös järjestelmiin, joita uusi työntekijä ei tarvitse tai joita hän ei lopulta edes tiedä omistavansa.

Näin syntyy näkymättömiä riskejä: käyttäjät, joilla on laajemmat oikeudet kuin työnkuva edellyttäisi ja järjestelmät, joihin pääsee kiertoteitse.

Minimikäyttöoikeus on keskeinen osa riskienhallintaa

Minimikäyttöoikeuden periaatteen arvo korostuu erityisesti silloin, kun käyttöoikeuksia tarkastellaan riskienhallinnan ja liiketoiminnan jatkuvuuden näkökulmasta. Kun käyttöoikeudet on rajattu työtehtäväkohtaisesti ja niiden myöntämistä sekä poistamista ohjataan systemaattisesti, organisaation altistuminen sisäisille tai ulkoisille uhille vähenee merkittävästi. Tällainen malli ei kuitenkaan ole toteutettavissa manuaalisesti – ei ainakaan skaalautuvasti, eikä ilman huomattavaa hallinnollista kuormaa.

IAM-ratkaisu tukee periaatteen toteuttamista skaalautuvasti

Tässä kohtaa nykyaikainen IAM-ratkaisu tarjoaa käytännön keinot periaatteen toteuttamiseen. Hyvin rakennetussa identiteetin- ja pääsynhallintajärjestelmässä käyttäjän käyttöoikeudet määräytyvät automaattisesti hänen työtehtäviensä, organisaatioroolinsa ja yksikkönsä perusteella. Tämä toimintamalli mahdollistaa sen, että oikeudet pysyvät ajan tasalla koko käyttäjän elinkaaren ajan.

Kun uusi työntekijä aloittaa, hän saa automaattisesti oikeudet juuri niihin järjestelmiin ja tietoihin, joita tehtävänkuva edellyttää. Jos henkilön rooli muuttuu, oikeudet muuttuvat sen mukana. Ja kun työsuhde päättyy, oikeudet poistuvat järjestelmällisesti, ilman tarpeetonta viivettä tai unohtuneita käyttöoikeuksia.

Automaation etuna on myös se, että käyttöoikeuksien myöntämisprosessi ei kuormita IT-hallintoa eikä edellytä manuaalista hyväksyntäketjua jokaisessa muutostilanteessa. Oikeuksien hallinta on läpinäkyvää, valvottavaa ja auditoitavissa, mikä helpottaa niin sisäistä valvontaa kuin ulkoisten sääntelyvaatimusten täyttämistä.

Minimikäyttöoikeus on enemmän kuin turvatoimi

Organisaation näkökulmasta minimikäyttöoikeuden periaate ei ole siis vain tietoturvatoimenpide, vaan hallinnan ja luotettavuuden perusta. Sen myötä syntyy ympäristö, jossa käyttöoikeudet eivät ole jatkuvasti muuttuva kompromissi turvallisuuden ja työn sujuvuuden välillä, vaan ennakoitava, dokumentoitu ja hallittu kokonaisuus.

(Alunperin julkaistu Trivore blogissa 24.9.2025
https://www.trivore.com/minimikayttooikeuden-periaate-miksi-samat-kayttooikeudet-kuin-kallella-malli-ei-toimi/)

IAM-järjestelmät ja tiedonhallintalaki: mitä tarjouspyynnöissä usein jää huomaamatta?

Viime vuosina olen osallistunut moniin identiteetinhallintajärjestelmien (IAM) tarjouspyyntöihin. Näissä on yleensä mietitty tekniset yksityiskohdat huolellisesti – joskus jopa liiankin tarkasti. Parhaimmillaan kokonaisarkkitehtuuri saa ansaitsemansa huomion, ja IAM-järjestelmä kytkeytyy luontevasti osaksi laajempaa kokonaisuutta.

Mutta sitten on se toinen puoli. Monessa tarjouspyynnössä unohtuu keskeinen näkökulma: lainsäädäntö. Erityisesti julkisen hallinnon tiedonhallintalaki (906/2019) jää usein taka-alalle, vaikka se vaikuttaa IAM-järjestelmän suunnitteluun ja toteutukseen merkittävästi.

Tiedonhallintamalli on IAM-järjestelmän näkymätön selkäranka

Tiedonhallintalaki edellyttää, että jokaisella tiedonhallintayksiköllä on tiedonhallintamalli. Tämä ei ole pelkkä muodollisuus, vaan konkreettinen kuvaus siitä, miten tieto organisaatiossa elää ja liikkuu.

IAM-järjestelmän on kyettävä toimimaan tämän mallin mukaisesti. Käyttöoikeudet on pystyttävä dokumentoimaan ja hallitsemaan järjestelmä- ja tietovarantotasolla, eikä siis vain teknisesti, vaan myös hallinnollisesti ja läpinäkyvästi.

Pienimmän oikeuden periaate käyttöoikeuksissa

Vaikka laki ei mainitse IAM-järjestelmiä nimeltä, se linjaa käyttöoikeuksista hyvin selkeästi. Käyttöoikeudet määritellään käyttäjän tehtävien mukaan, ja niiden täytyy pysyä ajantasaisina. Tämä kiteyttää pienimmän käyttöoikeuden periaatteen: käyttäjä saa vain sen, mitä tarvitsee. Ei enempää eikä vähempää.

Jotta tämä toteutuu, IAM-järjestelmän on tuettava rooli- ja tehtäväpohjaista käyttöoikeuksien hallintaa. Lisäksi tarvitaan hyväksymisprosessit, audit trail -toiminnot ja kyky linkittää käyttöoikeudet tiedonhallintamallin mukaisiin tietovarantoihin. Ilman tätä kokonaisuutta laki jää helposti pelkästään paperille.

Tietoturva vaatii enemmän kuin teknisiä ratkaisuja

Tiedonhallintalaki korostaa tietoaineistojen saatavuutta, eheyttä ja luottamuksellisuutta. IAM-järjestelmä tukee näitä tavoitteita tarjoamalla tunnistamisen, autentikoinnin ja käyttöoikeuksien hallinnan työkalut. Laadukas lokitus ja valvonta kuuluvat järjestelmän ydintoimintoihin, eivät lisävarusteisiin.

Yhteentoimivuus on järjestelmien yhteinen kieli

Laki edellyttää, että tietovarantojen yhteentoimivuus varmistetaan. IAM-järjestelmän täytyy tukea standardoituja rajapintoja (kuten SAML, OAuth, OpenID Connect) ja mahdollistaa käyttäjätietojen jakaminen eri järjestelmien välillä. Kyse ei ole pelkästä teknisestä yksityiskohdasta, vaan toimivan kokonaisuuden edellytyksestä.

Yhteistyö yli organisaatiorajojen

Tiedonhallintalaki painottaa viranomaisten välistä yhteistyötä. IAM-järjestelmän täytyy siksi mahdollistaa moniorganisaatiotunnistautuminen ja käyttöoikeuksien hallinta yli organisaatiorajojen. Tämä ei ole tulevaisuuden visio, vaan tämän päivän vaatimus.

Yhteenveto

Tiedonhallintalaki ei mainitse IAM-järjestelmiä suoraan, mutta niiden merkitys lain toteuttamisessa on kiistaton. Ilman lakia tukevaa IAM-ratkaisua vaatimusten täyttäminen muuttuu sekä raskaaksi että riskialttiiksi. Tarjouspyyntöä laatiessa kannattaa nostaa tämä näkökulma esiin. Ei pelkästään lain vuoksi, vaan myös sujuvan ja turvallisen tiedonhallinnan takia.

(Alunperin julkaistu Trivore blogissa 20.8.2025 https://www.trivore.com/iam-jarjestelmat-ja-tiedonhallintalaki-mita-tarjouspyynnoissa-usein-jaa-huomaamatta/)

Ensimmäinen kirjoitelma – tervetuloa blogiini

Jo joitakin vuosia on tullut kirjoiteltua juttuja ammatista ja vähäsen sen sivusta lähinnä LinkedIniin. Vähäsen on alkanut harmittaa, kun vanhat tarinat katoaa bittiavaruuteen.

Kun nyt sattui valmiina olemaan Domain ja blogin kirjoitteluun soveltuvat palvelut niin päätin siirtää tarinat tänne turvaan. Alkuun tänne ilmestyy ”parhaita paloja” vanhoista kirjoitelmista, mutta ajan kanssa myös uutta tarinaa.

Kommentteja ja palautetta otetaan ilolla vastaan.

-VP-
Veli-Pekka Vähälummukka

IT osasto hävisi (alunperin julkaistu Kauppalehden vieraskynä blogissa 31.03.2016)

IT-osasto hävisi – huomasiko kukaan?

Osallistuin muutama viikko sitten IBM InterConnect -tapahtumaan Las Vegasissa, joka vyörytti päälle tsunamin lailla tietoa IBM-pilvipalveluista, IoT:sta, oppivasta analytiikasta ja ties mistä teknologian ihmeellisyydestä. Kaikki opittu tieto sai miettimään IT-osaston kohtaloa muuttuvassa maailmassamme.

Suunta on selkeä ja kaikilla tiedossa. Organisaatiot ovat asettumassa omille paikoilleen digitalisaation marssijärjestyksessä. Nokkelimmat tietysti etulinjassa ja loput seuraavat muutoksen aaltoa vanavedessä. IT-osasto sellaisenaan, kuin olemme sen oppineet tuntemaan, tulee poistumaan organisaatioidemme pölyttyneistä kellarikerroksista paikkaan, jonne se ansaitusti kuuluukin. Ei ole hassumpi ajatus, että kellarikerros vaihtuu kattohuoneistoakin korkeammalle, nimittäin pilveen. Tai hybridipilveen. Tai yksityiseen pilveen.

Unohdetaan hetkeksi IT-osaston harppaus ja palataan maan pinnalle miettimään, mitä tämä sitten tarkoittaa käytännössä. Aikaisemmin organisaatioilla oli omat sähköpostipalvelimet, tiedostopalvelimet, tietokantapalvelimet, sovelluspalvelimet ja liuta muita palvelimia. Palvelimia hoitamassa oli joukko omia IT-nörttejä. Nykyisin organisaation tietotekninen infrastruktuuri pakenee kiihtyvällä vauhdilla palveluntarjoajien palvelimille ympäri nettiä – eli pilveen. Kaikki tavanomaisessa toimistokäytössä tarvittavat ohjelmistot ovat jo siirtyneet pilvipalveluiksi eikä niitä ole enää taloudellisesti järkevää pitää omilla palvelimilla. Vähitellen pilveen siirtyvät myös toiminnanohjaukset, sovelluskehitysympäristöt ja muut vaativammat ympäristöt.

IT-infra siis hävisi pilveen, mutta mitä organisaation omaan konesaliin sitten jää? Pölyn lisäksi saattaa olla saattohoidossa palvelimia liittyen turvallisuuteen ja organisaatiokohtaisesti räätälöityihin sovelluksiin. Oman konesalin sijaan nämä palvelimet kannattaa kuitenkin sijoittaa luotettavan kumppanin konesaliin yritykselle dedikoituun ympäristöön (private cloud). IT-slangissa puhutaan tällöin hybridipilvestä.

Elämä IT-osaston häviämisen jälkeen – onko sitä?

Kun IT-infrat ovat hävinneet pilveen ja konesali ammottaa tyhjyyttään, minkä perinnön IT-osasto sitten organisaatiolle jätti? Luultavasti muu henkilöstö jatkaa hommiaan huomaamatta, että IT-osasto olisi koskaan kellarissa ollutkaan, konesaleista puhumattakaan. Jäljelle jäävät käyttäjät ja käyttäjille erilaiset päätelaitteet. Laitteet vaihtelevat älykellosta älypuhelimen ja tabletin kautta perinteiseen työasemaan, ja mitä ikinä tulevaisuus tuokaan tullessaan. Todennäköisesti pilvi jopa mahdollistaa henkilöstölle modernimpien työvälineiden käyttöönoton ketterämmin, kuin mitä perinteinen IT-osasto olisi mahdollistanut. Päätelaitteiden lisäksi jäljelle jäävät tietoliikenneyhteydet, jotka voivat perustua mobiililiittymiin – tai vähänkin järeämpää kapasiteettia tarvittaessa valokuituun sekä kiinteään laajakaistaan. Henkilökohtaisten työvälineiden ja liittymien lisäksi jäävät kenties tulostimet. Siinäpä se perintö tuli jaettua ja IT voi jatkaa onnellisesti tarinaansa pilvessä.

Vai unohtuiko jotain?

Jouduimmeko digitalisaation myötä todella osoittamaan ovensuuta IT-nörteille, vai mihin katosivat kellarikerrosten kokiksen kittaajat? Nostetaan katsetta jälleen ylöspäin havaitaksemme, että pölyttyneet IT-kaverimme eivät olekaan enää niin pölyttyneitä vaan istuvat saman pöydän ympärillä digitalisoimassa organisaatioiden ydinliiketoimintaa. Tukifunktion sijaan nämä IT-nörtit ovatkin nykyään osa organisaation ydinosaamista. Voinemme siis unohtaa nörtit ja alkaa puhua digiammattilaisista.

Miten hankitaan, hallitaan ja tuetaan?

Kun ohjelmistot saadaan pilvestä ja niiden veloitus perustuu käyttöön, kannattaako päätelaitteet investoida itselle? Tuskin. Päätelaitteet siirtyvät mobiililaitteiden tapaan hallintaan etähallintapalveluiden avulla. Fiksu organisaatio nappaa tässä kohtaa vierelleen luotettavan IT-kumppanin, jonka ydinosaamista ovat niin pilvipalvelut, verkkoyhteydet kuin päätelaitteiden hallinta ja laitteisiin liittyvä logistiikka.

Kuunteleminen ei vielä takaa ymmärtämistä – oleellista kumppanin valinnassa onkin, että kumppanilla on ymmärrys siitä, miten laitteet ja käyttäjät tuetaan. Miten päätelaitteet kytketään verkkoon, miten eri pilvipalvelut saadaan keskustelemaan keskenään ja tuottamaan organisaation kannalta mielekästä raporttidataa. Kumppanin täytyy keskustella asiakkaan kanssa samaa kieltä niin liiketoiminnan kuin loppukäyttäjien näkökulmasta.

Mitä seuraavaksi?

Digitalisaation edetessä tullee tapahtumaan myös erilaisten järjestelmien konsolidoitumista. Miksi esimerkiksi tarvitaan kaksi erillistä järjestelmää pääsyn valvontaan, toinen tietojärjestelmille ja toinen fyysiselle pääsylle? Eikö saman järjestelmän kautta voitaisi yhdellä kertaa antaa oikeudet niin ohjelmistoihin kuin kiinteistöihin? Eikö käyttäjälle esimerkiksi voitaisi myöntää pääsy varaamaansa neuvotteluhuoneeseen samalla, kun hän tekee varauksen itselleen kalenteriin? Eikö neuvotteluhuoneesta voitaisi avata valmiiksi video- ja kuvayhteydet muihin neuvotteluhuoneisiin, joista kyseiseen kokoukseen osallistutaan? Eikö kalenterivarauksen kautta henkilölle voitaisi myöntää ajo-oikeus kampukselle kokouksen ajaksi?

Hävisikö IT-osasto sittenkään?

Huomasiko kukaan, miten salakavalasti IT-osasto tekikin itsestään osan ydinliiketoimintaa. Tärkeimmän lenkin bisneksen kannalta. Korvaamattoman. Jopa kuolemattoman? Villi veikkaus on, ettei digitalisaatio näe hetkeen laantumisen merkkejä. Lentävien autojen sijaan tuskin tulevaisuudessa kuljemme hevosella töihin, joten jokainen voi päätellä, mikä merkitys IT-nörteillä – digiammattilaisilla – on maailmassamme.

https://blog.kauppalehti.fi/vieraskyna/blc-wireless-it-osasto-havisi-huomasiko-kukaan